Security measures required for Agile Development

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. 自治体やデータベースマーケティング会社でのインフラ設計 /構築 /運用を主に経験し、2018 年 10 月に 3-Shake に Join。 3-Shake Join 後は Google Cloud / AWS / kubernetes / ServiceMesh など様々な技術的アプローチを駆使し、大手からベンチャー等規模を問わず様々な組織に対して SREのコンサルティングや実践を行っている。趣味：ボクシング観戦 ※ 日曜日の昼間は一人で WOWOW 見ながら一人で熱狂してます ... 手塚卓也 Takuya Tezuka

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

社名設立日代表取締役所在地人員（2022/1）資本金事業内容株式会社スリーシェイク 2015年1月15日吉田拓真本社：東京都新宿区大京町22-1 グランファースト新宿御苑3-4F 110名（正社員：71名、業務委託：21名、アルバイト：18名） 1億円 SREコンサルティング支援事業「Sreake」の運営セキュリティ診断サービス「Securify」の運営データ連携プラットフォーム事業「Reckoner」の運営フリーランスエンジニア紹介プラットフォーム「Relance」の運営会社概要 Copyright © 3-shake, Inc. All Rights Reserved.

Slide 6

Slide 6 text

事業全体像 07 Copyright © 3-shake, Inc. All Rights Reserved. 　　 Engineering as a Service すべてのエンジニア不足を解消する VALUE Engineering as a Service (EaaS) Application Development IaaS DevOps / SRE UIUX / Management HR（Engineer Hiring） Data Engineering Security

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

どの程度高速化されているのか ? Copyright © 3-shake, Inc. All Rights Reserved. 実際にどの程度「高速化」されているのか？ SDO (software delivery and operational (SDO) performance) エリート高中低デプロイの頻度アプリケーションコードを本番環境にデプロイ、エンドユーザーにリリースする頻度オンデマンド（1日複数回発生）週に1回から月に1回 1ヶ月から6ヶ月に1回 6ヶ月以上の間隔変更のリードタイムアプリケーションコードをコミットしてから本番で正常に稼働するまでにどれぐらいの時間がかかるか 1時間未満 1日 ~ 1週間 1ヶ月から6ヶ月の間 6ヶ月以上サービス復旧までの時間ユーザーに影響を与えるインシデントや不具合が発生した場合、サービス普及にどれぐらい時間がかかるか 1時間未満 1日未満 1日 ~ 1週間 6ヶ月以上 2021年の割合世界中の企業・Industoryから満遍なく収集したデータを元に算出 26% 40% 28% ~7% 高速に開発している企業は2021年は 66% に (出典) https://services.google.com/fh/ﬁles/misc/state-of-devops-2021.pdf

Slide 12

Slide 12 text

Slide 13

Slide 13 text

一方で新しい脆弱性が日々出てくる ... Copyright © 3-shake, Inc. All Rights Reserved. https://cybersecurity-jp.com/leakage-of-personal-information Apache Log4jの任意のコード実行の脆弱性（ CVE-2021-44228) ArgoCDのパス・トラバーサルの欠陥による脆弱性　(CVE-2022-24348) 利用しているOSSやパッケージの脆弱性は日々新しく出てくる...

Slide 14

Slide 14 text

脆弱性を攻撃された事例（2022年1月時点） Copyright © 3-shake, Inc. All Rights Reserved. 公表日企業名インシデント概要 2021/6 A社（航空）世界の航空会社の90％の通信およびITベンダーであるS社のシステムがサイバー攻撃を受け大規模な情報漏洩を起こした。A社だけでも100万件の情報漏えいが発生 2021/8 S社（通販）問い合わせフォームを運用する管理サーバが外部からの不正アクセスを受けたことにより個人情報 10万件が流出した可能性 2021/8 T社（通信）アメリカの通信会社である T社にサイバー攻撃が発生し、 5,000万人の個人情報が流出 2021/11 R社（衣料）公式オンラインショップがサイバー攻撃を受け、 27万の会員ユーザ個人情報が流出 2022/1 N社（教育）公式HPがサイバー攻撃を受け 28万件のメールアドレスが流出 https://cybersecurity-jp.com/leakage-of-personal-information

Slide 15

