メインコンテンツまでスキップ
Sumo Logic Japanese

AWS Security Hub への知見の送信

このページでは、Sumo Logic を知見プロバイダとして有効化する方法、AWS Security Hub フォワーダーをデプロイする方法、Webhook 接続を作成する方法、および Scheduled Search を作成する方法を説明します。

AWS Security Hub フォワーダーは、Scheduled Search の結果やアラートを知見として AWS Security Hub に送信します。このページでは、次のトピックについて説明します。リンクをクリックして、各セクションに移動してください。

AWS Security Hub フォワーダーの概要

AWS Security Hub フォワーダーは、Lambda 関数とともに Identity Access and Management (IAM) 認証で保護された API ゲートウェイ エンドポイントを作成します。Sumo Logic の Scheduled Search は、Webhook for Lambda を使用して結果をこのエンドポイントに送信します。トリガされた Lambda 関数は、検索結果を parse して、Amazon Finding Format (AFF) に変換します。AFF データの各行は、知見として AWS Security Hub に送信されます。

AWS_SecurityHubForwarder_collection_overview2.png

ステップ 1: 知見プロバイダとしての Sumo Logic の有効化

AWS Security Hub は、AWS アカウントで Security Hub を有効にすると生成されるこれらのセキュリティ知見を、サポートされている AWS サービスから検出して統合します。このセクションでは、AWS Security Hub と通信する AWS 知見プロバイダ (FP) として Sumo Logic を有効化する方法を説明します。

