Log4jの脆弱性がDevSecOpsの重要性を浮き彫りにする理由

2021年12月、世界中のITセキュリティチームと開発組織は失礼な警鐘を鳴らしました。研究者らは、無数のJavaアプリケーションやサービスに組み込まれている一般的なロギングコンポーネントであるApache Log4jユーティリティに重大なセキュリティ脆弱性を発見しました。この脆弱性のニュースにより、ITセキュリティチームや開発組織は、自社のネットワーク上でLog4jの脆弱なバージョンのすべてのインスタンスを見つけるために奔走するようになりました。

Log4j の脆弱性により、DevSecOps チームは、現在では理論的ではないと感じられる質問に答えることを余儀なくされています。Log4jやその他の脆弱性によって社内で開発されたアプリケーションが侵害された場合、セキュリティチームは攻撃を隔離し、その被害を軽減できるでしょうか?現在のDevOpsプラクティスは、組織が独自のコードを通じて迅速かつ効果的に脅威ハンティングを行うための準備をしていますか?

Log4jの脆弱性、それがDevSecOpsチームにとって何を意味するのか、そしてIllumioのゼロトラストセグメンテーションが、脆弱なソフトウェアが修正される前に攻撃されたときにDevSecOpsチームが脅威を軽減するのにどのように役立つかを簡単に見てみましょう。

Log4j の脆弱性とその重要な理由

この脆弱性が注目を集めているのは、Log4j が Java アプリケーションで人気のある命名および検索 API である Java Naming and Directory Interface (JNDI) を使用していることに関係しています。Log4j の初期バージョンでは、JNDI のメッセージ検索置換機能がデフォルトで有効になっていました。この機能を使用すると、攻撃者は慎重に構築されたメッセージをアプリケーションに送信し、攻撃者の制御下にあるLDAPサーバーまたはその他のエンドポイントからロードされたコードをアプリケーションに強制的に実行させることができます。このコードは、マルウェアをインストールしたり、データを盗み出したり、アプリケーションのネットワーク上でその他の悪意のあるアクションを実行したりする可能性があります。

Log4jが広く使用されています。Googleは、最も重要なJavaパッケージリポジトリとして広く認識されているMaven Central Repositoryの Javaパッケージの4% に含まれていると推定しています。Log4jは、Webアプリケーションからバックエンドサービス、IoTデバイス用のカスタムアプリに至るまで、あらゆる種類のソフトウェアで使用されています。

この脆弱性が発表されるとすぐに、IT セキュリティ チームはネットワークを精査し始め、環境内の任意のディレクトリにファイル名やその他の Log4j が存在する兆候を探しました。DevOpsチームも、独自のアーカイブを検索して、独自のアプリケーションでLog4jを使用するかどうかを探すのに忙しくなりました。

賭け金は高いです。サイバー犯罪者はすでにこの脆弱性を利用してランサムウェア攻撃を開始し、企業ネットワークにコインマイニングソフトウェアをインストールし、ベルギー国防省に侵入しています。攻撃者は、この脆弱性を標的とする新しい形式のマルウェアを設計しています。たとえば、新しい Night Sky ランサムウェアは、 VMware Horizon ソフトウェアの Log4j 脆弱性を標的にしています。

全体像:ソースコードの脆弱性とそれがもたらすリスク

Log4j の脆弱性は、社内開発組織にとって 2 つの大きな問題を浮き彫りにしています。まず、DevOps ツールとプロセスがどれほどよく整理されていても、ほとんどの組織は、特にそれらのコンポーネントがライブラリとして埋め込まれている場合、または他のサービスとの依存関係を通じてアクセスされている場合、アプリケーションで使用されるすべてのコンポーネントを特定することが困難です。

たとえば、Log4jの場合、Log4j JARファイルをリポジトリに残さずに、ユーティリティをアプリケーションに含めることができます。アプリケーション内のすべてのソフトウェアコンポーネント(オープンソースであろうとなかろうと)のすべてのバージョンを見つけることは、困難で時間のかかる作業です。

