セキュリティホール

出典: フリー百科事典『ウィキペディア(Wikipedia)』

出典: フリー百科事典『ウィキペディア(Wikipedia)』
検索に移動

セキュリティホール は、脆弱性についての俗表現である。 脆弱性は、コンピュータソフトウェアの欠陥(バグ、不具合、あるいはシステム上の盲点)の一つで、本来操作できないはずの操作(権限のないユーザが権限を超えた操作を実行するなど)ができてしまったり、見えるべきでない情報が第三者に見えてしまうような不具合をいう。ハードウェアおよびそれを含めたシステム全般の欠陥を指すこともある。

このような欠陥は古くから存在したが、特に問題視されるようになったのはインターネットの発展に伴って脆弱性がネットワークを介して容易に攻撃されうる状態になっているからである。

原因としては、プログラムのコーディング間違いや、システムの設定間違い、システム設計上の考慮不足、故意に作られ秘密にされた機能の漏洩などがある。

コンピュータセキュリティにおいて 、 脆弱性が悪用される可能性があるによって弱点である脅威俳優のコンピュータシステム内の不正なアクションを実行するために、攻撃者として、。 脆弱性を悪用するには、システムの脆弱性に接続できる少なくとも1つの適用可能なツールまたは手法が攻撃者に必要である。 このフレームでは、脆弱性は攻撃面とも呼ばれる。

脆弱性管理は、理論的には異なるが、すべての資産の発見、資産の優先順位付け、完全な脆弱性スキャンの評価または実行、結果のレポート、脆弱性の修正、修正の検証-繰り返しを含む、共通のプロセスを含む周期的なプラクティスである。 この慣行は一般に、コンピューティングシステムにおけるソフトウェアの脆弱性を指す。 [1]

多くの場合、セキュリティリスクは誤って脆弱性として分類される。 リスクと同じ意味の脆弱性を使用すると、混乱が生じる可能性がある。 リスクとは、脆弱性の悪用による重大な影響の可能性である。 次に、リスクのない脆弱性がある。たとえば、影響を受ける資産に価値がない場合などである。 機能し、完全に実装された攻撃の1つ以上の既知のインスタンスを持つ脆弱性は、 悪用可能な脆弱性、つまり悪用が存在する脆弱性として分類される。 脆弱性のウィンドウとは、展開されたソフトウェアにセキュリティホールが導入または明示されてから、アクセスが削除される、セキュリティフィックスが利用可能/展開される、または攻撃者が無効になるまでの時間である。 ゼロデイ攻撃を参照してください。

セキュリティバグ ( セキュリティ欠陥 )はより狭い概念である。ソフトウェアに関連しない脆弱性がある。 ハードウェア 、サイト、人員の脆弱性は、ソフトウェアのセキュリティバグではない脆弱性の例である。

適切に使用するのが難しいプログラミング言語の構成要素は、脆弱性の大きな原因となる可能性がある。

ゼロデイ[編集]

セキュリティホールを狙った攻撃が、セキュリティホールの修正プログラムや修正バージョンが提供される前に起こること。 QHosts や Download.ject などが、ゼロデイだったのではないかといわれている。 ゼロデイ攻撃とも報道される。(詳細は、項目参照)

エクスプロイト[編集]

エクスプロイト (exploit) とはソフトウェアの脆弱性を攻撃すること、及びその方法をいう[2]

脆弱性[編集]

脆弱性は、英語の vulnerability の日本語訳である。この分野での意味は「弱点」であり、セキュリティホール(安全性欠陥)と類似している。ただし、セキュリティホールがより具体的な欠陥を指す傾向があるのに対して、脆弱性は欠陥だけではなく、たとえ意図した(要求仕様どおりの)動作であっても、攻撃に対して弱ければ、つまり「弱点」があれば用いるという点が異なる。たとえば、災害や、悪意のある者がパスワードを管理者から聞き出してしまうような攻撃(ソーシャルエンジニアリング)といった、原因がコンピュータシステムだけに収まらない弱さに対しても用いられる。また、ハードウェアおよびそれを含めたシステム全般の欠陥や弱点については脆弱性のほうが好まれる。反対語はレジリエンス(resilience)であり、日本語訳として強靭化が用いられることもある。

定義[編集]

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

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

IETF [rfc:4949 RFC 4949の] 脆弱性 : [5]

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

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

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