Sumo Logic で AWS Security Hub を有効にするには、次の手順を実行します。
  1. Security Hub コンソール (https://console.aws.amazon.com/securityhub) を開いて [Settings (設定)] > [Providers (プロバイダ)] を選択します。
  2. 「Sumo Logic」を検索して、Sumo Logic Machine Data Analytics に対して [Subscribe (サブスクライブ)] をクリックします。

AWS_SecurityHub_Providers_dialog.png

ステップ 2: AWS Security Hub フォワーダーのデプロイ

このセクションでは、AWS SAM 仕様に基づいたサーバレス アプリケーションである AWS Security Hub フォワーダーをデプロイする方法を説明します。 

AWS Security Hub フォワーダーをデプロイするには、次の手順を実行します。 
  1. ブラウザ ウィンドウを開いて、次の URL に移動します。https://serverlessrepo.aws.amazon.com/applications
  2. [Serverless Application Repository (サーバレス アプリケーション リポジトリ)] で、「sumologic」を検索します。 
  3. [Show apps that create custom IAM roles or resource policies (カスタム IAM ロールまたはリソース ポリシーを作成するアプリケーションを表示)] チェック ボックスをオンにし、
    sumo-logic-securityhub-forwarder アプリケーション リンクをクリックして、[Deploy (デプロイ)] をクリックします。 

AWS_Serverless_Repository.png

  1. スタックがデプロイされたら、[CloudFormation] > [Stacks (スタック)] > [Stack details (スタック詳細)] > [Outputs (出力)] に移動して SecurityHubForwarderApiUrl の値をコピーします。これが API ゲートウェイ エンドポイントとなります。

AWS_ServerlessRepo_APIendpoint.png

ステップ 3: Webhook 接続の作成

このセクションでは、AWS Lambda 関数をトリガするための Webhook 接続を作成する方法を説明します。

Webhook 接続を作成するには、次の手順を実行します。
  1. 手順に従って Webhook 接続を作成し、ステップ 4 の値を URL として使用します。
  2. 次のペイロードが定義されていることを確認します。
{"Types": "<type> Ex: Software and Configuration Checks/Industry and Regulatory Standards/PCI-DSS Controls",
 "Description": "{{SearchDescription}}",
 "SourceUrl": "{{SearchQueryUrl}}",
 "GeneratorID": "{{SearchName}}",
 "Severity": <number from 0 to 100>,
 "Rows": "{{AggregateResultsJson}}",
 "ComplianceStatus": "(Optional)<status> - PASSED/WARNING/FAILED/NOT_AVAILABLE"
}

Types、Description、SourceUrl、GeneratorID、Severity、および Compliance。Status は、Amazon Finding Format で指定されている対応フィールドにマップされます。

  1. Amazon ドキュメントの「API を呼び出すためのアクセスの制御」の説明に従って、IAM ロールまたは (資格情報を使用する) IAM ユーザに API Gateway での API を呼び出す権限が付与されていることを確認します。

ステップ 4: Scheduled Search の作成

検索を保存する際に、周期的に実行するためのスケジュールとアラートを追加できます。このセクションでは、AWS Security Hub 用のクエリを作成してから、Scheduled Search を作成する方法を説明します。

この検索の目的は、セキュリティやコンプライアンスの問題が発生した時点で検出し、影響を受けるリソースを特定することです。  

次の例では、保護されているポートに対して外部トラフィックが直接送信されており、PCI 要件チェックの 1 つに違反するという知見がクエリによって生成されます。

_sourceCategory=Labs/AWS/VPC ACCEPT (3306 or 5439 or 5432 or 1433 or 2638 or 5984)
| json "message" as _rawvpc nodrop | if (_raw matches "{*", _rawvpc,_raw) as message
| parse field=message "* * * * * * * * * * * * * *" as version,aws_account_id,interfaceID,src_ip,dest_ip,src_port,dest_port,Protocol,Packets,bytes,StartSample,EndSample,Action,status
| where Action="ACCEPT" and dest_port in ("3306", "5439", "5432", "1433", "2638", "5984")
| where (compareCIDRPrefix("172.16.0.0", dest_ip, toInt(12)) or compareCIDRPrefix("192.168.0.0", dest_ip, toInt(16)) or compareCIDRPrefix("10.0.0.0", dest_ip, toInt(8)) and (dest_port in ("3306", "5439", "5432", "1433", "2638", "5984")))
| where (!compareCIDRPrefix("172.16.0.0", src_ip, toInt(12)) and !compareCIDRPrefix("192.168.0.0", src_ip, toInt(16)) and !compareCIDRPrefix("10.0.0.0", src_ip, toInt(8)))
| "Direct external traffic to secure port" as message | "Critical" as Severity
| concat("PCI Req 01: Traffic to Cardholder Environment: Direct external traffic to secure port on ", dest_ip) as title   
| _messagetime as finding_time
| dest_ip as resource_id
| "AwsEc2Instance" as resource_type  
| count by finding_time, resource_id, resource_type, title, aws_account_id
| fields -_count 
クエリを作成してから Scheduled Search を作成するには、次の手順を実行します。
  1. AWS Security Hub ドキュメントの説明に従って、以下の必須フィールドを含む検索クエリを作成します。
"finding_time", "resource_type", "resource_id", "title"
  1. このドキュメントの説明に従って Scheduled Search を作成し、次の設定を行います。
  • アラート条件は [Greater than > (より大きい)]、[Number of Results (結果数)] は 0 に設定します。
  • [Alert Type (アラート タイプ)] は [Webhook] に設定します。
  • [Connection (接続)] は (リンク先ドキュメントの説明の) ステップ 2 で設定した名前に設定します。
  • ペイロードのカスタマイズ ボタンを切り替えて、次のダイアログのフィールドに入力します。各フィールドの意味を下表に示します。
タイプ 形式名前空間/カテゴリ/クラシファイアの知見のタイプ。このフィールドの値は、AWS ドキュメントの知見タイプの分類で定義されているいずれかの知見タイプと一致しなければなりません。
説明 知見のインスタンスに特有の詳細です。入力は必須です。
SourceURL 知見を生成した知見そのものを参照する検索クエリの URL です。
GeneratorID この知見を生成した Scheduled Search 名です。
Severity (重大度) 知見が顧客に与える影響 (データ消失、マルウェア アクティビティ、設定の脆弱性など) です。0 ~ 100 の整数として表示されます。
ComplianceStatus コンプライアンス チェックの結果です。省略可能であり、値は次のいずれかになります。PASSED/WARNING/FAILED/NOT_AVAILABLE

 

AWS_SecurityHub_PCIReq01-dialog.png

トラブルシューティングのヒント

問題が発生したら、次の順序で原因を特定してください。

  1. モック データ (次の JSON サンプルなど) を使用して API をテストします。

{
    "Types": "Software and Configuration Checks/Industry and Regulatory Standards/HIPAA Controls",
    "Description": "This search gives top 10 resources which are accessed in last 15 minutes",
    "GeneratorID": "InsertFindingsScheduledSearch",
    "Severity": 30,
    "SourceUrl":"https://service.sumologic.com/ui/#/search/RmC8kAUGZbXrkj2rOFmUxmHtzINUgfJnFplh3QWY",
    "ComplianceStatus": "FAILED",
    "Rows": "[{\"Timeslice\":1542719060000,\"finding_time\":\"1542719060000\",\"item_name\":\"A nice dashboard.png\",\"title\":\"Vulnerability: Apple iTunes m3u Playlist File Title Parsing Buffer Overflow Vulnerability(34886) found on 207.235.176.3\",\"resource_id\":\"10.178.11.43\",\"resource_type\":\"Other\"},{\"Timeslice\":\"1542719060000\",\"finding_time\":\"1542719060000\",\"item_name\":\"Screen Shot 2014-07-30 at 11.39.29 PM.png\",\"title\":\"PCI Req 01: Traffic to Cardholder Environment: Direct external traffic to secure port on 10.178.11.43\",\"resource_id\":\"10.178.11.42\",\"resource_type\":\"AwsEc2Instance\"},{\"Timeslice\":\"1542719060000\",\"finding_time\":\"1542719060000\",\"item_name\":\"10388049_589057504526630_2031213996_n.jpg\",\"title\":\"Test Check Success for  207.235.176.5\",\"resource_id\":\"10.178.11.41\",\"resource_type\":\"Other\"}]"
}
  1. 応答本文でステータス コード 200 を探し、API Gateway と Lambda が正常に統合されていることを確認します。コンソールで API Gateway をテストする方法の詳細については、こちらのドキュメントを参照してください。

AWS_SecurityHub_ScheduledSearch_Troubleshooting.png

  1. Sumo Logic で次のクエリを使用して、Scheduled Search のログをモニタリングします。これにより、Scheduled Search がトリガされたかどうかを確認できます。

_view=sumologic_audit "Scheduled search alert triggered" <webhook_name>
  1. Lambda 関数の CloudWatch ログを確認します。Sumo は、Lambda 関数のログを CloudWatch のログ グループ「/aws/lambda/<function_name>」に保存します。このログで、Lambda の実行中にエラーが発生していないか確認してください。