ランタイムにこそ道がある

本文の内容は、2024年1月29日にJAMES BERTHOTYが投稿したブログ（https://sysdig.com/blog/runtime-is-the-way/)を元に日本語に翻訳・再構成した内容となっております。

クラウドセキュリティ市場が始まって以来、私たちは奇妙なことに未来を定義する新しいプロセス、ツール、導入について一緒に学んでいます。ワークロードをカウントするために Python スクリプトが提供されるのはなぜでしょうか? 「新しい暗号化されていないデータベース」などのアラートを SOC に送信するにはどうすればよいでしょうか? このツールとオープンソースオプションの違いは何でしょうか?

クラウドリソースがオンプレミスのリソースとは異なるという考えは賭けであり、初期にクラウドリソースに投資した企業にとっては大きな利益をもたらしました。マーケティング資金のおかげで、クラウドセキュリティポスチャー管理 (CSPM) は、ギャップが特定される前にクラウドセキュリティに必須のツールとなりました。クラウドネイティブアプリケーション保護プラットフォーム (CNAPP) は、混乱を一掃する方法として登場しました。Gartner は、CNAPP を「開発と運用全体にわたってクラウドネイティブアプリケーションを保護するために設計された、統合され緊密に統合されたセキュリティおよびコンプライアンス機能のセット」と定義しています。言い換えれば、セキュリティとコンプライアンス関連のすべてを 1 つのプラットフォームで行うことができます。しかし、クラウドでは、それらの「機能」の詳細が大きな違いを生みます。

下記について学び続けるためにぜひこのブログを読み進めてください:

ランタイム保護がこれまでクラウドセキュリティチームにとって最優先事項ではなかった理由
ランタイム保護を優先することに対する主な反対意見は何でしょうか？
ランタイムセキュリティがどのクラウドツールにおいても最高の投資収益率となる理由

典型的なクラウドセキュリティの取り組み

初めてのクラウドセキュリティの役割に就いた初日、CISO が私のところにやって来て、「開発者が何をしてきたのか、そしてそれをどのように保護するのかを把握してもらいたいのです。」と言いました。この言葉は、多くのセキュリティエンジニアがクラウドセキュリティに取り組むまでの道のりが遅れていることを完璧に表しています。以前のセキュリティの世界では、Windows サーバーと SIEMでEDR を管理することが重要でした。新しいものでは、根本的に異なるスキルセットが必要でした。つまり、すべてのセキュリティエンジニアは、コーディングから Kubernetes まで、標準ツールキットに含まれていないスキルを迅速に学習する必要がありました。

当時は知りませんでしたが、「開発者が何をしているのかを理解する」ことは大きな課題です。どうやって信頼を築くのでしょうか？どうやって可視性を得るのでしょうか？どうやって優先順位を付けるのでしょうか？これらの質問よりもさらに根本的なのは、どうすれば自分がバカだと感じないのかということです。私は主任設計者とのミーティングを 2 週間後に予定し、それまでに解決したいと考えていました。

何かを保護するには、それが何であるかを知らなければなりません。残念ながら、最新のアプリケーションが何であるかを知ることは非常に困難です。社内でアプリケーションのメンタルモデルを維持できる人はほとんどいません。これが、セキュリティがこれほど難しい立場に陥っている理由です。仕事をうまく進めるには、多くの場合、主任エンジニアやアーキテクトといった選ばれた人々と連携する必要があります。なぜなら、クラウドエンジニアリング、特に Kubernetes とクラウドネイティブサービスアーキテクチャーは、セキュリティ専門家にとって絶えず進化するスキルであり、特に不利な立場にあるからです。クラウドをほとんど使用したことがない人が、クラウドで最先端のアーキテクチャーを構築している人を指導することがよくあります。

その結果、私が見てきた限りでは、ほぼすべての企業がクラウドセキュリティに初めて進出するのは、他の機能よりも一般的な可視性を優先し、不安に駆られていることがわかります。恐怖は主な動機であり、セキュリティの不安が最初の大きな購入の動機となる可能性があります。これは確かに私自身にも当てはまりました。アカウントの設定ミスをチェックするための AWS ロールを作成できる既存のベンダーとの関係を拡張することで、すぐに価値を付加できるように感じました。最初の発見を修正しようとして初めて、セキュリティと開発者の関係を悪い方向からスタートさせながら、すでに負担を抱えているチームに無関係な多忙な仕事を生み出していることに気づきました。

