ソフトウェアの脆弱性：種類、リスク、対処方法

インフォマテックデジタル » Recursos » ソフトウェアの脆弱性：種類、リスク、対処方法

ソフトウェアの脆弱性は、現代のほとんどのデジタルシステムにおける弱点です。コードの小さな欠陥、設定ミス、あるいはパッチ未適用といった些細なことが、データ漏洩、ランサムウェア攻撃、深刻なサービス停止につながる可能性があります。多くの組織は既にウイルス対策ソフト、ファイアウォール、その他の防御策を導入していますが、ソフトウェアに脆弱性があれば、それまでの努力もわずか数分で無駄になってしまう恐れがあります。

人間が設計したものはすべて故障する可能性があり、ソフトウェアも例外ではありません。WebアプリケーションやAPIからオペレーティングシステム、ファームウェア、カーネルドライバに至るまで、これらのコンポーネントすべてに悪用可能な脆弱性が存在する可能性があります。脆弱性とは何か、どのような種類が存在するのか、どのように検出するのか、そして何よりも、どのように迅速に修正・管理するのかを理解することが、数百万ドルの損失、規制上の罰則、あるいは評判の失墜につながる可能性のある重大な問題を回避するための鍵となります。

ソフトウェアの脆弱性とは何ですか? また、なぜそれほど重要なのですか?

コンピュータ科学の分野において、脆弱性とは、システム、アプリケーション、デバイス、またはプロセスにおける弱点のことで、攻撃者がこれを悪用して、情報やサービスに損害を与えたり、改ざんしたり、許可なくアクセスしたりできるものです。この弱点は、コード（プログラミングエラー）、ハードウェア、構成、内部手順、あるいは人間の行動にも存在する可能性があります。

脆弱性そのものは、まだ攻撃ではありません。それは潜在的なリスクです。問題は、誰かがそれを悪用したときに発生します。悪用されるのは、意図的な場合（サイバー犯罪者がエクスプロイトを実行する場合）でも、偶発的な場合（ユーザーが予期しないデータを入力することでクラッシュを引き起こす場合）でも同様です。単純なバッファオーバーフローでも、サービス拒否攻撃から任意のコードの実行まで、あらゆる事態を引き起こす可能性があります。

脆弱性が悪用された場合の影響は甚大です。個人情報や金融データの盗難・漏洩、マルウェアの拡散、ランサムウェアによるデータ暗号化、重要サービスの停止、さらには高レベルのインフラストラクチャの侵害などが起こり得ます。例えば、Webアプリケーションの場合、SQLインジェクションやXSS攻撃が企業ネットワーク全体への侵入経路となる可能性があります。

脆弱性を早期に発見して修正することは、インシデント発生後に対応するよりもはるかにコスト効率が良い。ソフトウェア開発ライフサイクル（SDLC）にセキュリティを組み込み、DevSecOps型のアプローチを採用することで、「セキュリティを左に移動」させることが可能になる。つまり、設計やコーディングの初期段階で欠陥を発見し、既に運用環境に導入されているシステムにパッチを適用するよりも、その段階で修正する方がコストを抑えられる。

脆弱性は様々な形で現れる可能性があります。例えば、不要なポートでリッスンしているサービス、オープンなWi-Fiネットワーク、露出したファイアウォールポート、存在しないパスワードポリシー、物理的なアクセス制御のない施設などが挙げられます。これらの状況は、一見すると純粋に「ソフトウェア関連」ではないように見えますが、攻撃者が目的を達成するために悪用できる脆弱性の集合体の一部です。

ソフトウェアの脆弱性の主な種類

ソフトウェアの脆弱性は、古典的なメモリエラーから認証における論理的な欠陥、アーキテクチャ設計の不備まで、多岐にわたるカテゴリに及びます。以下に、今日最も一般的で関連性の高い脆弱性の種類をいくつか示します。これらの多くは、OWASP Top 10などのリストに直接反映されています。

ゼロデイ脆弱性

ゼロデイ脆弱性とは、メーカーが認識していない欠陥であり、パッチが提供される前に攻撃者によって既に悪用されているものです。Log4jの脆弱性のような事例は、こうした状況がいかに危険であるかを如実に示しました。ベンダーが修正プログラムの準備に奔走する間、数百万ものシステムが脆弱性にさらされたのです。

