使い物にならないAppSecツールを捨てて「ランタイムセキュリティ」を使おう

サンタさん、正直に教えてください：昔ながらのAppSecツール(アプリケーションセキュリティツール)はどこから来たのでしょうか？セキュリティ専門のエルフたちに、毒キノコのカケラやクモの巣をかき集めて作ってもらったのですか？

現在の状況を考えると、従来のAppSecツールは開発者が設計したわけではないことは明らかだ。開発者とは、セキュリティの問題を解決するためにツールの調査結果を使用する必要がある人達(あるいは、場合によっては、問題ではないもの、つまり誤検知を追いかけて時間を無駄にしている人達)である。そして、言うまでもなく、誤検知を見逃すこともあるため、セキュリティ管理者の安全に対する認識は誤ったままになる。

従来のツールと言えば、AppSecの略語だらけの中に浮かぶ石炭の塊(サンタが悪い子の靴下に入れるもの)なのだ：

• 静的アプリケーションセキュリティテスト (SAST)
• 動的アプリケーションセキュリティテスト (DAST)
• Webアプリケーションファイアウォール (WAF)
• 静的ソフトウェアコンポジション解析 (SCA)

非常に多くのツールがあり、これら4つの石炭の塊(Application Security Posture Management [ASPM]や、Application Security Orchestration and Correlation [ASOC]などが必要な場合は5つ目も追加する必要あり)をすべてインストールして、管理する必要があるとなると、一気に複雑さが増す。その結果、セキュリティ戦略がバラバラになり、遅延、摩擦、追加コストなどが発生し、セキュリティリスクを減らそうとしている部門は手に負えなくなる。

 正直に言って、今日のAppSecのアプローチは根本的に破綻している。堅牢なセキュリティを、こんな粗悪なツールの寄せ集めでつなぎ合わせるのは、あまりにも難しすぎる。

具体的に不満な点： 

使い物にならない従来のAppSecツール

SASTツールは視野が狭い：SASTツールは、目先のことしか見えない。SASTツールはソースコードを見るため、完全に組み立てられたアプリケーションが実際にどのように動作するかを見ることができない。カスタムコードがランタイムプラットフォーム、アプリ/APIサーバ、ライブラリ、フレームワーク、他のリポジトリからのコード等とどのように相互作用するのかは分からない。ほとんどの脆弱性は、カスタムコードとこれらの全てのコンポーネントの両方にわたって存在するため、SASTツールによって多くの間違いが発生することになる。

DASTはうわべだけ：一方、DASTツールは、完全に組み立てられた実行中のアプリケーションを実際に解析する。しかし、DASTは外部から内部に対して機能するため、実際に悪用してHTTPレスポンスで検知できる脆弱性のみを検出する。おそらく最悪なのは、DASTツールがスキャンできるのは「フロントドア」だけで、最新のアプリケーションのバックエンドインターフェイスや接続を全てスキャンできるわけではないことだ。要するに、DASTは手間がかかるし、ミスも多いということだ。

静的SCAツールはオオカミ少年のよう：静的ソフトウェアコンポジション解析(SCA)ツールにはSASTと同様の制限があり、アプリケーションの実行時に何が起こっているのかとは切り離して、アプリケーションの依存関係という1つの側面だけを対象としている。つまり、ライブラリがアプリケーションで実際にどのように使用されているのかは判断することができない。確かに、主要なSCAツールの中には、実際に「到達可能性解析」を実行する。言い換えれば、サポートされているいくつかの言語に対して、アプリケーションが実際に脆弱性に達しているかどうかを解析する。そうでなければ、そのソースコードで検出された脆弱性は無害である。それは役に立つ。しかし、到達可能性解析を考慮に入れても、依然としてSCAの検出結果の大部分は悪用できない誤報であることに変わりない。

WAFは肩越しに見てるだけ：WAFは、管理が難しいこと、アプリケーションやAPIを破壊すること、実際の攻撃を見逃すこと、バイパスされる可能性があることなどから、長い間批判されてきた。この問題の根本的な原因は、WAFがHTTPトラフィックを調べる際に、過去に確認された攻撃を表す、あらかじめ決められたパターンのみを対象としていることにある。このようなツールでは、考えられる全ての攻撃のパターンを捉える方法はない。

過去数週間にわたり、伝統的で欠点のあるツールによって引き起こされたお粗末な状況が繰り返されてきた。要約すると以下のようになる：

警告にうんざり 

これまでに何度も耳にしたことがあるだろう。セキュリティ部門は、絶え間ない警報の砲撃に耳をふさがれ、サイロ化されたツールの寄せ集めから流れてくる大量のアラートに圧倒されている。実際、最近の調査によると、調査対象となったIT意思決定者の59%が、1日あたり500件を超えるクラウドのセキュリティ警告を受信している。

