Special Feature
Log4j騒動から見る脆弱性対策 国内企業は取り組みの遅れが明らかに
2022/03/14 09:00
週刊BCN 2022年03月14日vol.1914掲載

2021年11月にJavaのロギングライブラリ「Apache Log4j(以下Log4j)」に深刻な脆弱性、通称「Log4Shell」が発見された。Log4jはログ出力などを目的に利用されるライブラリで多くのIT製品に組み込まれていることから、Log4Shellを悪用した攻撃によるセキュリティ事故の増加が懸念された。しかし、早期にLog4jのアップデートが行われたことなどから、現時点では、国内で目立った事故は確認されていない。最悪の事態は免れているものの、セキュリティベンダーは、今回の騒動で国内企業の関心の低さや対応の遅れが明らかになったと指摘し、対策の強化を促している。
(取材・文/岩田晃久)
目立った被害は確認されず
Log4jは、Webアプリケーションサーバーやデータベース、セキュリティ製品、クラウドサービスなど多くのIT製品で利用されている。ユーザーは最初からLog4jが組み込まれている状態で製品を利用していることから、社内システムでどれだけLog4jが使用されているのか把握できないケースが大半だった。Log4Shellが危険視された理由として、リモートから悪意のあるコードを実行できることが挙げられる。そのため、多くの企業の社内システムに点在するLog4jに対し、攻撃者が容易に攻撃を仕掛けることができるとされた。実際、共通脆弱性評価システム「CVSS」で、Log4Shellの深刻度が基準値最大の10.0に設定されたことからも、近年まれに見る高リスクの脆弱性だということが分かる。
海外では、Log4Shellが発見された直後、ランサムウェア攻撃や認証情報の搾取といった攻撃が確認された。国内でもセキュリティインシデントの発生が懸念されたが、情報処理推進機構(IPA)とJPCERTコーディネーションセンター(JPCERT)は、ともに「現時点では国内でLog4jの脆弱性が原因とされる攻撃被害の報告や相談は受けていない」と語る。
その要因として、Log4Shellが発見された後、すぐにJavaから修正版がリリースされたことが大きい。このバージョンアップにより、攻撃者が用意した任意のJavaコードの実行をいったんは阻止できるようになった。その後、さらなる脆弱性が明らかになったものの、都度バージョンアップを実施し対応を強化した。大々的に報道されたことで、ユーザーがいち早くこのバージョンアップを実行したことも被害の拡大を食い止めた要因として考えられる。
だが、JPCERTは「Log4jの一連の脆弱性は、攻撃手法によってはシステムに侵入してからユーザーが気づくまで、ある程度の時間を要する場合があると想定される。何か被害が生じた際に、それがLog4jの脆弱性に起因するものだったのか否か、判然としないケースもある。今後、時間の経過とともに被害が発覚する可能性もあるのではないか」としている。
診断ツールを活用して早期発見を
Log4Shellへの対応を迫られる中で明らかになったのが、国内企業の脆弱性対策が不十分だということだ。脆弱性管理ツールを提供する米テナブルネットワークセキュリティは、Log4Shellが発見された直後、ユーザーからの要望を受けて各製品を機能拡張し、社内システムに点在するLog4Shellを発見できるようにした。
貴島直也
カントリーマネージャー
日本法人のテナブルネットワークセキュリティジャパンの貴島直也・カントリーマネージャーは「グローバルでは当社の製品を利用して5000社以上が社内システムからLog4Shellを発見した。これはあくまでも初期段階での数字だが、多くの場所でLog4jが利用されていたことが分かる。一方で、国内企業は欧米に比べて問い合わせが極端に少なかった。脆弱性対策への関心が低く、取り組みが遅れているということだろう」と分析する。
また、手作業で社内システムからLog4jを洗い出している企業も少なくないことを挙げ、「Log4jが使用されている製品は無数にあるため、手作業で洗い出すことは現実的ではない。脆弱性診断ツールを有効活用するべきだ」と話す。
同社は、クラウド型脆弱性管理サービス「Tenable.io」やActive Directoryのリスクを可視化する「Tenable.ad」など複数の脆弱性対策ツールを提供している。システムによって潜んでいる脆弱性の特徴は異なるため、環境に沿った対策を施すことを推奨している。
貴島カントリーマネージャーは「年に一度、脆弱性診断サービスなどを利用するだけで、その他には何も対策をしていない企業が多いのが国内の傾向だ。年に一度の診断だけでは脆弱性を取り除くことはできず、社内システムに多くのセキュリティホールが存在することになる。攻撃者は既知の脆弱性を発見した際には、すぐに攻撃してくるため、常に脆弱性を見つけ対処できる体制を整えなければならない」と警戒を求める。
DevSecOpsの実現が急務
開発の際に用いられるLog4jで脆弱性が見つかったことで、多くのITベンダーがその対応に追われた。実際、Log4Shellに対応するパッチを適用するまでの間、製品の販売や利用を中止するなどビジネス面で大きな影響を受けたベンダーも多い。
松岡正人
シニア・プロダクト・マーケティング・マネージャ
アプリケーションテストツールなどを提供する米シノプシスの日本法人である日本シノプシスのソフトウェア・インテグリティ・グループの松岡正人・シニア・プロダクト・マーケティング・マネージャは「安全だとされていた製品などから突然、脆弱性が発見されるのは多くあることで、今回のLog4Shellもそのケースだ。(売り上げへの影響など)マイナス面が大きいのは事実だが、見つかったことで、脆弱性が放置されず対策を施せたという点を重視するべきだ」との見解を示す。
同社は、Log4Shellをはじめとしたオープンソースソフトウェア(OSS)の脆弱性対策としてOSS管理ソリューション「Black Duck」の利用を促進している。Black Duckは、脆弱性がソフトウェアのどこに含まれているかを洗い出して可視化できるという。松岡マネージャは「Log4Shell以外にもOSSの脆弱性は多いため、開発段階で把握し対策しなければならない」と注意を促す。
最近では、ソフトウェア開発ライフサイクルのすべてのフェーズにセキュリティを組み込む「DevSecOps」が重要視されているが、松岡マネージャは「まだ言葉だけが先行している状況で、DevSecOpsを実現できている現場は少ない。今回の騒動で、開発環境でのセキュリティの重要性が浮き彫りとなったことから、ベンダーやSIerは開発でのセキュリティ対策に本腰を入れる必要がある」とみる。
DevSecOpsを実現するには、セキュリティ確認のプロセスを、開発工程の早い段階に組み込む考え方「シフトレフト」が必須となる。同社は、Black Duck以外にも、セキュリティテストの自動化を支援する「Intelligent Orchestration」やセキュリティテストの結果からリスクを優先付けし可視化する「Code Dx」といったツールを提供している。これらを活用することで、シフトレフトに沿いながらスピーディーな開発が行えるとしている。
松岡マネージャは「米国では各種ガイドラインにより、セキュリティ基準を満たさない製品は販売できないことも多くある。今後は、日本でもグローバル基準での対応が求められるケースが出てくる。セキュアな開発現場を実現することが競争力の向上にもつながる」と強調する。
Webアプリケーション保護を強化
脆弱性対策も重要だが、防御策を強化することがセキュリティの基本だ。Log4Shellが発見された後、システム精査をしている間に攻撃を受ける可能性もあったため、ゲートウェイセキュリティの強化やEDR(Endpoint Detection and Response)やNDR(Network Detection and Response)を活用し攻撃をすぐに検知できる体制を整えることが有効とされた。特に脆弱性が多いソフトウェアとして、Webアプリケーションが挙げられる。ビジネスにおいてWebアプリケーションの利用が当たり前となり、年々、新たなWebアプリケーションが誕生しているが、それに伴い脆弱性が急増している。
Webアプリケーションのセキュリティ対策で一般的に用いられるのが、Webアプリケーションファイアウォール(WAF)である。だが、オンプレミスのWAFはシグネチャの設定など運用負荷が高い製品とされており、実際、導入したものの、シグネチャの設定ができておらず、サイバー攻撃の被害に遭ったケースも少なくない。そういった中で、近年、市場が拡大しているのがクラウド型WAFだ。
クラウド型WAF「攻撃遮断くん」やパブリッククラウドが提供するWAFの運用を自動化する「WafCharm」を提供するサイバーセキュリティクラウドでは、Log4Shellが発見された直後に、シグネチャを更新し対応した。クラウド型WAFのメリットとして、ユーザーは自社でシグネチャの設定することなく、最新の状態のWAFを自動で利用できる点がある。
渡辺洋司
代表取締役CTO
渡辺洋司・代表取締役CTOは「最初のシグネチャを出した後も、WAFを回避する攻撃手法が確認されるなど状況が変化したため、その都度、シグネチャを更新した。最新の対策をすぐにユーザーに提供できるクラウド型の強みが生きたケースだった」と語る。
その上で、以前、JavaのWebアプリケーションフレームワーク「Apache Struts2」で深刻な脆弱性が見つかり、セキュリティ被害を受けた企業が出たことに触れ「Webアプリケーションの脆弱性は常に生まれており、対策し続けていかなければならない。ユーザー自身で対応が難しい場合はベンダー側に運用を任せることが有効だ」とアドバイスする。
Log4Shellは騒動となったものの被害が確認されていないことで、安心している企業も多い。しかし、当然ながら油断は禁物である。今後より深刻な脆弱性が見つかる可能性は十分にあるだろう。多くのサイバー攻撃は脆弱性を突いたものになるため、脆弱性対策を強化し、セキュアな社内システム環境の構築に取り組むべきである。