ゼロデイ脆弱性では、攻撃者は有効なエクスプロイトを持っている一方で、防御側は対策が不十分なため、一時的に優位に立つことができます。このような状況では、公式パッチがリリースされるまでの間、影響を軽減するために、行動ベースの検出、トラフィックフィルタリング、ネットワークセグメンテーション、最小権限ポリシーが不可欠です。

リモートコード実行（RCE）

リモートコード実行の脆弱性とは、攻撃者が物理的なアクセスなしに標的システム上で悪意のある命令を実行できる脆弱性です。これは最も重大な脆弱性の一つであり、一度悪用されると、マルウェアのインストール、機密データへのアクセス、バックドアの作成、あるいは他の内部システムへの侵入などに悪用される可能性があります。

リモートコード実行（RCE）は通常、メモリオーバーフロー、インジェクション、データ逆シリアル化の問題など、他の根本的な脆弱性に依存しています。攻撃が成功すると、特に脆弱なアプリケーションが管理者権限で実行されている場合は、影響を受けるシステムが完全に侵害されることになります。

データ検証とサニタイズの問題

膨大な数の攻撃は、検証が不十分な入力データに起因しています。アプリケーションが受信したデータ（フォーム、URLパラメータ、ヘッダー、JSONなど）をチェックまたはクリーンアップしない場合、攻撃者は予期しないコードや命令として解釈される悪意のあるコンテンツを紛れ込ませることができます。

このカテゴリには、SQLインジェクション、クロスサイトスクリプティング（XSS）、文字列フォーマットエラー、特定のバッファオーバーフローなど、よく知られた脆弱性がいくつか含まれています。これらのリスクを最小限に抑えるには、すべてのフィールドの型、範囲、フォーマット、長さを検証し、ホワイトリストを使用し、クエリを安全に準備することが不可欠であり、優れたセキュア開発プラクティスの一部です。

SQLインジェクションおよびその他の種類のインジェクション

SQLインジェクション（SQLi）は、データベースと連携するWebアプリケーションに対する最も一般的な攻撃手法の一つです。これは、改ざんされたSQL文を保護されていない入力フィールド（ログインフォーム、検索、フィルタなど）に挿入することで、開発者が意図していないクエリをアプリケーションに実行させるものです。

この種の脆弱性により、攻撃者はテーブル全体（パスワードやクレジットカード情報を含む）を読み取ったり、レコードを変更または削除したり、認証情報を変更したり、データベース全体を使用不能にしたりすることが可能になります。SQLフォームとクエリは広く普及しているため、コードが適切に保護されていない場合、ほぼすべてのSQLエンジン（MySQL、PostgreSQL、SQL Server、Oracle、さらには同様のクエリをサポートする一部のMongoDBのような実装）が影響を受ける可能性があります。

SQLインジェクションは、SQLインジェクションだけにとどまりません。オペレーティングシステムコマンドインジェクション、LDAPインジェクション、テンプレートインジェクション、ヘッダーインジェクション、安全でない逆シリアル化なども存在します。これら全てに共通する問題は、適切な制御と分離が実装されていないために、ソフトウェアがデータを命令として解釈してしまうことです。

クロスサイトスクリプティング（XSS）とクロスサイトリクエストフォージェリ（CSRF）

クロスサイトスクリプティング（CSSS）は、攻撃者が他のユーザーが通常アクセスする正規のウェブページにスクリプトを挿入することを可能にする攻撃手法です。アプリケーションが表示コンテンツを適切にフィルタリングしない場合、悪意のあるスクリプトはセッションを盗み、認証情報を窃取し、被害者のブラウザからウェブサイトの動作を変更する可能性があります。

一方、クロスサイトリクエストフォージェリ（CSRF）は、ブラウザがセッションクッキーを自動的に送信する仕組みを悪用し、認証済みのユーザーのブラウザをだまして、信頼できるアプリケーション上で意図しない操作（パスワードの変更や送金など）を実行させる攻撃です。この攻撃に対する防御策としては、CSRF対策トークン、適切なヘッダー、および追加の検証手段が用いられます。

バッファオーバーフローとフォーマットエラー

バッファオーバーフローは、C言語およびC++言語における典型的なセキュリティ問題です。これは、プログラムが予約済みのメモリ領域（バッファ）に収まる以上のデータを書き込むことで、隣接する領域を上書きし、変数、戻りアドレス、または内部システム構造を変更する可能性がある場合に発生します。

