【New Relic×Amazon Bedrock】AWS Security Hubの要約した内容をNew Relicへ送り可能性を感じた話

記事タイトルとURLをコピーする

はじめに

こんにちは。マネージドサービス部の福田です。
みなさんはセキュリティイベントをどのように可視化されていますか?

以前、以下のブログでセキュリティイベントの可視化について取り組んだのですが
イベントが発生したことは分かっても、その後の具体的なアクションが分かりづらく結局AWSのコンソール画面に入って確認するなど
ダッシュボード上で「何が発生したのか」「何をすればいいのか」の流れが上手く完結出来ない課題があり、計画が途絶えていました。

blog.serverworks.co.jp

blog.serverworks.co.jp

ただ最近、Amazon Bedrockを活用してイベント情報を要約し、それを可視化することでこの課題が解決できるのではないかと思い、実践してみました。
本ブログではその取り組みについてご紹介します。

構成図

実現するにあたって以下構成を想定しました。
本ブログではLambdaを使用して可視化した内容についてご紹介します。

Step FunctionでもNew Relicへデータを送ることは出来ましたがデータの構造化が上手くいかなかったので Step Functionは後日改良してLambdaと同じような内容を実現できるようにする予定です。

ちなみに以下構成でNew Relicへデータを送ることは出来ました。
(構造化したつもりでもうまくデータ構造化ができなかったは悔しい)

(参考)Amazon Bedrockの料金試算例(東京リージョン/Anthropic Claude 3.5 Sonnetモデル)

aws.amazon.com

Amazon Bedrockは、主に2つの料金モデルがあります。

  1. オンデマンド価格:

    • 利用した分だけ支払う柔軟な料金体系。
    • 入力トークンと出力トークンごとに課金されます。
  2. バッチ価格:

    • 大量処理向けに50%割引された料金。
    • バッチ処理は、入力トークンと出力トークンそれぞれで割引が適用されます

料金詳細

利用形式 1,000入力トークンあたりの料金 1,000出力トークンあたりの料金 備考
オンデマンド $0.003 $0.015 標準料金
バッチ処理 $0.0015 $0.0075 50%割引
キャッシュ書き込み $0.00375 N/A 書き込み時のみ課金
キャッシュ読み取り $0.0003 N/A 読み取り時90%割引

試算例

オンデマンド利用の場合

入力トークン数 出力トークン数 入力コスト ($) 出力コスト ($) 合計コスト ($)
10,000 5,000 0.03 0.075 0.105
100,000 50,000 0.30 0.75 1.05

バッチ処理の場合

入力トークン数 出力トークン数 入力コスト ($) 出力コスト ($) 合計コスト ($)
10,000 5,000 0.015 0.0375 0.0525
100,000 50,000 0.15 0.375 0.525

Amazon Bedrockによる要約

利用した生成AIモデル

Anthropic Claude 3.5 Sonnetモデルを使用しました。

Bedrockによる要約の流れ

  1. AWS Security Hubからの情報取得
    • 特定条件(例: コンプライアンスステータスが「FAILED」、重要度が「CRITICAL」または「HIGH」など)に基づき検出結果を取得。
  2. Bedrockでの解析
    • イベント内容を要約し、推奨される対応方針をJSON形式で出力。
  3. New Relic用フォーマットへの変換
    • 要約結果をNew Relicログ形式に整形。
  4. New Relicへの送信
    • 整形済みログをNew Relicに送信し、ダッシュボード上で可視化。

Lambda実行時のログ

New Relicへ送られたログ例

New Relicへ送られる情報としてBedrock処理データは「bedrock.xxx」Security Hubから取得した情報は「aws.xxx」と明確化しております。