Slide 15 text

DX時代に起きた変化 Copyright © 3-shake, Inc. All Rights Reserved. （１）企業における変化　・　急速な市場変化や世の中の変化に対応する必要がある　・　その為ITの現場では、今まで以上に高速に開発することが求められるプロダクトの高速開発と並走したセキュリティ対策が必要。一方でセキュリティ人材不足を感じる企業は9割以上とのデータも。（参考）経済産業省 DXレポート2 （参考）NRI Secure Insight 2021 （２）セキュリティ対策における変化　・　日々出てくる新しい脆弱性に対して追随した対応

Slide 16

Slide 16 text

自社プロダクト対応①：セキュリティ対策の仕組みを導入 Copyright © 3-shake, Inc. All Rights Reserved. ネットワーク攻撃 Webアプリの脆弱性攻撃ファイアウォ｜ルＩＰＳ・ＩＤＳ W A F ポートスキャン Dos / DDos攻撃 Synフラッド攻撃等 SQLインジェクションクロスサイトスクリプティング等サイト自体の弱点(脆弱性)を無くし堅牢なものにすることが重要なのでは？防御が難しい攻撃も多い bypass出来てしまう Log4jの脆弱性等

Slide 17

Slide 17 text

対応②：脆弱性診断で対応 Copyright © 3-shake, Inc. All Rights Reserved. Copyright © 3-shake, Inc. All Rights Reserved. 設計実装テストリリース企画フェーズ② 設計実装テストリリース企画脆弱性診断セキュアコーディングフェーズ① 脆弱性診断セキュアコーディングウォーターフォールならリリースする直前や Agile開発だと、おおよそ年に一度脆弱性診断を受診するパターンが多い ....？大きな機能アップデートやリリース時に脆弱性診断を行うアプローチ実はここにも課題はあるが...

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © 3-shake, Inc. All Rights Reserved. 設計実装テストリリース企画開発プロセス（継続的）・対策例： ★ ★ （参考）DevOpsなどの言葉は使用していませんが、上図の開発プロセスを継続的に高速に回していくための考え方と考えていただければと思います。　　　　そこにセキュリティを追随させる考え方を付与したものを「 DevSecOps」と呼ぶこともあります。・脆弱性混入：★部分 ① ② ③ ④ 開発中に様々な解析ツールを使って脆弱性の発見・修正。 CI/CDに組み込むことでさらに効率化。 ★ 「開発プロセス」の中での脆弱性対策 ① セキュアコーディング ② SAST ③ DAST、IAST ④ 脆弱性診断

Slide 20

Slide 20 text

Copyright © 3-shake, Inc. All Rights Reserved. 「システム構成」の中での脆弱性対策プラットフォーム（AWS、GCPなど）アプリケーションコンテナサービスオープンソース ★ ★ ★ ・脆弱性混入：★部分　（アプリケーションは前ページに記載のため割愛） ① ② ③ システム構成の中で混入する脆弱性もツールなどを使い発見・修正。 CI/CDに組み込むことでさらに効率化。 ① SCA ② コンテナイメージ脆弱性スキャン（Trivyなど） ③ 脆弱設定のアセスメント、CSPM ・対策例：

Slide 21

Slide 21 text

DevSecOps の実現にあたってのポリシーのサンプル Copyright © 3-shake, Inc. All Rights Reserved. 領域項目ツールリリース前の実施必須実施担当者 NGの場合の対処実行頻度 App 脆弱性診断 - ○ 脆弱性診断員レポート提示後、スクラムチームにてソースコードの修正を行う年に一度 App 静的コード解析 Snyk ○ 開発チーム CIにて落とされる為、 Image Pushが不可となる定常的 App 動的解析 Securify Scan - 開発チーム CIにて落とされる為、 Image Pushが不可となる定常的 App セキュアコーディングの取り組み - - 全員 - 定常的 Infra プラットフォーム診断 - ○ SRE Firewall Ruleの修正を行う年に一度 Infra OSのCVEへの対策 Amazon Inspector ○ SRE SREにてBase Imageの更新を行う定常的 Infra Container脆弱性診断 Trivy ○ 開発チーム CIにて落とされる為、 Image Pushが不可となる定常的 Infra CISベンチマークなどOSの脆弱性対応 Amazon Inspector ○ SRE SREにてBase Imageの更新を行う年に一度 Infra Middlewareの脆弱性対策 Amazon Inspector ○ SRE SREにてBase Imageの更新を行う定常的 Infra 侵入検知・改ざん検知 CrowdStrike - SRE 検知後、CSIRTにて緊急対応を行う定常的

