情報システムの価値を壊すセキュリティは悪である

どうも おかしん です。

つい最近Xでこんな投稿が話題になってました。

経験上「セキュリティ組織は独立させない方が良い」という結論

分けると、
すべてのセキュリティ関連の判断が安全側に倒される
　↓
業務担当と折り合いがつかないか業務がやりにくくになる
　↓
問題発生
　↓
（上に戻って繰り返し）
　↓
セキュリティ担当は業務の責任を負わないから、このループが加速
　↓
最終的にクチだけ出す偉そうな人ができあがる
　↓
なんでそんな意味わからん業務やってんの？みたいな業務ができあがる
　↓
業務担当の負担が限界突破
　↓
徐々に人が減る
　↓
・・・

セキュリティわかる人が業務するのが理想ですよね。

私はこれに対して、こんな感じで引用しました。

めっちゃわかる。セキュリティしかやらないやつはクソだよまじで。何の価値もない。

とまあ社内外から怒られそうなことを言ったわけですが、全部を伝えきれたわけじゃないので、改めてしっかりと真意を説明しておこうかと思います。

世間の反応

sonic_taxi氏は、分けること自体ではなく、業務と優先度を理解していないセキュリティ組織の出来の悪さが問題だと整理していました。

MinaMizushina氏は、セキュリティが可用性を無視しがちな点を指摘し、別のリプライでも可用性をセキュリティのスコープに入れる必要性に触れていました。

また、qkr7f氏は、セキュリティ側を検察官、現場側を弁護士に見立て、経営という裁判官が不在になっていることを問題としていました。

eidocarity氏は、品質管理部門のような位置づけでセキュリティ監査と責任を持たせる案に触れていました。

分けると業務と噛み合わず、分けないと統制が効かない。概ねこの二択で話がこじれているように見えます。結論から言うと、分けるかどうかは本質に届きません。大事なのは、分けていても、分けていなくても、セキュリティ機能が事業価値を追えているかです。無条件に独立させるべきなのは、運用ではなく監査です。

この記事では、なぜ「セキュリティだけを追う」ことが悪だと考えているのかをまず説明し、そのうえで、情報システム部門とセキュリティ部門の分離を、組織図ではなく、目的の序列、職務分掌、監査の独立、経営判断の材料という観点で整理します。

そもそも情報セキュリティは何を守るもの？

情報セキュリティとは、情報資産のセキュリティ、つまりCIA（機密性、完全性、可用性）を維持することです。FIPS 199でも、情報と情報システムのセキュリティ目標はこの3つで整理されています。

情報資産とは？

情報資産とは、文字どおり、情報の形をした資産です。

情報資産はどこにあるのかというと、基本的には情報システムの上にあります。

広義では、情報資産が入っているデバイスそのものも情報資産と見なすことがありますが、それは正直、辞書的な意味で含めているに過ぎません。私個人としては、あまりセンスが良い定義ではないなと思っていて、情報資産というのは、やはりその中に入っている「情報そのもの」だと考えています。

情報資産（情報）は、端末も含めて、基本的には情報システムの上を流通しているものです。

情報システムは何のためにあるもの？

じゃあ、その情報システムというのは何のためにあるんでしたっけ、という話です。

これは営利・非営利、業種・業態・規模を問わず、何らかの事業活動を効率化したり、円滑に進めたりするために使われるものです。

逆から読んでみる

ここまでの話を、逆から読んでみます。

何らかの事業があります。その事業を効率化したい。品質を上げたい。再現性を高めたい。顧客によりよい価値を届けたい。だから情報システムを導入・構築し、運用していきます。

情報システムが生まれると、その中を流通する「情報資産」というものが生まれます。それこそが情報システムによって生み出された価値そのものです。その情報資産を守るために、情報セキュリティがあります。

情報システムの生み出す価値を毀損する情報セキュリティは悪である

つまり、情報システムが生み出す価値を守るためにやるのが情報セキュリティなんです。

だから、情報システムが生み出す価値を毀損するような情報セキュリティというのは、基本的には悪なんです。

これは「セキュリティなんて軽く見てよい」という話ではありません。むしろ逆です。守るべきものを見失ったセキュリティは、結果的にセキュリティの実効性も落とします。

たとえば学校の校庭を考えると分かりやすいと思います。校庭は、子どもが走ったり、遊んだり、体育をしたりして、体を動かすためにあります。もちろん、けがをしないように安全を考えることは大事です。危ない遊具を点検する。危険な使い方を止める。必要ならルールを作る。それ自体は悪いことではありません。

小学校設置基準は学校施設として運動場を置くことを前提にしていますし、学校教育法は健康な身体の育成を義務教育の目標に含めています。一方で、学校保健安全法は学校安全計画や学校環境の安全確保を求めています。目的と安全策は、どちらか片方ではなく両方要るんです。

