Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Security measures required for Agile Development

Security measures required for Agile Development

Avatar for TakuyaTezuka

TakuyaTezuka

October 12, 2022
Tweet

More Decks by TakuyaTezuka

Other Decks in Technology

Transcript

  1. 自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. 自治体やデータベースマーケティング会社でのインフラ設計 /構築

    /運用を主に経験し、2018 年 10 月に 3-Shake に Join。 3-Shake Join 後は Google Cloud / AWS / kubernetes / ServiceMesh など様々な技術的アプローチを駆使し、 大手からベンチャー等規模を問わず様々な組織に対して SREのコンサルティングや実践を行っている。 趣味 : ボクシング観戦 ※ 日曜日の昼間は一人で WOWOW 見ながら一人で熱狂してます ... 手塚 卓也 Takuya Tezuka
  2. アジェンダ Copyright © 3-shake, Inc. All Rights Reserved. 1. About

    3-shake 2. 高速開発とセキュリティ対策 3. 継続的セキュリティ対策の方法 4. 継続的セキュリティの実践手法 5. まとめ
  3. 社名 設立日 代表取締役 所在地 人員(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.
  4. 事業全体像 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
  5. 本日お話する内容 Copyright © 3-shake, Inc. All Rights Reserved. Agile 開発や

    DevOps に関する概念について 高速開発に対応した継続的セキュリティ対策について Bug Bounty について 話すこと 話さないこと ゼロトラスト、SASEなど
  6. どの程度高速化されているのか ? 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/files/misc/state-of-devops-2021.pdf
  7. プロダクト全体のライフサイクル Copyright © 3-shake, Inc. All Rights Reserved. Agile 開発で解決

    DevOps で解決 Agile開発 や DevOps といった手法を使って、ビジネス推進 ~ システム開発し リリースするまでのスピードや信頼性を向上を目指す ビジネス コンセプト ビジネス 推進 システム 開発 システム 保守 市場
  8. 一方で新しい脆弱性が日々出てくる ... 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やパッケージの脆弱性は日々新しく出てくる...
  9. 脆弱性を攻撃された事例(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
  10. DX時代に起きた変化 Copyright © 3-shake, Inc. All Rights Reserved. (1)企業における変化  ・ 急速な市場変化や世の中の変化に対応する必要がある

     ・ その為ITの現場では、今まで以上に高速に開発することが求められる プロダクトの高速開発と並走したセキュリティ対策が必要。 一方でセキュリティ人材不足を感じる企業は9割以上とのデータも。 (参考)経済産業省 DXレポート2 (参考)NRI Secure Insight 2021 (2)セキュリティ対策における変化  ・ 日々出てくる新しい脆弱性に対して追随した対応
  11. 自社 プロダクト 対応①:セキュリティ対策の仕組みを導入 Copyright © 3-shake, Inc. All Rights Reserved.

    ネットワーク 攻撃 Webアプリの 脆弱性攻撃 フ ァ イ ア ウ ォ | ル I P S ・ I D S W A F ポートスキャン Dos / DDos攻撃 Synフラッド攻撃 等 SQLインジェクション クロスサイトス クリプティング等 サイト自体の弱点(脆弱性)を無くし堅牢なものにすることが重要なのでは? 防御が難しい 攻撃も多い bypass出来てしまう Log4jの脆弱性等
  12. 対応②:脆弱性診断で対応 Copyright © 3-shake, Inc. All Rights Reserved. Copyright ©

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

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

    アプリケーション コンテナサービス オープンソース ★ ★ ★ ・脆弱性混入:★部分  (アプリケーションは前ページに記載のため割愛) ① ② ③ システム構成の中で混入する脆弱性もツールなどを使い発見・修正。 CI/CDに組み込むことでさらに効率化。 ① SCA ② コンテナイメージ脆弱性スキャン (Trivyなど) ③ 脆弱設定のアセスメント、CSPM ・対策例:
  15. 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にて緊急対応を行う 定常的
  16. 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 の実現にあたってのポリシーのサンプル
  17. Copyright © 3-shake, Inc. All Rights Reserved. 残存する課題... 1. 構築

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

    3-shake, Inc. All Rights Reserved. 設計 実装 テスト リリース 企画 フェーズ② 設計 実装 テスト リリース 企画 脆弱性診断 セキュア コーディング フェーズ① 脆弱性診断 セキュア コーディング ウォーターフォールならリリースする直前や Agile開発だと、 おおよそ年に一度脆弱性診断を受診するパターンが多い ....? 大きな機能アップデートやリリース時に脆弱性診断を行うアプローチ
  19. 対応②:脆弱性診断で対応 Copyright © 3-shake, Inc. All Rights Reserved. 費用が高額になりがち 毎月・毎日のリリースに脆弱性の検査対応ができない

    この期間内での脆弱性対応が出来ていない 大きな機能アップデートやリリース時に脆弱性診断を行うアプローチ 設計 実装 テスト リリース 企画 フェーズ② 設計 実装 テスト リリース 企画 脆弱性診断 セキュア コーディング フェーズ① 脆弱性診断 セキュア コーディング
  20. 対応②:脆弱性診断で対応 Copyright © 3-shake, Inc. All Rights Reserved. 費用が高額になりがち 進化する攻撃手法/技術に対応できない(属人的)

    毎月・毎日のリリースに脆弱性の検査対応ができない 1 2 3 この期間内での脆弱性対応が出来ていない 大きな機能アップデートやリリース時に脆弱性診断を行うアプローチ 設計 実装 テスト リリース 企画 フェーズ② 設計 実装 テスト リリース 企画 脆弱性診断 セキュア コーディング フェーズ① 脆弱性診断 セキュア コーディング アジャイル開発などを通じてリリース頻度が高まる一方で 脆弱性診断の頻度は本当に定期的(1年に一度など)で良いのか? より高いセキュリティ環境の実現にはここに大きな課題がある...?
  21. 手軽に脆弱性診断 手軽に脆弱性診断 継続的セキュリティ対策を実現するためのアプローチ Copyright © 3-shake, Inc. All Rights Reserved.

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

    プロダクトに対して、手軽に、何度でも 脆弱性診断の実施を可能にし、 セキュリティレベルを可視化・DevSecOps への取り組みをサポートします。
  23. Securify で実現する 自動脆弱性診断 Copyright © 3-shake, Inc. All Rights Reserved.

    このほかにも約900項目の診断が実施可能! SQLインジェクション クロスサイト・スクリプティング (XSS) OSコマンドインジェクション クロスサイトリクエストフォージェリ (CSRF) CRLFインジェクション パストラバーサル クリックジャッキング CORSの設定不備 Hostヘッダインジェクション 混在コンテンツ プライベートIPの公開 相対パスインポート 脆弱なJavaScriptライブラリの使 用 オープンリダイレクト ポートスキャン
  24. Securify で実現する継続的セキュリティ対策 Copyright © 3-shake, Inc. All Rights Reserved. Securifyで日次や週次で継続的に脆弱性の状況をモニタリングし、

    必要に応じて対応することで、セキュリティのベースライン品質担保を実現 企画 設計 実装 テスト リリース 自動で脆弱性診断を実行し、 日次や週次で継続的に脆弱性の状況をモニタリング 開発プロセス
  25. Bug Bounty とは Copyright © 3-shake, Inc. All Rights Reserved.

    Bug Bounty = バグバウンティ(バグ報奨金制度) 自社のプロダクトをホワイトハッカーが調査し、発見・報告された 脆弱性 に対して企業から報奨金が支払われる仕組みです。
  26. なぜBug Bountyが求められるのか Copyright © 3-shake, Inc. All Rights Reserved. 世界中のホワイトハッカー

    自社エンジニア 自社プロダクトの脆弱性を世の中の知見を使って調べてもらう、という考え方がBug Bountyの背景がある(オープンソースのような考え方に近い...?) 見る範囲が違う
  27. Bug Bounty の導入事例 Copyright © 3-shake, Inc. All Rights Reserved.

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

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

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

    IAST, SCA, コンテナスキャンツールなどのツールを CI/CDツールに組み込むなどで継続的に脆弱性発見と改修を実行 世界中のホワイトハッカー Bug Bountyにより、世界中の知見を 使って様々な角度からプロダクトの脆 弱性を発見(24時間365日) CI / CD CI / CD ・・・ 設計 実装 テスト リリース 企画 設計 実装 テスト リリース 企画
  31. 最も大事なのは脆弱性に向き合い続けること Copyright © 3-shake, Inc. All Rights Reserved. 見つかる脆弱性は氷山の一角 継続的セキュリティ対策を構築して運用できても

    ゴールではない。 発見できる脆弱性は一部です。組織として 見えていない脆弱性を見つける姿勢が必要。 継続的に取り組む姿勢が、プロダクトの透明性につ ながり、お客様の信頼獲得につながる。
  32. まとめ Copyright © 3-shake, Inc. All Rights Reserved. ❖ ビジネススピードの変化に応じるために機能開発をスピーディに行う事は重要であり、

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