これら全ての警告が正確なものであり、注意を払う必要があれば話は別だ。しかしながら、実際には不正確であることがあまりにも多い。実際、あまりにも多くのセキュリティ警告が優先順位の低いものであったり、まったくの偽物だったりする。

調査によると、企業の5分の2以上(43%)の過検知率が40%に達している。誤報は、単に迷惑なだけではない。実際、過検知はAppSecプログラム全体の経済的側面に大きな影響を与える。

ContrastのCTO兼共同設立者であるJeff Williamsが説明しているように、ツールによって報告された脆弱性が真実かどうかを見極めるには、本当に優秀なら10分でそうでなければ何時間もかかることがある。「(ほぼ全ての企業がそうであるように)リソースに制限がある場合、ツールで報告されるすべての脆弱性を調査することはできない。」と彼は言う。

例えば、アプリケーションで静的スキャナ(SAST)または動的スキャナ(DAST)を実行したところ、400個の脆弱性の可能性が検出されたとする。大量の警告の中には、本当に重大な問題が絶対に存在するはずで、そうした脆弱性には迅速な対応が必要だ。問題は、それらが干し草の山の中に隠れている針であるということだ。事実、企業の約65%は実際に重要な警告は10%のみであると回答している。

つまり静的または動的スキャナで脆弱性の可能性が検出された400件のうち、真の脆弱性は40件のみということになる…

.... しかし、どれが正しく検知されたもので、どれが過検知であるかが分からなかったために、何が本当で何が偽物なのかを見極めるために、山のような脆弱性を切り分けようと時間を費やすことになる。「これらの『潜在的』な脆弱性を100個検討する時間しかないと想像しよう。」とJeffは言う。「どんなに速くても、1つ1つ調べるのに10 分はかかるだろう。400件すべてを行うには、8日以上かかる計算になる。でも、2日しかないから25％だけ分析する、となる。そうすると、アプリケーション内の真陽性の10件は確定するが、残り30件の本当の脆弱性を見逃すことになる。」

このような誤検知の結果：

• 真陽性でも修正されるものがほとんどなくなる
• 対策・修正に長い時間がかかる
• 増え続けるバックログに悩まされる

これを読んだら泣かずにはいられない。

誤算に基づくAppSec

企業は重大な脆弱性を修正するのに平均2か月近くかかっている。対応/修復の平均時間(MTTR)が60日というのは、膨大なバックログがあるということを意味する。これは不当な計算であり、健全なAppSec環境とは言えない。

このようなMTTRは、膨大なバックログがあることを意味し、修正すべき点に優先順位を付けるためにセキュリティエンジニアが必要であることを意味する。セキュリティエンジニアが掘り下げて解明しない限り、何が本当の問題なのか(何が過検知で、何が正しく検知されているのか)を見極めることができない。

これを読んだら悲鳴を上げずにはいられない。

炎上するゴミ箱のようなAppSec予算

まったく意味がない：Forresterが実施した2022年のセキュリティ調査によると、セキュリティに関する意思決定者の63％が、景気後退にもかかわらず、2023年には自社のAppSec予算を増額する予定であると回答している。これらの企業は、攻撃された回数が多ければ多いほど、さらに火に油を注ぐ可能性が高くなる。つまり、そもそも攻撃から守るべきテクノロジにさらにお金をかけるというのだ。

AppSecへの支出が増加している理由は？答えは簡単だ。ツールが機能していないからだ。このお金がどこで無駄になってるのだろうか？と疑問に思うかもしれない。 それらは、使い物にならない従来のAppSecツール、お粗末なプロセス、膨大なバックログ、そしてそれらのツールが絶え間なく発する誤報に対するものだ。

これを読んだらビビらずにはいられない。

従来のAppSecツールで高度なサイバー攻撃を撃退しようとするのは、ひとまず忘れよう。実際のところ、OWASPトップ10ような昔ながらの脅威にも対応できていないのだから。従来のツールは、十分に理解されている脅威に対してでさえ効率・効果が低いのだ。

しかし、元気を出してほしい：守られなかったAppSecに終わりが見えてきた。それは、Contrast Securityが提供するランタイムセキュリティと呼ばれるものだ。

ランタイムセキュリティ革命の実現

ランタイムセキュリティは根本的に新しい考え方で、AppSecでうまくいかなかったことを解決する。それは、アプリケーションのライフサイクル全体を網羅する運用パラダイムであり、開発からデプロイまでの全てのフェーズで重要な洞察と保護を実現できる。

