Elasticセキュリティ、検知ルールの公開レポジトリをオープン
Elasticはオープンソースの力を信じており、コミュニティの重要性を理解しています。コミュニティを最優先することで、可能な限りすぐれたプロダクトを生み出し、ユーザーに届けることができます。Elasticセキュリティが掲げる2つのコア目標は、脅威を大規模に停止させること、そしてすべてのアナリストに武器を供給することです。本日Elasticは、新しいGitHubレポジトリ、elastic/detection-rulesを開設しました。セキュリティコミュニティと共に作業し、より大規模な脅威を停止するためのレポジトリです。
Elasticセキュリティによる検知エンジンのリリースで、Elastic Stackに自動の脅威検知機能が搭載されるようになりました。初回のリリース以降、Elasticセキュリティインテリジェンス＆分析チームは50以上のルールを検知エンジンに追加し、Linux、macOS、Windows OSに対する攻撃テクニックへの可視性を向上させてきました。検知の対象領域は継続的に拡大されており、クラウドサービスやユーザービヘイビアといった新たなドメインも続々と加わっています。
直近数回のリリースで、Elasticのチームは検知エンジンのルール管理に社内用レポジトリを使っていました。Kibana Query Language（KQL）構文や使用スキーマ、その他のメタデータを検証するあらたなコントリビューション用に自動化テストを追加して、テスト手順の反復的な改善を行ってきました。こうしてルール開発のプロセスも成熟し、物事を破壊しなくてもスピーディーに開発を進めることができるようになっています。
今回elastic/detection-rules GitHubレポジトリを開設することで、Elasticセキュリティチームはコミュニティとともに、オープンにルール開発を進めることが可能になります。私たちは、コミュニティ主導の検知を積極的に取り入れたいと考えています。またこのレポジトリは、私たち全員が集団的な知識を共有し、互いに学びあい、協働を通じて影響力を行使するすぐれた機会となります。
新しいレポジトリのコンテンツ
elastic/detection-rules GitHubレポジトリでは、MITRE ATT&CK®テクニックに準拠する多数のElasticセキュリティ向けルールが公開されています。現行のルールロジックは主にKQLで、またElastic Common Schema（ECS）を活用して書かれており、ルールを1度記述するだけで済みます。各種ルールはECSの指定フィールドとカテゴリを使用し、BeatsログおよびECSに適切にマップされた他のデータソースに対して自動的に動作します。
rules/フォルダー内で、ルールはTOMLファイルに格納され、プラットフォーム別にグループ化されています。新しいルールを簡単に探したり、追加したりできるよう、フラットな階層でシンプルな構成を目指しました。Windowsのみに対応するルールを探す場合、rules/windowsを開きます。ルールをうまく見つけられないときや、複数のルールを横断的に検索したい場合、python -m detection_rules rule-searchコマンドを実行してCLIを使用し、メタデータにマッチするファイルを表示させることもできます。
どのルールにもそれ自体のクエリに加えて複数のメタデータフィールドがあり、タイトルや説明、ノイズレベル、ATT&CKマッピング、タグ、スケジュールの時間間隔といった情報を捉えます。また、アナリストのトリアージに使える複数の付加的フィールドもあり、誤検知や、調査に役立つ手順の説明を記述できます。各種ルールに含まれるメタデータについて詳しくは、Kibanaルールの作成ガイドまたは、コントリビューションガイドのルールのメタデータサマリーをご覧ください。
検知エンジンで、レポジトリのルールを入手する
現在Elastic Cloudのマネージドサービス、または無料機能をすべて搭載するElastic Stackのデフォルト配布パッケージをご利用の方は、検知エンジンをはじめて開く際に最新のルールが表示されます。Elastic Stackをアップグレードすると、検知エンジンが追加、または変更されたルールを認識し、該当のルールをアップグレードするかどうかの判断を促すメッセージが表示されます。アップグレード後は、画面に表示される手順に従って最新のルールのコピーを入手することができます。
レポジトリのユーザーとは？
Elasticセキュリティインテリジェンス＆分析チームは、このレポジトリをルールの開発、作成、プルリクエストの管理、リリース目標の設定に使用しています。Elasticはこのレポジトリを公開することで、外部のすべてのコントリビューターをこのワークフローに招待しています。コントリビューターにとっては、公開によって検知エンジンでリリースされるルールの開発プロセスと、ルールへの明確なパスが可視化されます。
コントリビューションの実施にあたっては、Elasticが定めるコントリビューターライセンス同意書（CLA）に署名してくださるようお願いいたします。CLAはすべてのElastic GitHubレポジトリで求められる規範であり、Elasticがコントリビューターのコードをユーザーに自由に配布できることの根拠となります。
脅威検知のアプローチ
概して、Elasticは敵のビヘイビア（挙動）に注目する検知手法を好む傾向にあります。つまり通例としてElasticはATT&CKテクニックを重視しており、そのため、ルールの作成に先んじて、あるテクニックがどのような仕組みで動作するか把握するための研究や努力が求められることがあります。このアプローチの採用は、昨日までの攻撃だけでなく、今日、明日の攻撃も検知して停止するルール開発に役立ちます。
また、ビヘイビア中心のアプローチを採用する場合、多様な種類のルールが必要となります。たとえば一部のルールが小さなイベントを検知する一方で、他のルールは複数のイベントのアグリゲーションの実行を要求する、あるいは閾値を上回る異常を確認するといったことです。Event Query Language（EQL）を使うと、複数のイベントにわたるビヘイビアのシーケンスを検出するルールを記述することが可能になります。
もちろん、1つのテクニックがすべてのユーザー環境でビヘイビアに基づく検知を実行できるというケースばかりではありません。その場合は、本質的にもっとシグネチャーを重視したルールや、特定のビヘイビア、あるいはツールを想定して記述したルールを追加していただいて構いません。
熟慮された検知ルールを生み出すために何が必要か、という詳しい議論については検知ルールレポジトリのフィロソフィーセクションをご覧ください。
新しいレポジトリが必要とされる理由
公開ルールをシェアした経験がある方は、MITREのCyber Analytics Repository（CAR）や、Sigma、Elastic EQLに基づくEQL Analytics Libraryといった有名なGitHubレポジトリについてもご存じかもしれません。中には、「なぜ新しいレポジトリが必要なのだろう？すでにあるレポジトリを使わないのはなぜ？」と思っている方もいることでしょう。
よくあるパターンですが、この場合、最もわかりやすい答えは別の質問の答えです。「なぜ他のレポジトリが存在しているか？」を考えてみましょう。CARとSigmaは共に意図的に、言語やプラットフォーム、場合によってはデータソースを定めていません。対照的に、EQL Analytics Libraryは特定の言語を想定しています。
Elasticチームは新しい検知ルールのレポジトリを、これらと少し異なった目的で運用するつもりです。私たちの最終目的は、Elasticセキュリティのユーザーに多様なデータソースで横断的に動作する最良の検知機能を提供することです。そこでECSをすぐれたスキーマイコライザーとして使用し、ルールを1度記述するだけで複数のデータソースに適用することを可能にしました。
Elastic Stackは複数の言語をサポートしており、検知ルールにもそれを反映させる必要があります。一般的に、クエリ言語は多様な種類の問題解決の目的で開発されるものであり、他の言語で首尾よく解決できるなら、ルール開発者に特定の言語を強制すべきではありません。現在、このレポジトリではKQLおよびLuceneで記述されたルールのほか、機械学習異常検知を使用するジョブが公開されています。さらにElastic Stackとこのレポジトリの双方にEQLを導入することを目指し、鋭意作業を行っています。
また私たちはElasticsearchの最適なパフォーマンスという観点から、ベストプラクティスを提供していることを保証します。たとえばprocess.path:*\\cmd.exeを検索するにはワイルドカードチェックを行う必要がありますが、これはシンプルなキーワードチェックに比べてコストがかかります。私たちが推奨するのは、リーディングワイルドカードを含めて検索するのではなく、process.name:cmd.exeを使う方法です。この方がパフォーマンスにすぐれ、かつ最も正確な結果を返します。もう1つ挙げておきましょう。ECSはprocess.argsフィールドも含みます。これは、process.command_lineのパースされたバージョンですが、私たちはこのパース済みフィールドの方を使用することを推奨しています。ホワイトスペースや引用符ベースの回避が生じにくく、パフォーマンスにすぐれるためです。つまり、Win-Winです。
別のレポジトリにあるルールを追加できる？
あなたのKibanaロールに適切な権限がある限り、お使いの環境の検知エンジンに自由にルールを追加できます。あなたがelastic/detection-rulesレポジトリにルールを追加したいと考える場合、答えは…「状況によります」です。Elasticライセンスに基づいてサブライセンスできるルールであれば、問題ありません。大抵の場合、この要件は非常にストレートです。つまり、rule.authorの配列にオリジナルのオーサーを保持したままNOTICE.txtファイルをアップデートすることで、オリジナルオーサーを明記すればOKです。私たちは誰かの功績を奪いたくありません。この点を徹底させるには、皆さんのご協力が必要となりますので、よろしくお願いいたします。
レポジトリでのライセンシングアプローチについて詳しくは、READMEのLicensingセクションをご確認ください。
コントリビューションを行うには？
公開したいルールロジックがある場合、どのようにすればよいでしょうか。まずGitHubのelastic/detection-rulesへ行きましょう。ここに、レポジトリのナビゲーション、ルールの分岐やクローン、作成に関する詳細な指示が記載されています。バルク編集用のコマンドラインツールや、新規のルール作成を手軽にするコマンドラインツールも提供されています。レポジトリに新規のルールを追加する準備ができたら、python -m detection_rules create-ruleを実行します。すると、必要なメタデータを提供するよう求められます。可能な場合は、CLIを使用することが推奨されています。これは、別のルールやテンプレートのTOMLファイルのコンテンツを再利用する場合に、コピー＆ペーストによるエラーを軽減できるためです。
ルールの状態に問題がなければ、コマンドpython -m detection_rules testを実行してローカルでのユニットテストを実施し、構文や使用スキーマなどを検証します。次にプルリクエストを作成し、インテリジェンス＆分析チームがコントリビューションのレビューを実施します。チームから何らかの変更リクエストがある場合、チームが共同で作業し、推奨される変更内容を作成します。
ルールのアイデアを思いついたが、独力で作成するよりもElasticチームと協働したり、フィードバックが欲しいという場合は、ぜひNew Ruleにissueを作成してみてください。私たちElasticチームは、ルール作成の手助けや、ブレインストーミングも積極的に行っています。
詳しくは、contributionガイドをご参照ください。
今後の見通し
Elasticセキュリティの新しいルールレポジトリとワークフローへようこそ。チーム一同、皆さんからのコントリビューションを大歓迎しています。あなたの名前をrule.authorフィールドで拝見できる日が楽しみです。この検知ルールレポジトリはElasticセキュリティの他の領域と共に進化を続けており、私たちも今後のエキサイティングな展開に期待しています。
EQLの開発の進捗状況に関心がおありの方は、こちらのGitHub issueのsubscribeがおすすめです。また、Elasticsearchチームの最新情報が更新されているドキュメントをご覧いただくこともできます。
ルールの作成や、GitHubの新しい検知ルールレポジトリの使い方に関してフィードバックやご質問がおありの場合は、GitHubでissueを作成していただくか、ディスカッションフォーラムにdetection-rulesタグをつけてご投稿ください。併せて、Elastic Slack Communityの#detection-rulesチャンネルでご連絡いただくことも可能です。