AWS Security Hub とリスク分析を考慮したアラート対応アプローチ

Security-JAWS を運営していて、その参加者には AWS Security Hub を有効にする方々が非常に多く見受けられます。中には、別の理由で 3rd パーティーの CSPM を利用される方々もいます。

一方で、いずれも利用されていない方々がいることも知りました。「CSPM は利用していないが WAF での対策はバッチリです。」という声を聞くこともあります。

クラウドのリソースの設定を監視して脆弱な設定や設定不備を検知することによりセキュリティリスクを可視化し、レスポンスを行うためのしくみです。

管理対象となるクラウドのサービスと紐づけることで、クラウド上の脆弱な設定や設定不備のあるリソースを発見し、それらの設定に関してアラートをあげ、自動修復するといったことを考えることが可能です。

CSPM を導入することにより、管理対象となる環境に対してどれだけセキュリティ対策が行えているのかを自己評価することが可能であり、継続的な監視を行うことができます。そうして評価されたスコアを高めていくことで、自律的なサイバーセキュリティの高度化を促すことができます。

サイバーセキュリティの対策を立案するための工程は、現状把握、分析、計画立案です。現状把握を行うのに CSPM はとても有効な手段でもあります。さらに、CSPMの検出結果の一部をクラウドセキュリティ監査にも活用することが可能です。

CSPM では確認できない項目は、手動でクラウドセキュリティチェックを行う必要がありますが、多くの工数を簡略化できるでしょう。

2019 年に AWS Security Hub は、AWS が提供するマネージドな CSPM サービスとしてリリースされました。AWS Foundational Security Best Practices (FSBP) 標準 やサポートされている業界のベストプラクティスや標準に照らして、アカウントレベルとリソースレベルの設定を継続的に自動チェックします。

AWS Security Hub は、これらのチェックの結果をスコアとして提供し、注意が必要な特定のアカウントとリソースを特定します。さらに、自動修復をサポートしてくれます。2023 年の AWS re:Inforce では、自動化ルールが発表 され、検出された結果のフィールドを自動更新したり、検出結果を除外させるために非表示にするといったことも可能となりました。その直後には AWS Control Tower との統合 も発表され、

2023 年の AWS re:Invent でも複数の機能アップデートが発表されました。まだまだこれからも機能追加が行われるサービスと考えられます。

AWS Security Hub の特徴を見ていきましょう。

AWS Security Hub は、AWS リソースに関して、複数リージョンの検出結果を集約するクロスリージョン集約や、複数のAWS アカウントにわたるマルチアカウントのセキュリティ管理にも対応しています。マルチアカウントについては、AWS Organizations や AWS Control Tower を利用していない場合であっても、管理者アカウントを指定することで、特定の AWS アカウントにて AWS Security Hub による検知内容を集約することが可能です。

導入にあたっては、AWS Security Hub は有効化のためのボタンを押下するのみでとても簡単です。

セキュリティ標準についてみてみると、以下のフレームワークに対応しています。

• AWS Foundational Security Best Practices(FSBP)
• CIS AWS Foundations Benchmark v1.2.0
• CIS AWS Foundations Benchmark v1.4.0
• NIST SP 800-53 Revision 5
• PCI DSS v3.2.1

本フレームワークから技術的にチェックが可能な項目を AWS Security Hub にて確認することができます。

検出結果を集約するための統合という観点で言えば、以下は AWS Security Hub に結果を送信・統合 される他の AWS マネージド・サービスの一例です。

• AWS Config
• Amazon GuardDuty
• Amazon Inspector
• Amazon Macie
• AWS Health (セキュリティに関するアラートのみ)
• AWS IAM Access Analyzer
• AWS Systems Manager Patch Manager
• AWS Firewall Manager

AWS ネイティブのマネージドサービスを多く統合することができるため、AWS 内で連携しやすいと言えるでしょう。また、AWS とのパートナーシップを結んでいる複数の 3rd パーティーベンダーも存在し、それらのサービスで検知した内容を AWS Security Hub に送信し、AWS Security Hub 上のダッシュボードで結果を統合し、検知内容を一元管理することも可能です。

アラートを通知するにあたり、Amazon EventBridge を通じて、Amazon SNS や AWS Chatbot への連携が可能なので、メールはもちろん自社で利用している Chatops ツールへの連携も可能です。また、自動修復 のためのアクションを行うために AWS Lambda、AWS Step Functions、AWS Systems Manager Run Command 等を連携先として指定することも可能です。一方で、属人的な運用を排除することを目指して、何をどのように自動修復を設定するかはシステムに対するかなり熟考した設計の理解と実装が必要となります。当初目論んだ運用設計どおりに Playbook の実装や自動修復が行えたからといって、システムアーキテクチャが変わる等の変革が訪れるとともに、当初設定した運用設計自体もまた可能性があるためです。これからAWS Security Hubの導入を考えられている方々にはいきなり自動修復を目指すのではなく、運用設計やシステムのアーキテクチャの変更可能性などをきちんと検討いただくことをおすすめします。その上で、後のフェーズにて改めて 自動化 を検討されるのが良いと考えます。