ランタイムのアプローチによって、まざまな機能が単一のソリューションとして統合される。IAST(インタラクティブアプリケーションセキュリティテスト)、RASP(ランタイムアプリケーションセルフプロテクション)、R-SCA(ランタイムソフトウェアコンポジション解析)、オブザーバビリティなどの機能が一元化される。

このように相互に関連する機能が、ランタイムセキュリティのテクノロジを活用して1つのまとまったフレームワークとなる。そして、ソフトウェア開発の全段階で継続的な監視とプロアクティブな防御が可能になるため、DevOpsの実践や継続的インテグレーション/継続的デプロイメント(CI/CD)パイプラインには最適となる。

ランタイムは、アジャイル手法や現代のソフトウェア開発など速いペースにマッチする、汎用性のある効率的なセキュリティモデルになる。もう少し詳しく説明しよう：

ランタイムセキュリティとは？

要するに、ランタイムセキュリティは、高度なインストゥルメンテーション(エージェントによるアプリケーション内部からの検査)を使用して、既存のセキュリティプロセスを再構築し、よりプロアクティブで洞察力のあるものにする。ランタイムは単一のテクノロジだが、これはAppSecにどうアプローチするかを再定義する一連の機能である：

• ランタイムアプリケーションセキュリティテスト (R-AST)：R-ASTは、包括的なコード解析によるカスタムコードの脆弱性の検出が中心となる。ただし、サードパーティのコードとファーストパーティのコードを区別することはなく、両方のコードタイプのセキュリティを詳細に検査する。ライブラリの脆弱性を特定することもできるが、大半はカスタムコード自体からの検出となる。R-ASTは開発中にリアルタイムで動作し、コーディング中に脆弱性が発生すると、即座に担当・部門に警告される。 
  
  
• ランタイムSCA：ランタイムSCAは、アプリケーションで使用されるライブラリを特定し、SBOM(ソフトウェア部品表)を作成することから始まる。R-SCAは、ソースコードリポジトリ内の依存関係マニフェストのみを検査する静的SCAツールから得られるものよりも、正確な情報を提供する。静的SCAツールは2つの点で失敗している：実行中のアプリケーションで一度も使用されていないライブラリが報告されることが多いのと、コンテナベースの開発ではよくある、実行環境によって入り込んだ依存関係を見逃すことだ。R-SCAでこの課題に対処できる。静的SCAのような不正確な情報ではなく、SBOMが包括的かつ関連性のあるものになるからだ。静的SCAと同様に、R-SCAでは、このより正確なSBOMをデータベースと相互参照し、アプリケーションの依存関係の特定のバージョンに対して公表されている脆弱性があるかどうかを確認する。そして、それらのみがR-SCAでは脆弱性として報告される。
  
  
• RASP：RASPは本番環境における脆弱性に対する防御の最前線を形成するプロアクティブな機能だ。潜在的な脅威(攻撃者、その手法、標的の特定など)をコードレベルですべて把握することができる。脅威の検知と軽減におけるそのスピードと精度は他に類を見ない。
  
  
• ランタイムアプリケーション・セキュリティオブザーバビリティ：分散アプリケーションの実際の生のセキュリティ青写真があることを想像して欲しい。セキュリティオブザーバビリティと呼ばれるこの機能は、アプリケーションとAPIの操作を多方面から監視する方法で、攻撃対象、防御、危険なメソッド、APIエンドポイントへのアウトバウンドコール、システムインタラクション、データベース接続、ファイルシステムのやり取りなどが対象に含まれる。オブザーバビリティがあれば、セキュリティ担当がセキュリティシナリオの調査のために週末を費やすことになるような質問に対して、苦痛せずに自動的に必要な答えが得られる。
  
  

以上は、ランタイムセキュリティで実現できることのほんの一例だ。

使い物にならない従来のAppSecツールから抜け出す準備はできているだろうか？過検知や検知漏れには、もううんざりなのでは？誤ったAppSecの計算に頭を悩ませたり、見かけ倒しのものにAppSec予算を浪費するのはもうたくさんなのでは？

もしそうなら、12月12日(火)午前11時(PST)/午後2時(EST)に、Forrester ResearchとContrast Securityによるウェビナーに参加してほしい。この革命に備えよう：ランタイムセキュリティを使用してAppSecを作り替え、アプリ/APIを内側から強化する方法を学ぼう。

続きを読む

• 従来のAppSecツールの危険性とランタイムセキュリティの優位性(ポッドキャストの記事)
• 過検知＋検知漏れ＝実際のコスト(ブログ)
• 統計についての話：AppSecが誤った計算に基づいて行われている理由(ブログ)
• 無駄なAppSecにお金をつぎ込んではいけない(ブログ)