セキュリティホール(英: security hole)とは、情報セキュリティを脅かすようなコンピュータの欠陥をいう。脆弱性ともいう。

## 概要

セキュリティホールが発生する原因は、プログラムや設定の間違い、設計上の考慮不足、保守のために意図的に作られた機能に関する機密の漏洩などである。ソフトウェアの欠陥に限らず、ハードウェアの欠陥や、災害に対する弱さ、悪意のある者がパスワードを管理者から聞き出すような攻撃(ソーシャルエンジニアリング)といった様々な欠陥も、セキュリティホールに含めることがある。

セキュリティホールが残されていることにより、設計、運用時に想定していない操作(ある操作について権限のないユーザが権限を超えた操作を実行するなど)ができてしまったり、非公開のはずの情報が誰にでも取得できてしまうといった、情報セキュリティ上のリスクが増大する。

セキュリティホールは古くから存在したが、コンピュータネットワークの発展により、多くのコンピュータがネットワークを介した攻撃の脅威に晒されており、以前よりも脅威度が高まっている。

反対語はレジリエンス(resilience)であり、日本語訳として強靭化が用いられることもある。

## 定義

ISO 27005は脆弱性を次のように定義している:

IETF [RFC 4949]で定義された脆弱性:

アメリカ合衆国の国家安全保障システム委員会が、2010年4月26日付のCNSS命令No. 4009に国家情報保証用語集で定義した脆弱性:

多くのNISTの出版物は、さまざまな出版物でITコンテキストの脆弱性を定義している。FISMApediaの「Term:Vulnerability」にリストが示されている。そのリストに含まれる「NIST SP 800-30」はより広い定義を与える:

ENISAは、脆弱性を次のように定義している:

Open Groupは、脆弱性を次のように定義している:

情報リスクの要因分析(FAIR)は、 脆弱性を次のように定義している:

FAIRによると、脆弱性はコントロールの強さ、つまり力の標準的な測定値と比較したコントロールの強さ、および脅威の能力、つまり脅威エージェントがアセットに対して適用できる可能性のある力のレベルに関連している。

ISACAはRisk Itフレームワークの脆弱性を次のように定義している:

「データとコンピュータのセキュリティ:標準の概念と用語の辞書」は、脆弱性を次のように定義している:

Matt BishopとDave Baileyは、コンピュータの脆弱性を次のように定義している:

National Information Assurance Training and Education Centerは次のように脆弱性を定義している:

## 脆弱性に関連した騒ぎ

2001年秋、IIS の欠陥をついたワーム "CodeRed"、"Nimda"に多くのコンピュータが感染した。

2003年1月には Microsoft SQL Server の欠陥を利用した "Slammer" 、8月には Windows 2000/XP の欠陥を利用した "MSBlaster" というワームが猛威を振るった。

その後も、Microsoft Windows や IIS など、主としてマイクロソフト製ソフトウェアのセキュリティホールを利用して感染する、ワームやウイルスが出現した。

## 脆弱性とリスク要因モデル

リソース(物理的または論理的)には、脅威アクションで脅威エージェントが悪用できる1つ以上の脆弱性が存在する可能性がある。その結果、組織および/または関与する他の関係者(顧客、サプライヤー)に属するリソース(脆弱なリソースとは限らない)の機密性、完全性、可用性が損なわれる可能性がある。いわゆるCIAトライアドは、情報セキュリティの基盤である。

攻撃は、システムリソースを変更したり、操作に影響を与えたりして完全性や可用性を損なうときにアクティブになる可能性がある。「 パッシブアタック 」は、システムから情報を学習または利用しようとするが、システムリソースには影響せず、機密性が損なわれる。

OWASP(図を参照)は、同じ現象をわずかに異なる用語で示している。攻撃ベクトルを介した脅威エージェントは、システムの弱点(脆弱性)と関連するセキュリティコントロールを悪用し、ビジネスへの影響。