このような制御不能な動作は、クラッシュ、フリーズ、最悪の場合は任意のコード実行につながる可能性があります。同様に、文字列の書式設定エラー（例えば、ユーザーが制御するパラメータを持つprint関数の不適切な使用）は、注意深くプログラミングされていないと、メモリ操作や機密情報の漏洩を引き起こす可能性があります。

欠陥のあるアクセス制御と安全でない設計

アクセス制御の不具合とは、アプリケーションが各ユーザーの権限を適切に検証できず、制限されるべき操作やアクセスを許可してしまう場合に発生します。これには、認証されたユーザーなら誰でも閲覧できる管理機能から、ロールベースの制御を適用しないAPIまで、あらゆるものが含まれます。

一方、セキュリティ設計の不備は、単なるコーディングエラーではなく、より根深いアーキテクチャ上の欠陥を反映しています。これは、階層構造を考慮していない、ログ記録やトレーサビリティのメカニズムを含めていない、あるいは機密データの保護を最初から計画していないなど、構造上の問題のある決定事項です。これらの問題を修正するには、通常、システムの基盤に大幅な変更が必要となります。

暗号の失敗と暗号化の欠如

暗号技術の欠陥は、時代遅れのアルゴリズム（例えば、脆弱な暗号や安全性の低いハッシュ関数）の使用から、プロトコルの不適切な実装、鍵の不適切な再利用まで多岐にわたる。これらの欠陥はすべて、暗号技術が理論的に提供する保護機能を実際には無効にしてしまう。

暗号化が行われていないこと自体も脆弱性となります。データベース、ファイル、バックアップなどにデータを平文で保存したり、クライアントとサーバー間の通信を暗号化しなかったりすると、攻撃者が環境にアクセスしたり、ネットワークトラフィックを傍受したりすることが容易になります。

脆弱で構成が不十分なAPI

APIは、重要なデータや機能への目に見えない入り口であるため、サイバーセキュリティリスク管理において最優先事項となっています。多くの組織は、目に見えるWebインターフェースのセキュリティは確保していますが、内部API、モバイルAPI、サードパーティAPIの保護は不十分なままです。

典型的なAPIの脆弱性としては、認証の弱さ、認可の不備、過剰なデータ漏洩、詳細すぎるエラーメッセージ、リクエストレート制限の欠如などが挙げられます。これらの脆弱性すべてが、APIを大規模攻撃を自動化するための格好の攻撃経路にしてしまいます。

古くてパッチが適用されていないソフトウェアによる脆弱性

パッチが適用されていないソフトウェアは、おそらくあらゆる組織において最も一般的な弱点と言えるでしょう。ベンダーがセキュリティアップデートをリリースしても適用されない場合、その仕組みが既に周知の事実となっている鍵のかかった扉を開け放ったままにしておくことになります。その仕組みは、CVE（共通脆弱性識別子）リストのようなデータベースに文書化されている場合も少なくありません。だからこそ、積極的なソフトウェア保守が不可欠なのです。

これらの未修正の脆弱性は、オペレーティングシステム、ビジネスアプリケーション、ブラウザ、プラグイン、ネットワーク機器のファームウェア、ハードウェアドライバなど、あらゆる種類のコンポーネントに影響を与えます。パッチが適用されない期間が長くなるほど、悪用可能なエクスプロイトが出現し、広く悪用される可能性が高くなります。

サイバー犯罪者は、古いシステムを積極的に探し出す。なぜなら、それらは労力の少ない標的だからだ。IPアドレスの範囲や公開されているサービスをスキャンするだけで、脆弱性が知られているバージョンを特定し、複雑なエンジニアリングを必要とせずに自動攻撃を開始できる。

多くの脆弱性が修正されない理由

「常にパッチを適用する」ことの明らかな利点にもかかわらず、組織はいくつかの実際的な障害に直面します。アップデートの量、システム間の依存関係、時間や人員の不足、そしてますます分散化する環境などです。

最も一般的な要因としては、物流上の問題（更新すべきアプリケーションが数千種類もある）、リソースの制約（ITチームの過負荷、予算不足）、高度に相互接続されたシステムの複雑さ（パッチによって互換性が損なわれる可能性がある）、そして最近では、リモートデバイスや企業ネットワーク外のデバイスでパッチを管理することの難しさなどが挙げられます。

