コンピュータ セキュリティにおいて、脆弱性とは、システムの設計、実装、または管理における欠陥または弱点であり、悪意のある人物がこれを悪用してセキュリティを侵害する可能性があります。

システム管理者が完全な正確性を実現するために最善を尽くしたとしても、事実上すべてのハードウェアとソフトウェアにはバグが含まれており、システムが期待どおりに動作しないことがあります。そのバグによって攻撃者がシステムリソースの機密性、整合性、または可用性を侵害できる場合、それは脆弱性とみなされます。安全でないソフトウェア開発手法や、複雑さなどの設計要因は、脆弱性の負担を増大させる可能性があります。

脆弱性管理とは、システムを特定し、最も重要なものを優先順位付けし、脆弱性をスキャンし、システムを保護するための対策を講じるプロセスです。脆弱性管理は通常、修復、緩和、そして受け入れを組み合わせたものです。

脆弱性は、共通脆弱性評価システム（CVSS）に基づいて深刻度が評価され、共通脆弱性識別子（CVE）データベースなどの脆弱性データベースに追加されます。2024年11月現在、CVEデータベースには24万件以上の脆弱性が登録されています。[1]

脆弱性は、ハードウェアまたはソフトウェアに導入された時点で発生します。脆弱性を含むソフトウェアまたはハードウェアが稼働すると、脆弱性はアクティブになり、悪用可能になります。脆弱性は、管理者、ベンダー、または第三者によって発見される可能性があります。脆弱性が（パッチなどを通じて）公開されると、攻撃者はこの情報を利用して、パッチが適用される前に既存のシステムを攻撃できるため、侵害のリスクが高まります。脆弱性は、システムにパッチが適用されるか、使用が停止されると、最終的に解消されます。

原因

システム管理者の最善の努力にもかかわらず、事実上すべてのハードウェアとソフトウェアにはバグが存在します。[2]バグがセキュリティリスクを引き起こす場合、それは脆弱性と呼ばれます。[3] [4] [5]特定された脆弱性を修正するためにソフトウェアパッチが頻繁にリリースされますが、ゼロデイ脆弱性は依然として悪用される可能性があります。[6]脆弱性は、悪意のある攻撃者によって悪用される可能性が異なり、実際のリスクは脆弱性の性質と周囲のシステムの価値に依存します。[7]一部の脆弱性はサービス拒否攻撃にのみ利用可能ですが、より危険な脆弱性では、攻撃者がユーザーに気付かれることなくコードインジェクションを実行できます。 [3]権限昇格 を可能にする脆弱性はごくわずかであり、これは通常、より深刻な攻撃に必要です。[8]脆弱性がなければ、エクスプロイトは通常アクセスできません。[9]また、ソーシャルエンジニアリングや、施錠されていないドアや露出したポートなどの脆弱な物理的セキュリティを介して、エクスプロイトなしでマルウェアが直接インストールされる可能性もあります。 [10]

設計要因

脆弱性は、次のような不適切な設計要素によって悪化する可能性があります。

  • 複雑さ：大規模で複雑なシステムは、欠陥や意図しないアクセスポイントの可能性を高めます。[11]
  • 熟知性：一般的な、よく知られたコード、ソフトウェア、オペレーティングシステム、および/またはハードウェアを使用すると、攻撃者がその欠陥を悪用するための知識とツールを持っている、または見つけることができる可能性が高まります。[12]しかし、よく知られたソフトウェア、特に無料のオープンソースソフトウェアを使用すると、発見された脆弱性に対してより頻繁で信頼性の高いソフトウェアパッチを入手できるという利点があります。[引用が必要]
  • 接続性：インターネットに接続されたあらゆるシステムはアクセスされ、侵害される可能性があります。システムをインターネットから切断することは攻撃を防ぐのに非常に効果的ですが、必ずしも実現可能とは限りません。[13]
  • レガシーソフトウェアとハ​​ードウェアは、本質的にリスクが増大しています。[14]システム管理者はレガシーシステムからのアップグレードを検討する必要がありますが、コストとダウンタイムの観点から、これは多くの場合、法外な負担となります。[要出典]

発展要因

