コードとしての継続的コンプライアンス P1: Sigma

コンプライアンスは常にある種の受動的プロセスであり、基準は長く、更新には多大な労力と時間がかかり、実装にはさらに時間がかかり、監査プロセスは年に一度だけ発生します。SIEMの世界から来た私が、用意されたレポートを通じてコンプライアンスに取り組んでいると、通常は空の結果を返すか、外部監査人に説明するには程遠いものになりました。一方、レポートやクエリの根本的なロジックは不明瞭で、少なくともその維持には膨大な労力を要します。これを機能させるには、特定のSIEM技術とそれに付随するレポートエンジンの相関ルールエンジンまたはクエリ言語を習得し、実際の環境が動的であるのに対して、データを一箇所に集めるだけで数か月を要する可能性があるリストや例外を静的に大量に構成する必要があります。そしてこれらの作業が完了する頃には、SIEMテクノロジが変更されたり、旧式の「リアルタイム相関」ではなく、検索ベースのセキュリティ分析システムを使用する別の顧客と仕事をすることになります。VMスキャナーのようなコンプライアンス監査機能を備えたセキュリティ監査ツールを持っていると容易になります（例：Qualys Policy Compliance、Tripwireなど）。しかし、後者のツールは包括的またはリアルタイムの絵を描くことはなく、何らかのSIEMまたはセキュリティ分析プラットフォームと接続されていない限り難しいものです。そして、GRCの列車が大規模な製品とマン/イヤーのコンサルティング努力と共にやってきます。退屈です。コスト効率が悪いです。視認性に保証されたギャップがあります。私たちが暮らすデジタル時代には遅すぎます。そして、上記すべてがNIST CSFやGDPRを解決するのにどれほど有効でしょうか？個人的見解では、コンプライアンスはセキュリティの反映です。つまり、サイバーセキュリティを正しく行うことでコンプライアンスが続きます。しかし、これは逆には機能しません。変化の時ですか？はい。そして今日は、コンプライアンスを現代のデジタルビジネスに合った、敏捷で透明性が高く、コスト効率の高いプロセスにする一連の記事を始めましょう。

Sigmaルールの進化とコンプライアンスへのリンク

SIEM、SOC、そしてサイバーセキュリティタスクのためにSigmaルールの採用が加速していることは、セキュリティ業界で最もポジティブな変化の一つだと思います。そして、Sigmaがすでに脅威ハンティングクエリの事実上の標準であり、コンプライアンスの継続的な実践を確立するためにそれを適用するというクレイジーなアイデアを持っています。Sigmaを聞いたことがない方のために説明すると、それは簡単に理解でき、迅速に学べ、プラットフォームに依存せず、オープンソースの言語です。ルールの例とソースコード https://github.com/Neo23x0/sigma と開始するためのチュートリアル https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Elasticスタック、Splunk、ArcSight、QRadar、Qualys、Microsoft Windows Defender ATP、Logpoint、Greylogをお使いの場合、すでにSigmaルールをセキュリティやハントに役立てることができます。これらのプラットフォームはおそらくあなたの情報セキュリティ/ SOCの一部であり、コンプライアンスに使えるデータがたくさんあります。さらに、組織のさまざまな事業部門で使用されるElasticスタック、プレミアムまたはコミュニティ版がある可能性が高く、自動化されたコンプライアンスコントロールのデータを持つことができます。Sigmaの進化とグローバルな採用の重要な理由の一つは、そのMITRE ATT&CK https://attack.mitre.orgのネイティブサポートです。情報セキュリティの分野から来ていない方のために言えば、MITRE ATT&CKはサイバーセキュリティのブロックチェーンや化学の周期表のようなものです。したがって、オープンソースで広く採用された、どのSIEMのクエリ言語よりも学びやすく、ATT&CKの方法論でタグ付けをサポートするため、TTP属性を素早く行うことができる標準があります。コンプライアンスの基準に関連するタグを追加したらどうでしょうか？自動化されたコントロールをCSC 8.2によって照合したり、GDPRのために個人データを処理するシステムを見つけるクエリですか？Sigmaにとってそれは単に別のタグでしかないので、これは技術的に進化の次の論理的なステップです。

コンプライアンスのためにSigmaルールを書く方法

個人的にはSigmaの大きな支持者であることは秘密ではありませんが、現時点で私はそれほど多くのルールを書いているわけではありません。詳細なHOWTOガイダンスでは、私はAlex Yamposlkyiと短いチャットをしました。Alexは非常に活発なSigmaルールの開発者の一人で、開発したルールの量でFlorian Rothに次いで2番目です、彼は非常に実践的な洞察を提供してくれました。

