OCSF はセキュリティデータレークを民主化する鍵となるか?

セキュリティデータの取り込みと分析には多大な時間とリソースを要しますが、そうした状況を変えることを目指しているのが、オープンサイバーセキュリティスキーマフレームワーク (OCSF) です。この記事では、Salesforce のディテクション & レスポンス (DnR) チームが OCSF を試した際の所見を紹介します。
OCSF はセキュリティデータレークを民主化する鍵となるか?

現代のサイバー攻撃を検知し阻止するためには、さまざまなセキュリティツール間の連携が必要です。残念ながら、チームがこのセキュリティログデータの統合に費やす時間とリソースは、潜在的な攻撃を阻止するための分析に必要なコストとして受け入れられています。オープンサイバーセキュリティスキーマフレームワーク (OCSF) プロジェクトは、このような状況を変え、セキュリティチームが分析に費やす時間を短縮し、環境の保護に集中できるようにすることを目指しています。では、この新しいアプローチがなぜ重要でタイムリーであるかを見ていきましょう。

セキュリティログイベントデータが有用であるためには、ログに加えて、各ログに検索、集計、検出のために使用できるフィールドを定義するスキーマを持っている必要があります。たとえば、ネットワーク接続ログには、接続を開始した送信元 IP および要求への応答を受信して提供する宛先 IP が含まれます。スキーマには src と dest のようなフィールドがあるため、セキュリティアナリストはこれらのフィールドに関するクエリを作成できることがわかります。

ただし、これらのスキーマについては、ログのタイプまたはツール間でほとんど一致がありません。上の例で、CrowdStrike はネットワークログの 送信元 IP を ip として抽出し、宛先を RemoteAddressIP4 として抽出します。PAN ファイアウォールは、送信元 IP を src、宛先 IP を dst と呼びます。一部のログは完全に構造化されていないため、送信元 IP と宛先 IP は、ログ形式とログイベント内の IP の場所を理解することによってのみ決定できます。 

多くの場合、アナリストはログの大規模なサブセットに対してクエリを実行したいと考えます。たとえば、すべてのネットワークログから、特定の IP アドレスに接続したホストがあるかどうかを知りたい場合がそうです。このためには、ログのタイプごとにスキーマが必要なだけではなく、これらのスキーマが一致している必要があります。より少ない手作業でデータを取り込み、分析する良い方法はないのでしょうか。

ログの正規化の課題

これまで Salesforce は、「イベントデータディクショナリ」 (DDI) と呼ばれる複雑な内部ソリューションを使ってこの問題に対処してきました。DDI にはすべてのログのすべてのフィールドが一覧で記載されています。私たちはログを解析し、ディクショナリをスキーマとして適用するデータフィールド抽出 (DFE) ルールを定義しました。ディテクション & レスポンスアーキテクチャでは、このプロセスは「ノーマライザー」と呼ばれるシステムで行われます。 

正規化すると、構造化されていなかったログを含むすべてのログが、一致するスキーマとクエリ可能な一連のフィールドを持つようになります。CrowdStrike のログから RemoteAddressIP4 を抽出して IPDestination にリネームし、同様に PAN のログの dst を IPDestination にリネームします。これにより、アナリストは、特定の IP が接続されたかどうかを確認する場合、すべてのログにクエリを発行し、IPDestination==[...] の場所を尋ねるだけですみます。

理想的には、これは素晴らしいことです。アナリストが分析できるようになります。ただし、ログの正規化によって次のような独自の課題も生まれます。

  1. データディクショナリには数百のフィールドがあり、その多くは NULL で、多くのスペースを無駄にしています。
  2. 新しいログタイプを取得すると、フィールドが以前に定義したものと一致しないため、奇妙なエッジケースが生成される可能性があります (ログタイプによって、ユーザー、ユーザー名、ユーザーメールの意味が異なるなど)。
  3. 新しいログソースのオンボードの一環として、正規表現または解析ルールを作成して、すべての新しいログタイプまたはサブログタイプを、手動で解析する必要があります。
  4. ログの構造を変更したり、フィールドを追加または置き換えたりすると、既存のルールが関連するフィールドを解析できなくなる可能性があります。これはデータ品質にとって重大な問題となります。
  5. さらには、ルールを大規模に検証または追跡するための良い方法がありません。ルールが重複している可能性が非常に高いものの、ルールの廃止には大きなリスクが伴うため、ルールセットの保守または更新が困難になります。これは、新しいルールが古いルールの機能を上書きするリグレッションを引き起こす可能性があります。

これらの作業はすべて、それに伴うコストを増大させます。セキュリティチームは、イベントの検出と応答に集中する代わりに、手作業でのデータ正規化に多くの時間を費やさなくてはなりません。