一部のソフトウェア開発手法は、コードベースに脆弱性が取り込まれるリスクに影響を与える可能性があります。安全なソフトウェア開発に関する知識不足や、機能を迅速に提供することへの過度のプレッシャーは、特に企業文化においてセキュリティが優先されていない場合、回避可能な脆弱性が本番環境のコードに取り込まれることにつながる可能性があります。これは、意図しない脆弱性につながる可能性があります。システムが複雑になればなるほど、脆弱性が検出されなくなる可能性が高くなります。脆弱性の中には、意図的に作り出されるものもあり、その原因は様々です。不満を抱えた従業員がサイバー犯罪者にアクセス権を売ったり、国家が支援する巧妙な計画によってソフトウェアに脆弱性が取り込まれたりする可能性があります。

ソフトウェア開発のプラクティスが不十分だと、コードベースに脆弱性が入り込む可能性が高まります。安全なソフトウェア開発に関する知識やトレーニングの不足、納品への過度のプレッシャー、あるいはコードベースが過度に複雑であることなどは、脆弱性が入り込んでも気づかれないまま放置される原因となります。企業文化においてセキュリティが優先されていない場合、これらの要因はさらに悪化する可能性があります。[15]コードレビューが不十分だとバグの見逃しにつながる可能性もありますが、コードレビュープロセス中に静的コード分析ツールを使用することで、脆弱性を発見するのに役立つ場合もあります。[16]

DevOpsは、新機能の導入を迅速化するために自動テストと導入を重視した開発ワークフローですが、多くの開発者に構成変更のアクセス権を付与する必要があることが多く、これにより意図的または不注意で脆弱性が混入する可能性があります。[17] DevOpsワークフローの一部であることが多い依存関係の区分化は、依存関係を必要なものだけに絞り込むことで攻撃対象領域を減らすことができます。 [18]組織独自のハードウェアとソフトウェアではなく、サービスとしてのソフトウェアを使用する場合、組織は脆弱性を防ぐためにクラウドサービスプロバイダーに依存することになります。[19]

国家脆弱性データベース分類

国家脆弱性データベースは、脆弱性を重複する可能性のある8つの根本原因に分類しています。[20]

  1. 入力検証の脆弱性は、入力チェックだけでは攻撃者による悪意のあるコードの挿入を阻止できない場合に存在します。バッファオーバーフロー攻撃、バッファアンダーフロー攻撃、境界条件攻撃は、通常、このカテゴリを悪用します。[21]
  2. アクセス制御の脆弱性により、攻撃者は本来アクセスが制限されているはずのシステムにアクセスしたり、権限昇格を行ったりすることが可能になります。[21]
  3. システムが例外的な状況や予期しない状況を適切に処理できない場合、攻撃者はその状況を悪用してアクセスを取得する可能性があります。[22]
  4. 構成の脆弱性は、構成設定がシステムのセキュリティにリスクをもたらし、パッチが適用されていないソフトウェアやアクセスを十分に制限しないファイルシステムの権限などの障害につながる場合に発生します。[22]
  5. 競合状態（タイミングやその他の外部要因によって結果が変わり、一貫性のない、あるいは予測できない結果につながる状態）は脆弱性を引き起こす可能性があります。[22]

コンポーネント別の脆弱性

ハードウェア

製造中または製造後に意図的にセキュリティバグが混入され、特定の状況下で集積回路が期待通りに動作しなくなる可能性があります。ハードウェアにおけるセキュリティバグのテストは、時間の制約と21世紀のチップの複雑さのために非常に困難です。[23]また、設計と製造のグローバル化により、悪意のある行為者によってこれらのバグが混入される機会が増加しています。[24]

オペレーティング·システム

オペレーティングシステムの脆弱性は使用しているオペレーティングシステムによって異なりますが、一般的な問題は、攻撃者が本来許可されている以上のアクセス権を取得できる権限昇格バグです。LinuxやAndroidなどのオープンソースオペレーティングシステムは、ソースコードに自由にアクセスでき、誰でも貢献できるため、脆弱性が混入する可能性があります。しかし、 Microsoft WindowsやAppleオペレーティングシステムなどのプロプライエタリオペレーティングシステムでも同様な脆弱性が発生します。[25]信頼できるオペレーティングシステムベンダーはすべて、定期的にパッチを提供しています。[26]

クライアントサーバーアプリケーション

クライアントサーバー型アプリケーションはエンドユーザーのコンピュータにダウンロードされ、通常、ウェブアプリケーションよりも更新頻度が低くなります。ウェブアプリケーションとは異なり、クライアントサーバー型アプリケーションはユーザーのオペレーティングシステムと直接やり取りします。これらのアプリケーションによく見られる脆弱性には、以下のものがあります。[27]

ウェブアプリケーション