全体像は、リスクシナリオのリスク要因を表す。

## 情報セキュリティ管理システム

情報セキュリティ管理に関連する一連のポリシーである情報セキュリティ管理システム(information security management system, ISMS)は、 リスク管理の原則に従って、所定のポリシーに適用される規則や規制に従ってセキュリティ戦略が確立されていることを確認するための対策を管理するために開発された。これらの対策はセキュリティコントロールとも呼ばれるが、情報の送信に適用される場合はセキュリティサービスと呼ばれる。

## 分類

脆弱性は、関連する資産クラスに従って分類される:

- ハードウェア
  - 湿度に対する感受性
  - ほこりに対する感受性
  - 汚れに対する感受性
  - 保護されていないストレージに対する脆弱性
- ソフトウェア
  - テストが不十分
  - 監査証跡の欠如
  - 設計上の欠陥
- 通信網
  - 保護されていない通信回線
  - 安全でないネットワークアーキテクチャ
- 人事
  - 不十分な採用プロセス
  - 不十分なセキュリティ意識
- 物理的な設置場所
  - 洪水地域
  - 信頼できない電源
- 組織
  - 定期的な監査の欠如
  - 継続計画の欠如
  - セキュリティの欠如

## 原因

- 複雑さ:大規模で複雑なシステムは、欠陥や意図しないアクセスポイントの可能性を高める。
- 熟知度:よく知られている一般的なコード、ソフトウェア、オペレーティングシステム、ハードウェアを使用すると、攻撃者がその欠陥を悪用するための知識やツールを見つけたり、見つけたりできる可能性が高くなる。
- 接続性:より多くの物理的な接続、特権、ポート、プロトコル、サービス、およびそれらのそれぞれにアクセスできる時間が脆弱性を増加させる。
- パスワード管理の欠陥:コンピューターユーザーがブルートフォースアタックによって発見される可能性のある脆弱なパスワードを使用している。 コンピューターユーザーは、プログラムがアクセスできるコンピューターにパスワードを保存する。ユーザーは多くのプログラムとWebサイト間でパスワードを再利用する。

- オペレーティングシステムの基本的な設計上の欠陥:オペレーティングシステムの設計者は、ユーザー/プログラム管理に次善のポリシーを適用することを選択する。 たとえば、 デフォルトの許可などのポリシーを持つオペレーティングシステムは、すべてのプログラムとすべてのユーザーにコンピュータ全体へのフルアクセスを許可する。 このオペレーティングシステムの欠陥により、ウイルスやマルウェアが管理者に代わってコマンドを実行できるようになる。
- インターネットWebサイトの閲覧:一部のインターネットWebサイトには、コンピュータシステムに自動的にインストールされる有害なスパイウェアまたはアドウェアが含まれている場合がある。これらのWebサイトにアクセスすると、コンピューターシステムが感染し、個人情報が収集されて第三者に渡される。
- ソフトウェアのバグ:プログラマは、ソフトウェアプログラムに悪用可能なバグを残す。ソフトウェアのバグにより、攻撃者がアプリケーションを悪用する可能性がある。
- 未チェックのユーザー入力:プログラムは、すべてのユーザー入力が安全であると想定する。ユーザー入力をチェックしないプログラムは、コマンドまたはSQLステートメント( バッファオーバーラン、SQLインジェクション、またはその他の検証されていない入力と呼ばれる)の意図しない直接実行を許可する可能性がある。
- 過去の過ちから学ばない: たとえば、IPv4プロトコルソフトウェアで発見されたほとんどの脆弱性は、新しいIPv6実装で発見された。

調査によると、ほとんどの情報システムで最も脆弱なポイントは、人間のユーザー、オペレーター、デザイナー、またはその他の人間である。したがって、人間は、資産、脅威、情報リソースとしてのさまざまな役割を考慮する必要がある。近年ではソーシャルエンジニアリングと呼ばれるセキュリティに関する懸念が高まっている。

