Black Hatで最も印象的だったのが、TechStrong TVのAlan Shime氏とIDCのリサーチディレクターであるKatie Norton氏とのインタビューだ。AppSecとDevSecOpsの現状について、幅広い議論をした。この議論の中で、AppSec(アプリケーションセキュリティ)に対する現在のアプローチの欠点と、Contrastの新しいADR(アプリケーションにおける検知と対応)モデルがアプリケーションとAPIのセキュリティを向上させる方法について話す絶好の機会となった。是非、このインタビューを見てほしい。以下に要約も記載する。
AppSecが本番環境で機能していない
私たちは、DevSecOpsとAppSecが本番環境では機能していないという点で意見が一致した。開発において脆弱性の膨大なバックログを生み出しているだけだ。Ponemonの調査によると、平均的な組織には110万件の脆弱性のバックログがあるという。しかし、ほとんどの組織では攻撃に対する可視性も、それらの脆弱性が悪用されるのを防ぐ方法がない。
さらに悪いのは、DevSecOpsとAppSecが、本番環境にあるソフトウェアを保護するためにあまり役立っていないことだ。セキュリティの観点から、本番環境でアプリやAPIに何が起こっているのか全く把握できていない。攻撃も見えていない。
ここで皮肉なのは、DevSecOpsは部門とプロセス間の障壁を取り壊すことを意図するものだったのだが、多くの重要な点で、開発と運用の部門間に新たな壁を作り出してしまった。これはツールの仕組みに関係している。これらのツールによって、誰も処理したがらないバックログが生み出されるため、部門間の連携が阻害されてしまう。それはまるで、「ほら、あそこのグループにこの巨大なバックログの山を管理させよう」という感じだ。 これは人々をまとめるのに良い方法ではない。
DevSecOpsという考え方では、しばしば開発者にセキュリティ専門家のような働きを求めることがあり、それがこの問題をさらに悪化させている。同様に、セキュリティ専門家が開発者になることは決してない。私たちは、本番環境で発生するアプリケーションとAPIのインシデントに対処するために、誰もが力を発揮できる方法を見つける必要がある。
ADRでギャップを埋める
Contrast Securityは、Black HatでContrast ADRを正式に発表した。ADRは、まさにあなたが想像しているものだ。EDR(エンドポイントにおける検知と対応）、CDR(クラウドにおける検知と対応）、NDR(ネットワークにおける検知と対応)、XDR(拡張された検知と対応)と同じように、ADRをアプリケーションとAPIサーバにインストールするだけで、インシデントを検知し、運用部門に報告し、悪用を防ぐことが可能となる。ADRは、アプリケーション層におけるこうした様々なセキュリティギャップを埋め、既存のXDR、SIEM(セキュリティ情報/イベント管理)、CNAPP(クラウドネイティブアプリケーション保護プラットフォーム)のエコシステムにそのまま統合できる。これには、アプリケーションとAPIの両方が含まれる。ADRソリューションが攻撃を検知すると、セキュリティオペレーションセンター(SOC)や、SOAR(セキュリティのオーケストレーションと自動化による対応)プラットフォームなどと、その攻撃に関するテレメトリと完全なコンテキストを共有できる。
ADRが開発と運用をコンテキストでつなぐ
Katie Norton氏は、脆弱性と攻撃の両方を解釈し、評価するために必要な「コンテキスト」について重要な指摘をしている。開発者が見ているものとSOCで起こっていることの間には、大きな隔たりがある。例えば、開発者は脅威や攻撃を見ることができないのに、これらの2つのグループはどのように連携して脆弱性を対処するために優先順位を付けるのだろうか？また、運用担当者は、アプリケーションとAPIのワークロードが何をしているのか、どこに脆弱性があるのか分からない。そこでADRの出番だ。ADRにより、開発と運用の両方に完全な本番環境のコンテキストが提供され、優先順位付けという大きな課題を解決するための、強力な手段となる。コードのコンテキストだけでは、何をすべきかの優先順位付けはできない。そこで、Contrast Securityは本番環境のセキュリティオブザーバビリティを利用する。 これにより、開発者には完全なリスクコンテキストが提供され、運用部門では潜在的な危険領域を認識することができる。
APIセキュリティはAppSecそのもの
私たちの議論は、AppSecとAPIセキュリティの違いに関する話題へと発展した。セキュリティ専門家たちは、APIセキュリティをAppSecとは別のものとして扱うように言われてきたが、実際には同じではないだろうか？私たちは3人とも、APIは単にセキュリティテスト、検知、対応を必要とするソフトウェアとライブラリのもう一つの要素に過ぎないという結論に達した。
Katie Norton氏はこの問いに対して独特の見解を持っていた。それは、API保護とは主に本番環境側で行われきたということだ。問題は、本番環境からコード部分を理解できないことである。WAF(Webアプリケーションファイアウォール)は、現代のネットワークトラフィックにおいて多くを占める、APIトラフィックに関するテレメトリを提供する。しかし、WAFはAPIコードについて多くを明らかにしない。
DevSecOpsを機能させるための架け橋
この隔たりをどのように埋めるのか？ADRが解決策を提供する。ADRが本質的に橋渡し役となることで、この隔たりを埋める。例えば、運用部門は一般的に脆弱性、修復、バックログについては話さない。そして、開発者は、SIEMイベントやSOARプレイブックについては話さない。ADRの目標は、両者の言語を理解し、役割に関係なく人々が仕事をするために必要なデータを提供できるソフトウェアを作ることだ。この点において、データの精度が重要になる。質の高いデータがあれば、誰もが協力してDevSecOpsをより良く機能させることができる。
まとめ
ADRは新しい概念であり、AppSecでADRを活用してもらうために、お客様との対話を始めたばかりだ。しかし、私たちが話した誰もが、その必要性を認識していた。ギャップ、部門間の壁、可視性の欠如 - これらは、セキュリティ専門家、開発者、運用担当者が解決しなければならない現実の問題だ。ADRは、本番環境で発生している攻撃に関するデータを提供し、SOCチームやその他の重要な利害関係者と強化されたアラートを共有することで、これらの問題を解決できるのだ。
関連記事/サイト：
