Security Hubの運用を考える②

投稿日: 2023/10/06

はじめに

こんにちは、園田です。
本記事は、「Security Hubの運用を考える①」の続きとなります。
第1回目を見ていないという方はこちらを参照ください。

Security Hubの運用を考える①

「Security Hubの運用を考える①」では、Security Hubでどんな内容が検知できるかの概要説明。また検知したものから重要度の高いものを通知する方法、検知内容の分類を実施しました。

本ページでは実際にどんな運用をするのという所を見ていきましょう。

Security Hubでの例外対応

「Security Hubの運用を考える①」にて、Security Hubが検知する内容について分類を実施しました。その中で、「例外的に許可する」というのものが発生します。
具体的には、特定のパターンAの「セキュリティグループXXXではXXXポートをグローバルに公開したい」、パターンCの「XXＸのサーバは踏み台サーバであるため、グローバルIPを付与したい」などがそれに該当します。

また、パターンBの中にはSCPにて操作を禁止できるものも存在します。
その場合、特別な対応は特定の管理者のみが実施するため、そもそも「検知自体が不要」というケースも考えられます。

SCPでの操作の禁止については以下を参照ください。

AWSでマルチアカウント管理を考える（SCPでガードレールを作ろう①）

AWSでマルチアカウント管理を考える（SCPでガードレールを作ろう②）

上記のような要望に対応するため、Security Hubでは以下の2つが実施できるようになっています。

注意点としては、事前に抑制をすることが出来ず、SecurityHubで出力されたアラートに対して実施する必要があります。（1度はアラートが出力される）

無効化の対象と手順

無効化の対象は、SCPにて制限をしているもの、および「パターンE」のものとなります。パターンＥとしては、「ハードウェア MFA はルートユーザーに対して有効にする必要があります」、「AWS KMS キーを意図せずに削除しないでください」などが該当するかと思います。（KMSキーについてはSCPにて制限し、特定の管理者のみ削除可能にしてしまってもよいかもしれません。）

ネットワークにつながっていないという理由から耐タンパー性が高くより、セキュアなのはどっちと聞かれれば「ハードウェアMFA」となりますが、そもそもハードウェアMFAは以下の理由から運用に大変です。

• そもそも購入が難しい（AWSの場合、USのAmazonから購入が必要）
• 1台1アカウントになるため、ハードウェアMFAの台数が多くなり管理が大変
  （100アカウント存在する場合、100個のMFAが必要となります）
• 時刻同期が必要
  （時刻がずれると認証できないので、時刻同期というオペレーションが発生）
• 2年ぐらいで電池が無くなるので、リプレイスが必要

ぶっちゃけ、上記の理由からハードウェアMFAについては運用したくありません。
というわけでSecurity Hubの検知対象から無効化しましょう。

無効化の画面

上記のように無効化したいコントロール（画像の場合は「ハードウェア MFA はルートユーザーに対して有効にする必要があります」）をクリック。その後の画面で、「コントールの無効化」をクリックことで無効化が実施できます。

抑制済みの対象と手順

「抑制済み」とするものは、パターンA、パターンCのものとなります。
こちらについては事前に申請をもらって対象外の運用とする。申請をもらっていない場合は、誤って設定した可能性があるため、パターンA「早急に復旧対応を実施する必要があるもの」については、アラート検知時管理者にて対応を実施する必要があると考えます。（セキュリティグループに申請が上がっていないポートがグローバルから許可されていた場合、対象の行を削除する。）

パターンCは利用者に確認して、利用者にて設定を修正する、もしくは例外申請をあげてもらうという対応になるかと思います。

「抑制済み」の手順は以下の通りです。

アラートが上がった「コントロール」のタイトルをクリック
抑制対象にチェックを入れ、「ワークフローステータス」を「抑制済み」にすることで抑制が可能です。

なお、実際には抑制してよい対象か確認するため、以下のようにリソースをクリックし対象かどうかのチェックを実施します。

対象のチェック

対象の抑制

本例外対応、およびそれ以外の項目については設定の修正を実施することで、アラートを減らしていくことが可能です。

しつこいですが、セキュリティは「運用」をきちんと回すことが重要ですので、対応は重要度が「重要」および「高」のみとしましょう。その後よりセキュリティを強化したいというのであれば、「中」を追加するなどの運用としましょう。

Security HubのAWSアカウントへの導入

「運用」をきちんと回すという観点においては、現状Security Hubを導入していないアカウントに対し、どのように導入するかという点についても触れておきます。

アラート出力時、「パターンA「早急に復旧対応を実施する必要があるもの」については、管理者にて対応を実施する」と記載した通り、セキュリティ運用を実施する管理者（運用者）が存在し、管理を実施しているものと想定しています。

Security HubをAWSアカウントへの導入する際に、最初からセキュリティ運用を実施する管理者（運用者）にアラートを飛ばす運用を実施した場合、アラートが多数出力され、運用負荷が非常に大きなものとなってしまいます。
運負荷を減らすため、特定アカウントについては無視対応、などの例外対応をしてしまうとセキュリティ運用がどんどん形骸化されてしまいます。

そのため、Security Hub導入時はアラート通知を実施せず、コンソール上での出力のみとしましょう。コンソールにて「重要」、「高」の出力が消えたことをもって、アラート通知を含む正式運用を開始しましょう。

ステップとしては以下のような形となるかと思います。

• Step1：
  対象Security Hubの有効化を実施。
  本タイミングにて「無効化」の対応を実施。
  SecurityHubにてアラートが発生するが、運用を考慮し、通知は実施しない。
• Step2：
  SecurityHub、アラートの状況について、データのエクスポートを実施。
  重要度「高」以上で発生したアラートに対し、「パターンA」から「パターンD」のパターンへの分類を実施する。
• Step３：
  システム担当者に修正依頼を実施。
  パターンA、パターンCに対しては必要に応じて例外申請を挙げてもらうよう依頼。
  パターンBは早急に対応するよう依頼。
  パターンDは修正日程を出してもらうよう依頼。
• Step４：
  修正予定（対応予定日（暫定）） 日以降、運用チームにて、対応状況の確認を実施。重要度「高」以上のアラートについて、画面上から削除されていることを確認
• Step５：
  運用開始（Security Hubの通知運用を開始。検知後は運用ルールに従って対応を実施する）

ポイントは「ともかくきちんと対応が出来たことを運用担当者が確認し、運用を実施することです。これが出来ないと運用を回すという事は非常に難しいと思います。

最後に

セキュリティ運用についてはともかく「運用」をきちんと回すのが難しいと考えています。
依頼等のオペレーションについては実施されないと誰かが困りますのですぐにわかりますが、セキュリティ運用については出来ていなくても「直接困る人がいない」のが原因と考えます。

とはいえ、何かセキュリティ事故が発生してからでは遅いですし、その影響度は甚大です。

Security Hubについては非常に良い製品だと思っていますが、とりあえず導入ができる反面、運用をきちんと回しているところは案外少ないのではないでしょうか。

これが正しい運用とは思いませんが、このブログがセキュリティ運用の助けになればと思っています。

読んでいただいた方々、どうもありがとうございます。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。