## 脆弱性の影響

セキュリティ違反の影響は非常に大きくなる可能性がある。ITマネージャーまたは上級管理職は、ITシステムとアプリケーションに脆弱性があり、 ITリスクを管理するためのアクションを実行しないことを(簡単に)知ることができるという事実は、ほとんどの法律では不正行為と見なされている。プライバシー法により、管理者はそのセキュリティリスクの影響または可能性を低減するように行動する必要がある。 情報技術セキュリティ監査は、他の独立した人々がIT環境が適切に管理されていることを証明し、責任を軽減するための方法であり、少なくとも誠意を示している。侵入テストは、組織が採用する弱点と対策の検証形式である。ホワイトハッカーは、組織の情報技術資産を攻撃して、ITセキュリティの侵害がいかに容易か、または困難かを調べる。 ITリスクを専門的に管理する適切な方法は、 ISO / IEC 27002やRisk ITなどの情報セキュリティ管理システムを採用し、上層部が定めたセキュリティ戦略に従ってそれらに準拠することである。

情報セキュリティの重要な概念の一つが原則である深層防護すなわちできる多層防衛システムをセットアップするには:

- 悪用を防ぐ
- 攻撃を検出して阻止する
- 脅威エージェントを見つけて起訴する

侵入検知システムは、攻撃の検知に使用されるシステムのクラスの一例である。

物理的セキュリティは、情報資産を物理的に保護するための一連の対策である。誰かが情報資産に物理的にアクセスできる場合、正当なユーザーがリソースを利用できないようにするのは非常に簡単である。

優れたセキュリティレベルを満たすために、コンピュータ、オペレーティングシステム、およびアプリケーションが満たす必要のある基準のセットがいくつか開発されている。ITSECと共通基準は2つの例である。

## 脆弱性の開示

脆弱性の調整された開示(「責任ある開示」とも呼ばれるが、偏った言葉であるとも考える者もいる)は大きな議論の的となっている。例えば、2010年8月にTech Heraldは「 Google、Microsoft、TippingPoint (英語版) 、およびRapid7は最近、今後の開示にどう対処するかを説明するガイドラインと声明を発表した。」と報告した。

責任ある開示では、最初に影響を受けるベンダーに内密に警告し、その後2週間後にCERTに警告する。これにより、セキュリティアドバイザリを公開する前に、45日間の猶予期間がベンダーに与えられる。

他の方法として、脆弱性の全ての詳細を公開するという、フルディスクロージャが行われることもある。これは、ソフトウェアまたは手順の作成者に修正を早急に見つけるよう圧力をかけるために行われることもある。

尊敬されている著者は、脆弱性とそれらを悪用する方法についての本を出版している:「ハッキング:悪用の芸術 第2版」は良い例である。

サイバー戦争またはサイバー犯罪業界のニーズに応えるセキュリティ研究者は、このアプローチは彼らの努力に十分な収入を提供しないと述べている。代わりに、ゼロデイ攻撃を可能にするエクスプロイトを非公開で提供する。

新しい脆弱性を見つけて修正するための終わりのない努力は、コンピュータセキュリティと呼ばれる。

2014年1月に、Microsoftが修正プログラムをリリースする前にGoogleがMicrosoftの脆弱性を明らかにしたとき、Microsoftの代表者は、ソフトウェア会社間での開示を明らかにするための調整された慣行を求めた。

### 脆弱性インベントリ

Mitre Corporation (英語版) は、Common Vulnerabilities and Exposures (英語版) と呼ばれるシステムで公開されている脆弱性のリストを保持している。Common Vulnerability Scoring System(CVSS) (英語版) を使用して脆弱性が分類(スコアリング )されている。

OWASP (英語版) は潜在的な脆弱性のリストを収集して、システム設計者とプログラマーを教育することを目的としている。これにより、脆弱性が意図せずにソフトウェアに書き込まれる可能性を減らす。

