脆弱性とは ― セキュリティホールと脆弱性管理

脆弱性とは、攻撃に悪用されうる弱点のことです。OSやアプリの更新に「セキュリティ上の問題を修正」とあれば、直したのはこの脆弱性です。ソフトウェアの欠陥のほか、組織の決まりの不備や、従業員への徹底不足も含みます。

ソフトウェアの脆弱性は、塞ぐまで残ります。塞ぐには、開発元が出す修正プログラムを、利用者が適用しなければなりません。更新を後回しにした機器が狙われるのは、このためです。

バグは、プログラムの不具合です。バグがあると、ソフトウェアは作った人の意図と違う動きをします。

その不具合の中に、攻撃者に突かれて被害につながるものがあります。これが脆弱性です。ソフトウェアの脆弱性は、セキュリティホールとも呼ばれます。不具合が脆弱性になる例に、バッファオーバーフローがあります。

総務省の説明は、脆弱性の原因として、プログラムの不具合と設計上のミスの両方を挙げています。コードの誤りがなくても、設計に弱点があれば脆弱性になります。代表例はWebアプリの入力の扱いで、これを突くのがSQLインジェクションやXSSです。

情報資産は、顧客情報や人事情報など、組織が守るべき情報です。この情報資産を守る話では、脅威・脆弱性・リスクという3つの言葉が使い分けられます。

脅威が脆弱性を突くと、情報資産に被害が出ます。リスクは、その被害が起きる可能性と、起きたときの影響の大きさで表します。

脅威は、組織の側では止められないことが多いものです。脆弱性は自分たちの側にあるので、減らせます。脆弱性を減らすと、被害の起きる可能性が下がり、リスクも下がります。リスクへの対応の選び方は、リスクアセスメントの記事で説明しています。

脆弱性があるのは、ソフトウェアだけではありません。アメリカの国立標準技術研究所（NIST）の定義では、弱点があるのは情報システムだけではありません。セキュリティの手順や内部統制、実装にも弱点がありえます。

内部統制の不備は、行動規範や職務分掌が組織で整っていない状態です。職務分掌は、役割ごとに仕事と権限を分けることです。人的脆弱性は、決まりが従業員に徹底されていない状態です。人が意図的に不正をはたらく要因は、不正のトライアングルで説明できます。

シャドーITは、従業員がIT部門に知られないまま、仕事のためにIT機器やクラウドサービスを使うことです。NISTは、シャドーITが組織の管理や記録の要求を満たさないと述べています。次の事例が、どの種類にあたるかを見比べます。人的脆弱性と内部統制の不備の境目は、資料によって変わります。ここでは、決まりが無いか、決まりが守られていないかで分けます。

ソフトウェアの欠陥は、パッチで塞ぎます。残りの3つは、パッチでは塞げません。決まりの整備、従業員への徹底、使われているものの把握といった組織側の対応が必要です。

脆弱性は、見つかった時点では塞がっていません。開発元がパッチを公開し、利用者が適用して、初めて塞がります。この間に、攻撃が成り立つ期間が2つあります。

1つ目は、パッチが無い期間です。パッチが出る前に突かれる攻撃を、ゼロデイ攻撃と呼びます。総務省は、脆弱性が発見されたとき、メーカーが修正プログラムを配布する前に行われる攻撃と説明しています。NISTは、それまで知られていなかった脆弱性を突く攻撃としています。

パッチが無いため、完全な対策は難しくなります。総務省は、修正プログラムを適用するまでの間は、危険となる行為を行わないなどの注意が必要だと述べています。定義ファイルにまだ無い新しいマルウェアは、ビヘイビア法やヒューリスティック法で見つけます。

2つ目は、パッチの公開後から適用までの期間です。NISTによると、脆弱性が公に知られると、攻撃者が攻撃コードを作りやすくなります。そのため、リスクは通常高まります。

例は、2017年のWannaCryです。IPAの資料によると、Windowsの修正プログラムMS17-010は、2017年3月に公表されていました。5月に、この修正プログラムを適用していないシステムで、ランサムウェアの感染が広がりました。WannaCryは、ワームのように自ら広がるランサムウェアでした。

パッチを作る時期は、利用者には決められません。組織が短くできるのは、公開から適用までの期間です。

脆弱性を塞ぐために開発元が出す更新プログラムを、パッチと呼びます。OSのアップデートも、脆弱性を塞ぐ手段の1つです。

脆弱性は日々見つかるため、1回当てて終わりにはなりません。見つけて直すまでを繰り返す活動を、脆弱性管理と呼びます。NISTも、パッチを当てることを、脆弱性への対応の手段の1つとしています。

