実践セキュリティ監視基盤構築(24): セキュリティ監視エンジニアリング

この記事はアドベントカレンダー「実践セキュリティ監視基盤構築」の24日目の記事です。これまでに、セキュリティ監視基盤の構築と実装について詳しく解説してきました。今回は、視点を変えて、セキュリティ監視に関する新しい概念やアイデアについてお話しします。

情報技術に関連する多様なソフトウェア、サービス、手法が進化する中で、それに対応するための概念も進化しています。わかりやすい例としてはDevOpsやSREがありますが、セキュリティ監視においても新たな取り組みが行われています。

従来のセキュリティ監視業務と課題

新しい概念について話す前に、従来のセキュリティ監視業務を振り返ってみましょう。これらは筆者が経験したり、伝聞した内容に基づくもので、古く偏った視点である可能性があります。

• アラートの検知は、SIEMやIDSで提供されるデフォルトルールを使うことが多く、チューニングはルールのON/OFF程度に留まることが多い。
• 検知されたアラートには、アナリストが手動でトリアージを行い、必要に応じて対応する。
• ルールやシステムの更新は手動で行われる。
• デフォルトルール以外の検知も試みられるが、アナリストの経験や知識に依存する「直感的な」分析であることが多い。

このような従来のセキュリティ監視業務にはいくつかの課題があります。

❌️ (1) 高度な攻撃への対応が難しい

過去のセキュリティ監視では、主に既知の攻撃パターンに対する検知が中心でした。しかし、近年の攻撃は高度化しており、既知の攻撃パターンに対する検知が難しくなっています。IoC（Indicator of Compromise）も短期間で変わることが多く、攻撃自体も複雑化しています。このような高度な攻撃に対応するためには、組織ごとに検知ルールを作成し運用するアプローチが考えられます。これには、組織のポリシーから逸脱した挙動や、組織内の環境やアーキテクチャに基づく不審な挙動を検知することが含まれます。これらはベンダーが共通のルールとして提供するのが難しく、各組織にカスタマイズされたルールを作成する必要があります。

❌️ (2) 継続的な検知の改善が難しい

高度な攻撃への対応と同様に、既存ルールに対しても誤検知を減らすためのチューニングや、新たな検知ルールの追加が必要です。検知ルールは一度作成しただけでは終わらず、継続的に改善を行う必要があります。これは環境の変化、組織の変化、攻撃手法の変化に対応するために必要です。従来のセキュリティ監視業務やツールでは、様々な障害があり、継続的な改善を実施するのが難しい状況です。

• ⚠️ 作業ミス: 人間がルール更新を行うことでミスが発生する可能性があります。これは、検知ルールの更新頻度が高いほど発生する可能性が高くなり、ルールを置き換えようとする際の障害となります。
• ⚠️ 作業の遅延: 人間が手作業で更新を行うと、確認作業も手動で実施する必要があり、作業の遅延が発生します。
• ⚠️ 実機によるテスト: セキュリティ監視に利用するシステム側の問題で、ルールを更新した際のテストが実機・実環境でないと確認できない場合があります。これはテスト環境の用意・維持にコストがかかるため、テストの頻度が下がり、ルールの更新が遅れる原因となります。

このようなことから、独自ルールの作成だけでなく、既存ルールのチューニングや検知の改善においても、効率化が必要になっています。

❌️ (3) 対応作業に負荷がかかる

検知されたアラートに対しては、SOCアナリストがトリアージを行い、必要に応じて対応します。この作業はSOCアナリストの経験や知識に依存するため、組織によっては対応の品質や結果にばらつきが生じることがあります。また、この作業は人的リソースに依存するため、スケールが難しいという課題もあります。場合によっては同じような作業の繰り返しとなり、モチベーションの低下やミスの増加などの問題も発生します。

ルールの更新作業も特定の担当者に集中すると負荷がかかり、他のメンバーが作業をするためのハードルが高くなります。結果として、スケールが難しくなります。

ソフトウェアエンジニアリングを応用した検知・対応の継続的な改善

これらの課題を解決し、より効率的にセキュリティ監視を実施する目的で、近年ではセキュリティ監視に関連した新しい考え方がいくつか提唱されています。

