脆弱性修正プロセスの 4 つのステップ

常に念頭に置いておくべき重要なことは、脆弱性を管理する最終目標は対策にある、ということです。脆弱性を管理する上で重要となるプログラムの KPI の一つには、クリティカルなシステムやアセットが侵害される前に、リスクの高い脆弱性をどれだけ除去できるか、または無力化できるかというものが含まれます。

脆弱性の対策が重要である理由

顧客、パートナー、従業員、規制当局は、企業に偶発的または悪意のある損失や漏洩から継続的かつ効果的にデータを保護するポリシーやプロセスの導入を期待しています。システムの中断やスローダウンは一切許されません。つまり、脆弱性の対策という問題に取り組むことは、ビジネスの重要な一部分になっています。

このブログでは、スケーラブルで効果的な脆弱性修正プロセスを導入するため、主に優先順位の設定と修正という対策ステップを中心に説明します。

脆弱性修正プロセスの 4 つのステップ

1. 発見: スキャンとテストで脆弱性を検出する

2. 優先順位の設定: どの脆弱性が現実的で重大なリスクとなるかを把握する

3. 修正: パッチ、ブロックなどの方法で、大規模かつリアルタイムに脆弱性を修正する

4. モニタリング: 新たに発見された脆弱性について、プロジェクトとコードを自動的にモニタリングし、すべての関連チャネルを通じてリアルタイムで警告と通知を行う

1.脆弱性を検出する

脆弱性の優先順位の設定と修正について説明を始める前に、脆弱性とは何か、またどのように見つかるかを簡単に復習しておきましょう。

セキュリティ脆弱性とは、アプリケーションに侵入し、アプリケーション、サービス、ライブラリ、コンテナ、機能、および関連するすべてのアセットを悪用して危険にさらす、既知のコーディング上の欠陥やシステムの設定ミスのことをいいます。アクティブ攻撃は、システムのシャットダウンやパフォーマンスの劣化、データの流出、コンピューティングリソースの乗っ取りなどを目的として行われます。また、侵害されたコンポーネントに側面からアクセスできるシステムやアセットも危険にさらされます。

たとえば、よく知られているソフトウェアコーディングの脆弱性には、ユーザー認証手順を完全に実装していないことや、推奨されるベストプラクティスの多要素認証ではなく単一要素認証といった不十分な制御を実装していることが挙げられます。このような脆弱性があると、許可されていないユーザーが十分な権限を持ってしまい、電子的な盗聴とも言うべき中間者攻撃 (MITM) のようなエクスプロイトを仕掛けることができます。セキュリティチームとハッカーは、Log4Shell のような新しい脆弱性を定期的に発見しているため、スキャンを頻繁に実行することが重要です。

したがって、脆弱性修正プロセスの最初のステップは、セキュリティの脆弱性をスキャンして見つけることになります。成熟した脆弱性管理プログラムは、セキュア SDLC (ソフトウェア開発ライフサイクル) 全体を通じて脆弱性スキャンを実行する、シフトレフトの DevSecOps アプローチを導入しています。CI/CD パイプラインの速度を保つため、開発環境、テスト環境、本番環境に導入できる自動脆弱性テストツールがあります。以下のツールが含まれます。

• ソフトウェアコンポジション解析 (SCA) ツール

• オープンソースの脆弱性スキャナー

• ホワイトボックス型の静的アプリケーションセキュリティ (SAST) ツール

• ブラックボックス型の動的アプリケーションセキュリティツール (DAST)

コンテナセキュリティには特別な注意を払う必要があります。コンテナイメージだけでなく、実行中のコンテナインスタンスやリンクも含めて、セキュリティの脆弱性をスキャンすることが重要です。サードパーティのコンテナイメージは信頼できるソースのものだけを使っていることを確認することも重要です。また、Kubernetes セキュリティには、脆弱性のスキャンに独自の問題があります。クラスターで脆弱性に起因するインシデントが発生すると、ネットワーク上のすべてのサービスやマシンが危険にさらされます。

