多くのセキュリティインシデントは、実装や運用以前の「要求定義フェーズ」での見落としから始まります。セキュリティは後付けできるものではなく、製品・サービスの企画段階から明示的に設計に組み込む必要があります。セキュリティを要求定義に組み込むための基本的な考え方、必要なインプット、分析手法、ドキュメント化の方法について解説します。
■ セキュリティを早期に導入すべき理由
セキュリティ事故の多くは、セキュリティに関する要件漏れと設計不備が原因であり、修正コストは開発後になるほど指数関数的に増大していきます。これは、通常の要件漏れと設計の不備によって引き起こされる遅延や工数増加と同様です。
要求定義フェーズで検討されるべき要件には、機能要件と非機能要件があります。「セキュリティ」は非機能要件に含まれ、明確に要件として定義する必要があります。
| 非機能要件 | 概要 | |
| 性能（Performance） | 定量 | 処理時間 |
| 信頼性（Reliability） | 定量 | エラー率、復旧時間 |
| 可用性（Availability） | 定量 | 稼働時間 |
| セキュリティ（Security） | 定性 | 認証、権限、暗号化、監査ログ |
| ユーザビリティ（Usability） | 定性 | 操作が容易であること |
| 拡張性（Scalability） | 定性 | 負荷分散、拡張可能な構成 |
| 柔軟性（Flexibility） | 定性 | 様々な環境（組織、領域、業界など）に適応 |
| 保守性（Maintainability） | 定性 | 設定変更やログなど保守容易性 |
| 互換性 | 定性 | 異環境での動作可能性（バージョン互換など） |
| 移植性（Portability） | 定性 | 他環境への移植容易性 |
| 環境適合性（Environmental Sustainability） | 定性 | システムの構築や運用における法令や条約、ハードウェアの制限事項を考慮した目標設定など |
また、システム/ソフトウェア製品の品質特性（ISO25010）にも、「セキュリティ」が含まれ、品質面での対処が求められています。
そして、NIST SP 800-218（SSDF）のPOカテゴリは、組織全体で安全なソフトウェア開発を行う準備段階に該当し、以下の点が要求定義フェーズと密接に関連します。
PO.1：ロールと責任を定義する → セキュリティ要求の策定責任者と承認者の明確化
PO.2：セキュリティ要件を定義し、開発計画に反映する → セキュリティ非機能要件の明文化
PO.3：使用するツールや標準を定める → 要求書に準拠規格や使用ガイドラインを明記
■ セキュリティ対策の全体像
脅威は、守るべき対象システム/ソフトウェアの外部で発生します。
攻撃者はネットワークを通じてシステム内部に侵入しようとします。対象システム/ソフトウェアを脅威から防御するため、以下のような防御システムが配置されます。
FW（Firewall）：許可されていない通信をブロック
IPS（侵入防止システム）/IDS（侵入検知システム）：攻撃を検知し遮断する役割
防御システムを通過した脅威は、対象システム/ソフトウェアに到達し、提供されている機能を使って侵入しようとします。機能を安全に動作させるために、以下のようなセキュリティ機能を対象システムの内部に組み込みます。これらは開発段階で設計に組み込む必要があります。
・認証・認可
・アクセス制御
・ログ監視・改ざん検知
・データ暗号化
■ 「セキュリティ」要件定義としての「セキュリティリスク分析」
要件定義フェーズにおいて、「セキュリティリスク分析」を実施します。その結果は、非機能要件としての「セキュリティ」要件そのものとして捉えることができます。
セキュリティリスクとは、「特定の脅威が脆弱性を突いたときに、情報資産に及ぼす影響とその可能性」であり、対応すべき優先度と実現手段を明示する必要があります。
以下に「セキュリティリスク分析」の手順を示します。
- 対象の特定（アセット定義）
以下のような何を守るべき資産 を特定します。
①ソフトウェア資産（ソースコード、コンテナイメージ）
②ハードウェア資産（IoT機器、コントローラ）
③データ資産（個人情報、機密文書） - 優先順位をつける。
資産ごとに「機密性・完全性・可用性」（CIA）の重要度を付与します。重要度の高い資産を対象とします。 - 脅威の特定（Threat Modeling）
資産を狙う脅威（STRIDE）を明確にします。
・Spoofing（なりすまし）
認証の仕組みは十分か？MFA導入済みか？
・Tampering（改ざん）
通信・保存データの整合性検証はあるか？
・Repudiation（否認）
操作ログ・証跡は残っているか？
・Information Disclosure（情報漏洩）
暗号化されているか？必要最小限の情報のみか？
・Denial of Service（サービス妨害）
不要な通信を防ぐ対策はあるか？レート制限は？
・Elevation of Privilege（権限昇格）
権限制御は厳密か？最小権限の原則が守られているか？
そして、脅威シナリオを文章で表現します。脅威は、「誰が、どの経路で、どの弱点を狙うか」を含めて整理します。
例：「外部攻撃者がフィッシングメールを送り、認証情報を奪取する」
4. 脆弱性の特定（Vulnerability Identification）
脅威だけではなく「攻撃が成立する条件（脆弱性＝弱点）」が必要です。
既知の脆弱性（CVE情報など）を参考に、資産にどんな弱点があるかを明確にします。
5.リスクの分析（Risk Estimation）
資産の重要度、脅威の有無、脆弱性の有無から影響度（Impact）を数値化します。
合わせて発生頻度（Likelihood）を予測し、数値化します。
数値化は、5段階評価や CVSS v3スコアを参考にします。
Impact × Likelihood＝リスク値とします。
リスク値の基準を決め、対策の必要性を判断します。
6.リスク対応策の決定（Risk Treatment）
リスク対応の４つの原則を以下に示します。
①軽減（Mitigate）：設計変更、制御策追加
②転嫁（Transfer）：保険契約、サードパーティ委託
③受容（Accept）：リスクを残留リスクとして許容
④回避（Avoid）：機能廃止、要件変更
対策の必要がある脅威に対して、これらの原則のいずれかを選択します。
7.リスク対応策の要求仕様化（Requirement Specification）
「軽減」するための対応策が実現すべき要件です。
以下のような対応策を「セキュリティ要求」として設計書に組み込みます。
・RBACの導入
・多要素認証（MFA）
・TLS 1.3通信
・HSM による鍵保護
8.検証とレビュー（Verification & Validation）
開発プロセスにおいて、静的解析（SAST）、動的解析（DAST）、脆弱性スキャン、ペネトレーションテストを実施し、セキュリティ対策が有効であることを検証します。
■ まとめ
セキュリティ要求には、単なる脅威対応だけでなく、以下のような業界ごとの法的・標準的な要件も含まれます。これらは実質的に「遵守すべきセキュリティ要件」として扱われ、遵守していること担保するための監査が行われます。
・PCI DSS：クレジットカードセキュリティ規格
・ISO/SAE 21434：TARA（自動車業界における脅威分析とリスク評価手法）による継続的なリスク管理
これらの規格はプロジェクトや製品の特性によって選択・準拠すべきものであり、対応していない場合には事業継続や社会的信用にも関わります。
要求定義フェーズでセキュリティを設計に取り込むことは、後戻りコストの最小化、規格対応の効率化、将来の脅威への備えとして極めて重要です。
