無駄なAppSecにお金をつぎ込んではいけない

「これはどういうことなのか？」と問う部門からこんな調査結果が得られた：企業は、セキュリティインシデントの件数が増えるほど、アプリケーションセキュリティ(AppSec)に資金を投入する計画を立てる可能性が高くなると。つまり、AppSecはセキュリティインシデントを防ぐテクノロジーだが本末転倒となってしまっている。

AppSecへの支出が増加している理由は？答えは簡単だ。ツールが機能していないからだ。

数字で見る

Forresterが2022年に実施したセキュリティ調査によると、セキュリティ意思決定者の63%が、景気後退にもかかわらず、2023年には自社のAppSec予算が増加すると回答している。これらの企業は、サイバー攻撃によるセキュリティインシデントの発生頻度が高くなるほど、AppSecというゴミ箱の火にさらに油を注ぐ可能性が高くなる。

具体的には、自社が侵害されていないと回答した企業のうち、52％がAppSecの支出を増やす予定であると回答している。過去1年間に1回から5回、セキュリティインシデントが発生したと回答した企業に関しては、AppSecの支出を増やす予定であると回答した企業は63%に上った。また、前年に6回以上セキュリティインシデントが発生した企業のうち過半数(78％)が2023年のセキュリティ予算を増やす予定であると回答した。もっとも、セキュリティインシデントが発生した場合のコストを考えると、AppSec対策を講じる理由は十分にある。実際、Forresterは正当なAppSecを「必須」とまで呼んでいる。

その理由は、長年にわたって脆弱なアプリケーションが情報漏えいに関係しているからだ。Verizonの2023年度データ漏洩/侵害調査報告書(DBIR)では、この傾向が続いていることを強調している。ここでも、Webアプリケーションが最も頻繁に攻撃されるターゲットとなっている。また、API(アプリケーションプログラミングインターフェース)も攻撃に最適なターゲットとして急浮上しており、APIセキュリティは「注目のAppSecツール」となっている、とForresterは述べている。最近の調査によると、企業の74％がAPIに関連するセキュリティインシデントを3回以上経験したと報告している。最近のAPI関連の侵害では、980万人のOptusユーザ、540万人のX(旧Twitter)ユーザ、3700万人のT-Mobileユーザなど、数千万人の顧客の個人データが流出した。

実際、自社で6回以上セキュリティ侵害を受けたことがあるうちの3分の2は、侵害コストの総額が200万ドルを超えていると回答しているが、この数字にはブランドへのダメージや機会損失のコストは含まれていない。

使えないセキュリティに資金を費やさないためには

効果のないセキュリティ対策に費やした費用を取り戻そうとして、さらなる損失を重ねる前に、企業は既に確立されたプロセスで既に行なっていることの全体像を理解することが重要だ。新しいツールやテクノロジによって、開発者の作業やセキュリティ担当のタスクが停滞するのは、最も避けたいことである。そのため、Forrester は企業が次のようなツールを探すことを勧めている：

1. 開発ワークフローにシームレスに適合できる。
2. 正確な結果を得られる。
3. すべての開発担当にわたるCI/CD(継続的インテグレーション/継続的デリバリー)パイプラインにセキュリティガードレールを組み入れることができる。

しかし、Forresterには失礼ながら、Contrastではそのリストの最初には「実際に機能するツールを導入する」を挙げるべきだと考えている。さらにAppSecテクノロジーに投資する前に、既に何があるのか、うまく機能しているものはどこか、そしてそれが無駄な投資であると判明しているのはどこであるかを厳しくチェックすることは理にかなっている。
無駄になったAppSec投資を評価する際には、次の点に注意すべきだ：

AppSecソリューションに対する無駄遣い
あまりにも多くの企業が壊れたツールにお金を浪費している。問題点は次の通り： 

SASTツールの問題

