「壊れていないものを直すな」というアメリカの古いことわざにも知恵が隠されています。だからこそ、格言にもなったのです。
そして、このことわざは使い古しの芝刈り機に当てはまるのかもしれません。しかし、デジタル世界となると、これは時代遅れの「知恵」であり危険です。見かけは何の問題もなく機能しているような多くのシステムやアプリケーションも、数年前に発見された危険な脆弱性をはらんでいるかもしれないからです。多くの組織はこのようなレガシー脆弱性に気付いていません。忘れてしまったか、単に無視している場合もあるでしょう。しかし、攻撃者は忘れていません。
レガシーコードとレガシー脆弱性
最近見直していない「レガシーコード」がある場合、一見、問題なく動作していても脆弱性をはらんでいる可能性は否定できません。
- オープンソース・ソフトウェアまたはサードパーティ・ソフトウェアの場合、メンテナンス担当者がそのサポートを停止し、脆弱性が発見されてもパッチを作成していないことを意味します。
- 自身が所属する組織であっても、コードベースを継承した場合、そのソフトウェアに対して最新のテストプロセスを行ったとは考えられません。
- 開発チームは、積極的に開発しているソフトウェアの場合、新しい機能を追加する際に古いソフトウェアを温存することもあります。しかし、組織がテストおよび修正を重点的に行うのは最新バージョンの新しいコードです。
つまり、対策を棚に上げ、その後長らく忘れ去られているか、そもそも、その存在さえ知らないレガシー脆弱性が隠れたソフトウェアがリリースされているのかもしれないのです。
しかし、未知の脆弱性は徐々に明るみに出ています。そうでなければ「パッチの火曜日」が過去の遺物と呼ばれるわけがありません。先日、「パッチの火曜日」にMicrosoftが少なくとも115個のセキュリティ上の不具合を修正するアップデートをリリースしましたが、そのうちの26件は最も深刻な「重大」カテゴリーでした。
ソフトウェアのビルドや組み立てを担当する組織が独自の「パッチの火曜日」を設けなければ、そのシステムおよびアプリケーションは、ハッカーの悪用を容易に許してしまう既知の脆弱性で満ち溢れることなるでしょう。
これは、組織が不愉快な問題から破滅的な問題まで直面することを意味します。ハッカーが悪用しやすいターゲットを狙うことは文書で裏付けられています。
レガシーシステムへの攻撃
悪名高いWannaCryランサムウェアは、2017年の中頃に多くの企業の業務を麻痺させましたが、それは、攻撃を受けた企業がレガシーシステムを利用していたことと関係があります。
「犯人は‘EternalBlue’エクスプロイトと呼ばれるもので、これは、Windows XPなどの特定の古いMicrosoft Windows OS の未知の脆弱性を狙ったツールである。」という記事が、当時、Infosecurity誌に掲載されています。
WannaCryほど壊滅的な力を持つものであれば、人々に恐怖を引き起こすだけでなく人々の行動も促したはずだと皆さんは思うかもしれません。しかし、答えは「ノー」です。RSA Conferenceが2年前に実施したアンケートによると、脆弱性が判明してから即時にパッチを適用した企業はわずか47%でした。ハッカーにとっては天国です。アンケート結果によるとその理由は、十分な時間または資金がない、またはパッチを適用する専門知識を備えた人材がいない、ということでした。
このような脆弱性が1つでも悪用されれば、さらに時間と資金が奪われるわけで、まったくもって皮肉な話です。
IBMの2019年データ漏洩コストに関する報告書では、世界の平均的なデータ漏洩コストは392万ドルでしたが、米国ではその倍以上の819万ドルでした。
その上、レガシーコードは、厳しいコンプライアンス要件に従わなけれならないことも手伝って、ビジネス運用上の財務的リスクを増加させる可能性があります。HIPAA（医療保険の携行性と責任に関する法律）、PCI DSS（PCIデータ・セキュリティ・スタンダード）、SOX（サーベンス・オクスリー法）などの基準では、テクノロジに最新のセキュリティを適用することが義務付けられています。
レガシーテクノロジが原因で監査が困難かつコスト高になっているだけでなく、データ漏洩で経費がかさみ、罰金を受ける場合さえあります。
レガシー脆弱性への対処法
結論：問題の修正によって長期的に経費を抑えられることは、算数がわかれば誰でも分かります。もちろん、レガシー脆弱性への対処は頭の痛い問題ですが、これを怠れば頭痛どころではなく、さらに厄介な問題となります。
そして、その対処法は極めて簡単です。脆弱性を見つけて修正するのです。
それは、本来以上に微妙な問題です。優れたリスク管理とは、最初の最も重大なバグおよびその他の不具合を検出して修正することを意味します。
残念ながらレガシーコードに潜む脆弱性を修正するのは容易ではありません。レガシー脆弱性への対応は多大な労力を要するからです。しかし、多くの専門家によるアドバイスは一致しています。オープンソース・ソフトウェア・コンポーネントのセキュリティを保証するためにシノプシスが推奨する手順は通常、レガシーコードにも適用できます。
ソフトウェアインベントリの作成
これは、ソフトウェアインベントリには包括性が必要です。そうでないと、作成する価値がありません。ソフトウェアインベントリには、オペレーティングシステム、ハードウェア、アプリケーション、コンテナ内のすべてのソフトウェアを含めなければなりません。大部分の最先端アプリケーションにはオープンソースのソフトウェアコンポーネントが含まれているため、これらのコンポーネントを見つけるには、ソフトウェア・コンポジション解析（SCA）ツールが最適な方法です。
脆弱性の検証
脆弱性を把握したら、問題のあるコードを修正する必要があります。それは、すなわち、脆弱性を見つけることです。大部分のSCAツールでは、コードに既知の脆弱性が隠れたコンポーネントが含まれているかどうか報告されます。これらの脆弱性はNational Vulnerability Database（NVD）で公開されています。NVDで公開されている脆弱性は、CVE（Common Vulnerabilities and Exposures）データベースから提供されていますが、これら以外の脆弱性も公開されています。
NVDのWebサイトには、「このデータは脆弱性管理、セキュリティ評価、およびコンプライアンスの自動化を推進します。NVDには、セキュリティ・チェックリストのリファレンス、セキュリティ関連ソフトウェアの欠陥、不適切な構成、製品名、影響指標のデータベースが含まれています。」とあります。
一部のSCAベンダーも、独自の脆弱性情報フィードで、修正に関する詳細をはじめ、NVD以上の詳しい情報を提供しています。
リスク管理
NVDおよびその他の脆弱性リストの重大度スコアで分かることは、優先順位は組織が設定しなければならないという点です。脆弱性の終わりのないリストを上から下まで書き連ねるのは時間の無駄で、リスクも増大します。まず、最も手ごわい脆弱性から着手してください。
リスク管理
CyRC（Cybersecurity Research Center）のシニア・プリンシパル・コンサルタントのTim Mackeyが「時代遅れのコンポーネントをこねくり回して修正してもリスクを悪化させるだけだ」と言うのも無理はありません。
「過去の遺産の修正は一見すると正しい行為に見えるが、実際には利益以上に害をもたらす」と彼は述べます。「たとえば、古いライブラリの更新には、大した理由もなく無数のコードの書き直しが必要になるかもしれません。コードの書き直しは、コードに爆弾を抱えていることを受け入れるよりもはるかに危険な問題を招く恐れがあります。」
常に最新の状態を保つこと
一度、最新の状態に達したら、この状態を保ち続けてください。資産を陳腐化させることないようにしてください。常に最新のインベントリを保ち、アップデートおよびパッチを追跡し、実用化されたら即座にインストールするというポリシーを確立してください。
そうです。それに時間と予算を使うのです。しかし、長期的には時間と資金を節約できます。計画を作成して従い、レガシー脆弱性に対処することは投資であり、日刊紙の見出しのように「絶対その価値がある」のです。
Continue Reading
2024 OSSRA レポート：オープンソース・コンポーネントの古いコードのリスク
Apr 16, 2024 / 1 min read
Software Risk ManagerでAppSecプログラムの管理を簡素化
Aug 20, 2023 / 1 min read