1. 把握する：組織が使っているソフトウェアと版を、機器ごとに一覧にします。一覧が無いと、新しい脆弱性が自分に関係するか分かりません。NISTは、一覧を常に更新するため、自動化を勧めています。
2. 集める：JVNなどの公的な情報や、開発元の情報を見ます。入手先は、後の節で説明します。
3. 判断する：深刻度だけでは決めません。IPAは、攻撃の容易さと、攻撃を受けたときの影響も考えるとしています。個人情報を持たない告知サイトと、カード情報を持つ通販サイトでは、同じ脆弱性でも影響が違います。深刻度の指標には、CVSSがあります。脆弱性診断とペネトレーションテストの記事で説明しています。
4. 適用する：いきなり全台に当てず、先に一部の機器で試します。問題が出なければ、全体へ広げます。NISTは、緊急のときも同じ流れを、日程を大きく縮めて使うよう勧めています。
5. 確認する：パッチが入り、効いていることを確かめます。そのあとも、誰かが取り消していないかを見続けます。

一覧を補強する材料に、SBOMがあります。SBOM（Software Bill of Materials）は、ソフトウェアを構成する要素と、その供給の関係を記録した一覧です。NISTによると、開発元が提供する場合は、組織の一覧の補強に使えます。

すぐには当てられないことがあります。NISTは、パッチがまだ無い場合や、開発元のサポートが終わっている場合を挙げています。テストや停止時間の調整が要る場合も同じです。

その間は、被害を減らす別の手を取ります。NISTは、脆弱性のある機能を無効にすることや、ファイアウォールやネットワークの分割で隔離することを例に挙げています。

JVNの対策情報には、開発元のパッチのほか、回避策が載ることもあります。

日本の脆弱性情報の中心は、JVN（Japan Vulnerability Notes）です。JVNは、日本で使われているソフトウェアの脆弱性と対策の情報を載せるポータルサイトです。JPCERTコーディネーションセンター（JPCERT/CC）とIPAが、2004年7月から共同で運営しています。

JVNには、国内の届出制度で調整された情報のほか、海外の調整機関と連携した情報も載ります。国内の届出の枠組みを、情報セキュリティ早期警戒パートナーシップと呼びます。届出はIPAが受け付け、開発者との調整はJPCERT/CCが受け持ちます。

1. 発見者が、IPAに脆弱性を届け出ます。
2. JPCERT/CCが、製品の開発者に連絡し、対応を依頼します。
3. 開発者が、パッチや回避策を用意します。
4. JVNで、対策情報を公表します。

公表前の情報は、細心の注意で扱われます。JPCERT/CCは、海外の機関と連携して、公表日も調整します。JPCERT/CCがどんな組織かは、CSIRTの記事でも紹介しています。

もう1つの手がかりが、CVE（Common Vulnerabilities and Exposures）です。CVEは、個別の製品の脆弱性を1件ずつ見分ける識別番号で、「CVE-西暦-連番」の形をしています。WannaCryで悪用された脆弱性の1つは、CVE-2017-0145です。

番号があると、別々の組織が出した情報が同じ脆弱性を指すと分かります。番号を付けるのは、CVEの仕組みに参加を認められた組織です。JPCERT/CCもその1つで、JVNで公表する脆弱性に番号を付けます。AWSのAmazon Inspectorは、EC2やコンテナイメージの中のソフトウェアを調べます。照らし合わせるのは、公表されたCVEです。

• 総務省「国民のためのサイバーセキュリティサイト 脆弱性とは？」（脆弱性とセキュリティホール、ゼロデイ攻撃）
• NIST SP 800-30 Rev. 1（脅威・脆弱性・リスクの定義）
• NIST SP 800-40 Rev. 4（パッチ管理、脆弱性管理の流れ、パッチを当てられないときの対応）
• NIST SP 800-124 Rev. 2（シャドーIT）
• NIST用語集 zero-day attack（以前は知られていなかった脆弱性を突く攻撃）
• IPA「脆弱性対策の効果的な進め方（実践編）第2版」（2019年2月。修正プログラム公表後の攻撃例、CVE・CVSS、対策の進め方）
• IPA「共通脆弱性識別子 CVE概説」（識別番号の形式と採番）
• IPA「ソフトウェア等の脆弱性関連情報に関する届出制度」（受付機関と調整機関）
• JPCERT/CC「脆弱性対策情報」（情報セキュリティ早期警戒パートナーシップ、調整の流れ）
• JVN「JVNとは」（運営主体と掲載する情報）