構成ミスのスキャンが主要な問題ではなかったことがわかるまでに、それほど時間はかかりませんでした (最初のチケットを開発者に送信するのにかかった時間と同じくらい)。ほとんどの企業は、これらのアラートはSOCに送信されるべきであると誤って想定しており、SOCは何もできないアラートにすぐに溺れてしまいます。多くのセキュリティチームは購入したツールを通じてクラウドについて学習しているため、開発者全員が構成をコードとしてプッシュしており、実行時に構成をスキャンするのはすでに手遅れであることを複数年契約が始まるまで知りません。さらに、同社のCSPMツールには誤検知、または修正するには数か月のエンジニアリング時間がかかるような小さな脆弱性が多数あります。

セキュリティ部門はランタイムの可視性を優先していましたが、実際にはコード時の可視性、つまり「シフトレフト」が必要であることを知るのが遅すぎました。通常、これにより、検出と可視化をますます向上させようとする終わりのない罠が発生し、複雑なチケット発行ワークフローが作成されます。実際には、脆弱性がゼロになることはありませんが、ツールがクラウドをスキャンしていてコードを認識できない場合、それを修正できるチームに関連情報を提供することはできません。たとえば、私の安全でないアプリのデプロイメントのテストリポジトリでは、シークレットキーの削除は 1 行のコード変更ですが、実行時に環境変数がどこから来ているかを確認するのは非常に困難になる可能性があります。

私が見てきたところでは、クラウドセキュリティツールを導入した企業のほとんどがこのような状況にあります。彼らは、脆弱性の件数が右肩上がりにしかならないため、CSPMが思っていたような価値を提供していないことに気づいています。現時点では、チームが 2 つの方法のいずれかを行っているのを見てきました。構成スキャンのワークフローをさらに深く掘り下げるか、損失を削減して実行時のセキュリティを優先するかのいずれかです。

脆弱性の数に囚われて、「どうすればこれをなくすことができるか？」という質問に過剰に執着してしまいがちです。しかし、これでは「このグラフを下げると実際に何か効果があるのか?」という核心的な質問が抜け落ちています。説明しやすくするために、CSPM とランタイム保護を比較した次のクラウドアプリケーションの図を見てください。

実際の攻撃を特定または阻止することが目的の場合、CSPM とランタイム指向のツールが提供するものには根本的な違いがあります。コンピューティング層に対する意味のある可視性を備えているのはそのうちの 1 つだけです。クラウド API とスナップショットスキャンで確認できることはたくさんありますが、Kubernetes ポッドの内部とその動作を確認できない場合は、常に盲点が存在します。

重要なことは、ランタイムツールは単にレスポンス機能を獲得するだけではありません。また、すべてのサービスにわたるログデータを確認し、直接計算することで、CSPM よりも優れた可視性を提供します。では、なぜセキュリティチームはそれらを使用しないのでしょうか? まず、これは以前に共有した話です。多くの場合、セキュリティチームにとって可視性が最初の主要な評価基準となります。ただし、ランタイムファーストのアプローチをとることには反対意見もあります。

ランタイムツールに対する反対意見に答える

私は最近LinkedInで、なぜランタイムを売るのはビジビリティよりも難しいのかについて尋ねました：回答を分類すると次のようになります。

ランタイムの価値を示すのは時間がかかりすぎるし、難しい。
顧客は、まず可視性を確保する必要があると感じています。
ブロックするのは怖い。
エージェントのインストールは難しい
k8sの環境でk8s以外のエージェントを使うのは嫌です。

Anton Chuvakin 氏のコメントがそれを最もよく要約しています。「ランタイム保護はリスクが高く、導入の負担もはるかに大きいと考えられています。」

ランタイムの価値を示すのは難しすぎる