## 脆弱性公開日

脆弱性が公開される時期は、セキュリティコミュニティと業界で異なって定義されている。最も一般的には「特定の当事者によるセキュリティ情報の一種の公開」と呼ばれている。通常、脆弱性情報はメーリングリストで議論されるか、セキュリティWebサイトで公開され、その後セキュリティアドバイザリが発行される。

開示の時期は、セキュリティの脆弱性がチャネルに記載された最初の日付であり、脆弱性に関する開示された情報が次の要件を満たす必要がある。

- 情報は自由に公開されている
- 脆弱性情報は、信頼できる独立したチャネル/ソースによって公開されている
- 脆弱性は専門家による分析を受けており、リスク評価情報は開示時に含まれる

コンピュータシステムの脆弱性の発見(および場合によっては削除)に役立つソフトウェアツールは多数存在する。これらのツールは、存在する可能性のある脆弱性の概要を監査人に提供できるが、人間の判断を置き換えることはできません。スキャナーのみに依存すると、誤検知が発生し、システムに存在する問題の範囲が限定されて表示される。

脆弱性は、Windows、macOS、さまざまな形式のUnixおよびLinux、OpenVMSなどを含むすべての主要なオペレーティングシステムで発見されている。システムに対して脆弱性が使用される可能性を減らす唯一の方法は、絶え間ない警戒を行うことである。絶え間ない警戒とは、慎重なシステムメンテナンス(例:ソフトウェアパッチの適用)、運用のベストプラクティス(例:ファイアウォールとアクセス制御の使用)、開発中および運用中を通じての監査、などを含む。

## 脆弱性の例

脆弱性は以下に関連している:

- システムの物理的環境
- 人事
- 管理
- 組織内の管理手順とセキュリティ対策
- 事業運営およびサービス提供
- ハードウェア
- ソフトウェア
- 通信機器および設備
- 周辺機器
- そしてそれらの組み合わせ。

純粋な技術的アプローチでは物理的資産さえ保護できないことは明らかである。適切な注意を払って従うことを動機付けた、保守要員が施設や手順を十分に理解している人々に入るようにするための管理手順が必要である。詳細はソーシャルエンジニアリングを参照されたい。

脆弱性の悪用の4つの例:

- 攻撃者が、オーバーフローの弱点を見つけて使用し、マルウェアをインストールして機密データをエクスポートする。
- 攻撃者が、マルウェアが添付された電子メールメッセージを開くようにユーザーを誘導する。
- インサイダーが、強化された暗号化プログラムをサムドライブにコピーし、自宅でそれをクラックする。
- 洪水が、1階に設置されたコンピュータシステムを損傷する。

### ソフトウェアの脆弱性

脆弱性につながる一般的な種類のソフトウェアの欠陥は次のとおりである。

- メモリ安全性違反
  - バッファオーバーランとオーバーリード
  - ぶら下がりポインタ
- 入力検証エラー:
  - コードインジェクション
  - Webアプリケーションでのクロスサイトスクリプティング
  - ディレクトリトラバーサル
  - メールインジェクション
  - 書式文字列攻撃
  - HTTPヘッダ・インジェクション
  - HTTP応答分割
  - SQLインジェクション
- 権限混同バグ:
  - クリックジャッキング
  - Webアプリケーションでのクロスサイトリクエストフォージェリ
  - FTPバウンス攻撃
- 特権エスカレーション
- 競合状態:
  - シンボリックリンク競合
  - Time of check to time of useバグ
- サイドチャネル攻撃
  - タイミング攻撃
- ユーザインタフェースの障害
  - 被害者を非難し、ユーザーに回答するのに十分な情報を提供せずにユーザーにセキュリティの決定を促す
  - 競合状態
  - 警告疲労またはユーザーによる調整

いくつかのコーディングガイドラインのセットが開発され、コードがガイドラインに従っていることを確認するために、多数の静的コードアナライザーが使用されている。