ざっくりセキュリティ・バイ・デザイン

原典

この↑資料自体、もともと簡潔にまとまっていてすごくわかりやすいです。
ただ、開発メンバー全員が全てに目を通すのものコストがかかるので、
かいつまんで大枠どんなことが書かれているのかを以下にまとめました。

---

セキュリティ・バイ・デザイン is 何？

「情報セキュリティを企画、設計段階から組み込むための⽅策」
開発プロセスの早い段階からセキュリティを考慮すること

メリット is 何？

後付けでセキュリティ機能を追加したり、出荷直前になってセキュリティツールを実⾏していては、⼿戻りが多発したり、結果的に開発コストが多くかかってしまう可能性がある。
開発の早い段階でセキュリティ対策を⾏うことで、⼿戻りが少なく、コスト削減に繋がり、保守性の良いシステム・ソフトウェアの作成につながる。

何から始めれば良いか

OWASP SAMMの 「設計」 をやれば良い

• OWASP SAMM 2.0　とは
  • ソフトウェアセキュリティ対策のための戦略の策定・実施を⽀援するフレームワークである。

OWASP SAMM 「設計」

以下の3つからなる

• 1.脅威分析(Threat Assessment)
  • 何から守るべきか明らかにする
  • リスクの低減ができる
• 2.セキュリティ要件(Security Requirements)
  • ソフトウェア⾃⾝のセキュアな動作を定義する。
  • 要件の種類
    • システムの機能に関する要件
    • 可⽤性
    • 保守性
    • 性能
    • etc..
• 3.セキュリティアーキテクチャ(Security Architecture)
  • プラットフォームの提供元が推奨しているアーキテクチャをカスタマイズしつつ利⽤

1.脅威分析

• SAMM には実施⼿順が具体的に明記されていない。
• ↑だから脅威分析をやるためのフレームワークがあるよ
  • OWASP Threat Modeling / Threat Modeling Process
  • STRIDE
  • Trike
  • 攻撃ツリー
  • EBIOS ★今回はこれを取り上げるよ
  • 制御システムのセキュリティリスク分析ガイド（IPA）

EBIOS

5つのWS(WorkShop)をこなすだけで SAMM の「設計」をほぼカバーできてしまう

Workshop1：スコープとセキュリティベースライン (Scope and security baseline)

• ビジネススコープの定義
  • このソフトウェアが何を⽬的にして利⽤されるのか、ツールを使⽤する業務⼿順、情報の保管場所などを明確にする
• 事業被害の洗い出しとその深刻度の設定

成果物例：

Workshop2：脅威の特定 (Risk Origins)

1. 自組織にとって脅威となるような攻撃者を選定する
   • ハクティビスト【外部】
   • サイバー犯罪組織【外部】
   • 国家⽀援型組織【外部】
   • 産業スパイ【外部】
   • 個⼈犯罪者【外部】
   • 内部犯【内部】
   • サプライチェーン事業者（仕⼊れ先、下請け業者など）【内部、外部】
   • etc...
2. 上記に以下の指標を追加し、攻撃発生可能性をまとめる
   • 攻撃者が狙う攻撃⽬標 ：攻撃者が狙う資産や情報。攻撃者毎に複数存在しうる
   • 攻撃者のモチベーション：活動の活発さを４段階で評価
   • 攻撃者のリソース ：使える資⾦や⼈数、時間、技術⼒を４段階で評価

成果物例：

Workshop3：戦略的シナリオ (Strategic Scenarios)

ステークホルダー

サイバー攻撃に対する⾃組織の防御が⼗全であっても、攻撃を受けてしまうケースが存在する。機器ベンダーや顧客といった、ビジネスのサプライチェーン上におけるステークホルダーが攻撃されることにより、⾃組織が間接的な攻撃を受けてしまう場合がある。

• ステークホルダーの脅威度を算出する
  

成果物例：

• 脅威度に合わせて、脅威度を3段階で割り振る

ステークホルダーのリスク低減

• 今までの成果物を利用して、事業被害と攻撃⽬標が噛み合っているものを抽出する
• 攻撃シナリオを洗い出す
• セキュリティ対策をまとめる