次に、脆弱性が原因でアプリケーションが攻撃を受けていることが判明した場合、セキュリティチームは、攻撃がネットワーク上の他のシステムに広がる直前に攻撃を隔離する方法を必要としています。

Log4j攻撃をキャッチして阻止することは、機密データを保護し、運用の継続性を確保するためだけでなく、これらの目標は明らかに重要です。

しかし、コンプライアンスの角度もあります。2022年1月4日、米国連邦取引委員会(FTC)は、Log4jの脆弱性の結果、消費者の機密データが侵害されることを許した企業に対して罰則と罰金を科すと発表しました。

FTCは、Apache Strutsフレームワークにパッチが適用されていない脆弱性があったために消費者データを漏洩したとして Equifaxに対して7億ドルの罰金 を科したことを引用し、「将来、Log4jや同様の既知の脆弱性の結果として消費者データを公開から保護するための合理的な措置を講じていない企業を追及するために、完全な法的権限を行使するつもりだ」と発表した。

Log4j は、潜在的な脅威の巨大な氷山の一角であることが判明しました。Log4jだけでなく、自社のアプリケーションや実行しているサードパーティ製アプリケーションの ソフトウェアコンポーネント に関連する脆弱性を見つけて修正するには、企業は自社のソフトウェア環境を包括的に可視化する必要があります。データ侵害が発生する前にこれらの脆弱性を発見できなければ、規制当局に高額な罰金が科せられ、組織のブランドに永続的な損害が生じる可能性があります。

幸いなことに、DevSecOpsが役に立ちます。

ソフトウェアの脆弱性の脅威を軽減する上でのDevSecOpsの役割

DevSecOpsの背後にある考え方は単純で、ソフトウェアの開発と展開に関しては、セキュリティを後回しにすべきではありません。代わりに、設計から開発、テスト、リリース、運用管理に至るまで、DevOps のすべてのステップにセキュリティを含める必要があります。DevSecOpsは、DevOpsプロセスを通じて開発および管理されるソフトウェアアプリケーションにセキュリティを組み込む手法です。

DevSecOpsは、Log4jの脆弱性などの問題への対処にどのように役立ちますか?

まず、DevSecOpsのベストプラクティスでは、開発チームがアプリケーションを構築および管理する際に、Log4jなどのコンポーネントの更新バージョンを使用することを求めています。

第二に、DevSecOpsは、開発およびテスト組織に対し、アプリケーションで使用されるオープンソースコンポーネントを含むすべてのコンポーネントのバージョンを追跡することも求めます。これにより、IT セキュリティ コミュニティが特定のコンポーネントの脆弱性を発表した場合、DevSecOps 組織は、影響を受ける独自のアプリケーションがある場合、どのアプリケーションがあるかを迅速に判断できます。

同様に重要なことは、DevSecOpsのベストプラクティスでは、アプリケーション内にセキュリティ制御を組み込むことで、必然的に別のオープンソースライブラリやコンポーネントが脆弱であることが判明した場合に、チームはその脆弱性に対する ゼロデイ攻撃 を迅速かつ効果的に封じ込める準備を整えることができることです。防御策がすでに実施されている場合、組織は、脆弱性のパッチが数日または数週間先であっても、攻撃から防御するために行動することができます。

組み込みに最適なセキュリティ制御の1つは、システムに組み込まれているファイアウォールを使用して、ネットワークトラフィックを許可されたユーザーとプロセスのみに制限するセキュリティポリシーを適用するゼロトラストセグメンテーションソリューションです。ゼロトラストセグメンテーションは、攻撃者が利用できるネットワークパスを大幅に減らすことで、攻撃者を閉じ込め、最初に侵害できる可能性のある少数のシステムに攻撃者を隔離します。ゼロトラストセグメンテーションを導入すると、攻撃者は悪意のあるサイトからコードをダウンロードして実行できなくなります。

攻撃がネットワーク上で隔離されている場合、サイバー犯罪者はランサムウェアを他のシステムに拡散することはできません。彼らは密かにネットワークを探索して、盗み出す貴重なデータを探すことはできません。彼らは、天窓からなんとか立ち込めたがクマの罠に陥った不運な強盗のように、その場に閉じ込められています。彼らは入ったが、どこにも行かない。そして警報が鳴った。