アーキテクチャ図は以下のようになると思いますので、参考ください。

AWS Security Hub にしても、3rd パーティー CSPM を利用するにしても、運用するイメージを最初にある程度立てておくのが良いでしょう。

アラートが鳴りすぎて疲弊して、運用出来そうにありませんという声はよく聞きます。導入する際には運用設計を考えておく必要がありますので、参考にいただけると幸いです。ここからは、AWS Security Hub の初期設定と運用設計について気をつけておくべきポイントを述べたいとおもいます。

AWS Security Hub の Findings における Severity は情報レベルの検出結果であるInformational を除くと、 4 段階あり、Critical、High、Medium、Low が AWS によって定められた重要度となっています。

対応する必要のある項目が数少ないのであれば Severity の高いものから対応していけば良いと思いますが、項目の数が多いとなると、対応優先度を決定するために必要となってくるのはトリアージです。トリアージするにもこの 4 段階の Severity がそのまま企業にとっての優先度ではない場合があると私は考えます。例えば、次のようなリスク分析を検討してみましょう。

標準的なリスクモデルですと、リスクは発生頻度 x 影響度にて計算されます。ここで発生頻度とは、脅威の発生頻度と考えてみることにします。ここで脅威とは、自システムや自組織で保有している情報資産に損失・被害を与える事象です。そのシステムで衞るべきデータが何か、きちんと把握できていれば、そのデータにおける脅威とは何か？が見えてくるでしょう。

例えば、その脅威における発生頻度を月に1回発生しそう、年に数回発生しそう、年に 1 回発生しそう、数年に 1 回発生しそう、と想定を置きます。この想定に基づいて、発生頻度にも Critical、High、Medium、Low といったラベル付けを行っていきます。影響度は Severity の値をそのまま有効活用するとしたら、Severity と脅威の発生頻度の 2 軸で考えられた以下の図を参考に、リスクを総合評価することが可能であり、より右上に来たものが自システムで対応する優先度の高い順であると考えることができます。

脅威の発生頻度がわからないといった場合は、Serverity と対応のし安さ (工数として少なくすむか、多くかかるか) の 2 軸で同様に総合評価をしてみると良いかもしれません。手のつけやすいものから対応していくことで、対応の効率性を高める意図があります。

ここでは最低限検討しておくべき運用設計を列挙します。

初期設定の中で、利用していない AWS サービスにおける不要な AWS Security Hub の Control を除外するとしましたが、今後、該当サービスを利用することになった場合は、 Control を再度有効にすることをルールとして定めておくことです。

次に、 AWS Security Hub の新しい Control が増えた場合は自動的に有効化となるようにしておきましょう。同様に Amazon SNS と連携して、AWS Security Hub の発表をサブスクライブすることをおすすめします。受け取った際はほんの少しの工数を使って、新規で増えたり、更新となった Control の要否の判断と、Control を有効化とするなら必要に応じてアラート対応、不要とするなら除外対応を行いましょう。

ここで注意点としてあげておきたいのは、対応速度です。一年に一度の棚卸しを、といったことを耳にしますが、数日内にあるいは当日のうちに対策方針を決めるくらいのスピード感で実施したほうが楽だと考えます。ソフトウェアバージョンアップ対応ほどに大変な思いをするわけではないので、一定の保守工数の中でエラスティックに対応し、後回しにしないことをおすすめします。

これらの対応がそれぞれ行えるようになったならば、自動化の対応 を検討するフェーズに進むことも良いと思います。ですが、「運用」の本質は「価値の提供」であり、ユーザーへサービスの価値を提供できるなら「手段」は何でも良いのです (私が尊敬する方の言葉です)。自動化を目的とせず、運用の効率化に着目しながら、セキュリティとしての価値、そしてビジネスにコミットするための価値を築いてほしいと考えます。

本稿では、CSPM を題材に、AWS Security Hub の特徴、AWS Security Hub の初期導入と運用設計について述べました。

あくまで私個人の意見ですが、本番サービスに影響を出すといったものではないので、もっとカジュアルに CSPM に取り組んでみてもいいと思っています。それでも、AWS Security Hub 対応や、その他 AWS セキュリティサービスなど、何から手をつけたらいいのかわからなくて大変だといった場合の読者には、AWS Security Maturity Model (AWS セキュリティ成熟度モデル) を一度読んでいただくことをおすすめします。そして運用設計を考える上でどういった観点が必要なのか、イメージした上で各種セキュリティサービスを導入いただくことをおすすめします。

焦ることはなく、段階的にこつこつと取り組んでいきましょう。