非常に多くのセキュリティチームと開発者チームが、クリスマスのちょうど10日前の2021年後半に発生したLog4jセキュリティ脆弱性の大失敗について事後分析を行っているため、主な質問は、将来この種の痛みをどのように回避するかということです。残念ながら、その答えは…複雑です。
必読のセキュリティカバレッジ
認定サイバーセキュリティ専門家の世界最大の非営利団体である（ISC）2の新しいデータによると、サイバーセキュリティチームのほぼ半数（48％）が、修復を支援するために休日と週末をあきらめ、チームの52％が「数週間以上」を費やしました。 」Log4jを修正します。すでに拡大している開発者が休暇を過ごしたいと思っていた方法とは異なります。
ただし、その経験の苦痛が、開発者やセキュリティチームからの主要なソフトウェアサプライチェーンセキュリティの再考を引き起こしました。
レガシーコードを壊さずに脆弱性を修正する
Log4jの最も厄介な側面の1つは、脆弱性自体ではなく、テクノロジーがレガシーコードにどれほど深く組み込まれているかでした。結局のところ、Javaは世界で最も人気のあるプラットフォームの1つであり、Log4jは非常に人気のあるJavaロギングシステムであり、その最初のリリースは2001年までさかのぼります。したがって、Log4Jは、大量の実稼働システムだけでなく、多くのレガシーにも影響を与えます。コード。
「誰もレガシーコードに触れたくない」と、オープンソース統合テストフレームワークであるTestcontainersの背後にある新しいスタートアップであるAtomicJarのCEOであるSergeiEgorovは述べています。 「セキュリティの脆弱性を修正するだけでなく、システムを壊すことなく脆弱性を修正したことを知っておく必要があります。 Log4jのような非常に人気のあるロギングライブラリに脆弱性がある場合、通常はテストが不足しているレガシーコードへの依存関係について話していることになります。また、コードを記述してその動作を理解している開発者が会社でさえ機能しない場合もあります。もう。」
Egorovによると、Log4jは、更新が必要な他のライブラリの推移的な依存関係であることがよくあります。静的バイナリを提供するプラットフォームとは異なり、Javaシステムでは、コードのリンクは実行時に行われるため、実際に実行して依存関係と依存関係の間のリアルタイムのリンクをテストするまで、アプリケーションが正しく動作することを100％確信する方法はありません。コンパイル。
エゴロフ氏によると、Log4jは、本番環境への展開に先立ってこれらの相互作用をテストする方法として、すでに人気のあるTestcontainersプラットフォームへの関心を加速させています。彼は、Log4jに悩まされていた開発者が、システムと外部の依存関係の間の統合テストを作成していることを確認しました。これにより、次にセキュリティの脆弱性が発生したときに、開発者は、展開時に修正プログラムが本番システムを停止しないことをテストできます。テストコンテナはSnykとの人気のある組み合わせになりつつあります。これは、開発者が自動化されたセキュリティリクエストのプルリクエストを取得でき、統合テストにより、何も壊さずにマージできるという自信が得られるためです。
どちらが悪いですか…脆弱性またはユーザーの混乱？
Log4jのセキュリティの脆弱性の到来と、ホリデーシーズンのピーク時のそのひどいタイミングは、開発者チームにとって厄介な選択を生み出しました。今すぐ修正を展開し、ホリデーのピークeコマースサイクル中にシステムを停止するリスクを冒すか、商業的リスクの低い間隔で修正の展開をパントします。 ？
適切なコンテキストがないと、決定を下すことは不可能です。
「Log4jは、修正がユーザーに与える影響を予測する方法がなかったため、多くのエンジニアリングチームをパニックに陥れました」と、ソフトウェア信頼性スタートアップNobl9のCEOであるMarcin Kurcは述べています。このスタートアップの顧客には、大規模な電子小売業者が含まれています。 「セキュリティ修復で実行する必要のある費用便益分析があります。修正を展開するための適切な間隔を決定する必要があります。これには、影響を与える可能性のあるユーザーの数に関するリスクと、受け入れることができる信頼性の許容レベルを完全に理解する必要があります。」
Kurcの会社は、Googleのサイト信頼性エンジニアリングプラクティスで生まれ、Nobl9がプラットフォームに商品化されたサービスレベル目標（SLO）と呼ばれる運動を支持しています。
SLOを使用すると、開発者はソフトウェアインタラクション全体の稼働時間と成功率をモデル化し、ユーザーの結果のしきい値を定義できます。たとえば、ショッピングカートのチェックアウトの何パーセントが正しく実行されるかなどです。 Kurc氏によると、SLOをモデル化している企業は、パッチを適用するリスクとパッチを適用しないリスクについて実際に話し合うことができます。
ただし、このようなソリューションは、事実の後で、またはむしろオープンソースソフトウェアが作成された後に提供されます。しかし、本質的により安全にするために私たちは何をしますか？
より広範な問題：オープンソースのセキュリティを所有しているのは誰ですか？
誰もオープンソースの使用をやめるつもりはありません。 Log4jのようなツールに手を伸ばすのではなく、ロギングソリューションを最初から構築するのはばかげています。最近、開発者はより少ないロジックを作成し、より多くのフレームワーク、ライブラリ、APIを統合していますが、それは変わらないでしょう。
GoogleのFilippoValsordaがバイラル投稿で書いたように、これらのオープンソースメンテナの多くは「ボランティアまたは大企業の従業員の2つのカテゴリのいずれかに分類されます。時々両方。どちらのモデルも健全ではありません。」
Log4jは、最新のソフトウェアサプライチェーンの多くが、少数の保守者、または1人の保守者でさえ、サイドプロジェクトとしてテクノロジを作成することが多いオープンソースプロジェクトで支えられているという事実を明らかにしました。 （そして明確にしましょう。最近のデータによると、すべてのオープンソースソフトウェアの大部分は10人未満で作成されています。）
「最新のアプリケーションは多くのコンポーネントから構築されており、その多くは社内で開発されたものではなく、「既成の」ソリューションを使用して組み立てられています」と、（ISC）2のCISOであるJohnFranceは述べています。 「問題の認定と特定の大部分は、ソフトウェアで使用されているコンポーネントとライブラリを把握し、ソフトウェアの部品表（SBOM）を保持することです。」
しかし、（ISC）2のLog4修復調査の匿名のセキュリティ担当者によると、「開発者は一般に、ソフトウェアで使用しているものを追跡することに非常に怠惰でした。このようなイベントで、ライブラリまたはコンポーネントがコードで使用されているかどうかを特定する必要がある場合、そのトレーサビリティの欠如が大きな問題になります。これにより、在庫とSBOMをチェックするという単純な演習が複雑なスキャンプロセスに変わり、誤検知と誤検知の機会が多くなります。ウェイクアップコールが必要になった場合は、Log4jで大きなものを入手しました。」
Googleやその他の大物は、このオープンソースのセキュリティ脆弱性の課題に力を注いでいます。より深い投資とベンダーのコラボレーションがLog4jのようなインシデントの頻度と苦痛を軽減するのに役立つかどうかは時が経てばわかります。しかし、その間、開発者は次のホリデーシーズンにひどいセキュリティの驚きを避けるための戦略を考案しています。
開示：私はMongoDBで働いていますが、これらのビューは私だけのものです。
ソースリンク