Slide 22

Slide 22 text

Copyright © 3-shake, Inc. All Rights Reserved. 領域項目ツールリリース前の実施必須実施担当者 NGの場合の対処実行頻度 App 静的コード解析 Snyk ○ 開發チーム CIにて落とされる為、 Image Pushが不可となる定常的 App 動的解析 Securify Scan - 開發チーム CIにて落とされる為、 Image Pushが不可となる定常的 App Application手動脆弱性検査 - ○ 脆弱性診断員レポート提示後、スクラムチームにてソースコードの修正を行う年に一度 App セキュアコーディングの取り組み - - 全員 - 定常的 Infra プラットフォーム診断 - ○ SRE Firewall Ruleの修正を行う年に一度 Infra OSのCVEへの対策 Amazon Inspector ○ SRE SREにてBase Imageの更新を行う定常的 Infra Container脆弱性診断 Trivy ○ 開發チーム CIにて落とされる為、 Image Pushが不可となる定常的 Infra CISベンチマークなどOSの脆弱性対応 Amazon Inspector ○ SRE SREにてBase Imageの更新を行う年に一度 Infra Middlewareの脆弱性対策 Amazon Inspector ○ SRE SREにてBase Imageの更新を行う定常的 Infra 侵入検知・改ざん検知 CrowdStrike - SRE 検知後、CSIRTにて緊急対応を行う定常的各種ツールをCI/CDツールに組み込む事によって、開発と同時に脆弱性の発見と改修を継続的に実行することが可能。高速開発へ追随したセキュリティ対策が可能となる!!! DevSecOps の実現にあたってのポリシーのサンプル

Slide 23

Slide 23 text

Copyright © 3-shake, Inc. All Rights Reserved. 残存する課題... 1. 構築 / 運用面での課題 ● 仕組みを検討・構築・運用する人材 ● ツールについての理解 ● 脆弱性のトリアージ一方でこれらの課題はまだ残ってしまう... 2. 脆弱性診断における頻度の問題 ● リリース後の脆弱性診断をどうするか？ → 例えば、ビジネスロジック層の診断頻度は本当に定期的 (年一回)で良いのか...？

Slide 24

Slide 24 text

Slide 25

Slide 25 text

対応②：脆弱性診断で対応 Copyright © 3-shake, Inc. All Rights Reserved. 費用が高額になりがち毎月・毎日のリリースに脆弱性の検査対応ができないこの期間内での脆弱性対応が出来ていない大きな機能アップデートやリリース時に脆弱性診断を行うアプローチ設計実装テストリリース企画フェーズ② 設計実装テストリリース企画脆弱性診断セキュアコーディングフェーズ① 脆弱性診断セキュアコーディング

Slide 26

Slide 26 text

対応②：脆弱性診断で対応 Copyright © 3-shake, Inc. All Rights Reserved. 費用が高額になりがち進化する攻撃手法／技術に対応できない（属人的）毎月・毎日のリリースに脆弱性の検査対応ができない１２３この期間内での脆弱性対応が出来ていない大きな機能アップデートやリリース時に脆弱性診断を行うアプローチ設計実装テストリリース企画フェーズ② 設計実装テストリリース企画脆弱性診断セキュアコーディングフェーズ① 脆弱性診断セキュアコーディングアジャイル開発などを通じてリリース頻度が高まる一方で脆弱性診断の頻度は本当に定期的(1年に一度など)で良いのか？より高いセキュリティ環境の実現にはここに大きな課題がある...?

Slide 27

Slide 27 text

Slide 28

Slide 28 text