AB: 「アレックス、コンプライアンスのためにすでに何かSigmaルールを開発しましたか？」
AY: 「はい、多忙な数ヶ月がありました。Sigmaの公式GitHubリポジトリでいくつかの例を見つけることができます: https://github.com/Neo23x0/sigma/tree/master/rules/compliance そして、SOC Prime Threat Detection Marketplaceで: https://tdm.socprime.com/?sigmaTypes[]=Compliance 」

AB: 「素晴らしい。コンプライアンスSigmaルールを作成するときに従う特定のアルゴリズムはありますか？」
AY: 「これを5ステップのプロセスとして説明することができると思います。

1. CISコントロールを初めに学ぶ https://www.cisecurity.org/controls/cis-controls-list/
2. 組織内のどのログソースが特定のコントロールの要件をカバーできるかを理解する。
3. 必要なイベントを探してSIEMプラットフォームを検索する。
4. 適切なイベントが発見されたら、ルールロジックを決定する: ログエントリがコンプライアンスにとって良いか悪いかに対応するイベントであるか確認する。自問して下さい: このログエントリコントロールは合格か不合格か？
5. 結果イベントをSigmaルールにコード化し、プラットフォーム固有の検索パラメータを削除してSIEMに依存しないようにする。アイテム#1からタグを追加し、自動検索をスケジュールします。」

AB: 「これだとすぐに成果が出るように聞こえます。これをステップバイステップの指示へ拡張できませんか？」
AY: 「はい。ここに簡単なメモがあります。

1. 構築しているコントロールの特定のドメインを選択します。たとえば「マルウェア対策」で、これはCSCのドメイン＃8に対応します。
2. このコントロールの説明をさらに掘り下げます。私たちのケースでは8.2が「組織のアンチマルウェアソフトウェアがスキャンエンジンとシグネチャデータベースを定期的に更新することを保証する」と読んでいます。
3. このコントロールを通過または失敗させるためにシステムで何が起こる必要があるかを考えます。8.2の場合、AVサービスが停止したり、更新にエラーがある場合はコントロールが失敗することを意味します。したがって、特にサービス停止や更新エラーイベントのAVイベントログを追跡する必要があります。
4. この特定のコントロールを追跡することは非常に簡単です。AV製品をインストールする必要があります。私の場合、これはLogstashを使用してElasticスタックに統合されたSymantec製品でした。しばらくログをソートした後、更新をダウンロードして展開するのに責任があるイベントを見つけ、その中には次の文字列が含まれていました「新しいコンテンツをダウンロード」、「更新先」。
5. これらのキーワードを含むフィールドを確認することで、簡単なElasticクエリを作成できます：(event.name:(“Downloaded new content”)) OR (event.name:(“An update for”))
6. 次に、ルールロジックに関する判断を行います: イベントがあることは良いのか悪いのか。私たちのケースでは、ログエントリがあることはポジティブで、コントロールが合格したことを意味します。プロセスを自動化するために、Sigmaルールをコード化し、プラットフォーム特有の保存済み検索メカニズムに適用します。私の場合、環境に特有の時間間隔でElasticスタックを走るWatcherをスケジュールします。
7. Sigmaルールを書きましょう
8. この例では、ある期間イベントが見つからない場合にはアラートをスケジュールすることが決定されるかもしれません。他の例では、状況が反対になるかもしれず、イベントが発見されたときにアラートが必要です。
9. 今、我々のルールにはすべての関連タグが必要で、以下の形式でそれらを追加することになりますタグ:
   – CSC8.2
   – attack.impact
   – attack.t1489

実際にATT&CKのタグとコンプライアンスのタグを混ぜることができます。上記の例では「CSC8.2」はCSCドメインごとの対応するコントロール番号です。「attack.persistence」はMITRE ATT&CKの作戦目標、「attack.t1053」はコントロールが焦点を当てている特定の手法です。

更新されたSigmaコードはこのようになりますルールをThreat Detection Marketplaceに公開すると、ルールのメタデータも「Parse Sigma Content tags」ボタンを押すことで生成されます。「タグ」リストでは、ISO、PCI、NIST CSFなどのコンプライアンス基準とルールを相互リンクできます。

我々の会話はさらに1時間続き、SOC Prime Threat Bountyプログラムについてのインタビューに必要な素材が十分にありました。それまで、Sigma for Complianceに対するフィードバックは大歓迎です。そして、Elastic stackでどのように最終結果が見えるかを少し覗かせるなら、以下のビデオをご確認ください https://my.socprime.com/en/continuous-compliance

/Stay safe