レガシーシステムは特にデリケートな問題です。多くの旧型システムはメーカーのサポートが終了し、公式パッチが入手できなくなります。しかし、それらは重要なプロセスにとって依然として不可欠であるため、廃止は容易ではありません。このような場合、ネットワークから隔離したり、制御された仮想化を導入したりといった対策を検討する必要があります。

パッチ未適用のソフトウェアのリスク

セキュリティパッチを適用しないことによる影響は広範囲に及ぶ。第一に、サイバー攻撃に対する脆弱性が飛躍的に高まる。第二に、規制違反につながる可能性がある。そして最後に、経済的および評判上の悪影響が何年も続く可能性がある。

サイバーセキュリティの観点から見ると、パッチが適用されていないソフトウェアは、データ漏洩、様々なマルウェア感染、大規模なランサムウェア攻撃の温床として悪用される。WannaCry攻撃のような著名な事例では、パッチが適用されていないWindowsシステムの既知の脆弱性が悪用され、世界中で数十万台のコンピューターに影響を及ぼした。

規制対象分野（金融、医療、決済サービスなど）では、旧式のシステムを使い続けると、GDPR、HIPAA、PCI DSSといった、データ保護のための適切な措置の実施を義務付ける規制に違反する可能性があります。罰金は年間収益の相当な割合に達する可能性があり、さらに情報漏洩が公になった場合の評判への悪影響も無視できません。

パッチ未適用による脆弱性インシデントによる直接的な経済的損害には、インシデント対応、フォレンジック分析、バックアップからの復元、法的助言、顧客への通知、および潜在的な賠償が含まれます。これに加えて、システム停止による損失、顧客離れ、およびその後のセキュリティ対策強化にかかる費用も発生します。

その他の脆弱性領域：ハードウェアと人的要因

セキュリティはアプリケーションソフトウェアだけで完結するものではありません。それらのアプリケーションが動作するハードウェアと、それらを使用する人々も、攻撃対象領域の重要な構成要素です。本格的なサイバーセキュリティ計画では、これらの要素を無視することはできません。

ハードウェアの脆弱性

ハードウェア分野では、多くの弱点は製造上の欠陥やその後の管理不備に起因している。初期パスワードが設定されたまま出荷される機器、旧式のルーターやカメラ、偽造品、既知の脆弱性を持つファームウェアなどがその典型的な例である。

一般的なハードウェアリスクとしては、変更されないデフォルトパスワード、不正な物理的アクセスに対する対策の欠如、古いファームウェア、公式サポートのないデバイス、フォールトインジェクション攻撃、または悪意のある改変が加えられた偽造ハードウェアの使用などが挙げられます。

さらに、多くのインフラ構成要素は耐用年数が長く、陳腐化する一方で、新たな脅威が出現します。更新、分割、強化計画がなければ、それらは保護が非常に困難な脆弱な部分となってしまいます。

人事関連の脆弱性

人的要因は依然として最大の危険因子の一つです。脆弱なパスワードや使い回しのパスワードを使用したり、フィッシングメールに騙されたり、許可されていないデバイスを接続したり、認証情報を共有したり、セキュリティ手順を無視したりする従業員は、悪意がない場合でも、最高の技術的防御策さえも無効にしてしまう可能性があります。

人事関連の脆弱性として最も一般的なものには、セキュリティ対策が施されていないネットワークへのアクセス、フィッシング詐欺への認識不足、予測可能なパスワードの使用、許可されていないソフトウェアのインストール、企業方針の不遵守、または不満を抱えた従業員による内部脅威などが挙げられる。

これらのリスクを軽減するには、文書化された方針だけでは不十分です。継続的な研修と意識向上、シミュレーション（例えば、管理された内部フィッシングキャンペーンなど）、コンプライアンスの監視、そしてインシデントや不審な行動を報告することが当たり前となる文化の醸成が必要です。

CVEと高度な脆弱性：Linuxカーネルの事例

脆弱性の中には、オペレーティングシステムのカーネルや仮想化モジュールなど、システムの非常に低レベルな層に影響を与えるものがあります。その一例として、CVE-2026-23005として文書化された脆弱性が挙げられます。これは、KVM仮想化を使用するx86環境におけるFPUの状態管理とXSAVE/XRSTOR命令に関連するものです。