多くのNISTの出版物は、さまざまな出版物でITコンテキストの脆弱性を定義している 。FISMApedia [7] term [8]リストが示されている。 それらの間でSP 800-30、 [9]はより広いものを与える:

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

ENISAは、 [10] 脆弱性を次のように定義している。

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

Open Groupは、 [11] 脆弱性を次のように定義している。

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

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

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

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

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

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

データとコンピュータのセキュリティ:標準の概念と用語の辞書、著者のデニスロングリーとマイケルシェイン、ストックトンプレス、 ISBN 0-935859-17-9 、 脆弱性を次のように定義する :

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

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

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

National Information Assurance Training and Education Centerは脆弱性を定義している : [14] [15]

自動化されたシステムセキュリティ手順、管理コントロール、内部コントロールなどの弱点。情報への不正アクセスを取得したり、重要な処理を妨害したりする脅威によって悪用される可能性がある。 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 の欠陥を利用した "MSBlaster" というワームが猛威を振るった。

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

対策としては、まずファイアウォール、または IPるカレード (NAPT, NATP, eNAT とも) に対応したルータを導入し、外部から試みられる接続をすべて遮断した後に、修正モジュールのダウンロードインストール (Windows では Microsoft Update) をこまめに行う処置が中心となる。

脆弱性とリスク要因モデル[編集]

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

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

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

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

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

情報セキュリティ管理システム[編集]

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

分類[編集]

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

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

原因[編集]

  • 複雑さ:大規模で複雑なシステムは、欠陥や意図しないアクセスポイントの可能性を高め
  • 熟知度:よく知られている一般的なコード、ソフトウェア、オペレーティングシステム、ハードウェアを使用すると、攻撃者がその欠陥を悪用するための知識やツールを見つけたり、見つけたりできる可能性が高くなる。 [18]
  • 接続性:より多くの物理的な接続、特権、ポート、プロトコル、サービス、およびそれらのそれぞれにアクセスできる時間が脆弱性を増加させる。 [12]
  • パスワード管理の欠陥:コンピューターユーザーがブルートフォースによって発見される可能性のある脆弱なパスワードを使用している 。 [19] コンピューターユーザーは、プログラムがアクセスできるコンピューターにパスワードを保存する。 ユーザーは多くのプログラムとWebサイト間でパスワードを再利用する。 [20]
  • オペレーティングシステムの基本的な設計上の欠陥:オペレーティングシステムの設計者は、ユーザー/プログラム管理に次善のポリシーを適用することを選択する。 たとえば、 デフォルトの許可などのポリシーを持つオペレーティングシステムは、すべてのプログラムとすべてのユーザーにコンピュータ全体へのフルアクセスを許可する。 [20] このオペレーティングシステムの欠陥により、ウイルスやマルウェアが管理者に代わってコマンドを実行できるようになる。 [21]
  • インターネットWebサイトの閲覧:一部のインターネットWebサイトには、コンピュータシステムに自動的にインストールされる有害なスパイウェアまたはアドウェアが含まれている場合がある。 これらのWebサイトにアクセスすると、コンピューターシステムが感染し、個人情報が収集されて第三者の個人に渡される。 [22]
  • ソフトウェアのバグ :プログラマは、ソフトウェアプログラムに悪用可能なバグを残す。 ソフトウェアのバグにより、攻撃者がアプリケーションを悪用する可能性がある。
  • 未チェックのユーザー入力 :プログラムは、すべてのユーザー入力が安全であると想定する。 ユーザー入力をチェックしないプログラムは、コマンドまたはSQLステートメント( バッファーオーバーフローSQLインジェクション、またはその他の検証されていない入力と呼ばれる)の意図しない直接実行を許可する可能性がある。
  • 過去の過ちから学ばない: [23] [24]たとえば、 IPv4プロトコルソフトウェアで発見されたほとんどの脆弱性は、新しいIPv6実装で発見された。 [25]

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

脆弱性の影響[編集]

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

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

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

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

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

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

脆弱性の開示[編集]

脆弱性の責任ある開示(最初は偏った言葉であるため、多くの場合、「調整された開示」と呼ばれる)は大きな議論の的となっている。 2010年8月にTech Heraldが報告したように、「 GoogleMicrosoft 、 TippingPoint 、およびRapid7は最近、今後の開示にどう対処するかを説明するガイドラインと声明を発表した。」 [28]

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

