piyokango氏に聞く、ハードウェア脆弱性やクラウド誤設定はどうすべき？ CISA公開リスト「KEVC」とは？――ゼロデイそして「Nデイ」対策へ：特集：1P情シスのための脆弱性管理／対策の現実解（2）

いまの時代に即した脆弱性管理／対策の在り方を探る特集「Log4j 2、クラウド設定ミスだけじゃない―1P情シスのための脆弱性管理／対策の現実解」。初回に続き、インシデント情報をまとめて記録する「piyolog」を運営するpiyokango氏に、“脆弱性”をどう認識すべきか、そして新たな情報ソースから考える脆弱性対策の在り方について聞いた。

[宮田健，＠IT]

　脆弱（ぜいじゃく）性が企業組織に与える影響は、想像よりも大きく、想像よりも“面倒くさい”状況にある。そもそも「脆弱性」という言葉の認識も、もしかしたら人によって大きく異なり、対処を想定していない脆弱性が存在する可能性もある。

　インシデント情報をまとめ記録する「piyolog」を運営するpiyokango氏は、脆弱性にまつわる事件を観測し続けてきた。前編に続き後編では、その知見から“脆弱性”をどう認識すべきか、そして新たな情報ソースから考える脆弱性対策の在り方を聞いた。

“ハードウェア”も狙われる

――徳島県つるぎ町立半田病院では、VPN機器の脆弱性が狙われ、大きな事件となりました。CPUにおける「Spectre」をはじめ、ハードウェアおよびハードウェアに近い部分の脆弱性が狙われることもあるかと思います。

piyokango氏　最近ではSpectreに似た脆弱性として、「Retbleed」も話題になっています。脆弱性対応の面から難しいと感じるのはこういったハードウェアに起因する脆弱性の情報が明らかになったとき、影響を受ける人が「当事者である」という意識を持ちにくいのではないかということです。

　ハードウェアの脆弱性が公開された場合、多くはハードウェアベンダーから修正版のファームウェアのアップデートが公開され、対応となるわけですが、利用者に直接製品を提供するベンダーと製品の開発元のベンダーが異なる場合があります。利用者に直接製品を提供するベンダーが最新のファームウェアを検証する必要があるので、利用者の手に渡るようになるまでに時間を要することも珍しくありません。そしていざアップデートが公開されたときには、対応の発端となった話題も収束していることがあり、「これはいったい何だろう？」となってしまいかねません。

　またWindowsのように自動的にアップデートされない場合は、十分な周知がされなければ利用者が脆弱性の修正を行わなかったり、対応が遅れたりすることがあります。

　つるぎ町立半田病院がランサムウェアの被害に遭ったインシデントでは、VPN機器の脆弱性に起因する可能性が指摘されていましたが、脆弱性は2019年に修正版が公開されており、さらには2021年9月にVPN機器の認証情報が流出していました。私も審査員として参加している、「情報セキュリティ事故対応アワード」ではつるぎ町立半田病院の関係者にその当時のお話を伺っています。

• 【第7回】情報セキュリティ事故対応アワード | TECH+（テックプラス）
• 災害対応訓練がランサムウェア被害にも活きた - 徳島・半田病院に学ぶBCPの重要性[事故対応アワード受賞] | TECH+（テックプラス）

　このインシデントで課題を1つ挙げるとすればVPN機器を含む保守対応を明確にしておくべきだったという点です。当事者間において契約範囲や責任の分界点など十分に整理、検討されていなかったのではないかと推察しますが、このインシデントの以前も保守管理が十分ではない機器に起因したセキュリティインシデントがたびたび起きており、つるぎ町立半田病院も特異な事例ではないと思います。このインシデントを踏まえ、自組織で適切な時期に把握すべき情報を受けて担当者が対応できているかどうかについて“点検”すべきではないでしょうか。

　またハードウェアの脆弱性情報はポータルサイトにログインして見に行かねばならなかったり、保守契約を結んでいないと情報を入手できなかったりとさまざまでしょう。代理店とのコミュニケーションが必要になることもあります。「検索して出てくる」というものばかりでもありません。脆弱性情報における「コミュニケーションチャネルが正しく機能しているか」について先ほどの“点検”に加えていただきたく思います。

　つるぎ町立半田病院のインシデントが起きてから、幾つかのセキュリティインシデントが他の病院でも発生しています。幸いにして、つるぎ町立半田病院のように医療サービスへの長期間の影響が発生しているわけではなく、もしかしたらこのインシデントが「ウチは大丈夫なのか？」という波紋を呼び、興味関心を引き、事前の準備につながったのかもしれません。インシデントの対応に追われていたにもかかわらず、他の組織が参考にできる情報量を、メディアなどを通じて積極的に公開を進めたつるぎ町立半田病院の取り組みは素晴らしかったと思います。

――ソフトウェアとハードウェアで、対応や心構えに違いがありますか？

piyokango氏　最近では、WindowsやWebブラウザなどの主要なソフトウェアでは脆弱性を修正するアップデートが自動化され、利用者が意識せずにセキュアな状態が保たれるようになりました。ハードウェアに目を向けると、同じように利用者に意識させない流れが来つつあるように感じます。