でも、けがを防ぐことだけを目的にして、走るのは禁止、ボール遊びは禁止、遊具は禁止、転ぶかもしれないことは全部禁止、としていったらどうでしょうか。事故は減るかもしれません。でも、子どもが健やかに体を動かすという、校庭が本来生み出すはずだった価値は失われます。

これは「安全にしている」のではなく、校庭の価値を壊しています。

情報セキュリティも同じです。情報システムが事業活動を支えるためにあり、その上にある情報資産を守るために情報セキュリティがあるのだとすれば、情報システムが生み出す価値を毀損する情報セキュリティは、本末転倒です。やはりそれは悪です。

情報セキュリティが暗黙的に守るべきもの

ついつい情報セキュリティというと、情報資産のCIAを維持することに執心しがちです。

ただ、ここまでの話から分かるように、情報セキュリティは、そもそも情報システムが生み出す事業価値そのものを守るためにあります。

これは、情報資産のCIAを維持するという活動の裏側に、そもそも暗黙的に、絶対に基盤としてあるべきものなんです。

ここを忘れると、情報セキュリティは「セキュリティのためのセキュリティ」になります。

機密性だけを見る。例外を認めない。現場の可用性を見ない。業務の目的や期限を見ない。リスクの大きさに関係なく、全部を同じ厳しさで止める。

分けると、守るべき価値が見えにくくなる

特に、情報セキュリティが情報システム部門から独立している場合、このズレは起きやすくなります。独立していること自体が悪いのではありません。ただ、情報システムが生み出す価値から距離ができると、「その統制は何を守るためのものなのか」という問いが抜け落ちやすいんです。

その結果、形式上は安全に見えるけれど、現場は回らない、という状態になります。申請が遅すぎるから個人アカウントでSaaSを契約する。承認が重すぎるから管理者権限を共有する。ファイル共有が現場に合わないから、別経路でデータを渡す。

これは安全になっているのではありません。統制の外側に、見えないリスクを押し出しているだけです。

Bruce Schneierは、安心感は与えるが実際の安全性を高めない施策をsecurity theaterと呼びました。また、Compliance Budgetの考え方では、利用者がポリシー遵守に払える努力は有限であり、遵守コストが積み上がると回避行動が起きると整理されています。

ここで言いたいのは、用語の紹介ではありません。統制は、存在するだけでは意味がないということです。

その統制で何のリスクを下げるのか。代わりに何の価値を失うのか。利用者は正規ルートで仕事を続けられるのか。そこまで見ないと、セキュリティのためのセキュリティになります。

それでも、分ける意義はある

一方で、だから情報システム部門と情報セキュリティ部門を分ける意味がない、という話でもありません。

分けることには、ちゃんと意義があります。大きくは2つです。

1つ目は、監査的な目的と独立性の確保です。

情報システムを管理・運用している人は、強い権限を持ちます。アカウントを作れる。権限を付けられる。ログを見られる。場合によってはログを消せる。バックアップや監査設定にも触れる。

こういう権限を持つ人は、組織を守るために必要な存在です。同時に、その人たち自身が機密性、完全性、可用性を毀損できる存在でもあります。

だから、運用している人が自分で自分を監査する形には限界があります。NIST SP 800-53 Rev.5 の AC-5は、職務分掌を正当な権限の濫用リスクを下げるための管理策として扱っていますし、CISAの内部脅威の整理やCERT National Insider Threat Centerのガイドも、正当なアクセスを持つ内部者や特権者のリスクを扱っています。

ただし、ここで独立させるべきものを間違えると話がおかしくなります。無条件に独立が必要なのは、運用の全部ではありません。まず監査です。

IIAのThree Lines Modelでも、第1線は業務とリスク管理の実行、第2線はリスク管理やコンプライアンスなどの支援・監視、第3線は内部監査として整理されています。独立性が特に重要になるのは第3線です。

2つ目は、組織規模に伴う分業です。

組織が大きくなれば、情シスがすべてのシステム運用、セキュリティ企画、監査対応、インシデント対応、リスク評価、教育、規程整備まで抱えるのは難しくなります。専門性も要ります。集中して見るべき領域も増えます。

なので、分けること自体は自然です。むしろ、規制産業、上場企業、重要インフラ、個人情報を大量に扱う組織では、独立性や職務分掌の要求は重くなります。

でも、それは「セキュリティが事業価値から離れてよい」という意味ではありません。分けるなら、むしろ本質を追う責任は重くなります。

分ける・分けないの前に、何を分けるのか

この議論が難しいのは、「分ける」という言葉がいくつもの意味を持っているからです。

この4つを混ぜると、議論は一気に雑になります。

情シスとセキュリティを別部門にしたから安心、ではありません。逆に、同じ部門にあるから必ず危険、でもありません。見るべきなのは、どの機能に独立性が必要なのか。そして、その独立した機能が、事業価値を守るために働いているのかです。

