Log4j問題は大したことなかった？ 脆弱性対応はスプリント＆マラソン？ SBOMで解決？――piyokango氏に聞いた：特集：1P情シスのための脆弱性管理／対策の現実解（1）

いまの時代に即した脆弱性管理／対策の在り方を探る特集「Log4j 2、クラウド設定ミスだけじゃない―1P情シスのための脆弱性管理／対策の現実解」。初回は、インシデント情報をまとめて記録する「piyolog」を運営するpiyokango氏に、昨今のインシデントを基に、いまそこにある問題点や「企業がどう対策すべきか」について聞いた。

[宮田健，＠IT]

　オープンソースソフトウェア（OSS）の利用が当たり前になった今、“脆弱性”情報をいち早く押さえることは非常に重要だ。その対応の早さが企業の存続をも左右するようになっている。システムの脆弱（ぜいじゃく）性を考えたとき、現在ではソフトウェアの脆弱性だけでなく、ハードウェアに近い部分の脆弱性、設定に起因するグレーゾーンの脆弱性、そして組織の脆弱性も考えていかねばならない。

　多種多様な脆弱性に対応するには、公開された情報を基に、企業そして情報システム部門などの現場の担当者がそれをどう生かすかに焦点が当たっている。そこで、インシデント情報をまとめて記録する「piyolog」を運営するpiyokango氏に、昨今のインシデントを基に、今そこにある問題点や「企業がどう対策すべきか」について聞いた。

脆弱性は終わらない

――脆弱性に関する事件が次々と明らかになっています。最近、piyokangoさんの印象に残る、特徴的な脆弱性はありますか？

piyokango氏　最近の事例とはもう言えないかもしれませんが、やはり「Apache Log4j 2」（以下、Log4j）の脆弱性（CVE-2021-44228）に関連する状況を挙げたいと思います。この脆弱性は2021年末に大きく注目され、テレビや新聞などのメディアでも広く取り上げられました。

Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog

　2021年12月の公表直後には、脆弱性を悪用する活動に関連した観測情報もありましたが、この脆弱性に関連したインシデントは多くありませんでした。多くの方の尽力により、真っ先に狙われる、インターネット上に公開されたシステムへの対応が迅速に行われた成果だと思います。

　では、なぜ私がそれを“最近”として取り上げたのかというと、このLog4jに関する脆弱性の影響は、今もなお続いているからです。米国のサイバーセキュリティインフラセキュリティ庁（CISA）がLog4jの脆弱性に関連するアドバイザリーを2022年6、7月と続けて出しています。「脅威アクターによってLog4jを悪用したシステムへのサイバー攻撃が依然として続いているので、警戒せよ」と注意喚起したものです。

CISA Releases Log4Shell-Related MAR | CISA

　思い返すと、SANS Technology Institute（以下、SANS）の研究者（Johannes Ullrich氏）が、2021年12月にLog4jの脆弱性がいったん落ち着いたタイミングで、「Log4jへの対応はマラソンのようになる。そのように考えよう」とコメントしたことが記憶に残っています。Log4jはライブラリであり、「システムの中のどこで使われているか」を特定することが重要ですが、Log4jが内包されているシステムを漏れなく見つけ出す必要がある場合は時間も相応に要してしまうこともあります。その意味で“マラソン”と表現したのかもしれません。

　CISAの注意喚起を見ると、Log4jそのものではなく、その脆弱性を悪用した「VMware Horizon」「VMware Unified Access Gateway（UAG）」への攻撃に警戒せよという内容になっています。これら脆弱性の修正自体は2022年1月にパッチが公開されましたが、これを適用できていない組織が攻撃を既に受けている可能性があるのです。CISAがこのような内容で注意喚起を2回にわたって出すということは、より深刻な被害につながりかねない状況が発生しているのではないかと推測できます。

――対応が進む組織、対応が遅れる組織が二分化しているという印象です。

piyokango氏　対応が遅れてしまう組織は、脆弱性に関して「知らなかった」という場合もあれば、「知っていて、優先順位が低かった」という場合もあるでしょう。仮に知っていた場合でも、まさに今のように脆弱性に関連する情報が落ち着いてしまったことで「攻撃も既にやんだ」と誤解したり、対象のシステムがインターネットにつながっていなかったりすることで、「パッチ適用の優先度は下げてもよい」「月次や四半期ごとといった定期的な対応でよい」と判断してしまう場合もあるのではないでしょうか。