SAST(静的アプリケーションセキュリティテスト)ツールやテクノロジは、脆弱性を早期に発見するために開発パイプラインでよく使用される。これは理にかなっている。リリース前に脆弱性を防ぐことができれば、その方が良い。しかし、SASTツールは外側からアプリケーションの内部を解析する。つまり、ソースコードしか参照しないため、完全に組み立てられたアプリケーションが実際にどのように動作するのかは確認できない。

カスタムコードがランタイムプラットフォーム、アプリ/APIサーバ、ライブラリ、フレームワーク、他のリポジトリからのコード等とどのように相互作用するのかは分からない。ほとんどの脆弱性は、カスタムコードとこれらの全てのコンポーネントの両方にわたって存在するため、SASTツールによって多くの間違いが発生することになる。

DASTツールのジレンマ

一方、DASTツールは、完全に組み立てられた実行中のアプリケーションを実際に解析する。DAST ツールは、ハッカーの活動をエミュレートし、実行中のWebアプリケーションに悪意のあるデータを送り込む。DASTは、シミュレートされた攻撃に対してアプリケーションがどのように反応するかを解析し、悪用される可能性のあるセ キュリティギャップを探す。

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

一貫性のないフィードバック

これらのツールでは、(侵入テストの場合に)多くの労力が必要になり、(DASTの場合の再実行には)多くのコンピューティングリソースが必要になる。そのため、定期的にしか実行されない。

その一方で、SASTは通常、本番環境に対応したコードの各バージョンに対して実行する。

我々のアプローチは、これらのどれよりも簡単だ。一度Contrastエージェントを組み込めば、アプリケーションが更新されて疎通されるたびにフィードバックが得られる。とはいえ、Contrastで結果を得るためには、アプリケーションを疎通しなければならない。SASTが必ずしも全て差分に対して行われるとは限らないのと同じように、これは常に全ての差分に対して行われるとは限らない。

静的SCA診断の間違い

オープンソースの依存関係を追跡することは、セキュリティ担当にとって優先事項である。そのために、ソフトウエアを検査して、ソフトウエア内のすべてのコンポーネントとライブラリの由来を特定するのが、SCAツールだ。SCAツールによって、企業はアプリケーションのコードベースのソースを追跡し、CVE(共通脆弱性識別子)データベースと比較して脆弱性の有無を確認することができる。

しかし、静的SCAツールにはSASTと同様の制限があり、アプリケーションの依存関係という一面だけをを対象としている。つまり、これらのライブラリがアプリケーションで実際にどのように使用されているのかは判断することができない。

主要なSCAツールの中には、サポート対象の言語のいくつかに対して「到達可能性解析」を行うものがあり、これは役に立つが、到達可能性解析後のSCAの検査結果の大部分は依然として悪用不可の誤報だ。静的SCA ツールの主な問題は、アプリケーションの依存関係マニフェストによって依存関係が指定されているにもかかわらず、実際には使用されていないケースを判別できないことだ。その結果、誤検知が発生し、開発者は実際にコードの作成に時間を費やすことで企業の競争に貢献するのではなく、より多くの無関係なアラートを追いかけて時間を浪費することになる。

また、静的SCAツールでは、環境によって入り込む依存関係が見落とされる。これは、コンテナクラスタにデプロイされるアプリケーションが増えるにつれて、ますます一般的になっている。

その結果…

1. 過検知

従来のAppSecツールは、過検知によってセキュリティ部門を麻痺させてしまう。最近の調査によると、調査対象となったIT意思決定者の59%が、1日あたり500件を超えるクラウドのセキュリティ警告を受信している。

こうした警報が誤報であることがあまりにも多い。調査によると、企業の5分の2以上(43%)の過検知率が40%に達している。

つまり、SASTやDASTなどの不正確な従来のツールは、数十年前に導入されたテクノロジに基づくもので、当時は開発のペースがはるかに遅く、全ての検出結果を検証する時間があった。今日の開発ペースははるかに速く(そして、現在もなお加速している)、セキュリティエンジニアだけのサイロでは、プロセス全体を遅らせることなく、検出結果をひとつひとつ手作業で検証する方法はない。

