JTCや セキュリティチェックリストが夢の跡

20240918 Cyber-sec+ Meetup vol.5 発表資料

Transcript

1. JTCや セキュリティチェックリストが夢の跡 Cyber-sec+ Meetup vol.5
2. 自己紹介（超短縮版） 2 名前：ニキヌス（X:@nikinusu） 所属：金融JTCのシステム子会社 嫌いなもの：しいたけ
3. セキュリティチェックリストとは 組織のベースラインとして満たすべきセキュリティ要件をチェックリスト化したもの。 3 Policy Standards Baselines Guidelines Procedures このあたり 分類 例 業界の統制文書 • FISC 安全対策基準 自社グループの統制文書 • グループ共通のセキュリティ標準など 外部のベストプラクティス類 • OWASP Japan Webシステム/Webアプリケー ションセキュリティ要件書 • 外部ベンダによる脆弱性診断の観点から逆算した セキュリティ要件 • クラウドベンダのベストプラクティスフレームワーク類 • NIST-SP800シリーズなど 自社ローカルルール • 過去のヒヤリハットを要件化したものなど 位置づけ 主なインプット
4. 使いどころ システム開発プロセスの中で2つの目的・4つの出番 1. 委託先の評価 2. システムの開発・改修における品質確認 4 1ｰ① 委託先の評価（契約前） 1-②委託先の評価（契約後・年次） 要件定義 設計 開発 テスト リリース 運用 企画 2ｰ① 中間評価 2ｰ② 最終評価 委託先評価（委託先管理担当） システム評価（セキュリティ担当）
5. Section1. セキュリティチェックリスト回顧録
6. チェックリスト回顧録（紀元前） 6 セキュリティチェックリストらしきもの 委託先チェックリスト Webアプリのセキュリティ スマホアプリのセキュリティ API提供時のセキュリティ JTCあるある：「気づけばあった」 おそらくISMSや当局から求められることを他の非機能要件とごちゃまぜで書いていたと想像。 要件があるようでない。機能していない。
7. どうにかせねば… 「マトモなセキュリティ要件」が無いのは、セキュリティ担当の心臓がないのと同じ。 対策をもとめる根拠がない。説明もできない。 システム開発プロセスできちんと使われる、血が通う心臓を作らねば。 7 ＜コンセプト＞ ⚫ これさえ見ればセキュリティ要件はオールインワン ⚫ システムごとに育てていくチェックリスト
8. チェックリスト回顧録（誕生） 心臓、できました。 8
9. チェックリスト回顧録（誕生） 課題の大半を解決。セキュリティ要件が明確に認知され、組織的に機能するように。 9 課題 対応 • 複数のチェックリスト間で重複＆デコボコ チェックリストの統一、重複要件の排除（500→370項目） • 要件数が多すぎる 共通インフラで満たされる要件を除外（370→約130項目へ絞り込み） • メンテナンスの遅さ セキュリティ担当がメンテナンス権を持つ • 分かりづらさ（目的語が不明確） 文章の簡潔化、目的語の明確化 • 認知度ほぼゼロ、形骸化したプロセス 開発プロセスへ組み込み、セキュリティ担当のレビュー開始 • 各要件の出自、考え方不明 残課題
10. チェックリスト回顧録（育成期） 過去3年間で数千万円、数千時間を費やして怒涛の10回改訂。 総数は増えつつも、実質的な回答数は大きく変わらないように抑制。 加えて、10時間分の教育（要件解説）コンテンツも提供。 10 版数 改定時期 改定項目数 項目総数 一般パターン 要回答数 第1版 2021年4月 740 131 第2版 2021年7月 35 742 133 第3版 2021年12月 57 770 151 第4版 2022年4月 29 776 156 第5版 2022年7月 30 792 157 第6版 2022年10月 1 792 152 第7版 2023年1月 88 837 148 第8版 2023年7月 77 854 149 第9版 2024年4月 117 887 145 第10版 2024年7月 12 891 146 +151 +15 コンテナ要件の追加 クラウド要件の全面見直し OWASP Webシステム /Webアプリケーションセキュリ ティ要件書 取り込み
11. チェックリスト回顧録（育成期） 過去3年間で数千万円、数千時間を費やして怒涛の10回改訂。 総数は増えつつも、実質的な回答数は大きく変わらないように抑制。 加えて、10時間分の教育（要件解説）コンテンツも提供。 11 版数 改定時期 改定項目数 項目総数 一般パターン 要回答数 第1版 2021年4月 740 131 第2版 2021年7月 35 742 133 第3版 2021年12月 57 770 151 第4版 2022年4月 29 776 156 第5版 2022年7月 30 792 157 第6版 2022年10月 1 792 152 第7版 2023年1月 88 837 148 第8版 2023年7月 77 854 149 第9版 2024年4月 117 887 145 第10版 2024年7月 12 891 146 +151 +15 コンテナ要件の追加 クラウド要件の全面見直し OWASP Webシステム /Webアプリケーションセキュリ ティ要件書 取り込み （公開用補記） P.9の370項目と数字が異なるが、 カウント方法による違い。 詳細説明は割愛
12. チェックリスト回顧録（育成期） 新たな課題、続々発生。 12
13. ⚫ リリース直前に駆け込み回答 ⚫ 外部ベンダの回答そのまま提出 「～は御社の設計次第です」 ⚫ 「今回のプロジェクトの改修箇所でない」と素通り。一生素通り。 チェックリスト回顧録（育成期） 新たな課題、続々発生。 13 向き合わない人々
14. チェックリスト回顧録（育成期） 新たな課題、続々発生。 14 向き合わない人々 信用ならない回答 ⚫ とりあえず全部「YES」 ⚫ 誤読、見落とし、思い込み
15. チェックリスト回顧録（育成期） 新たな課題、続々発生。 15 向き合わない人々 信用ならない回答 評価ロードの爆増 ⚫ 年間300件×長いと1件あたり数時間のレビュー ⚫ 開発部からの相談激増（いいことではある） ⚫ 少しでも回答者の負担を減らすために回答要否を絞り込み！ →地獄のような制御ロジック メンテナンスの複雑化
16. チェックリスト回顧録（育成期） 新たな課題、続々発生。 16 向き合わない人々 信用ならない回答 評価ロードの爆増 メンテナンスの複雑化 収まりきらない要件 ⚫ 項目数を増やすと嫌がられるから！できるだけ要件数を増やさないように！ →1セルに文字大杉
17. チェックリスト回顧録（育成期） 新たな課題、続々発生。 17 向き合わない人々 信用ならない回答 評価ロードの爆増 育たないチェックリスト メンテナンスの複雑化 収まりきらない要件 ⚫ 過去のプロジェクトで整理した結果が引き継がれず、何故か毎回 「さいしょからスタート」
18. チェックリスト回顧録（育成期） 新たな課題、続々発生。 18 向き合わない人々 信用ならない回答 評価ロードの爆増 育たないチェックリスト メンテナンスの複雑化 収まりきらない要件 評価対象の混在 ⚫ そもそも社内と委託先向けに求める内容は異なる ⚫ 使うべき用語も異なる ⚫ そもそも社内と委託先向けに求める内容、使うべき用語は異なる ⚫ どんどん新たな要件が生まれるが・・・ それをチェックする委託先管理担当はセキュリティの専門家でも何でもない。 ついてこれない 委託先管理担当
19. チェックリスト回顧録（育成期） 19 ⚫ これは「北風と太陽」の北風状態では？ ⚫ 限られたリソースをこんな仕事に費やし続けていいのか？ ⚫ チェックリスト統制の限界では？
20. Section2. チェックリスト極小化への道のり（進行中）
21. 方向性 目指せ、高タイパ統制 21 向き合わない人々 信用ならない回答 評価ロードの爆増 育たないチェックリスト メンテナンスの複雑化 収まりきらない要件 評価対象の混在 ついてこれない 委託先管理担当 ガードレール化＆チェックリスト極小化 Excelからの脱却 委託先評価とシステム評価の分離 外部評価サービスの活用 活用しやすく 評価がブレにくく 評価ロードを下げて 過去の結果を反映して 仕組みをシンプルに 読みやすく 対象にあった内容で 餅は餅屋に
22. 22 方向性 実現のためにも、「ゲートウェイ型→ガードレール型」の発想を取り込む。 極力レベルダウンを避けつつ、自由と責任を渡してエンジニアの本業に時間を割けるように。 ⚫ 全要件をチェックリストで評価 ⚫ （前提）要件はしっかり提示（背景、実現手法、代替策含め） ⚫ 技術的な発見統制を整備し、真に残すべき要件のみ チェックリスト化 • 診断やxSPMで確認できるならチェックリスト化しない • 外部評価で確認できるならチェックリスト化しない • 優先度が低い要件はチェックリスト化しない Before：ゲートウェイ型 After：ガードレール型
23. 23 チェックリスト極小化への道のり（進行中） 単純削減＝極小化ではない。 要件の性質や重要度を見極めて、減らした分の品質をどう代わりに担保するのか、残した分を どう使いやすくするのか精査とセット。 優先度の定義 委託先評価と システム評価の分離 フレームワーク類との マッピング 外部評価活用の 枠組み整備 外部評価の活用 要件の詳述化 技術的に統制できる 要件の洗い出し (診断、xSPMなど） チェックリストの極小化 チェックリストに 残す要件の抽出 システム評価 委 託 先 評 価 Start Goal 脱Excel・Web化
24. 24 チェックリストに残す要件とは、例えば 「脆弱性診断で確認できず、かつ優先度が中以上の要件」など （以下、Webアプリ構築時の設計に関する要件の例） チェックリスト極小化への道のり（進行中） 診断で確認可否 優先度（危険度×手戻り度） 合計 高 中 低 可 8 7 4 19 不可 7 6 4 17 36 例：重要操作時のユーザ通知要件 例：特定条件での多要素認証の採用要件 例：パスワード強度要件 例：重要情報の画面表示マスク要件 36→13件に削減
25. まとめ 25 ⚫ ベースラインとしてのセキュリティ要件の定義は、統制の第一歩であり避けては通れない。 ⚫ ただし、その全てをチェックリスト化することは必ずしもベストではない。 チェックリストによる統制は、かかる労力に対して効果が非常に低い。 ⚫ 技術的な対策と組み合わせた「ガードレール化」や「外部評価の活用」によりチェックリストを 極小化し、高タイパ統制を目指したい。 ⚫ みんなでやれば怖くない（多分）
26. ありがとうございました。