• Detection Engineering: アラート検知に関するプロセスをソフトウェアエンジニアリングの手法で改善する考え方。
• Detection as Code: Detection Engineeringの一環として、検知ルールをコードとして管理する考え方。
• Monitoring as Code: Detection Engineeringに近い概念で、プロダクトの安定運用を含む広義の「監視」を中心とした考え方。
• Policy as Code: セキュリティポリシーをコードで管理し、評価などを自動化する考え方。
• Autonomic Security Operations: SOC全体の自律性を高めるための取り組み。

これらの概念はすべて一致しているわけではありませんが、共通の考え方としてソフトウェアエンジニアリングのベストプラクティスをセキュリティ監視に応用するという点があります。ソフトウェア技術の本質は以前から変わっていませんが、それを取り巻く環境や利用できるサービス、ソフトウェアが大きく進化したことで、セキュリティ監視にも新しいアプローチを取り入れる土壌が整っています。

ソフトウェアエンジニアリングのベストプラクティスをセキュリティ監視に応用することで、以下のようなメリットが得られると考えられます。

✅️ (1) 検知や対応ルールのコード化

"〜 as Code" という言葉が示しているように、ソフトウェアエンジニアリングの手法を活かすには、ルールをコードとして表現することが重要です。ここでのコードとは、テキストベースで人間が読み書きしやすく、かつ機械可読性（Machine Readability）がある形式で記述されたものを指します。この形式でルールを管理することで、ソフトウェア開発で利用されるツールやサービスを通じて様々な恩恵が受けられます。

• 👍️ 履歴管理: Gitのようなバージョン管理システムで、いつ誰がどのような変更を加えたのかを追跡できます。ルールを変更する際、どのような経緯で記述されたのかを確認でき、改善やリファクタリングの手助けとなります。
• 👍️ レビュー: GitHubのようなサービスを利用することで、プルリクエストやコードレビューを通じてルールの変更を他のメンバーがレビューできます。これにより、ルールの変更に複数のメンバーが目を通すことができ、ミスの発見や知識の共有が促進されます。
• 👍️ 承認管理: ルール変更時、組織のポリシーによっては責任者の承認が必要な場合があります。GitHubのようなサービスを利用することで、承認フローを定型化し、レビューや履歴管理と連携できます。
• 👍️ 機械的な検査: ソフトウェアでルールを読み込ませることで、自動的にルールの内容をチェックできます。具体的には、形式を整えるLintを実行したり、組織内・チーム内ポリシーに沿っているかのチェックが可能です。

✅️ (2) 検知や対応の自動化

ルールをコードとして管理することで、ルールの作成や改善が容易になり、自動化がより効果的になります。検知や対応をルールに基づいて自動化することで、以下のようなメリットが得られます。

• 👍️ 冪等性: ルールに基づいて自動化された検知や対応は、何度実行しても同じ結果が得られます。これにより、検知や対応の結果に一貫性が保たれます。
• 👍️ 人的ミスの低減: 人間が手動で検知や対応を行う場合、見逃しや取り違えといったミスが発生する可能性があります。自動化された検知や対応は、人間のミスを低減できます。もちろん、ルールに誤りがあった場合、自動化した処理も問題を引き起こすことがありますが、コードを修正することで問題の再発を防げます。
• 👍️ 作業の効率化: 人間が手動で検知や対応を行う場合、作業に時間がかかることがあります。自動化された検知や対応は、作業の効率化を実現します。これにより、人間はより価値のある作業に集中できます。
• 👍️ スケール: 自動化された検知や対応は、人間が手動で行う場合に比べてスケールしやすいです。大規模な環境でも効率的に検知や対応を行えます。
• 👍️ 迅速な対応: 自動化された検知や対応は、人間が手動で行う場合に比べて迅速に対応できます。遅延をどこまで小さくするかは組織の方針次第ですが、調整できる余地があることは重要です。

自動化で重要な観点として、すべてを自動化することが目的ではないということがあります。自動化における問題として、自動化のためのルール作成や管理の負荷が増える点があります。セキュリティ監視で対処しなければならない事象は多岐にわたり、稀にしか起こらない事象や例外的な事象も少なくありません。そのような事象に対しても自動化を網羅しようとすると、ルールの数が膨大になり、管理が困難になることがあります。そのため、どこまでを自動化するかをよく検討しながら取り組むことが重要です。

