こんにちは、翡翠です。
今回もセキュリティに関する技術的な内容ではないのですが、「こんな考え方があるんだ！」という新しい発見をしたので、備忘録としてまとめていきたいと思います。
現状「あとからセキュリティ対策追加」
「今のシステム、セキュリティ対策を追加しないと」
「開発工程も終盤に差し掛かっているのに、設計上の脆弱性がみつかってしまった。作業どこまで巻き戻す？企画か、アーキテクチャ設計か？」
こんな感じで、今までのシステム開発ではテスト段階、リリース前のセキュリティ診断、運用開始後など、後付でセキュリティを確保する流れが多くありました。
これだと納期の遅延・予算オーバが発生したり、最悪の場合はリスクを抱えたままリリースするか、手戻りのコストに耐えられずリリースを諦めるという事態が多発していたようです。
IPAの「セキュリティ・バイ・デザイン導入指南書」ではセキュリティ対策は、実施する工程が下流に行くほど是正コストが爆発的に増加するとされています。
出典：独立行政法人情報処理推進機構（IPA） セキュリティ・バイ・デザイン導入指南書 図 2 セキュリティ対策の実施タイミングと対策コスト
リリース後に対応するより、上流の設計段階で先手を打ってセキュリティを組み込む方が圧倒的にコストを抑えられることがわかります。
DX・IoT普及とサプライチェーン化により、攻撃対象が増加
デジタルトランスフォーメーション（DX）の推進、アジャイル開発やDevOpsの導入、クラウド利用やIoT機器の急速な普及に伴い、サイバー攻撃の対象となる領域（アタックサーフェス）が広大かつ複雑になりました。
特にIoT機器や制御システムなどは、一度出荷・運用開始されると物理的・運用的に後からパッチを適用することが難しいです。
また、オープンソースソフトウェア（OSS）やサードパーティ製ライブラリの依存関係を利用したソフトウェアサプライチェーン攻撃が増加したことで、後付けの対症療法では対応しきれなくなりました。
責任はだれに
セキュリティ設定や脆弱性対策は誰が責任を持って実施するのかが、曖昧だったり、専門知識がない一般のユーザや企業（利用する側）に委ねられている現状もあります。
CISA「Security by Design」
製品の企画・設計段階から安全性を組み込み、セキュリティの負担を個人の利用者に負わせるのではなく、十分なリソースを持つソフトウェア製造業者（アップストリーム）側へ移転させる「責任の構造的シフト」を目指す国際的な枠組みとして「Security by Design（セキュア・バイ・デザイン）」が提唱されました。
Security by Designの3大基本原則
① 責任の所有（Take Ownership of Customer Security Outcomes）
② 透明性と説明責任（Embrace Radical Transparency and Accountability）
③ リーダーシップ（Lead from the Top）
順番にみていきます。
① 責任の所有
製品の安全確保は製造業者の責務であり、顧客に安全運用の負担やリスクを転嫁してはならないという原則です。
- 基本機能としての保護: シングルサインオン（SSO）や二段階認証・多要素認証（MFA）、セキュリティログの出力といった機能を有料オプションとせず、製品の基本機能として組み込む。
- 脆弱性クラスの排除: 個別のバグを後追いでパッチ修正するだけでなく、メモリ安全なプログラミング言語の採用やアプリケーションの堅牢化（Hardening）により、脆弱性の種類そのものを根絶する。
- デフォルトでの安全（Secure by Default）: 特別な設定調整を行わなくても、出荷状態（Out-of-the-box）で最も安全な状態で動作するように設計する。
② 透明性と説明責任
開発ライフサイクル（SDLC）や脆弱性対応のプロセスを顧客や業界へ公開し、信頼関係を構築・維持する原則です。
- セキュリティデータ・統計の公表: MFA利用率、レガシープロトコルの利用状況、修正パッチの適用速度などを共有する。
- 脆弱性開示: 脆弱性が発見された際は、単なる修正報告にとどまらず、共通脆弱性タイプ（CWE）に基づく根本原因分析（RCA）を公開・共有する。
- プロセスやロードマップの明示: ソフトウェア部品表（SBOM）の提供、NIST SSDF等のセキュア開発フレームワークへの準拠宣言、メモリ安全言語への移行ロードマップを公表する。
③ リーダーシップ
セキュリティを現場の技術的課題として扱うのではなく、ビジネスの最優先事項および「製品品質」の要素として位置づける原則です。
- 経営幹部の責任任命: セキュア・バイ・デザインプログラムを主導・統括する上級役員を明確に指定する。
- 取締役会レベルでの管理: 製品セキュリティの状態やリスクメトリクスを取締役会へ定例報告し、ガバナンス評価の指標とする。
- 評価・インセンティブの連動: 機能開発やパフォーマンス目標と同様に、セキュリティの向上実績を人事評価や報酬（ボーナス・昇進基準）に反映させる。
組織における実装方法とベストプラクティス
CISAの原則を組織で実践するには、開発プロセス・組織体制・ビジネスの3つの面からアプローチします。
(1) デフォルト設定の堅牢化（Secure by Default Practices）
- 初期パスワードの全廃: 推測容易な共通デフォルトパスワードを廃止し、個体ごとの固有パスワード生成や初回ログイン時の強制変更を実施する。
- MFAとログの標準化: 特権アカウントに対するMFAの既定強制、およびセキュリティログの記録・保存を追加費用なしで標準有効化する。
- 後方互換性より安全性の優先: セキュリティリスクの高い古いプロトコルや暗号化方式を廃止・無効化する。
(2) セキュア開発ライフサイクル（S-SDLC）の構築
- 開発フレームワークの採用: NIST SSDF（SP 800-218）などの標準フレームワークを採用・ドキュメント化する。
- 早期の脅威モデリング（Shift-Left）: 企画・要件定義段階からSTRIDEやPASTAといった手法を用いて脅威モデリングを実施し、設計前にリスクを特定する。
- メモリ安全言語の活用: C/C++などのメモリ破壊系脆弱性が生じやすい領域に対し、RustやGoなどのメモリ安全言語への移転・新設を進める。
- サプライチェーンリスク管理: オープンソース（OSS）依存関係を精査し、SCA（ソフトウェア構成分析）ツールを活用してSBOM（ソフトウェア部品表）を自動生成・管理する。
(3) 推進体制と自動化パイプライン（DevSecOps）
- セキュリティチャンピオン（Security Champions）の育成: 各開発チーム内にセキュリティの啓蒙役（チャンピオン）を配置し、セキュリティチームと現場エンジニアの架け橋とする。
- DevSecOpsパイプラインでの自動化: IDEでのセキュアコーディング支援、CI/CDパイプライン内でのSAST（静的解析）、SCA、DAST（動的解析）、コンテナスキャンを自動実行する「ガードレール」を整備する。
- 指標（KPI）による継続的評価: 脆弱性の修正平均時間（MTTR）、リリース前閉塞件数、MFA適用率などのKPIを設定し、定期的に評価・改善する。
疑問と課題
なるほど、セキュリティも込みで最初から設計すればいいというのはわかる、信頼性も向上できそうだし、コスト削減という面でも理想であることもわかる。保守性もよいシステムができるだろう。
しかし、現状運用されているシステムを入れ替える必要があるのか？ 現実的に考えるとセキュリティの専門知識を要するため、セキュリティに特化した専門家が必要なのだろうか、など課題を感じました。
現場では、
- アジャイル開発で早くMVP（プロトタイプ）を出したいのに、最初からガチガチに脅威分析していられない
- 最初からNISTやOWASPの基準を100%満たそうとして開発チームが疲弊してしまう
- そもそもどこまでやれば十分なのかがわからず、費用対効果の線引きが難しい
- 誰が責任を持つのか問題（開発者ってどこまで責任を負う必要があるの？）
といったリアルな課題が挙げられています。
まずはできることから
今あるシステムを一から作り直す必要はなく（もちろんコストやリソースがあるならセキュアな設計ができたほうがよい）、できることから対策を進めていきましょうと、デジタル庁やIPAのガイドラインにも記載があります[cite: 1, 5]。できるところから対策・運用をはじめ、段階的に成熟度を上げていくアプローチが現実的です[cite: 1, 5]。
例えば
-
外側から守る（境界防御・WAF）
コードを直接実装し直せなくとも、システムの手前にWAFを導入したり、APIゲートウェイを設置してSQLインジェクションなどの攻撃を外側で遮断・保護することは十分可能だと思います。 -
機能追加や改修のタイミングで部分的に適用する
新規機能追加や画面改修のタイミングでそのモジュールだけ多要素認証必須化したり、入力バリデーションの厳格化などのセキュア・バイ・デフォルトの基準を適用していくのもありでしょう。 -
何が使われているかの可視化（SBOM・SCA）
コードを変更しなくとも、SCA（ソフトウェア構成分析）ツールを利用してオープンソースライブラリの依存関係やSBOM（ソフトウェア部品表）を自動生成して、脆弱性の影響範囲を把握できるようにしておくことで、何かあったときに対応しやすくなります。
セキュリティの知識がなくとも「OWASP Top 10 Proactive Controls」などのガイドラインを参考にして、開発者が押さえるべき基本ルールを活用することで独自に認証や暗号ロジックを組み込まず、既存の安全とされているフレームワークやライブラリの機能を利用することで、関連する脆弱性を防ぐことができそうです。
また、チーム内に「Security Champions（セキュリティチャンピオン）」を置くことで、開発スピードを落とさず安全確保が可能となるケースもあります。すでにSecurity Championsを導入している企業もあるそうです。
参考：freeeさん事例
おわりに
ずいぶん長い間、開発業務から離れてしまったので、今現在の開発チームがどのようにセキュリティ対策をしているのかを把握していないのですが、気をつけるべき点が多いなと感じます。
ただ、自分が担当した箇所だったり、自社システムなど、「改修しなきゃいけない」ってなったときに、こういう考え方があることを思い出していただけると嬉しいです。
これから先、AIによってサイバー攻撃のスピードが早くなったり、大量に攻撃コードを準備できたり、狙われるリスクは高くなるかもしれません。
後から何回もセキュリティ対策を実装するのも、開発側としてはしんどさを感じるだろうし（そこはメインではないかもしれない）、利用者側もセキュリティ大丈夫かなと心配になったり。経営層も「自分の会社のシステムはセキュリティしっかり考慮しているよ！」と言いたいかもしれない。
そういったときに、この考え方に沿っていることで、一定の安全性は担保できる（絶対攻撃されないとは言えないですが）、無茶な追加実装をしなくてよい設計なので、基本ルールに則って対応すれば問題ないという安心感、生まれてほしいなと思った次第でした。
次このテーマを扱うときは、読んでくださる方が学びを得られるように、もうちょっと深堀りしてみます。
おまけ
IPAのセキュリティ・バイ・デザイン導入指南書にある、素敵なひとこと。
いろんなページにあひるさんがいて、ユーモアあるコメントがチャーミングでした。
用語集
- CISA（米サイバーセキュリティ・社会インフラ安全保障庁）：米国のサイバーセキュリティ専門官庁。製品の安全は作る側の責任だと世界に呼びかける推進役。
- SDLC（ソフトウェア開発ライフサイクル）：企画から設計、実装、テスト、運用まで続く一連の開発プロセス。
- S-SDLC（セキュアソフトウェア開発ライフサイクル）：SDLCの全工程にセキュリティ対策を組み込んだ開発プロセスのこと。
- NIST SSDF（セキュアソフトウェア開発フレームワーク）：米国の標準化機関（NIST）が定めた、安全にソフトウェアを作るための手順書・チェックリスト（SP 800-218）。
- STRIDE（ストライド）：なりすましや改ざんなど、6つの攻撃手口から「どんな脅威を受けるか」を網羅的に洗い出す手法。
- PASTA（パスタ）：攻撃者の目線に立ち、「攻撃されたらビジネスにどんな損害が出るか」までを7段階で分析するリスク中心の手法。
- NIST（米国立標準技術研究所）：米国の公的標準化機関。世界中の政府や企業が手本にするセキュリティ基準を策定している。
- OWASP（オワスプ）：Webセキュリティの向上を目指す世界的な非営利コミュニティ。「OWASP Top 10」など現場向けの実践ガイドを多数公開している。