脆弱性（コンピュータセキュリティ）

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

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

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

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

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

原因

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

設計要因

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

発展要因

ソフトウェア開発のプラクティスが不十分だと、コードベースに脆弱性が入り込む可能性が高まります。安全なソフトウェア開発に関する知識やトレーニングの不足、納品への過度のプレッシャー、あるいはコードベースが過度に複雑であることなどは、脆弱性が入り込んでも気づかれないまま放置される原因となります。企業文化においてセキュリティが優先されていない場合、これらの要因はさらに悪化する可能性があります。[ 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. ^ a b「CVE - プログラムメトリクス」。2024年11月15日。
  2. ^アブロン＆ボガート 2017、1ページ。
  3. ^ a bアブロン＆ボガート 2017、p.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. ^ a bガーグ＆バリヤン 2023、p. 17.
  22. ^ a b cガーグ＆バリヤン 2023、p. 18.
  23. ^サルマニ 2018、1ページ。
  24. ^サルマニ 2018、11ページ。
  25. ^ Garg & Baliyan 2023、20–25 ページ。
  26. ^シャープ2024、271ページ。
  27. ^ a b cストラウト 2023、15ページ。
  28. ^ a b c d Strout 2023、13ページ。
  29. ^ハーバー＆ヒバート 2018、129頁。
  30. ^ 「CWE/SANS 最も危険なソフトウェアエラー トップ25」 SANS 2012年7月13日閲覧。
  31. ^ a b c d eストラウト 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. ^ a bハーバー＆ヒバート 2018、97–98頁。
  36. ^ Tjoa et al. 2024、63頁。
  37. ^チョアら。 2024、68、70ページ。
  38. ^マグナソン 2020、34ページ。
  39. ^ハーバー＆ヒバート 2018、166–167頁。
  40. ^ a b cハーバー＆ヒバート 2018、p.11。
  41. ^ a b Strout 2023、8ページ。
  42. ^ハーバー＆ヒバート 2018、12～13頁。
  43. ^ a bハーバー＆ヒバート 2018、p.84。
  44. ^ハーバー＆ヒバート 2018、85ページ。
  45. ^ハーバー＆ヒバート 2018、84～85頁。
  46. ^マグナソン 2020、32ページ。
  47. ^マグナソン 2020、33ページ。
  48. ^ハーバー＆ヒバート 2018、93ページ。
  49. ^ a bハーバー＆ヒバート 2018、96ページ。
  50. ^ハーバー＆ヒバート 2018、94ページ。
  51. ^ストラウト 2023、16ページ。
  52. ^ a b Strout 2023、18ページ。
  53. ^リビッキ、アブロン、ウェッブ、2015 年、p. 44.
  54. ^パールロス 2021、145頁。
  55. ^ Libicki、Ablon、Webb 2015、44、46ページ。
  56. ^アブロン＆ボガート 2017、8ページ。
  57. ^ a b c d Sood & Enbody 2014、42ページ。
  58. ^ストラウト2023、26ページ。
  59. ^リビッキ、アブロン、ウェッブ、2015 年、p. 50.
  60. ^ a b 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. ^リビッキ、アブロン、ウェッブ、2015 年、p. 45.
  68. ^ストラウト2023、36ページ。
  69. ^ a bハーバー＆ヒバート 2018、p.110。
  70. ^ストラウト 2023、22ページ。
  71. ^ a b 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。
「 https://en.wikipedia.org/w/index.php?title=Vulnerability_(computer_security)&oldid=1333365524」より取得