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