Inspectorを導入するために必要なスキルの習得方法を知りたい
上記の方向けにInspector導入スキル習得方法をまとめました。
Inspector提案時の知識習得に活用してもらえたらと思います。
筆者はインフラエンジニア歴10年以上です。
AWS案件は上流から下流まで幅広く対応してきました。セキュリティ関連知識についての詳細は以下に記載しております。
https://github.com/toma1110/cv
Amazon Inspector導入スキル習得方法
パッケージの脆弱性基礎知識
Inspector理解の前に最低限の脆弱性に関する知識を学んでおきます。
CVE、CVSSとは
脆弱性はCVE-IDという識別番号で管理されています。
脆弱性の評価基準にCVSSが利用されていおり、
CVSSは深刻度を同一の基準で比較できるものとなります。
※記憶に新しい「Apache Log4jの任意コード実行の脆弱性」( CVE-2021-44228)の深刻度は最大の10でした
CVSSにはV2、V3、V4があり、時代に合った形に改良され続けています。
InspectorはCVSS v3.1のスコアを利用しています。
脆弱性診断について
脆弱性診断は大きくWeb診断、プラットフォーム診断、ペネトレーションテストの3つがあります。(厳密にはもっと種類があったり、診断サービスによって呼び方が異なったりします)
- 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のコードの脆弱性は設計でつぶす必要がある)
上記3つの検知結果タイプがあるのですが、パッケージの脆弱性がメイン機能です。ここだけでおさえておきましょう。
コードの脆弱性はEC2が対象外であることを理解しておきましょう。
※私はここを理解せずにEC2内のコードの脆弱性に対する運用をどうするか検討してしまいました。。
Amazon Inspectorの運用
Findingsの見方
以下の通りInspectorには検出結果の重要度レベルが定義されいています。
私の案件ではこの重要度をもとに対応方針を定めていくことになりました。
重要度は脆弱性スコア評価により決まり、脆弱性スコア評価はCVSSスコアによって決まります。
CVSSスコアの評価算出方法は複雑なため、私もちゃんとは理解できていません。。
運用設計の参考事例(Amazon Inspectorを用いた脆弱性管理のプラクティス)
システムのセキュリティ要求レベルや運用に割ける工数によって違ってくると思いますので、あくまで一例ですが、私が担当した案件でどのように運用設計を行ったかを記載します。
- Critical:翌営業日に対応要否を確認
- High:翌営業日に対応要否を確認
- Medium:月次で対応要否を確認
- Low:月次で対応要否を確認
- Info:確認不要
Criticalを翌営業日対応で良いとした理由は実際に不正アクセスが行われた場合にはGuardDutyで検知できると判断したからです。(脆弱性があったとしても必ず攻撃されるわけではない)
このシステムのセキュリティ要件は金融案件ほどは高くなく、運用についてはAWS未経験の方が片手間で行うような方針であったため、なるべく緊急(夜間)の通知を少なくしたいという意図がありました。
正解は無い気がしますので、運用設計で相談しながら方針を決めていく必要があると思います。
以下のツイートに運用設計時に試行錯誤した内容をのせました。(複数ツイートで続いています)
Inspectorハンズオン
Inspectorのハンズオンは検索するといくつか出てきましたが、
今(2024年4月)実施可能なハンズオンは見当たりませんでした。
Inspectorは設定作業としては有効化するのみです。
あとは検索結果が見れるようになれば問題ないので、
ハンズオン無しでもInspectorを導入できるスキルはつくものと思います。
→サンプル環境を作り上げるCloudFormationサンプルコード見当たらず、実施不可
→Inspectorは利用されていない
まとめ
SecurityHubなどと統合するとさらに威力を発揮しますが、他サービスとの統合については別記事で纏めようと思います。
Inspector単体の導入でも十分効果はありますので、脆弱性対応で疲弊しているようであれば導入を検討してみて下さい。
コメント