この特定のケースでは、ゲスト仮想マシンの XSAVE ステート内の XFD レジストリと XSTATE_BV フィールドの処理に問題が発生します。特定の FPU 機能 (AMX などの高度な拡張機能) が XFD によって無効化されているにもかかわらず、XSTATE_BV で「使用中」とマークされたままになっている場合、カーネルは矛盾した状態を復元しようとして #NM 例外を発生させ、システムパニックを引き起こす可能性があります。

トリガーとしては、例えば、ゲストマシンによるMSR IA32_XFDへの書き込みと、VMのFPU状態がまだ適切に同期されていないまさにその瞬間の割り込みまたはコンテキストスイッチの組み合わせなどが考えられます。また、ユーザー空間がKVM_SET_XSAVEなどのインターフェースを介して矛盾したXSAVE状態を導入した場合にも発生する可能性があります。

カーネルの解決策は、ゲストマシンのXSAVE状態が更新されるたびに、XFDによって無効化された機能のXSTATE_BVをクリアすることです。これにより、XRSTORがXFDによって非アクティブとみなされたコンポーネントの情報を復元しようとしないことが保証されます。この修正により、Intelの仕様との整合性が維持され、利用不可デバイス例外の発生を防ぐことができます。

この例は、アプリケーション層しか見ていない人にとって、脆弱性が必ずしも明らかではないことを示しています。脆弱性は多くの場合、ハードウェア、カーネル、仮想化の間の相互作用に潜んでおり、特定と修正には高度な専門知識が必要です。したがって、オペレーティングシステムのセキュリティ勧告を綿密に監視し、低レベルのアップデートをこまめに適用することが重要です。

脆弱性を検出するための方法とツール

脆弱性を体系的に検出するには、手動と自動化された方法を組み合わせる必要があります。単一のアプローチでは不十分であり、コードレビュー、侵入テスト、システムスキャン、悪意のあるユーザーを模擬したテストはすべて相互補完的な要素です。

ソースコードレビュー

コードレビューは、ソフトウェアが本番環境にリリースされる前に脆弱性を検出するための最も効果的な対策の一つです。これは、開発者同士による手動レビュー、リスクパターンを自動的に検出する静的解析ツールによる支援など、様々な方法で行うことができます。

手動レビューにおいては、担当者は使用される用語、セキュリティのベストプラクティス（エラー制御、入力検証、メモリ管理、認証、暗号化）を十分に理解し、明確なチェックリストを用意しておく必要があります。「正常系」のみをレビューするだけでは不十分であり、エッジケースや競合状態も特定しなければなりません。

静的解析ツールとSASTは、大規模なコードベースをスキャンして、インジェクション、XSS、バッファオーバーフロー、危険な関数の使用など、典型的な脆弱性に関連する既知のパターンを検出することで、このプロセスを補完します。誤検出が発生することもありますが、特定の繰り返し発生する問題を見落とすことを防ぐのに役立ちます。

侵入テストと脆弱性スキャン

侵入テストは、攻撃者が行うように脆弱性を連鎖させることで、アプリケーション、インフラストラクチャ、APIに対する実際の攻撃をシミュレートし、侵入経路を特定します。これらのテストは、ブラックボックス（事前情報なし）、グレーボックス（ある程度のコンテキストあり）、またはホワイトボックス（コードとアーキテクチャへのアクセスあり）のいずれかで行われます。

同時に、脆弱性スキャナーはポート、サービス、アプリケーションをスキャンし、既知の脆弱性のあるバージョンや問題のある構成を探します。これらは、組織内に存在するリスクの最新マップを維持し、修復の優先順位付けを行うための理想的なツールです。

専用ツール: OWASP ZAP、Nikto、Acunetix

OWASP ZAPは、Webアプリケーションの分析に広く利用されているオープンソースツールです。トラフィックの傍受、探索攻撃の自動化、SQLインジェクションテスト、XSS攻撃、認証チェックなどを実行でき、検出された脆弱性とその影響を詳細に記したレポートを生成します。

Niktoは、Webサーバーの分析に特化しており、脆弱な設定、古いバージョン、機密性の高いディレクトリやファイル、設定ミスのあるヘッダーなどをチェックします。Web環境における基本的でありながら危険な問題を迅速に特定するためのスキャナーとして特に役立ちます。

Acunetixは、Webアプリケーションやモバイルアプリケーションの高度な自動スキャンと、コードインジェクション、認証・認可の失敗、XSS、CSRFなど、さまざまなカテゴリを対象としたテストを組み合わせた、より包括的な商用ソリューションです。レポートには通常、各検出結果に対処するための具体的な推奨事項が含まれています。

