2025.10.17

セキュリティ・バイ・デザイン概説4

中小企業の経営者や情報システム担当者の皆さん、日々のセキュリティ対策、お疲れ様です。
セキュリティ・バイ・デザイン概説の最終回となる本記事では、セキュリティ実装以降の各工程における要求事項、実施内容、セキュリティ対策の考え方のほか、実施における留意点等について解説します。

●セキュリティ実装工程における要求事項及び実施内容

セキュリティ設計工程に続くのがセキュリティ実装工程であり、セキュリティ設計の内容をシステムに実装する工程です。

この工程における要求事項及び実施内容は次の通りです。

セキュリティ設計に基づいて、セキュリティ機能の実装
セキュリティ設計方針に基づくアプリケーションのセキュアコーディング
セキュリティ設計に基づくプラットフォームのセキュリティ設定の実施（堅牢化、要塞化）

●セキュリティ実装工程におけるセキュリティ対策の考え方

セキュリティ関連のコーディングやセキュリティ設定は、テンプレートや自動化機能を用いることでミスやばらつきを防止することが推奨されます。同様にアプリケーション開発においては、セキュアコーディングをサポートする開発用ツールやフレームワークを活用することが有効です。

また、各種プラットフォーム向けに最適化されたセキュリティベンチマーク（ベストプラクティス）やセキュリティ設定が組み込まれたシステムイメージ、IaCテンプレート等を使用することも推奨されます。

●セキュリティテスト工程における要求事項及び実施内容

セキュリティ実装工程に続くのがセキュリティテスト工程です。

この工程における要求事項及び実施内容は次の通りです。

セキュリティ機能テストの実施（単体テスト、結合テスト、システムテスト等）
対象となるシステムに応じた脆弱性診断の実施（下記例）
　Web アプリケーション脆弱性診断
　プラットフォーム脆弱性診断
　スマートフォンアプリケーション診断
実際の脅威に基づく高度なセキュリティ診断（TLPT等）
機能テストで検出されたバグの是正対応
脆弱性診断、TLPT等で検出された脆弱性に対する是正対応

●セキュリティテスト工程におけるセキュリティ対策の考え方

攻撃対象となる領域（Attack Surface）に対して漏れなく脆弱性診断が実施されるように、システムの環境や特性に応じた適切なスコープで脆弱性診断を実施します。

また、重要度の高いシステムにおいては、表層的な脆弱性診断のみでは不十分であるため、専門家による高度な診断を追加で実施する等、リスクレベルに応じた脆弱性診断を実施することが重要です。

●セキュリティ運用準備工程における要求事項及び実施内容

セキュリティテスト工程に続くのがセキュリティ運用準備工程です。

この工程における要求事項及び実施内容は次の通りです。

セキュリティ運用体制の確立
下表の項目に対応したセキュリティ運用手順の整備

平時の運用	有事の運用
構成管理、変更管理	インシデント対応
セキュリティ製品のアラート、システムログ等を活用したセキュリティ監視、検知
脅威情報の収集、対象システムへの影響分析
CVSS 等に基づく、リスクに応じた脆弱性対応
定期的な脆弱性診断の実施

システム運用において人的ミスが発生する可能性のある箇所の洗い出し、是正
有事を想定したセキュリティ運用訓練の実施

●セキュリティ運用準備工程におけるセキュリティ対策の考え方

事前にインシデント対応手順等を整備していたとしても、実際にインシデントが発生すると、想定通りには対応が進まず、多くの時間を要して被害が拡大するケースが多くあります。
そのため、インシデント発生を想定した訓練を実施し、実運用上の課題を特定し、体制や手順の見直しを行うことで、インシデント対応の実行性を担保する取組みが推奨されます。

また、訓練実施後には関係者に結果をフィードバックすることで、セキュリティ意識の向上やインシデント対応手順の理解を促進する効果も見込まれます。

●セキュリティ運用工程における要求事項及び実施内容

