IISECAlumniReunion20200926

by mnoguchi

Slide 1

Slide 1 text

セキュア開発の先を考える～ある活動の中の人の私見～ IISEC Alumni Reunion 2020 2020/09/26 2014年度修士課程修了(田中研) Mutsuo Noguchi

Slide 2

Slide 2 text

今回お伝えしたいこと セキュア開発(SDLC：Secure Development Life Cycle)の取り組みは形骸化との闘い Security by Design(SbD)が適用できる範囲は限定的 DevSecOpsは手段に過ぎない システムリスクの呪縛から解放されませんか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 1 引用元：Microsoft SDL の簡単な実装

Slide 3

Slide 3 text

Slide 4

Slide 4 text

セキュア開発開発プロセス（要件定義、設計、開発=コーディング）の各段階でセキュリティ対応/対策を行い、脆弱性を作りこまないようにする考え方  参考資料  要件定義  セキュリティ要件ガイドブック 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

Slide 5

Slide 5 text

セキュア開発は必須システム開発において、ユーザーとシステムベンダー間でセキュア開発の要件が契約上存在しなくても、セキュリティ対策は実施していることが期待される 情報流出に係るｼｽﾃﾑ損害賠償請求事件（東京地裁平成26.1.23）  判例：情報流出に係るｼｽﾃﾑ損害賠償請求事件（東京地裁平成26.1.23）  レジュメ  ご参考システムベンダのセキュリティ対策義務～東京地裁平成26年1月23日判決（平23（ワ)32060号）を素材として～武田勝弘（発表者）  成城大学法学部教授の町村泰貴さんブログ privacy:個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例(追記あり): Matimulog  徳丸さんのブログ SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 4

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

やらない言い訳・やったつもり セキュリティポリシーはわかったが製品へ適合する要件にまとめられない 守るべき情報が何か特定できないので、すべて同じレベルで保護機能を設計した ウチのチームはSbDの思想に則って必要な設計を行っているが隣はわからない （作成日不明の）セキュア開発の手順書に沿ってやってます バリデーションって何すればいいんですか？ 要件テストで達成度合いを評価しました！（人の数だけ結果が異なる） 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 8

Slide 10

Slide 10 text

Slide 11

Slide 11 text

鮮度を維持しよう セキュリティポリシーはわかったが製品へ適合する要件にまとめられない 守るべき情報が何か特定できないので、すべて同じレベルで保護機能を設計した ウチのチームはSbDの思想に則って必要な設計を行っているが隣はわからない （作成日不明の）セキュア開発の手順書に沿ってやってます バリデーションって何すればいいんですか？ 要件テストで達成度合いを評価しました！（人の数だけ結果が異なる） 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 10 製品のカテゴリ別に適合要件のベースを整理&メンテナンス 守るべき情報の導出プロセスをカテゴリ別にシンプルに整理 習熟度を不定期に測定し、チーム間の状況を見える化 手順書のメンテナンスと版管理の徹底 実装におけるフレームワークの活用&適用シーンの明確化 テストの再現性も重視したテスト作成ポリシーの整備

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

SbDの適用『可能となる』範囲を意識しよう SbDの概念自体は新しくない 時代の変化（スクラッチ→既製品活用→サービス活用）に伴い、自由に手が出せる範囲も変化 利用する製品/サービスの選定時には『自らコントロールできることが限定されていること』を前提に選定し、コントロール外で発生する事象はすべてリスク受容となることを理解する必要がある 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 18

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

エンジニアだからこそ盲目的になることリスクは脆弱性をコントロールし、脅威の発生確率を減らせば大丈夫？ 仕様を確定して実装しているし、ソフトウェアのパッチ管理も適切に行っているから大丈夫！  ソフトウェアのEoSより早くAPIなど機能/サービスのEoSがやってくることもある  認識できていれば、変更容易性を前提とした設計が可能だったかも？ ある国で爆発的に利用者が増えているサービスを利用しよう！修正対応も早いし、安心！  その国の法律でデータがある組織に流れていることもある  サービスの内容や機能だけでなく、データの所在地と経路に着目できていれば、採用を思い止まれたかも？ 企画/要件定義時にリスク分析が行われているから安心して設計/開発ができる！  そのリスク分析はシステムリスクやサイバーセキュリティに特化したものだったりしない？  システム/サービス開発に必要な要件が見えれば、事業継続に影響する重大リスクも見えて来たかも？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 28

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

今回お伝えしたこと セキュア開発(SDLC：Secure Development Life Cycle)の取り組みは形骸化との闘い Security by Design(SbD)が適用できる範囲は限定的 DevSecOpsは手段に過ぎない システムリスクの呪縛から解放されませんか？ 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 36 引用元：Microsoft SDL の簡単な実装