Equifaxの情報漏えいは「完全に防止可能」だったと報告書が指摘

苦労して納めた税金が有効に使われるのを見るのは、いつだって喜ばしいことです。米国政府は最近、Equifaxが自社と私たちのデータを守るために妥当な対策を講じていれば、昨年発生した大規模な情報漏えいは完全に防げたことを示す報告書を公表しました。この記事では、報告書の重要な指摘と、Equifaxよりも適切に自らを守る方法を紹介します。

報告書

下院監視・政府改革委員会は、米国史上最大規模のセキュリティインシデントの一つとして広く知られ、1億4,800万人以上の消費者に影響を及ぼしたEquifaxの情報漏えいについて、14か月にわたる調査を経てスタッフ報告書を公表しました。多くの読者がすでにご存じのとおり、Equifaxは広く利用されているオープンソースのJava Webフレームワーク、Apache Strutsに存在する既知の脆弱性にパッチを適用できませんでした。

委員会は12万2,000ページを超える文書を精査し、EquifaxのITチームに直接関わっていた元従業員3人に聞き取りを行いました。これらの調査をもとに報告書が作成されており、全文はこちらからご覧いただけます。

報告書によると、「ネットワークトラフィックを監視するための機器は、セキュリティ証明書の期限切れにより19か月間停止していたため、Equifaxはデータの持ち出しに気づかなかった」とのことです。2か月後にEquifaxが証明書を更新すると、担当者は「不審なWebトラフィックにすぐ気づいた」と報告されています。

過ち：セキュリティのすべてを一人に任せる

特に注目すべきなのは、インシデントの直後に退任したEquifaxの元CEO、Richard Smithが、既知の脆弱性を含むStrutsライブラリへのパッチ適用を怠ったとして、ITスタッフ一人の責任にしたことです。Smithは、インシデントにつながった過ちについて、委員会に次のように説明しました。

「組織内でパッチ適用を伝達する責任を負っていた担当者が、それを行わなかったという人的ミスです」

責任は一人にあると考えていたことから、当時のEquifaxが、チーム全体に優れたセキュリティプラクティスを浸透させるにはほど遠かったことがわかります。根本的な問題は、一人の担当者に依存するセキュリティプロセスにありました。開発者をはじめとするチーム全体で、セキュリティに関する責任を共有すべきでした。

報告書では、「ITポリシーの策定と運用の間に実行上の隔たりがあった」とも指摘されています。このことから、Equifaxではエンジニアリング、運用、セキュリティの各チームが分断され、運用やセキュリティのプラクティスが開発ワークフローやアプリケーションのライフサイクルに組み込まれていなかったことがうかがえます。

DevSecOpsが解決を目指すのは、まさにこうした根本的な問題です。セキュリティテストを開発の早い段階に移すことで、コードやオープンソースライブラリの脆弱性をできるだけ早く特定し、修正できるようにします。これにより、*すべての*開発者がセキュリティの責任を共有し、開発ワークフローのあらゆる段階にセキュリティテストを組み込めます。これは、一人のスタッフに依存していたEquifaxのやり方とは大きく異なります。

解決策：開発ワークフローにセキュリティを組み込む

優れたDevSecOpsのプラクティスを活用すれば、一人の担当者に頼らず、開発チームによって脆弱なStrutsライブラリを介したEquifaxの情報漏えいを防ぐことができました。Apache Strutsの脆弱性が公表されてから、Equifaxのアプリケーションで最初の攻撃が確認されるまで、わずか2日でした。開発から本番環境までの各段階をたどり、どこでこのセキュリティ問題を特定し、修正できたのかを見ていきましょう。

開発：アプリケーションコードが引き続き開発中であれば、開発チームはローカル環境でアプリケーションの開発、ビルド、テストを行います。脆弱な依存関係を検出するセキュリティテストを組み込めば、IDEやビルドで通知を通じて問題を検出できます。新たな脆弱性の存在を開発チーム全体に知らせるとともに、プルリクエストやIDEで自動修正のアドバイスを提示できます。

CI：CIサーバーで新しいビルドを実行するたびに、タスクとしてCIサーバープラグインやCLIコマンドを使い、アプリケーションの依存関係を自動的にテストできます。新たな脆弱性がすぐに検出されてCIジョブが停止し、先に進む前に修正を促します。

監視：アプリケーションが現在開発中かどうかにかかわらず、本番環境で稼働しているなら継続的に監視する必要があります。新たに公表された脆弱性があれば、すぐに対処できます。自動PR、メール、Slackメッセージなど、開発チームが希望するチャネルを通じて通知し、問題の解消に必要なアップグレードとともに、脆弱性の修正を促します。

ランタイム：ランタイムセキュリティツールを使えば、動作の異常や脆弱な関数の呼び出しをすぐに検出でき、チームはセキュリティインシデントの発生時に迅速に対応できます。

主な調査結果

委員会はこのセキュリティインシデントについて、次の5つの主な調査結果を報告しています。

1. 完全に防止可能だった。Equifaxはサイバーセキュリティリスクを十分に把握し、軽減できていませんでした。確認できていたセキュリティ上の問題に対処していれば、情報漏えいは防止できたはずです。

2. 責任体制と管理構造の不備。Equifaxは社内のIT管理体制に明確な権限系統を設けていなかったため、ITポリシーの策定と運用の間に実行上の隔たりが生じていました。その結果、セキュリティ施策を包括的かつ迅速に実施する能力が損なわれました。

3. 複雑で時代遅れのITシステム。積極的な事業拡大とデータの蓄積により、EquifaxのIT環境は複雑化していました。システムの複雑さに加え、独自開発のレガシーシステムが時代遅れだったことも、ITセキュリティを特に困難にしていました。

4. 適切なセキュリティ対策の不履行。Equifaxは、ビジネスに不可欠なドメインを監視するための79件を含め、300件を超えるセキュリティ証明書の有効期限切れを放置していました。デジタル証明書の期限切れから19か月間更新しなかったため、サイバー攻撃の間、データの持ち出しを把握できませんでした。

5. 影響を受けた消費者を支援する準備不足。Equifaxは情報漏えいを公表した後、影響を受けた消費者を特定し、通知して支援する準備ができていませんでした。情報漏えいに関するWebサイトとコールセンターはすぐに対応能力を超え、消費者は自分の身元を守るために必要な情報へアクセスできませんでした。

まだお試しでなければ、ぜひSnykでアプリケーションプロジェクトを無料でテストしてみてください。プロジェクトのスキャンと監視を開始し、現在存在する脆弱性を見つけ、コードベースから取り除くお手伝いをします。