セキュリティを重視したユーザーテスト

技術的なテストに加えて、セキュリティを重視したユーザーテストを実施することが不可欠です。これは単にアプリケーションが「正常に動作する」ことを確認するだけでなく、悪意のあるユーザー、誤った入力、あるいは予期せぬワークフローに直面した際に、アプリケーションがどのように動作するかをチェックすることを意味します。

例えば、データインジェクションテストでは、特別に細工されたデータ（特殊文字、長い文字列、疑わしい構造など）を挿入し、アプリケーションがそれをどのように処理するかをテストします。ソフトウェアのフィルタリングが不十分であることが判明した場合、SQLインジェクション、XSS、その他の攻撃を受ける可能性が生じます。

認証テストでは、ログインプロセス、セッション管理、パスワード回復メカニズム、およびロールベースのアクセス制御の堅牢性を検証します。ログインプロセスを迂回したり、権限を昇格させたり、セッションを再利用したり、トークンを操作したりする試みを行い、認証システム全体の強度を評価します。

脆弱性の防止と管理に関するベストプラクティス

効果的な脆弱性対策戦略は、予防、早期発見、迅速な対応を組み合わせたものです。脆弱性を100%防ぐことは不可能ですが、脆弱性の数、深刻度、そして悪用可能な期間を減らすことは可能です。

パッチの保守と管理

システムとアプリケーションを最新の状態に保つことは、ソフトウェア保守の基本であり、その一部です。これには、セキュリティパッチを可能な限り速やかに適用すること、定期的なメンテナンス期間を設定すること、本番環境前の環境でアップデートをテストすること、そして可能な限りデプロイメントを自動化することが含まれます。

自動化されたパッチ管理ソリューションは、オペレーティングシステムやサードパーティ製ソフトウェアのアップデートを効率化し、重要度に基づいて優先順位を付け、手動による介入を削減するのに大いに役立ちます。これらのツールをエンドポイントセキュリティ（ウイルス対策、EDR、ファイアウォール）と統合することで、保護状況を一元的に把握できます。

リスクに基づいた優先順位付けが重要です。すべてのパッチが同じ緊急度を持つわけではありません。CVSSなどの指標を使用し、脅威インテリジェンス（どの脆弱性が実際に悪用されているかを把握する）を組み合わせ、各システムがビジネスにおいて果たす役割を考慮することで、最初に修正すべきものを判断できます。

スタッフのトレーニングと安全文化

技術をもってしても、意識の欠如を補うことはできません。フィッシング、パスワードの使用方法、デバイスの保護、機密情報の取り扱い、インシデント報告について、全従業員を定期的に研修することで、攻撃対象領域を明らかに縮小できます。

さらに、セキュリティはIT部門だけの責任ではなく、全員の責任であるという文化を醸成することが重要です。これには、開発者、運用担当者、人事担当者、財務担当者、そして経営陣が含まれます。セキュリティは後回しにされるものではなく、日々の業務や意思決定に組み込まれるべきです。

ポリシー、監査、インシデント対応

明確なセキュリティポリシーを策定することで、ソフトウェアの使用、リモートアクセス、パスワード管理、データストレージ、個人所有デバイス（BYOD）など、許可されるものと許可されないものの境界線を定めることができます。しかし、これらのポリシーは遵守を確保するために定期的に見直し、監査する必要があります。

定期的なセキュリティ監査を実施することで、逸脱の検出、旧式のシステム、不適切なプロセス、これまで見過ごされてきた脆弱性の特定が可能になります。これらの監査結果に基づき、是正措置計画が策定され、優先順位が再評価されます。

明確なインシデント対応計画を策定しておくことは、万が一問題が発生した場合の影響を最小限に抑えるために不可欠です。この計画には、検出、封じ込め、根絶、復旧、および情報伝達の手順に加え、関係する各チームの明確な責任分担を含める必要があります。

脅威が絶えず進化する環境において、安全を確保するための唯一現実的な方法は、脆弱性は常に存在すると想定しつつ、その数を減らし、早期に発見し、悪用される時間を最小限に抑えることです。そのためには、優れた設計、安全な開発、規律あるパッチ管理、専用ツール、保護されたハードウェア、そして何よりも組織のセキュリティにおける自身の役割を認識している訓練された人材を組み合わせる必要があります。