[レポート]SisyphusとCVEフィード：大規模な脆弱性管理について – CODE BLUE 2022 #codeblue_jp

CODE BLUE 2022 で行われた下記セッションのレポートです。

セッション概要

タイトル

SisyphusとCVEフィード：大規模な脆弱性管理について

概要

脆弱性管理は、新旧または未定義のCVEを終わりのない流れで選別する、退屈で時間のかかる作業になっている。デフォルトの危険度評価は不正確なことが多く、大量の誤検知や運用業務につながる。多種多様なスキャン製品と、増え続ける資産から脆弱性を追跡することは、常に課題となっている。これらの問題を対処しなければ、アラート・ファティーグ（アラート疲れ）でセキュリティ・チームへの信頼が低下し、検知から修復までのターンアラウンド・タイムが長期化することになる。

この講演では、われわれのチームのインフラストラクチャに対する脆弱性の自動的管理のアプローチと、業界の標準的なアプローチがなぜ欠けていたのかについて説明する。すべての脆弱性を一元管理し、検出、リスク評価、脆弱性レポート、脆弱性修正検証をスケーラブルに自動化するわれわれの作業について説明する。ベンダーに依存せず、デフォルトの危険度に頼らず、運用作業を可能な限り削減できるような内部ツールをどのように開発したかを共有する。

Presented by

キザイア・プラットナー - Keziah Plattner
カディア・マシャール - Kadia Mashal

レポート

• Airbnb における脆弱性管理の自動化を紹介するセッション
• Sisyphus とはどういった意味か
  • 由来はギリシャ神話
  • 永遠に終わらないタスク（脆弱性対応）を表現している
• どのようにして終わりのないタスクに対応したかを話す
• 脆弱性管理の基本
  • 脆弱性を見つけて、リスクアセスメントして、報告して、修復と防止する、というサイクル
  • Objective
    • 変化・拡大するクラウドインフラに対応
    • タイムリーな検出、修復、検証
    • 優先順位付け
    • 根本原因
    • ベンダに依存しない
• 従来の脆弱性管理では、たくさんの情報源があり、セキュリティ担当者が全部見る必要があった
  • 手動では時間がかかる
• 自動化の前の課題
  • リスク評価の課題
    • スコアは全ての環境で適用するには曖昧
    • 環境に応じたものにはなっていない
  • ベンダの機能に対してカスタマイズが必要（そのまま利用できない）
  • 説明責任がある
• 対策として指針を作成した
• デフォルトのスコアは正しくない
  • 誤検知ではないが、自分たちにとっては重要でないものがある
• アラート疲れや誤解もあるため、手作業ですべてを見ることは現実的ではない
  • できるだけリスクアセスメントを自動化して誤検知を最小限としたい
  • 人によっては見落としがあることを心配する
    • 全てをキャッチアップするのは不可能なため、トリアージを早くすることの方が大事
    • パーフェクトではないものを受け入れる必要がある
• 事後対応ではなく、事前対応（プロアクティブ）とする
  • Standard deployment pipeline
  • CI Check
  • Image auto-rotation
  • Patching cadence
• 全てを自動化しても、他のチームを敵に回すことはよくない
  • 他のチームと協力して、ゴールを一緒にすることの同意を得る必要がある
  • トップダウン過ぎた間違いもあった
  • 両者にとって利益があることが必要（関係性を作る）
• どのように説明責任を果たすのか
  • SLA を設定
    • Critical な脆弱性を優先して対応する
  • セキュリティメトリックはビジネスのメトリックとして扱われることが重要
• 構築した脆弱性管理システム
  • Aggregate and Process Vulnerabilities
    • データをインポートして一元化、重複排除、標準化、ユニークな ID で脆弱性を管理
  • Contextualize Risk
    • Internal Risk Scoring
    • 関連するメタデータを集める
      • 例えば、外部アクセスできるのか、個人情報を扱うか、開発環境 or 本番環境、など
    • 情報は複数の情報源から集める
    • 上記を元にできるだけ分類する
  • Reporting and Remediation
    • ユニークな ID を付与した脆弱性毎のレポートを作成
  • Verification
    • 信頼できるものでも検証する方針
• One Step At a Time（一歩ずつ）
  • 今から情報を収集する
  • 一部でも自動化する
• Scaling（スケーリング）
  • アーキテクチャはマイクロサービス
  • Tech Stack
    • Vendor APIs
    • Apache Airflow
    • Hive/Presto
    • Spinnaker
    • Ticketing APIs
• Resalts
  • 会社都合で実際の結果は共有できないが、大幅にリスクは下がった結果となった
  • ノイズを排除できた
  • Log4j の対応を非常に早くできた
• ベンダーにこだわらない
  • ベンダに依存しない基盤をデザインする
  • Open-Source-Security Solutions の利用検討（自動化に役立つ）
  • 多くの情報源から脆弱性スコアを取得する
• 学んでいただきたい点
  • メタデータの収集に投資すること
  • 脆弱性を一元管理する
  • リスクを可視化する
  • 自動化と脆弱性の根本原因対策に投資する
  • 早く従来型の運用が大変なやり方から離れる
    • 手作業では、対策を行う十分な時間をとれなくなる

さいごに

大変になりがちな脆弱性管理を自動化した事例を知ることができる貴重なセッションでした。