Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
JTCや セキュリティチェックリストが夢の跡
Search
nikinusu
September 18, 2024
Technology
2
1.2k
JTCや セキュリティチェックリストが夢の跡
20240918 Cyber-sec+ Meetup vol.5 発表資料
nikinusu
September 18, 2024
Tweet
Share
More Decks by nikinusu
See All by nikinusu
実務における脅威モデリングを考えよう
nikinusu
1
890
Other Decks in Technology
See All in Technology
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
3.1k
Case Study: Concurrent Counting
ennael
PRO
0
110
YAPC::Hakodateの映像記録を支える技術
godan
4
220
O'Reilly Superstream: Building a RAG App to Chat with Your Data
pamelafox
0
120
分析者起点の企画を成功させた連携面の工夫
lycorptech_jp
PRO
1
250
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
1
860
DenoでもViteしたい!インポートパスのエイリアスを指定してラクラクアプリ開発
bengo4com
2
1.9k
Product Utilization of Large Language Models Starting Today
ymatsuwitter
3
1.3k
VS CodeでF1〜12キーつかってますか? / Do you use the F1-12 keys in VS Code?
74th
2
300
【swonet.conf_】NOCメンバーが語るSTMの実態!! ~ShowNetから若者への贈り物~
shownet
PRO
0
310
【shownet.conf_】クロージングセッション
shownet
PRO
0
300
プロダクト開発の貢献をアピールするための目標設計や認知活動 / Goal design and recognition activities to promote product development contributions.
oomatomo
4
770
Featured
See All Featured
The Language of Interfaces
destraynor
154
24k
Docker and Python
trallard
40
3k
Embracing the Ebb and Flow
colly
84
4.4k
Creatively Recalculating Your Daily Design Routine
revolveconf
217
12k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.7k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Rails Girls Zürich Keynote
gr2m
93
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
327
21k
4 Signs Your Business is Dying
shpigford
180
21k
Typedesign – Prime Four
hannesfritz
39
2.3k
The Invisible Side of Design
smashingmag
297
50k
Transcript
JTCや セキュリティチェックリストが夢の跡 Cyber-sec+ Meetup vol.5
自己紹介(超短縮版) 2 名前:ニキヌス(X:@nikinusu) 所属:金融JTCのシステム子会社 嫌いなもの:しいたけ
セキュリティチェックリストとは 組織のベースラインとして満たすべきセキュリティ要件をチェックリスト化したもの。 3 Policy Standards Baselines Guidelines Procedures このあたり 分類
例 業界の統制文書 • FISC 安全対策基準 自社グループの統制文書 • グループ共通のセキュリティ標準など 外部のベストプラクティス類 • OWASP Japan Webシステム/Webアプリケー ションセキュリティ要件書 • 外部ベンダによる脆弱性診断の観点から逆算した セキュリティ要件 • クラウドベンダのベストプラクティスフレームワーク類 • NIST-SP800シリーズなど 自社ローカルルール • 過去のヒヤリハットを要件化したものなど 位置づけ 主なインプット
使いどころ システム開発プロセスの中で2つの目的・4つの出番 1. 委託先の評価 2. システムの開発・改修における品質確認 4 1ー① 委託先の評価(契約前) 1-②委託先の評価(契約後・年次)
要件定義 設計 開発 テスト リリース 運用 企画 2ー① 中間評価 2ー② 最終評価 委託先評価(委託先管理担当) システム評価(セキュリティ担当)
Section1. セキュリティチェックリスト回顧録
チェックリスト回顧録(紀元前) 6 セキュリティチェックリストらしきもの 委託先チェックリスト Webアプリのセキュリティ スマホアプリのセキュリティ API提供時のセキュリティ JTCあるある:「気づけばあった」 おそらくISMSや当局から求められることを他の非機能要件とごちゃまぜで書いていたと想像。 要件があるようでない。機能していない。
どうにかせねば… 「マトモなセキュリティ要件」が無いのは、セキュリティ担当の心臓がないのと同じ。 対策をもとめる根拠がない。説明もできない。 システム開発プロセスできちんと使われる、血が通う心臓を作らねば。 7 <コンセプト> ⚫ これさえ見ればセキュリティ要件はオールインワン ⚫ システムごとに育てていくチェックリスト
チェックリスト回顧録(誕生) 心臓、できました。 8
チェックリスト回顧録(誕生) 課題の大半を解決。セキュリティ要件が明確に認知され、組織的に機能するように。 9 課題 対応 • 複数のチェックリスト間で重複&デコボコ チェックリストの統一、重複要件の排除(500→370項目) • 要件数が多すぎる
共通インフラで満たされる要件を除外(370→約130項目へ絞り込み) • メンテナンスの遅さ セキュリティ担当がメンテナンス権を持つ • 分かりづらさ(目的語が不明確) 文章の簡潔化、目的語の明確化 • 認知度ほぼゼロ、形骸化したプロセス 開発プロセスへ組み込み、セキュリティ担当のレビュー開始 • 各要件の出自、考え方不明 残課題
チェックリスト回顧録(育成期) 過去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アプリケーションセキュリ ティ要件書 取り込み
チェックリスト回顧録(育成期) 過去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
⚫ リリース直前に駆け込み回答 ⚫ 外部ベンダの回答そのまま提出 「~は御社の設計次第です」 ⚫ 「今回のプロジェクトの改修箇所でない」と素通り。一生素通り。 チェックリスト回顧録(育成期) 新たな課題、続々発生。 13
向き合わない人々
チェックリスト回顧録(育成期) 新たな課題、続々発生。 14 向き合わない人々 信用ならない回答 ⚫ とりあえず全部「YES」 ⚫ 誤読、見落とし、思い込み
チェックリスト回顧録(育成期) 新たな課題、続々発生。 15 向き合わない人々 信用ならない回答 評価ロードの爆増 ⚫ 年間300件×長いと1件あたり数時間のレビュー ⚫ 開発部からの相談激増(いいことではある)
⚫ 少しでも回答者の負担を減らすために回答要否を絞り込み! →地獄のような制御ロジック メンテナンスの複雑化
チェックリスト回顧録(育成期) 新たな課題、続々発生。 16 向き合わない人々 信用ならない回答 評価ロードの爆増 メンテナンスの複雑化 収まりきらない要件 ⚫ 項目数を増やすと嫌がられるから!できるだけ要件数を増やさないように!
→1セルに文字大杉
チェックリスト回顧録(育成期) 新たな課題、続々発生。 17 向き合わない人々 信用ならない回答 評価ロードの爆増 育たないチェックリスト メンテナンスの複雑化 収まりきらない要件 ⚫
過去のプロジェクトで整理した結果が引き継がれず、何故か毎回 「さいしょからスタート」
チェックリスト回顧録(育成期) 新たな課題、続々発生。 18 向き合わない人々 信用ならない回答 評価ロードの爆増 育たないチェックリスト メンテナンスの複雑化 収まりきらない要件 評価対象の混在
⚫ そもそも社内と委託先向けに求める内容は異なる ⚫ 使うべき用語も異なる ⚫ そもそも社内と委託先向けに求める内容、使うべき用語は異なる ⚫ どんどん新たな要件が生まれるが・・・ それをチェックする委託先管理担当はセキュリティの専門家でも何でもない。 ついてこれない 委託先管理担当
チェックリスト回顧録(育成期) 19 ⚫ これは「北風と太陽」の北風状態では? ⚫ 限られたリソースをこんな仕事に費やし続けていいのか? ⚫ チェックリスト統制の限界では?
Section2. チェックリスト極小化への道のり(進行中)
方向性 目指せ、高タイパ統制 21 向き合わない人々 信用ならない回答 評価ロードの爆増 育たないチェックリスト メンテナンスの複雑化 収まりきらない要件 評価対象の混在
ついてこれない 委託先管理担当 ガードレール化&チェックリスト極小化 Excelからの脱却 委託先評価とシステム評価の分離 外部評価サービスの活用 活用しやすく 評価がブレにくく 評価ロードを下げて 過去の結果を反映して 仕組みをシンプルに 読みやすく 対象にあった内容で 餅は餅屋に
22 方向性 実現のためにも、「ゲートウェイ型→ガードレール型」の発想を取り込む。 極力レベルダウンを避けつつ、自由と責任を渡してエンジニアの本業に時間を割けるように。 ⚫ 全要件をチェックリストで評価 ⚫ (前提)要件はしっかり提示(背景、実現手法、代替策含め) ⚫ 技術的な発見統制を整備し、真に残すべき要件のみ
チェックリスト化 • 診断やxSPMで確認できるならチェックリスト化しない • 外部評価で確認できるならチェックリスト化しない • 優先度が低い要件はチェックリスト化しない Before:ゲートウェイ型 After:ガードレール型
23 チェックリスト極小化への道のり(進行中) 単純削減=極小化ではない。 要件の性質や重要度を見極めて、減らした分の品質をどう代わりに担保するのか、残した分を どう使いやすくするのか精査とセット。 優先度の定義 委託先評価と システム評価の分離 フレームワーク類との マッピング
外部評価活用の 枠組み整備 外部評価の活用 要件の詳述化 技術的に統制できる 要件の洗い出し (診断、xSPMなど) チェックリストの極小化 チェックリストに 残す要件の抽出 システム評価 委 託 先 評 価 Start Goal 脱Excel・Web化
24 チェックリストに残す要件とは、例えば 「脆弱性診断で確認できず、かつ優先度が中以上の要件」など (以下、Webアプリ構築時の設計に関する要件の例) チェックリスト極小化への道のり(進行中) 診断で確認可否 優先度(危険度×手戻り度) 合計 高 中
低 可 8 7 4 19 不可 7 6 4 17 36 例:重要操作時のユーザ通知要件 例:特定条件での多要素認証の採用要件 例:パスワード強度要件 例:重要情報の画面表示マスク要件 36→13件に削減
まとめ 25 ⚫ ベースラインとしてのセキュリティ要件の定義は、統制の第一歩であり避けては通れない。 ⚫ ただし、その全てをチェックリスト化することは必ずしもベストではない。 チェックリストによる統制は、かかる労力に対して効果が非常に低い。 ⚫ 技術的な対策と組み合わせた「ガードレール化」や「外部評価の活用」によりチェックリストを 極小化し、高タイパ統制を目指したい。
⚫ みんなでやれば怖くない(多分)
ありがとうございました。