統計についての話：AppSecが誤った計算に基づいて行われている理由

例えば、セキュリティ問題への対応/修復の平均時間(MTTR)が60日だとしよう。

もっと悪くなるかもしれないし、良くなるかもしれない。例えば、Veracodeが公表している数値は298日のMTTRだ。 Contrastの指標では、MTTRは8日となっている。しかし、実際のところ、企業が重大な脆弱性を修正するのに平均2か月近くかかっている。

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

一般的に、遅いプロセスは次のような流れになる。

• アプリケーションがセキュリティチームによってスキャンされる：4～7日間
• セキュリティエンジニアによって結果が分析される：14日間
• セキュリティ管理チケットが作成される：7日間
• スプリントサイクルに統合される：30日間
• 最適なシナリオの合計：54 ～ 58日(全員が同期して作業し、高い優先順位を維持できる場合)

誤り：計算されていない

調査が必要なセキュリティ上の問題が10件見つかったとしよう。そして2週間後、10件のうち4件は、無駄骨を折ったことが判明する。なぜなら、実際にはアプリケーションによって呼び出されなかったライブラリに関する問題であったからだ。これらのライブラリは単純に一度も使用されていなかったため、脅威となる可能性はなかった。 …しかし、それらを調査しなければならなかった人達の時間を無駄にしたことは間違いない。

Vectra AIはまた、SOCチームの63%が過去3年間で攻撃対象領域の規模が拡大したと報告していることも明らかにした。手作業によるトリアージでは対応できない。調査したセキュリティエンジニアによると、毎日受信するアラートの67%に対処できず、アラートの83%は過検知であり時間をかける価値がないと報告している。

調査対象となったSOCチームメンバーの3分の2(66%)は、受信するアラート数が増加し、関連コストも増加していると回答している。

先ほどの仮説シナリオに戻ろう。10件のセキュリティ上の問題があるが、そのうちの4件は呼び出されたことのないライブラリに関するものであるため、時間の浪費であった。もし、その4件の無駄な作業に駆り出されていなかったらと想像してみてほしい。重要な6件にもっと早くたどり着けたかもしれない。数週間もかかるのではなく、1週間以内にたどり着けたはずだ。

何が悪いのか？

非難するつもりはないが、これらの懲罰的な数字はどこからか来ているんだろう。実際のところ、市場はSAST(静的アプリケーションセキュリティテスト)とDAST(動的アプリケーションセキュリティテスト)の技術を専門とするベンダーで飽和状態だ(これらのアプローチに関するIDCの詳細なレポートを参照してほしい。または要約はこちら。)

これらのシステムの根本的な問題：

1. すぐに使えるSASTやDASTのスキャンツールは、大量の過検知を含む不正確な結果を発生させる。どれが本当でどれがノイズなのかを検証する余力がないため、セキュリティ担当と開発担当の間で、この結果リストは厄介者のように扱われることがよくある。それに、誰が何百・何千ものチケットをオープンしたいだろうか？
2. スキャンは完了するまでに数時間、場合によっては数日かかることもある。膨大でノイズの多いリストに加えて、長いフィードバックループが組み合わさることで、担当者がウォーターフォールやスプリントサイクルのアプローチを採用せざるを得ず、開発が遅延する原因となる。

この誤った計算を正すには

MTTRの値が小さいということは、少なくとも40%は誤報であるという、この途方もない数のアラートを回避できるため、セキュリティ負荷がはるかに軽くなることを意味する。MTTRを短くすると、対応にかかる時間を短縮できるため、アプリケーションごとのセキュリティ負債を減らすことができる。

残念ながら、ほとんどの企業では、実際にどの脆弱性が問題であるかを自動化で優先順位付けする方法がない。気がつくと、リスク評価の実施やバックログの管理に膨大な時間を費やしてたのだ。これでは、脆弱性を実際に修正する時間がほとんどない。そもそも、開発のなるべく早い段階で脆弱性を見つけることが重要なのに。

見つけた全ての脆弱性を修正する時間(またはスタッフ)が確保できなければ、それらは山積みになり始める。洗う時間がない洗濯物の山や調理するまでに手が回らなかったカビの生えた食料品のようになる。

企業のアプリケーションにおける巨大なバックログ(既知の脆弱性と、脆弱性の可能性が判明してもその真偽を確認するまでに調査に時間を要する問題の両方を含むバックログ)という重い負荷を軽減するには、プロセスを自動化する必要がある。

ランタイムセキュリティはより合理的

このような実行不可能で持続不可能な方程式を減らすための最も強力なアプローチは、インストルメンテーションとランタイム解析によるリアルタイムの解析と対策、つまりランタイムセキュリティを使用することだ。ランタイムセキュリティは、本番環境でのセキュリティだけを意味するものではない。開発、テスト、本番にかかわらず、ソフトウェアが実行されるあらゆる場面でのセキュリティを意味する。

ランタイムにより、開発担当とセキュリティ担当がリアルタイムでデータを分析し、脆弱性を検出することが可能になる。これは、実際に企業がMTTRを短縮するのに役立つ。例えば、Contrastが達成した8日間のように。

その意味するところは、どうしようもないバックログをただ単に処理できるだけではない。リアルタイムによって、生きたセキュリティが反映される青写真という形でオブザーバビリティを利用できる。これには、アプリケーションとAPI(アプリケーションプログラミングインターフェース)の操作を多方面から監視でき、攻撃対象、防御、危険なメソッド、APIエンドポイントへのアウトバウンドコール、システムインタラクション、データベース接続、ファイルシステムのやり取りなどが対象に含まれる。

安心できる数字が知りたいのであれば、小売業者Floor & Decor 社のIDCのビジネス バリューケーススタディをご覧頂きたい。同社は過検知を削減するためにContrast Assess (IAST:インタラクティブアプリケーションセキュリティテスト) を導入し、重大な問題の処理にかかるスタッフの時間を94%削減した。

さらに詳細

ランタイムセキュリティがAppSecにどのような変革をもたらすかについて、Contrast SecurityのCTO兼共同創業者であるJeff Williamsが、フォレスター・リサーチのアナリストのJanet Worthington氏をゲストに迎え、議論する。ランタイムセキュリティがどのように役立つかを知りたい方は、是非チェックして欲しい。

ディスカッションで予定している内容：

• 基本的な統計値と、従来のAppSec対策では不十分な理由。
• 現代の企業にとって「ランタイムセキュリティ」が意味するもの。
• 迫りくる2024年の動向と脅威、企業の心構え。

従来のAppSecが押し付けてきたおかしな方程式から解放されるのだ。その方法を知るために、12月12日の午前11 時(太平洋標準時)のウェブキャストに参加しよう。

Read more: 

• False positives + false negatives = real costs (blog)
• Learn about the hidden dangers of traditional AppSec tools and why Runtime Security is replacing them: (podcast writeup blog)
• Attack-path mapping your applications (blog)
• IDC’s business value case study of Floor & Decor (case study)