Inspectorを利用した脆弱性管理について

Transcript

1. Inspectorを利⽤した 脆弱性管理について 2024.7.29 AWS事業本部 みなみ
2. Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い
3. ⾃⼰紹介 南 宏樹 (みなみ) クラスメソッド株式会社 AWS事業本部コンサルティング部 AWSソリューションアーキテクト • 最近は基幹システムへのゼロトラスト‧SASEの導⼊や セキュリティのアセスメントなどを⾏っていました。 3
4. みなさん脆弱性と 向き合ってますか? 4
5. アジェンダ 1. 脆弱性の基本 2. 脆弱性診断と脆弱性管理について 3. Inspectorについて 4. 脆弱性管理の理想と現実 5. 脆弱性のトリアージと対応 6. Inspectorを活⽤した脆弱性管理 5
6. 脆弱性とは • プラットフォームの脆弱性 (今回はこっち) ◦ OS / ミドルウェア / ライブラリ • アプリケーションの脆弱性 ◦ SQLインジェクション ◦ クロスサイトスクリプティング 6
7. 頻出ワードについて 7 • CVE（共通脆弱性識別⼦） ◦ CVE-〇〇〇〇-×××× • CVSS（共通脆弱性評価システム） ◦ CVSSスコア • NVDとJVN（脆弱性情報データベース） ◦ NVD（National Vulnerability Database） ◦ JVN（Japan Vulnerability Notes）
8. 脆弱性の⼀⽣ 8 脆弱性の 発⾒ パッチの 提供 攻撃コード の公開 パッチの 適⽤ CVEの採番 ゼロデイ攻撃 パッチ公開から2⽇以内に5% 1ヶ⽉以内に45%の攻撃が観測
9. 脆弱性診断 9 • リリース前の診断 ◦ プラットフォームとアプリケーションの脆弱性を診 断し、修正後にリリース ◦ 診断はあくまでも現時点での検出のみ
10. 脆弱性診断の限界 10 • スポット的な診断の問題点 ◦ 脆弱性の数と深刻度の増加 ◦ 攻撃⼿法の⾼度化
11. 脆弱性管理 11 • システムの理解 • 脆弱性情報の収集 • 脆弱性の特定 1. 情報収集 • リスクの評価 • 有効な対策についての調査‧確認 2. リスク評価 • ワークアラウンド(暫定対応 / 緩和策) • 修正パッチの適⽤ 3. 対応
12. とりあえず脆弱性の検知に Inspector使ってみましょう 12
13. Amazon Inspectorの概要 13 • OS‧ライブラリの脆弱性、 意図しないネットワークの露出、 コードの脆弱性の検出が可能 • 対象サービス ◦ Amazon EC2 ◦ Amazon ECR ◦ AWS Lambda • 数クリックで簡単に有効化することができる Amazon Inspector Amazon EC2 Amazon ECR AWS Lambda
14. EC2のスキャン 14 • パッケージの脆弱性 ◦ OSだけではなく、プログラミング⾔語のパッケージマネージャーでイ ンストールされたパッケージの脆弱性も検出可能 ◦ エージェントベースのスキャンだけではなく、エージェントレスス キャンにも対応 (2024年6⽉ GA) • ネットワーク到達性 ◦ インターネット、VPC外のネットワークの到達性のスキャン ◦ 公開されているサービス、ポート、プロトコルに基づいて重要度を判 断
15. ECRのスキャン 15 • ベーシックスキャン (ECRの機能) ◦ ClairプロジェクトのCVEデータベースを使⽤ ◦ OSパッケージのみ • 拡張スキャン (Inspectorによるスキャン) ◦ 複数のデータベース(Snyk, Github Advisory Database)を使⽤ ◦ OSとプログラミング⾔語のパッケージにも対応
16. Lambdaのスキャン 16 • 標準スキャン ◦ コードとレイヤーで脆弱性のあるパッケージが使⽤ されているかスキャン • コードスキャン ◦ Lambdaのコードをセキュリティベストプラクティ スに基づいてスキャン
17. Inspectorを使うメリット 17 • コストの低減 • セットアップの簡便性 ◦ スキャン漏れを減らせたり、開発環境に対してもス キャンを⾏いやすい為、カバレッジ率の向上 • AWSの他サービスとの連携が容易
18. スキャンするだけで終わっていませんか？ 脆弱性管理が重要です 18
19. 理想的な脆弱性管理 19 • 開発フローへ脆弱性スキャンの組み込み • 定期的なパッチの適⽤ • 脆弱性の深刻度、リスクに応じた対応 ◦ 緊急度の低い脆弱性の場合は定期的なパッチで対応 ◦ 緊急度が中程度の場合は定期パッチよりも短いスパンで対応 ◦ 緊急度が⾼いものは最優先で緊急パッチの対応
20. LambdaやECSを利⽤しているケースや モダンな開発現場であれば対応難易度は それほど⾼くない しかし、こんなケースも.... 20
21. 現実 21 • 定期パッチの仕組みがなく、多数の脆弱性が検出されている • 本番環境のみであり、⼀括でのパッチ適⽤が困難。そのため各 修正に対して個別の動作確認が必要 • アプリケーションはベンダー管理下にあり、作業が容易でない
22. 脆弱性管理の対応⽅針 22 • そのような状況下の場合「2. リスクの評価」が重要 • 全てを対応することは現実的ではない為、トリアージ(優先順位付け) を⾏う
23. よくあるトリアージの例 23 • よくあるトリアージのパターン ◦ CVSSスコアが7.0以上の脆弱性のパッチを適⽤しよ う
24. CVSSスコアが7.0以上の脆弱性は多い （実際には50%以上） CVSSスコアだけを利⽤したトリアージは 破綻する可能性が⾼い 24
25. CVSSスコアの問題点 25 • CVSSスコアが⾼い脆弱性から対応することは悪いことではない、し かし、以下の点も考慮する必要がある ◦ 脆弱性を放置するリスク ▪ サイバー攻撃の⼤部分はすでに対処⽅法が公開されている既 知の脆弱性を標的としている ▪ ゼロデイの脆弱性を狙うより攻撃者としては既知なのに未対 策の脆弱性を使う⽅が効率的
26. CVSSスコアの問題点 26 ◦ システム⾃体への影響度を⽰していない ▪ 特定のシステム上での実際の影響を考慮していない ◦ 実際のリスクを反映していない ▪ システムの価値や脅威を考慮しておらず、脆弱性の深刻度のみ に焦点を当てている ◦ 対応のガイドラインがない ▪ CVSSスコアはあくまでもその脆弱性の深刻度を⽰すのみ。 実際の対応⽅針は組織ごとに決定する必要がある
27. リスクとは 27 • 脆弱性の深刻度 ◦ 脆弱性⾃体の深刻度 (攻撃の容易さ、攻撃の影響など) • 脅威 ◦ 攻撃の普及度など攻撃の可能性(攻撃コードの有無、実際に攻撃が⾏われ たことを⽰す情報) • 資産重要性 ◦ 影響を受ける可能性のあるシステムの特性や情報の重要度 リスク = 「脆弱性の深刻度」×「脅威」×「資産重要性」
28. 正しいリスク評価 28 • 具体的にどのように評価を⾏えばいい？ ◦ とりあえずCVSSスコアだけで判断するのはやめよう ⼀旦CVSSについておさらいしましょう
29. CVSS Deep Dive 29 • CVSSは3つの基準で脆弱性の評価を⾏う ◦ 基本評価基準 (Base Metrics) ▪ 脆弱性固有の特性を評価する基準。時間や環境に依存しない ◦ 現状評価基準 (Temporal Metrics) ▪ 現時点での脆弱性の状況を評価する基準。時間と共に変化する ◦ 環境評価基準 (Environmental Metrics) ▪ 特定の環境や組織における脆弱性の影響を評価する基準 • ⼀般的によく使われるのは基本評価基準から算出されるベーススコア
30. CVSSの正しい利⽤法 30 • スコアだけではなく、ベクター(評価基準)も確認することが重要 ◦ Windows SMBv3 の脆弱性(CVE-2020-0796) ▪ CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Base Score: 9.8 • ベンダーが出す現状評価基準の確認 • CVSS Calculatorなどを利⽤して環境評価基準を再計算するのもいい アプローチ⽅法
31. 脅威 31 リスク = 「脆弱性の深刻度」×「脅威」×「資産価値」 • EPSS • KEVカタログ • 攻撃コードの有無 • 最後に攻撃が観測された⽇時 • JPCERT/CCの早期警戒情報 • ベンダーからの脆弱性情報の収集 • X (旧Twitter) リスク = 「脆弱性の深刻度」×「脅威」×「資産重要性」
32. 資産重要性 32 リスク = 「脆弱性の深刻度」×「脅威」×「資産価値」 • システムの資産重要性も考慮するべき ◦ 影響を受けるシステムの特性攻撃を受けた場合のビジネ スインパクト リスク = 「脆弱性の深刻度」×「脅威」×「資産重要性」
33. トリアージの⼀例 33 1. KEVカタログやJPCERT/CC等からの警戒情報が出ている もの 2. 攻撃コードが存在し、すでに攻撃が観測されているもの 3. NWから攻撃可能であるもの 4. 緩和策/回避策なし及び権限無しで攻撃可能なもの
34. SSVC 34 • システムのNW環境‧業務影響、脆弱 性の攻撃状況、攻撃者⽬線の利⽤価 値の4つの情報を⼊⼒として4段階の 対応レベルを出⼒するフレームワー ク SSVC決定⽊
35. 対応の基本 35 • トリアージが出来た後、次にどのような対応をするか？ ◦ 基本的にパッチの適⽤を⾏うが、パッチの適⽤が出来 ない場合も ▪ そもそもパッチが存在しない ▪ 諸事情によりパッチの適⽤が難しい
36. 対応の種類 36 • 4種類の基本の対応⽅針 ◦ 軽減 ▪ 脆弱性のリスクを軽減するための対策 ◦ 回避 ▪ 脆弱性の影響を受ける機能を⼀時的に停⽌するなど、脆弱性の影響 を回避する対策 ◦ 転嫁 ▪ リスクの責任や影響を第三者に移転する⽅法 ◦ 受容 ▪ リスクを受け⼊れ、対応を⾏わない場合
37. Inspectorなどを使って なるべく楽に脆弱性管理をしよう 37
38. Inspectorで取得できる情報 38 • 使⽤可能な修正 ◦ 公式パッチの有無 • 最後に攻撃された⽇時 ◦ 脆弱性を利⽤して最後に攻撃が観測された⽇時 • 考えられる攻撃 ◦ 攻撃コードの有無 • EPSS ◦ 脆弱性が今後30⽇間に悪⽤される確率を数値化した指標 • ⽶国国⼟安全保障省(CISA)の情報 ◦ KEVカタログに追加された⽇付とCISAが定めるパッチ適⽤期限
39. Inspectorスコア 39 • CVSSを元にAWS上での環境を加味して再計算を⾏う
40. 抑制ルール 40 • 特定の条件に合う脆弱性をダッ シュボードから排除する機能 • 単なるフィルター機能として利⽤ しないことが重要
41. 可視化 41 • Inspectorのフィルター機能やAthena、QuickSight • 結果をエクスポートして、エクセルで可視化
42. 通知 42 • SecurityHubを利⽤した通知、SlackやBacklog(課題管 理ツール)への通知や⾃動起票 ◦ ノイズにならないように⼯夫する必要がある
43. パッチ適⽤ 43 • AWS Systems Manager を活⽤した定期的なパッチを適⽤ • SecurituHubのカスタムアクションから緊急パッチを適⽤させ る仕組み
44. そもそも 44 • サーバーレスなサービス、マネージドなサービスを積 極的利⽤し、責任範囲をAWSに移す AWS Lambda AWS Fargate Amazon RDS
45. まとめ 45 • 脆弱性管理の重要性 • 脆弱性管理の理想と現実 ◦ 現実問題すぐにシステム‧仕組みを変えるのは難しい為、 トリアージを⾏いリスクが⾼い脆弱性から対応を⾏う ▪ 脆弱性の深刻度ベースのトリアージではなく、リスク ベースのトリアージを⾏う