jonrau1/syntheticsunサーバーレスAWSセキュリティ自動化フレームワーク。脅威インテリジェンスを取り込み、MLベースの異常検知（RCF、IP Insights）を適用し、Kibanaでセキュリティテレメトリをエンリッチして、自動化された脅威の予防、検出、対応を実現します。
SyntheticSunは、多層防御のセキュリティ自動化および監視フレームワークであり、脅威インテリジェンス、機械学習、マネージドAWSセキュリティサービス、サーバーレステクノロジーを活用して、継続的に脅威を予防、検出、対応します。
君は砕けたガラスの中で眠る
自分自身の反射と共に
でも生きていると感じているのか？
ああ、聞かせてくれ
生きていると感じているのか？
- Norma Jean, 2016
SyntheticSunは、Malware Information Sharing Platform（MISP）とAnomaliのLIMOの使用を基盤としています。これらはコミュニティ主導の脅威インテリジェンスプラットフォーム（TIP）であり、さまざまなタイプの侵害指標（IoC）を提供します。正規化および重複排除された脅威インテルは、ほぼリアルタイムで照合され、さまざまなタイプのネットワークトラフィックにおける既知の脅威を迅速に特定します。潜在的な脅威の特定に動的な要素を加えるために、IP Insightsモデルがデプロイされ、IPアドレスとエンティティ（IAMプリンシパルID、ユーザーエージェントなど）のペアリングにおける異常（およびその中の潜在的な脅威）を見つけます。また、Elasticsearch内のネイティブRCF検出器を使用して、セキュリティテレメトリがKibanaにストリーミングされる際のほぼリアルタイムでの異常を検出します。セキュリティチーム内でのMLモデルの利用と微調整を民主化するために、IP Insightsモデルをトレーニングするユーティリティがコアソリューションへのアドオンとして提供されています。
セキュリティテレメトリのオーケストレーションと自動化、ならびにKibanaへの抽出、変換、ロード（ETL）を実行するために、AWS Lambda、Amazon DynamoDB、AWS CodeBuildなどのさまざまなAWSサーバーレステクノロジーが使用されています。これらのサーバーレステクノロジーは、スケーラビリティ、使いやすさ、重いMapReduceやGlue ETLベースのソリューションに比べて比較的安価であることから選ばれています。ソリューションの大部分はCloudFormationを介してデプロイされ、さまざまなステージ全体でPythonとシェルのヘルパースクリプトが提供され、採用と継続的インテグレーションパイプラインへのデプロイの可能性を促進します。
ソリューションの「内臓」を可能な限り軽量にするため、boto3、requests、json、ipaddress、socket、reなどの基本的なPythonモジュールが、下流サービスへの抽出、変換、ロード（ETL）の大部分を実行します。すべての地理位置情報情報はip-api.comによって提供されるため、アカウントや有料階層は不要で、応答ヘッダーにスロットリング情報を含む優れたAPIを備えています。ElasticsearchとKibanaの依存関係の大部分もコード内で提供され（インデックス、マッピング、可視化など）、手動での構成を回避しています。
SyntheticSunは、ソリューションの規模と必要な依存関係のため、3つのステージにわたっています。すべてのアーキテクチャとインストール手順（該当する場合はFAQも）は、それぞれのステージ内にあります。機能を拡張するためのアドオンモジュール（付録と呼ばれる）も提供されており、それぞれのアーキテクチャとインストール手順がローカライズされています。
SyntheticSunは、GitHubで見つけたものという性質上、概念実証であり、したがって最初のリリースでは絶対的な堅牢化まで手を加えていません。あなたがこの文書を読んでいる時点で、私が必要な変更をまだ行っていない場合は、このソリューションを本番環境（またはセキュリティ要件が高い環境）にデプロイする前に、以下の点を考慮してください。これらの項目はロードマップに載せ、適宜更新します。
SyntheticSunは、商用ツールに投資したり、セキュリティチームにデータサイエンティストを雇うことなく（理想的には後者を行うべきですが）、AWSクラウド上でサイバー脅威インテリジェンスと機械学習をエッジ保護のセキュリティユースケースに使い始めるための簡単な方法です。初期設定後、このソリューションは完全に自動化され、マシンスピードで脅威を特定し対応できます。最後に、このソリューションは、インシデント対応チームが脅威対応に使用するための基本的な可視化機能を提供します。例えば、悪意があると判断されたIPアドレスやドメインへの/からの許可されたインバウンド/アウトバウンド接続やDNSクエリなどです。ソリューションの核は非常に軽量な自動化とデータエンジニアリングパイプラインに依存しており、理論的には、多段階の正規化とエンリッチメントやスケジュールされた高速バッチジョブが必要な他の目的に再利用できます。
まず、Amazon GuardDutyやAWS WAFを利用している場合、このソリューションの評価は理にかなっていますが、必須でもあります。明らかなペルソナは、フルスタックのセキュリティ責任を負い、機械学習アルゴリズムのモデリング、トレーニング、デプロイ、またはサイバー脅威インテリジェンスフィードの意味のある運用化を行うための資本や専門知識が不足しているプロダクトチームです。前述のペルソナは、おそらくセキュリティエンジニアリング、SecOps/SOCアナリスト＆エンジニア、またはDevSecOpsエンジニアです。ただし、このリストは網羅的ではなく、プロダクト/アプリケーションに限定される必要はなく、中央チームもこれを利用できます。もう1つの用途は、同じペルソナ（SecOps、セキュリティエンジニアリング）が中央チームで働き、ファイアウォールや侵入防止システム用の動的ブロックリストを作成したい場合です。CodeBuildプロジェクトを再利用して、CSVまたはフラットファイルを任意の場所（Palo Altoファイアウォール、SquidフォワードプロキシURLフィルターなど）にドロップできます。
SyntheticSunは現在、主要なログソースすべてをカバーしていません。具体的には、S3アクセスログとCloudFrontアクセスログです。これらは多くの人（特にS3バケット上のSPA）がサービスを提供する方法に不可欠です。異常検知は、WAF、API Gatewayアクセスログ、CloudTrailを超えて拡張されていません。これは、IP Insightsへの執着と、データサイエンスのトレーニングがまったく不足しているためです（本当に、pandasやnumpyの使い方さえ知りません）。生の脅威インテリジェンスIoCの詳細な分析は、ログで一致を試みること以外にはありません。
このソリューションを組織にデプロイする最も簡単な方法は、一元化されたセキュリティサービスアカウントにデプロイすることです。VPCフローログやWAFログのような低レベルのテレメトリについては、AWS Service Catalogを介してヘルパースクリプトやCloudFormationテンプレートを提供し、下位環境での有効化を促進することを検討する必要があります。一元化された場所に公開するクロスアカウントのKinesis Data Firehose配信ストリームがある場合、Elasticsearch Serviceのシャード消費とインデックスローテーション、およびアクセス許可を評価する必要があります。私はこのソリューションを個人のサンドボックスアカウントで構築したため、上記の考慮事項のいずれもソリューションに組み込んでいません。この点を考慮したPRであれば喜んで作業し、将来自分で行うかもしれません。
2020年7月31日現在、AWS Firewall ManagerポリシーはWAFログ記録のマルチアカウント集約をサポートしており、これによりこのソリューションをより簡単にできるようになりました...
注意: 私はデータサイエンティストではなく、これは長い回答になります。要約すると、異常検出器であり、そうだと思います。
私はデータサイエンティストには程遠く、訓練も受けていないので、ドキュメントを読むことをお勧めします。とはいえ、私の素人なりの試みを以下に示します。IP Insightsは教師なし機械学習アルゴリズムであり、IPv4アドレスとエンティティ（例：アカウント番号、ユーザー名、ユーザーエージェント）の関係を学習します。そして、そのエンティティがそのIPv4アドレスを使用する可能性がどの程度かを判断しようとします。IP Insightsの背後にはニューラルネットワークがあり、これらのエンティティとIPv4アドレスの潜在的なベクトル表現を学習します。これらのベクトル化された表現間の距離は、エンティティがIPv4アドレスに関連付けられる（例：リクエストを送信する）ことが異常であるかどうかを象徴しています。
ニューラルネットワークは、その名の通り、人間の脳と同様に動作するように設計された機械学習システムであり、コンピュータ化されたニューロンとシナプスを備えています。教師なし機械学習では、アルゴリズムは、すべてのIPv4アドレスとそれらに関連付けられたエンティティの関連性を調べることで、「良い」（真陰性）と「悪い」（真陽性）を区別できます。この関連性は、他のベクトルと類似しているベクトルを「距離」によって特定するために評価されます。IP Insightsの場合、事前構築されたエンコーダが提供され、IPv4アドレスを検索し、すべてのエンティティをクラスターにハッシュ化します。次に、ベクトル化を使用してそれらを反復処理します。ベクトル化は、ループで処理する代わりに行列として計算を実行する方法です（数千万の値を含むリストの「For」ループを考えてください）。
IP Insightsモデルをトレーニングするとき、実際には、遠い距離（つまり高度に異常）で現実には発生しにくいIPv4アドレスとエンティティをペアリングすることで、モデルが偽陽性を自ら生成します。これにより、モデルは真陽性、偽陽性、真陰性を区別できるようになります。これは、「クロスエントロピー」（別名「対数損失」、これで良くなったように聞こえますか？）と呼ばれるもう1つのクレイジーな用語を防ぐためであり、二値分類という別の用語を導入します。IP Insightsは基本的に、「このIPアドレスとこのエンティティの組み合わせが異常である確率はどれくらいか？」と尋ねています。これが二値である理由だと思います。つまり、「はい、悪い」または「いいえ、悪くない」です。確率は0から1の間の値として表され、すべての機械学習モデルの目標はこれをできるだけ0に近づけることです。そのため、実際には1（既知の真陽性）であるものを0.01と予測すると、非常に高い対数損失が発生します。したがって、以上のことから、意図的にガベージデータを作成することで、IP Insightsはトレーニング中にその対数損失（つまり、悪い予測）を減らすのに役立ちます。
以上がエンドポイントからの出力につながります。クエリを実行すると（バッチまたはInvokeEndpointAPIを使用したほぼリアルタイムのいずれかで）、応答は負または正の値になり得る非有界浮動小数点数です。0より高いほど、異常である可能性が高く、そこからがあなたの作業の始まりです。このソリューションでは、私は0.03以上のものを選択しました。これはほとんど概念的なものですが、真実に近づくためには、エンドポイントに真陽性を提供し、応答が何であるかを確認する必要があります。その結果に基づいて、アプリケーションがスコアに応じて2要素認証を発行したり、アラートを発行したり、直接ブロックしたりする段階的アプローチを構成できます。質問の2番目の部分に対する答えは「はい、そう思います」です。ユーザーエージェントをIPとペアリングしてモデルをトレーニングすることは、実際にはかなり疑わしいです。一方、他の変動の少ないエンティティ（アカウント番号、ユーザー名、IAMユーザー）については、意図された使用法のように感じます。
ソリューションでは、使用すべきいくつかの例示的なフィードを提供しています。サイバー犯罪ドメインフィード、Emerging Threats、CI-badguysなど、いくつかはかなり明白です。私の実際の仕事では、世界で最も才能のあるサイバー脅威インテリジェンススペシャリストの一人（冗談抜きで彼女は素晴らしいです！）と協力しており、彼女も選択に影響を与えました。機械学習モデルや他の構築するものと同様に、脅威インテリジェンスフィードと集約を現在の脅威環境に合わせて調整する必要があります。重複はMISPで識別され、DynamoDBテーブルでは一意性を強制するためにハッシュキーのみが指定されているため、5つのフィードが同じIPv4アドレスを報告していても、テーブルには1つだけが入ります。
また、InfoBloxやRecorded Futureなどの商用脅威インテリジェンスプラットフォームやフィードを、同じ構文でDynamoDBテーブルに指定することで、このソリューションに持ち込むこともできます。
AWSからのログ配信のほとんどは「ベストエフォート」であり、公式なSLAは公開されていません。ただし、99.5〜99.9％程度であると想定され、最後の0.5〜0.1％は配信されない可能性があります。「本番」トラフィックもAWSでは最優先です。ネットワーク帯域幅の制約がある場合、ログを送信するよりもクライアントへの接続性を優先します。より可能性が高いのは、Lambdaが生ログファイル全体を処理するのに時間内に処理できなかったことです。これは、同じクライアントIPからのDOSやクローラーに攻撃されているときに多く見られます。WAFとALBは、私の知る限り、ログファイルを呼び出し元ごとにバンドルするため、数百のリクエストを吸収するとログファイルが非常に大きくなる可能性があります。
はい、ただし以下いずれかを実行する必要があります。
これには追加のコストがかかります。VPC内のLambda、特に数十の同時呼び出しでは、ENIが残存してRFC1918空間を消費する可能性が高く、より多くの問題を引き起こす可能性があります。コンプライアンス要件を満たすためにどうしてもすべてのトラフィックをVPC内に分離する必要がない限り、その道は進まないことをお勧めします。
はい、ソリューションを変更して、最終フォーマットされたログをKinesis Data Firehoseに公開し、それをSplunkにポイントすることで実現可能です。
将来、Route 53 DNSログ、S3アクセスログ、CloudFrontアクセスログ、API Gatewayアクセスログ、およびおそらく他のホストベースのログをサポートしたいと考えています。
正直なところ、Kinesis Data Agentを使用したかったのですが、多くの問題が見つかりました。Amazon Linux 2にはデフォルトで含まれておらず、Ubuntu 18.04 LTS AMIにはJava 11がプリインストールされているため、エージェントとの後方互換性の問題が発生し、OpenJDK 8または9がないとビルドに失敗します。CloudWatch Agentは、新しい機能で頻繁に更新され、構成用のSystems Managerドキュメントサポートがあり、インストール用のウィザードさえもあるため、インストールがはるかに簡単でした。AWSが将来的にKinesis Data AgentのサポートをCloudWatch Agentと同程度に真剣に取り組むなら、特定のホストベースのログ（Suricata、Squid、Nginx、Apache）については、CloudWatch Logsを中間層として使用するよりも、Kinesis Data Firehoseに直接公開したいので、切り替えるかもしれません。
Issuesまたはプロジェクトボードで「Help Wanted」とタグ付けされたアイテムのPRを喜んで受け付けます。プロジェクトの精神に沿っているものであれば、他の提案されたPRもレビューします。
SyntheticSunの微調整に貴重なフィードバック、テスト、貢献を提供してくださったDavid Dorsey氏とRyan Nolette氏に特に感謝します。
このライブラリはGNU General Public License v3.0 (GPL-3.0) の下でライセンスされています。LICENSEファイルを参照してください。
