Security Hub Orgnization
Security Hub
OrganizationでSecurity Hubを有効にしてみました。
SecurityHubの有効化はAWS Configの有効化が必須なのが注意。
検出結果はChatbotを使用してSlackに通知している。
構築はほとんどTerraformで行った。
Chatbotはawscc providerを使用すれば設定できますが、ChatbotをSlackのWorkspaceに招待することができず、AWS Consoleから操作しました。
もしかしたら見逃しているだけかも...
適用したルールセットはSecurityHubを有効化したときにデフォルトで設定される以下。
Slackへの通知は以下のように行われる。
検出結果1つにつき1件のコメントが通知されるので、場合によっては大量に通知がくる。
上位のSeverityだけをフィルタリングをEventBridgeのルールで設定できるので、絞っておいたほうがようさそう。
Security Hubの実行スケジュールは12時間毎に定期的に行われるため、対処しない限りは検出される。
一応、一度しかSlackへ通知しないといったフィルタリングもできるが、一度見逃したらアウトという感じになるのでやめたほうがいいと思う。
困ったこと
EventBridgeのデバックが難しい
Security HubというかEvent Bridgeの問題。
Event Bridge -> ルール -> 対象ルール名 -> モニタリング と遷移してCloudWatchから失敗していることが分かるが「Failed Invocations」以外の情報がない。
難しいというか不可能に近い。Event BridgeでECSタスクを発火させる場合はCloudTrailから失敗理由を終えたりするけど、今回のような構成では無理。
こういう場合はだいたいターゲット側（今回で言えばSNS）が原因のことが多いためそこから探っていく。
通知問題
大きく2つ。
- 見辛い。
ConsoleからSecurity Hubを開けば何のルールで引っかかったのか、改善方法等が見れるがやっぱり見辛い気がする。
多分慣れ。通知のフォーマットが見辛いならLambdaを挟んでなんとかするしかない。
といっても見やすさは個人差があるのでそこまでやるメリットがあるかは不明。
慣れたほうがコスパよさそう。
- 大量通知がくる
Severityでフィルタリングすればまぁ抑制することはできる。
が、大量のアカウントを作成していたり、AWS Foundational Best Practices に乗っ取らず運用してきた場合は中々難しい。
不要になったIAMはちゃんと削除してる？とか。そのレベルからの話もある。
ちゃんと運用しよう。に尽きる話ではある。が今後どうしていくか？というところにちゃんとリソースを投下しないと厳しい。
チーム内で一定期間専任をつけたりとかした方がいいと思う。
運用
公式のドキュメントにもあるように無効化したいルールが出てきた場合。
TerraformでもCosoleからでもできるが、その判断が難しい。
無効化するにあたっての根拠を整理し合意を取るというコストは割と大きいと思う。
(コストといってよいのか？)
隔週でMTGを行うとかが最初の1歩としてはよさそうな気がしている。