多くのウェブサイトではウェブアプリケーションが稼働しています。ウェブアプリケーションは他のアプリケーションに比べて本質的に安全性が低いため、データ侵害やその他のセキュリティインシデントの主な発生源となっています。[28] [29]ウェブアプリケーションには以下のようなものが含まれます。

Web アプリケーションの脆弱性を狙った攻撃には次のようなものがあります。

分類学

セキュリティバグは一般的に、以下の比較的少数の広範なカテゴリに分類されます。[33]

管理

様々なサイバー攻撃防止対策の有効性と費用対効果に関する証拠はほとんどない。[34]攻撃のリスクを見積もることは簡単ではないが、侵入までの平均時間と予想コストを考慮することで、特定された脆弱性を修復または軽減するための優先順位と、そうすることが費用対効果が高いかどうかを判断することができる。[35]セキュリティに注意を払うことで攻撃のリスクを軽減できるが、複雑なシステムに完璧なセキュリティを実現することは不可能であり、多くのセキュリティ対策には許容できないコストや使いやすさの欠点がある。[36]たとえば、システムの複雑さと機能を減らすことは、攻撃対象領域を減らすのに効果的である。[37]

脆弱性管理を成功させるには、通常、修復（脆弱性を解消すること）、緩和（エクスプロイトの難易度を高め、その影響を軽減すること）、そしてある程度の残存リスクを受け入れることが必要です。多層防御戦略は、攻撃に対する複数の障壁に対して用いられることがよくあります。[38]一部の組織では、すべての脆弱性を修正するためのリソースが不足している状況において優先順位付けを可能にするため、最もリスクの高い脆弱性のみをスキャンします。[39]費用の増加は、収益の減少を もたらす可能性があります。[35]

修復

修復は、例えばソフトウェアパッチをダウンロードするなどして脆弱性を修正します。[40] 脆弱性スキャナーは通常、ゼロデイ脆弱性を検出することはできませんが、データベースに基づいて既知の脆弱性を発見することにはより効果的です。これらのシステムは、いくつかの既知の脆弱性を発見し、パッチなどの修正をアドバイスすることができます。[41] [42]しかし、誤検知などの限界があります。[40]

脆弱性は、それがアクティブな状態、つまり脆弱性が埋め込まれたソフトウェアがシステム上でアクティブに実行されている場合にのみ悪用される可能性があります。[43]脆弱性を含むコードがシステム上で実行するように設定される前は、キャリアとみなされます。[44]休眠中の脆弱性は実行可能ですが、現在は実行されていません。休眠中の脆弱性とキャリアの脆弱性を含むソフトウェアは、アンインストールまたは無効化することでリスクを除去できる場合があります。[45]アクティブな脆弱性は、他の種類の脆弱性と区別することで、パッチ適用の優先順位を付けることができます。[43]

脆弱性緩和策とは、脆弱性を解消するのではなく、攻撃を困難にしたり、攻撃による影響を軽減したりする対策です。[46]特にルート（管理者）アクセス権を持つシステム部分の攻撃対象領域を縮小し、権限の悪用を企てる攻撃の機会を遮断することは、サイバー攻撃による被害を軽減するための一般的な戦略です。[40]サードパーティ製ソフトウェアのパッチが利用できない場合は、ソフトウェアを一時的に無効にできる可能性があります。[47]

テスト

侵入テストは、エクスプロイトを介してシステムに侵入し、システムが安全かどうかを確認します。[48]侵入テストが失敗したとしても、必ずしもシステムが安全であるとは限りません。[49]一部の侵入テストは、既存のエクスプロイトを用いて既知の脆弱性をテストする自動ソフトウェアを用いて実施できます。[50] 他の侵入テストは、訓練を受けたハッカーによって実施されます。多くの企業は、外部からの攻撃をシミュレートするため、この作業を外部委託することを好みます。[49]

脆弱性ライフサイクル

脆弱性タイムライン

脆弱性のライフサイクルは、ハードウェアまたはソフトウェアに脆弱性が導入されたときに始まります。[51]脆弱性の検出は、ソフトウェアベンダーまたはサードパーティによって行われます。後者の場合、脆弱性をベンダーに直ちに開示して修正してもらうのが最も倫理的だと考えられています。[52]政府機関や諜報機関は、公表されていない脆弱性を購入し、攻撃に利用したり、蓄積したり、ベンダーに通知したりすることがあります。[53] 2013年時点で、ファイブアイズ（米国、英国、カナダ、オーストラリア、ニュージーランド）が市場の過半数を占めており、その他の主要な購入者には、ロシア、インド、ブラジル、マレーシア、シンガポール、北朝鮮、イランなどが含まれています。[54]組織犯罪グループも脆弱性を購入していますが、通常はエクスプロイトキットを好みます。[55]

