はじめに
2023年、最初のブログはAWSセキュリティについて書きます。
MITRE ATT&CK（マイターアタック）という素晴らしいフレームワークには、非常に多くのナレッジが蓄積・公開されています。
パブリッククラウドサービスについても、各種クラウドごとにも纏められています。
さまざまな活用方法があるとは思いますが、自分なりの使い方の一つを共有しておきたいと思います。
今回、紹介するのは、インシデント発生後の再発防止についてです。
手順の概要
インシデント発生後、再発防止策の検討の際には、攻撃内容をもとにセキュリティホールを埋める対応を行いますが、多くの場合、担当者の知識ベースで考察します。
経験のあるエンジニアの場合、当初漏れてしまっていた対策も、この再発防止策を検討する際に気付けることが多いのですが、ここでMITRE ATT&CKと照らし合わせることで、攻撃者視点でのプロセスごとでの手順と対策を体系的に確認ができます。
また、他の対策に気付ける可能性もあります。
MITRE ATT&CKでは、攻撃者が行うプロセスを14ステップのTactic(s)と呼びます。
また、各手順をTechnique(s)と呼びます。
実際の攻撃事例でのサンプル
私自身がこれまでも目にしてきたセキュリティインシデントに、クレデンシャル漏洩からの不正アクセスがあります。
以下のようなプロセスを例に、考えてみます。実際には①の漏洩と⑤以降のプロセスもありますが、今回は割愛します。
①漏洩したクレデンシャルを使って、IAMユーザー（ユーザーA）にログイン
②ユーザーAにて、攻撃用のIAMユーザー（ユーザーB）を作成
③ユーザーBに強権限を付ける
④ユーザーAを含む他のIAMユーザーから権限剥奪
⑤ユーザーBを使って、不正行為
AWSのMITRE ATT&CKマトリクスと照らし合わせます。
検知または緩和のためのコントロールを確認することが可能です。
Tachticsを左側から確認していきます。
Initial Access
Initial Accessのステップに当たるのは①と考えられます。
Techniqueとしては、Valid Accountsが該当します。
コントロールとして、GuardDutyで検知する対応が挙げられます。
例えば、アクセス元がある程度限定されている環境においては、普段とは異なるアクセス元からの操作を検知できた可能性があります。
また、別のコントロールとしてIAMによる緩和もあります。
複雑なPWを短期間で更新するようにしておけば、防げた可能性もあります。
Persistence
Persistenceのステップに当たるのは②と考えられます。
ここでのTechniquesは２つ考えられます。
一つ目がAccount Manipulationです。
コントロールは３つ挙げられます。
一つ目は、先ほどと同じくGuardDutyです。
IAMユーザーの作成が、普段と違う内容で行われたことを検知できた可能性があります。
その他、Config, IAMのコントロールも挙げられます。これらは、Mitigationsの対策です。PWの有効期間を設定しないアカウント作成を抑止できた可能性があります。
二つ目のTechniqueとしてCreate Accountがあります。
コントロールは、同じくGuardDutyでの検知が挙げられます。
Privilege Escalation
Privilege Escalationのステップに当たるのは③と考えられます。
Techniqueとしては、Initial Accessと同じく、Valid Accounts、
コントロールとしてGuardDutyで検知する対応が挙げられます。
このように、同じTechniqueが複数のTacticsで利用されることもあります。
Defense Evasion
Defense Evasionのステップに当たるのは④と考えられます。
Techniqueとしては、またまた、Valid Accountsがあります。
Credential Access以降
実際に行われた攻撃内容によって、同様にマトリクスを確認していきます。
まとめ
上記のように、攻撃のステップごとに確認することで、より深い調査と検討が可能になります。
先の例ではGuardDutyを入れることによって、今後はいち早く検知できるであろうことが確認できました。すでにGuardDutyを入れていたが早期に動けなかったのであれば、運用を見直す必要があると見受けられます。再発防止としては、IAMやConfigの設定見直し、導入を検討することが有効そうです。
ただ、マトリクスの確認において、あまり分類に時間をかけすぎなくてもいいと考えます。
一つのTechniqueが複数のTacticsで登場するように、明確に分類しにくいものもあります。
先に挙げた分類も、別の見方もできるかも知れません。
あくまで、より深い調査と分析のために利用することが目的であって、マトリクスにマッピングすることが目的ではありません。
また、すべてのコントロールを無条件に導入することはお勧めできません。
例えば、①において、リモート業務などでアクセス元が頻繁に変わる場合は、この検知はノイズになることもあります。
コストの視点での見送りもあります。守るべきデータの重要性に合わせたコストをかけましょう。秘匿性が高くないデータに対して、高い投資をすることは適切ではありません。
一見、十分でないと思われる緩和も有効に機能することもあります。
例えば、②におけるAccount Manipulationにおいて、PWの変更期間を設定しなかった or 長すぎる設定だった場合に、リトライするだろうから無駄と思われるかもです。
ただ攻撃は、スクリプトで行われることが多いです。スクリプト内でエラーが発生した場合、諦めるようになっていることも多いです。セキュリティ対策が不十分な環境を狙った方が攻撃の効率が高いためです。実際、スクリプトがエラーを吐いて中断したと思われる攻撃のログも見ることがあります。
セキュリティインシデントへの対応の質が上がり、少しでも世の中から被害が減ることの役に立てば幸いです。
参照