OCSF の採用

オープンサイバーセキュリティスキーマフレームワーク (OCSF) は、2022 年 8 月の BlackHat でデータスキーマのオープンスタンダードとして公式に発表されました。この分野としては世界初のプロジェクトであり、複数のサイバーセキュリティソースにまたがるデータを標準化する重要な取り組みです。このフレームワークの目的は、シンプルでベンダーに依存しない分類法を提供することにより、すべてのセキュリティチームが、時間のかかる初期段階の正規化作業を行うことなく、より適切かつ迅速にデータの取り込みと分析を実現できるようにすることです。 

目標は、既存のセキュリティ標準とプロセスに適合し、どのような環境、アプリケーション、ソリューションプロバイダーでも採用できる、オープンスタンダードを確立することです。OCSF は、上述した初期の両方の問題を解決することを目的にしているという点で、Salesforce のデータディクショナリのアプローチと類似したオープンソースフレームワークです。また、アナリストの使用状況に基づいて構造化されるフィールドのサブセットを定義することで、Salesforce のアプローチから生じる課題にも対処しています。

Salesforce のチーフトラストオフィサー Vikram Rao は次のように述べています。「あらゆる企業にとって、デジタル化への迅速な対応は待ったなしの必須課題です。一方で、インターネット規模のデジタルの信頼性を満たすセキュリティ体制の構築は大きな課題です。OCSF のような新しい標準によって、セキュリティチームの負担を軽減して、脅威分析や攻撃防御などのより影響の大きな作業に集中できるようになります」

テストの実施

Salesforce ディテクション & レスポンスエンジニアリングチームは OCSF を評価し、Salesforce が生成したログにこのスキーマを適用することを検討すると共に、イベントデータディクショナリで定義されたカスタムスキーマではなく、OCSF で定義されたスキーマでログを出力するように、現在の正規化のアプローチを適応させました。

OCSF をより深く理解するために、私たちはまず、仮想の Salesforce セキュリティ検出イベントを OCSF 形式に変換して評価する演習を行いました。以下は、現在の DDI 形式と OCSF 形式でのイベントのスクリーンショットです。 

image
Salesforce セキュリティイベント - DDI 形式のスキーマ
image
Salesforce セキュリティイベント - OCSF 形式のスキーマ

この演習に取り組み、OCSF スキーマについて調査しているときに、使用できる可能性のある興味深いフィールドを見つけました。たとえば、修復オブジェクトです。このフィールドは、インシデントのトリアージの最中に、下流のアナリストに有用な説明となるナレッジベースの記事をリンクし、アナリストがさらなるアクションを取るのに役立ちます。

私たちは、社内チーム全体で協力して内部アプリケーション ログ (sfdc_applog) の変換のプロトタイプを作成し、評価することによってジャンプスタートを切りました。最終的には、OCSF に準拠するログを作成する予定です。私たちは、今後も継続的に OCSF に協力していきたいと考えています。このスキーマを使用してログを標準化する場合は、こちら から OCSF GitHub のフォークを作成して始めてください。

称賛に値するプロジェクト

オープンサイバーセキュリティスキーマフレームワークプロジェクトの目的は、ベンダーに依存しないフレームワークで簡素化された分類法を提供し、セキュリティチームがデータ正規化に費やす時間を短縮し、サイバー攻撃から企業を守ることに集中できるようにすることです。こうした取り組みは称賛に値します。OCSF には、Cloudflare、CrowdStrike、DTEX、IBM Security、IronNet、JupiterOne、Okta、Palo Alto Networks、Rapid7、Salesforce、Securonix、Sumo Logic、Tanium、Trend Micro、Zscaler の各社が貢献しています。

Salesforce は、OCSF をいち早く採用したことにわくわくしています。私たちが実施した初期の演習、すなわち、上位数件のログタイプイベントの OCSF への変換は、素晴らしい第一歩となりました。社内のさまざまなチームが、このフレームワークについて学び、その現状を知りました。OCSF はオープンスタンダードであり、セキュリティ業界全体が共同で取り組むプロジェクトであると同時に、多くのステークホルダーがこの標準を採用し、その進化をサポートしています。このことから、OCSF はあらゆる組織のセキュリティデータレークを民主化するポテンシャルを秘めています。

最後に、OCSF が最大限のインパクトを発揮するためには、クラウドプロバイダーとセキュリティベンダーが連携し、OCSF スキーマでログを提供する必要があります。この領域に携わっている方々には、互いの垣根を取り払い、OCSF をセキュリティコミュニティのスタンダードにするために協力していただけるようお願いします。

おすすめの事例