2.脆弱性に優先度を判断する

脆弱性修正プロセスの次のステップは、脆弱性修正の優先順位を設定することです。

私がアプリケーションセキュリティの仕事を任されたばかりの頃は、あまりにも多くのことをやろうとして、多くの時間を費やしてしまっていました。これは、特定の脆弱性の細かい点に時間をかけ過ぎていたことを意味しています。

ブレンダン・ディベル (Brendan Dibbel)、Toast アプリケーションセキュリティエンジニアリングチームリーダー

会社がセキュリティリスク管理に対してどのようなアプローチを取っているかに関わらず、検出されたすべての脆弱性が同じレベルのリスクをもたらすわけではありません。重大性、修正可能性、適用範囲、コンプライアンスなど、さまざまな考慮事項の中で常にトレードオフが発生します。リスクベースでコンテキストを意識した優先順位の設定により、脆弱性修正チームは、限られたリソースを最も重要な問題に集中させることができます。

発見された脆弱性の 80% 以上は誤検知の可能性が高く、18% はリスクが低いもので、本当に修正する必要があるのは残りの 2% と言われています。

クラウドネイティブアプリケーションのセキュリティプラットフォーム、Snyk は、脆弱性の優先順位の設定をさまざまな方法でサポートしています。

• 豊富な脆弱性情報のインサイト: Snyk では、エクスプロイトの成熟度、修正可能性、リスクレベル (一般的な危険度、特にビジネスクリティカルなプロジェクトに対する影響を含む) 、普及率 (影響を受けるプロジェクトやアセットの数)、経過年数などの実行可能な情報に基づいて、優先順位を設定できます。

• リスクベースの正確な優先順位スコアリング: Snyk の脆弱性データベースは、既知と未知の脆弱性を網羅する公開情報や独自のソースからのデータで拡充・分析されており、脆弱性にはそれぞれ周到に計算された優先度スコアが割り当てられています。

• アプリケーションレベルのインサイト: Snyk は、実行およびランタイムの起動データ、Kubernetes の設定情報、および実行中のコンテナからのシグナルを使用して、脆弱性による影響 (または影響のなさ) を判定します。もし、脆弱性のある機能が実際には使われていない場合、緊急に対処すべき必要性は本当にあるのでしょうか。

• セキュリティポリシーのきめ細かい制御: 脆弱性の優先順位は、企業のセキュリティポリシーと関連させて設定する必要があります。セキュリティ対策の実装がよりきめ細かいほど、脆弱性の優先順位の設定を適切に行えます。Snyk では、タグと属性を使用して、プロジェクトごとにセキュリティポリシーを定義できます。

3.脆弱性を修正する

脆弱性修正プロセスの 3 番目のステップは、脆弱性の修正です。

多くの場合、脆弱性のあるソフトウェアを取り除くには、関係するソフトウェアのベンダーが推奨しているアップグレードやパッチの導入が必要です。しかし、パッチの導入はそれ自体が困難な場合もあります。パッチやアップグレードのテストや展開には、かなりの時間とリソースを消費します。ビジネスクリティカルなシステムは、デプロイメントプロセスの最中にシャットダウンしなければならないかもしれません。また、パッチがアプリケーション自体やその依存関係に想定外の影響を及ぼすリスクも常に存在しています。

よりリスクの低い方法で脆弱性を修正したり、導入するパッチの準備ができるまで時間を引き延ばせるかもしれません。たとえば、リスクのあるシステム、プラットフォーム、サービス設定を更新できます。同様に、実際に使用されていない脆弱性のあるプロセスや機能を無効にしたり、脆弱なコンポーネントを削除したりできます。

4.脆弱性をモニタリングする

SDLC の他の部分と同様、セキュリティ脆弱性修正プロセスも継続的に行います。このループを円滑に回すためには、モニタリングが必要です。使用するツールでは、プロジェクトとコードを自動的にモニタリングし、新たに発見された脆弱性について、すべての関係チャネルでリアルタイムに警告、通知できるようにしておく必要があります。

