目次

• 1．セキュリティ・バイ・デザインとは
• 2．セキュリティ要件定義で陥りがちな落とし穴
• 3．セキュリティ要件定義のポイント
• 4．まとめ

1．セキュリティ・バイ・デザインとは

組織を標的としたサイバー攻撃は大規模化且つ高度化しており、組織は情報システム（以降、システム）に対して確実且つ効率的にセキュリティを確保することが求められています。このような背景から「情報セキュリティを企画・設計段階から確保するための方策」である「セキュリティ・バイ・デザイン（※1）」が近年注目されています。

従来型のシステム開発では、セキュリティ検討が後手後手に回る傾向があります。例えば、リリース直前のテスト工程の段階で、ようやくセキュリティテスト（脆弱性診断、ペネトレーションテスト等）を実施する等の対応がよく見られました。リリース直前の段階でセキュリティ対策漏れ等の致命的な指摘を受けた場合、上流工程への手戻りとなる等、開発スケジュールの遅延や追加コストが生じる恐れがあります。一方で、セキュリティ・バイ・デザインに基づくシステム開発では、企画段階からセキュリティの検討を行うため、システムの全てのライフサイクルにおいて一貫したセキュリティを確保できます。したがって、前述の致命的なセキュリティ対策の漏れ等による上流工程への手戻りを防止し、プロジェクトのQCDの担保につながります。

図1：セキュリティ・バイ・デザインに基づくシステム開発の特徴

セキュリティ・バイ・デザインにおいて最も重要な工程は、「セキュリティ要件定義」です。なぜならば、本工程はセキュリティ・バイ・デザインの起点であるためです。次章では、自組織やシステムの特性を踏まえ、適切なセキュリティ要件を検討するためのポイントを解説します。

2．セキュリティ要件定義で陥りがちな落とし穴

前章では、セキュリティ・バイ・デザインの策定の背景と目的、セキュリティ・バイ・デザインとその起点となる「セキュリティ要件定義」の重要性について述べました。自組織の特性を踏まえて適切なセキュリティ要件を検討することが重要ですが、実際は「他のシステムのセキュリティ要件定義の内容をそのまま流用する」ケースや「業界標準や基準、ガイドラインの内容をそのまま流用する」ケースもあります。このような、場当たり的な対応をしているシステム担当者の方も少なくないのではないでしょうか。

図2：セキュリティ要件定義で陥りがちな落とし穴とそのリスク

「セキュリティ対策や脅威に係る最新動向」や「自組織またシステム特有の事情」は、システム開発の度に考慮すべき観点です。それにもかかわらず、それらを考慮せずに画一的なセキュリティ要件を検討してしまうと、重大なセキュリティインシデントの発生につながり、自組織の信用失墜の恐れがあります。

3．セキュリティ要件定義のポイント

では、どのような取り組みをすれば、確実且つ効率的にセキュリティ要件が検討できるのでしょうか。私たちは、以下の2つのポイントが重要であると考えます。

ポイント（1）トップダウンとボトムアップの両輪での検討

一般的に必要とされているセキュリティ観点と、自組織特有のセキュリティ観点の双方を含めたセキュリティ要件を定義するためには、「国や業界団体、セキュリティ団体等が定めたベースラインからの検討（トップダウンでの検討）」と「自組織やシステムの特性を考慮したリスクベースの検討（ボトムアップでの検討）」の両輪が重要です。

図3：トップダウンとボトムアップの両輪での要件定義

トップダウンでの検討の第一歩は、「自組織が遵守すべきベースラインの選定」です。自組織の業種やビジネスの形態によって、最低限実施しなければならないセキュリティ対策（＝ベースライン）は異なります。ベースラインとなりうるものは、国や業界団体、セキュリティ団体が発行する法令や標準・基準、ガイドラインです。加えて、セキュリティポリシーやスタンダード、プロシージャ等の自組織内あるいは関連組織内の規程類も挙げられます。それらのベースラインの中から、自組織のシステムに適したセキュリティ対策を抽出することで、一般的に必要とされているセキュリティ観点をセキュリティ要件に含めることができます。

実例として、過去の政府系システムの開発プロジェクトにおいては、一般的に考慮すべきである「政府機関等のサイバーセキュリティ対策のための統一基準群」や「当該省庁内の規程類」等に加えて、見落としがちな「当該システムを利用する地方公共団体内の規程類」までをベースラインとして、セキュリティ要件を抽出しました。これにより、システムの提供者側及び利用者側の双方に対して、十分性や妥当性を説明できるセキュリティ要件となりました。

