セキュリティ・バイ・デザインとは？成功の道筋を語る～後編：実践の概要を解説
事業のDX成功にはセキュリティ・バイ・デザインを組織的に実装していくことが必須と言われていますが、多くの組織で乖離があるのが現状です。前編では、DXの背景や本質から必要な組織体制をひもときました。続く後編では、具体的な実践方法の概要をトレンドマイクロ日本地域CISOが手法や技法を交えて示します。
セキュリティ・バイ・デザイン実践はどこから始めるべきか
セキュリティ・バイ・デザインとは、その言葉が端的に示す通り、セキュリティを後付けではなく、製品やサービスの企画・設計段階から確保するアプローチを意味します。つまり、開発工程に入ってからのそれではなく、IT及び情報資産を活用したビジネス・スキームを検討する段階からスタートしなければならないということです。
セキュリティ施策は二階層構造で考えるべきという話を前編で述べました。一階部分（共用スペース）は「ベースライン」としての基本的施策（例えば、セキュリティポリシー、ルール、セキュリティソフトの利用などに対する対策）であり、その主たる担い手はセキュリティ専門チームです。そして二階部分に相当するのが、守るべき資産・システムおよびそこに影響を与え得るリスクの大きさ（≒影響の大きさ）に応じて適切な対応策を投資と捉えて行うべき部分であり、その主たる担い手はビジネス・スキームのオーナーです。セキュリティ・リスクに対する正しい判断は「対象とするシステム」が生み出す価値の大きさに比例して行われるべきで、より大きな価値を生むものを守るためには、それに見合うリスク対策コストが必要です。そして、その生み出す価値を知り得るのはビジネス・スキームを企画しているチームに他ならないのです。
つまり、セキュリティ要求を行うべきなのはビジネス・チームということです。その要求に応じ、セキュリティ専門チーム及びシステムの開発チームが要求に応じた具体的な施策を実施するという役割分担となるべきでしょう。企画段階で、生み出す価値の大きさに対して発生し得るセキュリティ・リスクの大きさと影響について把握し、どのような追加措置が必要かを双方で摺り合わせを行うことからセキュリティ・バイ・デザインの工程がスタートするべきです。
各フェーズで行うべき項目について、以下に概要を示します。
企画フェーズ：
このフェーズではおおまかなビジネス・フローを元に、どのような資産が使われるのか、それらの資産が侵害された際の影響の大きさを検討した上で、概要レベルでシステム・フローやデータ・フローを描いて必要となるセキュリティ対策を洗い出していきます。
例えば、エンドユーザがIDとパスワードでログインしてサービスを利用し、決済情報など機微性の高い情報を含んだユーザ情報を登録する必要がある場合、「なりすまし防止」などがセキュリティ対策として必要になると考えられます。CIAトライアド（Confidentiality：機密性、Integrity：完全性、Availability：可用性）に４要素（真正性、責任追及性、否認防止、信頼性）を加えたセキュリティ７要素の観点、及び脅威モデリングで活用されるSTRIDE（なりすまし、改竄、否認、情報漏洩、業務妨害、権限昇格）といったフレームワークを活用すると、どのような管理策が必要となるかマッピングすることができます。
なお、特定の技法としては予備的ハザード分析（PHA : Preliminary hazard analysis）※1などの手法を使うと良いでしょう。影響度を分析するための分析メソッドについても、精緻なものである必要はこの段階ではなく、例えばプロセスフローを元にした構造的What-If分析技法（SWIFT: Structured What If Technique）※２などを用いて進めると良いでしょう。
具体的なセキュリティ施策の実装などについては第二線（セキュリティ専門チーム）から提案してもらえばよいので、企画側（ビジネス・チーム）はハイレベルなセキュリティ要件をこの段階で定義できれば十分と言えます。
※１：予備的ハザード分析（予備危険源分析）：過去に発生した事や経験から、発生し得るリスクをディスカッションしてリスト化する方法
※２：SWIFT: リスク特定のため、仮定現象と結果をブレインストーミングで導き出す方法
図：セキュリティの７要素
セキュリティ施策の検討にあたっては、これらの要素を意識する
設計フェーズ：
このフェーズでは、企画フェーズで定義したハイレベルなセキュリティ要求を受けて、それを具体的にどのような手法で実現するかを検討していきます。
この段階では、詳細なリスク・アセスメントを実施していきます。アセスメント対象資産（情報資産・システム）に対して、リスク事象（例えば、情報漏洩、業務妨害、金銭詐取など）がどのような経路で発生するかを検討し、企画段階でのリスクの特定漏れを防ぎつつ、要求されたセキュリティ要件を満たす最適なソリューションを見出していきます。具体的には、以下のようなステップで検討していきます。
１）リスク事象の発生経路を特定する（リスクシナリオを作成する）
発生経路を特定するための分析フレームワークとしては、故障の木分析（FTA : Fault Tree Analysis）などを利用します。ただし、例えば、侵入シナリオのような攻撃手法を参照しなければならない領域については、セキュリティ専門チームの支援が必須であり、専門チームはMITRE ATT&CKのようなフレームワークを参考にして、予めパターンを用意し、汎用化（テンプレート化）することを推奨します。この時、特定の脆弱性とその攻撃ツールを使った侵入手口のように、深いレベルで選択肢を作ってしまうと、以降のアセスメントの工数が多大となってしまうため、中分類程度にまとめるよう留意してください。
なお、ツリー図は、横に長くなってしまって非常に見づらいチャートとなりがちです。１つのチャートで全てを示すのではなく、幾つかのブロックに分けて分析することを推奨します。以下に示す例は、「情報漏洩」が発生する経路について、FTA（故障の木分析）を用いて、まずハイレベルに分析した上で、「外部犯罪者の侵入」というブロックを掘り下げ分析した事例です。
２）リスクシナリオに対するリスク値を計算する
特定したリスク事象の発生経路は「リスクシナリオ」として登録し、その時点でのシナリオに対する低減策（例えば社員のエンドポイント端末でのアンチウイルスやEDR導入など、既に存在しているものを含む）を当てていきます。それを踏まえて、ETA（Event Tree Analysis : 影響の木分析）などのフレームワークを活用して、そのシナリオの進展の確度を求めていきます。
図：ETA(Event Tree Analysis)の例
「フィッシングメールによりマルウェア感染する」シナリオの進展からリスク値（発生確率）を求めている
例示したETAではフィッシングメールによりマルウェア感染させられるシナリオの進展をセキュリティ対策と合わせて感染確率を求めている例となります。この例では、１通のメールに対する感染確率を0.0084%と算出していますが、例えば毎日100通のフィッシングメールが着弾し、それが毎日続くとなると、感染する確率が高くなり、既存対策だけでは感染をゼロにすることは不可能であることが推定されます。
求めれらたリスク値について、ビジネス・チームや経営層などの意思決定者に理解されにくい場合も多いため、セキュリティ専門チームは、その解釈を加えてわかりやすく説明する必要があることを、留意してください。
３）リスク値に対する対策の合理性を確認する
リスク値に対し、要求されたセキュリティ管理策を加えることで、リスク値がビジネス・チームとセキュリティ専門チームの合議で決めたしきい値を下回ることが可能かどうかを確認していくと同時に、その対策案を選択した場合に必要となるコストやリソースも算出していきます。ビジネス・チームは、この積算結果をプロジェクトプラン（リソース、予算、スケジュール）に組み込んでいき、プロジェクトとして最適化されているか、あるいは必要なコストなどがプロジェクトの成果と比して合理的かを確認し、仮に合理的ではない（例えば、ビジネス収入が少ないと見込まれるシステムに巨額のセキュリティ対策を投入することなど）場合は、セキュリティ専門チームに戻して合理性の範囲内で、許容できるリスク値に収めるための方策を検討しましょう。
また、侵害が実際に発生した場合、事態がどのように推移するかを、さきほどご紹介した影響の木分析（ETA : Event Tree Analysis）などの技法を使って分析しておき、対応シナリオをこのフェーズで策定しておくと良いでしょう。
開発フェーズ：
このフェーズでは、要求されたセキュリティ機能を実装していきます。また、セキュア・コーディングを実践し、新たに未知のリスクを作り出さないように開発・検証を行っていきましょう。可能であればペネトレーションテストを行うなど、リリース前段階で脆弱性のないことを確認します。また、どのようなモジュールが使われているかを目録化（SBOM : Software Bill of Materials）できるようにしておくと良いでしょう。
QA（Quality Assurance）工程では、機能テストとは別に（設計フェーズで作成したリスクシナリオを元に）攻撃シナリオに対して実際にセキュリティが確保できるかを確認するためのテストケースを用意し、実施すると良いでしょう。
全ての機能が実装されその効果を検証した後に、リスクシナリオ一つ一つに対してリスク値の再算出を行い、しきい値（許容範囲）以内にリスク値が収まっていることを確認します。また、この時に、リスク値が変化する条件（例えば、なりすまし防止のために多要素認証を導入したが、この認証を突破するような攻撃手法が発見された場合はリスク値が高くなる可能性があるなど）についても注釈として記載を残しておくと、運用フェーズにおいてその条件をモニタリングし、適切な対応を行うトリガーとして有用となります。
運用フェーズ：
このフェーズでのポイントは、定期的及びトリガー条件（きっかけとなる条件）に応じた再アセスメントを行うことにあります。リスクの大きさは常に一定ではなく、システムの改変、プロセスの変更、メンバーやチームの交替、攻撃手法の進化など様々な理由で大きく変動するからです。設計・開発フェーズの段階で運用フェーズにおける再アセスメントのプロセスをしっかりと定義しておき、運用フェーズに入ってそのプロセスを実践することが大切なルーチンワークとなります。
再アセスメントは、登録されたリスクシナリオベースで行います。１）想定していないシナリオの有無、２）無効化されたシナリオの有無などを確認してリスクシナリオを更新した上で、リスク値の見直しを実施します。これにより、「シナリオの想定漏れ」による予期せぬインシデントの発生を抑止することが可能です。
また、経年変化により想定通りに動けなくなってしまうことを防止するため、インシデント発生時の対応について定期的な訓練を行いましょう。内部または外部からインシデントの指摘を受けた場合の対応プロセスをきちんと整備し、運営していくことが重要です。
なお、インシデントには当該システムの脆弱性への対応も含まれます。脆弱性対応については、一般的にPSIRT（Product Security Incident Response Team）※3と呼ばれる体制とプロセスの構築を推奨します。
※3：PSIRT（Product Security Incident Response Team）：自社が提供する製品やサービスへのセキュリティインシデントへの対応や、関連するユーザサポートなどを行うチームや体制のこと
終わりに～DX成功の鍵はビジネス・オーナーのコミットメントにある
以上述べてきた通り、真の意味でDX推進を成功させるためには、セキュリティ・バイ・デザインをしっかりとDX推進に関わる全ての組織・メンバーに浸透させることが極めて重要であり、そのためには、ビジネス・オーナーによる強いリーダーシップの発揮が肝要となります。NISC（内閣サイバーセキュリティ・センター）が定めるサイバーセキュリティ戦略の中でも度々指摘されていた「戦略マネジメント層」と呼ばれる役割を担うリーダーたちが、真に、セキュリティの重要性がビジネスの成功に直結することを理解し、コミットメントを示すことが成功の大きな鍵となります。
組織でセキュリティ・バイ・デザインの取り組みを進めるにあたっては、本稿の内容に加え、「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」、IPAから発行されている「セキュリティ・バイ・デザイン導入指南書」なども参考にされることをお奨めします。また、トレンドマイクロでは、ビジネス・チーム側で必要となるセキュリティ知識を習得するためのトレーニングコースをご用意し、組織におけるセキュリティ・バイ・デザインの取り組みを支援しています。
また本稿では、リスク・アセスメントの実践においては概要を述べるにとどまっておりますが、詳細についてはこちらのコースでご紹介しております。
応用コース：プラス・セキュリティトレーニング応用―資産別リスク・アセスメント実践編
これらの情報が読者の方々のセキュイリティ・バイ・デザイン、ひいてはDXの真の成功のご支援になれば幸いです。
清水 智
トレンドマイクロ株式会社
日本地域CISO
2002年トレンドマイクロ入社、製品開発部門、セキュリティのコアテクノロジー部門での品質マネジメントや事業継続マネジメントの責任者を歴任。2012年より統合型リスクマネジメントの重要性を認識し社内に専門チームを発足。大規模スポーツイベントのセキュリティ、サイバーセキュリティ、リスクマネジメント、人材育成などのマネジメント領域における専門家。2020年10月よりトレンドマイクロ・日本本社のCISOを務める。
政府へのセキュリティ政策提言、INTERPOL向けサイバー犯罪捜査官育成などに携わる。一般社団法人サイバー犯罪捜査・調査ナレッジフォーラム代表理事、一般財団法人日本サイバー犯罪対策センター（JC3）理事、国際刑事警察機構グローバルサイバー犯罪専門家委員会委員なども務める。
Security GO新着記事
ソブリンクラウドとは？プライベートクラウドやガバメントクラウドとの違いを解説
（2024年11月5日）
VPN機器の脆弱性はなぜ管理しづらいのか～ネットワークエンジニアの立場から探る
（2024年11月1日）