セキュリティスキャンソリューションを販売する短いながらも楽しい時間の中で、ほとんどの人は結果のみに注目しており、PoC 中に (たとえ実施したとしても) 詳細に注目することはめったにないことを、私は直接学びました。1 つの検出を示すデモを見ると、ツール全体で多数の重大な検出が発生していると自動的に想定します。ランタイムの販売が難しい理由は、セキュリティチームがデモに安易に慣れてしまうためです。多くの場合、詳細を確認する必要があることがあります。

私は最近 2 つのビデオを作成しました。1 つはランタイム Kubernetes セキュリティについて詳しく説明したもので、もう 1 つは Kubernetes 脆弱性スキャンに関するものです。当然のことながら、脆弱性スキャンツールは運用開始までにそれほど時間がかかりませんでしたが、発見された結果を修正することは検出することより難しいため、ビデオ全体が長くなりました。ランタイムの価値を確信する唯一の方法は、結果に集中し続けることです。脆弱性スキャナーの実装により、1 年分の作業が必要になりましたが、ランタイムセンサーの実装により、修正する必要があった攻撃の 90% がブロックされました。

ここで言いたいことは：ランタイム・ツールの価値を20分のセールスコールで示すのは難しいでしょうし、売り手はその代わりにツールから得られる結果に焦点を当てる必要があります。あなたが買おうとしているのは、製品チームの仕事を増やすことではなく、攻撃を阻止するためのものなのです。

セキュリティチームは、まず可視性を確保する必要があると感じている

私はこの反対意見に同感です。それは私自身のクラウドセキュリティの取り組みで起こりました。過去に戻って自分自身に 2 つのアドバイスを与えることができるとしたら、それは次のとおりです。

意味のある可視化はコンピューティング層で行われます。
開発者が問題を修正しないのは、それが本当に難しいからであり、それについて知らないからではありません。

セキュリティ・ツールを購入する前に、DevOpsチームやSREチームのメンバーをシャドーイングして、クラウド環境を管理するためのあらゆるツールを見せてもらいましょう。彼らが可視化ツールを持っていることは保証しますし、あなたは「すごいな、それにアクセスさせてもらえないかな」と通話中に何度も言うでしょう。

シンプルな可視化ツールなどというものはありません。シンプルなものは重要な計算データが欠落し、必要なものが表示されているという誤った保証を提供してしまうからです。最小のリフトで最大の可視性のみを優先する場合は、すべてのクラウド API をクロールして環境の全体像を構築するだけのツールを購入することになります。おそらく、スナップショットスキャンが行われ、レガシーワークロードの可視性が限定的に得られる可能性があります。自問してみてください。もし私が環境内のワークロードに接続した攻撃者だった場合、それを示すツールはあるでしょうか? 私たちは、ダッシュボードを見るためだけではなく、セキュリティの成果を達成するための可視性を求めています。また、クラウドセキュリティツールに Kubernetes やコンテナの可視性がない場合は、存在しないのも同然です。

さらに、可視性は役立つ場合もありますが、最良の可視性は開発者との良好な関係です。開発者は、コード内のどこにエクスプロイトが潜んでいる可能性があるかを知っています。彼らについて質問する必要があるだけです。これが、私がオープンソース AI セキュリティスキャナーの作成を支援している理由です。一般的な小切手は、100万枚のチケットよりも役に立ちます。

要約すると、可視性の容易さは誤解を招くため、災害が起こるのを待っているということです。エクスプロイトが発生しているのが見えない場合、本当に何かが発生していると言えるでしょうか? 警備会社が設置すべきカメラのリストをくれたので、自宅防衛システムを持っていると言っているようなものです。何かを得たような気分になるかもしれませんが、実際には、やるべきことが増えただけです。

なにかをブロックするのは怖い

ブロックされることへの恐怖は現実のものですが、それは WAF や EDR の時代の名残です。WAF ルールの構成が間違っていると、EDR と同様にアプリケーションが完全にダウンする可能性があります。Kubernetesの Cattle vs Pets ルールは、運用に革命をもたらしただけでなく、ランタイムのセキュリティにも革命をもたらしたはずです。エージェントが数千のユーザーにサービスを提供する Web サーバー上で実行中のプロセスを強制終了すると、最悪の事態になります。Sysdig エージェントが悪意のあるアクティビティを検出したポッドを強制終了した場合、朗報です。さらに何百ものポッドがトラフィックを受け入れる準備ができています。コンテナの世界における EDR は、以前ほど恐ろしいものである必要はありません。