　例えばブロードバンドルーターでも、ファームウェアのアップデートが自動更新されるようになっている製品が増えました。国内大手の製品なら、初期の管理者パスワードも一律固定ではなく、製品固有のパスワードが設定されているものが大半ではないでしょうか。過去の悪用事例に学ぶ取り組みが、ここでも進められています。

　一方で利用者は「今、動いているのならば、そのままでよい」と思われることも多いでしょう。利用者視点に立てば「面倒」とも思えるアップデートを積極的に行うモチベーションはありません。さらにこの手の機器は、正常に動作している場合、攻撃者何らかの不正な動作をしていても気が付くことはできません。その点においては、ハードウェアは問題発生への気付きや適切な管理が難しいと感じます。特に家庭用機器では正常に動作することが優先され、セキュリティは二の次になりがちだからです。

　このようなハードウェアの脆弱性が積極的に狙われる状況は今後も続くだろうと思います。最新のWindowsなら、何らかの脆弱性が存在した場合に悪用される影響を緩和する対策が進んでおり、攻撃者が脆弱性を使って攻撃を成立させること自体が難しくなっているからです。

――テレワークにおいて、逼迫（ひっぱく）したVPNリソースをカバーするために、古い機器を取り出したことが攻撃のきっかけになった事例もありました。

piyokango氏　多くの組織でVPN機器の脆弱性に起因するインシデントが発生しましたが、その中でも平田機工が被害に遭ったインシデントは学ぶべき点があります。平田機工では、もともと脆弱性対応が済んでいたVPN機器を使用していたのですが、テレワーク利用に対する負荷分散のために、以前使用していた取り換え前の旧機器を、脆弱性を修正せずに急きょ稼働させたことで、約2カ月後に情報流出の被害に遭ってしまいました。「脆弱性を修正していない機器はすぐ狙われる」という現状については改めて認識しなくてはなりません。

ハッキングフォーラムへ投稿された多数のVPNサーバーの認証情報についてまとめてみた - piyolog

クラウド設定ミスは「脆弱性」か？

――昨今では、クラウドサービスの設定ミスが元で、情報が意図せず公開される事例も多く報告されています。

piyokango氏　クラウドサービスを使えば容易に情報処理や共有が可能となり、今や欠かせないものとなった半面、扱い方を間違えると、意図しない人にも“共有”されてしまう情報漏えいが発生します。過去には「Trello」やSalesforceのサービスでも、設定不備に起因した情報漏えいが発生しました。

Salesforceの設定不備に起因した外部からのアクセス事案についてまとめてみた - piyolog

　このような設定不備に起因したインシデントが起きた際、サービス提供者と利用者の間で問題の所在から認識合わせが開始されることも起こり得ます。設定不備で起きた問題はサービスの「脆弱性」と扱われるのか、利用者の「不注意」だったのか。お互いの認識の隔たりが大きければ、早急にすべき対応に時間を要してしまいかねません。クラウドサービスは提供する事業者が脆弱性を修正しますので、セキュアな状態が保たれますが、機能も追加、変更されていくので利用者もその内容を把握しておく必要があります。「気が付いたら変わっていた」とならないよう、サービスを提供する事業者と利用者間のコミュニケーションは特に重要です。

　さらに利用者においても、組織における脆弱性対応として、このような機能変更に起因した問題が確実に含まれるのかどうかを懸念しています。これは主観ではありますが、クラウドサービスの設定に起因する問題は、顕在化すればインシデントとして扱われる可能性はあるものの、未然に防止するために「脆弱性」として捉え、情報を収集、対応している組織は多くないのではないかと思っているからです。

CISAが公開するリストに注目せよ

――最近、CISA（米国のサイバーセキュリティ社会基盤安全保障庁）の「既知の悪用された脆弱性一覧」が注目されていますね。

piyokango氏　CISAが、2021年11月3日から運用を始めた「Known Exploited Vulnerabilities Catalog」（既知の悪用された脆弱性一覧：以下、KEVC）は、CISAが悪用を認識した脆弱性をまとめたリストです。「重大なリスクのある脆弱性のうち、既知のものを適切に対応せよ」という目的で行われている、「Binding Operational Directive 22-01」に伴う強力な取り組みです。ここには「Due Date」も設定されており、米国政府機関は指定された日までに脆弱性への対応を済ませることが求められます。

　CISAは脆弱性の悪用を確認してから24時間以内に、カタログに追加するように運用しています。現在（2022年8月のインタビュー時点）では794件の脆弱性が含まれており、「Adobe Flash Player」「Microsoft Silverlight」を含む、数年以上前に公表された脆弱性もリストアップされており、悪用を確認されている脆弱性に対して、ある程度の網羅性をもって対応状況を確認する際に参考となるのではないでしょうか。

――「特に、ここを見てほしい」という点はありますか？