{
  "aws.accountId": "xxxx",
  "aws.associatedStandards": "[]",
  "aws.complianceStatus": "N/A",
  "aws.description": "A process is querying a domain name associated with a known Command & Control server.",
  "aws.findingId": "arn:aws:guardduty:ap-northeast-1:xxxx:detector/8cbf263a94caaf7bea2e0496d87b6897/finding/2d07b45bf63d4e2b97ea3653e54979ae",
  "aws.lastUpdatedAt": "2025-01-02T12:26:01.458Z",
  "aws.message": "N/A",
  "aws.productName": "GuardDuty",
  "aws.region": "ap-northeast-1",
  "aws.resourceArn": "[\"N/A\"]",
  "aws.resourceId": "[\"arn:aws:ec2:ap-northeast-1:xxxx:instance/i-99999999\"]",
  "aws.resourceType": "[\"AwsEc2Instance\"]",
  "aws.service": "SecurityHub",
  "aws.severity": "HIGH",
  "aws.title": "A Command & Control server domain name was queried by EC2 instance i-99999999.",
  "bedrock.impact": "この活動は、EC2インスタンスが悪意のあるアクターに制御されている可能性を示しており、データ漏洩やさらなる攻撃の拡大につながる恐れがあります。",
  "bedrock.productName": "GuardDuty",
  "bedrock.recommendation": "1. 該当のEC2インスタンスを即時に隔離し、ネットワークから切り離してください。\n2. フォレンジック調査を実施し、マルウェアの有無や侵入経路を特定してください。\n3. インスタンスのイメージを取得し、詳細な分析を行ってください。\n4. 必要に応じて、インスタンスを終了し、クリーンな状態から再構築することを検討してください。\n5. セキュリティグループとNACLを見直し、不要な通信を制限してください。\n\nAWS公式ドキュメント:\nhttps://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-ec2.html",
  "bedrock.severity": "HIGH",
  "bedrock.summary": "EC2インスタンス(i-99999999)が既知のCommand & Control (C&C)サーバーのドメイン名に対してDNSクエリを実行しました。これは潜在的なマルウェア感染やセキュリティ侵害を示唆しています。",
  "logtype": "security-findings",
  "newrelic.source": "api.logs",
  "plugin.version": "1.0.0",
  "service": "AWS Security Hub",
  "timestamp": 1736235445163,
}

作成したダッシュボード

以下のような情報を可視化するダッシュボードを作成しました。

ダッシュボード内容

  1. イベント発生数およびリソース割合
  2. イベント発生数の推移
  3. 発生したイベントの詳細情報

ダッシュボード変数の使用

AWSアカウントやイベントレベルごとに表示内容を切り替えられるようにしました。

イベント発生数およびリソース割合の把握

発生したイベントの詳細情報

以下情報が確認可能です。

概要:Tor出口ノードIPアドレスからKubernetes APIが呼び出され、Impact(影響)タクティクスで一般的に使用されるAPIが実行されました。

必要なアクション例:1. 該当するKubernetesクラスターのセキュリティ設定を確認し、必要に応じて強化してください。
2. Tor出口ノードからのアクセスを制限するためのネットワークポリシーを実装してください。
3. Kubernetes APIサーバーのログを詳細に調査し、不審なアクティビティがないか確認してください。
4. IAMロールとKubernetesのRBACポリシーを見直し、最小権限の原則に従って設定してください。

AWS EKSのセキュリティベストプラクティスについては、以下のAWS公式ドキュメントを参照してください:
https://docs.aws.amazon.com/eks/latest/userguide/security.html

問題:攻撃者がTorネットワークを使用してKubernetesクラスターにアクセスし、潜在的に有害な操作を実行している可能性があります。これにより、データ漏洩、リソースの不正使用、またはクラスターの破壊などの影響が生じる可能性があります。
}

以下情報が確認可能です。

概要:AWS Configが有効化されていないか、正しく設定されていません。これにより、AWSリソースの設定変更の追跡や監査が行われていない可能性があります。

必要なアクション例:AWS Configを有効化し、すべてのリソースを記録するように設定してください。また、AWS Configのサービスリンクロールを使用するように設定してください。詳細な手順については、以下のAWS公式ドキュメントを参照してください:https://docs.aws.amazon.com/console/securityhub/Config.1/remediation

問題:リソースの設定変更の追跡ができず、セキュリティリスクや規制要件への違反を見逃す可能性があります。また、インシデント対応や問題解決が困難になる可能性があります。

Bedrockの処理が失敗した場合(Lambda側で以下状態になった場合)

Bedrockでの処理失敗=New Relic連携失敗は避けたいのでBedrockでの処理失敗時は Bedrock以外の情報が連携されるようにしました。
情報を表示されるようにしました。

以下はNew Relicへ送られた情報です。
※New Relicへ送られる情報としてBedrock処理データは「bedrock.xxx」Security Hubから取得した情報は「aws.xxx」と明確化しております。

