セキュリティホール

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

概要

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

セキュリティホールが残されていることにより、本来できないはずの操作（ある操作について権限のないユーザが権限を超えた操作を実行するなど）ができてしまったり、非公開のはずの情報が誰にでも取得できてしまうような、情報セキュリティ上の欠陥となる。

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

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

定義

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

1つ以上の脅威によって悪用される可能性のあるアセットまたはアセットのグループの弱点。アセットとは、組織の使命をサポートする情報リソースを含む、組織、その事業運営、および継続性に価値のあるものを指す

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

システムのセキュリティポリシーに違反するために悪用される可能性がある、システムの設計、実装、または運用と管理の欠陥または弱点

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

脆弱性-脅威の発生源によって悪用される可能性のある情報システム、システムセキュリティ手順、内部統制、または実装の脆弱性。

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

システムのセキュリティ手順、設計、実装、または内部統制の欠陥または弱点であり、行使されて（偶発的に引き起こされた、または意図的に悪用された）、セキュリティ違反またはシステムのセキュリティポリシーの違反につながる可能性がある。

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

関与するコンピュータシステム、ネットワーク、アプリケーション、またはプロトコルのセキュリティを危険にさらす、予期しない望ましくないイベント[G.11]につながる可能性のある弱点、設計、または実装のエラーの存在。(ITSEC）

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

脅威の能力が脅威に抵抗する能力を超える確率。

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

資産が脅威エージェントのアクションに抵抗できない確率

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

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

設計、実装、運用、または内部統制の弱点

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

1）コンピュータセキュリティにおいて、情報への不正アクセスを取得したり、重要な処理を妨害したりする脅威によって悪用される可能性のある、自動システムセキュリティ手順、管理制御、インターネット制御などの弱点。 2）コンピューターのセキュリティーにおいて、ADPシステムまたはアクティビティーに危害を加えるために悪用される可能性がある、物理的なレイアウト、組織、手順、人員、管理、ハードウェアまたはソフトウェアの弱点。 3）コンピューターのセキュリティーにおいて、システムに存在する弱点または欠陥。攻撃または有害なイベント、または脅威エージェントがその攻撃を開始する機会。

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

コンピュータシステムは、コンピュータシステムを構成するエンティティの現在の構成を記述する状態で構成される。システムは、システムの状態を変更する状態遷移を適用して計算する。一連の状態遷移を使用して特定の初期状態から到達可能なすべての状態は、セキュリティポリシーで定義されているように、許可または無許可のクラスに分類される。このホワイトペーパーでは、これらのクラスと遷移の定義は公理的と見なされる。脆弱な状態とは、許可された状態遷移を使用して許可されていない状態に到達できる許可された状態である。侵害された状態とは、そのように到達した状態である。攻撃とは、危険にさらされた状態で終了する一連の許可された状態遷移である。定義により、攻撃は脆弱な状態で始まる。脆弱性とは、脆弱な状態を特徴付けるものであり、すべての脆弱な状態と区別される。一般的な場合、この脆弱性は多くの脆弱な状態を特徴付ける可能性がある。具体的には、1つだけを特徴付ける場合がある。

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

自動化されたシステムセキュリティ手順、管理コントロール、内部コントロールなどの弱点。情報への不正アクセスを取得したり、重要な処理を妨害したりする脅威によって悪用される可能性がある。 2.システムのセキュリティ手順、ハードウェアの設計、内部統制などの弱点。これらの情報を悪用して、機密情報や機密情報への不正アクセスを可能にする可能性がある。 3.ADPシステムまたはアクティビティに危害を加えるために悪用される可能性がある、物理的なレイアウト、組織、手順、人員、管理、ハードウェア、またはソフトウェアの弱点。脆弱性の存在自体が害を及ぼすことはありません。脆弱性は、ADPシステムまたはアクティビティが攻撃によって被害を受ける可能性がある状態または状態のセットにすぎない。 4.主に内部環境のエンティティ（アセット）に関する主張。アセット（またはアセットのクラス）は脆弱であると言う（何らかの方法で、エージェントまたはエージェントのコレクションが関与している可能性がある）。 V(i,e)と書き表す。ここで、eは空の集合であるかもしれない。 5.さまざまな脅威に対する感受性。 6.特定の外部エンティティの一連のプロパティと組み合わせて、リスクを意味する特定の内部エンティティの一連のプロパティ。 7.不自然な（人工の）敵対的な環境で特定のレベルの影響を受けた結果として、システムに明確な劣化（指定されたミッションを実行できない）を引き起こすシステムの特性。

脆弱性に関連した騒ぎ

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

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

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

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

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

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

OWASP：脅威エージェントとビジネスへの影響の関係

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バグ
• サイドチャネル攻撃
  • タイミング攻撃
• ユーザインタフェースの障害
  • 被害者を非難し、ユーザーに回答するのに十分な情報を提供せずにユーザーにセキュリティの決定を促す
  • 競合状態
  • 警告疲労またはユーザーによる調整

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

関連項目

• 脆弱性
• コンピュータセキュリティ
• 情報セキュリティ
• ゼロデイ攻撃 - セキュリティホールが周知・対処される前の攻撃
• エクスプロイト - セキュリティホールを利用する攻撃あるいはその攻撃手法
• コンピュータウイルス
• 脆弱性情報データベース
• 脆弱性検査ツール
• CSIRT
• セット打法 - パチンコ・パチスロを動作させているソフトウェアのセキュリティホールを突く操作

出典

[脚注の使い方]

1. ^ “基礎知識　セキュリティホールとは？”. www.soumu.go.jp. 2020年9月19日閲覧。
2. ^ “脆弱性（ぜいじゃくせい）とは？｜どんな危険があるの？｜基礎知識｜国民のための情報セキュリティサイト”. www.soumu.go.jp. 2020年9月19日閲覧。
3. ^ ^{a b} ISO/IEC, "Information technology -- Security techniques-Information security risk management" ISO/IEC FIDIS 27005:2008
4. ^ British Standard Institute, Information technology -- Security techniques -- Management of information and communications technology security -- Part 1: Concepts and models for information and communications technology security management BS ISO/IEC 13335-1-2004
5. ^ ^{a b} Internet Engineering Task Force RFC 4949 Internet Security Glossary, Version 2
6. ^ “CNSS Instruction No. 4009” (26 April 2010). 2013年6月28日時点のオリジナルよりアーカイブ。2020年12月21日閲覧。
7. ^ “FISMApedia”. fismapedia.org. 2020年12月21日閲覧。
8. ^ “Term:Vulnerability”. fismapedia.org. 2020年12月21日閲覧。
9. ^ NIST SP 800-30 Risk Management Guide for Information Technology Systems
10. ^ “Glossary”. europa.eu. 2020年12月21日閲覧。
11. ^ Technical Standard Risk Taxonomy ISBN 1-931624-77-1 Document Number: C081 Published by The Open Group, January 2009.
12. ^ ^{a b} "An Introduction to Factor Analysis of Information Risk (FAIR)", Risk Management Insight LLC, November 2006 Archived 2014-11-18 at the Wayback Machine.
13. ^ Dennis Longley and Michael Shain. Data & Computer Security: Dictionary of standards concepts and terms. Stockton Press, ISBN 0-935859-17-9
14. ^ Matt Bishop and Dave Bailey. A Critical Analysis of Vulnerability Taxonomies. Technical Report CSE-96-11, Department of Computer Science at the University of California at Davis, September 1996
15. ^ Schou, Corey (1996). Handbook of INFOSEC Terms, Version 2.0. CD-ROM (Idaho State University & Information Systems Security Organization)
16. ^ NIATEC Glossary
17. ^ ISACA THE RISK IT FRAMEWORK (registration required) Archived July 5, 2010, at the Wayback Machine.
18. ^ ^{a b} Wright, Joe; Harmening, Jim (2009). “15”. In Vacca, John. Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 257. ISBN 978-0-12-374354-1 
19. ^ Krsul, Ivan (April 15, 1997). Technical Report CSD-TR-97-026. The COAST Laboratory Department of Computer Sciences, Purdue University. 
20. ^ Pauli, Darren (16 January 2017). “Just give up: 123456 is still the world's most popular password”. The Register. https://www.theregister.co.uk/2017/01/16/123456_is_still_the_worlds_most_popular_password/ 2017年1月17日閲覧。 
21. ^ ^{a b} Kakareka, Almantas (2009). “23”. In Vacca, John. Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 393. ISBN 978-0-12-374354-1 
22. ^ “The Six Dumbest Ideas in Computer Security”. ranum.com. 2020年12月21日閲覧。
23. ^ “The Web Application Security Consortium / Web Application Security Statistics”. webappsec.org. 2020年12月21日閲覧。
24. ^ Ross Anderson. Why Cryptosystems Fail. Technical report, University Computer Laboratory, Cam- bridge, January 1994.
25. ^ Neil Schlager. When Technology Fails: Significant Technological Disasters, Accidents, and Failures of the Twentieth Century. Gale Research Inc., 1994.
26. ^
27. ^ Kiountouzis, E. A.; Kokolakis, S. A.. Information systems security: facing the information society of the 21st century. London: , Ltd. ISBN 0-412-78120-4 
28. ^ Bavisi, Sanjay (2009). “22”. In Vacca, John. Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 375. ISBN 978-0-12-374354-1 
29. ^ “The new era of vulnerability disclosure - a brief chat with HD Moore”. The Tech Herald. 2010年8月26日時点のオリジナルよりアーカイブ。2010年8月24日閲覧。
30. ^ “Browse - Content - SecurityStreet”. rapid7.com. 2020年12月21日閲覧。
31. ^ Betz (11 Jan 2015). “A Call for Better Coordinated Vulnerability Disclosure - MSRC - Site Home - TechNet Blogs”. blogs.technet.com. 12 January 2015閲覧。
32. ^ “Category:Vulnerability”. owasp.org. 2020年12月21日閲覧。
33. ^ David Harley (10 March 2015). “Operating System Vulnerabilities, Exploits and Insecurity”. 15 January 2019閲覧。
34. ^ Most laptops vulnerable to attack via peripheral devices. http://www.sciencedaily.com/releases/2019/02/190225192119.htm Source: University of Cambridge]
35. ^ Exploiting Network Printers. Institute for IT-Security, Ruhr University Bochum
36. ^ [1] Archived October 21, 2007, at the Wayback Machine.
37. ^ “Jesse Ruderman » Race conditions in security dialogs”. squarefree.com. 2020年12月21日閲覧。
38. ^ “lcamtuf's blog”. lcamtuf.blogspot.com. 2020年12月21日閲覧。
39. ^ “Warning Fatigue”. freedom-to-tinker.com. 2020年12月21日閲覧。
40. ^ “ネットワークセキュリティ関連用語集（アルファベット順）：IPA 独立行政法人 情報処理推進機構”. www.ipa.go.jp. 2020年9月19日閲覧。

外部リンク

• ウィキメディア・コモンズには、セキュリティホールに関するカテゴリがあります。
• オープンディレクトリのセキュリティアドバイザリリンクhttp://dmoz-odp.org/Computers/Security/Advisories_and_Patches/
  • セキュリティホールmemo