【New Relic】AWS Security Hubイベント情報を可視化する方法（後編）

はじめに

こんにちは、マネージドサービス部の福田です。
以下ブログの後編になります。
Amazon EventBridgeによりNew RelicへAWS Security Hubのイベント情報を送ることができたので 実際にどのように可視化されるのかについて紹介します。

blog.serverworks.co.jp

本ブログで得られること

• New Relic Parsing Rulesの概要、活用方法
• NewRelic Lookup Tableの概要、活用方法
• NewRelic に送られたAWS Security Hubのダッシュボードの例
• NewRelic に送られたAWS inspectorのダッシュボードの例

Parsing Rulesとは

ログデータから必要な情報を抽出し、検索やクエリ、アラート設定を効率化できます。
Grokパターン(正規表現ベース)を適用することで、ログデータを構造化し、より実用的な形で利用することが可能です

docs.newrelic.com

例: カスタムログ (SSHログイン試行)

元のログ

May 17 13:45:30 server sshd[12345]: Failed password for invalid user root from 192.168.1.1 port 22 ssh2

Grokパターン

%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} sshd\[%{POSINT:pid}\]: Failed password for %{DATA:auth_method} user %{USER:user} from %{IP:client_ip} port %{NUMBER:port} ssh2

解析結果

• timestamp: May 17 13:45:30
• hostname: server
• pid: 12345
• auth_method: invalid
• user: root
• client_ip: 192.168.1.1
• port: 22

NewRelic Lookup Tableとは

CSVファイルに記載された情報を、New Relicのデータと連携させることができる機能になります。

docs.newrelic.com

例: IPアドレスから地理情報を取得

問題: ログデータにクライアントのIPアドレスが記録されているが、その地理的な位置情報がわからない。
解決方法: Lookup Tableを使用して、CSVファイルからIPアドレスに対応する地理情報を取得します。

CSVファイルの例

ip_address,country,city,latitude,longitude
1.1.1.1,オーストラリア,シドニー,-33.8688,151.2093
8.8.8.8,アメリカ合衆国,マウンテンビュー,37.4056,-122.0775
93.184.216.34,オランダ,アムステルダム,52.3676,4.9041

Lookup Tableを利用しない場合

クエリ例

FROM Log
SELECT count(*) FACET client_ip

実行結果の例

client_ip       | count
----------------|-------
1.1.1.1         | 12345
8.8.8.8         | 67890  
93.184.216.34   | 2345

Lookup Tableを利用した場合

クエリ例

FROM Log 
JOIN (FROM lookup(csvTable) SELECT ip_address, country, city, latitude, longitude)
ON client_ip = ip_address
SELECT count(*) FACET country, city

実行結果の例

country    | city          | client_ip    | count
------------|---------------|--------------|---------
オーストラリア   | シドニー        | 1.1.1.1      | 12345
アメリカ合衆国    | マウンテンビュー | 8.8.8.8      | 67890  
オランダ         | アムステルダム   | 93.184.216.34| 2345

AWS Security HubからNew Relicに送られるログ

構造化されておらずNRQLとして使用が難しい

detail.findingsの内容をparsingRuleによって構造化してみる

使えそうなところを構造化してみる

なお、構造化した情報は以下です。

swx-sechub-remediation-url

ログからイベント詳細情報を抽出した内容になります。
上記例に表示されているリンクは以下になります
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/iam-controls.html#iam-21

swx-sechub-Resources

リソースのARN等をログから抽出した内容になります。

swx-sechub-severity-title

ログからイベントタイトルを抽出した内容になります。

swx-sechub-AwsAccountId

AWSアカウントIDをログから抽出した内容になります。。

swx-sechub-severity-label

ログからセキュリティの重大度ラベル（例えば "CRITICAL", "HIGH" など）を抽出した内容になります。

swx-sechub-ResourcesType

リソースのタイプ（例えば "S3", "EC2" など）をログから抽出した内容になります。

収集した情報をNew Relicでダッシュボード化してみた

以下情報をダッシュボード化しました。

• 発生したイベント数
• セキュリティレベル/リソースタイプの割合
• イベント発生数の推移
• イベント発生一覧（対象のリソース/イベント内容及び対処方法）

（おまけ）Lookup Tableを用いてAWS inspectorの検知一覧をNew Relicでダッシュボード化してみた

イベント詳細情報の例：https://jvndb.jvn.jp/ja/contents/2018/JVNDB-2018-010717.html
なんとなく見えやすいですが以下懸念があるので運用するとしたら仕組化が必要になります

• CSVファイルに記載されているイベント以外はダッシュボードに表示されない
• セキュリティイベントが増えるたびにCSVファイルの更新が必要

上記の改善案

共通脆弱性識別子CVE番号とJVN iPediaのURLを同じダッシュボードに表示する
イベントID項目のCVEをコピー→JVN iPediaにて検索→CVE詳細情報および対処方法を確認

さいごに

まだまだ改善の余地がありますが今回の検証を通してNew RelicへAWS Security Hubの情報を送りイベント発生個所、イベント情報、対応方法（Nextアクション）について 可視化することができました
同じようなやり方でGuardDuty やCloudTrail、Config等の可視化も可能になります。

New RelicもVulnerability Managemenなどセキュリティに関する機能も増えてきておりますので 今後はSIEM製品としても活用できるようになるのでしょうか。

newrelic.com

宣伝

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

福田 圭 (記事一覧)

マネージドサービス部

2023 New Relic Partner Trailblazer

X @soundsoon25