✅️ (3) ルールの自動テスト

現代のソフトウェア開発において自動テストは欠かせない存在ですが、セキュリティ監視においてもルールの自動テストには様々な恩恵があります。

• 👍️ ルールの品質維持: ルールをテスト可能にしておくことで、ルールを作成・更新した際に既存ルールに影響を及ぼしていないかを回帰テストできます。
• 👍️ 自動化による負荷軽減: ルールのテストを自動化することで、テストの負荷を軽減できます。これによりテストを気軽に実施でき、ルール更新に対する心理的負荷を下げられます。

自動テストは必ずしもコード化が必要というわけではありませんが、コード化されていることでテストのための仕組みやフレームワークを構築しやすくなります。また、後述するCI/CDと連携しやすくなり、これによって履歴管理やレビューとも組み合わせた価値を発揮するようになります。

✅️ (4) CI/CDの活用

CI（Continuous Integration）/CD（Continuous Deployment）は現代のソフトウェア開発において重要な概念です。デプロイを繰り返し、複数人で行う場合にはCI/CDが有効です。セキュリティ監視においても、ルールの更新でCI/CDを活用することで以下のようなメリットが得られます。

• 👍️ デプロイ前の自動テスト: ルールを作成・更新した後、デプロイ前にテストを実施することで、本番環境での事故を防ぐことができます。
• 👍️ デプロイ作業の自動化: ルールの更新を自動化することで、ルールの適用を自動化できます。これにより、ルールの適用漏れやミスを防ぐことができ、さらに適用にかかる作業に時間を浪費せずに済みます。また、属人化を避けて誰でもルールを適用しやすくなるため、チームでの作業がしやすくなります。

セキュリティ監視にソフトウェアエンジニアリングを適用するための課題

セキュリティ監視に対するソフトウェアエンジニアリングの適用には、多くの恩恵がある一方で、実現するための課題もいくつか存在します。以下にその一部を挙げてみます。

⚠️ 対応するサービスやソフトウェアが少ない

セキュリティ監視に対するソフトウェアエンジニアリングの適用は新しい概念であるため、対応するサービスやソフトウェアが少ないという課題があります。セキュリティ監視自体は古くからの業務であり、そのためのサービスやソフトウェアは多く存在しますが、セキュリティ監視を担当する人々はそれらの「サービスやソフトウェア自体を使いこなす」ことが主なスキルであることが多いです。そのため、こうした指向のサービスやソフトウェアのニーズが高まっているとは言い難い状況です。

こうした背景もあり、このアドベントカレンダーではセキュリティ監視基盤を内製で構築するための一連の流れを紹介しました。セキュリティ監視基盤を内製で構築することで、自分たちのニーズに合わせたサービスやソフトウェアを構築できます。ただし、内製で構築することはコストやリソースの問題があり、またセキュリティ監視基盤の構築には専門的な知識が必要となるため、それらを持つ人材を確保する必要があります。

⚠️ セキュリティ監視とソフトウェアエンジニアリングの両方のスキルがある人材が希少

もう一つの課題は、セキュリティ監視とソフトウェアエンジニアリングの両方のスキルを持つ人材が希少であるという点です。セキュリティ監視には、セキュリティに関する知識や経験が必要です。一方でソフトウェアエンジニアリングには、プログラミングやアーキテクチャ設計、テストなどのスキルが必要です。これらのスキルや経験を兼ね備えた人材は希少であり、チームを構成するのが難しいという課題があります。

先述の通り現状ではソフトウェアエンジニアリングを適用することを前提としたサービスやソフトウェアが限られているため、既存のサービスやソフトウェアを元に構築するとしても、一定のソフトウェアエンジニアリングのスキルが必要となるでしょう。これはサービスやソフトウェアが少ないことと連鎖した問題となっています。

まとめ

Detection EngineeringやDetection as Code、Monitoring as Codeなど、既存のセキュリティ監視（あるいはSOC）業務にソフトウェアエンジニアリングの手法を適用する考え方はまだ新しいもので、適用できる組織や環境も限られているのが現状です。しかし、これらの考え方が今後浸透し、より効率的なセキュリティ対策を実現できるようになることを期待して、この記事を終えたいと思います。