2LoD.sec

セキュリティマネージャの仕事やセキュリティガイドラインの要約など

【雑記】数千件のセキュリティ相談から学んだ対応方法

雑記

JTCのセキュリティマネージャのニキヌスです。

これまでの記事で事業会社におけるセキュリティ業務を紹介（※）してきました。

今回は、地味だが大変な「相談対応」の話です。


私が所属するセキュリティチームには、毎日、約2000人のIT部門メンバから大量の相談が届きます。

これを4～5名で対応していますが、中にはそちらに手を取られて自分のプロジェクトが進められなくなったり、労働時間が伸びてしまったりする人もいます。

相談をどう効率よくうまく捌くか？は意外と文章化されていないように思うので、これまでに身につけた自分のやり方を書いてみます。


※セキュリティ業務に関する過去記事

【雑記】「事業会社のセキュリティマネージャ」というキャリア - 2LoD.sec

【雑記】「セキュリティ戦略」の作り方 - 2LoD.sec

セキュリティ相談とは

相談元のIT部門とは、業務PCやAD等のいわゆる社内システムを担っている部門も、ビジネス部門からのニーズを受けてシステム開発を行う部門も両方あります。

つまり、私たちにはコーポレートセキュリティ・プロダクトセキュリティ両方の相談が集まるということです。

1日5~10件以上ありますから、年間244営業日換算でざっくり1500件/年は対応します。


今回は「システム開発に関する相談」を対象に書きますが、その中にもまた様々なものがあります。

システム開発に関する相談例

このうち具体的なものは知識さえあれば即答できます。

抽象的・例外的なものは、基本的にオープンクエスチョンだし、時には無理を通そうとする相手との調整なので時間がかかります。今回は後者の話です。

相談のゴール

当たり前ですが、相談者の思いは「困りごとをどうにかしてほしい」です。

自分で考えても行き詰った中で何とか突破口はないか、と来るのです。

ですから、求められているのはYES/NOの回答だけではなく、なぜ・何を・どうすればいいのかを一緒に考える必要があります。

相談内容にOKを出す場合は、セキュリティ担当も相談者も「何故OKとしたか」を説明できるようになるべきですし、

NGを出す場合は、相談者が他の人に「NGな理由」と「何をクリアできればよいか」を説明できる状態を目指します。

相談対応の流れ

相談対応はケースバイケース…と見せかけて、実は守るべき流れがあります。それが以下の6ステップです。

内容により対応時間は大きく変わりますが、今回は30分の会議でゴールを目指す最短ケースを書いてみます。

セキュリティ相談対応の流れ

1. 相談内容の把握

まずは相談者からの話を聞きます。 この段階では、相談への回答よりも、後に続く２や３に向けて「追加で何の情報が必要か」を意識しています。


2. 責任範囲の確認

把握した相談内容は自部門で回答すべきか？を考えます。

大企業ほど担当は細分化されているので、下手に管轄外のことを答えてしまうと問題になることがあります。

ただし、自分に提供できる情報がある場合は、管轄外であっても門前払いはせず「本当の担当はＸＸなので正確にはそちらに問い合わせて頂きたいが」「担当外なので一般論として話すが」など前置きした上で伝えます。


3. 全体像の把握

ここが超重要です。

相談対応が苦手な人はこのステップがしっかり出来ておらず、後で追加の事実が出てきて手戻る等、結果的に遠回りになることが多いです。


基本的に相談者は、自分の困りごとを「点」として話します。

しかしセキュリティ担当が回答するためには、以下の情報を含めた「面」を捉えた上で総合的に判断したいです（理由は後述）。

  • 相談対象のシステムは誰が、何のために使うのか
  • どんなデータがどこから生まれ、どう処理されるのか
  • どんなシステム構成か

  • そのシステムをどうする（新規に作る、変更する）のか

  • （設計や実装に関する相談の場合）相談者はなぜその設計/実装を考えたのか

  • 相談者はどういう事情を抱えているのか

この他、１を聞いて分からなかったことも全て洗い出します。

私の場合、１を聞き終わった時点で概ね5～10個くらいの質問が手元に挙がっています。

それらを質問し、全体像を把握し、整合性を確認します。


質問の仕方も重要です。