　しかし今では、他の手段で社内システムの境界内に入り込み、その後内部のネットワーク上に存在する脆弱性を狙う攻撃もあるわけです。

「スプリントレース」から始まり「マラソン」に続く

――社内システムの対応が遅れる場合も多いでしょうね。

piyokango氏　Log4jの対応も「業務を止めてでも社内システムにすぐさまパッチを当てる」という判断ができた組織がどれほどいただろうかとは改めて思います。先ほども述べたようにLog4jの脆弱性が公表された当初、脆弱性のスキャン活動の報告は多数あったものの、深刻な被害報告は、国内で公表された事例がなく、海外でも散見されていた程度だったので、一過性の騒ぎとして「結局Log4jの脆弱性は大したことなかった」と思っている方もいるかもしれません。

　ただ、CISAが今も注意喚起を出している状況を踏まえれば、その評価は結果的に「誤りだった」と言えます。特に業務影響の懸念から対応に時間を要した組織では、「仮に業務に影響が出る可能性があっても対応を優先するという過酷な判断をするために、どのような情報が本当に必要だったのか」について答え合わせしながら振り返るべき点があると思います。

　OSSの話からは外れますが、発生から5年たった「WannaCry」も、ソフトウェアの脆弱性を悪用して拡散します。「この脆弱性の影響を受けるとみられるシステムは今も複数存在している」という報告があります。特に、広く利用されているソフトウェアにおいて「全ての組織が対応を完全に済ませる」という状況に近づけるのは本当に難しいと思います。

――まさに「マラソン」という考え方ですね。

piyokango氏　一方で脆弱性の初動対応は、まさに「スプリントレース」と言えるものです。特定の脆弱性の話が注目されると、「他に問題がないか」と深掘りして調査されることがあります。「ShellShock」とも呼ばれたBashの脆弱性（CVE-2014-6271、CVE-2014-7169）でも見られたものですが、「修正パッチが公開された後に、その修正内容が有志によって精査され、別の方法で修正が回避できてしまうことが判明する……」といった具合に、問題の発見と修正の公開がしばらく繰り返されることがあるのです。立て続けに行われる、脆弱性のさらなる発見と修正が落ち着くまで“スプリントレース”で全力疾走するような期間がしばらく続くわけですね。

　“スプリントレース”後は、業務システムなどインターネットに直接接続しているかどうかにかかわらず、全てのシステムへの確実な対応が必要となります。ここから、マラソンが始まります。

SBOMで解決できるか？　「管理」とまではいかなくても――今、私たちにできることは？

――マラソン状態に備えるには、どうしたらよいのでしょう？

piyokango氏　この“マラソン”を走り切るのは並大抵のことではありません。Log4jでも問題になりましたが、システムの構成を詳細に把握している人は多くないと思います。これまでのITmediaのセミナーでもたびたび触れていますが、「OSSをはじめ社内で利用しているソフトウェアは何か」を把握することは重要だとだとお話ししてきました。

　今、SBOM（Software Bill of Materials：ソフトウェア部品表）が注目されていますが、SBOMを運用し、外注するなら仕様書に入れられるかどうかも重要なことだと思いますし、入れられたとしても費用が増える可能性が考えられます。ただ「SBOMを取り入れれば解決だ、これを導入しよう！」と声高に叫ぶだけでは、頓挫する可能性があるのです。一方で、SBOMのようなソフトウェアのリストがなく、自社とベンダーの双方が何を使っているか把握し切れていない状況では、対応が遅れがちとなります。攻撃側はそのような隙を見逃しません。

　こういった状況に陥ることを回避するためにも、繰り返しになってしまいますが「まずは自分が使っているものに対して、興味、関心を持つ」ことが大事ではないかと思います。すぐに「漏れなく確実な管理」まではできなくても、自分が今の業務で使っている、重要なシステムに対してだけでも、「管理の一歩手前」として、自分たちが使っているものを知っておくことに損はないのではないでしょうか。

――脆弱性は、OSSだけにあるものではありません。後編に続きます。

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

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

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