2021年11月にJavaのロギングライブラリ「Apache Log4j(以下Log4j)」に深刻な脆弱性、通称「Log4Shell」が発見された。Log4jはログ出力などを目的に利用されるライブラリで多くのIT製品に組み込まれていることから、Log4Shellを悪用した攻撃によるセキュリティ事故の増加が懸念された。しかし、早期にLog4jのアップデートが行われたことなどから、現時点では、国内で目立った事故は確認されていない。最悪の事態は免れているものの、セキュリティベンダーは、今回の騒動で国内企業の関心の低さや対応の遅れが明らかになったと指摘し、対策の強化を促している。
(取材・文/岩田晃久)
目立った被害は確認されず
Log4jは、Webアプリケーションサーバーやデータベース、セキュリティ製品、クラウドサービスなど多くのIT製品で利用されている。ユーザーは最初からLog4jが組み込まれている状態で製品を利用していることから、社内システムでどれだけLog4jが使用されているのか把握できないケースが大半だった。Log4Shellが危険視された理由として、リモートから悪意のあるコードを実行できることが挙げられる。そのため、多くの企業の社内システムに点在するLog4jに対し、攻撃者が容易に攻撃を仕掛けることができるとされた。実際、共通脆弱性評価システム「CVSS」で、Log4Shellの深刻度が基準値最大の10.0に設定されたことからも、近年まれに見る高リスクの脆弱性だということが分かる。
海外では、Log4Shellが発見された直後、ランサムウェア攻撃や認証情報の搾取といった攻撃が確認された。国内でもセキュリティインシデントの発生が懸念されたが、情報処理推進機構(IPA)とJPCERTコーディネーションセンター(JPCERT)は、ともに「現時点では国内でLog4jの脆弱性が原因とされる攻撃被害の報告や相談は受けていない」と語る。
その要因として、Log4Shellが発見された後、すぐにJavaから修正版がリリースされたことが大きい。このバージョンアップにより、攻撃者が用意した任意のJavaコードの実行をいったんは阻止できるようになった。その後、さらなる脆弱性が明らかになったものの、都度バージョンアップを実施し対応を強化した。大々的に報道されたことで、ユーザーがいち早くこのバージョンアップを実行したことも被害の拡大を食い止めた要因として考えられる。
だが、JPCERTは「Log4jの一連の脆弱性は、攻撃手法によってはシステムに侵入してからユーザーが気づくまで、ある程度の時間を要する場合があると想定される。何か被害が生じた際に、それがLog4jの脆弱性に起因するものだったのか否か、判然としないケースもある。今後、時間の経過とともに被害が発覚する可能性もあるのではないか」としている。
この記事の続き >>
- 診断ツールを活用して早期発見を
- DevSecOpsの実現が急務
- Webアプリケーション保護を強化
続きは「週刊BCN+会員」のみ
ご覧になれます。
(登録無料:所要時間1分程度)
新規会員登録はこちら(登録無料) ログイン会員特典
- 注目のキーパーソンへのインタビューや市場を深掘りした解説・特集など毎週更新される会員限定記事が読み放題!
- メールマガジンを毎日配信(土日祝をのぞく)
- イベント・セミナー情報の告知が可能(登録および更新)
SIerをはじめ、ITベンダーが読者の多くを占める「週刊BCN+」が集客をサポートします。 - 企業向けIT製品の導入事例情報の詳細PDFデータを何件でもダウンロードし放題!…etc…
- 1