脆弱性が公開されていたり、修正プログラムが適用されていても、長期間にわたって悪用される可能性があります。[56] [57]セキュリティパッチの開発には数か月かかる場合があり、[58]あるいは開発されないこともあります。[57]パッチはソフトウェアの機能に悪影響を及ぼす可能性があり[57] 、ユーザーは機能と互換性を確認するためにパッチをテストする必要がある場合があります。 [59]大規模な組織では、すべての依存関係を特定してパッチを適用できない場合があります。一方、小規模な企業や個人ユーザーはパッチをインストールしない場合があります。[57]調査によると、脆弱性が公開されたり、パッチがリリースされたりすると、サイバー攻撃のリスクが高まります。[60]サイバー犯罪者は、パッチをリバースエンジニアリングして根本的な脆弱性を見つけ、エクスプロイトを開発することができ、 [61]多くの場合、ユーザーがパッチをインストールするよりも早く開発できます。[60]

脆弱性は、ソフトウェアまたは脆弱なバージョンが使用されなくなると廃止されます。[52]これには長い時間がかかる場合があり、特に産業用ソフトウェアは、メーカーがサポートを停止しても交換が不可能な場合があります。[62]

評価、開示、および目録

評価

脆弱性の深刻度を評価するために一般的に用いられる尺度として、オープンソース仕様の共通脆弱性評価システム（CVSS）があります。CVSSは、脆弱性を悪用してデータの機密性、可用性、および整合性を侵害する可能性を評価します。また、脆弱性がどのように利用されるか、そしてエクスプロイトにはどの程度の複雑さが必要かを考慮します。エクスプロイトに必要なアクセス量や、ユーザーの介入なしにエクスプロイトが実行可能かどうかも、総合スコアに反映されます。[63] [64]

開示

脆弱性を発見した者は、直ちにそれを開示する（完全開示）ことも、パッチが開発されるまで待つ（責任ある開示、または調整された開示）こともできる。前者のアプローチはその透明性が高く評価されているが、欠点は、開示後にパッチがない状態で攻撃を受けるリスクが増大する可能性が高いことである。[65]ベンダーの中には、脆弱性を報告した人にバグ報奨金を支払うところもある。 [66] [67]開示は法的責任や運用上のオーバーヘッドを引き起こす可能性があるため、すべての企業が開示に積極的に応じるわけではない。[68] 脆弱性の開示を義務付ける法律はない。[69]脆弱性がベンダーや一般に開示されない第三者によって発見された場合、それはゼロデイ脆弱性と呼ばれ、防御策が少ないため、最も危険なタイプであると考えられることが多い。[70]

脆弱性インベントリ

最も一般的に使用されている脆弱性データセットは、 Mitre Corporationが管理するCommon Vulnerabilities and Exposures (CVE)です。[71] 2024年11月現在、24万件を超えるエントリがあります[1]この情報は、米国のNational Vulnerability Database を含む他のデータベースと共有され、[71]各脆弱性にはCommon Vulnerability Scoring System (CVSS)、Common Platform Enumeration (CPE) スキーム、およびCommon Weakness Enumerationを使用してリスクスコアが与えられます[要出典] CVE やその他のデータベースでは、通常、サービスとしてのソフトウェア製品の脆弱性は追跡されません[41] CVE の提出は、脆弱性を発見した企業にとって任意です[69]

責任

ソフトウェアベンダーは、脆弱性が攻撃に利用された場合、通常、その費用について法的責任を負いません。そのため、安価だが安全性の低いソフトウェアを開発するインセンティブが生まれます。[72]一部の企業は、 PCI、HIPAA、サーベンス・オクスリー法など、脆弱性管理に法的要件を課す法律の対象となっています。[73]

参照

参考文献

  1. ^ ab "CVE - プログラムメトリクス". 2024年11月15日.
  2. ^ アブロン＆ボガート 2017、1ページ。
  3. ^ Ablon & Bogart 2017、2ページ。
  4. ^ ダスワニとエルバヤディ 2021、p. 25.
  5. ^ シーマン 2020年、47～48頁。
  6. ^ ダスワニ & エルバヤディ 2021、26–27 ページ。
  7. ^ ハーバー＆ヒバート 2018、5～6頁。
  8. ^ ハーバー＆ヒバート 2018、6ページ。
  9. ^ ハーバー＆ヒバート 2018、10ページ。
  10. ^ ハーバー＆ヒバート 2018、13～14頁。
  11. ^ Kakareka, Almantas (2009). "23". Vacca, John (編). 『コンピュータと情報セキュリティハンドブック』 . Morgan Kaufmann Publications. Elsevier Inc. p. 393. ISBN 978-0-12-374354-1。
  12. ^ Krsul, Ivan (1997年4月15日).技術レポート CSD-TR-97-026 . COAST研究所 コンピュータサイエンス学科, パデュー大学. CiteSeerX 10.1.1.26.5435 . 
  13. ^ Linkov & Kott 2019、2ページ。
  14. ^ ハーバー＆ヒバート 2018、155ページ。
  15. ^ ストラウト2023、17ページ。
  16. ^ ハーバー＆ヒバート 2018、143ページ。
  17. ^ ハーバー＆ヒバート 2018、141ページ。
  18. ^ ハーバー＆ヒバート 2018、142ページ。
  19. ^ ハーバー＆ヒバート 2018、135–137頁。
  20. ^ Garg & Baliyan 2023、17–18 ページ。
  21. ^ ab Garg & Baliyan 2023、p. 17.
  22. ^ abc ガーグ＆バリヤン 2023、p. 18.
  23. ^ サルマニ 2018、1ページ。
  24. ^ サルマニ 2018、11ページ。
  25. ^ Garg & Baliyan 2023、20–25 ページ。
  26. ^ シャープ2024、271ページ。
  27. ^ abc Strout 2023、15ページ。
  28. ^ abcd Strout 2023、13ページ。
  29. ^ ハーバー＆ヒバート 2018、129ページ。
  30. ^ 「CWE/SANS 最も危険なソフトウェアエラー トップ25」SANS . 2012年7月13日閲覧。
  31. ^ abcde Strout 2023、14ページ。
  32. ^ ストラウト2023、14～15頁。
  33. ^ Alhazmi, Omar H.; Woo, Sung-Whan; Malaiya, Yashwant K. (2006年1月). 「主要ソフトウェアシステムにおけるセキュリティ脆弱性カテゴリ」.第3回IASTED国際通信・ネットワーク・情報セキュリティ会議議事録.
  34. ^ アグラフィオティスら。 2018、p. 2.
  35. ^ ハーバー＆ヒバート 2018、97～98頁。
  36. ^ Tjoa et al. 2024, p.63.
  37. ^ チョアら。 2024 年、68、70 ページ。
  38. ^ マグナソン 2020、34ページ。
  39. ^ ハーバー＆ヒバート 2018、166–167頁。
  40. ^ abc ハーバー＆ヒバート 2018、p.11。
  41. ^ Strout 2023、8ページより。
  42. ^ ハーバー＆ヒバート 2018、12～13頁。
  43. ^ ハーバー＆ヒバート 2018、84ページより。
  44. ^ ハーバー＆ヒバート 2018、85ページ。
  45. ^ ハーバー＆ヒバート 2018、84～85頁。
  46. ^ マグナソン 2020、32ページ。
  47. ^ マグナソン 2020、33ページ。
  48. ^ ハーバー＆ヒバート 2018、93ページ。
  49. ^ ハーバー＆ヒバート 2018、96ページより。
  50. ^ ハーバー＆ヒバート 2018、94ページ。
  51. ^ ストラウト2023、16ページ。
  52. ^ Strout 2023、18ページより。
  53. ^ リビッキ、アブロン & ウェッブ、2015 年、p. 44.
  54. ^ パールロス 2021、145頁。
  55. ^ リビッキ、アブロン、ウェッブ 2015年、44、46頁。
  56. ^ アブロン＆ボガート 2017、8ページ。
  57. ^ abcd Sood & Enbody 2014、42ページ。
  58. ^ ストラウト2023、26ページ。
  59. ^ Libicki、Ablon & Webb 2015、p. 50.
  60. ^ ab Libicki、Ablon＆Webb 2015、49～50頁。
  61. ^ ストラウト2023、28ページ。
  62. ^ ストラウト2023、19ページ。
  63. ^ ストラウト2023、5～6頁。
  64. ^ ハーバー＆ヒバート 2018、73～74頁。
  65. ^ 「倫理学者に聞く：脆弱性開示」。計算機協会職業倫理委員会。2018年7月17日。 2024年5月3日閲覧。
  66. ^ オハロー 2013、18ページ。
  67. ^ Libicki、Ablon & Webb 2015、p. 45.
  68. ^ ストラウト2023、36ページ。
  69. ^ ハーバー＆ヒバート 2018、110ページより。
  70. ^ ストラウト2023、22ページ。
  71. ^ Strout 2023、6ページより。
  72. ^ スローン＆ワーナー 2019、104～105頁。
  73. ^ ハーバー＆ヒバート 2018、111ページ。

出典

  • アブロン、リリアン、ボガート、アンディ (2017). 『ゼロデイ、千の夜：ゼロデイ脆弱性とそのエクスプロイトの生涯と時代』（PDF） . ランド研究所. ISBN 978-0-8330-9761-3。
  • アグラフィオティス, イオアニス; ナース, ジェイソン RC; ゴールドスミス, マイケル; クリース, サディ; アプトン, デイビッド (2018). 「サイバー被害の分類：サイバー攻撃の影響の定義と伝播経路の理解」.ジャーナル・オブ・サイバーセキュリティ. 4 (1). doi : 10.1093/cybsec/tyy006 . ISSN  2057-2085.
  • ダスワニ、ニール、エルバヤディ（2021年）『大規模侵害：誰もが学ぶべきサイバーセキュリティの教訓』 Apress. ISBN 978-1-4842-6654-0。
  • ガーグ、シヴィ。バリヤン、ニヤティ（2023）。モバイル OS の脆弱性: 定量的および定性的分析。 CRCプレス。ISBN 978-1-000-92451-0。
  • ハーバー、モリー・J.; ヒバート、ブラッド (2018). 『資産攻撃ベクトル：組織を守るための効果的な脆弱性管理戦略の構築』 Apress. ISBN 978-1-4842-3627-7。
  • リビッキ、マーティン・C、アブロン、リリアン、ウェッブ、ティム（2015年）『防御者のジレンマ：サイバーセキュリティへの道筋を描く』（PDF）ランド研究所、ISBN 978-0-8330-8911-3。
  • イゴール・リンコフ、アレクサンダー・コット（2019年）「サイバーレジリエンスの基本概念：序論と概要」『システムとネットワークのサイバーレジリエンス』シュプリンガー・インターナショナル・パブリッシング、pp.  1- 25. ISBN 978-3-319-77492-3。
  • マグナッソン、アンドリュー（2020年）『実践的脆弱性管理：サイバーリスク管理への戦略的アプローチ』ノー・スターチ・プレス、ISBN 978-1-59327-989-9。
  • オハロー、ロバート（2013年）『ゼロデイ：サイバー空間の脅威』ダイバージョン・ブックス、ISBN 978-1-938120-76-3。
  • パールロス、ニコール（2021年）『これが世界の終わりを告げる方法：2021年FT＆マッキンゼー・ビジネスブック・オブ・ザ・イヤー受賞』ブルームズベリー・パブリッシング、ISBN 978-1-5266-2983-8。
  • サルマニ、ハッサン（2018年）『信頼できるデジタル回路：ハードウェアトロイの木馬の脆弱性、予防、検出』シュプリンガー社ISBN 978-3-319-79081-7。
  • シーマン、ジム（2020年）『PCI DSS：統合データセキュリティ標準ガイド』Apress. ISBN 978-1-4842-5808-8。
  • シャープ、ロビン（2024年）『サイバーセキュリティ入門：多分野にわたる課題』シュプリンガー・ネイチャー、ISBN 978-3-031-41463-3。
  • スローン、ロバート・H.、ワーナー、リチャード（2019年）『なぜ私たちはより良く守れないのか？：データ侵害、リスク管理、そして公共政策』CRC Press. ISBN 978-1-351-12729-5。
  • スード、アディティア、エンボディ、リチャード（2014年）『標的型サイバー攻撃：エクスプロイトとマルウェアによる多段階攻撃』Syngress. ISBN 978-0-12-800619-1。
  • ストラウト、ベンジャミン（2023年）『脆弱性研究者のためのハンドブック：セキュリティ脆弱性の発見、報告、公開のための包括的ガイド』 Packt Publishing. ISBN 978-1-80324-356-6。
  • チョア、サイモン。ガフィッチ、メリサ。ピーター・キースバーグ (2024)。サイバーレジリエンスの基礎。スプリンガーの自然。ISBN 978-3-031-52064-8。
  • ウィキメディア・コモンズの脆弱性（コンピューティング）に関連するメディア