手軽に脆弱性診断手軽に脆弱性診断継続的セキュリティ対策を実現するためのアプローチ Copyright © 3-shake, Inc. All Rights Reserved. セキュリティツールで手軽にセキュリティ診断し、SaaS利用からリスクを無くす。脆弱性診断ツール 4万人のバグハンターによる世界レベルでのセキュリティ・サービス品質を実現します。バグバウンティ運用代行サービス開発フローの中で自動での脆弱性診断を高い頻度で行う「自動化」や実質「無限のリソース」を活用して脆弱性と向き合っていく世界中のホワイトハッカーの知見を活用してより高度なセキュリティレベルを実現する４万人のバグハンターと連携

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Securify で実現する自動脆弱性診断 Copyright © 3-shake, Inc. All Rights Reserved. このほかにも約900項目の診断が実施可能！ SQLインジェクションクロスサイト・スクリプティング（XSS） OSコマンドインジェクションクロスサイトリクエストフォージェリ（CSRF） CRLFインジェクションパストラバーサルクリックジャッキング CORSの設定不備 Hostヘッダインジェクション混在コンテンツプライベートIPの公開相対パスインポート脆弱なJavaScriptライブラリの使用オープンリダイレクトポートスキャン

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Bug Bounty の導入事例 Copyright © 3-shake, Inc. All Rights Reserved. ◯海外事例：　Facebook、Microsoft、Google、TikTok（ByteDance）、米国国防総省、　スターバックス、Uberなど世界的なIT企業から、政府機関、飲食店まで幅広く導入されています。 ◯国内事例：　任天堂、サイボウズ、ピクシブ、 LINEなどが利用しています。　（日本での事例は非常に少ない状態です。公開事例も実績もともに少ないです） ◯金融事例：　高いセキュリティが求められる金融系の企業では、 DZ BANK（ドイツ第二位の銀行）、　ビットバンクなどがバグバウンティを利用しています。 ◯コロナ禍における事例：　Zoom社は新型コロナウイルス感染症対策の影響により利用が急増、セキュリティ強化圧が　高まったことを受けて、 2020年4月にバグバウンティプログラムを開始しました。

Slide 35

Slide 35 text

Tech Giants でもバグバウンティを行う理由 Copyright © 3-shake, Inc. All Rights Reserved. ・自社に優れた開発者がいても脆弱性は無くならない・脆弱性を攻撃された時の回復費用と比較してリーズナブル・Googleは、バグバウンティプログラムの開始から10年で　合計11,055のバグが見つかり、2,022のバグハンターに　報奨金が支払われました（合計3,000万ドル近く） Tech Giants も日々脆弱性と向き合っている

Slide 36

Slide 36 text

Bug Bounty のメリット Copyright © 3-shake, Inc. All Rights Reserved. ① 世界中の高度な技術を持つセキュリティ専門家が攻撃者目線で脆弱性を　発見するため、より多角的な視点での脆弱性発見が期待できます。 ② 特定の期間ではなく、24時間365日脆弱性の調査が継続されます。 ③ 高速開発に追随して脆弱性の調査をしてくれます。 ④ 完全にクローズドな状態でBug Bountyを開始することが可能です。 ⑤ 脆弱性への対応状況をオープンにすることで企業に対する透明性が増し、　安心感と誠実なイメージの提供が見込めます。

Slide 37

Slide 37 text

なぜBug Bountyが求められるのか Copyright © 3-shake, Inc. All Rights Reserved. SAST, IAST, SCA, コンテナスキャンツールなどのツールを CI/CDツールに組み込むなどで継続的に脆弱性発見と改修を実行世界中のホワイトハッカー Bug Bountyにより、世界中の知見を使って様々な角度からプロダクトの脆弱性を発見（24時間365日） CI / CD CI / CD ・・・設計実装テストリリース企画設計実装テストリリース企画

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

まとめ Copyright © 3-shake, Inc. All Rights Reserved. ❖ ビジネススピードの変化に応じるために機能開発をスピーディに行う事は重要であり、 Agile開発は手法として有効である。一方でセキュリティ対策も避けては通れない。 ❖ DevSecOps、自動での脆弱性診断、 Bug Bounty などのアプローチによって絶えず変化するシステムに対して追随が出来る継続的セキュリティ対策を実現しよう。 ❖ 脆弱性への対応は向き合い「続ける」事が何よりも重要。何かツールを入れればとか、一度実施すれば終わりとかではなく、組織的に常に脆弱性と向き合い続けていこう。