ITセキュリティ用のPowerShellアプリケーション。 パートII：ファイルアクセス分析

この一連の記事に取り組んでいるとき、PowerShellには未来から不可解にやってきたテクノロジーがあるとほとんど信じていました。 エンタープライズスターシップスポックの上級役員が宇宙の解析をスキャンしてバイザーを覗いたときの、もちろんオリジナルのスタートレックシリーズを覚えていますか？ 実際、SpockはStarFleetが承認したPowerShellスクリプトの結果を見ていました。









トリコーダー？ また、PowerShellテクノロジーに基づいて機能します。



はい、私はPowerShellテクノロジーのファンであり、ブロガーがこれまで考えもしなかったトピックを大胆に探ります。 Linuxシェルの基本言語で教育を受けた人にとって、PowerShellは非常に高度なテクノロジーのように見えます。 PowerShellのハイテク機能の1つは、前の記事で述べたように、ファイルの更新などの低レベルのOSイベントを追跡する機能です。



Register-WmiEventリクエストの詳細な分析



前回説明した1行だけでファイルを監視するためのすばらしいPSコードに戻りましょう。

1. Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE TargetInstance ISA 'CIM_DataFile' and TargetInstance.Path = '\\Users\\bob\\' and targetInstance.Drive = 'C:' and (targetInstance.Extension = 'doc' or targetInstance.Extension = 'txt)' and targetInstance.LastAccessed > '$($cur)' " -sourceIdentifier "Accessor" -Action $action
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご想像のとおり、追跡対象のロジックは、Register-WmiEventクエリパラメーターのWQLに含まれています。



思い出すように、WQLを使用すると、スクリプト作成者はWindowsシステム内のイベントに関する一般的な情報を取得できます。また、今回の場合のように、ファイルイベント（ファイルの作成、更新、変更）に関する情報も取得できます。 このクエリを使用すると、CIM_DataFileクラスの形式で表示されるWindowsの暗い場所からファイル変更イベントに関する情報を簡単に取得できます。

WQLでは、検索するメディアとフォルダーを指定できます。 これを行うには、ドライブとパスの上記のプロパティを使用します。



ワイルドカード検索は使用できませんが、これは言語機能であり、エラーではありません-代わりに、特定のファイル拡張子を検索できます。 このメモのスクリプトの開発における私の目標は、ITセキュリティの専門家がテキストファイルに関連する過剰なアクティビティを検出できるようにすることでした。 したがって、docまたはtxt拡張子を持つファイルを検索するための論理条件を設定します。 論理的ですか？



次に、1つの非自明な点を考えてみましょう。



誰かがファイルにアクセスしようとしたときに発生するイベントに関する情報を収集する必要があります。変更を加えずにMicrosoft Word文書のみを読む場合などです。



これを行うことは可能ですか？



Windowsエクスプローラーでファイルの一覧を表示するときに使用できる[変更日]フィールドについては、よく知っています。 しかし、アクセス日付フィールドもあることをご存知ですか？ Windowsファイルを読み取るたびに、このフィールドは理論的には現在のタイムスタンプを示します。 列見出しをクリックしてアクセス情報フィールドをオンにすることで、これを自分で確認できます（以下を参照）。







ただし、実際には、ファイルが編集用ではなく読み取り専用で開かれた場合、Windowsコンピューターは通常、この内部フィールドを更新するように構成されていません。 Microsoftは、これによりパフォーマンスが低下すると主張しています。 しかし、疑念はさておきましょう。

Windowsでファイルアクセス時間の継続的な更新を構成するには、過小評価されているfsutilユーティリティ（管理者権限が必要）を次のパラメーターとともに使用します。

 fsutil set behavior disablelastaccess 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テスト環境でファイルアクセスイベントを設定することにより、Windowsで読み取り専用イベントを記録できるようにしました。



その結果、上記のWQLコードでこのような論理的な検索条件を示しました。

 targetInstance.LastAccessed > '$($cur)'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、Register-WmiEventの開始後にファイルにアクセスするファイルイベントにのみ興味があるということです。 ところで、$ cur変数には、Get-Dateコマンドレットから取得した現在の時刻値が割り当てられます。



ファイルアクセス分析



WQL言語を調べました。残りのRegister-WmiEventパラメーターに移りましょう。



SourceIdentiferでは、イベントの名前を指定できます。 ネーミング-人、ぶち猫、テリア-を使用することをお勧めします。これにより、必要に応じてそれらを呼び出すことができます。



そして、イベントに適しています！ この識別子を必要とするいくつかのコマンドレットがあります。 初心者の場合：Unregister-Eventを使用して特定のイベントサブスクリプションを削除します。Get-Eventを使用すると、キューに入れられたすべてのイベントを表示できます。Remove-Eventを使用してキュー内の現在のイベントを削除します。 これらのコマンドレットのいくつかを最終コードで使用します。



スクリプトの主要コンポーネントを作成しました。



Actionパラメーターを検討する必要があります。 Register-WmiEventはイベントに非同期的に応答するため、トリガーされたイベントへの反応を処理するコードが必要です。その中で、たとえば、送信されたPowerShellコードのブロック内のアクションです。



そして、これはスクリプトで実際に達成しようとしているものにつながるので、PowerShellコードの数行でユーザーの行動を分析する世界全体を征服するという壮大な計画を明らかにしなければなりません。



これが計画です。 このPSスクリプトは、ファイルアクセスイベントの強度を追跡し、基準値と比較して、この強度が潜在的なハックの試みを示す可能性がある非特性値の範囲に入るかどうかを判断します。 このしきい値に達すると、最新のアクティビティデータを含む優れたダッシュボードが表示されます。



つまり、特定のディレクトリ内のテキストファイルに関する異常な動作を通知するアラートを備えた脅威追跡システムを使用します。



Powershellは他のセキュリティソリューションを市場から押し出しますか？



いいえ、 ヴァロニスはいくつかの理由でこれについて心配する必要はありません。



まず、Windowsでのイベントトラッキングは効果的とは言えません。 実際、Microsoftは、fsutilを介したファイルへの最後のアクセスに関する更新を含めると、システムの負荷が増加することを警告しています。 さらに、Register-WmiEventは内部イベントのフライホイールを高速化します。コマンドレットがシステムの速度を低下させる可能性があるというコメントに出会いました。



次に、この監視がリアルタイムまたはほぼリアルタイムで実行されないことに気付きました。ファイルイベントの受信に遅延があり、30分以上に達します。 少なくとも、AWS仮想マシンでスクリプトを実行した経験がありました。 おそらく、特定のマシンで結果が良くなるかもしれませんが、Microsoftがこれについて何かを約束できるとは思いません。



第三に、どのように試しても、ファイル変更イベントをアプリケーションのユーザーに接続できませんでした。これがイベントの原因でした。 つまり、ファイルイベントが発生したことは知っていますが、残念ながら、Register-WMIEventを使用して誰がそれを行ったのかを特定することはできません。



そのため、ファイルへのアクセスを追跡できるスクリプトを受け取りましたが、IDは確立しません。 うーん...私のアクセスに関するデータを収集するファイルアクセス分析と呼ばれる新しいセキュリティ制御カテゴリを作成しましょう。 ガートナー、聞こえますか？



もちろん、特定のユーザーの行動は興味深い情報であるため、ユーザーの行動を分析することは、脅威を識別するためのはるかに効果的な方法です。 ファイルアクセスの詳細ではない分析は、有用ではありますが、複数のユーザーからイベントに関するデータを収集するため、違法な動作を特定することはできません。



ただし、登録アカウントの数が少ない中小企業の場合、ファイルアクセス分析で十分な場合があります。 たとえば、管理者は、機密データを含むディレクトリに頻繁に関心を持つユーザーの動作が疑わしい場合、これらのスクリプトを使用できます。 このコードには、さらに魅力的な機能もあります。



また、私のスクリプトが完全に機能しない場合でも、PowerShell（または使用する別の言語）を使用してWindowsイベントを操作する複雑さを理解することがさらに重要な議論であり、エンタープライズクラスのソリューションに注意を払う必要があります。



これで、Register-WmiEventコマンドレットのPowershellスクリプトブロックを確認する準備ができました。

 1. $action = { 2. $Global:Count++ 3. $d=(Get-Date).DayofWeek 4. $i= [math]::floor((Get-Date).Hour/8) 5. 6. $Global:cnts[$i]++ 7. 8. #event auditing! 9. 10. $rawtime = $EventArgs.NewEvent.TargetInstance.LastAccessed.Substring(0,12) 11. $filename = $EventArgs.NewEvent.TargetInstance.Name 12. $etime= [datetime]::ParseExact($rawtime,"yyyyMMddHHmm",$null) 13. 14. $msg="$($etime)): Access of file $($filename)" 15. $msg|Out-File C:\Users\bob\Documents\events.log -Append 16. 17. 18. $Global:evarray.Add(@($filename,$etime)) 19. if(!$Global:burst) { 20. $Global:start=$etime 21. $Global:burst=$true 22. } 23. else { 24. if($Global:start.AddMinutes(15) -gt $etime ) { 25. $Global:Count++ 26. #File behavior analytics 27. $sfactor=2*[math]::sqrt( $Global:baseline["$($d)"][$i]) 28. write-host "sfactor: $($sfactor))" 29. if ($Global:Count -gt $Global:baseline["$($d)"][$i] + 2*$sfactor) { 30. 31. 32. "$($etime): Burst of $($Global:Count) accesses"| Out-File C:\Users\bob\Documents\events.log -Append 33. $Global:Count=0 34. $Global:burst =$false 35. New-Event -SourceIdentifier Bursts -MessageData "We're in Trouble" -EventArguments $Global:evarray 36. $Global:evarray= [System.Collections.ArrayList] @(); 37. } 38. } 39. else { $Global:burst =$false; $Global:Count=0; $Global:evarray= [System.Collections.ArrayList] @();} 40. } 41. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、Out-Fileコマンドレットを使用してログインをチェックし、各アクセスケースのタイムスタンプ付きエントリを作成します。 また、イベントの数を$ Global：ベースライン配列の参照値と比較すると、15分ごとにファイルアクセスの急増が検出されます。

ここで少し空想し、各曜日の基準値に含まれるイベント数の神話上の平均値を設定し、各日を3つの8時間の期間に分割しました。 特定の期間のピークアクティビティが正規分布曲線の最後尾にある場合、脅威が検出されたと見なすことができます。



ファイルアクセス分析ダッシュボード



$ Global：evarray（タイムスタンプ付きのファイルを開く）でのイベント数のピーク増加に関するデータを受け取ったので、このデータをスタイリッシュな情報パネルの形式で表示することをお勧めします。 しかし、このコードをスクリプトブロックに追加する代わりに、このデータを個別のイベントに「キュー」し、個々のアプリケーションで処理できます。



なに？



説明させてください。 これは、上記のスクリプトブロックの最後にNew-Eventコマンドレットが登場する場所です。 このコードをスクリプトブロックにバインドせずに、別のアプリケーションまたはスクリプトに非同期で信号を送信できるため、次のファイルアクセスイベントを処理できます。



次のノートでは、ファイルアクセスを分析するためのPowerShellスクリプトの完全なコードを紹介します。 ここで、Wait-Eventコマンドレットを構成したと言います。その唯一の目的は、イベントのこれらのバーストを選択し、Out-GridViewを使用して美しいテーブルの出力に送信することです。



管理コンソールに表示される最終結果は次のとおりです。







ファイルアクセス分析用の「プラットフォーム」全体が60行のPSコードで実装されていると考える場合の優れたソリューションです。



今日は十分な量の資料を調べました。



次回、ファイルアクセス分析スクリプトについて詳しく説明し、次に、PowerShellコンテンツの優れた分類機能について説明します。