piyokango氏　「Binding Operational Directive 22-01」には、このリストに関するFAQが記載されており、「CISAがどのようにカタログを運用しているか」についての考え方が述べられている一節があります。これまでも共通脆弱性評価システム「CVSS」（Common Vulnerability Scoring System）をはじめ、脆弱性を評価する指標がありましたが、脆弱性の対応では、情報の入手で終わるのではなく、その後「どう判断して対応すべきか」が重要です。ただでさえ日々公表され、大量にある脆弱性情報の中から優先して対応すべきものがどれなのか、トリアージに対する考え方は画一的な解はなく、専門家も悩む部分です。

　CISAは先のFAQで「2019年以降の脆弱性のうち、悪用されているのはCVE（Common Vulnerabilities and Exposures）総数の4％未満」というデータを提示しています。「悪用されているかどうかがトリアージの観点として重要だ」と、このFAQで述べているのです。

「重要かつ高度の脆弱性と既知の悪用される脆弱性、どちらを先に修正することがより重要か？」という点に関し、KEVCの元となる「Binding Operational Directive 22-01」では「既知の悪用された脆弱性を最優先にすべし」と回答している

　KEVCの公開当初はリストに追加される判断基準がブラックボックスでしたが、FAQが追記され、これまで私の中で疑問に思っていた点が解消されました。KEVCは既に多くの識者から注目されている情報ですが、これを単に「便利リスト」と捉えるだけでは「もったいない」と思います。ぜひ、このFAQ部分も踏まえてご活用いただきたいと思います。

――KEVCを見る上で、他に注意点はありますか？

piyokango氏　実はそのFAQを見ると分かるのですが、KEVCに掲載されるには「CVEが採番されていること」「悪用されているという信頼できる情報や認識があること」、そして一番重要なのは「更新プログラムが公開されていること」が条件です。裏を返せば、「ゼロデイ」と言われるような、修正する手段が存在していない脆弱性は掲載されません。

　最近話題になった「Microsoft Support Diagnostic Tool」（MSDT）に関する脆弱性「CVE-2022-34713」は2022年8月9日にKEVCに掲載されましたが、この脆弱性は6月初旬には話題になっていたので、しばらくの間KEVCに掲載されない時期があったことが分かります。そのため、KEVCだけを見てしまうと、このような脆弱性の対応で後れを取ります。その点においても、FAQをしっかり読んでいただき、カタログに追加される条件や考え方を知っておいた方がよいでしょう。

　また、このリストは米国機関が出しているものです。日本では「JVN」（Japan Vulnerability Notes）といった脆弱性関連情報をまとめたサイトもありますが、個人的には日本国内で主に利用されているソフトウェアの脆弱性をまとめた、「日本版KEVC」があってもよいのではないかと思っています。

ゼロデイ、そして「Nデイ」――もう一度脆弱性を取り巻く自社環境を見直そう

――脆弱性の対策で、企業、組織に見直してほしい部分はありますか？

piyokango氏　アイティメディアで開催するセミナーでも繰り返し触れていますが、脆弱性の対策や管理が「硬直化」していないかどうかについて現状を点検してほしいと思います。

　淡々と対応できる仕組みが作られている組織もあると思いますが、脆弱性管理を「パッチ管理」と捉えてしまうと、ソフトウェアの脆弱性を修正することのみが目的となってしまい、VPN機器などハードウェアや、クラウドサービスの設定に起因する問題など、「パッチ管理」の範囲に入ってこない可能性のある“広義の脆弱性”が漏れてしまいかねません。今回のインタビューでは度々「点検」とうるさく言っていますが、そこもぜひご確認いただきたいと思います。

　また、未知の脆弱性を悪用する「ゼロデイ攻撃」以上に、修正パッチが公開された後パッチを適用するまでの期間に攻撃を受ける「Nデイ攻撃」への対策をより意識していただきたいと思います。今では修正パッチの解析から攻撃方法を検証する動きなど、既知となった脆弱性が積極的に研究されていますが、先ほど取り上げたトリアージを誤れば、このNデイ攻撃を受ける可能性が長期に及びます。脆弱性情報と「悪用されている」という情報を適切に入手し、状況に応じたトリアージを可能とする体制を整え、必要ならばやはり対応を早めるなどの判断ができるように備えておく必要があるでしょう。

特集：Log4j 2、クラウド設定ミスだけじゃない―1P情シスのための脆弱性管理／対策の現実解

Log4j 2の件を端に、再び世間を騒がせたソフトウェアの脆弱性問題。だが、もともと脆弱性というものは、OSSに限らず、商用ソフトウェア、ルーターやメモリなどのハードウェアと、あらゆるところに存在する。パッチを当てるなどの対策を施しても、減るどころか日々新たな脆弱性が発見されて増え続けるような報道が後を絶たない。むしろクラウドの設定ミスやコーディングミス、テスト不足など、人が新たな脆弱性を次々と作り出しているといっても過言ではない。人手が足りない企業の情報システム部門は日々の安定運用に手いっぱいで、脆弱性を管理して対策を講じるところまで頭が回らないのが実情ではないだろうか。本特集では、脆弱性を取り巻く現状を改めて整理し、今の時代に即した脆弱性管理／対策の在り方を探る。

特集：Log4j 2、クラウド設定ミスだけじゃない―1P情シスのための脆弱性管理／対策の現実解