この4部構成のブログシリーズ（"Lessons learned from building Cybersecurity Lakehouses,"
パート1では 、まず統一されたイベントのタイムスタンプ抽出から始めた。 パート 2では、ログの取り込みの遅れを発見し、対処する方法について見てきた。 この第3回目のブログでは、 メダリオンアーキテクチャを 指針として、 半構造化機械生成データの解析に関する いくつかの問題に取り組む。
このブログでは、ログ生成データを解析する際に直面する課題について概説し、アナリストが異常な行動、潜在的な侵害、侵害の指標に関する洞察を得るために、データを正確に取得し、解析するためのガイダンスとベストプラクティスを提供します。 このブログが終わる頃には、Cybersecurity Lakehouseにデータを取り込み、解析する際に直面するいくつかの問題と、それを克服するために私たちが使用できるいくつかのテクニックについて、しっかりと理解していることだろう。
序章 サイバーセキュリティの文脈で機械が生成したログを解析することは、データを理解し、組織内の活動から可視性と洞察を得るための基礎となります。 解析は厄介で困難な作業だが、データを分析し、報告し、視覚化するためには必要な作業である。 正確で構造化された形式を生成しなければ、組織はサイバー攻撃によって機械が生成したデータに残された多くの情報の痕跡に気づかない。
解析の課題 生データを取得する際に直面する課題は多い。主に、多くの情報源のように、機械が生成したデータがストリーミング形式である場合だ。
適時性： データの到着が遅れたり、遅れたりする可能性がある。 このことについては、<<part two> > で述べた。最初のデータキャプチャーはもろいもので、最初の書き込みの前に必要最小限の変換動作だけを行うことができる。
データフォーマット： データ形式：ログファイルは通常、転送エージェントによって読み取られ、転送先に 転送される（サードパーティーのシステムを経由する場合もある）。 同じデータでも、エージェントや仲介ホストによってフォーマットが異なる場合がある。 例えば、クラウド・ストレージに直接書き込まれたJSONレコードは、他のシステム情報でラップされることはない。 しかし、Kafkaクラスタが受信したレコードは、JSONレコードがKafkaラッパーにカプセル化される。 このため、異なるシステムから同じデータを解析することは、適応的なプロセスとなる。
データの不整合： 入力データに対してスキーマを生成すると、解析エラーが発生する可能性がある。 また、ネストしたフィールドをアンパックすると、カラム名が重複する可能性があるため、適切に処理する必要がある。
メタデータの抽出： データソースの成り立ちを理解するためには、次のようなメタデータフィールドを抽出するメカニズムが必要である：
ソース・ホスト ファイル名（ファイルソースの場合） 解析のためのソースタイプ ワイヤ・データは複数のネットワーク・システムを経由している可能性があり、発信元のネットワーク・ホストはもはや明らかではない。 ファイルデータは、ネットワークホスト名や発信元によって分割されたディレクトリ構造に格納されることがある。 データを完全に理解するためには、最初のインジェストでこの情報をキャプチャする必要がある。
レトロスペクティブ解析： クリティカルなインシデント対応や検知データは、文字列の一部のみを抽出する必要がある場合がある。
イベント時間： システムはイベントのタイムスタンプを様々なフォーマットで出力する。 システムはタイムスタンプを正確に解析しなければならない。 このトピックに関する詳しい情報は、このブログシリーズのパート 1をチェックしてほしい。
ログフォーマットの変更： ログファイルのフォーマットは頻繁に変更される。 新しいフィールドが追加され、古いフィールドはなくなり、フィールド名の基準は幻想にすぎない！
構文解析の原則 以上のような課題を考えると、生データの解析はもろい作業であり、慎重かつ計画的に処理する必要がある。 以下は、生のログデータを取得し、解析するための指針である。
構文解析の作業は、少なくとも3つの異なるステージで行われると考えてほしい：
生データをキャプチャし、必要なものだけを解析して、さらなる変換のためにデータを保存する。 取り込んだデータから列を抽出する イベントをフィルタリングし、共通情報モデルに正規化する オプションとして、正規化処理の前または後（あるいは両方）にデータをエンリッチする。 初期データ収集 ログファイルやストリーミングソースからのデータの最初の読み込みは、データ解析の最も重要で脆い部分である。 この段階では、データには最低限の変更しか加えない。 変更は限定的であるべきだ：
データの塊をイベントごとに1つのレコードに分解する メタデータの抽出と追加(_event_time、_ingest_time、_source、_sourcetype、_input_filename、_dvc_hostname) このよう に未処理の生データをキャプチャすることで、下流でエラーが発生した場合でも、後の時点でデータを再取得することができる。
列の抽出 第2段階は、必要に応じて元の構造からカラムを抽出することに重点を置く。 STRUCTSとMAPをフラットにすることで、サイバーアナリストが必要とする重要な情報にアクセスするための複雑なPySparkコードを必要とせず、正規化フェーズを簡単に完了できる。 使用例によっては、MAP<STRING, STRING> フォーマットのままの方が有益な場合もあるため、列の平坦化はケースバイケースで評価されるべきである。
イベントの正規化 通常、1つのデータソースは、1つのフィード内で数十から数百のイベントタイプを表現することができる。 イベントの正規化には、特定のイベントタイプをイベント固有の共通情報モデルにフィルタリングすることが必要である。 例えば、CrowdStrike のデータソースには、プロセス固有のテーブルにフィルタリングされるべきエンドポイントプロセスのアクティビティがあるかもしれないが、WMI固有のテーブルにフィルタリングされ正規化されるべきWindows Management Instrumentation (WMI) イベントもあるかもしれない。 イベントの正規化は次回のブログのテーマになる。 ぜひ期待していてほしい。
Databricksは、Lakehouseのこれらのタスクを論理的に整理するために、「メダリオンアーキテクチャ 」と呼ばれるデータデザインパターンを推奨している。
解析例 以下の例 は、Apacheのaccess_combinedログフォーマットに適用される 解析の原則を実践する方法を示している。
以下では、生データをテキストファイルとして読み込む。
上述したように、データソースを表現するために必要なメタデータの抽出や追加に変換を留めたい。 このデータ・ソースはすでにイベントごとに1行として表現されているので、explode機能は必要ない。
source = "apache"
sourcetype = "access_combined"
timestamp_col = "value"
timestamp_regex = '^([^ ]*) [^ ]* ([^ ]*) ˶[([^]]*)˶]'
df = df.select(
) current_timestamp().cast(TimestampType()). alias ( "_ingest_time" ),
to_timestamp(unix_timestamp(col(timestamp_col), timestamp_format).cast( "timestamp" )、
"dd-MM-yyyy HH:mm:ss.SSSZ" ). alias ( "_event_time" ),
lit( source ). alias ( "_source" ),
lit(sourcetype). alias ( "_sourcetype" ),
input_file_name(). alias ( "_source_file" ),
"*" ).withColumn( "_event_date" 、 to_date(col( "_event_time" ))) このコマンドでは、レコードから_event_timeのみを抽出し、メタデータの新しいカラムを追加し、input_file_nameをキャプチャする。
この段階では、このデータソースからカラムを抽出するための変換を行う前に、ブロンズデルタテーブルを書くべきである。 これができたら、正規表現を適用して個々のカラムを抽出し、シルバーテーブルを作成することができる。
ex = r"^([♪d.]+) (↪S+) (↪S+) ↪S+) ↪S+[.+] ↪S+)"(↪S + ) (↪S + ) . + " (\d{3}) (\d+) \"(. + )\" \"(. + )♪"?$"
df = (df.select( '*' ,
) regexp_extract("value", ex, 1 ).alias( 'host' ),
regexp_extract("value", ex, 2 ).alias( 'user' ),
regexp_extract("value", ex, 4 ).alias( 'method' ),
regexp_extract("value", ex, 5 ).alias( 'path' ),
regexp_extract("value", ex, 6 ).alias( 'code' ),
regexp_extract("value", ex, 7 ).alias( 'size' ),
regexp_extract("value", ex, 8 ).alias( 'referer' ),
regexp_extract("value", ex, 9 ).alias( 'agent' )
)
.withColumn("query_parameters", expr("" " transform(split(parse_url(path,
" QUERY")," & " ), x -> url_decode(x))"" " ))) このコマンドでは、個々のカラムを解析し、シルバーステージ・テーブルへの書き込みに使用できるデータフレームを返す。 この時点で、適切にパーティショニングされたテーブルは、クエリーの実行やダッシュボード、レポート、アラートの作成に使用できる。 しかし、このデータソースの最終段階は、共通の情報モデルの正規化プロセスを適用 することである。 これは、このブログシリーズの次のパートのテーマである。 ぜひご期待ください！
ヒントとベストプラクティス ログソースの解析でお客様を支援する過程で、私たちは多くのヒントとベストプラクティスを開発した。
ログフォーマットの変更。 再利用可能でバージョン管理されたパーサーを開発する。 メダリオンアーキテクチャを使用して、ダーティなデータを解析し、クリーンな構造に変換する。 テーブルのスキーマを進化させる。
機械が生成したデータは乱雑で、ソフトウェアのリリースごとに頻繁に変更される。 新しい攻撃ベクトルには、新しいカラムの抽出が必要になる（その場で作成するだけでなく、テーブルに書き込みたいものもあるだろう）。 メダリオン・アーキテクチャーのさまざまな段階における保管要件について考える。 シルバーやゴールドのテーブルと同じように、生のキャプチャーを保管する必要があるか？ まとめ 機械が生成した半構造化データを解析し正規化することは、良好なセキュリティ姿勢を獲得し維持するための要件である。 考慮すべき要素はいくつもあるが、デルタ・レイクのアーキテクチャはサイバーセキュリティ分析を加速するのに適した位置にある。 スキーマの進化 、データ・リネージ 、データ品質 、ACIDトランザクションなど 、このブログでは説明しきれなかった機能については、興味のある読者のために残しておく。
お問い合わせ Databricksのサイバー・ソリューションがどのようにあなたの組織にサイバー脅威の特定と軽減の力を与えることができるかについて、さらにご興味がおありでしたら、[email protected] にLakehouse for Cybersecurity Applicationsのウェブページを ご覧ください。
