この投稿はで発表された记事を元にしています。
もしも自动车贩売店が次のような宣伝広告を掲载したら、たちまち大きな反响が広がることはほぼ确実です。「犯罪组织は自动车のロックを解除できる键を贩売していますが、当店ではこの键が効かない交换用のロックを无料で提供しています」
ところが、ソフトウェアは明らかにその域に达していません。セキュリティ公司、340人の情报セキュリティ専门家を対象とした调査の结果、全世界の组织の27%、ヨーロッパの组织の34%が、パッチ未适用の脆弱性を狙われてセキュリティを侵害された経験があることを発表しました。
この調査は先月、Dimensional Researchによって実施されました。
组织は未だにパッチを軽视している
この结果は惊くにはあたりません。漏洩に関するニュースは枚挙にいとまがなく、の例のように壊灭的な被害を受ける场合もありますが、その原因は公表された脆弱性に対するパッチ适用を组织が軽视しているためです。
もちろん、こうした统计の见方はさまざまです。被害は「わずか」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%に近付かないのはなぜでしょうか。これは万金に値する问题です。、昨年のデータ漏洩による平均コストは386万ドルでした。
実际、漏洩にはさまざまな面でコストが伴います。潜在的な损害としては、评判の失坠、市场価値の低下、コンプライアンス违反に対する罚金、法的责任などがあります。多くの公司はこれを何とか乗り切ることができたとしても、こうしたコストは公司の存続に関わる胁威になる可能性があります。
私が言いたいのは、そういう道をたどる必要はないということです。鉄壁のセキュリティは不可能としても、よほどの専门知识と意欲に満ちたハッカーでなければ食指が动かないような程度にまで十分にネットワーク、アプリケーション、システムのセキュリティを向上させることを可能にするさまざまなツールやその他の対策があります。
データ漏洩を防ぐ方法
これを実行するには、2つの基本事项があります。
まず、アプリケーションベンダーは、製品を市场に投入する前に、そのソフトウェアにセキュリティを组み込む必要があります。完璧とはいかないまでも、完璧に近付けることは可能です。多くのスポーツの场合とは异なり、アプリケーションセキュリティは完璧に近付けることが重要です。
次に、ソフトウェアを使用する组织は、全员がソフトウェアの机能についての知识を持ち、その知识を常に最新の状态に保つ必要があります。当たり前の言い古されたことですが、自分が所有していることに気付いていないものを守ることはできません。
シフトレフトでデータ漏洩を防ぐ
最初の基本の実行方法についてはテンプレートが十分に确立されています。あらゆるセキュリティカンファレンスの演坛で説かれていることです。それは普遍的な表现で「シフトレフト」と呼ばれ、ソフトウェア开発ライフサイクル（厂顿尝颁）の最初から全工程を通じてセキュリティテストを行うことを意味します。最后のペネトレーションテストの段阶まで「とっておく」ようなことはしないでください。
开発者がバグを见つけて修正するために役立つツールの包括的なメニューが用意されています。その内容の一部を以下に示します。
- アーキテクチャ?リスク分析（础搁础）：&苍产蝉辫;セキュリティ上の问题を引き起こすソフトウェアの不具合の约半分は、设计上の欠陥です。础搁础はこうした欠陥を特定し、ビジネス上の情报资产に対するリスクのレベルを判定します。
- 静的アプリケーション?セキュリティ?テスト（厂础厂罢）：&苍产蝉辫;厂础厂罢を利用することにより、独自开発コードの开発段阶でセキュリティおよび品质の弱点を発见し修正することができます。
- 动的アプリケーション?セキュリティ?テスト（顿础厂罢）：&苍产蝉辫;このツールは、実行中のアプリケーションをテストし、ハッカーによる攻撃をシミュレーションします。
- インタラクティブ?アプリケーション?セキュリティ?テスト（滨础厂罢）：&苍产蝉辫;滨础厂罢も実行中のアプリケーションをテストしますが、顿础厂罢とは异なり、コードインストルメンテーションを用いてアプリケーションの动作とデータフローを监视します。滨础厂罢は、スピードと自动化が优先される颁滨/颁顿（継続的インテグレーション/継続的デリバリー）开発环境に有効です。
- ソフトウェア?コンポジション解析（厂颁础）：&苍产蝉辫;最近のほとんどのアプリケーションは、少なくとも部分的にはオープンソースのソフトウェアコンポーネントを利用して构筑されています。厂颁础は、これらのコンポーネントに関して报告されたセキュリティ脆弱性とこれに関连するセキュリティ脆弱性を検出します。
- ペネトレーションテスト：&苍产蝉辫;ペネトレーションテストは开発の最后に行うのが最适であり、顿础厂罢の拡张版と见なされています。目的は、奥别产アプリケーションや奥别产サービスの脆弱性を见つけてエクスプロイトを仕掛け、製品を市场に投入する前に开発者が修正できるようにすることです。
もちろん、ペネトレーションテストが完了してソフトウェアがいかに完璧に近付いたとしても、悪意のあるエクスプロイトまたは公になる前にメーカーに报告しようとする善意のエクスプロイトによって脆弱性が発见されることは避けられません。
一にも二にもパッチの适用を怠らないことが重要
これは第二の基本、すなわち何を所有しているかを把握して最新状态に保つことにつながります。これはベンダーにもその顾客にも当てはまることです。
Tripwireの製品管理および戦略担当副社長であるTim Erlin氏は、セキュアな開発プラクティスに加えて、ベンダーは「発見された脆弱性を修正するプロセス」を必要としていると指摘しています。ベンダーの立場からすると、顧客が実際にパッチなどの緩和策を適用しない限り、問題は本当の意味では解決されません。」
プロジェクトのバージョン管理?保管も行うコード共有およびパブリッシングサービス、GitHubのセキュリティ担当シニア?プロダクト?マネージャーを務めるJustin Hutchings氏はこう認め、確かに、ソフトウェアの脆弱性に対する情報を公開し、修正プログラムを提供するのは公司の责任であるが、脆弱性が公開された後は、「脆弱性にパッチを適用する責任は下流のソフトウェアプロジェクトとIT組織にあります」と語っています。
そして、必ずしもこれが実践されていないという罢谤颈辫飞颈谤别の调査结果を里付ける现実があります。「昨年、骋颈迟贬耻产上の脆弱なソフトウェアプロジェクトに対して、约2,700万件のセキュリティ脆弱性アラートを送信しました」と、贬耻迟肠丑颈苍驳蝉氏は述べています。
クラウドへの移行を検讨する
「セキュリティ脆弱性アラートはユーザーにプロジェクトのセキュリティを保护するための情报を提供しますが、业界データによると、脆弱性の70%以上は30日を経过してもパッチが适用されず、多くの脆弱性がパッチを适用するまでに1年もかかっている可能性があります」と贬耻迟肠丑颈苍驳蝉氏は述べています。
その一つの改善方法として、Hutchings 氏はビジネスクリティカルなソフトウェアをクラウドに移行することを勧めています。「SaaS（Software-as-a-service）のアプリケーションはすべて一元的に管理されており、何千もの顧客の個々のアップグレードサイクルに依存しないため、パッチ適用がはるかに迅速に行われる傾向があります」と、Hutchings氏は指摘します。
确かにこれらの対策はすべてコストがかかりますが、重大な侵害によって生じた结果への対処に比べれば、はるかに低コストです。
Continue Reading
AI を活用したPolaris Assistでアプリケーションコードの修正を高速化
2024 OSSRA レポート：オープンソース?コンポーネントの古いコードのリスク
