最近ライトなテーマが続きました。
今回はセキュリティマネージャが本領発揮する「セキュリティ戦略策定」について書きます。
NRI Secure Insight 2022によると、日本企業で最も不足しているセキュリティ人材は「戦略・企画を策定する人」だそうです。
この記事の内容が「ベストな正しい方法」かは分かりませんが、一応やったことがある立場として自分なりの手法を書いてみます。
セキュリティ戦略とは
セキュリティ戦略とは、自組織のセキュリティをどんな姿に・どう進めていくか、中長期的な計画を定めたものです。
中身はともかくとして、戦略といえばおおむねこんなものがイメージされると思います。
例としてNISCのサイバーセキュリティ戦略や米国家サイバーセキュリティ戦略（解説記事はこちら）が挙げられます。
今回は一企業の話でありIT部門に近い目線の話なので上記例に比べるとスケールは小さくなりますが、構成は大体同じです。
ただし、今回主に扱うのは柱と具体策の決め方であり、コンセプトの話には触れません。理由は後述します。
戦略策定に取り組む前に
戦略策定の中身に入る前に、周辺部分について書きます。
いつ作るのか
戦略は継続的に見直し続けるのが理想ですが、実際には3年サイクルなどの中期計画にあわせて作りなおすことが多いと思います。
策定には膨大な情報収集、処理、調整を必要とするため、1ヵ月程度で「エイヤ」で作れるものではないです。
組織の規模にもよりますが3～6ヵ月くらい見込んでおいたほうがよいと思います。
誰が誰と作るのか
教科書的にはCISOかもしれませんが、実態はセキュリティマネージャ的な人が作るかと思います。（特に「とりあえず設置しただけ」のCISOが多い日本企業においては。。）
策定にあたり巻き込むべき人は以下が考えられます。
- 意思決定権者（経営層、居る場合は特にCISO）
- 予算権者
- システム部門
- セキュリティ部門
- 監査部門
- 外部コンサル（必要に応じて）
戦略策定の進め方
戦略策定ってどこから取り組むのでしょうか。
大きなコンセプト決めからか、個々の具体策の積み上げからか、入口から悩みます。
セキュリティ戦略は経営戦略やIT戦略と整合するものですからトップダウンアプローチは確実に必要です。
一方で、攻撃者としては細かいWeakest Linkこそ狙い目ですからボトムアップアプローチも取り入れたいです。
このハイブリッド方式の流れはこんな感じです。
なお、この方式で作られた戦略には多種多様な柱が含まれます。
それらを一言でまとめるコンセプトワードは納まりの良い抽象的な言葉になりがちです。冒頭でコンセプトの決め方には触れないと書いたのはこれが理由です。
ステップ１．検討のタネを集める
我々が普段目にする戦略は、組織が検討を重ねた結果をカッコよくまとめたアウトプットです。それが元々どういうインプットから生まれたのかを知る機会は多くありません。
それゆえに、いきなり戦略を作れと言われてもとっかかりが掴めない人が少なくありません。
以下にインプット（検討のタネ）を集めるための手法や観点を挙げます。
検討手法①：ヒアリング／ベースライン分析／リスクベース分析
「ヒアリング」は名前の通り、様々な立場の人へのご意見伺いを通じて検討のタネを探す方法です。単純そうに見えますが、価値のある情報を引き出すためには高いファシリテーション能力が必要です。
「ベースライン分析」はISMSやCIS Controlsなどを用いて自社の課題を洗い出す方法です。成熟度評価ツールやサービスを活用する場合もあります。
「リスクベース分析」は特定の検討テーマ（脅威）について攻撃シナリオを考え、その攻撃を防御・検知・対応・復旧するために必要な対策を評価対象システムが打てているか確認する方法です。後で詳しく説明します。
検討手法②：机上評価／実機評価
「机上評価」は検討手法①で挙げたものが該当します。
「実機評価」はペネトレーションテストなどが該当します。戦略策定のためにペネトレーションテストを始めるというよりも、定期的に実施しているテストから見つかった課題をインプットとして拾うイメージです。目線の高さ：経営目線／現場目線
「経営目線」は経営戦略やIT戦略を踏まえてセキュリティがどうあるべきかを考えます。「新たな業種への参入に伴うセキュリティ対策」や「グループ会社の統制」「サプライチェーンリスク」といった大きなテーマが挙がりやすいと思います。
「現場目線」は「実はあのクラウドを使えばデータが持ち出せてしまう」「XXの通信経路をWAFで監視できていない」といった細かいものが挙がると思います。目線の方向①：外部の変化／内部の課題
「外部の変化」の把握にはセキュリティベンダの脅威レポートや業界動向系の資料が役立ちます。 １，２年前だと「ゼロトラスト」、最近だと「AIセキュリティ」みたいなキーワードが挙がると思います。「内部の課題」は名前の通りです。（上述の）新たな業種への参入、買収したグループ会社の統制、セキュリティ運用負荷の高まりなど様々です。
目線の方向②：過去からの積み残し課題／未来に向けた新たな課題
名前の通りです。
上記の記載にあたり、一部、以下のブログを参考にさせて頂きました。
この作業は大変です。でも、ここで入念に洗い出しておかないと後になって「そういえばアレはなんで入ってないの？」と偉い人からツッコミを受け、せっかくまとめた戦略に無理やりねじ込むハメになったり、検討の網羅性を疑われて手戻りになったりしますので、丁寧に頑張りたいところです。
このステップのポイントを２点挙げます。
１点目は、大きすぎるタネを早めに砕いておくことです。
特に経営層へのヒアリングでは粒度が大きく抽象的なキーワードが出がちです。
ゴールイメージが湧かないタネが登場した場合は「どんな状態になったら達成と言えるか」を掘り下げて定義しておく必要があります。
２点目は、セキュリティマネージャ自身がしっかり考える時間を取ることです。
様々な洗い出し手法を書いたものの、セキュリティの課題意識や目指したい思いを一番持っているのはセキュリティマネージャ自身です。
＜参考：リスクベース分析とは？＞
「ウチの〇〇システムは××という攻撃に耐えられるのか？」の観点から課題を抽出する方法です。
正しい手法を学んだわけではないですが、私は以下のように分析しています。
①評価対象の脅威を決める（ざっくり）
②評価対象システムを決める（ざっくり）
③①の脅威について、攻撃の流れをサイバーキルチェーンに沿って洗い出す（ざっくり）
④チェーン上の各攻撃への対策をNIST CSFに沿って洗い出す（ざっくり）
⑤②の評価対象システムごとに④の対策状況を評価する
サンプルイメージを作りました。上の①～⑤と図中の黄色い丸印が対応しています。
この表が１つの脅威に関する１セットであり、脅威の数だけ同様のセットを作成します。
なお、あくまでイメージ用なので記載内容の網羅性は考慮していません。むしろ色々削っています。
この作業のポイントは、何度も書いた「ざっくり」です。
技術力が高い人ほど攻撃手法や対策をアレコレ思いつきますが、細かすぎると終わらないので中程度の粒度感でざっと進める力加減が重要です。粒度の細かさは分析を繰り返す中で上げていけばいいのです。
「中程度の粒度感」のイメージは例えばこんな感じです。
①の脅威は「DoS系の攻撃によるサービス停止」「マルウェア・ランサムウェア感染」「内部者による不正」「サプライチェーンの…」みたいな大枠の種類を考えます。多くて10種類くらいのイメージです。
②の評価対象システムは代表的・特徴的なシステムを数個選びます。「従業員の業務用端末群」「お客様向けに提供する代表Webシステム」「社内向けの基幹システム」といった括りです。
この分析を通して「マルウェア感染リスクに対してBシステムはVPN機器の脆弱性対策の強化が必要。また、バックアップの保護とリストア訓練が必要」といった課題と改善策の抽出ができます。
具体的な脅威や攻撃シナリオに基づいた発見が得られるため、ベースライン分析に比べて関係者からの納得感を得られやすいように思います。
ステップ２．トップダウンで柱を仮決めする
ここまでに集めたタネの中に、明らかに「これは問答無用で柱にすべき」というものがあるはずです。
それは経営戦略やIT戦略と整合するために重要なものであったり、数年かけて取り組む価値がある組織全体の・目線高めの課題だったりします。
例えば、「新たにヘルスケア事業に参入する！」という全社方針が経営層から出ている場合、セキュリティ戦略にも「ヘルスケア業界のセキュリティ標準に対応する」柱が生まれるのが自然だと思います。
粒度の細かいタネと格闘を始める前に、そういう主要な柱はこの時点で仮確定として横によけておきます。
ステップ３．タネをふるい分ける
ここからは比較的細かいタネをこね回してボトムアップ的に柱に仕上げていく作業です。
これまでに洗い出した玉石混交のタネを「関係性と実現性の把握」「リスク評価」を行い取捨選択します。
タネ集めは丁寧かつ客観的に進めましたが、ふるい分けは豪快かつ主観的に進めざるを得ない場面があります。
（１）関係性と実現性の把握
以下のような観点からタネ同士の関係性や、それぞれの実現性を把握します。
類似テーマのグルーピング
実施効果の依存整理
「Aの対策をやればBの対策の必要性が下がる」みたいな関係です。
内部の実施順序の依存整理
「Aができない限りBには着手できない」「AとBはまとめてやったほうが効率的」みたいな関係です。
外部の実施順序の依存整理
「AはXXシステムのサポート切れ再構築のタイミングでやったほうが効率的」「BはXXというソリューションが成熟してから着手したほうが効率的」といった関係です。実現性の把握
そのままです。自社の組織体制やシステム環境の特性を踏まえ、それぞれの難易度を考えておきます。
（２）リスク評価
これまでに洗い出した検討のタネは、いずれも何らかのリスクに対する改善策であるはずです。
一般的なリスク評価の手法と同様に、リスクの発生可能性（Probability）とリスクの影響（Impact）の2軸で分類し、優先付けします。
大量のタネをふるい分けるのは途方もない労力がかかるように思うかもしれません。
しかし、実際には、ふるい分けの70%くらいはタネの洗い出しと同時に終わっている感覚です。
何故かというと、私がこの記事で書いたように、本来セキュリティマネージャは自社のシステム環境、セキュリティ面の課題、組織体制や文化を詳しく知っているために、このステップで書いたことは「見た瞬間になんとなく分かる」はずだからです。
もちろん勘違いも多々あるので後のステップでシステム部門を巻き込んで裏どりしますが、この時点ではおおよその粗さでよいと思います。
ステップ４．ボトムアップで柱を仮決めする
先ほどふるい分けたタネから柱を作ります。
ステップ３の（１）でグルーピングしたものや（２）で①最優先群に含まれるものほど柱になりやすいはずです。
柱の決め方（まとめ方やネーミング）は結構センスが問われるところで、賛否あると思いますが、適度にバズワードを取り入れると捗る場合があります。
例えば「ゼロトラスト」という言葉の中には認証・認可の見直し、脆弱性管理や構成管理のレベルアップ、ログ取得のレベルアップ、ネットワークのセグメンテーションの細分化など細かいタネを詰め放題です。こういう言葉は経営層もある程度耳にしたことがあるため「オッ大事そう！」と謎の納得感を得られます。「サイバーレジリエンス」とかも似たように使えます。
ただし、バスワードの乱用は全体的に何言ってるか分からん戦略になるので要注意です。
また、最初のイメージ図にも書きましたが、柱の中には横断的な施策として位置づけたほうが納まりが良いものがあります。組織体制に手を加えるものや育成・教育系の施策が当てはまりやすいと思います。
柱を決める際のポイントを2点挙げます。
一つはバズワードを取り入れる際は戦略を立てる本人がその言葉の定義やゴールイメージをしっかり腹落ちさせてから使うことです。そうでないと、後で銀の弾丸化したバズワードに振り回されます。
もう一つは、手段だけの言葉を柱のタイトルにしないことです。「ゼロトラストモデルの実現」は手段でしかないです。「XXのためのゼロトラストモデルの実現」のように、手段を通じて何を成し遂げようとしているのかが大事です。
ステップ５．計画を具体化する
おおむね仮の柱が出そろいました。
しかし、この時点ではまだまだ不確定要素が多いです。ステップ２で決めたトップダウンな柱は粒度が大きいままだし、ステップ３で考えた実現性についても裏どりが必要です。
それらを具体化し、誰が・いつ・何をやるか、個々のプロジェクト単位に落とし込みロードマップ化します。
ここではシステム部門を巻き込むことが重要です。
戦略を推進する際にはシステム部門の協力が欠かせません。それにも関わらず、立案時にシステム部門が何も聞いていないようでは協力する気になってもらえないと思います。
また、戦略策定後は経営レベルで達成状況を管理される中「いざやってみたら一歩目から全然できないことを戦略化してました」となるのは避けたいです。事前にある程度勝算を見込むためにも巻き込む必要があります。
反面、具体化にこだわりすぎないよう注意が必要です。
システム部門の皆さんは「戦略化されたが最後、自分達がやらされる」という危機感もあり、真剣に考えてくれます。
それは非常に心強いのですが「確実に実現可能と言い切れないから戦略には出さないでほしい」みたいな石橋を叩きすぎる声が出てくる場合もあります。
この段階で具体化すべき粒度と各プロジェクト内で具体化すべき粒度を区別することが必要です。
ステップ６．合意する
ここまでの検討で、主要な柱と、柱に属する具体策、おおよそのロードマップが見えてきたと思います。
それらの合意に向けてやっとアウトプットを作る時です。しかし、どんな資料を作ればよいのでしょうか。
私は最低限、3つの資料が必要だと思います。
1つ目は冒頭に挙げたように戦略の全体像が分かるもの。（具体策は代表的なもののみ記載）
2つ目は柱と具体策（全量）の関係、および具体策の概要が分かるもの。
3つ目は各具体策の検討経緯の詳細を記したものです。後々のトレーサビリティのためにも、柱に含み切れなかった検討のタネを最終的にどう整理したのかや見送った理由を残しておきます。
加えて、これは必須ではないですが、技術策系の柱に関する解説資料を作るようにしています。
特に経営層に多いのですが、柱は分かったけどもう一歩詳しく知りたい。けどシステム的に難しいことは分からん。という中で「結局何がどう変わるの？」という質問を受けることがあります。その際にこういう資料を出すと興味深そうに聞いてくれます。
一例として、以下はアカウントハッキングの脅威が大きな課題だった時に、関連する対策群を図にしたものです。
システムに詳しくない人には、システム構成図ベースで変更点を話しても伝わりません。
どんな攻撃の種類があり、攻撃の流れをどう食い止める対策をいつやるのか、みたいな情報を盛り込みます。
また、多層防御の全体感を知ってもらうために既に出来ている対策もあえて記載しています。
最後に、当たり前のことですが、資料化の際に「計画は確定ではなく随時見直す」ことを明記しておきましょう。
戦略策定は細部までデザインするものではなく大きな羅針盤を作る作業なので、各プロジェクトを進める中で断念せざるを得ないものもあれば、途中で変更する場合もあります。それらに柔軟に対応できるように「予定は未定」であることも握っておきましょう。
そして、だからこそ、戦略は策定後に何度も見直すことが重要です。
余談：外部コンサルに任せられるのか？
私は戦略策定の一部を外部コンサルに頼るのはアリだけど、コンサル頼み・コンサル任せは無しだと思います。
セキュリティ対応組織（SOC/CSIRT） の教科書でもその考え方が示されています。
（CDCのサービスカタログのうち「A. CDC の戦略マネジメント 」のサービスの多くが「自組織で実施すべき領域」に属する）
私はこれまでに様々なコンサル会社の方々とお仕事をさせて頂きましたが、概して彼らは非常に優秀です。
こちらの組織体制やシステム構成を短期間で鳥瞰的に把握する能力や、パワーをかけねばならない調査系タスクの推進力、段取り力は目を見張るものがあります。
しかし、上の図にもある通り、セキュリティ戦略策定は「組織内部の情報」を必要とする仕事です。
検討のタネを各所にヒアリングする際、誰にどう聞けば最も期待する情報を得られるかを彼らは知っているでしょうか？
検討のタネをふるい分ける際、その組織における実現性や効果や依存関係を彼らは正しく見分けられるでしょうか？
仮に超優秀なコンサルがイイ感じの戦略を作ってくれたとして、丸投げしていた組織は戦略の本意を見失わずに正しく推進し続けられるでしょうか？
外部環境の変化に関する情報収集や、手間がかかるベースライン分析、アウトプット資料作成など一部をお願いすることは有効だと思いますが、全体の推進は必ず内部のセキュリティマネージャや担当者が行うべきだと思います。
さいごに
長くなりましたが、これでも戦略策定の流れをざっと触れただけで、実際にはもっと細かいポイントがあります。
一つ一つのタスクにソフトスキルや（ある意味で強引な）メンタルが必要であり、それらは経験を積みながら、様々な関係者に揉まれながら慣れていくしかないと思います。
その意味で、戦略策定はセキュリティマネージャにとっての総力戦であり、本領発揮すべき面白いお仕事だと思います。
冒頭に書いたように人材が不足している領域らしいので、この仕事をしっかりできるようになると年収1000万円超えは確実でしょう。レッツトライ！と適当なことを書いて締めくくりたいと思います。
これまでの記事一覧はこちら