{
  "aws.accountId": "xxxx",
  "aws.associatedStandards": "[]",
  "aws.complianceStatus": "N/A",
  "aws.description": "A sequence of actions involving 14 signals indicating a possible credential compromise one or more S3 bucket(s) was observed for IAMUser/john_doe with principalId xxxxE in account 111122223333 between eventFirstSeen and eventLastSeen with the following behaviors:   - 5 MITRE ATT&CK tactics observed: Exfiltration, Impact, Persistence, Defense Evasion, Discovery   - 5 MITRE ATT&CK techniques observed: T1526 - Cloud Service Discovery, T1098 - Account Manipulation, T1078.004 - Valid Accounts: Cloud Accounts, T1485 - Data Destruction, T1530 - Data from Cloud Storage   - Connected from a known Tor Exit Node: 10.0.0.1   - 7 sensitive APIs called: s3:DeleteObject, s3:GetObject, s3:PutBucketPublicAccessBlock, cloudtrail:DeleteTrail, iam:AttachUserPolicy, s3:ListObjects, s3:ListBuckets ",
  "aws.findingId": "arn:aws:guardduty:ap-northeast-1:xxxx:detector/xxxxding/xxx
  "aws.lastUpdatedAt": "2025-01-02T12:26:01.461Z",
  "aws.productName": "",
  "aws.region": "ap-northeast-1",
  "aws.resourceArn": "[\"N/A\",\"N/A\",\"N/A\"]",
  "aws.resourceId": "[\"arn:aws:s3:::EXAMPLE-BUCKET1\",\"arn:aws:s3:::EXAMPLE-BUCKET2\",\"arn:aws:s3:::EXAMPLE-BUCKET3\"]",
  "aws.resourceType": "[\"AwsS3Bucket\",\"AwsS3Bucket\",\"AwsS3Bucket\"]",
  "aws.service": "SecurityHub",
  "aws.severity": "CRITICAL",
  "aws.severityNormalized": 90,
  "aws.title": "Potential data compromise of one or more S3 buckets involving a sequence of actions associated with IAMUser/john_doe.",
  "bedrock.impact": "",
  "bedrock.recommendation": "",
  "bedrock.summary": "",
  "CustomMessage": "Security Hub Finding - Title: Potential data compromise of one or more S3 buckets involving a sequence of actions associated with IAMUser/john_doe., Compliance Status: N/A",
  "logtype": "security-findings",
  "newrelic.source": "api.logs",
  "plugin.version": "1.0.0",
  "service": "AWS Security Hub",
  "timestamp": 1736235024888
}

個人的に感じたこと

良かった点

  • セキュリティイベント発生時、「何が起きたか」「何をすべきか」がわかりやすくなった。
  • AIによる要約とダッシュボード表示によって、全体像と詳細情報が一目で把握できる仕組みが構築できた。

課題

  1. AI要約の正確性への懸念

    • Bedrockによる要約結果が誤っている場合、それに基づいた対応が間違った方向に進む可能性があるなと感じました。
  2. 運用時の注意点

    • 「1」の懸念があるのでAI生成情報であることを明示しつつ(AI情報は補足情報として扱う)、原文(AWS Security Hub検出結果)も一緒に表示必要があると感じました。
      以下はそのアラート通知文の例です。

      以下のようなAWS原文を表示する
      ・タイトル:AWS Config should be enabled and use the service-linked role for resource recording
      ・概要:This control checks whether AWS Config is enabled in your account in the current AWS Region, records all resources that correspond to controls that are enabled in the current Region, and uses the service-linked AWS Config role.
      ・イベントレベル:CRITICAL
      ・リソースタイプ:["AwsAccount"] など
      
      -----
      ■AIによる要約
      ・概要:AWS Configが有効化されておらず、設定レコーダーがオンになっていません。これは、CIS AWS Foundations Benchmark v1.2.0/2.5の要件に違反しています。
      ・問題:リソースの構成変更の追跡ができず、セキュリティ監査やコンプライアンス確認が困難になります。また、潜在的なセキュリティリスクを見逃す可能性が高くなります。
      ・必要なアクション:AWS Configを有効化し、すべてのリソースを記録するように設定してください。また、AWS Configのサービスリンクロールを使用するように設定してください。詳細な手順については、提供されたAWS Security Hubのドキュメント(https://docs.aws.amazon.com/console/securityhub/Config.1/remediation)を参照してください。
      ・ダッシュボードリンクなど
      -----
      

まとめ

Amazon Bedrockを使用することでSecurity Hubの情報がいい感じに要約することが可能になりました。
一方でBedrock自体の正確性や処理漏れ等Bedrock自体の監視が必要だなと感じました。
また通知頻度が高いとBedrockのコスト増加につながるのでその辺りの考慮も必要そうです。

とはいえ便利であることは変わりないのでBedrockを組み合わせたシステム運用方法を確立していきたいですね。

宣伝

弊社では、お客様環境のオブザーバビリティを加速するための伴走型のNew Relic導入支援サービスなどもご提供しております。 もしご興味をお持ちの方は、こちらのサービスご紹介ページの一番下にあるお問合せフォームよりお問合せ頂けましたら幸いでございます。

福田 圭 (記事一覧)

マネージドサービス部

2023 New Relic Partner Trailblazer

X @soundsoon25

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });