セキュリティホール

セキュリティホール（英: 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）は、 リスク管理の原則に従って、所定のポリシーに適用される規則や規制に従ってセキュリティ戦略が確立されていることを確認するための対策を管理するために開発された国。これらの対策はセキュリティコントロールとも呼ばれるが、情報の送信に適用される場合はセキュリティサービスと呼ばれる。
分類.
脆弱性は、関連する資産クラスに従って分類される：
原因.
調査によると、ほとんどの情報システムで最も脆弱なポイントは、人間のユーザー、オペレーター、デザイナー、またはその他の人間である。したがって、人間は、資産、脅威、情報リソースとしてのさまざまな役割を考慮する必要がある。近年ではソーシャルエンジニアリングと呼ばれるセキュリティに関する懸念が高まっている。
脆弱性の影響.
セキュリティ違反の影響は非常に大きくなる可能性がある。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つの例：
ソフトウェアの脆弱性.
脆弱性につながる一般的な種類のソフトウェアの欠陥は次のとおりである。 
いくつかのコーディングガイドラインのセットが開発され、コードがガイドラインに従っていることを確認するために、多数の静的コードアナライザーが使用されている。