概要
当エントリーでは、Trend Micro Cloud One Conformity (以後C1C)で初期導入時に、考慮しておきたい「デフォルトで有効化されていない重要なルール」についてどうすべきかについて考えていきます。
※これが正解というものがない内容なので、管理者ご自身で良いと感じた内容のみ取り入れるような視点で参照頂ければと思います。
- 概要
- 何故に重要なのにデフォルトで有効化されていないルールがあるのか？
- リスクレベルの指定が高いものを把握する
- 1. Canary Access Token (IAM-055)
- 2. Unintended AWS API Calls Detected (RTM-011)
- 実際の設定値を考えていく
- 自身の環境にあったルールの考察
- RTM-011を設定後の運用について
- まとめ
- 関連エントリー
何故に重要なのにデフォルトで有効化されていないルールがあるのか？
答えは、ユーザー側でなんらかの「値」を指定しないと機能しないルール であるからです。
執筆時点(2021/10)で 54個あり、初期構築後の状態であれば以下画面のようなメッセージが表示されます。
対象ルールの対応の進め方について考える
警告じみたメッセージが消えるよう「全ての項目に目を通してリスクレベル: Low のものまで網羅して有効化していく」というのが究極の理想かもしれませんが、この対応はプライオリティの低い内容を多く含み大変なコストを要すことに加え初期導入のスピード大きく遅延させます。
そもそもの話ですが、管理者として先にやるべきことがあります。
それは「C1Cでクラウド環境のリスクを速やかに可視化し、リスクレベルの高いもの(例: Very High以上 )の対応を実環境で進める」事です。
例えばですが、C1Cを導入して環境のリスクを可視化し Very High以上の対処が全て終わってから、次のステップとして High-> Mediumとルールを徐々にチェックしていきましょうといった方針を定め、その時がきたら デフォルトで有効化されていない対象リスクレベルのルールについて確認しながら有効化を検討するといった形が、現実的な進め方の一つとして考えられます。
※Trend Micro社がそのような進め方を推奨している訳ではないのでその点はご注意ください
リスクレベルの指定が高いものを把握する
対象ルールの中で、一番高いリスクレベル: Very High が設定されている内容は執筆(2021/10)時点で以下二つのルールとなります。
この程度の数であれば短時間で設定が完了するので、初期導入のタイミングに考慮/有効化すべき事項として定めても良さそうです。
| ID | Rule | Risk Level |
|---|---|---|
| IAM-055 | Canary Access Token | Very High |
| RTM-011 | Unintended AWS API Calls Detected | Very High |
続けて、こちらの2つのルールの詳細について確認しながらどのように設定すべきかを考察していきます。
(参考)C1Cのリスクレベル
全体だと一番高いのはExtremeとなり、Very Highは二番目の内容となります。
| No. | Risk Level |
|---|---|
| 1 | Extreme |
| 2 | Very High |
| 3 | High |
| 4 | Medium |
| 5 | Low |
1. Canary Access Token (IAM-055)
ルールの詳細
以下オフィシャルの当該ルールに関する詳細ページとなります。
当ルールは、そもそもとしてこちらの設定がAWS環境にされている事を前提としているものとなりますので、未実施の場合は AWS環境で CanaryToken用のIAMユーザーが1つ作成されている状態とする 必要があります。
CanaryTokenとAWS環境にそれを仕掛ける際の設定に関する詳細は以下blogエントリーで紹介しています。
どのようなリスクと設定後の効果が考えられるか
上のblogを参考に作成されたCanaryToken用のAWS Identity and Access Management (以後IAM)ユーザーの設定が、意図せぬ操作であったり悪意のあるユーザーから侵害を受けるリスクがあり、その際にCanaryTokenとして機能しなくなる事が想定されます。
こちらのルールを設定しておくことで、設置したCnaryTokenとして管理しているIAMユーザーが正常な状態で存在し続けている事を監視出来ます。
設定が必要な内容
上のblogを参考に作成した CanaryToken用の IAMユーザー名を指定して有効化します。
注意点
他ポリシーとのバッティング
CanaryTokenは、用途が特殊なアクセスキーを発行するものとなります。
もし、アクセスキーを一定日数でローテーションを義務付けるようなルールがあったとしたらバッティングし、運用が煩雑になったりしますので例外処理として加える考慮をすると良いでしょう。
様々な場所にセンサーとして設置されたCanaryToken(アクセスキー)を定期ローテーションするという運用は厳しいと想定される為です。
IAMユーザーを複数指定は出来ない
C1C管理化とする全てのAWS環境でCanaryToken用のIAMユーザー名が一致している場合は、Organisation Profileに設定するだけで問題ないですが、異なる場合はAWSアカウント単位のルールで設定する必要があります。
リアルタイム検知は非対応であると理解する
こちらのルールについては、IAM側でも設定後に情報が反映されるまでしばらくタイムラグが発生する事もあり、リアルタイムで検知できる内容ではないルールとなります。
中のロジックまでは不明ですが、IAM側の認証情報レポートをの元となる情報をチェックをしている可能性があります。
2. Unintended AWS API Calls Detected (RTM-011)
ルールの詳細
以下オフィシャルの当該ルールに関する詳細ページとなります。
タイトル通り、管理者として意図しないAPIを指定して監視する といったルールになります。
理想を語るとそもそもとしてIAM等の権限コントロールを駆使してそのようなAPIを実行出来ないよう設計すべきですが、すべての網羅は難しく、セキュリティと利便性もトレードオフであり、強い権限を持つユーザーは何かしら必ず必要であり、行使するのも人間であればミスは起こります。
最小権限の原則を意識して運用することに加えて、C1Cで意図しないAPIアクティビティについてAWSアカウントを24時間年中無休で監視することが推奨されています。
どのようなリスクと設定後の効果が考えられるか
AWS環境の管理者としての考えや会社のポリシーで許容できない APIが叩かれてしまうリスクに対し設定後は、実行されるたびに検知が出来るようになります。
C1C上での通知例
Slackへの通知例
設定すべき値の考察
オフィシャルのルール詳細頁に例として書いてある内容が、多くのお客様が検討のはじめに使える良いベースになるように感じたので、転記してご紹介します。
| Item | Identity | Service | Event |
|---|---|---|---|
| (a) | IAM user | IAM | * |
| (b) | * | CloudTrail | DeleteTrail |
| (c) | IAM user | EC2 | StartInstances |
| (d) | * | * | "Create" "Delete" "Update" "Put" "Stop*" |
上から順に確認していきます。
(a) IAMUserによる IAMの全てのAPIを検知
権限管理について集約されているIAMは書いてある通り、すべて拾うというのは管理者として良い選択のように思えます。
特殊な環境を除き頻繁に変更される項目でもなく、管理者の知らないところで野良IAMユーザーのようなものが作成されてたり、セキュリティリテラシーの低い方が Administrator 相当のポリシーを付与してそのまま放置していたり、IAMロールを使うべきところをアクセスキー発行していたり、とセキュリティ事故に繋がるAPIアクティビティを管理者として受け取り予防に繋げる運用に組み込む事ができそうです。
(b) CloudTrail の DeleteTrailの検知
悪意のあるユーザーが、自分の不正ログの証跡を削除するようなアクティビティを検知可能となります。
ちなみに弊社(サーバーワークス)が構築している環境では、そもそも実行出来ないような制御を加えており、AWSパートナーに構築を依頼した場合はそのような環境も多いと思いますが、このようなオペレーションを試みる時点で悪意のある内部不正者の疑いがあるのでそれを検知できるようになるイメージで設定されるのが良いと思います。
(c) IAMUserによる既存EC2インスタンスの起動の検知
こちらは正直、多くの環境でフィットしないであろう内容なので 要調整 といった印象です。
StartInstancesは既に存在かつ停止状態のEC2インスタンスを起動した事を検知する内容となります。
StartInstances
自動か手動かはさておき日常的にやられているオペレーションである事も多く API監視するなら、新規作成や終了といったセキュリティやコストの面で影響がある内容が良いと思われます。
(d) 全てのユーザーから 全てのサービスで発生した Create,Delete,Update,Put,Stopの検知
AWS環境のリソースに対して何らの変更がされた際に検知出来る内容です。 かなり広範囲でHITする内容なので環境によっては確認しきれない大量の通知がされる場合があるので注意が必要です。
ここでいう全てのユーザーというのは、固有のIAMユーザー(IAMUser)だけでなく IAMロール等も含むとイメージ頂ければと思います。
例えばですが、アクセスキーが有効なIAMユーザー1つ作成するだけでも以下3点のAPIが検知される事となります。
CreateAccessKey
CreateLoginProfile
CreateUser
実際の設定値を考えていく
設定が必要な内容
実際の設定画面です。ルール設定の実画面は以下となり項目内容を指定して有効化する必要があります。(Add newを押下すると選択できる枠の行が追加されます)
上で紹介したオフィシャルの情報は、実際の設定画面とカラムが反転しているだけでなく、人間が理解出来るそれっぽいような記載をしてあるだけなので、実は上のサンプルの値をそのまま貼り付けても全く動作しません。
こちらはCloudTrail で APIログに出力される内容をベースに、必要に応じて正規表現を駆使しながら検知ルールを組み立てていく必要があります。
例として、EC2インスタンスを終了(Terminate)した時のAWS CloudTrail のAPIログから抜粋すると 以下の3項目の値を各項目に指定する必要があるという事です。
### snip "userIdentity": { "type": "IAMUser", ### snip "eventSource": "ec2.amazonaws.com", "eventName": "TerminateInstances", ###snip
このように管理者として検知したい内容と対象APIを紐付ける他、一定の正規表現力が求められます。
C1Cの正規表現を指定について以下ページを参照
今回は私の方で一旦、例として記載されている内容を解釈しながら、実際に動作する指定値に変換してみました。
| eventName | eventSource | userIdentityType |
|---|---|---|
| .* | iam.amazonaws.com | IAMUser |
| DeleteTrail | cloudtrail.amazonaws.com | .* |
| StartInstances | ec2.amazonaws.com | IAMUser |
| ^Create*|^Delete*|^Update*|^Put*|^Stop* | .* | .* |
設定イメージ
正規表現の | (or指定) でつないで1行もいいですが、表示出来る範囲が限られるUIやら変更ミスによる影響範囲を考えると行を分けたほうが人間視点で運用/管理しやすい場合もあるかもしれません。
(参考) 指定項目で重複する内容を検知した場合の挙動
重複検知する内容の場合、マッチした内容のいずれかで検知される挙動をするので通知は重複しません。
例えば、上の例の通り IAMのAPIを全て監視している状態で、 全てのAPIで ^Create* から始まるものを監視IAMユーザーを新規作成した場合は、2つのルールにマッチする形となりますが、後者の方で通知される形となりました。
中がどのようなロジックかまでは不明ですが、設定画面とは別に評価順が内部でソートされているのか eventNameのロンゲストマッチなのかもしれません。
自身の環境にあったルールの考察
実際に動作する指定内容が理解できたところで、上のオフィシャルのサンプルをベースに自分の環境にあったルールについて考察して必要に応じて設定していきます。
セキュリティに重点をおくスタイル
IAMのアクティビティを全て監視する以外で考えるとAWS Organization を利用している場合は以下の様に IAMと同等レベルに監視するのが良さそうです。
その場合、具体的に以下ルールの追加を検討します。
| eventName | eventSource | userIdentityType |
|---|---|---|
| .* | organizations.amazonaws.com | IAMUser |
それ以外にセキュリティの観点で監視したいサービスがあれば検討して追加します。
特定サービスの挙動検知に重点をおくスタイル
(c)のサンプルだと既存のEC2インスタンス起動のみ検知でしたが、実際の現場で管理者視点だと「新規作成」や「終了(ターミネート)」を検知したいケースのほうが多いと思われます。
その要件がある場合は、その特定サービスのAPIリファレンスを眺めながら検討し設定するのが良いでしょう。
(例) Amazon EC2 であれば以下APIリファレンス頁を参照 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/APIReference/Welcome.html
- 新規作成(ローンチ)の場合は、"eventName": "RuninateInstances"
- 終了(ターミネート)の場合は、"eventName": "TerminateInstances"
とお目当ての内容を確認できたら、これらを or条件(正規表現だと|) とかで指定していきます。 具体的に以下ルールの追加を検討します。
| eventName | eventSource | userIdentityType |
|---|---|---|
| ^Run*|^Terminate* | ec2.amazonaws.com | IAMUser |
(参考)完全一致文字列でもいいですが、前方一致とすることで今回の場合は以下のようなアクティビティも同時検知できたりするので上手く活用してください。
RunInstances
RunScheduledInstances
TerminateInstances
TerminateClientVpnConnections
同様に「稼働している重要なDBへのアクティビティについては把握したい」という要件があれば Amazon RDS、Amazon Redshift 等の実際利用しているサービスで必要な検知内容を検討し追加していきます。
まずは大規模な範囲(*)で仕掛けて運用しながら徐々に絞っていくスタイル
環境により大量に通知がされると思われますが、まずは以下のサンプル通りの設定で試し、実際に運用をしながら見極めて不要なものは絞っていくと考え方です。
具体的に上の(d)の例のまんまですが、以下ルールを適用して、運用してみます。
| eventName | eventSource | userIdentityType |
|---|---|---|
| ^Create*|^Delete*|^Update*|^Put*|^Stop* | .* | .* |
その後の絞り方は、単純に eventNameから不要な内容をカット(以下例だとPutを削除)でもいいですし、 eventSource に以下のように指定すれば Amazon EC2の内容を除外する事もできます。
| eventName | eventSource | userIdentityType |
|---|---|---|
| ^Create*|^Delete*|^Update*|^Stop* | ^(?!ec2).*$ | .* |
管理者視点でどのような内容のみ通知を受け取りたいか が明確になってから指定ルール(正規表現)を検討すると良いと思います。
また一文字でも変更したら、その行の検知の動作確認は忘れず実施することをオススメします。
RTM-011を設定後の運用について
通知を受け取った際の管理者としての以下例のようなアクションについても合わせて検討しておくと良いでしょう。
(例）
- 通知を受け取ったら必ず実環境に問題がない事を確認する
- 問題がなければ、その旨のコメントを残しつつ Supress する
- 問題があれば、実行者へ速やかにヒアリングを行う
通知を受け取る管理者視点で有益ではないものがあれば適宜設定を見直していくことも大切です。
(参考) RTM-011は特殊なルールである理解する
RTM-011は「管理者として検知したい内容」を自由に反映出来るC1Cの中でも特殊なルールです。
念の為APIアクティビティを把握したい程度で利用する場合、必ずしもデフォルト設定で「リスクレベル: Very High」として通知される事が好ましいとは言えません。
こちらのルールに限っては、用途に合わせてリスクレベルの手動変更あわせて検討したいところです。
まとめ
初期導入時に、考慮しておきたいデフォルトで有効化されていない重要なルール2点についての考察をご紹介しました。 C1C導入時の参考になれば幸いです。
