はじめに
これまではAWS環境にIBM QRadar Community Edition V7.3.3を構築した話を投稿してきました。
SIEM製品にログ情報が何も見えないのはつまらないため、ここから実際にログソースを登録することも試してみたいと思います。
AWS CloudTrailとは何か?
AWSを触った方であれば、必須といっても良い監査ログ。AWS基盤においては最も重要となるAPI使用の監査情報になります。詳細は公式サイトをご参照下さい。
公式ドキュメントのCloudTrailサンプル例を見ると、実際に監査ログがどのように出力されているのか分かります。
例)IAM ユーザーである Alice が AWS CLI を使用して、CreateUser アクションを呼び出し、Bob という名前の新しいユーザーを作成した際の監査ログ
{"Records": [{
"eventVersion": "1.0",
"userIdentity": {
"type": "IAMUser",
"principalId": "EX_PRINCIPAL_ID",
"arn": "arn:aws:iam::123456789012:user/Alice",
"accountId": "123456789012",
"accessKeyId": "EXAMPLE_KEY_ID",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:11:59Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-2",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.3.2 Python/2.7.5 Windows/7",
"requestParameters": {"userName": "Bob"},
"responseElements": {"user": {
"createDate": "Mar 24, 2014 9:11:59 PM",
"userName": "Bob",
"arn": "arn:aws:iam::123456789012:user/Bob",
"path": "/",
"userId": "EXAMPLEUSERID"
}}
}]}
AWSではCloudTrailのベストプラクティスを以下のように提言しています。
- 証跡の作成
- 証跡をすべての AWS リージョンに適用する
- CloudTrail ログファイルの整合性の実現
- Amazon CloudWatch Logs と統合する
- 専有および一元化された Amazon S3 バケットへのログ
- AWS KMS で管理されたキーを使用したサーバー側の暗号化
- ログファイルを保存する Amazon S3 バケットへの最低限のアクセス権限を実装する
- ログファイルを保存する Amazon S3 バケットで MFA Delete を有効にする
- ログファイルを保存する Amazon S3 バケットにオブジェクトライフサイクル管理を設定する
- AWSCloudTrailFullAccess ポリシーへのアクセスを制限する
IBM QRadar SIEMにCloudTrailを取り込む場合、AWS側が推奨するCloudWatch Logsのアラート設定と若干被る部分も出てきますが、この辺りも実運用使い分けが出来ます。まず本編はQRadarにログソースとして追加し、CloudTrailを取り込むことを目的にご紹介します。
事前準備 - IBM QRadar
IBM QRadar側は以下の事前準備が必要です。
詳細はIBM QRadar DSMガイド AWS CloudTrailでご確認下さい。
- AWS CloudTrail DSMの導入(別投稿でご紹介しています。こちらをご参照下さい)
- AWS CloudTrailの証跡の有効化
- S3 BucketにCloudTrailが保管されていること
- CloudWatch LogsにCloudTrailが出力されていること
接続方式の比較 - メリット・デメリットを考える
ドキュメントを見ると幾つかの接続方法が掲載されていますが、AWSのテクノロジーとIBM QRadarに精通した方でないと中々分かり難い内容になっています。各方式について考えてみます。
-
S3直接接続方式
2. Amazon AWS CloudTrail log source that uses an S3 bucket with a directory prefix
2. CloudTrailの出力先であるS3 Bucketに対して直接ポーリングを行う方法
3. メリット
4. 設定がシンプルで分かり易い。
5. 切り分けなどが容易。
6. デメリット
7. マルチアカウントで束ねられている CloudTrail のS3 Bucketに未対応
8. リージョンは特定リージョンのみ -
S3->SQSポーリング形式
3. Amazon AWS CloudTrail log source that uses an S3 bucket with a directory prefix
4. S3 Bucketに更新されたCloudTrailファイルをAmazon SQSキューに通知し、QRadarはSQSキューを読み込む方法
5. メリット
6. マルチアカウント/複数リージョンに対応する
7. キューイングサービス経由で受け渡しを行うため、疎結合になっており耐障害性が高い。
8. デメリット
9. 設定がやや複雑(S3->SQS設定、IAM権限設定など) -
CloudTrail(CloudWatch Logs) -> Kinesis DataStream経由による方式
11. Adding an Amazon AWS CloudTrail log source by using the Amazon Web Services protocol and Kinesis Data Streams
12. CloudTrailの出力をCloudWatch Logsで行う
13. CloudWatchLogsからQRadarへ受け渡しを行う際に、Kinesis Streamにキューイングさせ、QRadarはキュー経由での受け渡しを行う。(疎結合)
14. メリット
15. マルチアカウント/複数リージョンに対応する
16. キューイングサービス経由で受け渡しを行うため、疎結合になっており耐障害性が高い。
17. デメリット
18. 設定が複雑(CloudWatch Logs->Kinesis設定、IAM権限設定など) -
CloudTrail(CloudWatch Logs) -> QRadar(Web Services Protocol収集)
20. Configuring an Amazon AWS CloudTrail log source by using the Amazon Web Services protocol and CloudWatch Logs
21. CloudWatch Logsに出力されているCloudTrailをQRadar側から読み込む
22. メリット
23. CloudWatch Logsを取り込む設定が容易。GuardDutyも同じ取り込み方法なので統一できる
24. デメリット
25. 疎結合ではない
昔はS3のRESTAPIだけだったのが選択が増えたため、どれを使うか迷われる方が多いのではと思います。
もし、本番環境のマルチアカウント環境に対して、CloudTrailの監視をIBM QRadarで行いたい、といった要望なのであれば 「2. S3->SQSポーリング形式」か、「3.CloudTrail(CloudWatch Logs)-> Kinesis DataStream」経由のどちらかかなと思います。
Splunkも取り込み方式が複数選べるのですが、パフォーマンスや受け渡し専用のキューイングを挟むことで障害切り分けもしやすくなる、といったメリットがあり、実践としてはSQS、Kinesisなどのサービスを経由させることが多いようです。
DSM設定を行う 〜 AWS CloudTrail
それでは QRadar に AWS CloudTrailの設定を行ってみます。方法はもっともシンプルな1)のS3 RESTAPI直接続を試してみました。筆者の環境は QRadar Community Editionでライセンス制約があり、大量のイベントを取り込めないことや、まずはシンプルに接続した上でステップ毎に検討してみるのが重要です。
実際の構成イメージは以下の通りです。
1. IAMロールの作成
今回、IBM QRadarはAWS環境のEC2にある想定で設定を行います。
EC2上にあるIBM QRadarから、CloudTrailのS3 Bucketにアクセスする場合、IAMロールの権限をEC2に設定することで、QRadar側にAPIのアクセスキー/パスワードを埋め込む必要が無くなります。
ドキュメントにあるIAMロールの例は以下です。Resource句のBucket名、AWSアカウントID、リージョン名などを収集する対象に変更しましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<bucket_name>",
"arn:aws:s3:::<bucket_name>/AWSLogs/<AWS_account_number>/CloudTrail/ap-northeast-1/*"
]
}
]
}
IBM QRadar DSM設定
ログソースを設定後、デプロイを行なって反映させます。
ログアクテイビィティから確認
無事、ログソース接続が行われると、IBM QRadarのログアクティビティ画面より CloudTrail のログ情報が取り込まれているのが分かります。
まとめ
今回、AWS用のDSMを用いてCloudTrailのログを取り込んでみました。
次回からは、実際に取り込んだログを活用した IBM QRadar の相関分析ルールを実践してみたいと思います。