セキュリティ・バイ・デザイン：IEC 62443と脅威モデリング

CEマーキング

近年、サイバー攻撃は高度化と巧妙化を増しており、標的型攻撃やサプライチェーン攻撃のリスクは企業規模を問わず無視できないものとなっています。さらに、欧州サイバーレジリエンス法（Cyber Resilience Act：CRA）の施行により、製品開発におけるセキュリティ・バイ・デザイン（Security by Design）は、もはや「あれば良い」オプションではなく、法的にも実装が義務付けられた要件になりました。CRAは、製品の設計段階からリスクアセスメントや技術文書の整備を求めており、開発者や設計者にとって新たな挑戦となっています。

本記事では、会社で働く技術者が、セキュリティ・バイ・デザインを単なるチェックリストではなく、製品の信頼性・品質向上のための実践的なエンジニアリングプロセスとして理解できるように、具体的手法、応用事例、国際規格の活用法を詳しく解説します。

なぜIEC 62443シリーズを参照すべきか？

IEC 62443は、もともと産業用制御システム（Industrial Control Systems：ICS）向けに策定された国際標準規格です。しかし、その体系的なアプローチは、IoTデバイス、組み込みシステム、クラウドサービスなど幅広いデジタル製品開発に応用可能です。

この規格を参照することで、セキュリティ対策が属人的なノウハウに頼るのではなく、グローバルで認められたベストプラクティスに基づく開発プロセスを構築できます。結果として、製品の信頼性や市場での競争力も向上します。

IEC 62443シリーズの主要ポイント

  1. IEC 62443-4-1（セキュア製品開発ライフサイクル）
    • 要件定義、設計、実装、テスト、運用保守の各フェーズで必要なセキュリティ活動を明示。
    • 設計フェーズでは脅威モデリングの実施を推奨。
    • 実装フェーズでは静的コード解析（SCA）による脆弱性検出。
    • テストフェーズではファジングテストやペネトレーションテストを通じた脆弱性発見。
    • この体系に沿えば、どの段階でどの活動を行うべきかが明確になり、開発者はロードマップに従ったセキュリティ実装が可能。
  2. IEC 62443-4-2（コンポーネントの技術的セキュリティ要件）
    • OS、ミドルウェア、アプリケーションなど、製品の各コンポーネントが満たすべき技術的要件をセキュリティレベル（SL）で規定。
    • SLは1～4まであり、SL1は基本的対策、SL4は高度なサイバー攻撃への耐性を要求。
    • 製品の重要度や用途に応じて適切なセキュリティ目標を設定可能。
  3. IEC 62443-3-2（リスクアセスメントとシステム設計）
    • システム全体のリスクを分析し、必要なセキュリティ対策を導出。
    • CRAが義務付けるリスクアセスメント文書作成の基盤となる。
    • リスク分析の結果をもとに、設計変更や追加対策を検討できる。

脅威モデリングの実践：STRIDEモデル

設計フェーズで潜在的な脆弱性を洗い出す上で不可欠なのが脅威モデリングです。Microsoftが提唱したSTRIDEモデルは、網羅的に脅威を分類し、具体的な対策を導出する強力なツールです。

STRIDEの6つの脅威カテゴリーと具体的対策

  1. Spoofing（なりすまし）
    • 技術的対策：OAuth 2.0やOpenID Connectなどの認証プロトコルの厳格実装、多要素認証（MFA）の導入。
    • 具体例：ログイン時のトークン偽装、APIキーの窃取。
  2. Tampering（改ざん）
    • 技術的対策：TLS/SSLによる通信暗号化、ハッシュ関数やデジタル署名によるデータ完全性保証、署名付きファームウェア更新。
    • 具体例：中間者攻撃（MITM）、不正なファームウェア書き換え。
  3. Repudiation（否認）
    • 技術的対策：改ざん防止付き監査ログの記録。
    • 具体例：ユーザーが操作履歴を否認するケースへの対策。
  4. Information Disclosure（情報漏えい）
    • 技術的対策：データ保存時（Data at Rest）と転送時（Data in Transit）の暗号化、最小特権原則に基づくアクセス制御。
    • 具体例：データベースからの個人情報流出、通信内容の盗聴。
  5. Denial of Service（サービス妨害）
    • 技術的対策：リソース使用制限（レートリミット）、異常トラフィック検知システム（WAF）導入。
    • 具体例：DDoS攻撃によるWebサービス停止、CPU/メモリリソース枯渇。
  6. Elevation of Privilege（権限昇格）
    • 技術的対策：権限分離、サンドボックス活用、セキュアなプロセス間通信（IPC）の実装。
    • 具体例：低権限プロセスがカーネル脆弱性を利用してroot権限を取得。

このモデルに基づき、開発者は脅威を体系的に文書化し、脅威モデル文書として記録することが可能です。

脆弱性を作り込まない開発テクニック

静的コード解析（SCA）と動的コード解析（DAST）の活用

  • SCAツール（SonarQube、Checkmarxなど）をCI/CDに組み込み、コミットごとに脆弱性を検出。
  • DASTツール（OWASP ZAP、Acunetixなど）でアプリケーション実行時の脆弱性を確認。SCAでは検出困難なランタイム特有の脆弱性を発見可能。

ソフトウェア部品表（SBOM）の作成と管理

  • SBOMは製品が使用する全ソフトウェアコンポーネントと依存関係をリスト化。
  • OSSの脆弱性情報データベース（NVD、GitHub Security Advisories）と連携し、既知脆弱性（CVE）の迅速特定と対応を可能に。
  • CRAではSBOM作成が実質義務化され、サプライチェーンリスク管理に不可欠。

インターフェース最小化とセキュアAPI設計

  • 外部に公開する通信インターフェースやAPIを最小限に。
  • 入力値のバリデーション、セッション管理、エラー情報の非公開などで攻撃の入口を制御。

検証・バリデーションの実践

ファジングテスト（Fuzzing Test）

  • 無効データや異常データを大量に送信し、クラッシュや予期せぬ挙動を確認。
  • 開発段階で未知の脆弱性を発見するために有効。

ペネトレーションテスト（Penetration Testing）

  • 専門のセキュリティエンジニアが攻撃者視点で侵入を試みる。
  • 複数脆弱性を組み合わせた攻撃や論理的欠陥も発見可能。

これらはCRAが要求する「適切な適合性評価」の証拠となり、後の監査や製品申請に不可欠です。

文書化の重要性

CRA対応では、セキュリティ対策を単に実施するだけでなく、技術文書として証拠化することが極めて重要です。

  • 技術文書（Technical Documentation）
    リスクアセスメント、セキュリティ要件仕様書、設計書、テストレポートなどを体系的に整理。
  • SBOMと脆弱性情報管理
    SBOM管理と既知脆弱性情報の追跡・更新が、CRA準拠の鍵となります。

コメント