一方で、ベースラインから検討したセキュリティ要件だけでは、自組織やシステム特有の要件にはならず、表面的な対策にしかなりません。自組織のシステムの特性を踏まえた本質的なセキュリティ対策を講じるには、後述のボトムアップでの要件検討も併せて必要になります。

ボトムアップでの検討の第一歩は「リスクアセスメント」です。システムが担う業務や取り扱う情報、システムの利用者、システムの使用環境、システムへのアクセス方法等、システムの特性に応じて、システムに係るリスクは異なります。そこで、システムの企画段階で「リスクアセスメント」を行い、自組織のシステムに係るリスクを把握し、リスクへの対応要否や対応方針を検討することが重要です。
「リスクアセスメント」には「リスク特定」、「リスク分析」、「リスク評価」の3つの工程があります。まず、「リスク特定」では、トップダウンでの検討から導出されたセキュリティ要件を実施する前提のもと、システムにどのような脅威が発生する恐れがあるかを特定します。次に、「リスク分析」では、それらの脅威が顕在化する恐れ（＝脆弱性）がどの程度あるのかや、脅威が顕在化した際にどのような資産が影響を受けるのか等を分析します。最後に、「リスク評価」では、脅威、脆弱性、資産などの影響（＝リスク）を総合的に評価します。自組織として許容できないレベルのリスクに対しては、リスク低減のための追加のセキュリティ対策を検討することで、自組織ならではのセキュリティ観点をセキュリティ要件に含めることができます。
一般的なリスクアセスメントの方法論としては以下があり、自組織の現状のセキュリティレベルや対応期間、コスト等を考慮し、適切な方法を選定することも重要です。

図4：一般的なリスクアセスメントの方法論（※2）

なお、MITRE ATT&CKを用いた詳細リスク分析の活用事例については、別の記事（※3）に詳細があります。

ポイント（2）継続的な見直し

ポイント（1）で述べた、セキュリティ要件検討のインプットとなる「ベースライン」や「リスク」に係る状況は日々変化しています。従って、セキュリティ要件も一度検討したら終わりでなく、継続的に見直していくことが重要です。
具体的には、次のようなシステムのセキュリティに影響を及ぼすイベントが発生した際には、日々の運用の中で対応していくことに加え、必要に応じてリスクアセスメントを再実施することを推奨します。これにより、現状のセキュリティ対策でのリスク低減度合いと追加のセキュリティ対策の要否が明らかになります。

• システムの更改、改修
• ベースラインとして遵守している法令や標準・基準、ガイドライン、自組織や関連組織内の規程類のアップデート
• 新たな脆弱性や脅威事象の発見
• 使用するプロダクトのサポート終了
• システムの使用対象、アクセス環境の変化

追加のコストが発生することからも、セキュリティ要件を継続的に見直すことは敬遠される傾向にあります。一方で、セキュリティ・バイ・デザインに基づくシステム開発では、システムの企画段階から「ベースライン」及び「リスク」を踏まえたセキュリティ要件を検討する仕組みを確立できるため、継続的な見直しや更新のサイクルを効率的に回していくことも難しい話ではありません。

図5：セキュリティ要件の見直しのタイミング（※4）

4．まとめ

本記事では、セキュリティ・バイ・デザインにおいて特に重要なセキュリティ要件定義のポイントを紹介しました。
NTTデータグループ社では、自社でのセキュリティ運用が困難な課題を抱えるお客さま企業を支援するためUnified MDRサービス（※5）を提供しています。セキュリティ・バイ・デザインについても、リスクアセスメントやそれに付随するセキュリティ要件定義等、幅広いコンサルティングを提供可能です。
他にも同サービスでは、日本をはじめ各国に拠点を有するお客さま企業に対するインシデント対応の仕組みの導入から、運用時におけるインシデントの検知・対応・復旧、さらには導入した仕組みの評価・改善までを横断的かつ多言語対応により一気通貫で支援します。
お困りの際はぜひご相談ください。

図6：Unified MDRサービスにて提供可能なコンサルティングメニュー

NTTDATAのセキュリティコンサルティングに関するお問い合わせはこちら

株式会社NTTデータグループ
技術革新統括本部
サイバーセキュリティ担当
E-mail：security-contact@kits.nttdata.co.jp