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

クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題

 クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題

参考書籍
コンテナセキュリティ
https://amzn.asia/d/iOkwv1K

参考URL
米カーネギーメロン大学ソフトウェア工学研究所公開のオリジナル論文 https://resources.sei.cmu.edu/asset_files/WhitePaper/2021_019_001_653461.pdf

Source Code Analysis Tools
https://owasp.org/www-community/Source_Code_Analysis_Tools

Takashi Yamaguchi

February 20, 2024
Tweet

More Decks by Takashi Yamaguchi

Other Decks in Technology

Transcript

  1. 株式会社 Gunosy テクノロジー本部 プロダクト開発部 SREチーム マネージャー 山口 隆史 <YAMAGUCHI Takashi>

    2024年2月21日(水) クラウドセキュリティの技術選択と、セキュリティ対応してい く中で出て来た課題
  2. (C) Gunosy Inc. All Rights Reserved. PAGE | 2 エレベーターピッチ

    [セキュリティに興味がある人]、 [セキュリティをこれから始めたい人]向けに発表する [クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た 課題]は [現場の泥臭い話]です これは[大きくない開発組織でのセキュリティ対応の現場での実践に基づい て構成しているため、現実感]があり これまでの成功事例やベンダーのセールス資料とは違って [ツールの限界と、ツールを導入してから定常運用に至るまでの活動に焦 点をあてている]
  3. (C) Gunosy Inc. All Rights Reserved. PAGE | 3 終了後に狙う状態

    論理面 - セキュリティ対策を現場に適用して、理想的な運用状態になるまでに発生 する・した課題が理解できる - セキュリティツールを導入したら解決できる問題、解決できない問題が理解 できる 感情面 - セキュリティ対策に興味を持ってやってみようと思える
  4. (C) Gunosy Inc. All Rights Reserved. PAGE | 5 自己紹介

    氏名:山口隆史(やまぐちたかし) 所属:株式会社Gunosy テクノロジー本部 プロダクト開発部 SREチーム マネージャー 業務:コンサルティング SREとしての活動 略歴:フリーランス、SIer等を渡り歩く→現職(2022/01〜) 自称:Security Hub芸人 好きなAWSサービス:Security Hub、GuardDuty、サポート 他:AWS Community Builder(Security & Identity)、JAWS-UG千葉支部運営、   Snyk Ambassador 第022587号
  5. (C) Gunosy Inc. All Rights Reserved. PAGE | 6 株式会社Gunosy

    ギリシャ語で「知識」を意味する「Gnosis(グノーシス)」+「u(“you”)」 「”Gnosis” for “you”」あなたのための知識  =情報を届けるサービスを提供し続ける、という意味 ▪ 2012年11月創業 ▪ 2015年4月東証マザーズ上場 ▪ 2017年12月東証第一部に市場変更 ▪ 2022年4月東京証券取引所の市場一部からプライム市場に移行 ▪ 従業員数 252名 (2023年5月末現在 連結ベース) ▪ 事業内容 – 情報キュレーションサービスその他メディアの開発及び運営 ▪ 提供サービス  グノシー、ニュースパス、 auサービスToday、 企業理念「情報を世界中の人に最適に届ける」
  6. (C) Gunosy Inc. All Rights Reserved. PAGE | 8 アジェンダ

    話すこと • Gunosyがセキュリティ対応を始めた背景 • Gunosyの開発体制 • クラウドセキュリティ対応で求められる内容とは • セキュリティツールの技術選定 • どんな感じで導入していったか • セキュリティ対応で出てきた課題と脆弱性への向き合い方 • こうやればうまく導入できそう • 今後の展望 • まとめ
  7. (C) Gunosy Inc. All Rights Reserved. PAGE | 10 セキュリティ対策に対する優先度が上がった

    キッカケはLog4j問題での対応 - ヤバめの脆弱性情報は個人がTwitter等で拾ってくる体制だった - Log4jはこれで拾えたが取りこぼしがあると致命的 - 調査が人力総力戦だったので、もうやりたくない 定期的・自動的にスキャンして継続的に潰していくサイクルにしたい - セキュリティの設計への組み込みはベストプラクティスに従って対応してい たが、レビュワー、実装者の個人のスキル任せになっていた
  8. (C) Gunosy Inc. All Rights Reserved. PAGE | 11 自動でスキャンして継続的に潰すサイクルを回したい

    [定期・自動] スキャン DBとの照合 トリアージ 対応 なんかやばいぞってな る 急いで調査 対応 As-Is To-Be
  9. (C) Gunosy Inc. All Rights Reserved. PAGE | 14 WebP問題の時のGunosyの対応状況

    ▪ 9/28 20時 – SnykさんからWebPの0-Day攻撃の案内あり – blog記事を確認して、Gunosyでの影響範囲を軽く確認 ▪ 9/29 – 30分くらいでSnykダッシュボードでCVEを検索してスプシで対応 リストを作成 – チーム別に担当を振り分けして全体アナウンス • 各チームでスプシから使用していないリポジトリをフィルタ ▪ 10/13 – 2週間くらいで主要な範囲について対応完了
  10. (C) Gunosy Inc. All Rights Reserved. PAGE | 15 WebP問題の時のGunosyの対応状況

    ▪ 9/28 20時 – SnykさんからWebPの0-Day攻撃の案内あり – blog記事を確認して、Gunosyでの影響範囲を軽く確認 ▪ 9/29 – 30分くらいでSnykダッシュボードでCVEを検索してスプシで対 応リストを作成 – チーム別に担当を振り分けして全体アナウンス • 各チームでスプシから使用していないリポジトリをフィルタ ▪ 10/13 – 2週間くらいで主要な範囲について対応完了 ここがもの すごく早くな りました
  11. (C) Gunosy Inc. All Rights Reserved. PAGE | 17 Gunosyの組織体制

    グノシー ニュースパス au サービス Today 広告配信 グノシー 開発チーム 機械学習チーム ニュースパス 開発チーム au サービス Today 開発チーム 広告配信 開発チーム SREチーム ストリームア ラインド コンプリケイ テッドサブシ ステム イネイブリン グ
  12. (C) Gunosy Inc. All Rights Reserved. PAGE | 18 Gunosyの組織体制

    グノシー ニュースパス au サービス Today 広告配信 グノシー 開発チーム 機械学習チーム ニュースパス 開発チーム au サービス Today 開発チーム 広告配信 開発チーム SREチーム それぞれ 5名前後 10名規模 2名
  13. (C) Gunosy Inc. All Rights Reserved. PAGE | インフラ運用 19

    Gunosyでの開発チームとSREとの責任分担 アプリ開発 アプリ運用 オンコール対応 セキュリティ・脆弱性対応 CI/CD運用 障害対応(ポストモーテム) 自動化・標準化 全社的なガードレール運用 SLOふりかえりの実施 開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化 ができている状態 SRE 「開発チームが 新たなプロ ダクト価値の創造 に集中 できる状態を作る」がミッ ション セキュリティ環境整備 セキュリティ・脆弱性のトリアージ モニタリング設定 ECS・EKS運用 EKS VersionUP コスト管理
  14. (C) Gunosy Inc. All Rights Reserved. PAGE | インフラ運用 20

    Gunosyでの開発チームとSREとの責任分担 アプリ開発 アプリ運用 オンコール対応 セキュリティ・脆弱性対応 CI/CD運用 障害対応(ポストモーテム) 自動化・標準化 全社的なガードレール運用 SLOふりかえりの実施 開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化 ができている状態 SRE 「開発チームが 新たなプロ ダクト価値の創造 に集中 できる状態を作る」がミッ ション セキュリティ環境整備 セキュリティ・脆弱性のトリアージ モニタリング設定 ECS・EKS運用 EKS VersionUP コスト管理
  15. (C) Gunosy Inc. All Rights Reserved. PAGE | 21 Gunosyでの開発チームとSREとの責任分担

    チーム 責任範囲 開発チーム • セキュリティ・脆弱性への対応 SREチーム • セキュリティ環境整備 • セキュリティ・脆弱性のトリアージ  (と対応依頼(チケット起票))
  16. (C) Gunosy Inc. All Rights Reserved. PAGE | 22 Gunosyでの開発チームとSREとの責任分担

    チーム 責任範囲 開発チーム • セキュリティ・脆弱性への対応 SREチーム • セキュリティ環境整備 • セキュリティ・脆弱性のトリアージ  (と対応依頼(チケット起票)) お膳立てして ケツ叩く係
  17. (C) Gunosy Inc. All Rights Reserved. PAGE | 25 セキュリティの原則

    出典: コンテナセキュリティ P.32-33 ▪ 最小権限 – 処理を実行するのに最小の権限に制限する ▪ 多層防御 – 攻撃者がある防御を突破できても別のレイヤー防ぐ ▪ 攻撃対象領域の縮小(アタックサーフェースの縮小) – システムの複雑さを解消することで、攻撃しにくくする ▪ 影響範囲の制限 – 小さなコンポーネントに分割して、最悪の事態発生時の影響を限定的にする ▪ 職務分掌 – 異なるコンポーネントに対して、可能な限り最小限の権限のみを与える
  18. (C) Gunosy Inc. All Rights Reserved. PAGE | 26 セキュリティの原則

    出典: コンテナセキュリティ P.32-33 ▪ 最小権限 – 処理を実行するのに最小の権限に制限する ▪ 多層防御 – 攻撃者がある防御を突破できても別のレイヤー防ぐ ▪ 攻撃対象領域の縮小(アタックサーフェースの縮小) – システムの複雑さを解消することで、攻撃しにくくする ▪ 影響範囲の制限 – 小さなコンポーネントに分割して、最悪の事態発生時の影響を限定的にする ▪ 職務分掌 – 異なるコンポーネントに対して、可能な限り最小限の権限のみを与える ここを深堀りし ます
  19. (C) Gunosy Inc. All Rights Reserved. PAGE | 28 クラウド環境でのレイヤー別のセキュリティ

    レイヤー テスト内容 手法 ツール アプリケーション コードの脆弱性 SAST Snyk Code OSSライブラリの脆弱性 SCA Snyk OSS, Trivy, dependabot Base Image OSSライブラリの脆弱性 SCA Snyk Container, Trivy, Aqua Dockerfile 機密情報、特権等 Snyk Container, Dockle, Trivy, Aqua オーケストレーター ミスコンフィグ CWPP Snyk Cloud, Aqua ランタイムセキュリティ DAST Falco, Sysdig, GuardDuty ホストOS ハードニング、OS脆弱性 CWPP Inspector, Security Hub クラウド環境 ミスコンフィグ CSPM Security Hub 出典: https://owasp.org/www-community/Source_Code_Analysis_Tools
  20. (C) Gunosy Inc. All Rights Reserved. PAGE | 29 クラウド環境でのレイヤー別のセキュリティ

    レイヤー テスト内容 手法 ツール アプリケーション コードの脆弱性 SAST Snyk Code OSSライブラリの脆弱性 SCA Snyk OSS, Trivy, dependabot Base Image OSSライブラリの脆弱性 SCA Snyk Container, Trivy Dockerfile 機密情報、特権等 Snyk Container, Dockle, Trivy, Aqua オーケストレーター ミスコンフィグ CWPP Snyk Cloud, Aqua ランタイムセキュリティ DAST Falco, Sysdig, GuardDuty ホストOS ハードニング、OS脆弱性 CWPP Inspector, Security Hub クラウド環境 ミスコンフィグ CSPM Security Hub 全てのレイヤで なんらかのリスク軽 減対策が必要 (多層防御)
  21. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 31

    Gunosyのデプロイパイプラインの一例 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS EC2 Fargate
  22. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 33

    Gunosyのデプロイパイプラインの一例 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS EC2 Fargate 全ての段階で なんらかのリスク軽減対 策が必要 (多層防御)
  23. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 34

    クラウドセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 開発者の手元でスキャ ン (コード、OSS、ライセ ンス、Dockerfile、マ ニュフェスト)
  24. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 35

    クラウドセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ PR作成時に差分スキャ ン (コード、OSS、ライセン ス、Dockerfile) 定期的自動的にスキャ ン (コード、OSS、ライセン ス、Dockerfile)
  25. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 36

    クラウドセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions Argo CD ビルドした成果物をス キャン (コード、OSS、ライセン ス、Dockerfile、マニュ フェスト)
  26. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 37

    クラウドセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub 定期的自動的にスキャ ン (コード、OSS、ライセン ス、Dockerfile)
  27. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 38

    クラウドセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS マニュフェストを スキャン 使用Imageをス キャン
  28. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 39

    クラウドセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS EC2 Fargate ワークロード保護 ランタイム保護 ミスコンフィグの検知、 修正
  29. (C) Gunosy Inc. All Rights Reserved. PAGE | 42 Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector GuardDuty Security Hub Inspector Inspector Inspector GuardDuty Security Hub Inspector GuardDuty Security Hub Security Lake
  30. (C) Gunosy Inc. All Rights Reserved. PAGE | 43 Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 この時は何も使 用していません
  31. (C) Gunosy Inc. All Rights Reserved. PAGE | 44 Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector GuardDuty Security Hub Inspector できるだけAWSに 寄せる感じで選定 とりあえずスキャン してみた感じ CIS Benchmark準拠 Security Hubに送れる
  32. (C) Gunosy Inc. All Rights Reserved. PAGE | 45 Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector Inspector GuardDuty Security Hub reviewdog+OSSでの スキャンを試したが、 Snykの標準機能のPR チェックで充足できた WebUIで全社統一 ルールを作れる
  33. (C) Gunosy Inc. All Rights Reserved. PAGE | 46 Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector GuardDuty Security Hub Security Lake Tagでの絞り込み ができないので Snykを採用 VSCode拡張 強力なサジェスト機 能 PRチェック Security Hubのダッシュ ボードが使いにくいので Security Lake+QuickSight で自作 Inspectorのダッシュボー ドでトリアージができな かったのでSnykを採用 Snykのダッシュボードがいい感じ だったのでクラウドセキュリティも Snykにしようかと検討したが、コス ト面で断念
  34. (C) Gunosy Inc. All Rights Reserved. PAGE | 47 Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector GuardDuty Security Hub Security Lake Tagでの絞り込み ができないので Snykを採用 VSCode拡張 強力なサジェスト機 能 PRチェック Security Hubのダッシュ ボードが使いにくいので Security Lake+QuickSight で自作 Inspectorのダッシュボー ドでトリアージができな かったのでSnykを採用 Snykのダッシュボードがいい感じ だったのでクラウドセキュリティも Snykにしようかと検討したが、コス ト面で断念 ダッシュボード大事です!
  35. (C) Gunosy Inc. All Rights Reserved. PAGE | 49 脆弱性の一覧表示

    ▪ ダッシュボードで脆弱性の一覧表示が できる – Severity毎の件数 • リポジトリ単位 • パッケージマネージャ単位 – CVE単位での検索
  36. (C) Gunosy Inc. All Rights Reserved. PAGE | 50 Snykの修正方法サジェスト

    ▪ 脆弱性の修正方法のSuggest – Base Imageを更新したらどれくら い脆弱性が減るか – 脆弱性の修正方法 イチオシ機能
  37. (C) Gunosy Inc. All Rights Reserved. PAGE | 51 修正PR

    ▪ 脆弱性の修正PRが出せる – 手動でPRが出せる – AutoFixでPRも出せる
  38. (C) Gunosy Inc. All Rights Reserved. PAGE | 52 PRチェック

    ▪ SnykにImportして一括設定するだけで自動PRチェックができる – requiredにするとSnykが止まったらMergeできなくなるので注意
  39. (C) Gunosy Inc. All Rights Reserved. PAGE | 55 セキュリティ対策ツール導入の流れ

    ▪ ツールの調査 – 対応できる範 囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策 の必要性を幹 部に理解しても らう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルー ルを決める – 全リポジトリの 優先度を決め る ▪ 全チーム・リポジトリ に展開 – 優先順位に従っ て脆弱性を対応 していく ▪ 並行してトリアージ の省力化に取り組む ▪ (通知+)定期棚卸 し運用に切り替え 運用 導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月 事前調査と社内調整 1ヶ月
  40. (C) Gunosy Inc. All Rights Reserved. PAGE | 56 セキュリティ対策ツール導入の流れ

    ▪ ツールの調査 – 対応できる範 囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策 の必要性を幹 部に理解しても らう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルー ルを決める – 全リポジトリの 優先度を決め る ▪ 全チーム・リポジトリ に展開 – 優先順位に従っ て脆弱性を対応 していく ▪ 並行してトリアージ の省力化に取り組む ▪ (通知+)定期棚卸 し運用に切り替え 運用 導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月 事前調査と社内調整 1ヶ月 PoCから運用までを、それぞれの導入フェーズで繰り返していく 本番環境への導入 IaCの導入 Codeスキャンの導入
  41. (C) Gunosy Inc. All Rights Reserved. PAGE | 57 (再掲)Security系利用サービスの移り変わり

    フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector GuardDuty Security Hub Inspector Inspector Inspector GuardDuty Security Hub Inspector GuardDuty Security Hub Security Lake
  42. (C) Gunosy Inc. All Rights Reserved. PAGE | 58 セキュリティ対策ツール導入の流れ 大事なこと!

    ▪ ツールの調査 – 対応できる範 囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策 の必要性を幹 部に理解しても らう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルー ルを決める – 全リポジトリの 優先度を決め る ▪ 全チーム・リポジトリ に展開 – 優先順位に従っ て脆弱性を対応 していく ▪ 並行してトリアージ の省力化に取り組む ▪ (通知+)定期棚卸 し運用に切り替え 運用 導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月 事前調査と社内調整 1ヶ月 有償ツールを使用している場合、 コスト削減を求められるタイミングで ツールを削ることを求められるので、 役員レベルに念押ししておくことが大事!
  43. (C) Gunosy Inc. All Rights Reserved. PAGE | 61 導入フェーズの課題

    ▪ 初期導入時の大量の脆弱性への対応 ▪ 脆弱性へ優先順位付けはどうやるか(クラウド) ▪ 脆弱性へ優先順位付けはどうやるか(コンテナ) ▪ 脆弱性への対応の追跡がつらい(コンテナ)
  44. (C) Gunosy Inc. All Rights Reserved. PAGE | 63 初期導入時の大量の脆弱性への対応

    ▪ 初期導入時に脆弱性が大量に検出される – 優先順位を付けて順次対応していくしかない • internet-facing / internal(攻撃面) • 攻撃コードの公開有無 • 脆弱性の重大度 • 攻撃された際の業務影響 引用 米カーネギーメロン大学ソフトウェア工学研究所公開のオリジナル論文より https://resources.sei.cmu.edu/asset_files/WhitePaper/2021_019_001_653461.pdf

  45. (C) Gunosy Inc. All Rights Reserved. PAGE | 64 初期導入時の大量の脆弱性への対応

    ▪ 初期導入時に脆弱性が大量に検出される – 優先順位を付けて順次対応していく必要がある (これは初期導入後の運用時も必要) • internet-facing / internal • 攻撃コードの公開有無 • 脆弱性の重大度 • 攻撃された際の業務影響 ▪ なぜ必要なのか? – 全部対応してくださいだと拒絶が先に来てしまう • 優先順位をつけて対応していくことで、開発チーム側の理解を得やすい – リスク✖業務影響で影響が大きいところから対応するのがコスパが良い
  46. (C) Gunosy Inc. All Rights Reserved. PAGE | 65 脆弱性へ優先順位付けはどうやるか(クラウド)

    ▪ クラウドセキュリティの場合は、基本的にCritical、High指摘は対応が必要
  47. (C) Gunosy Inc. All Rights Reserved. PAGE | 66 脆弱性へ優先順位付けはどうやるか(クラウド)

    ▪ クラウドセキュリティの場合は、基本的にCritical、High指摘は対応が必要 ▪ しかし指摘全てを対応する必要はない – 自社の運用に合わない指摘もあるので、指摘の内容とそのリスクを理解し た上で対応しない判断(リスクを軽減した上での受容)も必要になる – この辺りの判断がつかないときは利用しているクラウドベンダーのセキュリ ティに詳しいパートナー等への相談が良さそう
  48. (C) Gunosy Inc. All Rights Reserved. PAGE | 67 脆弱性へ優先順位付けはどうやるか(コンテナ)

    ▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる(すご い便利)
  49. (C) Gunosy Inc. All Rights Reserved. PAGE | 68 脆弱性へ優先順位付けはどうやるか(コンテナ)

    ▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる(すごい 便利) ▪ しかし – リポジトリ・Imageが以下のどれに該当するかはアーキテクチャ図、関係者 へのヒアリング等であらかじめ把握しておく必要がある • Internet-facing / Intenal • 攻撃された際の業務影響
  50. (C) Gunosy Inc. All Rights Reserved. PAGE | 69 脆弱性へ優先順位付けはどうやるか(コンテナ)

    ▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる(すごい 便利) ▪ しかし – リポジトリ・Imageが以下のどれに該当するかはアーキテクチャ図、関係者 へのヒアリング等であらかじめ把握しておく必要がある • Internet-facing / Intenal • 攻撃された際の業務影響 ▪ 上記の情報を一覧表で整理した上で、Snyk WebUIかREST APIでタグをつけて いく
  51. (C) Gunosy Inc. All Rights Reserved. PAGE | 70 脆弱性への対応の追跡がつらい(コンテナ)

    ▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票 する – しかしSnykの機能でサポートされているのは脆弱性単位のJIRAチケット起票
  52. (C) Gunosy Inc. All Rights Reserved. PAGE | 71 脆弱性への対応の追跡がつらい(コンテナ)

    ▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票 する – しかしSnykの機能でサポートされているのは脆弱性単位のJIRAチケット起票 ▪ Why – 特に初期導入時の脆弱性消し込み段階だと、脆弱性単位だと大量にJIRAチ ケットが発生する • 開発チームの拒絶反応に直結してしまう
  53. (C) Gunosy Inc. All Rights Reserved. PAGE | 72 脆弱性への対応の追跡がつらい(コンテナ)

    ▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票 する – しかしSnykの機能でサポートされているのは脆弱性単位のJIRAチケット起票 ▪ Why – 特に初期導入時の脆弱性消し込み段階だと、脆弱性単位だと大量にJIRAチ ケットが発生する – 開発チームの拒絶反応に直結してしまう ▪ 脆弱性が消し込み終わった段階で、脆弱性単位のJIRAチケット起票に切り替え る (まだできてません)
  54. (C) Gunosy Inc. All Rights Reserved. PAGE | 73 導入フェーズの課題(再掲)

    ▪ 初期導入時の大量の脆弱性への対応 ▪ 脆弱性へ優先順位付けはどうやるか(クラウド) ▪ 脆弱性へ優先順位付けはどうやるか(コンテナ) ▪ 脆弱性への対応の追跡がつらい(コンテナ)
  55. (C) Gunosy Inc. All Rights Reserved. PAGE | 75 運用フェーズの課題

    ▪ 脆弱性検知時に通知するとうるさい(クラウド) ▪ トリアージが手間(コンテナ) ▪ トリアージが手間(コンテナ)その2 ▪ 脆弱性を修正してもゼロにならない(コンテナ) ▪ Shift-leftしてもright側のスキャンと対応も必要 ▪ 本番環境とソースリポジトリで指摘が違う
  56. (C) Gunosy Inc. All Rights Reserved. PAGE | 76 脆弱性検知時に通知するとうるさい(クラウド)

    ▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る
  57. (C) Gunosy Inc. All Rights Reserved. PAGE | 77 脆弱性検知時に通知するとうるさい(クラウド)

    ▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生し にくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない
  58. (C) Gunosy Inc. All Rights Reserved. PAGE | 78 脆弱性検知時に通知するとうるさい(クラウド)

    ▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生し にくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない ▪ Gunosyの場合は、CIでのIaCチェック運用をした上で週次でSecurity Lakeの ダッシュボードを確認 – 新しい脆弱性があればリソースを確認 – 既知の脆弱性で対応されていないものはSLOふりかえりで確認 これくらいのゆるい運用をしています
  59. (C) Gunosy Inc. All Rights Reserved. PAGE | 79 脆弱性検知時に通知するとうるさい(クラウド)

    ▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生し にくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない ▪ Gunosyの場合は、CIでのIaCチェック運用をした上で週次でSecurity Lakeの ダッシュボードを確認 – 新しい脆弱性があればリソースを確認 – 既知の脆弱性で対応されていないものはSLOふりかえりで確認 これくらいのゆるい運用をしています ▪ GuardDutyは通知運用が必要で、通知された場合は即時調査・対応が基本で す!
  60. (C) Gunosy Inc. All Rights Reserved. PAGE | 80 トリアージが手間(コンテナ)

    ▪ 当初は、Internet-facingかどうか、Severity(Critical、Highを対象)、攻撃コード の有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを 判断 Critical+攻撃コードあ り それ以外 Internet-f acing できるだけ早く対応 四半期を目処に対 応 それ以外 1ヶ月以内を目処に 対応 任意のタイミング で対応
  61. (C) Gunosy Inc. All Rights Reserved. PAGE | 81 トリアージが手間(コンテナ)

    ▪ 当初は、Internet-facingかどうか、Severity(Critical、Highを対象)、攻撃コード の有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判 断 ▪ トリアージはSREの責務 – SREは2名 – Highレベルまで追跡すると数が多すぎてトリアージが回らなくなった
  62. (C) Gunosy Inc. All Rights Reserved. PAGE | 82 トリアージが手間(コンテナ)

    ▪ 当初は、Internet-facingかどうか、Severity(Critical、Highを対象)、攻撃コード の有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判 断 ▪ トリアージはSREの責務 – SREは2名 – Highレベルまで追跡すると数が多すぎてトリアージが回らなくなった ▪ トリアージ対象をCritical(+攻撃コードあり)に絞り込んだ – セキュリティリスクとトリアージ工数を検討して決断
  63. (C) Gunosy Inc. All Rights Reserved. PAGE | 83 トリアージが手間(コンテナ)その2

    ▪ 対応しない方向に倒す目的で、CVEの詳細まで確認してトリアージすると手間が かかりすぎる – このCVEは攻撃条件がXXXで、このライブラリをそういう使い方はしていな いから対応しなくてヨシ! – ライブラリの脆弱性指摘はあるけどアプリケーションで使ってないから対応し なくてヨシ!
  64. (C) Gunosy Inc. All Rights Reserved. PAGE | 84 トリアージが手間(コンテナ)その2

    ▪ 対応しない方向に倒す目的で、CVEの詳細まで確認してトリアージすると手間が かかりすぎる – このCVEは攻撃条件がXXXで、このライブラリをそういう使い方はしていな いから対応しなくてヨシ! – ライブラリの脆弱性指摘はあるけどアプリケーションで使ってないから対応し なくてヨシ! ▪ 対応の考え方としては – やらない理由をこねくり回すよりは、脆弱性指摘があれば対応する方が前向 きで健康的 • 重要なのは、Base Image、ライブラリをシュッと差し替えられるCI/CDを 整備したり、テストを回せる開発体制を作ること
  65. (C) Gunosy Inc. All Rights Reserved. PAGE | 85 トリアージが手間(コンテナ)その2

    ▪ 対応しない方向に倒す目的で、CVEの詳細まで確認してトリアージすると手間が かかりすぎる – このCVEは攻撃条件がXXXで、このライブラリをそういう使い方はしていな いから対応しなくてヨシ! – ライブラリの脆弱性指摘はあるけどアプリケーションで使ってないから対応し なくてヨシ! ▪ 対応の考え方としては – やらない理由をこねくり回すよりは、脆弱性指摘があれば対応する方が前向 きで健康的 • 重要なのは、Base Image、ライブラリをシュッと差し替えられるCI/CDを 整備したり、テストを回せる開発体制を作ること ▪ CI/CD、テスト周りは開発生産性の文脈でも大事になってくるので、普段からの 足回り整備がセキュリティ対応にも効いてきます
  66. (C) Gunosy Inc. All Rights Reserved. PAGE | 86 脆弱性を修正してもゼロにならない(コンテナ)

    ▪ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロ になりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性
  67. (C) Gunosy Inc. All Rights Reserved. PAGE | 87 脆弱性を修正してもゼロにならない(コンテナ)

    ▪ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロ になりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性 ▪ 向き合い方としては、デプロイ完了時点で検出がゼロになることを目指さない – 受容可能な範囲までリスクを軽減するのが目的なので、検出ゼロを目指さな くても達成可能 • 軽減策がとれる場合は積極的にとりましょう
  68. (C) Gunosy Inc. All Rights Reserved. PAGE | 88 脆弱性を修正してもゼロにならない(コンテナ)

    ▪ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロ になりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性 ▪ 向き合い方としては、デプロイ完了時点で検出がゼロになることを目指さない – 受容可能な範囲までリスクを軽減するのが目的なので、検出ゼロを目指さな くても達成可能 • 軽減策がとれる場合は積極的にとりましょう ▪ 具体的には、以下のような対応を段階的に行う – BaseImageを更新する • マイナーバージョンアップだと影響が少ない – Critical(+攻撃コードあり)の脆弱性だけ対応する
  69. (C) Gunosy Inc. All Rights Reserved. PAGE | 89 Shift-leftしてもright側のスキャンと対応も必要

    ▪ 対象 – 現在動いている本番環境 ▪ 目的 – 本番環境でのセキュリティ リスク確認 ホスト・基盤 オーケスト レーター レジストリ CI/CD 開発 ▪ 対象 – 本番環境にデプロイするア プリ・環境 ▪ 目的 – 本番環境に脆弱性がある アプリ・環境がデプロイされ ないようにする Shift-Left 現実世界 これから起きる未来
  70. (C) Gunosy Inc. All Rights Reserved. PAGE | 90 Shift-leftしてもright側のスキャンと対応も必要

    ▪ 対象 – 現在動いている本番環境 ▪ 目的 – 本番環境でのセキュリティ リスク確認 ホスト・基盤 オーケスト レーター レジストリ CI/CD 開発 ▪ 対象 – 本番環境にデプロイするア プリ・環境 ▪ 目的 – 本番環境に脆弱性がある アプリ・環境がデプロイされ ないようにする Shift-Left 現実世界 これから起きる未来 目的も対象も 異なるので 両方必要!
  71. (C) Gunosy Inc. All Rights Reserved. PAGE | 91 本番環境とソースリポジトリで指摘が違う

    ▪ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される
  72. (C) Gunosy Inc. All Rights Reserved. PAGE | 92 本番環境とソースリポジトリで指摘が違う

    ▪ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される ▪ どういうことかというと – 本番環境で脆弱性が検知される – ソースコードを修正してコミット・マージ – 開発環境・ステージング環境にデプロイして確認 – (ここまで本番環境の脆弱性は検知されたままの状態) – 本番環境にデプロイ – (ここまでくると本番環境の脆弱性は検知されなくなる)
  73. (C) Gunosy Inc. All Rights Reserved. PAGE | 93 本番環境とソースリポジトリで指摘が違う

    ▪ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される ▪ どういうことかというと – 本番環境で脆弱性が検知される – ソースコードを修正してコミット・マージ – 開発環境・ステージング環境にデプロイして確認 – (ここまで本番環境の脆弱性は検知されたままの状態) – 本番環境にデプロイ – (ここまでくると本番環境の脆弱性は検知されなくなる) ▪ つまり本番環境にデプロイされるまでは以下の状況が発生する – ソースリポジトリ上のスキャン結果は脆弱性なし – 本番環境のスキャン結果には脆弱性あり
  74. (C) Gunosy Inc. All Rights Reserved. PAGE | 94 本番環境とソースリポジトリで指摘が違う

    ▪ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される ▪ どういうことかというと – 本番環境で脆弱性が検知される – ソースコードを修正してコミット・マージ – 開発環境・ステージング環境にデプロイして確認 – (ここまで本番環境の脆弱性は検知されたままの状態) – 本番環境にデプロイ – (ここまでくると本番環境の脆弱性は検知なくなる) ▪ つまり本番環境にデプロイされるまでは以下の状況が発生する – ソースリポジトリ上のスキャン結果は脆弱性なし – 本番環境のスキャン結果には脆弱性あり ▪ 対応としては、リスク評価は本番環境スキャンで、修正確認はソースコードスキャ ンで行うように使い分ける
  75. (C) Gunosy Inc. All Rights Reserved. PAGE | 95 運用フェーズの課題(再掲)

    ▪ 脆弱性検知時に通知するとうるさい(クラウド) ▪ トリアージが手間(コンテナ) ▪ トリアージが手間(コンテナ)その2 ▪ 脆弱性を修正してもゼロにならない(コンテナ) ▪ Shift-leftしてもright側のスキャンと対応も必要 ▪ 本番環境とソースリポジトリで指摘が違う
  76. (C) Gunosy Inc. All Rights Reserved. PAGE | 97 導入フェーズ

    ▪ 継続的にコスト(セキュリティツール、対応コスト)が発生することの承認とセキュリ ティ対策の必要性の理解を幹部レベルで得ておく – リスク軽減のメリット訴求も忘れない – なにかの拍子に別の幹部からコスト削減要請がきます ▪ 想像以上に大量の脆弱性指摘が発生するので、開発チームと合意しておく ▪ 導入当初から開発チームを巻き込む – セキュリティチャンピオン制度は有効 ▪ 脆弱性対応は最初からがんばりすぎない – 対応する脆弱性・対応しない脆弱性の振り分けから始める – リスクの高いものから対応する
  77. (C) Gunosy Inc. All Rights Reserved. PAGE | 98 運用フェーズ

    ▪ GuardDutyの通知運用は必須 – 他はお好みで大丈夫 • 通知をチケット化する運用まで持っていければ有用 ▪ トリアージが必須なので、トリアージする対象の量、マンパワーに応じてトリアー ジ対象を絞る – トリアージがボトルネックになると運用が回らなくなる – 開発チームに委譲していくことを織り込んでいく • ex:セキュリティチャンピオン
  78. (C) Gunosy Inc. All Rights Reserved. PAGE | 99 運用フェーズ

    ▪ 対応の優先順位付けと期日設定をする – 優先付けしないと拒否反応がでる – 期日を設定しないと結局対応されない Critical+攻撃コードあ り それ以外 Internet-f acing できるだけ早く対応 四半期を目処に対 応 それ以外 1ヶ月以内を目処に 対応 任意のタイミングで 対応
  79. (C) Gunosy Inc. All Rights Reserved. PAGE | 100 運用フェーズ

    ▪ 普段の開発にセキュリティを織り込んでいく – ゆとりを作ってセキュリティと技術負債の解消をねらったり – 改善Day的にセキュリティ対応する日を決めて対応したり – CI/CD、テスト周りの整備がセキュリティ対応にも効きます この辺はチームと開発プロセスによってやり方はいろいろありますが、 大事なのはセキュリティを後回しにしないこと!
  80. (C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 102

    デプロイパイプラインでのセキュリティ対応フロー オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS EC2 Fargate 開発中の Scanと修 正 PR チェック 差分をス キャン 定時ス キャン ミスコン フィグの チェック ログ、 Image Scan
  81. (C) Gunosy Inc. All Rights Reserved. PAGE | 103 定常的な運用フロー

    [定期・自動] スキャン DBとの照合 ダッシュボードで 確認 or 通知で確認 トリアージ 脆弱性対応 無影響確認 ・テスト デプロイ 網羅的なス キャン 強力な修正 Suggest 一覧で確認しや すいダッシュ ボード Security Hub Security Lake GuardDuty
  82. (C) Gunosy Inc. All Rights Reserved. PAGE | 105 トリアージとチケット起票の自動化

    ▪ モチベーション – トリアージルールは決まっていて、チケット起票ルールも決まっている – SREは2名なので手動だとスケールしないことは確定している – なので、自動化したい ▪ こんな仕組みでいけそう – Snykの検出結果がCSVでアウトプットできるので、それを解析してJIRAを起 票 – GASでも実装できそう
  83. (C) Gunosy Inc. All Rights Reserved. PAGE | 107 まとめ

    ▪ セキュリティ対応に銀の弾丸はありません – セキュリティ対応の目的は受容可能な範囲にリスクを抑えること • ゼロは目指さなくてよい – 脆弱性を減らすには結局はマンパワーと事前調整が必要です ▪ セキュリティ対応ツールをうまく利用すれば高速道路に乗れます – 少ない人数でも運用できます ▪ セキュリティを後回しにしない、プロセスに織り込む – 当たり前品質にセキュリティを加えましょう ▪ 前向きで健康的なセキュリティ対応をしましょう – 普段からのCI/CD、テスト周りの整備が効いてきます