IISECAlumniReunion20200926

IISEC Alumni Reunion 2020で発表した資料です

Transcript

1. セキュア開発の先を考える ～ある活動の中の人の私見～ IISEC Alumni Reunion 2020 2020/09/26 2014年度修士課程修了(田中研) Mutsuo Noguchi
2. 今回お伝えしたいこと セキュア開発(SDLC：Secure Development Life Cycle)の 取り組みは形骸化との闘い Security by Design(SbD)が適用できる範囲は限定的 DevSecOpsは手段に過ぎない システムリスクの呪縛から解放されませんか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 1 引用元：Microsoft SDL の簡単な実装
3. セキュア開発とは 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 2
4. セキュア開発 開発プロセス（要件定義、設計、開発=コーディング）の各段階でセキュリティ対応/対策を行い、脆弱性を 作りこまないようにする考え方  参考資料  要件定義  セキュリティ要件ガイドブック https://www.soumu.go.jp/main_content/000517209.pdf  Webシステム／Webアプリケーションセキュリティ要件書 3.0 https://github.com/ueno1000/secreq  設計  セキュリティ・バイ・デザイン入門 https://www.ipa.go.jp/files/000055823.pdf ※金子 朋子さん発表資料  安全なソフトウェア開発が改めて重視 – SDL 導入の手始めに役立つガイドライン https://msrc-blog.microsoft.com/2012/04/23/sdl-1/  SDL https://owasp.org/www-pdf-archive/Jim_Manico_(Hamburg)_-_Securiing_the_SDLC.pdf  開発  JPCERT コーディネーションセンター セキュアコーディング https://www.jpcert.or.jp/securecoding/index.html  SEI CERT Coding Standards - CERT Secure Coding https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards  その他  情報システム開発契約のセキュリティ仕様作成のためのガイドライン（案） https://www.softwareisac.jp/ipa/index.php 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 3
5. セキュア開発は必須 システム開発において、ユーザーとシステムベンダー間でセキュア開発の要件が契約上存在しなくても、 セキュリティ対策は実施していることが期待される 情報流出に係るｼｽﾃﾑ損害賠償請求事件（東京地裁 平成26.1.23）  判例：情報流出に係るｼｽﾃﾑ損害賠償請求事件（東京地裁 平成26.1.23）  レジュメ  ご参考 システムベンダのセキュリティ対策義務～東京地裁平成26年1月23日判決（平23（ワ)32060号）を 素材として～ 武田勝弘（発表者）  成城大学法学部教授の町村 泰貴さんブログ privacy:個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例(追記あり): Matimulog  徳丸さんのブログ SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 4
6. セキュア開発の活動 以下のようにセキュア開発で実施される活動は各開発プロセスに合わせて実施される 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 5 引用元: https://www.pwc.com/jp/ja/services/digital-trust/cyber-security-consulting/product-cs/sdlc.html
7. セキュア開発行われていますか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 6
8. こんなことを聞いたことありませんか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 7
9. やらない言い訳・やったつもり セキュリティポリシーはわかったが製品へ適合する要件にまとめられない 守るべき情報が何か特定できないので、すべて同じレベルで保護機能を設計した ウチのチームはSbDの思想に則って必要な設計を行っているが隣はわからない （作成日不明の）セキュア開発の手順書に沿ってやってます バリデーションって何すればいいんですか？ 要件テストで達成度合いを評価しました！（人の数だけ結果が異なる） 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 8
10. セキュア開発は鮮度管理が命 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 9
11. 鮮度を維持しよう セキュリティポリシーはわかったが製品へ適合する要件にまとめられない 守るべき情報が何か特定できないので、すべて同じレベルで保護機能を設計した ウチのチームはSbDの思想に則って必要な設計を行っているが隣はわからない （作成日不明の）セキュア開発の手順書に沿ってやってます バリデーションって何すればいいんですか？ 要件テストで達成度合いを評価しました！（人の数だけ結果が異なる） 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 10 製品のカテゴリ別に適合要件のベースを整理&メンテナンス 守るべき情報の導出プロセスをカテゴリ別にシンプルに整理 習熟度を不定期に測定し、チーム間の状況を見える化 手順書のメンテナンスと版管理の徹底 実装におけるフレームワークの活用&適用シーンの明確化 テストの再現性も重視したテスト作成ポリシーの整備
12. Security by Designを真面目に取り組もう 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 11
13. 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 12
14. 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 13
15. 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 14
16. そもそも設計対象はすべてコントールできてる？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 15
17. コントロール可能なもの スクラッチで設計/開発するプログラム 自社製ソフトウェアを活用したシステム 他社製ソフトウェアの公開仕様の範囲で利用可能な設定/機能 上記のサポート範囲で提供されるパッチ適用などの運用 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 16
18. コントロールできる？ 自社製品の『動作環境』のライフサイクル 他社製品のライフサイクル クラウドサービスのEnd of Serviceポリシー 自開発システムとクラウドサービスの通信経路 ※可能なものはある クラウドサービスの稼働環境自体 などなど 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 17
19. SbDの適用『可能となる』範囲を意識しよう SbDの概念自体は新しくない 時代の変化（スクラッチ→既製品活用→サービス活用）に伴い、自由に手が出せる範囲も変化 利用する製品/サービスの選定時には 『自らコントロールできることが限定されていること』 を前提に選定し、 コントロール外で発生する事象はすべてリスク受容となることを理解する必要がある 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 18
20. DevSecOps 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 19
21. DevOpsにセキュリティを 要件定義から設計、実装、展開に至るDevOpsのサイクルにセキュリティを組み込んだものが DevSecOps 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 20
22. DevSecOps DevOpsの全プロセスでセキュリティを考慮すること 全プロセスで開発・運用・『セキュリティ』担当者が責任を共有すること 三者が連携してリスクが許容可能な範囲に留めながら、各プロセスを回すこと これらは手段でしかない 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 21
23. DevSecOps これまでの経験で開発プロセスの中で常にセキュリティが考慮されている事例の割合は？ セキュリティ担当者が開発現場で責任を担っているケースは？ 開発が終わった後に保守開発要員と運用要員を残して、主要メンバーが抜けていく経験は？ 手段を実践し続けるには『ヒト・モノ・カネ』の維持が必要 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 22
24. DevSecOpsは手段に過ぎない & 実践できているところは偉大 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 23
25. DevSecOpsはXaaSのような クラウドネイティブなサービス運営向けアプローチ 手段＝付加価値＝収益源 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 24
26. リスクの考え方 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 25
27. リスクとは将来の不確実性のこと 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 26
28. こんな傾向ありませんか？ リスクといえばネガティブなものだ システムリスクを適切に把握・管理すれば大丈夫 情報セキュリティリスクを（ｒｙ サイバーセキュリティリスクを（ｒｙ 脅威分析や脆弱性管理を（ｒｙ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 27
29. エンジニアだからこそ盲目的になること リスクは脆弱性をコントロールし、脅威の発生確率を減らせば大丈夫？ 仕様を確定して実装しているし、ソフトウェアのパッチ管理も適切に行っているから大丈夫！  ソフトウェアのEoSより早くAPIなど機能/サービスのEoSがやってくることもある  認識できていれば、変更容易性を前提とした設計が可能だったかも？ ある国で爆発的に利用者が増えているサービスを利用しよう！修正対応も早いし、安心！  その国の法律でデータがある組織に流れていることもある  サービスの内容や機能だけでなく、データの所在地と経路に着目できていれば、採用を思い止まれたかも？ 企画/要件定義時にリスク分析が行われているから安心して設計/開発ができる！  そのリスク分析はシステムリスクやサイバーセキュリティに特化したものだったりしない？  システム/サービス開発に必要な要件が見えれば、事業継続に影響する重大リスクも見えて来たかも？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 28
30. エンジニアだからこそ盲目的になること リスクは脆弱性をコントロールし、脅威の発生確率を減らせば大丈夫？ 仕様を確定して実装しているし、ソフトウェアのパッチ管理も適切に行っているから大丈夫！  ソフトウェアのEoSより早くAPIなど機能/サービスのEoSがやってくることもある  認識できていれば、変更容易性を前提とした設計が可能だったかも？ ある国で爆発的に利用者が増えているサービスを利用しよう！修正対応も早いし、安心！  その国の法律でデータがある組織に流れていることもある  サービスの内容や機能だけでなく、データの所在地と経路に着目できていれば、採用を思い止まれたかも？ 企画/要件定義時にリスク分析が行われているから安心して設計/開発ができる！  そのリスク分析はシステムリスクやサイバーセキュリティに特化したものだったりしない？  システム/サービス開発に必要な要件が見えれば、事業継続に影響する重大リスクも見えて来たかも？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 29 信頼するに足る情報を揃えずに 信頼していないか？
31. 国家の介入でビジネスの継続性が左右される世の中 リスクを適切に把握・管理するのは限界がある 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 30
32. エンジニアを縛る鎖 契約と契約に基づいた受注額による行動範囲指定 目の前に存在するシステム（設計図） 誰かが選定し、利用者として使うだけのサービス 上流プロセスから渡された要件定義/設計書 無慈悲に投げ掛けられる権力という名の暴力 etc 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 31
33. エンジニアを縛る鎖 契約と契約に基づいた受注額による行動範囲指定 目の前に存在するシステム（設計図） 誰かが選定し、利用者として使うだけのサービス 上流プロセスから渡された要件定義/設計書 無慈悲に投げ掛けられる権力という名の暴力 etc 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 32 現場のエンジニアを縛る鎖は堅い
34. 現場エンジニアの鎖が堅いなら、 現場の外から支援すれば良いのでは？ 外なら縛られないしね 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 33
35. Why？ 契約になくても問題が発生すれば責任を問われるのは変わらない 鎖を気にせず、自らの技術・知見をぶつけてみたい しがらみに燻っているエンジニアは組織が大きいほど存在する そもそもルーチンを繰り返す作業なんて（できるだけ）したくない 既存のセキュア開発のプロセスに限界を感じている 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 34
36. そういう想いに応えられる組織 欲しくありませんか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 35 https://twitter.com/sen_u/status/1309132758091026434
37. 今回お伝えしたこと セキュア開発(SDLC：Secure Development Life Cycle)の 取り組みは形骸化との闘い Security by Design(SbD)が適用できる範囲は限定的 DevSecOpsは手段に過ぎない システムリスクの呪縛から解放されませんか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 36 引用元：Microsoft SDL の簡単な実装