さらに、コードとして定義されるランタイムが増えているため、Kubernetes セキュリティルールには明るい未来があります。コンテナプロセスとネットワークフローのモデルを構築し、逸脱をブロックできます。エージェントの使用率とレスポンスのしきい値を設定できます。ブロックすることを実装するには怖すぎると考える必要はもうありません。必要なのは、Kubernetes の考え方に専念することだけです。

エージェントのインストールが難しい

これも Kubernetes 以前の名残で、エージェントのデプロイと保守は非常に面倒でした。大規模な Ansibleプレイブックを実行しようとする場合でも、GPO を介して大量にデプロイする場合でも、エージェントを配置するプロセスを楽しむ人は誰もいませんでした。逆に、Kubernetes を使用すると、エージェントのデプロイがほぼ楽しくなり、さらに重要なことに、セキュリティチームにとって素晴らしい学習体験になります。

helm chartをインストールするDevOpsと手を取り合って作業することは、それだけでランタイムツールを購入する価値があると思えるほど、キャリアを決定づける学習経験です。確かに、DevOpsチームは新しいものをインストールすることに最初は文句を言いそうですが、誰もが常に変化について文句を言うものです。

チケットや新しいエージェントについて不満を言うことはあっても、セキュリティチームが kubectl と Helm の使用方法を学習していることについて不満を言った DevOps チームはいませんでした。エージェントのインストールに伴う短期的な痛みは、手を汚さずに実際に DevOps に引き渡した場合にのみ痛みが残るだけです。Kubernetes エージェントがないからツールを選択するのではなく、Kubernetes エージェントがあるからツールを選択する必要があります。実践的な経験とコラボレーションには、ツール自体よりも価値があります。

古いEDRでの悪い経験

おそらく、レガシープロバイダーとの第 1 世代の Kubernetes “インテグレーション”をインストールしたため、ランタイムツールがないのかもしれません。インストール手順はすべてベータ版で、エージェントは扱いにくく、可視性は重要ではないようです。Kubernetes 固有のランタイム保護ベンダーを検討する価値があります。インストールから視認性まですべてが向上しています。

初めてKubernetes環境のEDRを評価したとき、私はレガシーなEDRプロバイダー、Sysdig、そしてもっと “クラウド “なベンダーからいくつか検討しました。その中で “クラウド “ベンダーは、非常に基本的なアラート（新しいネームスペースの作成など）で動作させることができました。レガシーEDRに関しては、文字通り壊れていると思っていました。ポッド内部で、特権昇格、コンテナエスケープ、パスのトラバーサルなど、攻撃を仕掛けてみたのですが、すべてゼロアラートでした。2年後、私はレガシーEDRプロバイダーと再会し、再度評価を行いました。しかしこの時、彼らが本当にコンテナ内のランサムウェア攻撃しか調べていないことを知りました。

コンテナのEDRに関しては、MITRE テスト、Gartner マジッククアドラント、今月の流行語などの古い評価をすべて放棄してください。そして、https://github.com/latiotech/insecure-kubernetes-deploymentsを使用して自分でテストしてください。

ランタイムのROI

最近、どのCNAPPプロバイダーも同じような見積もりを使っています。どのプロバイダーも同じような価格設定で、独自の “ワークロード “を設定しています。残念ながら、どのCNAPPプロバイダーが最大のROIをもたらすかを測定するのは困難です。

一般的な評価基準をひっくり返す理由は次のとおりです。

結局のところ、ランタイムは四半期ごとの作業のために製品チームを保護し、チケット発行ワークフローによって開発者自身が作業を管理できるようにし、検出の品質によって構成ミスを見つけることができ、可視性によって開発者に追加のコンテキストが提供されます。目標は開発者の効率性を高めることですが、古い評価優先順位は非効率性を生み出します。開始するために基本的な可視性が必要な場合は、複数年の CSPM 契約に署名せずに、Prowlerを実行するだけです。