相談対応が苦手な人は、分からない点を曖昧に投げかけてしまいます。

質問を受けた相談者は、その意図を理解しきれずにかみ合わない回答を返して無駄に時間を費やします。

以下のように、極力自分の理解や想像を言葉にしながらクローズドクエスチョンにすると相談者も答えやすいですし、こちらの勘違いにも気づいてもらえます。

  • こういうシステムやデータの流れと理解したがあっているか？
  • 話に含まれていなかった部分はこういう仕組みになっていると想像するがあっているか？
  • この部分に疑問があり、AとBの2つが考えられるがどちらか？


ちなみに「どんなシステム構成か」については、相談を受けるたびに脳内で似た図を作っているなぁと思いました。それを書いてみたのがこの図です。

意外と反響があり、なんと24年8月号の日経NETWORKと日経クロステックの特集にも掲載されました。


4. 脳内簡易脅威モデリング

これは３と同時に行います。

脅威モデリングとは…だけでも1つの記事ができるテーマですので今回詳しくは書きませんが、簡単に言えばシステムやデータに対して攻撃者や内部不正の目線で「悪いことができそうなところ・こと」を探す作業です。


一般的にはデータフロー図やシステム構成図をもとにSTRIDEモデルを使って信頼境界を中心に云々…とやりますが、ここでは短いやりとりと並行して進めますのでそんなに丁寧なことはできません。

また、システムに対する脅威は様々あれど、普通、組織は共通的なセキュリティ対策を講じています。

例えば、組織全体で利用するインターネット回線にDDoS対策が講じられているなら、システム単位にDDoSの脅威を気にする必要はないわけです。

そうした共通対策でカバーされる脅威は除外して、システム固有の登場人物、アクセス経路、重要データに集中して「それを漏洩や破壊されるシナリオはないか」を考えます。


特に気にするのは認証・認可、ネットワークアクセス制限、クラウドサービスにおけるデータの共有や招待に関わる観点あたりです。

気になるリスクシナリオがあった場合は、３のQAの中で事実確認します。


ところで、相談から離れてまで何故こんな面倒なことをするのでしょうか。

その理由は「より大きな問題の見落としを防ぐため」です。

よく聞いたらそもそも相談内容以前にダメじゃない？ってことはよくあります。

それを見落として問われたことだけ回答すると、相談者は「セキュリティ担当にOKもらった！」と全体にお墨付きを得た気持ちで進んでしまいます。

中には、見落としではなく、本当にマズい問題を意図的に隠してくるケースもあります。「そっちは触れてほしくない」的なやつです。


ですので、セキュリティ担当は相手の土俵で話してはいけません。

どういう相談内容や話し方であれ、自分の言葉で全体像をとらえて自分なりのリスク洗い出しを行うのです。

３で「総合的な判断」を重視した理由の１つはここにあります。


5. 論点の整理

ここまでに多くの情報が得られました。

場合によっては、相談内容以外に複数の論点が生まれているかもしれません。

それらを全て潰しこむかどうかは、相談を受けたタイミングにより異なります。

開発プロジェクトの企画・設計段階における相談であれば、一旦全ての想定リスクへの対策案を検討します。

リリース直前の相談であれば、リスク評価により確実に潰すべきポイントを絞った上で、対策案を検討します。


「リスク評価」とは、発生可能性×影響でリスクを優先付けすることです。

この際、漏洩などの直接的な被害だけでなく、何のルールに違反するのか（法、業界ルール、社内ルール）も含めて考える必要があります。

例えばリスクが小さくとも法令違反は見過ごすわけにはいきません。


「想定リスクへの対策案を検討」とは、リスクへの打ち手を考えることですが、これにも優先順位があります。

機械的な予防 ＞ 機械的な発見 ＞ 手動による発見 ＞ ルールや教育のみ

左からまずはできることがないか、それが無理なら右に…と順に考えます。


沢山書きましたが３，４，５は同時並行で行います。


6. 調整～回答

最後のステップです。

相談に対する見解 ＋ 追加で認識したリスクと対策案を伝え、方向性をすりあわせます。


相談内容がセキュリティ的に問題ない場合は、判断理由も含めて伝えます。

何らかのリスクが残る場合は、ケースバイケースで結論が変わります。

