Zach Mathis (田中ザック)

はい、1.4.1まではOKで、1.4.2以上ではランダムにイベントの検知漏れがあります。

@kazuminn OKです。良いと思います。revertの修正でお手数をかけてすみません！

@fukusuket Thank you so much for looking into this for us and for the unit test! I thought it was due to a race condition due to the parallel processing...

Thank you so much! That helps us out a bunch! Please send us a pull request when you are ready. I will be happy to help test it out.

ありがとうございます！ロゴが表示されなくなって、寂しいと思ったが、メニューが大きくなっているので、無い方が読みやすいかもしれません。 メニューの上下に１行を空けられますか？ 例： ``` user@504-MBP hayabusa % ./target/release/hayabusa Hayabusa 1.5.0-dev Yamato Security (https://github.com/Yamato-Security/hayabusa) @SecurityYamato) ``` ↓ ``` user@504-MBP hayabusa % ./target/release/hayabusa Hayabusa 1.5.0-dev Yamato Security (https://github.com/Yamato-Security/hayabusa) @SecurityYamato) ``` ``` -U,...

色々対応ありがとうございました！ では、これでいきましょう。

ありがとうございます！そうですね。バージョン番号のハードコーディングを避けましょう。

@kazuminn 情報ありがとうございます！ unsafeの使用は仕方ないですね。 traitからenumに変更すると、早くなるかどうか分かりますか？

よく考えていたら、ストリームとして処理のリアルタイム検知ではなくて、定期的にライブ調査すると良いと思います。 理由は以下の通りです： 1. EVTX解析はリアルタイムに向いていなくて、リアルタイムで検知したい場合はETWの方が良い。 2. ルール更新ができない 3. 新しいルールで過去にあった攻撃を検知できない hayabusaは過去に攻撃があったかを調べるためのツールなので、検知するまで若干タイムラグはあるが、仕方ないと思います。代わりにルール更新で過去にあった(以前検知できなかった）攻撃の痕跡を検知できるメリットはあります。 イメージは管理者が以下の`.bat`スクリプトをタスクで定期的に実行する。(負担がかからなさそうだったら、5分ごと等、あまり負担をかけたくないんだったら、深夜に１回とか自由に設定する。） ``` hayabusa-1.3.0-win-x64.exe -u hayabusa-1.3.0-win-x64.exe --level-tuning hayabusa-1.3.0-win-x64.exe --min-level medium --live-analysis --quiet --thread-number 2 --display-record-id --output scan-results.csv --slack-alert ``` `--slack-alert`が指定されていて、`scan-results.csv`が存在しない場合(一回目のスキャンの場合）は結果を全部slackで通知します。 `scan-results.csv`が存在する場合は「ファイルが既に存在している」というエラーを出力しないで、スキャンします。ルールのアラート名等が変わる可能性があるため、既に通知したアラートをもう一回通知しないように、イベントのTimestamp, Channel,...

そうですね。都度のCSVファイルの保全は普段要らないと思いますが、ユーザが欲しい場合はスクリプトの方でローカルで保全したり、サーバに送ったりできると思います。２回目以降のスキャンは一時的に結果を`scan-results-temp.csv`等に保存して、差分だけをslackに通知して、`mv -f scan-results-temp.csv scan-results.csv`等で上書きしたら、少し実装しやすくなるかも？