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
IISECAlumniReunion20200926
Search
mnoguchi
September 26, 2020
Research
0
310
IISECAlumniReunion20200926
IISEC Alumni Reunion 2020で発表した資料です
mnoguchi
September 26, 2020
Tweet
Share
More Decks by mnoguchi
See All by mnoguchi
Ethics & Intelligence
mnoguchi
0
110
Other Decks in Research
See All in Research
Minimum Bayes-Risk Decoding における性能変動の理解に向けて(2024年6月5日 第59回 NLPコロキウム)
atsumoto
0
210
この先生きのこるには
verypluming
3
4.5k
インタビューだけじゃない!ユーザーに共感しユーザーの目👀を手に入れるためのインプット
moco1013
0
430
SSII2024 [OS2] 大規模言語モデルと基盤モデルの射程
ssii
PRO
0
380
SSII2024 [TS3] 画像認識におけるマルチモーダル基盤モデル ~基盤モデル、あなたのタスクに役立つかも?~
ssii
PRO
0
810
SSII2024 [PD] 画像センシングの未来
ssii
PRO
0
290
中高生にSFを読んでもらうには
ichiiida
1
830
LINEチャットボット「全力肯定彼氏くん(LuC4)」の 1年を振り返る
o_ob
0
680
スモールデータ勉強会発表資料
natsutan
0
310
The past, present, and future of local-first
ept
0
390
第28回 著者ゼミ:Identification of drug responsible glycogene signature in liver carcinoma from meta-analysis using RNA-seq data
ktatsuya
2
200
自然言語とVision&Language
kuehara
19
4.4k
Featured
See All Featured
Optimizing for Happiness
mojombo
373
69k
Designing for humans not robots
tammielis
247
25k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
360
22k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
20
7.2k
How to Think Like a Performance Engineer
csswizardry
4
590
The Art of Programming - Codeland 2020
erikaheidi
48
13k
Embracing the Ebb and Flow
colly
81
4.3k
No one is an island. Learnings from fostering a developers community.
thoeni
17
2.8k
Leading Effective Engineering Teams 2024
addyosmani
3
300
Navigating Team Friction
lara
181
13k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
Transcript
セキュア開発の先を考える ~ある活動の中の人の私見~ IISEC Alumni Reunion 2020 2020/09/26 2014年度修士課程修了(田中研) Mutsuo Noguchi
今回お伝えしたいこと セキュア開発(SDLC:Secure Development Life Cycle)の 取り組みは形骸化との闘い Security by Design(SbD)が適用できる範囲は限定的 DevSecOpsは手段に過ぎない
システムリスクの呪縛から解放されませんか? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 1 引用元:Microsoft SDL の簡単な実装
セキュア開発とは 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 2
セキュア開発 開発プロセス(要件定義、設計、開発=コーディング)の各段階でセキュリティ対応/対策を行い、脆弱性を 作りこまないようにする考え方 参考資料 要件定義 セキュリティ要件ガイドブック 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
セキュア開発は必須 システム開発において、ユーザーとシステムベンダー間でセキュア開発の要件が契約上存在しなくても、 セキュリティ対策は実施していることが期待される 情報流出に係るシステム損害賠償請求事件(東京地裁 平成26.1.23) 判例:情報流出に係るシステム損害賠償請求事件(東京地裁 平成26.1.23) レジュメ
ご参考 システムベンダのセキュリティ対策義務~東京地裁平成26年1月23日判決(平23(ワ)32060号)を 素材として~ 武田勝弘(発表者) 成城大学法学部教授の町村 泰貴さんブログ privacy:個人情報漏洩で脆弱なシステムの責任をソフトメーカーに問う事例(追記あり): Matimulog 徳丸さんのブログ SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 4
セキュア開発の活動 以下のようにセキュア開発で実施される活動は各開発プロセスに合わせて実施される 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 5 引用元: https://www.pwc.com/jp/ja/services/digital-trust/cyber-security-consulting/product-cs/sdlc.html
セキュア開発行われていますか? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 6
こんなことを聞いたことありませんか? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 7
やらない言い訳・やったつもり セキュリティポリシーはわかったが製品へ適合する要件にまとめられない 守るべき情報が何か特定できないので、すべて同じレベルで保護機能を設計した ウチのチームはSbDの思想に則って必要な設計を行っているが隣はわからない (作成日不明の)セキュア開発の手順書に沿ってやってます バリデーションって何すればいいんですか? 要件テストで達成度合いを評価しました!(人の数だけ結果が異なる) 2020/9/26 ©2020 Mutsuo
Noguchi @vulcain 8
セキュア開発は鮮度管理が命 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 9
鮮度を維持しよう セキュリティポリシーはわかったが製品へ適合する要件にまとめられない 守るべき情報が何か特定できないので、すべて同じレベルで保護機能を設計した ウチのチームはSbDの思想に則って必要な設計を行っているが隣はわからない (作成日不明の)セキュア開発の手順書に沿ってやってます バリデーションって何すればいいんですか? 要件テストで達成度合いを評価しました!(人の数だけ結果が異なる) 2020/9/26 ©2020 Mutsuo
Noguchi @vulcain 10 製品のカテゴリ別に適合要件のベースを整理&メンテナンス 守るべき情報の導出プロセスをカテゴリ別にシンプルに整理 習熟度を不定期に測定し、チーム間の状況を見える化 手順書のメンテナンスと版管理の徹底 実装におけるフレームワークの活用&適用シーンの明確化 テストの再現性も重視したテスト作成ポリシーの整備
Security by Designを真面目に取り組もう 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 11
2020/9/26 ©2020 Mutsuo Noguchi @vulcain 12
2020/9/26 ©2020 Mutsuo Noguchi @vulcain 13
2020/9/26 ©2020 Mutsuo Noguchi @vulcain 14
そもそも設計対象はすべてコントールできてる? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 15
コントロール可能なもの スクラッチで設計/開発するプログラム 自社製ソフトウェアを活用したシステム 他社製ソフトウェアの公開仕様の範囲で利用可能な設定/機能 上記のサポート範囲で提供されるパッチ適用などの運用 2020/9/26 ©2020 Mutsuo Noguchi @vulcain
16
コントロールできる? 自社製品の『動作環境』のライフサイクル 他社製品のライフサイクル クラウドサービスのEnd of Serviceポリシー 自開発システムとクラウドサービスの通信経路 ※可能なものはある クラウドサービスの稼働環境自体 などなど
2020/9/26 ©2020 Mutsuo Noguchi @vulcain 17
SbDの適用『可能となる』範囲を意識しよう SbDの概念自体は新しくない 時代の変化(スクラッチ→既製品活用→サービス活用)に伴い、自由に手が出せる範囲も変化 利用する製品/サービスの選定時には 『自らコントロールできることが限定されていること』 を前提に選定し、 コントロール外で発生する事象はすべてリスク受容となることを理解する必要がある 2020/9/26 ©2020 Mutsuo
Noguchi @vulcain 18
DevSecOps 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 19
DevOpsにセキュリティを 要件定義から設計、実装、展開に至るDevOpsのサイクルにセキュリティを組み込んだものが DevSecOps 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 20
DevSecOps DevOpsの全プロセスでセキュリティを考慮すること 全プロセスで開発・運用・『セキュリティ』担当者が責任を共有すること 三者が連携してリスクが許容可能な範囲に留めながら、各プロセスを回すこと これらは手段でしかない 2020/9/26 ©2020 Mutsuo Noguchi @vulcain
21
DevSecOps これまでの経験で開発プロセスの中で常にセキュリティが考慮されている事例の割合は? セキュリティ担当者が開発現場で責任を担っているケースは? 開発が終わった後に保守開発要員と運用要員を残して、主要メンバーが抜けていく経験は? 手段を実践し続けるには『ヒト・モノ・カネ』の維持が必要 2020/9/26 ©2020 Mutsuo Noguchi @vulcain
22
DevSecOpsは手段に過ぎない & 実践できているところは偉大 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 23
DevSecOpsはXaaSのような クラウドネイティブなサービス運営向けアプローチ 手段=付加価値=収益源 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 24
リスクの考え方 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 25
リスクとは将来の不確実性のこと 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 26
こんな傾向ありませんか? リスクといえばネガティブなものだ システムリスクを適切に把握・管理すれば大丈夫 情報セキュリティリスクを(ry サイバーセキュリティリスクを(ry 脅威分析や脆弱性管理を(ry 2020/9/26 ©2020 Mutsuo Noguchi
@vulcain 27
エンジニアだからこそ盲目的になること リスクは脆弱性をコントロールし、脅威の発生確率を減らせば大丈夫? 仕様を確定して実装しているし、ソフトウェアのパッチ管理も適切に行っているから大丈夫! ソフトウェアのEoSより早くAPIなど機能/サービスのEoSがやってくることもある 認識できていれば、変更容易性を前提とした設計が可能だったかも? ある国で爆発的に利用者が増えているサービスを利用しよう!修正対応も早いし、安心! その国の法律でデータがある組織に流れていることもある
サービスの内容や機能だけでなく、データの所在地と経路に着目できていれば、採用を思い止まれたかも? 企画/要件定義時にリスク分析が行われているから安心して設計/開発ができる! そのリスク分析はシステムリスクやサイバーセキュリティに特化したものだったりしない? システム/サービス開発に必要な要件が見えれば、事業継続に影響する重大リスクも見えて来たかも? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 28
エンジニアだからこそ盲目的になること リスクは脆弱性をコントロールし、脅威の発生確率を減らせば大丈夫? 仕様を確定して実装しているし、ソフトウェアのパッチ管理も適切に行っているから大丈夫! ソフトウェアのEoSより早くAPIなど機能/サービスのEoSがやってくることもある 認識できていれば、変更容易性を前提とした設計が可能だったかも? ある国で爆発的に利用者が増えているサービスを利用しよう!修正対応も早いし、安心! その国の法律でデータがある組織に流れていることもある
サービスの内容や機能だけでなく、データの所在地と経路に着目できていれば、採用を思い止まれたかも? 企画/要件定義時にリスク分析が行われているから安心して設計/開発ができる! そのリスク分析はシステムリスクやサイバーセキュリティに特化したものだったりしない? システム/サービス開発に必要な要件が見えれば、事業継続に影響する重大リスクも見えて来たかも? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 29 信頼するに足る情報を揃えずに 信頼していないか?
国家の介入でビジネスの継続性が左右される世の中 リスクを適切に把握・管理するのは限界がある 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 30
エンジニアを縛る鎖 契約と契約に基づいた受注額による行動範囲指定 目の前に存在するシステム(設計図) 誰かが選定し、利用者として使うだけのサービス 上流プロセスから渡された要件定義/設計書 無慈悲に投げ掛けられる権力という名の暴力 etc 2020/9/26 ©2020 Mutsuo
Noguchi @vulcain 31
エンジニアを縛る鎖 契約と契約に基づいた受注額による行動範囲指定 目の前に存在するシステム(設計図) 誰かが選定し、利用者として使うだけのサービス 上流プロセスから渡された要件定義/設計書 無慈悲に投げ掛けられる権力という名の暴力 etc 2020/9/26 ©2020 Mutsuo
Noguchi @vulcain 32 現場のエンジニアを縛る鎖は堅い
現場エンジニアの鎖が堅いなら、 現場の外から支援すれば良いのでは? 外なら縛られないしね 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 33
Why? 契約になくても問題が発生すれば責任を問われるのは変わらない 鎖を気にせず、自らの技術・知見をぶつけてみたい しがらみに燻っているエンジニアは組織が大きいほど存在する そもそもルーチンを繰り返す作業なんて(できるだけ)したくない 既存のセキュア開発のプロセスに限界を感じている 2020/9/26 ©2020 Mutsuo Noguchi
@vulcain 34
そういう想いに応えられる組織 欲しくありませんか? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 35 https://twitter.com/sen_u/status/1309132758091026434
今回お伝えしたこと セキュア開発(SDLC:Secure Development Life Cycle)の 取り組みは形骸化との闘い Security by Design(SbD)が適用できる範囲は限定的 DevSecOpsは手段に過ぎない
システムリスクの呪縛から解放されませんか? 2020/9/26 ©2020 Mutsuo Noguchi @vulcain 36 引用元:Microsoft SDL の簡単な実装