この投稿は『Forbes』誌で発表された記事を元にしています。
もしも自動車販売店が次のような宣伝広告を掲載したら、たちまち大きな反響が広がることはほぼ確実です。「犯罪組織は自動車のロックを解除できる鍵を販売していますが、当店ではこの鍵が効かない交換用のロックを無料で提供しています」
ところが、ソフトウェアは明らかにその域に達していません。セキュリティ企業Tripwireは、今週、340人の情報セキュリティ専門家を対象とした調査の結果、全世界の組織の27%、ヨーロッパの組織の34%が、パッチ未適用の脆弱性を狙われてセキュリティを侵害された経験があることを発表しました。
この調査は先月、Dimensional Researchによって実施されました。
組織は未だにパッチを軽視している
この結果は驚くにはあたりません。漏洩に関するニュースは枚挙にいとまがなく、信用情報会社Equifaxの例のように壊滅的な被害を受ける場合もありますが、その原因は公表された脆弱性に対するパッチ適用を組織が軽視しているためです。
もちろん、こうした統計の見方はさまざまです。被害は「わずか」4分の1、つまり75%が漏洩しなかったと捉えれば肯定的な数字に思えるかもしれませんが、泥棒に自宅のセキュリティ・システムを破られるといった物理的セキュリティを考える場合なら、多くの人が想定する発生確率は数百分の1程度でしょう。
しかも、これらの脆弱性は初めて遭遇する「ゼロデイ」の脆弱性ではなく、既知のバグや欠陥であり、パッチを適用可能なものです。提供されているパッチを適用し損なったばかりに被害を受けたのです。
組織がデータ漏洩を防ぐことができない理由
このレポートには、組織が脆弱であるさまざまな理由も示されています。
- ネットワークに追加された新しいハードウェアやソフトウェアを数分から数時間以内に検出できるという回答が59%を占めた一方で、31%は数日、数週間、あるいは数か月かかると回答しました。まったく検出できないという回答も11%ありました。
- 3分の1以上（35%）が、自動検出ソリューションの利用対象はソフトウェアおよびハードウェア資産の半分に満たないと回答しました。自動検出をまったく利用していないという回答は13%でした。
- 大多数が何らかの脆弱性スキャンを行っていると報告していますが、その頻度は月1回以下という回答が39%でした。
- また、大多数（74%）が1か月以内に脆弱性を修正したと報告していますが、つまり「4分の1」は1か月以内に脆弱性を修正しなかったということです。また、約半数が2週間以内にパッチを適用すると報告していますが、これは残りの半分は2週間以内にパッチを適用していないということです。
- ソフトウェア製品のメーカーやベンダーにとっても、この調査は警告になりました。脆弱性のために自社の組織が製品の使用を中止する場合があるという回答が大半でした。中止の頻度は、頻繁という回答が少数（わずか6%）、ときどきという回答が31%、ごくたまにという回答が44%でした。また、公開された脆弱性に対するパッチは2週間以内に提供されるべきだという回答が82%でした。
パッチ適用は基本
セキュリティの基本である厳格なパッチ適用が100%に近付かないのはなぜでしょうか。これは万金に値する問題です。IBMの調査によると、昨年のデータ漏洩による平均コストは386万ドルでした。
実際、漏洩にはさまざまな面でコストが伴います。潜在的な損害としては、評判の失墜、市場価値の低下、コンプライアンス違反に対する罰金、法的責任などがあります。多くの企業はこれを何とか乗り切ることができたとしても、こうしたコストは企業の存続に関わる脅威になる可能性があります。
私が言いたいのは、そういう道をたどる必要はないということです。鉄壁のセキュリティは不可能としても、よほどの専門知識と意欲に満ちたハッカーでなければ食指が動かないような程度にまで十分にネットワーク、アプリケーション、システムのセキュリティを向上させることを可能にするさまざまなツールやその他の対策があります。
データ漏洩を防ぐ方法
これを実行するには、2つの基本事項があります。
まず、アプリケーションベンダーは、製品を市場に投入する前に、そのソフトウェアにセキュリティを組み込む必要があります。完璧とはいかないまでも、完璧に近付けることは可能です。多くのスポーツの場合とは異なり、アプリケーションセキュリティは完璧に近付けることが重要です。
次に、ソフトウェアを使用する組織は、全員がソフトウェアの機能についての知識を持ち、その知識を常に最新の状態に保つ必要があります。当たり前の言い古されたことですが、自分が所有していることに気付いていないものを守ることはできません。
シフトレフトでデータ漏洩を防ぐ
最初の基本の実行方法についてはテンプレートが十分に確立されています。あらゆるセキュリティカンファレンスの演壇で説かれていることです。それは普遍的な表現で「シフトレフト」と呼ばれ、ソフトウェア開発ライフサイクル（SDLC）の最初から全工程を通じてセキュリティテストを行うことを意味します。最後のペネトレーションテストの段階まで「とっておく」ようなことはしないでください。
開発者がバグを見つけて修正するために役立つツールの包括的なメニューが用意されています。その内容の一部を以下に示します。
- アーキテクチャ・リスク分析（ARA）： セキュリティ上の問題を引き起こすソフトウェアの不具合の約半分は、設計上の欠陥です。ARAはこうした欠陥を特定し、ビジネス上の情報資産に対するリスクのレベルを判定します。
- 静的アプリケーション・セキュリティ・テスト（SAST）： SASTを利用することにより、独自開発コードの開発段階でセキュリティおよび品質の弱点を発見し修正することができます。
- 動的アプリケーション・セキュリティ・テスト（DAST）： このツールは、実行中のアプリケーションをテストし、ハッカーによる攻撃をシミュレーションします。
- インタラクティブ・アプリケーション・セキュリティ・テスト（IAST）： IASTも実行中のアプリケーションをテストしますが、DASTとは異なり、コードインストルメンテーションを用いてアプリケーションの動作とデータフローを監視します。IASTは、スピードと自動化が優先されるCI/CD（継続的インテグレーション/継続的デリバリー）開発環境に有効です。
- ソフトウェア・コンポジション解析（SCA）： 最近のほとんどのアプリケーションは、少なくとも部分的にはオープンソースのソフトウェアコンポーネントを利用して構築されています。SCAは、これらのコンポーネントに関して報告されたセキュリティ脆弱性とこれに関連するセキュリティ脆弱性を検出します。
- ペネトレーションテスト： ペネトレーションテストは開発の最後に行うのが最適であり、DASTの拡張版と見なされています。目的は、WebアプリケーションやWebサービスの脆弱性を見つけてエクスプロイトを仕掛け、製品を市場に投入する前に開発者が修正できるようにすることです。
もちろん、ペネトレーションテストが完了してソフトウェアがいかに完璧に近付いたとしても、悪意のあるエクスプロイトまたは公になる前にメーカーに報告しようとする善意のエクスプロイトによって脆弱性が発見されることは避けられません。
一にも二にもパッチの適用を怠らないことが重要
これは第二の基本、すなわち何を所有しているかを把握して最新状態に保つことにつながります。これはベンダーにもその顧客にも当てはまることです。
Tripwireの製品管理および戦略担当副社長であるTim Erlin氏は、セキュアな開発プラクティスに加えて、ベンダーは「発見された脆弱性を修正するプロセス」を必要としていると指摘しています。ベンダーの立場からすると、顧客が実際にパッチなどの緩和策を適用しない限り、問題は本当の意味では解決されません。」
プロジェクトのバージョン管理・保管も行うコード共有およびパブリッシングサービス、GitHubのセキュリティ担当シニア・プロダクト・マネージャーを務めるJustin Hutchings氏はこう認め、確かに、ソフトウェアの脆弱性に対する情報を公開し、修正プログラムを提供するのは企業の責任であるが、脆弱性が公開された後は、「脆弱性にパッチを適用する責任は下流のソフトウェアプロジェクトとIT組織にあります」と語っています。
そして、必ずしもこれが実践されていないというTripwireの調査結果を裏付ける現実があります。「昨年、GitHub上の脆弱なソフトウェアプロジェクトに対して、約2,700万件のセキュリティ脆弱性アラートを送信しました」と、Hutchings氏は述べています。
クラウドへの移行を検討する
「セキュリティ脆弱性アラートはユーザーにプロジェクトのセキュリティを保護するための情報を提供しますが、業界データによると、脆弱性の70%以上は30日を経過してもパッチが適用されず、多くの脆弱性がパッチを適用するまでに1年もかかっている可能性があります」とHutchings氏は述べています。
その一つの改善方法として、Hutchings 氏はビジネスクリティカルなソフトウェアをクラウドに移行することを勧めています。「SaaS（Software-as-a-service）のアプリケーションはすべて一元的に管理されており、何千もの顧客の個々のアップグレードサイクルに依存しないため、パッチ適用がはるかに迅速に行われる傾向があります」と、Hutchings氏は指摘します。
確かにこれらの対策はすべてコストがかかりますが、重大な侵害によって生じた結果への対処に比べれば、はるかに低コストです。
Continue Reading
2024 OSSRA レポート：オープンソース・コンポーネントの古いコードのリスク
Apr 17, 2024 / 1 min read