３で「総合的な判断」を重視したもう１つの理由はこのためで「落としどころはコンテキストにより変わるため」です。


単純に「セキュリティ標準を満たせなくてもいいですか？」と問われると、NGとしか言えません。

しかし、前提となる業務の特性的にリスクが大きくないと考えられる場合は例外OKにできるかもしれません。

実はXか月後には別のプロジェクトで改善できそうな見込みがあれば、簡易な補完策だけ加えて一旦OKとできるかもしれません。

あるいは、マイナス50点の現状をプラス30点くらいにレベルアップする話であれば、合格ラインである70点に届いてなくとも一旦は目を瞑って段階的にレベルアップしていく判断もあるかもしれません。


このようにリスクに対する判断は単純なYES/NOではないからこそ、セキュリティ担当は困りごとをどうにかするために役立てられそうなヒントを必死にかき集めていたのです。

大事なのはリスクを100％潰しこむことではなく、リスクへの対応方針の妥当性を説明できるようにすることです。

こういう前提なら、ここまでの補強が出来れば、一応OKと説明がつく。という理屈を立てられれば、ひとまず前に進むことができます。


しかし残念ながら、理屈が全く立たずに「NGとしか言えない」ケースもあります。

その場合は、せめてここまでは満たしてほしいラインを伝えて持ち帰ってもらいます。

中には「ダメなのは分かっているが認めてもらうしかない」みたいなケースもあり、その場合はセキュリティ担当だけでは結論を出せないので、各組織の責任者を集めて組織判断をします。

つまり、ビジネス面の事情を踏まえてリスク受容するのか、ビジネス側を縮小・撤退するのか。といった判断です。

そういう混沌とした判断のパターンをまとめたのが↓の図の３．です。


さいごに

以上、ざっと相談対応の流れを書いてみました。

「効率の良い捌き方」の割に長ったらしい…と感じたかもしれませんが、何千回と繰り返す中で結局これが最短だと思っています。


大事なのは6つのステップをしっかり踏むことと、相談対応の中で学んだこと（自社の環境の知識など）を次に活かすことです。

そうすることで問題点の洗い出しが早くなったり、提示できる解決策が増えたりしますので、結果的により早く・より正確に対応できるようになります。


また、この対応を繰り返すことでメリットがもう1つあります。

それは「社内の情報が集まりやすくなること」です。

一度自分の悩み事を何とかしてくれた人には、次も相談が集まります。新しい話は「とりあえず耳に入れとく」繋がりが生まれます。

そうして得られる情報は、事業会社のお仕事をする上で必要不可欠なのです。


（余談）セキュリティ相談 今昔物語

私がセキュリティ担当を始めた約10年前は相談といっても週に数件程度でした。

仕事が回らなくなるほどの相談が寄せられるようになったのはここ3，4年です。


激増のキッカケは、セキュリティ標準を明確化してチェックリスト化し、システム開発プロセスに組み込んだ（評価プロセスを作った）ことです。

開発者としては、チェックリストを満たせないとリリースできないし、セキュリティ担当から面倒なツッコミが入るので、不安な点は相談せねば…という動きに繋がります。


一般的にセキュリティチェックリストは「諸悪の根源」「意味ない」と忌み嫌われるものです。

が、チェックリストが生まれる前に作られたシステムを今ひも解くと、基礎的な脆弱性がバンバン見つかる、というか設計や実装においてセキュリティがほぼ考慮されていない恐ろしいものもあったことが分かっています。

当時の担当者に理由を聞くと「だって要件がなかったから」

そんな状態に比べると、チェックリストといえど、セキュリティを意識する人が増えて相談が増えたのは良いことだと言えます。


とはいえ、相談が多いことが望ましいわけではありません。開発スピードの阻害要因にもなります。

ですので、私が次に目指しているのは「開発品質を保ちつつ相談を減らすこと」です。

それにはセキュリティ標準を分かりやすくし、開発プロセスにおけるセキュリティ対策をシフトレフトし、開発者を教育し、、と色々動き出しているところです。


最終的には、10年前のように相談件数が週に数件程度に減り、開発者もセキュリティ担当も自分のプロジェクトに時間を割けて、相談が来てもスマートに対応できる組織を目指したいなぁと思っています。


これまでの記事一覧はこちら