1.ランタイムのない CSPM は役に立ちません。

もちろん、これを宣伝する人は誰もいませんが、CNAPP プロバイダーはランタイム保護またはクラウドスキャンに基づいて構築されています。真実は、構成はクラウドではなくコード内で行われるということです。そのため、クラウドの構成スキャンを主な目的として購入するのはやめてください。CSPM の可視性は、一般的なアプリケーションの可視性に関するいくつかの優れた機能を提供しますが、CNAPP の価値は、アプリケーションの実際のコンピューティング層で何ができるかにあります。クラウドセキュリティ強化の中心は、Terraform モジュールと IaC スキャンを通じて行われる必要があります。クラウドセキュリティプログラムの中心は CNAPP ランタイム保護である必要があります。

2.セキュリティは構成スキャンのエンドユーザーではありません – 開発者がエンドユーザーです。

多くのセキュリティチームは、CSPM への初期投資が原因で、負のスパイラルに陥っています。彼らは膨大なアラートの山を抱え、それらの管理に役立つツールを探しています。その状況を「ツールを直すためにツールを買う」、と言います。根本的な問題は、セキュリティユーザーとして、表示されているアラートに対して何もできないことです。すべての開発チームにセキュリティメンバーが組み込まれるほど大規模なセキュリティチームがない限り (これを行う人はいません)、CSPM からのアラートを単独で修正するのに十分なコンテキストを得ることができません。これにより、セキュリティチーム全体がプロジェクトマネージャーとビジネスアナリストとして拘束され、チケットを移動して脆弱性の傾向を分析するというプロセス上の問題が発生します。

ランタイム保護は、セキュリティに実際に実行できる何かを与えるという点で異なります。ランタイムアラートが表示された場合、調査、コンテナの強制終了、ネットワークポートの閉鎖などのアクションを独自に実行できます。ランタイムセキュリティにより、セキュリティチームは実際に直接的で有意義な作業を実行できるようになります。

3.実際の攻撃を阻止できるのはランタイム保護だけです

私が参加したすべての興味深い調査は、誤検知であろうとなかろうと、ランタイム保護ツールから来ています。私は DAST (悪い古いものではなく、良い新しいもの) だけが実際の SQL インジェクションやパフォーマンスの問題を見つけているのを見てきました。私が見たのは、コンテナ保護が不審なポッドアクティビティを検出することだけです。内部アドレスが外部ソースから攻撃されようとしたことをファイアウォールが検出したのを見たことがあります。

サービスを強化するのに何年も費やすこともできますが、Log4Jレベルの脅威が発生するたびに、レイヤー防御のオプションが用意されていることに感謝しています。WAFルールを実装し、ランタイムアラートを設定し、SIEM検出を設定して、設定を修正する時間を稼ぎます。大規模な調査中にクローズされるアプリケーションをご存知ですか？CSPMです。私はコードスキャンを行い、開発者にパッチを当てるよう指示し、ランタイム防御のレイヤーで時間を稼ぎます。私はランタイムソリューションを持っていたので、チケットを渡す以外に実際に何かをすることができました。

私のクラウドセキュリティのジャーニーでの結論は、他のすべてを事実上無視して、ランタイムの Kubernetes 機能に基づいて CNAPP を評価することでした。構成アラートは開発者向けであり、ランタイムアラートはセキュリティ向けです。脆弱性が 0 個であろうと 10,000 個であろうと、実際に攻撃を阻止できるのはそのうちの 1 つだけです。コンプライアンスや脆弱性チャートよりもアプリケーションのセキュリティを重視する場合は、ランタイムが最適であると私は確信しています。

James Berthotyについて：

エンジニアリングとセキュリティ分野で10 年以上テクノロジーに携わってきました。DevSecOps の初期の提唱者である彼は、製品へのコントリビューターとしてセキュリティチームを推進することに情熱を持っており、人々を適切な製品に結び付けるのに役立つ Latio Tech を構築しました。妻と 3 人の子供とともにノースカロライナ州ローリーに住んでおり、哲学の博士号取得を目指しています。