本文の内容は、2022年8月24日にNigel Douglasが投稿したブログ(https://sysdig.com/blog/introducing-managed-policies-for-sysdig-secure/)を元に日本語に翻訳・再構成した内容となっております。
クラウドネイティブのワークロードの保護を初めて学ぶ人も、マイクロサービスのワークロードを既に実運用している人も、クラウドネイティブのセキュリティが、従来のモノリスアプリケーションに使われていたセキュリティ設計とは大きく異なることにすでに気づいていることでしょう。複雑さの劇的な増加と進化する脅威の状況により、クラウドとコンテナのセキュリティはさらに重要であり、管理するのが難しくなっています。アプリケーションのライフサイクルに変更があった場合に、Falcoルールやセキュリティポリシーを維持することは、多くのユーザーにとって現実的な課題です。
‘Terminal shell in a container’ は、ほとんどチューニングを必要としないシンプルなポリシーの条件です。このルールを変更する唯一の理由は、特定のワークロードまたはネームスペースを検出対象から除外する場合です。しかし、実行時の脅威は複雑さを増して変化し続けており、運用中の何百ものワークロードを反映する可能性がある何十もの既存のポリシーに対して、これらの新しい実行時の脅威を防ぐためにポリシーを常に変更しなければならないと仮定すると、これはすぐに退屈な作業になってしまうのです。
Falco: コンテナ内でシェルの起動に成功した場合のみ、適切なイベントの種類とその条件を付加してアラートを出します。
オープンソースのFalcoを基盤に利用するSysdig Secureは、DevOpsまたはDevSecOpsエンジニアが、Kubernetesクラスター、ホスト、クラウド環境において悪意のある動作を防ぐためのクラス最高のルールを迅速に実装できる直感的なユーザーインターフェイスを提供します。しかし、多くのエンジニアはルールをオンにすることで、このルールが今後完全なセキュリティを提供してくれると安心することでしょう。多くの場合、それは正しいのですが（つまり、多くの変更を必要としないポリシー）、敵対者は絶えず攻撃方法を改善しているため、これらの行動の変化に合わせてポリシーを更新する必要があります。
マネージドポリシーで問題を解決する
そこで、SysdigはSysdig Secureに全く新しいマネージドポリシー機能を発表することになりました!
新しいマネージドルールが作成されると、割り当てられたマネージドポリシー内に表示されます。既存のポリシーの更新を確認する必要がなく、Sysdigの脅威リサーチチームがポリシーを更新しているため、安心して保護することができます。目標はシンプルです。Sysdig脅威リサーチチームは、エンドユーザーの個々の設定選択を尊重しつつ、できるだけ混乱を起こさないようにしながら、デフォルトのルールとポリシーを自動的に取得するにはどうすればよいか？
新しいマネージドポリシーはどのように見えるのでしょうか？
ランタイムポリシー:ポリシーの更新日時は右側ペインに表示されます。
マネージドポリシーはロックされた南京錠のアイコンで識別でき、変更はできませんが、必要に応じて独自のカスタムポリシーを作るためにコピーすることができます。
Sysdigは、既存のランタイム脅威検知ルールセットに、GPGプライベートキーを見つけようとする試みを特定するための新しいマネージドポリシールールを追加しました。
GPGは、データや通信の暗号化と署名を可能にするもので、あらゆる種類の公開鍵ディレクトリへのアクセスモジュールとともに、多用途の鍵管理システムをその特徴としています。攻撃者があなたのシステムにアクセスしたと仮定すると、彼らが行う一般的な作業は、他の認証情報を検索することでしょう。いったん見つかったら、それらの GPG 鍵を使用して他のシステムに感染したり、目標に近づいたりしようとするはずです。このルールがどのように設定されたかを知らなくても、既存のマネージドランタイム脅威検出ポリシーの中でこのルールが有効になっているはずです。
SysdigのUIで、「Policies」に移動します。「Runtime Policies」の下にある検索フィールドで「sysdig runtime」を検索します。新しいリリースなので、ルールがわずか14日前に更新されたことがわかります（このブログを書いている時点）。
このポリシーをさらにスクロールすると、GPGコンテキストが追加されていることがわかります。
条件、出力、説明、およびタグを含む Falco ルール – ポリシー ビュー内で確認可能
従来、ユーザーはどのようにポリシーを管理していたのでしょうか？
歴史的に、ユーザーはポリシーに同様の変更がないか手動で確認する必要がありました。Sysdig SecureはSaaSファーストでAPI駆動型のアーキテクチャーを提供しているため、エンドユーザーは特定のcronジョブを指定する必要なく、迅速にルール変更を受け取ることができます。Falco OSS と Sysdig Secure のどちらを使用しても、ユーザーには一連のデフォルトポリシーが与えられ、一部はデフォルトで有効化されます。これは、特定の脅威ベクトルをすぐに検出できるという意味で素晴らしいことですが、市場には、新しい脅威ベクトルが特定されたときにはそれを検出したいという明確な要件が従来からありました。既存の課題は、例えばLog4Jの重大な脆弱性のように、エンドユーザーがこれらの脅威に対応するのが遅すぎるということです。
一般的な脆弱性に対して、新たに作成したルールで解決策を講じた場合、これらのルールは、エンドユーザーを迅速に保護できるはずの既存のポリシーにプッシュされることはありませんでした。この場合、これらの新しいルールを適用する責任は、すべてエンドユーザーにありました。デフォルトのルールは、新しい脅威や誤検知を発見するために定期的に更新されていましたが、ルールがノイズや時代遅れであるためにポリシーの一部でなくなった場合、エンドユーザーはそれらの更新を受け取ることができません。これが、マネージドポリシーアプローチの主な推進要因でした。
さらに、ユーザーインターフェースには、ルールが追加されたか更新されたかの表示がないため、ルールが追加された場合、いつのまにか動作が変わっていて、混乱を招くことになります。
新しいルールが作成されたことが表示されないと、ユーザーは既存のポリシーにその新しい変更を追加しないで終わってしまう可能性が高いのです。最新リリースでは、管理対象ポリシーの更新時間が表示されているように、この点にも対処しています。ユーザーは、いつ変更が発生したかを簡単に特定でき、新しいルールがマネージドポリシーに追加されたことを確認できるようになりました。
管理対象ポリシーの変更が反映された時間
マネージドポリシーのまとめ
マネージドポリシーの優れた点は、一般的に誤検知の割合が低いことです。Sysdig Secureでは、セキュリティアナリストのチームによって、攻撃主体が実行する最新の攻撃パターンを特定するためにポリシーが調整されます。アラートがどのように発動されたかを確認し、「インサイト」ビューを通じて、今後の検出から偽陽性となる可能性のあるものを即座に除外することができます。
Sysdig Secure Tunerの提案により、将来のターミナルシェルアクティビティでNginxイメージがアラートのトリガーにならないように除外することができます。
多くのDevOpsエンジニアは、Day 2のセキュリティ運用（アプリケーションが最初にデプロイされ、安定した状態になってから）には不向きな状態にあります。彼らはKubernetes Threat Landscapeに関する幅広い知識を必要とし、最新のMITRE ATT&CKの条件からラテラルムーブメントを特定するための適切なツールを持っていないことが多いのです。この例として、Sysdigの2022 Cloud-Native Security And Usage Reportによると、27%のチームが管理タスクにルートユーザーアカウントを使用していることが挙げられています。
REPORT：2022 Cloud-Native Security And Usage Report
Sysdig Secureは、クラウドネイティブな脅威の緩和が可能なCloud Detection and Response（CDR）ソリューションです。脆弱性ライフサイクル管理をより深く可視化したい、Kubernetesの脅威検知でラテラルムーブメントを制限したいなど、30日間の無料トライアルでSysdig Secureを今すぐお試しいただけます。
クレジットカードの登録なしで、数分で開始できます。