モニタリングツールで状況に応じた優先順位を設定し、脆弱性修正プロセスのステップ 1 と 2 (検出と優先順位の設定) の両方を支援できることが理想的です。そうしないと、開発者やセキュリティ担当者は、大量に発生する優先度の低い脆弱性への対応に追われすぐに疲弊してしまうでしょう。重要なのは、チームがノイズに手こずらないようにすることです。ノイズが多いと迅速な対策が必要な重要度や優先度の高い脆弱性の処理が遅れてしまうことになりかねません。

モニタリングはこのリストのステップ 4 に挙げられていますが、高度に機能しているセキュリティプログラムにおいて、モニタリングはステップ 1 として考えることができます。

脆弱性修正プロセスの 4 つの重要なステップを理解した上で、プロセスを促進し、効率を高めるために、適切なツールを用意することは非常に重要です。

この問題はほぼすべての組織で見られます。ほんの数名のセキュリティエンジニアが、膨大な人数の開発者に対応しているため、すべての変更を追うのは無理です。

そのため、私たちはすべてをやり遂げようとする代わりに、エンジニアがセキュリティに責任を持つために必要なツールの提供に注目したいと考えています。

ブレンダン・ディベル (Brendan Dibbel)、Toast アプリケーションセキュリティエンジニアリングチームリーダー

適切なツールによって開発チームに力を与え、脆弱性を発見して修正しましょう。ここでは、Snyk がお手伝いできることをいくつかご紹介します。

• 即時ロックダウン: Snyk の SCA ツールは、脆弱性の影響が及ぶすべてのインスタンスをスキャンしてすばやく発見し、ハッカーをただちにロックアウトする措置を講じます。

• 操作性の向上: 高度に分散した最近のイベントトリガー型クラウドネイティブアプリケーションでは、開発者による修正が必要とされる脆弱なコードやコンポーネントを見つけるのは容易ではありません。Snyk では、開発者に脆弱性へのアクセス方法を正確に伝えることで、修正を加速できます。

• 脆弱性のないバージョンへの自動または手動でのアップグレード:Snyk は、自動修正プルリクエストによって自動的に、またはチームに手動で行うよう依頼することによって、直接的な依存関係を脆弱性のないバージョンにアップグレードしています。

• 脆弱性パッチの適用: Snyk は、既存のブランチがあるかどうかを自動的にチェックし、正確に修正できるようにするため、既存のプルリクエストを再開します。既存のブランチがない場合は、新しいブランチとプルリクエストが作成されます。

よくある質問

脆弱性スキャンと脆弱性テストとは

脆弱性スキャンとは、既知のコーディング上の欠陥や設定ミスのデータベースと照らし合わせて、アプリケーションやシステムをモニタリングすることです。脆弱性テストは、アプリケーションを調査して脆弱性を評価することです。脆弱性スキャンと脆弱性テストはいずれも自動化プロセスとして、ソフトウェア開発ライフサイクルを通じて CI / CD パイプラインとシームレスに統合する必要があります。

脆弱性の優先順位を安全に設定する方法

Snyk で脆弱性の優先順位を設定する場合は、複数の脆弱性と脅威インテリジェンスデータソースの分析、キュレーションによって得られるリスクスコアに基づいて行うことができます。これらのソースの中には、一般に公開されているものもありますが、独自の調査だけでなく、現場 (開発者、学術機関など) からの情報によって充実させる必要があります。

脆弱性のあるソフトウェアを削除するには

脆弱性のあるソフトウェアは通常、ソフトウェアベンダーが提供するパッチやアップグレードを導入することで削除できます。ただし、システムやアプリケーションの設定を更新したり、脆弱性が指摘された未使用のコンポーネントを削除したり、無効化するなど、他のアクションを通じて脆弱性のあるソフトウェアに対策を施すことも可能です。