脆弱性のすべての詳細が公開されたときに完全な開示が行われる。おそらく、ソフトウェアまたは手順の作成者に修正を早急に見つけるよう圧力をかけるためである。

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

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

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

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

脆弱性インベントリ[編集]

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

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

脆弱性公開日[編集]

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

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

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

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

脆弱性は、 WindowsmacOS 、さまざまな形式のUnixおよびLinuxOpenVMSなどを含むすべての主要なオペレーティングシステム[32]発見されている。 システムに対して脆弱性が使用される可能性を減らす唯一の方法は、慎重なシステムメンテナンス(例:ソフトウェアパッチの適用)、導入のベストプラクティス(例: ファイアウォールアクセスコントロールの使用 )、および監査(両方とも)開発およびデプロイメントのライフサイクル全体を通じて)。

脆弱性の例[編集]

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

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

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

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

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

ソフトウェアの脆弱性[編集]

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

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

関連項目[編集]

出典[編集]

  1. ^ Vulnerability Management Life Cycle | NPCR | CDC” (英語). www.cdc.gov (2019年3月12日). 2020年7月4日閲覧。
  2. ^ 情報処理推進機構:セキュリティセンター:ネットワークセキュリティ関連用語集
  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” (2010年4月26日). 2013年6月28日時点のオリジナルよりアーカイブ。 Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  7. ^ FISMApedia”. fismapedia.org. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  8. ^ Term:Vulnerability”. fismapedia.org. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  9. ^ NIST SP 800-30 Risk Management Guide for Information Technology Systems
  10. ^ Glossary”. europa.eu. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  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. ^ 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
  14. ^ Schou, Corey (1996). Handbook of INFOSEC Terms, Version 2.0. CD-ROM (Idaho State University & Information Systems Security Organization)
  15. ^ NIATEC Glossary
  16. ^ ISACA THE RISK IT FRAMEWORK (registration required) Archived July 5, 2010, at the Wayback Machine.
  17. ^ 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 
  18. ^ Template:Cite webの呼び出しエラー:引数 url は必須です。Krsul (1997年4月15日). “[{{{url}}} Technical Report CSD-TR-97-026]”. The COAST Laboratory Department of Computer Sciences, Purdue University. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  19. ^ Pauli, Darren (2017年1月16日). “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日閲覧。 
  20. ^ 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 
  21. ^ The Six Dumbest Ideas in Computer Security”. ranum.com. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  22. ^ The Web Application Security Consortium / Web Application Security Statistics”. webappsec.org. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  23. ^ Ross Anderson. Why Cryptosystems Fail. Technical report, University Computer Laboratory, Cam- bridge, January 1994.
  24. ^ Neil Schlager. When Technology Fails: Significant Technological Disasters, Accidents, and Failures of the Twentieth Century. Gale Research Inc., 1994.
  25. ^ Hacking: The Art of Exploitation Second Edition
  26. ^ Kiountouzis, E. A.; Kokolakis, S. A.. Information systems security: facing the information society of the 21st century. London: Chapman & Hall, Ltd. ISBN 0-412-78120-4 
  27. ^ 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 
  28. ^ The new era of vulnerability disclosure - a brief chat with HD Moore”. The Tech Herald. 2010年8月26日時点のオリジナルよりアーカイブ。2010年8月24日閲覧。
  29. ^ Browse - Content - SecurityStreet”. rapid7.com. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  30. ^ Betz (2015年1月11日). “A Call for Better Coordinated Vulnerability Disclosure - MSRC - Site Home - TechNet Blogs”. blogs.technet.com. 2015年1月12日閲覧。
  31. ^ Category:Vulnerability”. owasp.org. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  32. ^ David Harley (2015年3月10日). “Operating System Vulnerabilities, Exploits and Insecurity”. 2019年1月15日閲覧。
  33. ^ Most laptops vulnerable to attack via peripheral devices. http://www.sciencedaily.com/releases/2019/02/190225192119.htm Source: University of Cambridge]
  34. ^ Exploiting Network Printers. Institute for IT-Security, Ruhr University Bochum
  35. ^ [1] Archived October 21, 2007, at the Wayback Machine.
  36. ^ Jesse Ruderman » Race conditions in security dialogs”. squarefree.com. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  37. ^ lcamtuf's blog”. lcamtuf.blogspot.com. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。
  38. ^ Warning Fatigue”. freedom-to-tinker.com. Template:Cite webの呼び出しエラー:引数 accessdate は必須です。