成果物例：

Workshop4：攻撃⼿順シナリオ (Operating Scenarios)

• 攻撃者が⽬的を達成するまでの⼿順をフローチャートとして図に書き起こす。
• 攻撃の⼿順を４段階に分けて記述し、それに対して実現可能性と難易度の２観点で脅威度のスコア付けを⾏う。

成果物例：

Workshop5：リスクへの対策 (Risk Treatment)

• リスクの評価を行う：Workshop1の成果物(深刻度)とWorkshop4の成果物(発生可能性)から計算をする
• シナリオを 深刻度 と 発生可能性 のマトリクスを配置し、自組織にとってリスクの高いシナリオを洗い出す
• リスクの高いシナリオの発生可能性を下げるように対策を立てる
  • 対策は進捗管理をすると良い

リスク = 事業被害の深刻度 × シナリオの発⽣可能性

深刻度 x 発生可能性 のマトリクス

進捗管理

2.セキュリティ要件

セキュリティ要件の定義

• 手法は様々なやり方があるので、適切なものを選ぶべし

例

• 概要図を作成する

• 機能要件の各項⽬に対して「C:情報流出しそうか？」「I:改竄されそうか？」「A:機能停⽌しないか？」という点からセキュリティ要件を定める手法

• データセキュリティ、アクセス制御、トランザクションの完全性、ビジネス機能の重大度、職務分掌、稼働時間に関する期待を⽰し、それに対するセキュリティ要件を考える手法

ガイドラインに準拠する

• ここではSAMM における SR2 セキュリティ要件定義の実施⽅法を取り扱う。 SR2 では機能要件以外の要素からセキュリティ要件を定義する
  • 業界毎のガイドライン
  • 法令や法的ガイドライン
  • etc...
• ガイドラインの採用は以下の条件を考える
  • 実装が可能であり、コスト効率の良いもの
  • 特定の技術やホスティング環境に依存しないもの
• ガイドラインの採用はバランスよく

• OWASP ASVS がおすすめ

対応するセキュリティ要件の決定

• 全て対応するのは難しい
• 優先度を決めて見える化する

決定して終わりじゃない。随時ブラッシュアップする

• 設計⼯程でセキュリティ要件をブラッシュアップする
• 開発プロセス全体でセキュリティ要件の実装状況をチェックする仕組みを作る

3.セキュリティアーキテクチャ

セキュリティアーキテクチャ is 何?

IT 製品において、脅威に対抗するセキュリティ機能そのものを安全に実装するための、設計⽅針・プログラムの構造・しくみのこと

何をするの?

1. 設計作業に⼊る前にセキュリティ原則を記述したリストを作成する
   • リストに記述する原則は OWASP SAMM、ASVS や情報セキュリティの 3 要素 (機
     密性、完全性、可⽤性)、業界毎のガイドラインを参照して定義する
2. ツールや技術の選定
   • 共通機能はSAMMではサードパーティライブラリを使うことが推奨されている
     • ただし、出自に注意する
     • Black Duck などを用いれば、サードパーティ製のセキュリティや品質などの管理が行える

その他

シフトレフト

シフトレフト is 何？

安全なものを開発するための現状把握や振り返り、対策へのフィードバック、改善を⾏うプロセスのこと

メリット is 何？

これまで後⼯程で⾏っていたセキュリティに関する問題について発⽣原因まで遡り、その発⽣原因に対して根本的な解決を⾏うことで、従来よりも早い段階にセキュリティ対策を組み込むことができるというものである。

勘違いしないでね

「動的な脆弱性スキャンを何回もかけること」⾃体をシフトレフトであると⽿にするが、これは⼿段であってシフトレフトの本質とは少し異なる。

例

ユーザ企業側の受け⼊れテスト時に、重⼤な脆弱性がたくさん出て、⼤規模なソースコードの変更や、OSS のバージョンアップが必要になった。

• ↑こうした問題が発生した場合に、 根本解決 として、教育の実施、セキュリティスキャンの自動実施をする