OSやミドルウェアの脆弱性調査で疲弊している
Inspectorを導入するために必要なスキルの習得方法を知りたい

上記の方向けにInspector導入スキル習得方法をまとめました。
Inspector提案時の知識習得に活用してもらえたらと思います。

筆者はインフラエンジニア歴10年以上です。
AWS案件は上流から下流まで幅広く対応してきました。

セキュリティ関連知識についての詳細は以下に記載しております。
https://github.com/toma1110/cv

Amazon Inspector導入スキル習得方法

パッケージの脆弱性基礎知識
1. CVE、CVSSとは
2. 脆弱性診断について
Amazon Inspectorとは
1. Inspectorは脆弱性対応効率化するツール
2. Amazon Inspectorの検知結果タイプ3つ
Amazon Inspectorの運用
1. Findingsの見方
2. 運用設計の参考事例（Amazon Inspectorを用いた脆弱性管理のプラクティス）
Inspectorハンズオン
まとめ
1. 関連

パッケージの脆弱性基礎知識

Inspector理解の前に最低限の脆弱性に関する知識を学んでおきます。

CVE、CVSSとは

脆弱性はCVE-IDという識別番号で管理されています。
脆弱性の評価基準にCVSSが利用されていおり、
CVSSは深刻度を同一の基準で比較できるものとなります。
※記憶に新しい「Apache Log4jの任意コード実行の脆弱性」（ CVE-2021-44228）の深刻度は最大の10でした

CVSSにはV2、V3、V4があり、時代に合った形に改良され続けています。
InspectorはCVSS v3.1のスコアを利用しています。

脆弱性診断について

脆弱性診断は大きくWeb診断、プラットフォーム診断、ペネトレーションテストの３つがあります。（厳密にはもっと種類があったり、診断サービスによって呼び方が異なったりします）

Web診断：SQLインジェクションやクロスサイトスクリプティングなどに耐えられるか診断
プラットフォーム診断：OS・ミドルウェアの脆弱性検査、ポートスキャンを実施
ペネトレーションテスト：攻撃者の視点にたって、実際に攻撃を行う

Inspectorはプラットフォーム診断を自動で行ってくれるサービスですが、脆弱性診断サービスのプラットフォーム診断はペネトレがセットにできることがおおく、ペネトレが必須要件になることがあります。
Inspectorが脆弱性診断すべてを置き換えるものではないことを理解しておきましょう。

Amazon Inspectorとは

Inspectorは脆弱性対応効率化するツール

【これまで】
手動による脆弱性情報収集し、システムで問題のあるソフトウェアがないかを目視確認してきた
↓
【Amazon Inspector導入後】
手動による脆弱性情報収集を不要とし、システムで問題のあるソフトウェアを自動抽出し、対応優先度順に表示してくれる

手動による脆弱性情報収集が苦行(金融業界だったため日課でした)だったので、これはかなりありがたいです！

↓BlackBeltからの引用です。Inspectorの特徴をつかむのに最適です。

Amazon Inspectorの検知結果タイプ3つ

パッケージの脆弱性：ソフトウェアパッケージの脆弱性を検出。スコアリングはCVSSを基にInspector独自に算出。配置場所(パブリックネットワークかプライベートか)でスコアが変わる。
ネットワーク到達可能性：危険な通信許可(0.0.0.0/0への22ポート許可など)を検出。配置場所でスコアが変わる。(Securityhubでも検知されるが配置場所は考慮されない)
コードの脆弱性：lambda関数のみが対象。（→EC2のコードの脆弱性は設計でつぶす必要がある）

上記３つの検知結果タイプがあるのですが、パッケージの脆弱性がメイン機能です。ここだけでおさえておきましょう。

コードの脆弱性はEC2が対象外であることを理解しておきましょう。
※私はここを理解せずにEC2内のコードの脆弱性に対する運用をどうするか検討してしまいました。。

Amazon Inspectorの運用

Findingsの見方

以下の通りInspectorには検出結果の重要度レベルが定義されいています。
私の案件ではこの重要度をもとに対応方針を定めていくことになりました。

Amazon Inspector の検出結果の重要度レベル - Amazon Inspector

Amazon Inspector が脆弱性の検出結果を生成すると、その検出結果に重要度が自動的に割り当てられます。検出結果の重要度は、検出結果の主要な特性を反映し、検出結果の評価と優先順位付けに役立ちます。検出結果の重要度は、影響を受けたリ...

重要度は脆弱性スコア評価により決まり、脆弱性スコア評価はCVSSスコアによって決まります。
CVSSスコアの評価算出方法は複雑なため、私もちゃんとは理解できていません。。

運用設計の参考事例（Amazon Inspectorを用いた脆弱性管理のプラクティス）

システムのセキュリティ要求レベルや運用に割ける工数によって違ってくると思いますので、あくまで一例ですが、私が担当した案件でどのように運用設計を行ったかを記載します。

Critical：翌営業日に対応要否を確認
High：翌営業日に対応要否を確認
Medium：月次で対応要否を確認
Low：月次で対応要否を確認
Info：確認不要

Criticalを翌営業日対応で良いとした理由は実際に不正アクセスが行われた場合にはGuardDutyで検知できると判断したからです。（脆弱性があったとしても必ず攻撃されるわけではない）

このシステムのセキュリティ要件は金融案件ほどは高くなく、運用についてはAWS未経験の方が片手間で行うような方針であったため、なるべく緊急（夜間）の通知を少なくしたいという意図がありました。

正解は無い気がしますので、運用設計で相談しながら方針を決めていく必要があると思います。

以下のツイートに運用設計時に試行錯誤した内容をのせました。（複数ツイートで続いています）

Inspectorの運用ルールを決めないといけないとなったので、

・Criticalは即時パッチ適用
・Highは定期メンテナンス時に適用
・Medium以下は対応不要

のように定義しました。。

ChatGPTには「Medium以下は対応不要」はやりすぎと怒られました。。https://t.co/e4N1FVzqu1 pic.twitter.com/jfL7dNtfZ3
— とーま@AWSインフラエンジニア (@Toma1110) March 24, 2024

Inspectorハンズオン

Inspectorのハンズオンは検索するといくつか出てきましたが、
今（2024年4月）実施可能なハンズオンは見当たりませんでした。
Inspectorは設定作業としては有効化するのみです。
あとは検索結果が見れるようになれば問題ないので、
ハンズオン無しでもInspectorを導入できるスキルはつくものと思います。