NISTや監査基準のような信頼できる文書を見ても、答えは「常に分けるべき」でも「常に統合すべき」でもありません。NIST Cybersecurity Framework 2.0は、サイバーセキュリティリスク管理を全社的リスク管理へ組み込むことを重視しています。同時に、ICTリスク管理を全社的リスク管理へ高いレベルで統合する組織もあれば、十分な注意を払うために分ける組織もある、と整理しています。

小さな会社では、完全な職務分掌が難しいこともあります。PCAOB AS 2201でも、小規模で複雑性の低い会社は、職務分掌の機会が限られるため、代替統制で目的を達成する場合があるとされています。

つまり、組織図の正解を探す話ではなく、目的に対して設計する話なんです。

セキュリティのためのセキュリティにならないために

分けたなら、本質を追う責任が残る

セキュリティ部門を分けるなら、むしろ本質を追う責任は重くなります。分けたことは、事業価値を見なくてよい理由にはなりません。別部門になった瞬間に、現場の業務、売上、顧客影響、可用性、利用者体験から自由になるわけではありません。

では、どうすれば「セキュリティのためのセキュリティ」にならずに済むのか。

目的の順序を逆にしない

まず確認すべきなのは、目的の順序です。

事業がある。事業を支えるために情報システムがある。情報システムの上に情報資産がある。その情報資産のCIAを守るために情報セキュリティがある。

この順序を逆にしない。

統制ごとに「守る価値」と「失う価値」を説明する

次に、統制ごとに「守る価値」と「失う価値」を説明できるようにします。

そのルールは何のリスクを下げるのか。どの情報資産を守るのか。代わりに、どの業務を遅くするのか。現場は正規ルートで仕事を続けられるのか。例外を認めるなら、期限、承認者、ログ、見直しはどうするのか。

ここを説明できない統制は、かなり危ないです。

可用性と利用者体験をセキュリティの外に置かない

可用性はCIAの一部です。利用者体験は「優しさ」だけの話ではありません。使いにくい統制は、現場を正規ルートから遠ざけます。結果として、管理できないSaaS、共有アカウント、個人ストレージ、説明できない例外が増えます。

運用と監査を混ぜない

セキュリティ担当が運用に近いこと自体は悪ではありません。むしろ、業務を知らないセキュリティは危ういです。ただし、監査する人が監査対象の運用権限を持っている、例外を承認する人が自分でログも閉じる、という形は避ける必要があります。

経営に判断材料として渡す

専門部門の役割は、危険か安全かを一言で決めることではありません。効果、リスク、コスト、代替策、残るリスクを並べ、経営が妥協ラインを決められるようにすることです。以前、情シス・情報セキュリティはどう経営と対話すればいいのかでも書きましたが、ここを飛ばすと、現場も経営も「セキュリティに止められた」という受け取り方になります。

関連して、NIST IR 8286の読み方は以前の記事 NIST IR 8286 Rev.1を読むでも整理しています。サイバーリスクを経営リスクの言葉へ翻訳する、という意味では今回の話とも地続きです。

「セキュリティのためのセキュリティ」になっていないか

ここまで話してきたことがちゃんとできているかを確認するには、以下の5つをチェックすればいいです。

1. その統制は、情報システムが生み出すどの価値を守っているか。
2. その統制は、機密性、完全性、可用性のどれに効いているか。
3. その統制によって、現場は正規ルートから外れていないか。
4. 監査する人が、監査対象の運用権限を兼ねていないか。
5. 経営が選べる形で、効果、リスク、コスト、代替策、残余リスクを提示できているか。

まとめ

情報システム部門と情報セキュリティ部門を分けるかどうかは、本質ではありません。

情報システムは、事業の価値を生み出すためにあります。情報セキュリティは、その価値を守るためにあります。だから見るべきなのは、部門を分けたかどうかではなく、守る価値、下げるリスク、失う価値、残るリスクを言語化できているかです。

「セキュリティのためのセキュリティ」にならないためには、情報システムと情報セキュリティがそれぞれ何のために存在しているのかを見失わず、経営に判断材料を提供し、対話し、意思決定につなげ、それをシステムや運用に落とし込んでいく。価値を守りながら、事業を前に進める。情報システムや情報セキュリティの仕事は、本来そこにあるはずです。

さいごに

冒頭で「社内外から怒られそう」なんて書きましたが

弊社にも「セキュリティ&データガバナンスセクション（通称セキュリティチーム）」という部門があります。でも、弊社のエンジニアリングセクションは全て「ビジネステクノロジーコンサルティング部」という部の配下にあるんですね。

つまり弊社のセキュリティチームは「セキュリティのためのセキュリティ」とは真逆の、お客様に事業価値を高めることに真剣に向き合ったセキュリティをやってるってわけ。

ではまた