セキュリティ運用準備工程に続くセキュリティ・バイ・デザインの最終工程がセキュリティ運用工程です。

この工程における要求事項及び実施内容は次の通りです。

前工程で整備した運用体制、手順等によるセキュリティ運用の実施
セキュリティ運用を行う要員の教育及び訓練の実施、重要な情報を取り扱う要員のスクリーニング（要員のスキルや行動特性等を考慮）

●セキュリティ運用工程におけるセキュリティ対策の考え方

①SBOM等によるソフトウェアの構成管理

アプリケーションで使用するライブラリやミドルウェア等に深刻な脆弱性が発見された場合に、それが対象システムに含まれるかどうかを迅速に判断できるよう、SBOM等を利用してソフトウェアの構成管理を行います。

②定常的な脅威情報/脆弱性情報の収集及び対応

セキュリティ脅威や脆弱性に対処するため、定常的に脅威情報や脆弱性情報を収集し、被害の発生が想定される脆弱性に対しては、緊急にセキュリティパッチを適用する、セキュリティパッチが適用できないケースは暫定対処策を講じる、システムの機能を制限する等、対応方針を決定します。

③サイバーレジリエンスを高めるセキュリティ運用

インシデントやその兆候の早期検知、速やかなインシデント対応や業務復旧を実践することで、インシデント発生時のシステム被害やサービスへの影響を極小化します。
また、インシデント対応やサービス復旧の実行性を維持するため、定期的にインシデント対応手順やサービス復旧手順を見直し、インシデント対応訓練を実施します。
実際にセキュリティインシデントが発生した場合には、根本的な発生原因を究明して再発防止策を講じるとともに、対応において想定通りに進まなかった部分等について継続的に改善を行うことで、インシデント対応レベルの向上を図ります。
こうした取り組みが組織のサイバーレジリエンス（回復力）を高めることにつながります。

●セキュリティ・バイ・デザイン実施における留意事項

これまで4回にわたり、セキュリティ・バイ・デザイン導入のメリットや基本的な考え方、各工程における要求事項、実施内容、セキュリティ対策の考え方等について解説してきました。
このシリーズのまとめとして、セキュリティ・バイ・デザイン実施における留意事項を挙げておきます。

セキュリティ・バイ・デザインの工程間で整合のとれていないセキュリティ対策が実施された場合、システムのセキュリティ品質を確保することが困難になるため、工程間で一貫した、整合性が確保されたセキュリティ対策を実施するよう留意する必要がある。
セキュリティ・バイ・デザインの実施内容の全てを同時に実現することは困難であるため、自組織の開発プロセスやルール、考慮すべきリスク等を踏まえ、重要かつ実施可能な箇所から運用を開始し、課題の改善と内容の拡充を図りながら成熟度を向上していくことが推奨される。
セキュリティ・バイ・デザインは一過性の取り組みではなく、脅威の動向やシステム環境の変化等を踏まえ、再実施の要否、再実施方法等を検討し、継続的にセキュリティリスクの低減を図っていくことが求められる。

●用語解説

IaC（Infrastructure as Code）

ITインフラの構成をコード化し、構築、変更、削除等を自動化する手法であり、その設定ファイルをIaCテンプレートと呼びます。

TLPT（Threat-Led Penetration Testing）

実際のサイバー攻撃の脅威に関する情報を収集・分析した結果（脅威インテリジェンス）を活用し、それを模した手法を駆使することで企業等のサイバーセキュリティ対策の有効性を総合的に評価する手法です。

CVSS（Common Vulnerability Scoring System）
脆弱性の深刻さを評価する仕組みであり、ベンダに依存しない共通の評価方法を提供しています。

SBOM（Software Bill of Materials）
ソフトウェアを構成する各部品（コンポーネント）の名称、ビルド情報、ライセンス情報、互いの依存関係、どのような構成となっているか等を示すリスト。SBOMにより、ソフトウェアの構成情報を詳細に把握することができるため、脆弱性情報の即時の特定等が可能となります。