イルミオは、DevSecOpsチームが必要とする可視性と自動化を提供します

Illumio Zero Trust Segmentation は、開発チームがネットワークやセキュリティプラクティスの複雑さを学ぶことなく、厳格なセキュリティ制御をアプリケーションに簡単に組み込むことができるため、DevSecOps組織にとって価値のあるセキュリティソリューションです。

イルミオは、開発者とセキュリティチームがゼロトラストセグメンテーションポリシーを簡単に定義できるようにすることで、アプリケーションを保護します。作成された組織は、イルミオの 仮想適用ノード (VEN)と、組織のアプリケーションが実行されているシステムにすでに組み込まれているホストベースのファイアウォールを使用して、これらのポリシーを簡単に適用できます。Illumio VENは、ソフトウェアビルドに簡単に組み込むことができる軽量でフェイルセーフなクライアントです。大規模な設計変更は必要ありません。

イルミオのソリューションはファイアウォールを使用しますが、開発者は複雑なファイアウォールルールセットをプログラムする手間を省きます。代わりに、開発者とセキュリティチームは、適用するポリシーを定義し、必要なトラフィックのみがアプリケーションを通過できるようにし、それらのポリシーをアプリケーションに埋め込まれたVENにプッシュして適用できます。

DevSecOps組織は、さまざまなアプリケーションや環境のポリシーを微調整できます。具体的には、以下に基づいてポリシーを定義できます。

• アプリケーション内の役割
• アプリケーション自体
• アプリケーションが実行される環境 (開発、テスト、運用など)
• 環境の場所: たとえば、米国西海岸のデータセンターの本番環境

次に、DevSecOpsチームは、ソフトウェアビルドにイルミオVENを追加するだけです。VENは、アプリケーション環境で実行されると、 ゼロトラストポリシーを適用し、疑わしいラテラルムーブメントを検出するとアラートを発し、アクティブな攻撃に対応してトラフィックを削減し、感染したエンドポイントをネットワークの他の部分から隔離します。

イルミオは、マイクロサービスアーキテクチャで一般的なコンテナ化された環境で使用するための C-VENクライアントとKubelinkサービス も提供しています。C-VENは軽量のイルミオエージェントで、Kubernetesクラスター内の各ノードでポッドとして実行され、ノードとその上で実行されているすべてのポッドを保護します。DaemonSet として提供される C-VEN は、クラスターの進化に合わせてスケールアップおよびスケールダウンします。Kubelinkは、Kubernetes APIサーバーを監視してクラスター内のリソースについて学習し、KubernetesコンテキストをPCEに提供するIllumioサービスです。パッケージとして提供され、クラスターごとに1つのレプリカのみを必要とするため、イルミオコンテナソリューションの拡張性が高くなります。

DevSecOpsチームは、Illumio PCEと対話するための2つの方法があります:PCEユーザーインターフェイスまたは十分に文書化されたREST APIを介して。DevSecOpsチームはAPIを使用してイルミオをCI/CDパイプラインに統合できるため、ゼロトラストセグメンテーションがDevSecOpsワークフローの標準部分になります。APIを使用すると、セキュリティチームはIllumioを他のセキュリティツールやワークフローと統合することもできます。

イルミオ製品スイートは、エンドポイントを含む、アプリケーションやサービスが展開されるあらゆる場所でゼロトラストセグメンテーションを提供します。

• データセンター: イルミオコア
• パブリッククラウド、プライベートクラウド、またはハイブリッドクラウド: Illumio CloudSecure
• エンドポイントデバイス: イルミオエッジ

Log4jは、危険な脆弱性を含むことが判明した最後のソフトウェアコンポーネントではありません。DevSecOpsプラクティスを採用し、イルミオを使用してあらゆるアプリケーションにゼロトラストセグメンテーションを適用することで、組織は、時間のかかるネットワークスキャンと脅威ハンティングの作業を継続しながら、データ、アプリケーション、および人々を保護する準備を整えることができます。

詳細については:

• ソリューション概要「 Illumio for DevSecOps」をご覧ください。
• デモについてはお問い合わせください。