AppSecの予算を増やそうとしているなら、過検知が多発する不正確な従来のツールにさらに資金を投資するのは意味がない。セキュリティ部門では、どのアラームが本物でどれが偽物であるかを判断できないため、全てのアラームを調査するために貴重な時間を無駄に費やさなければならない。その作業は、10分で終わるものもあれば数時間かかる場合もある。リソースに制約のある企業・組織にとって、不正確なツールから報告される脆弱性をひとつひとつ調査するというのは、現実味のない話だ。

2. 不適切なプロセス

SAST、DAST、およびSCA(ソフトウェアコンポジション解析)は、開発ライフサイクルに割り込ませる個別のセキュリティスキャンフェーズが必要となるため、多くの場合、時間がかかり扱いにくい。このまとまりのないアプローチは、現代の開発部門で採用されているアジャイル手法の妨げとなり、摩擦や遅延を生む。セキュリティを開発プロセスの一部として統合するのではなく、独立したフェーズとして扱うことで、これらのツールは開発部門とセキュリティ部門の間の橋渡しではなく障壁を作り出してしまう。

3. 膨大なバックログ

従来のAppSecツールでは、巨大なAppSecバックログが生成される。そして、バックログには、ほとんどの場合、多くの未対応で未解決の問題が驚くほど多く含まれている。バックログは、セキュリティに関して誤った感覚をもたらす。脆弱性を完全に把握できずに古くなってしまい、深さ、コンテキスト、リアルタイムの応答性の点で不十分である上に、修正に長い時間がかかってしまう。

セキュリティ/AppSec部門が、未処理のセキュリティ問題の山の中に深刻な脅威がないことを祈っているとしたら、不正確なAppSecツールからの報告に息が詰まるような状態であることは間違いない。

より賢くセキュリティに投資するには

機能していないツールにさらにお金をかけるのではなく、ランタイムセキュリティに目を向けてみよう。ランタイムセキュリティは、インストルメンテーションの力により、一般的なソフトウェアスタックに含まれる何千ものメソッドのうち、使用時に危険であり、かつ全く保護されていないものを守ることができる。これは、ランタイムによって、ソフトウェアスタック全体に信頼境界が埋め込まれることで実現する。これらの信頼境界は、メソッドが安全に使用されていない場合に開発者に警告を発する。また、ライブラリが脆弱で悪用可能かどうかを判断し、メソッドの使用を観察することでセキュリティの青写真を明らかにし、攻撃を検出して悪用の試みを防ぐ。

ランタイムはAppSecのあり方を変える。高価で不正確かつ非効率的な手動ツールやプロセス(企業をサイバー攻撃から守れない効果のないツールやプロセス)を、開発から本番環境までの全てのアプリケーションを保護する、自動化された正確で実用的なセキュリティに置き換えることができる。

無駄なことにさらにお金をつぎ込むのはやめよう。ランタイムセキュリティによって、セキュリティ部門が過検知の追跡から解放され、プロセスを改善して、息がつまるほどのバックログから抜け出すための方法を知るには、12月12日(火)午前11時(EST)/午後2時(EST)に開催される、Forrester ResearchとContrast Securityのウェビナーに是非参加してほしい。

ランタイムセキュリティがどのようにAppSecに革命をもたらし、アプリ/APIを内側から強化し、AppSecの予算がゴミ箱のようになった状況から抜け出す道を知ることができる。

Read more:

• Contrast Security Integration with CI/CD Pipelines (solution brief PDF)
• Contrast's MTTR is 37x faster than the competition (blog)
• Let’s talk stats: Why AppSec’s running on broken math (blog)
• False positives + false negatives = real costs (blog)
• The Truth About AppSec False Positives (white paper PDF)
• Learn about the hidden dangers of traditional AppSec tools and why Runtime Security is replacing them (podcast writeup)