いざ、BSC討伐の旅

Transcript

1. いざ、BSC討伐の旅 ※BSC：ぼくのかんがえたさいきょうのチェックリスト
2. セキュリティチェックリストとは 組織のベースラインとして満たすべきセキュリティ要件をチェックリスト化したもの。 2 Policy Standards Baselines Guidelines Procedures このあたり 分類 例 業界の統制文書 • FISC 安全対策基準 自社グループの統制文書 • グループ共通のセキュリティ標準など 外部のベストプラクティス類 • OWASP Japan Webシステム/Webアプリケー ションセキュリティ要件書 • 外部ベンダによる脆弱性診断の観点から逆算した セキュリティ要件 • クラウドベンダのベストプラクティスフレームワーク類 • NIST-SP800シリーズなど 自社ローカルルール • 過去のヒヤリハットを要件化したものなど 位置づけ 主なインプット
3. 使いどころ システム開発プロセスの中で2つの目的・4つの出番 1. サードパーティの評価 2. システムの開発・改修における品質確認 3 要件定義 設計 開発 テスト リリース 運用 企画 2ｰ① 中間評価 2ｰ② 最終評価 システム評価（セキュリティ担当） 1ｰ① 契約前 1-② 契約後・年次 サードパーティ評価（委託先管理担当）
4. 目次 1.BSC闇堕ちものがたり 2.BSC討伐の旅(夢想編） 3.BSC討伐の旅(現実編）
5. Section1. BSC闇堕ちものがたり
6. 魂を注ぎ育てあげたBSC 過去3年間で数千万円、数千時間を費やして怒涛の10回改訂。 総数は増えつつも、実質的な回答数は大きく変わらないように抑制。 加えて、10時間分の教育（要件解説）コンテンツも提供。 6 版数 改定時期 改定項目数 項目総数 一般パターン 要回答数 第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アプリケーションセキュリ ティ要件書 取り込み
7. ⚫ 要件に対して一部でも出来ていたら「YES」回答 ⚫ マズい部分は「セキュリティのため非開示」 新たな課題、続々発生（サードパーティ評価ver） 7 明かされない真実 BSCの課題
8. 8 ⚫ 評価者も回答者（サービス提供者）も、セキュリティの専門家ではない ⚫ 評価者（委託先管理担当）は、評価対象システムに詳しいわけではない 新たな課題、続々発生（サードパーティ評価ver） 明かされない真実 すれ違うやりとり BSCの課題
9. 9 ⚫ 毎年全システムへの定期チェックリスト評価 （10名以上で延々とチェックリストを見つめる毎日） 新たな課題、続々発生（サードパーティ評価ver） 重い作業負荷 明かされない真実 すれ違うやりとり BSCの課題
10. 10 重い作業負荷 揉める改善調整 ⚫ ベンチャー企業には重すぎるJTCの要件 ex. 本番環境メンテナンス用のインターネット接続・メール不可な踏み台 ⚫ ノンカスタマイズSaaSに対し、当社要件のために改善して！は通らない 明かされない真実 すれ違うやりとり 新たな課題、続々発生（サードパーティ評価ver） BSCの課題
11. 11 BSCの課題 ⚫ これは「北風と太陽」の北風状態では？ ⚫ 限られたリソースをこんな仕事に費やし続けていいのか？ ⚫ チェックリスト統制の限界では？ 力をかけた分効果があれば良いが…結局、セキュリティ事故は起こる 評価時はYESと答えたのにやってなかった… あるはずのない場所に本番データがおかれていた… etc
12. Section2. BSC討伐への旅(夢想編）
13. 13 どうしてこうなった そもそも外部サービスを使うのは、ビジネスの機能を疎結合にしてスピーディに価値を提供したいから 疎 ノーチェック 細部の評価 改善の強制 （理想）リスクに応じた力加減での 「身だしなみの確認」 無関係の他社 グループ会社など サードパーティ事業者 密 しかし責任は密結合。その割に基準は曖昧で個社任せ 各社バラバラ＆過剰に密な管理（BSC管理）へ… <金融分野におけるサイバーセキュリティに関するガイドライン>
14. 解決の方向性（案） 14 外部評価の活用 ＆ BSCの極小化 ロードを下げて 同じモノサシで （皆がそうなら仕方ない） 重い作業負荷 揉める改善調整 明かされない真実 すれ違うやりとり <金融分野におけるサイバーセキュリティに関するガイドライン> 餅は餅屋に 外部評価を活用して「評価基準の統一」と「一定の距離感」を「みんなで進める」 ISMAP SOC2 Secure SketCH Assured etc…
15. 解決の方向性（案） 「みんなで進める」土台は整いつつあるように見える 15 Assured様 Webサイトから https://assured.jp/case
16. 外部評価 各種ガイドライン類 各社BSC 要件A 要件B 要件C 各社の小さなチェックリストへ 解決の方向性（案） 外部評価を活用するためには各事業会社のBSCを分解・マッピングし、残った自社オリジナル 要件を「小さなチェックリスト」に（各社がパワーをかけるべき・支援が欲しいところ） 更に残った要件が業界共通なら、外部評価サービス側に取り込んでもらうなどの協業も 16 ISMS CIS Controls FISC 安対基準 外部評価サービス 第三者保証レポート
17. Section3. BSC討伐への旅(現実編）
18. 外部評価サービスを評価してみた 評価項目の確認 18 ➢ 一定の網羅性がありイイ感じに見えるが、深度の面で物足りない ex. セキュアコーディングの個々の対策は？クラウド保護の詳細は？etc 利用企業へのインタビュー ➢ 評価の質は高評価 ➢ 反面、以下の課題 ➢ 利用したいサービスの網羅率 ➢ 評価のスピード感 ➢ BSC適合率 ➢ 再委託先（フォースパーティ）の評価不可 ➢ （もっと活用したいが）セカンドオピニオン、限定利用どまり ＃上記全般的に、自業種だけ細かすぎる自覚はありつつ。
19. 解決の方向性（案） 19 （１）外部評価サービスと各社 双方の歩み寄り （２）複数の外部評価の使い分け 充実・見切りともにISAC単位など業界横ぐしで調整し、全体としての落としどころを模索 サードパーティの重要度ごとに評価方法を使い分け 重要度 評価方法 最高 BSC 高 ISMAP（BSC適合率70%） 中 外部評価サービスA（BSC適合率50%） 低 外部評価サービスB（BSC適合率30%） ※表の内容はイメージです
20. 各サービス事業者へお願いしたいこと 20 • セキュリティへの真摯な取り組み 対策不十分の事業者がいるのも事実（特に内部不正対策） 過度な評価をしない分、各社が自立的に対策しないと単なるレベルダウン • 透明性の向上 • 脆弱性診断結果の開示（概要だけでも） • 要件への充足状況の開示（YES/NOだけでも） • 契約やSLAへの必要事項の盛り込み <金融分野におけるサイバーセキュリティに関するガイドライン>
21. まとめ 21 ⚫ 本来は疎結合で使いたかった外部サービスに対し、様々な外圧から密な管理をしてきたが、 BSCによる管理手法も限界を迎えつつある ⚫ 解決のためには外部評価サービス等を利用して 「評価基準の統一」と「一定の距離感」を「みんなで進める」 ⚫ ただし、現状は（特定業種においては）外部評価サービスをフル活用できない実情 ⚫ 事業会社、サービス事業者、外部サービス評価者 3者の協力が重要 共通化 見切り セキュリティへの取り組み 透明性向上 評価の充実
22. ありがとうございました。 ・・・といいつつ（時間あれば）
23. （おまけ）裏ボス？「提供元基準」 23 （当ページは発表者が勉強不足の領域なので誤りを含む可能性があります） 個人データを第三者提供する場合、提供先で特定の個人を識別できない状態だとしても、 提供元で容易に照合できて特定の個人を識別できる状況にあれば「個人データの提供」となる。らしい。 提供元基準に当てはめるとほとんどの システムが個人データ有になってしまう。 個人データ有だと重要度「中」以下とし て扱いにくく、メリハリつけたサードパー ティ管理が困難に。。（要調査） 重要度 評価方法 最高 BSC 高 ISMAP（BSC適合率70%） 中 外部評価サービスA（BSC適合率50%） 低 外部評価サービスB（BSC適合率30%）