Equifax Data Breach
注意事項
- 本資料は、米国下院監査政府改革委員会が発行した『The Equifax Data Breach Report』を翻訳した資料です。
- 内容については、最大限の努力を持って正確に期していますが、本書の内容に基づく運用結果については責任を負いかねますので、ご了承ください。
- 他の翻訳は、『Scientia Securtity on GitHub』を参照してください。
- ブログは『セキュリティコンサルタントの日誌から』を参照してください。。
エグゼクティブサマリ
2017年9月7日、Equifaxは1億4300万人の消費者に影響を与えるサイバーセキュリティインシデントを発表しました。この数は、ついには148百万人に増え、アメリカの人口のほぼ半分、アメリカ成人の56パーセントに達しました。本レポートは、世界最大の消費者信用情報サービス(CRA:Consumer Reporting Agencies)の1つであるEquifaxに対するサイバー攻撃の状況を説明しています。
Equifaxは、米国の大手消費者信用情報サービスの1つです。消費者信用情報サービスは消費者データを収集し、それを分析してクレジットスコアと詳細なレポートを作成してから、そのレポートを第三者に販売します。消費者は自発的に消費者信用情報サービスに情報を提供することも、この情報収集プロセスからオプトアウトすることもできません。消費者信用情報サービスは金融取引に必要な情報共有を促進するサービスを提供しますが、大量の機密個人データを集めることによって実現します。それはサイバー犯罪者にとって高い付加価値の攻撃対象となります。その結果、消費者信用情報サービスには最高レベルのデータセキュリティを提供することによって消費者データを保護するという重い責任があります。
2005年、Equifax社の元CEO Richard Smith氏は積極的な成長戦略に着手し、複数の企業、ITシステムやデータを買収しました。買収戦略はEquifaxの利益と株価を押し上げましたが、この成長はEquifaxのITシステムの複雑さを増し、データセキュリティリスクを増大させました。Equifaxが情報漏洩を公に発表する3週間前の2017年8月、Richard Smith氏はEquifaxが毎日議会図書館で保持されているデータ量のほぼ1,200倍のデータを管理していると自慢げに語っていました。
しかしEquifaxは、この機密データを保護するための適切なセキュリティプログラムを実装することができませんでした。 その結果、Equifaxは米国史上最大規模の情報漏洩の一つに直面してしまいました。しかし、この侵入は完全に防げたものといえるでしょう。
2017年3月7日に、Apache Strutsに関する深刻な脆弱性が公開されました。 Equifaxは、Apache Strutsを利用し、古いOS上であるアプリケーションを動かしていました。翌日、国土安全保障省はこの重大な脆弱性についてEquifaxに警告しました。EquifaxのGlobal Threat and Vulnerability Management(GTVM)チームは、3月9日にこの警告を400人以上にメールで共有し、Apache Strutsを実行しているシステムは48時間以内にパッチ適用を行うよう指示しました。 Equifax GTVMチームは、この脆弱性について、3月16日にもミーティングを行っています。
残念ながら、Equifaxはシステム群すべてにパッチを適用できていませんでした。1970年代に開発されたインターネット公開向けに独自開発された消費者苦情ポータルACISシステム(Automated Customer Interview System)は、当該脆弱性を含むバージョンのApache Strutsを実行していました。 EquifaxはACIS内にあるApache Strutsにパッチを当てず、システムとデータをインターネットで運用し続けました。
2017年5月13日、攻撃者はEquifaxへのサイバー攻撃を開始しました。攻撃は76日間続き、Equifaxのネットワークを遠隔操作するため、Web Shell(Webベースのバックドア)を配置しました。彼らは、暗号化されていない認証情報(ユーザ名とパスワード)を含むファイルを発見し、攻撃者がACIS環境外において機密データにアクセスすることを可能にしました。攻撃者はこの認証情報を使用して、48の無関係なデータベースにアクセスしました。
攻撃者はこれらの48のデータベースで9,000のクエリを送信し、暗号化されていない個人情報データへのアクセスに265回成功しました。攻撃者は、このデータをEquifax環境から持ち出していますが、これはEquifaxに気付かれずに成功しています。セキュリティ証明書の有効期限が切れているため、ACISのネットワークトラフィックの監視に使用デバイスが19か月間非アクティブ状態となっており、Equifaxはデータを検知できませんでした。 2017年7月29日、Equifaxは期限切れの証明書を更新し、疑わしいWebトラフィックを検知しました。
セキュリティ証明書を更新した後、Equifaxの従業員は中国のIPアドレスから不審な通信を検知しました。ACISアプリケーションから出る不正な通信には、消費者の信用調査に関連する画像が含まれている可能性が発覚し、Equifaxは現在も攻撃を受けていることと判断し、すぐにインシデント対応を開始しました。
7月30日、EquifaxはACIS上に存在するアプリケーション脆弱性を検出しました。Equifaxは、ドイツのISPが所有するIPアドレスからの不正通信の存在も確認しましたが、これも中国のプロバイダにリースしているIPアドレスであることが判明しました。この兆候を受けて、Equifaxは緊急メンテナンスとしてACIS Webポータルを停止しました。サイバー攻撃はACISがオフラインになった特に終了しています。
7月31日、CIO David Webb氏は、CEO(Richard Smith氏)にこの事案について連絡しています。Equifaxは、攻撃者がApache Strutsの脆弱性を悪用して、情報漏洩を行ったと考えていました。8月2日、Equifaxはサイバーセキュリティ会社Mandiant社に包括的なフォレンジック調査を依頼しました。 また、この事案について報告するため、社外法律顧問とFBIにも連絡しています。
2017年8月下旬までに、Mandiant社は、攻撃者が大量の消費者の個人情報へアクセスした事実を確認しました。これを受けて、Equifaxはこの事案を公開するための準備に取り掛かりました。この取り組みの一環として、Equifaxは、各個人が情報漏洩の影響を受けているかどうかを調べ、影響を受けた場合はクレジットカード利用監視サービス(Credit Monitoring)、アイデンティティ盗難監視サービス(Identity Theft Service)に登録するためのWebサイトを作成しました。Equifaxはまた、1,500名のスタッフを配置した緊急コールセンター機能を立ち上げる準備に取り掛かりました。9月4日、EquifaxとMandiant社は、情報漏洩の影響を受けた1億4,300万人の顧客リストを作成しましたが、後にこの数は1億4,800万人にまで増加しています。
Equifaxが9月7日にこの情報漏洩について発表した際、影響を受けた多数の消費者を支援する体制と準備ができていませんでした。専用のWebサイトとコールセンターはすぐに逼迫し、消費者は自分たちが影響を受けたか否か、そしてどのようにアイデンティティ盗難監視サービスを受けることができるかについて、必要な情報を入手できませんでした。
Equifaxは、この情報漏洩の影響を最小化し、未然に防ぐための二つの失敗に対処する必要がありました。第一に、EquifaxのIT管理体制には説明責任の欠如と明確な権限の組織体制が存在せず、ITポリシー策定と運用の間で、実務上のギャップが存在していました。またこうしたずさんな管理態勢は、他のセキュリティ対策を包括的かつタイムリーにて実施することの妨げにもなりました。一例として、Equifaxは、ビジネスクリティカルなドメインを監視するための79の証明書を含め、300を超えるセキュリティ証明書の期限切れを許可していました。
第二に、Equifaxの積極的な成長戦略とデータ蓄積により、IT環境が複雑になりました。Equifaxは、独自開発された古い環境上で最も重要なアプリケーションをいくつも実行しました。EquifaxのITシステムの複雑さと時代遅れという二つの特徴が、ITセキュリティをより困難な状態にしています。Equifaxは古い基盤を刷新する取り組みを開始したため、Equifaxは古いITシステム運用における固有のセキュリティリスクを認識していました。しかしながら、こうした改善努力は情報漏洩を防ぐには遅すぎたと言えます。
Equifaxは、情報漏洩について責任を負う役員を数名指名しました。しかし、このアナウンスの8日後の9月15日、CIOとCSO(最高セキュリティ責任者)はどちらも早期退職し、CEOであるRichard Smith氏は9月26日に辞任します。10月2日、EquifaxはApache Strutsの脆弱性に関する電子メールの転送に失敗したという 理由で、SVP(Senior Vice President)兼Global Corporate Platforms担当CIOを務めるGraeme Payne氏を解雇しました。7年間優秀な従業員として活躍し、400名近くの上級管理職を務めるPayne氏は、ACISを含むEquifax内の多数のITシステムを管理していました。 10月3日、Richard Smith氏は、人為的なミスと、情報漏洩の根本原因としてパッチを適用する必要性を伝えることに失敗したことを非難する議会の前で証言をしました。
Equifaxは、そのサイバーセキュリティリスクを十分に認識し軽減することに失敗しました。このサイバー攻撃に先立って、同社が認識可能なセキュリティ問題に対処するための措置を講じていれば、情報漏洩は防止された可能性があります。
登場人物と略語
本レポートの主要な登場人物は以下の通りです。
- CEO (Chief Executive Officer)
- 2018.04 - Present : Mark Begor
- 2017.09 - 2018.03 : Paulino do Rego Barros Jr.(暫定CEOとして就任。)
- 2005.12 - 2017.09 : Richard Smith
- CIO (Chief Information Officer - 現在では、CTOとして知られている)
- 2018.06 - Present : Bryson Koehler
- 2010.01 - 2017.09 : David Webb
- 2004.11 - 2009.07 : Robert Webb
- CSO (Chief Security Officer - 現在では、CISOとして知られている)
- 2018.02 - Present : Jamil Farshchi
- 2017.09 - 2018.02 : Russ Ayres(暫定CSOとして就任。2018.02から現在は、Deputy CISOに就任)
- 2013.08 - 2017.09 : Susan Mauldin
- 2005.09 - 2013.03 : Tony Spinelli
- その他の上級幹部(Senior Equifax Officials)
- 2013.01 - Present : John J. Kelley (CLO - Chief Legal Officer)
- 2011.03 - 2017.10 : Graeme Payne (SVP & Global Corporate Platforms担当CIO)
(本書で登場する略語については、翻訳から省略)
主要なイベントのタイムライン
2017年3月7日
- Apache Strutsプロジェクト管理委員会が、Apache Strutsに影響を与えるCVE-2017-5638の脆弱性を発表し、パッチをリリースします。
2017年3月8日
- US-CERTは、Apache Strutsの脆弱性にパッチを当てることを推奨し、Equifaxに警告を送ります。
2017年3月9日
- EquifaxのGlobal Threat and Vulnerability Management(GTVM)チームは、48時間以内に重要なセキュリティパッチを適用するように電子メールで依頼し、US-CERTの通知メールを内部で展開しています。
2017年3月10日
- Equifaxネットワークに接続されたサーバ上で、攻撃者がApache Struts脆弱性を不正に悪用している最初の証拠が発見された時期です。
2017年3月15日
- Equifaxのセキュリティチームは、Apache Strutsの脆弱性を含むシステムを特定するため、スキャンを実行します。 スキャンは、外部に直面しているシステム上において、当該脆弱性を検出しませんでした。
2017年5月13日
- 攻撃者は、ACISアプリケーション(Automated Consumer Interview System)内にあるApache Strutsの脆弱性を悪用して、Equifaxネットワークに侵入し、Web ShellをEquifaxシステムにインストールします。
2017年5月13日〜2017年7月30日
- 攻撃者は、Equifaxの古い環境からEquifaxデータベースへの不正アクセスを取得した期間です。攻撃者は、Equifaxシステム内の機密データベースに対して約9,000回のクエリを実行しました。
2017年7月29日
- Equifaxは、ACISネットワーク通信を監視しているデバイスの有効期限が切れたセキュリティ証明書を更新します。19か月間、証明書の有効期限は切れました。
- Equifaxのセキュリティチームは、ACIS Webアプリケーションに関連する疑わしいネットワーク通信を検知しました。それに応じて、Equifaxは疑わしいトラフィックをブロックしました。
2017年7月30日
- Equifaxのセキュリティチームはネットワーク通信を監視し続け、追加の疑わしい活動を監視します。 EquifaxはACISアプリケーションをオフラインにします。 SVP兼Global Corporate Platforms担当CIOであるGraeme Payne氏は、CIOであるDavid Webb氏にセキュリティインシデントについて報告しました。
2017年7月31日
- Equifaxのスタッフは、侵入の一環として、個人情報が漏洩した可能性があると判断しました。
- David Webb氏は、セキュリティインシデントについてCEOであるRichard Smith氏に通知します。
2017年8月2日
- Equifaxは、法律事務所のKing and Spaldingと契約します。また、情報漏洩に関するフォレンジック調査を行うため、サイバーセキュリティ会社Mandiant社を雇います。Equifaxは、FBIにも通知します。
2017年8月11日
- Mandiant社は、攻撃者が大量の個人情報を含むデータベーステーブルにアクセスした可能性があると判断します
2017年8月17日
- Equifaxは、情報漏洩調査に伴うMandiant社の予備調査結果を討議するため、経営層で会議を行いました。
2017年8月24日
- Mandiant社は、アクセスされた個人情報の量を確認し、データベース管理者と影響を受けた顧客の身元を特定するアプローチの検討に着手しました。
2017年8月24〜25日
- CEOのRichard Smith氏が、Equifaxの取締役会と電話会議を開き、取締役会に情報漏洩について報告しました。
2017年9月4日
- Mandiant社の調査に基づき、Equifaxは、個人情報が漏洩した可能性がある1億4,300万人の顧客リスト作成に着手しました。
2017年9月7日
- Equifaxは、情報漏洩の事実を公開しました。Equifaxは、攻撃者がアクセスした情報には、氏名、社会保障番号、生年月日、住所、運転免許証番号、クレジットカード番号、クレーム文書などが含まれていることを言及しました。
2017年9月14日
- 米議会下院に属する監査・政府改革委員会(The House Committee on Oversight and Government Reform)と科学・宇宙・技術委員会(The House Committee on Science, Space, and Technology)は、Equifaxの情報漏洩/侵害に関する調査を開始しました。
- Equifax CIOであるDavid Webb氏、CSO Susan Mauldin女史が退職しました。
2017年9月26日
- Equifax CEO、Richard Smith氏が退職を発表しました。
2017年10月2日
- Mandiant社はフォレンジック調査を完了し、潜在的な被害者数、当初の報告数より250万人増えたと結論付けました。
- Equifaxは、Apache Struts脆弱性のパッチ適用に関するGTVMチームのメール警告の転送に失敗したという理由で、Graeme Payne氏を解雇しました。
2017年10月3日
- Richard Smith氏は、米議会エネルギー・商業委員会に属する、デジタル商取引と消費者保護に関する小委員会において、証言しています。
2018年3月1日
- Equifaxは2017年の情報漏洩に関する最新情報を公開しており、攻撃者はさらに240万人の米顧客の氏名、運転免許証の一部を含む個人情報にアクセスしていたことを発表しています。
I. 消費者信用情報サービスのビジネスモデルと個人情報利用
A. 消費者信用情報サービスのビジネスモデル
消費者信用情報サービス(CRA:Consumer Reporting Agencies)は、消費者の情報を収集し、それを分析してクレジットスコアと詳細な報告書を作成し、消費者レポートを第三者に販売します(図1を参照)。消費者信用情報サービスのビジネスモデルは、情報を収集し、米国民の機微情報から利益を得ています。三大企業として、Equifax、Experian、TransUnionが挙げられ、給与日支払いローン、当座預金口座、光熱費などに関連する情報の収集に重点を置いた専門企業、あるいは地場企業が約400社あります。
個々の消費者は自発的に消費者信用情報サービスにデータを提供しません。むしろ、消費者信用情報サービスは消費者の個人情報をファーニッシャー(ファーニッシャーとは、消費者情報を消費者信用情報サービスに提供する会社のこと。ファーニッシャーの例として、銀行、貯蓄金融機関、信用組合、貯蓄貸付機関、住宅ローン融資会社、クレジットカード発行会社、回収代行会社、消費者金融、自動車ローン融資会社が含まれる。)から積極的に収集しています。この情報には、クレジット返済、テナント支払い、雇用、保険金請求、逮捕歴、破産、小切手作成、口座管理に関する過去のデータが含まれます。消費者信用情報サービスは、こうした情報をまとめ、分析し、企業へ販売します。個人には、このプロセスを「オプトアウト」する機会はありません。
消費者信用情報サービスによって提供される消費者データを使用して、企業は、財務上・取引上のリスクを識別し、管理します。たとえば、融資会社は、貸付を行うか否か、あるいは対応する金利を決定する際にこの報告書およびクレジットスコアに依存します。保険会社はこの情報を使用して保険料を設定します。雇用主はこの情報を使って、見込みのある従業員が詐欺を働くリスクについてスクリーニングすることができます。公益事業および電気通信サービスプロバイダは、レポートを使用して顧客の身元を確認し、新規顧客に対する前払いの要件を決定します。
連邦機関は、連邦のベネフィットとサービスに対する新規申請者を登録する際に、1つ以上の消費者信用情報サービスによって提供された本人確認サービスを使用します。例えば、米国内国歳入庁(IRS)は、2017年の情報漏洩が公表された後、Equifaxが提供する納税者の身元確認・検証サービスをために725万ドルの契約をしています。
図1:Equifaxはどのように個人情報を受領するか?
各消費者信用情報サービスには、個人のクレジットレポート情報を評価し、クレジットスコアを割り当てるための独自のモデルがあります。クレジットスコアは、様々な金融行動を予測するために使用される数値メトリックです。クレジットスコアモデルは、クレジットスコアを決定する際に、次の要因を測定します。(1)支払い履歴(2)クレジット利用歴(3)信用履歴の長さ(4)新しいクレジットアカウントの作成・要求(5)クレジットミックスが挙げられます。消費者信用情報サービスはこの情報を分析し、個人のクレジットスコアを作成します。消費者信用情報サービスは同じ情報を収集する傾向がありますが、重み付けや特定の要素を異なって評価することもあります。その結果、個人のクレジットスコアはEquifax、Experian、TransUnionの間で異なる可能性があります。
消費者信用情報サービスは、これらのクレジットスコア、そして対応する詳細なクレジット報告を特定の目的のためで様々な事業に販売しています。たとえば、顧客がローンを申し込むと、消費者信用情報サービスはその顧客のクレジットスコアと詳細なレポートを融資会社に販売することができます。融資会社は、消費者信用情報サービスのレポート内の顧客についての情報を使用して、お金を融資するか、適用する金利をどうするか、頭金が要求すべきか決定します。
消費者信用情報サービスのビジネスモデルの性質により、Equifaxは消費者の生活を詳細に把握することができます。多数の情報源を組み合わせることで、Equifaxは個人の入国状態、収入、富、資産、銀行口座残高、現在および過去の住所、雇用主、借入履歴、光熱費の支払い、支出習慣を知ることができます。消費者信用情報サービスはこうした情報をおせっかいにも保有しているため、こうした企業は最高レベルのデータ保護とサイバーセキュリティの実践とツールを整備する義務を負っています。 しかし、Equifaxには最高レベルのセキュリティを実現していませんでした。
B. Equifax - データ分析産業における積極的な成長とリスクの増大
Richard Smith氏は、Equifax CEOとして、任期開始時に野心的な成長戦略を開始しました。2017年の情報漏洩が発生したとき、Equifaxは8億2000万人の消費者と9100万件の企業に関する信用情報を持っていました。 この膨大な量の機密情報により、Equifaxはハッカーの最初の攻撃対象となりました。また、Equifaxはこうしたセキュリティ上のリスクに対する準備ができていませんでした。
1. エクイファックスの会社概要
Equifaxは、1899年にジョージア州アトランタで設立され、1965年に上場企業となりました。全世界で10,300人の従業員を擁し、北米、中南米、ヨーロッパ、アジア太平洋地域の24か国で事業を展開しています。 8億2000万人の消費者と9100万人以上の企業の信用情報を取り扱っています。スタンダード&プアーズ(S&P)500インデックスに加盟しており、その普通株式はニューヨーク証券取引所でEFXシンボルで取引されています。
2018年10月26日、Equifaxの市場価値は117.2億ドルでした。その比較として、2017年の情報漏洩を発表された前日、Equifaxの市場価値は170.2億ドルでした(図2参照)。 同社は、2017年に33億6,200万ドルの収益を上げています。2017年9月7日の情報漏洩発表に続き、世間の批判を受けても、同社の2017年の売上高は2016年から7%増加したと報告しています。
図2:Equifaxの株価(2017.08 - 2018.09)
Equifaxの第3四半期決算報告の前に、Equifaxの株式は情報漏洩前の価格にほぼ戻り、2018年9月中旬に138.06ドルに達しました。Equifaxは2018年10月24日に第3四半期決算報告を発表しました。この決算報告によると、Equifaxは四半期ごとの売上と利益が減少しており、情報漏洩に関連するコストは増加する一方でした。それを受けてEquifaxの株価は17%以上下落し、その週の終わりを97.19ドルで取引を終えています。
2. CEO Richard Smith氏の成長戦略
2005年12月、Richard Smith氏はEquifaxのCEO(最高経営責任者)として雇われ、すぐに野心的な成長戦略に着手しました。 2007年、Equifaxは14億ドルで1億4,200万人の雇用記録を持つ米国の人事・給与計算サービス会社であるTALXコーポレーションを買収しました。2014年には、英国資本の債権管理会社であるTDXグループを3億2700万ドルで買収し、2016年にオーストラリアの大手クレジット会社Veda Groupを19億ドルで買収しました。
合計して、Equifaxは18社を買収しました。この買収により、Equifaxは世界最大の消費者信用情報サービスの一つとなりました。Richard Smith氏 は、CEOとしての在任期間中、Equifaxの買収成長戦略は、4倍以上もの市場価値成長につながりました。2005年12月では、1株当たり約38ドルから程度でしたが、2017年9月上旬には1株当たり138ドルまで上がりました。
ジョージア大学における2017年8月17日の講演で、Richard Smith氏はEquifaxの事業戦略を説明しました。彼は以下のように述べています。
私たちは何をしている企業なのでしょうか?私たちは、膨大な量の非常にユニークなデータを管理しています。事実、私たちは10億人に近い個人のデータ、世界中にある1億近い企業のデータを保有しています。データ資産はとても膨大で、とてもユニークです。その中には、クレジットデータなどの財務情報が含まれます。私たちは個人に関する20兆ドルの資産データを持っているので、あなたが持っている年金、投資信託、株式の数もわかります。資産データも約20兆ドル分あるので、所有する可能性がある資産の詳細、例えば購入時の価値、現在の価値、光熱費データ、マーケティングデータなど、様々と情報を掘り下げることができますが、本当に考えられないほど大量のデータなのです。実際…世界最大の図書館を思い浮かべてみると、議会図書館が思いつきますが、我々は毎日、その1200倍のデータを扱っています。
3.「大量のデータ」が大量のセキュリティリスクに等しい
1か所に大量の個人情報があることで、Equifaxはハッカーの最初の対象になりました。近年、消費者信用情報サービスが複数のサイバー攻撃の標的になっています。たとえば、主要な消費者信用情報サービスの1つであるExperianでは、2つの大規模情報漏洩事件が発生しました。2013年に、個人情報漏洩を企んでいた男性が、2012年に買収されたExperianの子会社をだまして、2億人を超える消費者の個人データと財務データに直接アクセスできるようにしました。この男性は、Experianの知らないところで、買収後10か月近くにわたり、消費者データを吸い上げ続けました。また2015年には、Experianは、ワイヤレスプロバイダT-Mobileから融資を申請した人々について、1500万の社会保障番号と他のデータを盗んだそのコンピュータシステムからの情報漏洩を明らかにしました。Experianは、内部サーバの侵害により、名前、生年月日、住所、社会保障番号、運転免許証番号などが漏洩しました。
Equifaxはこうしたリスクに対して準備ができていませんでした。金融指標提供サービスを手掛けるMSCI Inc.が発表した2016年8月のレポートでは、Equifaxのデータセキュリティへの取り組みが、10のうち0と評価されました。2017年4月時点での評価にも変更がありませんでした。両報告書は次のように結論づけています。
Equifaxのデータセキュリティとプライバシー対策は、情報漏洩事件を防ぐ上で不十分であることが証明されています。同社の消費者信用情報事業は、データ盗難とそれに伴う評判への高いリスクに直面しています。 同社のデータ、そしてプライバシーポリシーは範囲が限定されており、Equifaxは情報漏洩計画や情報セキュリティポリシーとシステムの定期的監査の証拠を示していません。
4. ITおよびセキュリティ担当のEquifax担当者
情報漏洩発生時において、EquifaxのITおよびサイバーセキュリティ業務を指揮していた2人の人物は、CIO David Webb氏とCSO Susan Mauldin女史でした。この情報漏洩時において、SVP兼Global Corporate Platforms担当CIOを務めるGraeme Payne氏も重要な役割を果たしました。委員会は、Equifaxの2017年の情報漏洩に関する1年間の調査において、3人の個人とのインタビューを実施しました。
David Webb氏は、1977年からテクノロジー分野で働き始めました。2010年には、EquifaxはグローバルIT基盤の責任を担うCIOとして David Webb氏を雇いました。Susan Mauldin女史は、1983年からHewlett Packard社のソフトウェアエンジニアとしてテクノロジー分野のキャリアを始めました。他の企業において、ITとセキュリティポジションを経験した後、2013年8月にEquifaxのCSOとして採用され、サイバーセキュリティとビジネスレジリエンスの担当となりました。Graeme Payne氏は、2011年にEquifaxのITリスクとコンプライアンスのVPとして採用される前は、民間企業で様々なITとテクノロジー役割を担っていました。2014年7月、EquifaxはGraeme Payne氏をSVP兼Global Corporate Platforms担当CIOに昇進させ、CIO David Webb氏がレポートラインとなりました。この役割では、Graeme Payne氏は「企業がビジネス、財務、人事、法務、マーケティング、販売、会社に収益を生み出さない管理機能を運営する上で必要な全てのビジネスシステムの支援に責任を持つ」ことでした。2016年4月にEquifaxのIT組織内で組織再編が行われ、Graeme Payne氏はアクセス管理、IT監査とITセキュリティの調整に関する責任を引き受けました。
II. 消費者信用情報サービスに対する規制
消費者信用情報サービスは、消費者情報を保護するために設計された様々な連邦法の規制を受けます。他の民間企業と同様、消費者信用情報サービスはセキュリティインシデントによって情報漏洩された場合、消費者に通知する必要があります。情報漏洩が発生した場合、影響を受ける個人に通知すべしと組織の責任を義務付けた包括的な連邦法は存在しません。その代わりに、Equifaxのような事業体は、50の異なる州で定めた独自の情報漏洩通知法(Breach Notification Law)を遵守する必要があります。以下の説明では、Equifaxのような消費者信用情報サービスに適用される、情報漏洩の開示と通知要件を含む、既存の規制と執行ツールについて説明します。
A. 消費者信用情報サービスに対するFTC・CFPBの権限
連邦取引委員会(FTC:Federal Trade Commission)と消費者金融保護局(CFPB:Consumer Financial Protection Bureau)は、どちらも消費者信用情報サービスに対する執行権限を持っています。公正信用取引法(FCRA:The Fair Credit Reporting Act)とグラム・リーチ・ブライリー法(GLBA:Gramm-Leach-Bliley Act)は、消費者信用情報サービスを規制する二つの主要な連邦法です。連邦取引委員会(FTC)は、一部の例外を除いて、消費者情報を管理する法律違反について組織を調査し、執行する権限を持っています。2010年、ドッド・フランク法(Dodd-Frank Act)は、公正信用取引法に含まれる条文の大半に違反し、ドッド・フランク法に基づいて不公平、欺瞞的、悪意のある行為や慣行を行った消費者信用情報サービスに対する、消費者金融保護局の執行権限を得ています。
1. 連邦取引委員会法(Federal Trade Commission Act)
「商業に影響を与える不公正かつ欺瞞的な慣行」を禁止する連邦取引委員会法(FTC法)の第5条にもとづいて、連邦取引委員会(FTC)は権限を行使し、データセキュリティ侵害を訴求します。2002年以来、連邦取引委員会(FTC)は、消費者の個人情報を適切に保護することに失敗したことにより、不公正かつ欺瞞的な慣行に従事した企業に対し、およそ60件以上の訴訟を行ってきました。連邦取引委員会(FTC)の基本的なアクションは、違法行為をした企業に対する法の執行し、当該行為を是正するために積極的な措置を講じるよう求めます。積極的な措置には、包括的なデータセキュリティプログラムの実施や、消費者に対する金銭的弁済などが含まれます。
連邦取引委員会(FTC)は、連邦取引委員会(FTC)の命令や公正信用取引法(FCRA)、およびその他のプライバシー保護法の違反に対して民事法に基づいた罰金を科すことができます。また、連邦取引委員会(FTC)は、連邦取引委員会法(FTC法)に違反した場合、連邦裁判所で民事訴訟を行うこともできます。連邦裁判所は、連邦取引委員会法(FTC法)第5条に違反した場合、連邦取引委員会の権限を活用してデータセキュリティ活動を規制することを支援しています。しかし、連邦取引委員会(FTC)は連邦取引委員会法(FTC法)への継続的な遵守に対して、消費者信用情報サービスのデータセキュリティ活動を検査する権限を保持していません。
2. ドッド・フランク法(Dodd-Frank Act)
2010年に施行されたドッド・フランク法は消費者金融保護局(CFPB)を設立しました。ドッド・フランク法は、連邦消費者金融法を強制し、執行する責任を消費者金融保護局(CFPB)に与えました。消費者金融保護局(CFPB)の権限は(1)金融機関に報告要件を課し、検査する権限を含む監督権限(2)公正信用取引法(FCRA)およびグラム・リーチ・ブライリー法(GLBA)などの特定の規定を含む、様々な消費者保護法および規制の執行(3)規則制定、の大きく3種類に分類されます。その規則制定権限の範囲内で、消費者金融保護局(CFPB)は「特定の行為・慣習が不当、欺瞞的、または悪意のあるため違法である」と宣言できる規則を試行する権限を持ち合わせています。
ドッド・フランク法は、消費者信用ビジネスからの年間受領額が700万ドルを超える消費者信用情報サービスなど、「他の消費者金融商品・サービスのための市場の主要プレイヤー」を含む銀行以外の事業体に対して、消費者金融保護局(CFPB)の監督権限を与えました。
消費者金融保護局(CFPB)には、以下の目的のために報告を求め、検査を実施することが含まれています。(1)連邦消費者金融法要件の遵守状況の評価(2)ビジネス活動・コンプライアンスの仕組み・手順に関する情報の入手(3)消費者、および消費者金融商品・サービスの市場に対するリスクの検出・評価。消費者金融保護局(CFPB)は、継続的にいくつかの大規模な消費者信用情報サービスを監視しています。この監督は、データセキュリティではなく、消費者情報の正確性に関する公正信用報告法(FCRA)の要求準拠に重点を置く傾向があります。
ドッド・フランク法は、消費者金融保護局(CFPB)に不当、欺瞞的、または悪意のある行為・慣習を行う金融機関に対して介入する権限を与えています。2016年3月には、消費者金融保護局(CFPB)はデータセキュリティの取り組みについて詐欺的な陳述を行ったとして、企業に対する最初のデータセキュリティ執行措置を発表しました。消費者金融保護局(CFPB)は、消費者信用情報サービスに対して、過去に不正行為を理由に執行措置を取りましたが、これらの執行措置はデータセキュリティとは関係ないものです。
3. 公正信用報告法 (Fair Credit Reporting Act)
1970年、議会は消費者信用情報サービスが保持する消費者ファイルについて、情報の正確性とプライバシーを促進するために公正信用報告法(FCRA)を制定しました。公正信用報告法(FCRA)は、信用ファイル内のセンシティブ消費者情報をまとめる消費者信用情報サービスを含む組織体に責任を課す法律です。例えば、公正信用報告法(FCRA)では、「機密性、正確性、関連性、および情報の適切な活用について、公正かつ公平な方法で、消費者の信用、役職、保険、およびその他の情報について、商取引のニーズを満たす合理的な手続きを採用すること」を消費者信用情報サービスに求めています。
二つの政府機関が、公正信用報告法(FCRA)の要求を監督する責任を負っています。第一に、公正信用報告法(FCRA)は、要件へのコンプライスを強制する権限を連邦取引委員会(FTC)に与えています。連邦取引委員会(FTC)は、公正信用報告法(FCRA)に違反した企業に対して100以上のアクションを取り、罰金として30億円を徴収しています。第二に、ドッド・フランク法は消費者金融保護局(CFPB)に対して、公正信用報告法(FCRA)を強制する権限を与えています。連邦取引委員会(FTC)と消費者金融保護局(CFPB)は、当局間の了解覚書にて、双方の責任範囲を調整しました。覚書は、調査を開始したり、公正信用報告法(FCRA)違反への法的手続きを進める際には、片方の機関がもう片方の機関へ連携することを定めています。
公正信用報告法(FCRA)によれば、消費者信用情報サービスは、消費者報告書中に記載された不正確・不完全な情報について、消費者は申し立てをでき、訂正できる手続きを持たないといけません。この要件を満たすために、Equifaxは自社のレポートに含まれる情報への申し立てをする方法として、3種類の方法を提供しています。(1)電話による申し立て(2)書面による郵送による申し立て(3)EquifaxのHP上にあるオンラインポータルからの申し立て。Equifaxは、1970年代に消費者申し立てを処理するために消費者苦情ポータルであるACISシステム(ACIS)を構築しました。Equifaxが申し立てを受け取ると、消費者の信用ファイルを検索し、調査プロセスを追跡するためACISシステムで事案を開始します。消費者は、ACIS Webポータルを介して、自分の信用情報申し立てに関連する文書のコピーを提出することができます。
4. グラム・リーチ・ブライリー法
グラム・リーチ・ブライリー法(GLBA:Gramm-Leach-Bliley Act)では、顧客情報の安全性と機密性を確保するための基準と保護の確立をFTCに義務付けています。特に、グラム・リーチ・ブライリー法(GLBA)の条項501(b)は、連邦取引委員会(FTC)に対して「(1)顧客の記録・報の安全性と機密性を保証するため(2)こうした記録の安全性・完全性に対して、予想される脅威・危険から保護するため(3)いかなる顧客に対しても実質的な損害・不都合をもたらす可能性がある記録・情報への不正なアクセス・利用から保護するため、組織的、技術的、物理的な安全保護措置(Safeguard)に関する管轄対象となる金融機関に対して、適切な基準を確立すること」を求めています。
GLBAの実施の一環として、連邦取引委員会(FTC)は2003年に「安全保護措置ルール(Safeguards Rule)」を公表しました。この規則は、顧客情報の安全性・機密性に保つため、包括的な情報セキュリティプログラムを開発・実施・維持することを消費者信用情報サービスに要求しています。このプランは、企業の規模・複雑さ、活動の性質・範囲、とり扱う顧客情報の機密性に適合していなければなりません。この規則では、各消費者信用情報サービスは次のことを行う必要があります。
- 情報セキュリティプログラムを調整するため、一人以上の従業員を指名する。
- 会社事業に関連する各分野の顧客情報に対するリスクを特定・評価し、これらのリスクを管理するための現在の安全策の有効性を評価する。
- 安全保護措置プログラムを設計・実施し、それを定期的にモニタリングして、テストする。
- 適切な安全保護措置を維持し、契約が安全保護措置の維持を要求していることを確認し、顧客情報の取り扱いを監督できるサービス提供者を選択する。
- 会社の事業・業務の変化、あるいはセキュリティのテスト・監視の結果を含む、関連する状況に照らしあわせて、プログラムを評価・調整する。
連邦取引委員会(FTC)が安全保護措置ルールを制定してから1年後に、企業がこれらの要件を遵守していることを確認するために全国的なコンプライアンス点検が実施されました。消費者の個人情報を守ることに失敗し、安全保護措置ルールへ遵守できていない企業に対して、連邦取引委員会(FTC)は強制的に執行することができます。但し、消費者金融保護局(CFPB)は安全保護措置ルール以上の権限を持っていません。
グラム・リーチ・ブライリー法(GLBA)の下では、金融機関は、「プライバシー規則」を遵守しなければなりません。この規則では、対象となる企業は、プライバシーポリシー・実施内容を消費者に説明すべきとする内容です。グラム・リーチ・ブライリー法(GLBA)は、プライバシー規則の実装・実施に責任を負います。
2017年9月、FTCとCFPBの両方が、Equifaxの情報漏洩調査を公に確認しました。2018年10月25日、Equifaxは進行中のFTCおよびCFPBの調査に関する最新情報を、米国証券取引委員会(SEC)に提供しました。その中で、Equifaxは以下のように述べています。:
2018年6月13日、CFPBとFTCは私たちに以下の通知を提供しました。その通知には、CFPBとFTCの職員は、各機関が私たちに対して訴訟を起こすこと、当局が我々に差止命令による弁済・損害賠償・罰金を求めることを勧告することを検討しているという内容です。我々は、CFPBとFTCに対し、彼らの予想される申し立てに対処するため、書面による回答を提出し、我々は引き続き調査において各機関と協力しています。
B. 情報漏洩の通知・開示の要件について
情報漏洩が発生した後、民間企業は、開示・通知要件に関する無数の規制・法律を遵守する必要があります。例えば、Equifaxの関係者は、FTC・SEC・州政府官僚・FS-ISACに2017年の情報漏洩について通知しました。
包括的な連邦情報漏洩通知法はありませんが、50州すべてが、個人情報に影響を与えるセキュリティ侵害について、民間企業が個人に通知することを義務付ける法律を制定しています。州で制定された情報漏洩通知法を以下の要素を含んでいます。
- どの事業体が法律を遵守しなければならないか?
- どのような個人情報が保護されているのか、情報漏洩の定義は何か?
- 通知を行う条件は、どの程度の実害が発生した場合か?
- 通知を配信する方法・時期は?
- 例外やセーフハーバールールは?
- 他の州法との優先度と他の連邦法との関係性
- 罰則、執行機関、および、影響を受けた人々に対する救済策
州が定める情報漏洩通知法の間に起こる矛盾の一例は通知要件です。一部の州では「合理的な遅滞なく」通知を行うことを要求する一方、情報漏洩に気付いてから45日以内に民間企業に要求する州法もあります。州法の差異が生まれる別の観点として、個人情報の定義が挙げられます。つまり、漏洩した情報の種類に基づいて、同じ種類の消費者情報が盗まれたとしても、民間企業はある州の消費者に通知する義務がある一方、別の州の消費者には通知する必要はない場合があります。
州職員に対して情報漏洩通知を提供することに加えて、民間企業は、サイバーセキュリティのリスクとインシデントを投資家に開示要求される場合があります。 2011年10月、SECは、上場企業はサイバーセキュリティリスクとインシデントの開示を義務付ける拘束力のないガイダンスを発表しました。このガイダンスによれば、サイバーセキュリティのリスク・インシデントが「投資家にとって十分に大切」ならば、民間勧業は有価証券届出書、財務諸表、8-Kフォームの情報の開示が要求されるかもしれません。
Equifaxは、2017年における情報漏洩前に、サイバーセキュリティリスクとセキュリティインシデントに関してSECに開示していませんでした。2017年の情報漏洩後、Equifaxは2017年と2018年度の情報漏洩に関する情報を開示するようになりました。
III. Equifax情報漏洩事件の事後分析
Equifaxでのサイバーセキュリティに関する自己満足の文化は、1億4800万人の個人情報の流出につながりました。Equifaxは、既知の深刻な脆弱性にパッチを適用しなかったため、システムは145日間危険にさらされていました。ファイル改竄検知やネットワークセグメンテーションなど、基本的なセキュリティ対策の実装の失敗したため、攻撃者は大量のデータにアクセスして削除できました。 ACIS環境を通過する暗号化されたネットワーク通信を監視するためのデジタル証明書は、情報漏洩に気付くまでの19か月間有効期限が切れていたため、攻撃者は情報を持ち出すことができてしまいました。この章では、2017年の情報漏洩を引き起こしたイベントの詳細について分析していきます。
A. Apache Strutsの脆弱性が公開され、Equifaxはパッチ適用を試みた(2017年2月〜3月)
Apache StrutsはオープンソースのWebアプリケーションフレームワークです。特にApache Strutsはミドルウェア(OSとアプリケーションの間で動作するソフト)であり、OS上でアプリケーションを正常に動作することを支援するソフトウェアです。
2017年2月14日
Apache Software Foundationは、Apache Strutsの複数のバージョンにおける脆弱性について、最初の報告を受けました。複数のバージョンの134に見つかりました。この脆弱性を発見したセキュリティ研究者は、セキュリティメーリングリストを通じてApacheにバグを報告しました。
2017年3月7日
Apache Strutsプロジェクト管理委員会(PMC)がApache Strutsの脆弱性を一般に公開しました。これは、Apache Strutsがサーバに送信するデータを処理する方法に関連する脆弱性でした。これにより、リモートからの任意のコード実行を可能にするファイルアップロード機能を利用し、攻撃者は悪意のあるコードやコマンドをサーバに送信することができます。National Vulnerability Databaseの脆弱性の影響分析では、この脆弱性を悪用する攻撃の複雑性は低く、侵害されたシステムで機密性、整合性、およびリソースの可用性が完全に失われる可能性が高いことが示されました(図3参照)。 National Vulnerability Database は、IT脆弱性管理データに関する政府機関のリポジトリです。
図3:National Vulnerability Database CVE-2017-5637のインパクト分析
Apache Strutsの脆弱性が公開されると、セキュリティ研究者らはすぐに多くの悪用を試みるリクエストを確認しました。ある会社では、ハッカーが簡単なコマンド(例えば、whoami)だけでなく、複雑なコマンドを試みているのを観察しました。3月7日には、Apache Struts脆弱性を悪用する方法に関する情報が、中国のセキュリティサイトFreeBuf.com、そして無償のハッキングツール群であるMetasploitにて公開されています。Apache Struts プロジェクト管理委員会は、同じ日にこの脆弱性に対するパッチを公開しました。
2017年3月8日
米国国防省のUS-CERTは、EquifaxにApache Struts脆弱性にパッチを当てる必要性を警告する通知を送っています。Global Threat and Vulnerability Management(GTVM)チーム、および元CSO Susan Mauldin女史を含むEquifaxの複数のスタッフが、US-CERTの電子メールを受け取っています。
2017年3月9日
Equifaxは、GTVMのメーリングプロセスを通じて、US-CERTの通知を共有しました。大体、430名の個人と様々なメールアドレスがこの通知を受け取りました。このメールは、Apache Strutsのインストールを担当する担当者に、特定のApache Struts 2バージョンにアップグレードするよう指示する内容でした。GTVMのメールによると、「この脆弱性の攻撃コードは既に公開されており、現時点でも悪用されている事例があるため、重大なリスクにさらされています。そのため、セキュリティポリシーに従い、48時間以内にパッチを適用する必要があります。」 と書かれています。
Equifaxのセキュリティチームは、脆弱なバージョンのApache Strutsシステムを識別するため、オープンソースの脆弱性スキャンを実施しました。しかし、脆弱性スキャンは影響を受けるバージョンのApache Strutsを利用したシステムを発見できませんでした。暫定CSOのRuss Ayres氏は、スキャンをルートディレクトリにのみ実施し、Apache Strutsが配置されているサブディレクトリに実施しなかったため、脆弱性スキャナが脆弱性を見逃したと述べています。
2017年3月10日
(Equifaxに依頼を受けたMandiant社により行われた事後のフォレンジック調査により)Equifax環境において、Apache Struts脆弱性が悪用された最初の痕跡が残っている日です。(図4の「初期偵察」ステップ)。攻撃者は「whoami」コマンドを実行してEquifaxネットワーク上に接続されている他の脆弱なサーバを発見しました。しかし、Mandiant社によれば、この日(3月10日)のアクションが5月13日からの情報漏洩活動につながる明確な関連性を示す証拠は確認できませんでした。
2017年3月14日
Equifaxの脅威分析チーム(Emerging Threats Team)は、Snortのルールを作成しました。これは、特定の脆弱性を検知し、対応を行う侵入検知ツールで、Apache Strutsを悪用する攻撃を検知するために作成されました。Equifaxの対策チームは、この日(3月14日)にIDS・IPSに対してこのApache Struts脆弱性の不正利用を検出するSnortルールをインストールしました。
2017年3月15日
この日、EquifaxはMcAfeeからApache Strutsの脆弱なバージョンを検出する新しいシグネチャルールを取得しました。同社は、このシグネチャとMcAfee Vulnerability Managerを使って二度、外部公開システムをスキャンしました。Equifax が管理する958個の外部公開用IPアドレスをチェックしましたが、脆弱性が確認できたインスタンスは確認できませんでした。言い換えれば、パッチ適用プロセス中にEquifaxによって使用されたスキャンツールは両方、脆弱なバージョンのApache Strutsを特定することに失敗しました。
2017年3月16日
GTVMチームが主催する月例会議でApache Strutsの脆弱性が議論されました。GTVM会議のスライドでは、この脆弱性が現在悪用されているため、Apache Strutsのインストール担当者にバージョン2.3.32、あるいは2.5.10.1にアップグレードするように通知しました。このスライドは、ミーティング終了後にGTVMチームのメーリングリストに流され、430名の個人がこのスライドを受け取りました。
B. Equifaxからの情報漏洩と検知されなかった空白の76日間(2017年5月〜7月)
図4:攻撃のライフサイクル
2017年5月13日 - 7月30日 5月13日において、攻撃者はACIS環境内にあるApache Strutsの脆弱性を介してEquifaxネットワークに侵入しました(初期侵入のステップは図4参照)。ACIS環境は、インターネット公開用の業務用システムで、個人が信用ファイル内で見つかった誤った情報を申し立てるために利用し、もともとはFCRAの要求を満たすために1970年代に構築したシステムです。ジョージア州アルファレッタのデータセンター内にある、複雑かつ古いITシステムで運用されていました。
Apache Strutsの脆弱性を介してACIS環境に侵入した後、攻撃者は最初のWeb Shellをアップロードしました。これは、サーバをリモートから操作することを可能にするため、侵入先のサーバにアップロードする悪質なスクリプトです(図4の足場構築ステップ)。本質的に、Web Shellは、攻撃者が侵入先のシステムに再侵入して操作するための秘密のバックドアを提供します。
ACIS環境は、2台のWebサーバと2台のアプリケーションサーバで構成され、Webサーバ周辺にファイアウォールが設定されていました。攻撃者は、アプリケーションサーバのApache Strutsの脆弱性を悪用してこれらのファイアウォールを迂回しました。一度内部に入ると、攻撃者は両方のアプリケーションサーバにWeb Shellを作成しました。これにより、攻撃者はアプリケーションサーバ上で直接コマンドを実行することが可能になりました。大体、30種類のユニークなWeb Shellが攻撃に使われています。Mandiant社によれば、不正なネットワーク変更を検知し、アラートを出すことにより、ファイル改竄検知はこうしたWeb Shellの作成を発見できたはずだと指摘しています。しかし、攻撃時にACISシステムでファイルの改竄監視が有効になっていませんでした。
最初のWeb Shellをインストールした後、攻撃者は設定ファイルデータベースに保存されている暗号化されていないアプリケーション認証情報(例:ユーザー名とパスワード)が含まれているマウントされたファイル共有へアクセスしました(図4の「特権の昇格」ステップ)。マウントとは、OSがストレージデバイス上のファイルやディレクトリを、コンピュータのファイルシステムを介して内部アクセスできるようにするプロセスです。Equifaxは社内の古いITシステムで機密ファイルへのアクセスを制限していないため、攻撃者はファイル共有にアクセスすることができました。暫定CSOのRuss Ayresは、この方法で認証情報を保存することは、Equifaxのポリシーと矛盾していると述べています。
ACISアプリケーションは、ビジネス機能を実行するためにEquifax環境内の3つのデータベースにのみアクセスできればよかったのですが、ACISアプリケーションは他の無関係なデータベースをセグメントとして切り離していませんでした。その結果として、攻撃者は取得したアプリケーション認証情報を使い、ACIS環境外の48個の無関係なデータベースへのアクセスすることができました。
攻撃者はこれらのデータベースに対して約9,000のクエリを実行し、機密情報が格納されたエリアにアクセスしました(図4の「内部偵察」のステップ)。攻撃者は特定のテーブルからメタデータを取得し、テーブル内に含まれる情報の種類を把握しました。攻撃者は個人情報を含むテーブルを見つけ、そのテーブルからデータを取得するため、追加クエリを実行しました。9000のクエリのうち265クエリは、攻撃者はEquifax環境内から個人情報を含むデータ群を引き出すクエリでした。しかし、このデータ群の中には、暗号化された個人情報は含まれていませんでした。
攻撃者は、265クエリで取得できた個人情報をファイルへ保存しました。そして、ファイルを圧縮して、Webからアクセス可能なディレクトリに配置しました。次に、攻撃者はwgetツール(ユーザーがコマンドを発行し、Webサーバからコンテンツを取得することができる一般的なシステムユーティリティツール)を介してコマンドを発行し、Equifaxの環境から情報を持ち出そうとしました。攻撃者はまた、Webシェルを使用してデータの一部を持ち出しました(図4の「任務の完了」ステップ)。攻撃者は、約35の異なるIPアドレスを使用してACIS環境とやり取りしました。
この攻撃がEquifaxの従業員によって発見されるまで、76日間続きました。期限切れのSSL証明書により、EquifaxはACIS環境内のトラフィックを監視できませんでした。SSLは、WebブラウザとWebサーバ間の暗号化通信を可能にする標準的なセキュリティプロトコルです。この安全な接続を確立するには、復号化が行われる部分に有効なSSL証明書をインストールする必要があります。SSL証明書は、発行された日付に応じて27ヵ月か39ヵ月の寿命があります。この期間が過ぎると証明書は期限切れになり、もう一度有効にするには更新し交換する必要があります。
期限切れのSSL証明書は、SSL可視化アプライアンス(SSLV)と呼ばれるトラフィック監視デバイスにインストールされました。このデバイスにより、Equifaxは、ACISサーバに送信する前に、分析目的で通信を復号化することで、ACISプラットフォームとの間でやり取りされる暗号化通信を検査できました。IDSとIPSの両方は、この監視デバイスの背後にありました(図5を参照)。
図5: SSLVアプライアンスを経由した外部コンピュータからのトラフィック通信
このデバイスのデフォルト設定では、SSL証明書が期限切れになった場合でもWebトラフィックがACISシステムへ届くように許可されていました。しかし、ツールは暗号化された通信を分析できないため、証明書が期限切れになった場合、インターネットを出入りする通信はIDSによって分析することができません。
入手した文書によると、ACISドメインai.equifax.comを監視しているSSL可視化アプライアンスにインストールされたSSL証明書は、2016年1月31日に有効期限が切れました。結果として、Equifaxは19か月間ACIS環境のネットワーク通信内容を確認することができませんでした。
C. Equifaxが情報漏洩を発見し、Project Sierraを開始(2017年7月 - 8月)
2017年7月29日
Equifax対策チーム(Equifax Countermeasures team)は、ACIS環境が存在するジョージア州アルファレッタのデータセンターにあるSSL可視化アプライアンスに、67の新しいSSL証明書をアップロードしました。これにより、同社はACISアプリケーションから送受信される通信の検査を再開できました。対策チームは、セキュリティアラートの急激な増加を受けてアプライアンスとIDSを監視しました。
対策チームは、復号化がきちんと行われていることを確認するため、パケットキャプチャのレビューを開始しました。パケットキャプチャとは、特定のネットワークポイントを通過する際のデータパケットのコピーに相当します。パケットは、取得したデータの分析のため、一時的に保存されます。フルパケットには、ペイロード(パケットの実際の内容)とヘッダー(パケットの送信元アドレスや宛先アドレスなどの情報)が含んでいます。
調査開始後すぐに、Equifax対策チームは中国のIPアドレスからから発信された疑わしいリクエストを検出しました。チームは疑わしいパケット全体、そしてその他の最近のリクエストを分析しました。最近のリクエスト大半に対するサーバからのレスポンスは10MBを超えるデータであり、信用調査に関連する画像ファイルなども含まれています。
Equifaxは、パケットトラフィックのインデックス化、表示、分析に使用するオープンソースのソフトウェアMolochツールを使用して、ネットワーク通信をインデックス化しました。スタッフが外国からの疑わしい通信に気付いた後、EquifaxはMolochで中国のIPアドレスを検索しました。検索結果によると、2017年7月25日以降、このIPアドレスからACIS Webポータルに継続的にアクセスしたことが判明しました。対策チームは、このIPアドレスをISPでブロックすることを決定しました。期限切れのSSL証明書が原因で、EquifaxはACISアプリケーションに対して行われたリクエストの詳細を含め、7月29日以前に攻撃者が何をしたか、判断できませんでした。
2017年7月30日
EquifaxはACISアプリケーションの脆弱性テストを実施することにより、事件の調査を続けました。EquifaxはACISアプリケーションにおいてコードの欠陥を発見し、SQLインジェクション、および安全でない直接オブジェクト参照(Insecure Direct Object Reference)攻撃に対して脆弱であることがわかりました。SQLインジェクション脆弱性は、攻撃者がデータベース情報を操作したり、検索したりすることを許してしまいました。直接オブジェクト参照の脆弱性は、適切な認証や許可を必要とせず、システムデータに直接アクセスすることを可能にしてしまいました。EquifaxがApache Struts脆弱性について知った後、2017年4月にACISアプリケーションの脆弱性診断が行われ、未修正の脆弱性がないことを確認しました。しかし、2017年4月の脆弱性診断と2017年7月30日の脆弱性診断において、異なる結果がでた理由は明らかにされていません。
Equifaxのフォレンジックチームは、個人情報を含んだ可能性が高いデータが外部に持ち出されていることを発見しました。Equifaxは、ドイツのISPが所有されているが、中国のプロバイダにリースあれている、2つ目のIPアドレスからの不正な通信群を発見しました。この発見から、Equifaxは、7月30日、午後12時41分に緊急メンテナンスを理由にACISのWebポータルをシャットダウンすることを決めました。サイバー攻撃は、システムがオフラインになった段階で終了しました。
CSOの一人であるSusan Mauldin女史の従業員の一人が、午後1時30分頃に事件を知らせるよう呼びかけ、できるだけ早くインシデント管理の電話会議に参加するように伝えまし。彼女が電話会議に参加したとき、ITとセキュリティの従業員たちが、ACISをオフラインするロジスティクスを相談しました。Susan Mauldin女史は、次のように証言しています。
- Q. 2017年7月30日に、ACISマシンをオフラインにしたいとチームから報告された時、電話会議で何を言いましたか?
- A.まあ、その時に既に、当該サーバはオフラインにする途中でした。そのため、チームは私に承認を求めていませんでした。なぜなら作業は進行中だったためです。しかし私は…承認する必要はありませんでした。要するに、私はほとんどの時間話を聞いていて、何が起こっているのか理解しようとしました。なぜなら、私は何も状況を知らず、ほとんど新しい話ばかりだったためです。
この電話の直後、Mauldin女史は当時休暇中だったCLO(最高法務責任者)John Kelley氏に、このセキュリティインシデント事件についてメールで連絡しました。Kellyは不在中であるため、法務部チームの一人がカバーしました。Mauldin女史は、その日彼女のEメールに返事を書いた彼らのどちらも思いだしませんでした。
午後6時30分ごろ、Mauldin女史はACISアプリケーションのシニアマネージャ兼グローバルコーポレートプラットフォームのSVP兼CIOであるGraeme Payne氏に電話をかけました。
- A. その議論について最もよく覚えていることは、ACISアプリケーションに関連するセキュリティインシデントが発生したことを彼に連絡したことです。私達は、Apache Strutsを悪用される可能性があると思いましたが、その時点では確信が持てませんでした。サーバがダウンであり、アプリケーションはオフラインだったので、彼の開発チームとセキュリティチームを協力して何らかの調査を行うため、彼の助けが必要でした。そして、攻撃者がApache Strutsを使用していたかどうか、またそのバージョンは何かなどを理解しようとしました。そのため、私達は何が起きたか調査を開始しました。
- Q. 2017年7月30日に電話をしたとき、Payne氏は何かあなたに伝えたんでしょうか?
- A. 性格な言い回しは覚えていませんが、Payne氏は非常に賛成でした…明らかに、これは彼の責任範囲のもとでのアプリケーションであり、彼は確かに助けになることに同意しました。彼は非常に素早く、私たちがお願いしたことを実行してくれました。
7月30日午後7時16分、Payne氏はCIOであるDavid Webb氏に電子メールでインシデントについて連絡しました。
2017年7月31日
Equifaxは、インシデント対応を行うため、コードネームProject Sierraを開始しました。Project Sierraを開始するため、7時から電話会議が始まりました。Equifaxの脆弱性診断チームは、7月30日に行ったACISアプリケーションレビューの検出事項について議論しました。チームは、SQLインジェクション経由でACISアプリケーションに挿入された想定外のJSPファイルを特定しました。JSP(Java Server Pages)ファイルは、サーバにより動的に生成されるWebページです。言い換えれば、JSPファイルがWebサーバ上の適切な場所には配置されれば、攻撃者からのコマンドに答えるWeb Shellとして機能します。コマンドにより、Webサーバはファイル内のコードを処理・実行し、生成されたアウトプットをWebページの形式で返します。
Equifaxは、JSPファイル内に、悪用につながる不正コードを発見しました。この午前7時の電話会議の後、ACISアプリケーション内で2つ目の予期しないJSPファイルが特定されました。
Payne氏とWebb氏は、7月31日(月)の早い時間に、このインシデントについてわかっていることを議論しました。Webb氏は以下のように証言しています。
- A. はい。 あれは月曜日でした。普段私は朝早く出社しますし、Graemeも朝早く出社していました。そこで私たちはこっそり集まり、セキュリティインシデントが発生したこと、何が起こっているのか全くわかっていないこと、そしてセキュリティチームと一緒に調査作業をしていたことを私に教えてくれました。そのため、このような場合、セキュリティチームから指示を受けます。
- Q. 彼は、その時点でインシデントの重大度について何か伝えていましたか?
- A. いいえ。
7月31日現在、Equifaxは攻撃者がどのようにACIS環境に侵入したのか明確にはわかっていませんでした。しかし、Equifaxは攻撃者がApache Strutsの脆弱性を悪用したと考えていました。脆弱性診断チームは、ACISポータルに対する脆弱性のレビューを行い、脆弱性を悪用する方法を検討していました。そしてチームは、2017年1月25日に実行されたスキャンにより、ACISプラットフォーム上で修正されたApache Strutsの脆弱性を確認されました。開発者は、脆弱性診断のチームのスタッフに、アプリケーションのWARファイルを提供していました。WARファイルとは、アプリケーションを実行するために必要なすべてのファイルとJavaのコンポーネントを入れた圧縮パッケージです。ACISアプリケーションでは、WARファイルが脆弱なバージョンのApache Struts環境で実行していることが確認されました。
7月31日の遅い時間、脆弱性診断チームは他のサーバ上でApache Strutsの追加インスタンスを探すマニュアルレビューを実施しました。ACISアプリケーション内の2番目のサーバで脆弱なバージョンであるApache Strutsが発見されました。EquifaxはSSL証明書をロードしていないため、このサーバに関するトラフィックを可視化することができませんでした。Equifaxは、このドメインのSSL証明書を8月3日にアップロードしました。
7月31日において、主任フォレンジックアナリストによって確認された情報に基づき、Mauldin女史は、「その時点で個人情報が流出しているように思えた」と述べた。しかし、David Webb氏にはそのことを伝えていませんでした。Mauldin女史は次のように証言している。
- Q. 私たちが議論していたセキュリティインシデントに関連して個人情報が漏洩した可能性があるという考えを、CIOに報告しなかった特別な理由はありますか?
- A. 特定の理由を覚えていません…正直ほとんど覚えていません。
2017年8月1日
Graeme Payne氏はDavid Webb氏にProject Sierraの調査に関する最新情報を提供しました。Payne氏は、Webb氏に調査は進行中だが、その時点では新しい情報は知られていないと伝えています。これは、2017年8月17日までの間、Project SierraへWebb氏が最後に関与した瞬間でした。なぜなら、Webb氏は8月2日から16日まで休暇で国外にいたからです。
===
Equifaxによる情報漏洩の痕跡発見とそれに関するインシデント対応の調査結果から、影響を受けた個人に通知する方法と時期についての議論が開始されました。その後、Equifaxは影響範囲、すなわち保持していた1億4800万人の消費者に関する機密個人情報が漏洩しているという事実を知りました。そのためEquifaxは、大規模な情報漏洩について公に通知する準備に取り掛からなければなりませんでした。
IV. Equifaxによる大規模な情報漏洩/侵害に関する一般通知
2017年9月7日、Equifaxは推定1億4,300万人の消費者に影響を与える情報漏洩について一般に通知しました。 一般に通知する前に、情報漏洩に関する消費者からの問い合わせを制御するため、専用の通知用Webサイトを作成し、コールセンターを用意しました。また、Equifaxは経営層の入れ替えを行いました。
A. 2017年9月7日公開に向けた準備
Equifaxが情報漏洩を発見し、さらなる攻撃を阻止するための措置を講じた後、同社はフォレンジック調査を行うために外部のサイバーセキュリティ会社を雇いました。 フォレンジック調査により、侵害範囲、侵害された消費者情報の量、および影響を受けた消費者の身元が特定できました。Equifaxは、公に公開する準備を行うため、Project Spartaを始めました。
1. Equifax経営層に報告し、フォレンジック調査を開始
2017年7月31日
CIOのDavid Webb氏は、CEOのRichard Smith氏にセキュリティインシデントについて知らせましたが、入手可能な情報は限られていたと説明していました。David Webb氏は、この時点でCEOにこのことを知らせるのが賢明だと述べています。その理由として、このインシデントには、「Equifaxの顧客が毎年、紛争や苦情を申し出る際に利用するWebサイトが関連しており、そしてオンラインサービスが利用できない場合は、コールセンターに電話が集中するためだ」と述べています。Equifaxは、次の数週間を使って、情報漏洩の公開と、この後に行われる消費者からの綿密な問い合わせと批判に対応するため、慌てて準備を行いました。
2017年8月2日
Equifaxは社外法律顧問に連絡し、情報漏洩について、FBIに通報した。社外法律顧問はサイバーセキュリティ会社であるMandiant社に連絡した。Equifaxは、情報漏洩の包括的なフォレンジック調査を完了させるため、Mandiant社と契約を結んだ。
2017年8月3日
Mandiant社は、8月3日から10月2日までフォレンジック調査を行いました。フォレンジック調査を終了するため、Mandiant社は攻撃者がアクセスしたデータベースを保全し、攻撃者がデータベースにアクセスした際に利用したクエリの検索を行いました。Mandiant社は、Equifax者のサーバ上に攻撃者が残した痕跡に基づき、潜在的な侵入ポイントを特定しました。Mandiant社は、こうした痕跡をもとに攻撃者の行動を再現し、攻撃者がアクセス可能な情報の範囲を発見しました。
2017年8月11日
Mandiant社は、攻撃者によって消費者の個人情報への最初の潜在的アクセスを特定しました。
2017年8月15日 Equifaxの従業員は、当時CEOであったRichard Smith氏に消費者の個人情報が摂取された可能性が高いと報告しました。
2017年8月17日
この日までに、Equifaxは「大量の消費者データが漏洩した」事実を決定しました。Equifaxの上級幹部、Mandiant社の代表者、外部法律顧問は一同に会し、進行中のフォレンジック調査について話し合いました。上級幹部の中には、CEO、CIO、CLO、CFO、そしてACIS環境のビジネス責任者も含まれていました。この会議後もMandiant社は調査を続け、侵害された消費者データの範囲を特定しました。
2017年8月24日~27日
Mandiant社は、攻撃者が大量の個人情報へアクセスしたことを確認しました。Mandiant社は、Equifaxのデータベース管理者とともに、どのデータに攻撃者がアクセスし、どのユーザが影響を受けたか特定しました。これは非常に困難な作業となりました。なぜならEquifaxはデータベース管理者のリストを持っておらず、データベース内の特定のデータを明確に識別できませんでした。 8月24日~25日において、Richard Smith氏はEquifaxの取締役会に情報漏洩を報告しました。
2017年9月1日
Equifaxは、調査、個人情報の侵害規模、通知計画を話し合うために取締役会を開催しました。そして、別の経営層会議が同日行われました。CSO Susan Mauldin女史は、この日の経営層会議に出席し、フォレンジック調査の状況、影響を受けたレコード数、インシデントについて考えられる根本原因、調査を終了するために必要なアクションなどについて述べました。
2017年9月4日
EquifaxはMandiant社のフォレンジックの支援を受けて、影響を受けた約1億4,300万人の消費者のリストを完成させました。 取締役会が召集され、上級幹部がMandiant社の調査に関する最新情報を受け取った一方、他のEquifax従業員は専用の情報漏洩通知サイトを立ち上げ、消費者からの問い合わせを支援するコールセンターを設立する準備に取り掛かりました。
2. EquifaxがProject Spartaを立ち上げ、コールセンターを準備
2017年8月中旬に、EquifaxはProject Spartaと呼ばれる顧客対応の取り組みを開始しました。Project Spartaの目的は、各個人が情報漏洩の影響を受けているか調べ、影響を受けていた場合はクレジットモニタリングとID漏洩サービスへの登録を行う消費者用のWebサイトを作成することです。このプロジェクトの技術リーダの上司はDavid Webb氏、ビジネスリーダの上司はCEOのRichard Smith氏に決定しました。Webb氏は自分の役割は、推定50〜60人のIT従業員を含む十分なリソースをこのプロジェクトに割り当てることであると述べています。CIOを務めるGraeme Payne氏は次のように証言しています。
Project Spartaチームは、顧客に対して現在対応中の情報漏洩について知らせるだけのプロジェクトだといわれていました。そのため、自分たちが何を準備しているのかについては実際には全く理解できていませんでした。しかし、彼らはすべてのシステムの準備を行い、大量の消費者が私たちのシステムへアクセスするためのWebポータルを立ち上げました。
Mauldin女史は、このプロセスにおける彼女の役割は「非常に小さい」と説明しました。セキュリティチームは、公開の数日前に最終的なWebサイトのデザインとセキュリティ管理を見直しました。 彼女は、技術的な議論が多数行われたと述べている一方、この時点では大きなセキュリティ上の問題は指摘されなかったとしています。文書によると、Equifaxはこの外部Webサイトの設計と作成に多大な努力を払っています。
9月7日に公にリリースされるまでの数週間、Equifaxはコールセンター機能を立ち上げるための準備も始めました。Payne氏は、コールセンターを設立する際に直面する課題について、以下のように証言しています。
予想された電話量に備えて、コールセンターを増強する準備を始めなければなりませんでした。Equifaxは一般的にB2B企業であり、消費者対応は不慣れです。だから我々は外部のコールセンター業者をたくさん向かい入れる必要があります。また、私は彼らを支援するために組織化し、全ての手順が準備され、彼らがコールセンター業務を適切に行うために必要なすべてのシステムへのアクセスを適切に設定する必要がありました。
Payne氏は、「Equifax は1週間程度で1,500人のコールセンター担当者を準備しなければならなかった」と述べています。証言と文書によると、2017年9月7日の通知に向けた準備のため、繁忙の局面にありました。
B. 2017年9月 - Equifaxの通知
Equifaxは、2017年9月7日に情報漏洩を公に発表しました。同社はその後、侵害を受けてさらなる情報を求める個人が用意したWebサイトとコールセンターに対して殺到する事態となりました。9月末までに、EquifaxのCIO、CSO、およびCEOは会社を退職しました。
1. 2017年9月7日 – Equifaxが情報漏洩を発表
2017年9月7日、Equifaxは、約1億4,300万人の米国消費者に影響を与える「サイバーセキュリティインシデント」を発表しました。Equifaxは、アクセスされた消費者情報の種類として、名前、社会保障番号、生年月日、住所、運転免許証を含めました。 Equifaxによれば、攻撃者は約20.9万件のクレジットカード番号と約18.2万件の個人情報を含むクレジット紛争文書へアクセスしています。
Equifaxは、追加情報はequifaxsecurity2017.comを確認するように述べています。(図6参照)。Equifaxは、以下の内容をWebサイトに公開しています。
- (1) 顧客の個人情報が侵害されているか否か
- (2) クレジットモニタリングと個人情報盗難防止サービスへの登録への誘導
図6:2017年9月7日 Equifax Webサイト
Equifaxは、この情報漏洩の被害者に、1年間の無料クレジットモニタリングと個人情報盗難防止サービスを提供することを決定しました。これらのサービスには以下が含まれます。(1)3つの主要な信用調査機関による信用報告書の監視(2)Equifaxの信用報告書のコピー(3)Equifaxの信用報告書をロックおよびロック解除する機能(4)個人情報盗難保険(5)社会保障番号の漏洩有無のインターネットチェック
Equifaxは、州法の情報漏洩通知法で定められている通り、情報漏洩を公開するため、50州全ての当局担当者に手紙を送りました。この内容には、情報漏洩の結果と顧客を守るためにEquifaxがとる内容について説明されています。この手紙は、各州で影響を受ける可能性のある住民のおおよその数についても言及されています。
2. Equifaxの発表に伴う他の利害関係者の反応
Equifaxの公表後、Equifaxの株価は最初の週に35%下落し、時価総額で60億ドルが消えました。FTCとCFPBを含む複数の連邦規制当局が、調査を宣言したり、内容を確認する旨発表しました。US-CERTは、Equifaxの情報漏洩を悪用したフィッシング詐欺の可能性について言及しています。多数の議会委員会が聴講会の開催を求め、文書を要請しました。この委員会は2017年9月14日にEquifaxの調査を開始しました。
3. Webサイトとコールセンターの逼迫
公開直後、Equifaxは顧客対応における問題が浮上しました。Webサイトやコールセンターは、多数の顧客からの情報問い合わせに逼迫し、情報漏洩の影響を受けているか否か、消費者に回答しない状態にありました。
a. equifaxsecurity2017.comの問題
Equifax内のProject Spartaチームは、(8月中旬から9月7日までの)約3週間において、1億4300万人の個人からの情報問い合わせをを処理するため、Webサイトとサポート基盤を構築しました。チームはequifaxsecurity2017.comというWebサイトを構築しました。これは、EquifaxのHPであるequifax.comとは別のサイトです。セキュリティ専門家は、このURLが疑わしく混乱を招くため、情報漏洩に関する案内をするためにequifax.comからequifaxsecurity2017.comにユーザを誘導することは安全ではないと考えました。この長いWebサイトのリンクは、Equifaxの従業員ですら混乱させています。例えば、EquifaxのTwitterアカウントは、従業員が誤って単語の順序を逆に記述してしまったため、約2週間にわたって顧客をフィッシングWebサイトに誘導していました(図7を参照)。
図7:EquifaxのTwitter投稿
このフィッシングサイトはセキュリティ研究者によって作成されました。偽のリンクをクリックして自分の個人情報を入力した人々には、次のポップアップが表示されます(図8を参照)。
図8:securityequifax2017.comのフィッシングサイトにおけるポップアップウィンドウ
正規のWebサイトequifaxsecurity2017.comは、消費者に不完全または不正確な情報を提供しました。 たとえば、クレジットモニタリングサービスに登録しようとした一部の顧客は、正しく登録されなかったり、エラーメッセージを受け取りました。他の例では、自分のコンピューターと携帯電話からWebサイトにアクセスした際に、情報漏洩の影響を受けたか否かについて矛盾する回答が表示されました。Webサイトの課題は深刻であり、顧客の反応に大きな影響を受けました。Webb氏は以下のように証言しています。
システムに対する需要はかなりあったと思います。そして、これは消費者が求める数ある要望の一つであることも理解していました。そのため、その要望を理解したので、すぐに準備を始めました…私たちはすぐに着手する必要があったため、Webスケールの問題を解決する時間はほとんどありませんでした。
Payne氏は、「短い期間で相当量のトラフィックを処理できる消費者用Webサイト」を立ち上げることができたので「チームはかなり良い仕事をした」と考えています。彼は、システムの「ボトルネック」が遅延の原因となっていると述べています。Webサイトは、大量のトラフィックを受け入れることができる大手クラウドサービスプロバイダにホストされていましたが、Equifaxシステム条件により、こうしたトラフィック処理に制約が課されました。 多くの消費者がEquifaxサービスに登録しようとしましたが、Equifaxの内部システムが一度に大量の要求を処理できなかったため、登録が遅れました。Payne氏は、大量の登録リクエストを水を張った浴槽に、Equifaxの内部システムの能力を浴槽の排水溝に例え、たとえを使ってこの状況を説明しました。彼は、以下のように証言しています。
つまり、私たちの浴槽は既にいっぱいでした。しかし私たちのシステムには処理できる数に制限があったため、私たちは実際のトランザクションを自分たちのシステムに入れることしかできませんでした。つまり、浴槽はあふれた状態です。私たちは排水溝を開け流し始めました。排水溝から水を流れ続けましたが、浴槽はあふれたままです。そして、それは我々が排水溝から水を流すよりもずっと早く浴槽に水が入り続けました。そのため、毎日私たちは、排水溝の大きさを調整しようとしていました。これが、登録したが通知がなかった人々の膨大なバックログが発生した理由です。
Payne氏は、コーディングの問題が、消費者が情報漏洩の被害者であるかどうかを正確に識別するためのWebサイトの機能に影響を及ぼしたと述べています。彼は圧力が激しく、「スタッフは自転車操業で仕事をしていた」ことが、コーディングミスにつながったと述べています。また、彼はコーディングミスは迅速に対処したが、この時に消費者との関係に致命的な影響を与えてしまったと述べています。
b. コールセンターの不満
消費者からの質問に答え支援を行う目的でEquifaxが構築したコールセンターでは、遅延や不満がうまれつつありました。equifaxsecurity2017.comに記載された専用のコールセンター電話番号に電話をかけた個人の中には、個人情報が侵害されたか否か知ることができなかった人もいます。ほかには、問い合わせ電話の数が、用意したカスタマーサービス担当者(コールセンタースタッフ)の数を圧倒的に上回り、話すべき適切な担当者へ取り次いでもらうことができなかった人もいます。
この情報漏洩が発生する前、Equifaxは約500人のカスタマーサービス担当者を雇っていました。Equifaxはコールセンターにスタッフを派遣するため「数千人」以上のカスタマーサービス担当者を雇い、トレーニングを行いました。それにも関わらず、コールセンターの人材不足は続き、スタッフは適切なトレーニングがなされていない状態でした。Payne氏は、コールセンターを適切に展開できなかったEquifaxの失敗について、以下のように証言しています。
私の個人的見解では、これらのコールセンターのいくつかの立ち上げは、機を逸していました。そして…Equifaxの対応において、この規模の対応はこれまで経験したことのないものでした。…たとえ、多くのリソースを迅速に増やすことができ、それらをトレーニングすることができる第三者を決めるだけでも、相当の時間がかかり、夜が明けるまで取り組みました…影響を軽減しようと、莫大な努力を払いました…しかし、私たちのプロセスは、私たちが立ち上げたすべてのシステムを素早く拡張し、安全な方法で実行するためのレベルに達していませんでした。
Equifaxは、侵害後の情報公開トラフィックを処理するために、Webサイトとコールセンターに多大な労力とリソースを費やしましたが、この規模の情報漏洩への対応に十分に備えていませんでした。
4. Equifax幹部3名による「引退」
2017年9月15日、Equifaxは、CIOとCSOの退任を発表しました。
元CIOのDavid Webb氏は、Equifaxに7年間勤務していました。彼は自分の退職は計画されていると証言したが、彼は「この計画が早められた」と付け加えたとき、この計画の存在は完全には真実ではないと認めました。Webb氏は、この年の終わりまで給料を受け取る一方、Equifax社で費やした貢献に基づく年金以外の退職パッケージは受け取っていないと述べています。Webb氏は、なぜ彼の引退が早められたかということについて、「完全な答えを持っていない」と述べています。彼は、「私はまだ、この会社の改善に貢献できる部分はたくさんあると考えていましたが、これは取締役会によってなされた決定だと考えています。」
元CSOのSusan Mauldin女史は、Equifaxに4年間勤務しており、今回の早期退職は情報漏洩事案に関連していると証言しました。彼女は、情報漏洩発生前に退職の旨伝えていたので、今回Equifaxは退職時期を延ばした」と言っています。Webb氏は、「Mauldin女史は、私と同じ日に退職しました。しかし、Susan(Mauldin女史)の退職に関する決定は、それよりも早い時期に行われた。」
2017年9月26日に、EquifaxはCEO Richard Smith氏の退任を発表しました。
C. 2017年10月 – フォレンジック調査が完了し、Equifaxの上級管理職が解任される
Mandiant社は、9月7日の発表後、影響を受ける250万人のさらなる消費者を特定しました。同日、Mandiant社の調査が終了し、EquifaxはGraeme Payne氏を3月9日のGTVM Apache Strutsパッチアラートの転送に失敗したことを理由に解雇しました。
1. 2017年10月2日 - 250万人以上の被害者が発表
2017年10月2日、Mandiant社はフォレンジック調査を終了しました。調査中、Mandiant社は攻撃者によって作成されたWeb Shellに隠された失敗したデータベースクエリを多数発見しました。さらなる調査により、こうしたクエリが成功していたことが判明しました。Mandiant社は、この情報漏洩を通じてさらに250万人の個人情報が侵害されていることが判明しました。これにより、Equifaxの情報漏洩被害を受けた米国消費者の総数は1億4,500万人を超えました。Mandiant社の調査結果を踏まえ、Equifaxは次のように述べています。
最終報告書によれば、およそ250万人の米国消費者が確認され、合計1億4,550万人が影響を受ける可能性があると判断しました。Mandiant社は、追加の攻撃活動、あるいは新しい攻撃者の存在、新しいデータベースやテーブルへのアクセスの証拠は発見されませんでした。その代わりに、この追加で被害が確認された消費者は、Mandiant社が残りの調査業務と、調査プロセスに組み込まれた品質保証手順を完了したときに報告されました。
2. Equifaxの上級管理職が「Eメール転送の失敗」を理由に解雇
2017年10月2日、Equifaxは、ACIS環境の管理を担当するGraeme Payne氏(シニアバイスプレジデント兼グローバルコーポレートプラットフォーム担当CIO)を解雇しました。Payne氏は、情報漏洩事案が発生するまでの7年間にわたり、高い評価を得ていたEquifaxの従業員でした。
Payne氏は委員会に対し、インシデント調査の結果により、解雇されることを通知した2人の人事部担当者との面談を求められたと述べた。彼が調査について新しい情報を強く求めたとき、人事部は調査に関するいかなる書類提供も拒否しました。しかし、その一方で彼は、電子メールを転送しなかったことを伝えた。
10月3日には、Payne氏が解雇された翌日、元Equifaxの CEO Richard Smith氏は議会で証言を行い、セキュリティの警告に基づき、行動しなかった個人の責任について繰り返し言及しました(図9参照)。米国下院エネルギーおよび商業対策委員会における彼の証言において、Smith氏は次のように述べています。
- 「ヒューマンエラーは、パッチが適用されていない対象に対して適用するため、組織内でコミュニケーションを担当している個人により発生しました。」
- 「議員の皆さん、ITチームとセキュリティチームは定期的に通知を受けて、[パッチ]を適用します。私が前述したように、この個人はパッチを適用するのに適切な関係者に伝達しませんでした。」
- 「私は、ある個人がアプリケーションに手動でパッチを適用するため、適切な担当者に連絡を取っていないことによる、ヒューマンエラーと説明しました。それに続いて、環境内の脆弱性を探すためのスキャンが脆弱性を発見できなかったという、我々が利用している機器において、脆弱性技術的エラーが続いたと考えている」
図9:元CEO Richard Smithは委員会の前で証言(2017.10.03)
Payne氏は、Smith氏の議会証言を見て「少し残念だった」と述べた。Payne氏は、Smith氏がこの情報漏洩事故を、ヒューマンエラー(電子メールの転送失敗)とシステムエラーのせいにしていると述べました。また、Payne氏は、「私は2つと2つをまとめてメールしました。そしてそのメールこそが、彼らが言及しているメールのはずだと確信している」と述べました。
Payne氏は、Smith氏の証言について「これは、実際に起こったこと…これらの複雑さ…に関する過剰な単純化だ。議員の前で…なんてこった…ある一人がEメールを転送するのを忘れた単純なミスだ…これが原因だ…これは非常に単純な話だ…。ようするに過剰な単純化なんだよ」。
2017年3月9日に、Apache Strutsの脆弱性に関する、GTVMチームのパッチ警告メールを転送できなかった疑惑について、Payne氏は以下のように証言しています。
組織のSVP(上級幹部)が脆弱性警告情報を人々に転送するべきであると主張する…アラートごとに組織内の3つか4つの層に分類されているだけでは意味がありません。 それが会社が頼らなければならないプロセスであるならば、それは問題です。
Payne氏は、Apache Struts脆弱性に関して、GTVMの電子メール警告を受け取った430人の従業員のうちの1人に過ぎませんでした。Payne氏はこのメールを情報共有目的で共有したが、特定のアクションが要求されたわけではなかった。彼は以下のように証言しています。
- A. GTVM [Eメール警告]において、すべてのCIOがその情報は転送されていたと思います。しかし、私が示したように、それはおそらく何よりも情報共有を目的としたものでした。
- Q. あなたがなにか行動すべきだったのではないですか?
- A. いいえ、私はパッチ管理ポリシーに関する責任を負っていなかったのです。システムオーナー、またはアプリケーションオーナーではありませんでした。
Payne氏は、誰からもその電子メールを転送するように指示されていませんでした。
Equifaxの上級管理職は、元CEO Richard Smith氏が議会で証言する前日、電子メールの転送に失敗しことを理由に解雇されました。これは、彼が指示していなかった行動でした。この種の広報目的の動きは、全ての事実を背景に不当であると見受けられます。
D. 2018年初頭 - 総被害者数は1億4800万人に増加
最初のフォレンジック調査終了後、Equifaxは影響を受けた個人をより多く特定しました。 2018年3月1日、Equifaxは9月7日と10月2日のお知らせを更新し、「名前と運転免許証の一部が盗まれた消費者で、以前影響を受けた名簿にはいなかった」とされる240万の米国消費者の身元を特定しました。この発表により、情報漏洩被害を受けた個人の合計数は1億4800万人になりました。
2018年5月4日、Equifaxは攻撃者によって盗まれたデータを記載した記録を委員会へ提出し、「これらの記録は、異なるスキーマを持つ多数のデータベーステーブルからのもので、盗まれたデータ要素は統一感がなかった」と説明しました。追加のフォレンジック調査により、12の標準データ要素について、影響を受けた消費者の概数を確認することができました。これらのデータ要素には、名前、生年月日、社会保障番号、住所情報、性別、電話番号、運転免許証番号、電子メール、クレジットカード番号と有効期限、納税者ID、運転免許証の状態が含まれます。
Equifaxは、2017年の情報漏洩で侵害されたデータのカテゴリをまとめた次の図を公表しています。(図10を参照)。 図10:2017年情報漏洩における漏洩したデータ
図10に記載されているデータに加えて、Equifaxは、約182,000人の米国消費者によって、Equifaxの消費者苦情ポータルにアップロードされた画像に攻撃者がアクセスしたことを確認しています。
E. Mandiant社のフォレンジック調査が抱えた課題
Equifaxの情報漏洩/侵害の結果として行われたフォレンジック調査は、EquifaxのIT環境が複雑であるため非常に困難でした。Susan Mauldin女史は、Mandiant社は「影響を受けた被害者数を確固たるものにするまで」数週間(8月上旬~9月6日)までかかったと述べた。Mandiant社は、なぜこの分析にここまで時間がかかったか、以下のように証言をしています。
本件については、非常に複雑な案件でした。データはさまざまなテーブルやデータベースにあり、その関係性を理解する必要がありました。そして、二重に計上することがないよう確認しなければなりませんでした。例えば、レコードがここにあり、またそのデータがここにもある場合は、その人を2回数えないでください…みたいな。そのため、それを見越して進める必要がありました。…そして私が思い出したのは、全てを並び替え、整理してその数を変更した可能性があるすべての要因を確認したうえで正しい数を特定することは、非常に大変な作業でした。
Mandiant社は、Equifax環境におけるフォレンジック分析の課題について説明しました。 Mandiant社は、明確に識別できないデータの意味を理解するため、データベース所有者と協力しなければならないと委員会に伝えました。Equifaxデータベース所有者のリストは存在しませんでした。そのため、Mandiant社は分析を開始する前にデータベースの所有権を識別して確認する必要がありました。
Payne氏は、フォレンジック分析がなぜそれほど困難であるかについて証言しました。セキュリティ能力へ悪影響を及ぼすEquifax IT環境の複雑性がフォレンジック分析を妨げると述べています。
私は金融サービスや他の環境で働いていました。そしてEquifaxの技術基盤は非常に複雑です。とても複雑なのです。たくさんの異なるシステム、多くの複雑さ、たくさんのマトリックス管理、そしてこれらを管理することは非常に難しいのです。…これらのシステム群の一部がどのように結び付いたかの歴史的経緯もあり、その量は膨大です…本当に複雑なのです。
V.具体的な失敗のポイント:Equifaxの情報技術とセキュリティ管理
多くの点で、Equifaxは他のグローバル金融会社と同じように運営されています。株式は上場取引されており、従業員は世界中の国々に住んでいます。個々の消費者への取引ではなく、主要な企業や政府への契約が会社の収益を生み出します。しかし、Equifaxはいくつかの点で類似企業と業務上の違いがあります。しかし、こうした逸脱は、2017年の情報漏洩を引き起こした特定の問題にまで辿ることができます。
A. EquifaxのIT管理構造における説明責任と調整の欠如
1.侵害時のIT組織構造
2005年以前は、EquifaxのCSOは当時CIO Robert Webb氏に報告していました(David Webb氏とは無関係)。この報告構造により、Robert Webb氏はCSOが主導するITセキュリティ機能に責任を負いました。Robert Webb氏の任期中、内部組織構造が変更され、報告先も変更になりました。この変更により、CSOはCIOではなく、CLO(最高法務責任者)に報告しました。
Richard Smith氏は2005年に同社のCEO(最高経営責任者)として雇われました。Tony Spinelliは2005年にSmith氏の指示のもとCSOの役割を果たすため雇われました。Equifaxの経営幹部は、セキュリティリスクとコンプライアンス要件により、同社のセキュリティ統制を見直さざるを得なくなりました。Spinelli氏は、全社的なITセキュリティ標準を確立することを任務としていました。Spinelli氏は、Equifaxの取締役会に、企業全体のITセキュリティを再編成するため、1500万ドルの3年計画を提示しました。
CIO Robert Webb氏とその配下のCSOであるTony Spinelli氏との関係性は、「基本的な意見の不一致」が原因で悪化しているため、セキュリティ機能をIT部門から法務部門に移すという重大な決定が下されました。Payne氏は、Tony Spinelli氏は、「セキュリティをIT外である法務部に移管すべく推進していました」。つまり、セキュリティ組織をCIOの管理下から外れ、CLOの管理下に置かれました。CLOは、”Head of Security”と呼ばれていました。
2010年、CIO Robert Webb氏が退任すると、EquifaxはCIOとしてDavid Webb氏を雇いました。2013年に、Tony SpinelliがEquifaxを去った後、Susan Mauldin女史はCSOの地位を引き継ぎました。 David Webb氏とEquifaxのリーダーシップ間で多数の議論があったにもかかわらず、同社はIT組織構造を元の形に戻すことはしませんでした(図11参照)。
図11:Equifax ITの組織構造(2013~2017.09)
David Webb氏は、CEO Richard Smith氏とCLO John Kelley氏、そしてCSO Susan Mauldin女史との間で、その構造について様々な会話をしました。Webb氏は以下のように証言しています。
- Q. Equifaxにいたときに、CSOからCIOへ報告すべきであることを明らかにしましたか?
- A. しました。
- Q. 詳細を教えてください。 あなたは、いつその話題を取り上げましたか?誰にその話をしましたか?議論はどのような結論になったのですか?
- A. この話題が取り上げられた状況は複数あります。私が会社でCIOとしての仕事を始めた直後、私はなぜこのような組織構造になっているのか、質問しました…私は本当に組織構造を理解しようとしました。その時、私は新しい役職で着いたばかりで、やるべきことがたくさんあり、その時は単純に受け入れられるものだと感じました。 最終的には、確か私が退職する2週間前におきたミーティングが最後の議論する場だったと思います。そして、最終的にはセキュリティ機能をIT部門の下に移すことに最終的に同意しました。それは確か、CEO Richard Smith氏と、そうそう、他の経営幹部の一人との会話でした。そして、その時点で新しいCSOを探すことにしました。
- Q.以前の会話でも、CEOとの会話もありましたか?
- A. (セキュリティに責任を持つ)“Head of Security” (John Kelley氏のこと)と一緒に会話しました。
Webb氏はMauldin女史に、CSOの役割をCIOの下に戻すことに賛成か聞いた。Webb氏は以下のように証言しています。
- A. 私は、この話が組織の改善につながるか否か、Susan Mauldin女史と一度だけ話をする機会がありました。
- Q. 彼女の反応はどうでしたか?
- A. 彼女は、当時の組織体制について満足していたと思います。
Mauldin女史は、この変わった組織構造の理由について証言しました。
私はEquifaxに着任したときには、この組織はもともとこういう構造になっていました。それは、私の前任者が構築した体制であり、この組織運営で今までうまくいっていることを私は知っていたので、私はその組織構造に疑問を持たずそのまま踏襲しました。ただそこにあったので、私は今まで続けてきたを続けていました。
2013年から2017年までのEquifaxの組織構造が、大規模かつ複雑な組織として典型的なものであるかどうかを尋ねられれば。Webb氏は単に「いいえ。CSOはCIOに報告をあげることが一般的です。」と証言しました。
Webb氏、Smith氏、Kelley氏の間で行われる組織構造の最後議論は、Webb氏が2017年9月中旬に会社を早期退職する2週間前に行われました。この会議中において、セキュリティ組織をCIOの下に戻すことが決定されました。
2017年9月15日、EquifaxはWebb氏とMauldin女史の退職を発表し、二つの役職を埋めるため暫定役員を指名すると発表した。この発表で、Equifaxは暫定CSOとしてRuss Ayresを指名し、暫定CIOであるMark Rohrwasser氏の元で働くことになりました。この体制は、新しいCISO Jamil Farshchi氏が雇われるまで、Equifaxが2018年2月まで続きました。Farshchiは、Equifax CEO Mark Begor氏に直接報告しています。
2. 組織体制の運用努力
CIO / CSO組織体制の機能的結果は、ITの運用とセキュリティの責任が分割され、説明責任のギャップが生じたことを意味します。当時、Equifaxの組織体制は、CIOとCSOの強力なパートナーシップを促進するものではありませんでした。議会での証言は、IT運用とセキュリティ間にある断絶を実証しています。
Webb氏は、委員会におけるインタビューの間、本人と彼の組織をセキュリティから遠ざけ、答えるためにMauldin女史に聞くように促す場面があった。例えば、経営会議においてその話題についてどのように対応されたか尋ねられた時、以下のように述べています。
私は、IT機能を専門としているため、ITの話題からセキュリティの要素を除外して話したいと思います。
私たちは、経営層全体で四半期ごとに事業レビューを行い、事業部門に代わって行っていた重要な活動について話し合いました。現在行っている主な取り組みについてお話しします。それから、うまくいっているプロジェクト、うまくいっていないプロジェクトについても話しています。私たちは経営層に情報をアップデートし続けています。それから…私達は技術的な観点から見たトレンドは何かについても話します。つまり、ITに関する最新動向と私たちが取り組んでいることを報告しているのです。
そのセキュリティ部分は通常、法務レビューの対象でした。ですから、そこで議論されていることを理解したいのであれば、提示されている資料の内容についてSusanと法律顧問に相談する必要があると思います。それが私のおすすめです。
Mauldin女史も同様に、この責任分担について証言しました。たとえば、彼女は次のように述べています。
- Q.あなたの責任の範囲は、全社にわたりますか?
- A.はい、その通りです。
- Q.ジョージア州アルファレッタのシステムを含めて、セキュリティ担当者はあなたに報告していたはずです。あれは正しいですか?
- A.まあ、より厳密にいえばそうですね…これが、ご質問に答えられているかわかりませんが…セキュリティチームはグローバルに責任を担い、ITチームが運用するのと同様に、ポリシー、標準、ルールなどを確立します。 そして、アトランタのシステムを取り上げれば、セキュリティチームが事前定めた規則に従う責任があるITチームについて考えるようにします。 そのため、セキュリティチームがルールを確立し、ITチームと協力してそれらのルールを実装するという作業上の関係がありました。 それは質問に答えますか?
- Q.一部は。では、誰がそれらのルールを強制するでしょうか? 誰がコンプライアンス要件を満たしていることを確認するのでしょうか?
- A.それは…IT担当者が規定された規則と方針に責任を持っていることを確実にするため、複数の関係者が責任を担っていました。ITにも…失礼、セキュリティもギャップがある可能性がある、または正しくルールに従っていない可能性がある分野を探すため、継続的にスキャンして探すために利用しているプロアクティブなプロセスがありました。
委員会がインタビューしたすべての証言者がプロセスに対する不満を指摘したが、証言者はIT部門とセキュリティ部門の間、あるいは内部での良好なコミュニケーションが不可欠であることに同意しました。Webb氏は、「ご存知の通り、組織としてこの組織構造が機能するためには、高度な調整とコミュニケーションが必要です」と述べています。Webb氏は、この企業におけるサイバーセキュリティインシデントに対する組織構造について以下のように証言しています。
組織間で複数のコミュニケーションラインを持っているなら、物事はゆっくり起こります。実行速度は遅くなりますが、結果が異なるわけではありません。 決断するまでにはもっと時間がかかります。
2016年4月、IT内の組織再編を行ったとき、同社のITガバナンスに対する不満が高まり、IT Risk and Compliance Groupが(Global Corporate Platforms担当CIOを務める)Graeme Payne氏の配下に移動しました。その結果、アクセス管理、IT監査の調整、IT部門とセキュリティ部門間の調整に関する責任を担うことになりました。
2016年にIT Risk and Compliance Groupを引き継いだとき、Payne氏は、”Head of Security”でありSusan Mauldin女史の上司であるCLOであるJohn Kelley氏とミーティングを行い、ITチームがセキュリティチームをより良くサポートする方法について話し合いました。このミーティングの結果、ITチームとセキュリティチーム間の月例ミーティングが2016年4月から開催されるようになりました。Kelley氏、Mauldin女史、Webb氏、およびPayne氏は、ITチームとセキュリティチーム間の機能をよりうまく、調整するためにこれらの会議に参加しました。
Payne氏によれば、これらの月例ミーティング目的は、「セキュリティチームがITチームに求めていること、およびセキュリティチームの要求事項に対してITが適切に対応していること」について、経営幹部に対して「見える化」することでした。Payne氏はこのミーティングを始めた理由は、「特定の事項の進捗について、つまりは、ITがセキュリティに十分な速度感を持って取り組んでいないように見えており、J(John Kelly)のチームが不満を持っているように見えたからです。」
[Kelly]は(やるべき)リストを持っていましたが、私にそのリストを決して共有しませんでした。しかし、私たちは会議体を設定し、そのプロセスを追跡したいと考えるその間に10~20の異なるイニシアチブがあることを理解し、そしてトラッキングを始めました。
月例ミーティングでは、パッチ管理やデジタル証明書の展開など、さまざまなイニシアチブが追跡されていました。この二つのイニシアチブはどちらも、2017年の情報漏洩につながる重要な体系的な課題であることがわかりました。
3. Equifaxの組織構造による非効率なIT調整
企業がCSOとCIOの役割を取り入れた組織構造により、矛盾することもあれば、補完しあう関係になる可能性があります。Equifaxでは、IT部門とセキュリティ部門がサイロ化されていました。つまり、あるグループから別のグループに情報が共有されることはほとんどありません。セキュリティチームがネットワーク上の変更を承認するためにITを必要としていたときのように、ITとセキュリティの間のコラボレーションが必要になる局面は多くありました。Equifaxではこれらのグループ間のコミュニケーションと調整が矛盾し、効果がないことがよくありました。
ITとセキュリティの連携が欠如している一例は、複数の不完全なソフトウェア棚卸リストが各グループで別々に管理されていたことです。 IT部門もセキュリティ部門も、正確な棚卸リストに基づいて、会社のITシステムの運用、修正、監視を行う必要があります。より協調的な環境では、これらのリストは単一のマスター文書にまとめられ、両チームが協力して棚卸リストを完成させます。しかし、Equifaxには最適なIT管理環境がありませんでした。
EquifaxのCEOはサイバーセキュリティを優先しませんでした。Webb氏は、四半期ごとに開催される経営会議で、ITセキュリティも議論されるべき多くのトピックとして取り扱われたと証言しました。CEO Smith氏は、四半期ごとにしかセキュリティを確認していませんでした。Mauldin女史はこのミーティングに定期的に参加していませんでした。なぜなら、彼女の任期中、CSOは経営層とは考えられていなかったためです。この会議の流れの結果、Smith氏はEquifaxのセキュリティ態勢に関する情報をタイムリーに受け取っていませんでした。彼が受け取った情報は、同社のITセキュリティ専門家であるMauldin女史ではなく、ITやセキュリティのバックグラウンドを持っていない法務部門の長であるKelley氏によって提示されました。
情報漏洩前のEquifaxの組織構造は、CSOは法務部に報告していたため、いびつとも言えるでしょう。Ponemon Instituteによる2017年の調査では、CSO調査回答者の50%がCIOに報告していました。それとは対照的に、わずか8%のCSOが経営会議へ、4%のCSOがCEOに報告しているとしています。2018年に発表されたPwCの調査では、CSOはCIOよりもCEOまたは取締役会に直接報告するのが一般的であると結論付けています。 CSO調査回答者の24%がCIOに報告する一方、調査回答者の40%がCEOに直接報告しています。
2017年9月にWebb氏とMauldin女史が退任したことを発表して以来、ITの管理変更が数多く行われています。まず、EquifaxはCSO(最高セキュリティ責任者)をCISO(最高情報セキュリティ責任者)に改名しました。 2018年2月2日、EquifaxはJamil Farshchi氏をCISOに任命しました。Equifaxは、CISOがCEOに直接報告するよう、CISOの立場を昇格させて組織構造の変更を発表しました。2018年6月15日、EquifaxはBryson KoehlerをCTOに任命しました。CTOは引き続き、CEOに直属します。
Equifaxが最近行ったIT管理の取り組みは、現在において、サイバーセキュリティがコアビジネス機能であると認識していることを示しています。CISOとCTOをEquifaxの経営層とすることで、より生産的でコラボレーティブなセキュリティへの取り組みが可能になります。
B. EquifaxのITポリシー策定と実行面における深刻なギャップ
侵害時当時は、エクイファックスの内部IT管理プロセスは、ITセキュリティポリシーを策定し、これらのポリシーを実行するための明確な説明責任を確立することができませんでした。 IT部門とセキュリティ部門の間には、ITポリシーの開発と運用上の実装に取り組む責任がありました。Webb氏は以下のように証言しています。
- Q. ITセキュリティの運用に関する決定に携わっていますか?
- A.通常、作業は組織間で分離された方法をとっています。セキュリティチームは「何を」定義します。彼らはセキュリティエンジニアリング機能を持っていました。 セキュリティチームが導入したい技術をインフラストラクチャに展開する責任をIT担当者が担い、その後、セキュリティチームに、ソフトウェア、すべてのソリューション、アプライアンスを必要に応じて構成する機能を提供します。
- Q.最終的にセキュリティの決定するのは誰ですか?例えば、あなたがソフトウェアの脆弱性にどのようにパッチを当てるかを決める場合、いつ、どこで、どのように行うのですか?
- A.その場合でも、やはり、「何」と「どのように」は分離されました。そのため、ポリシーの観点からすると、ポリシーは通常セキュリティチームで定義されていました。ITチームは、与えられたインフラストラクチャと環境において、ポリシーに遵守し、理にかなっていることをレビューし、確認する機会を得ることになります。そして、それはセキュリティ製品によっても変わります…しかし、通常は…ITチームは、たとえばパッチの場合は、そのパッチが適用されたことを確認する責任があります。セキュリティチームがインフラストラクチャへの変更に直接影響を与えることができません。彼らはソフトウェアを操作することはできますが、ソフトウェアをインストールすることはできず、インフラストラクチャを変更することもできませんでした。 それで、つまり共同責任でした。一つはポリシーのためのもの、そしてもう一つは実行のためのものです。セキュリティチームはその後、作業が正しく完了したことを確認する責任があります。
- Q.それで、あなたはCSOの指示で実行するでしょうか?
- A.その通りです。
1. Equifaxのパッチ管理プロセス
ポリシーの作成と実行の間の断絶は、Equifaxのパッチ管理ポリシーに関して特に顕著でした。このポリシーでは、役割と責任を定義し、パッチ適用プロセスのガイドラインを設定しました。このポリシーでは、Equifaxの2名の従業員が実担当者としてアサインされ、ポリシーマネージャーと経営幹部からこのプロセスのオーナーを指名しました。Webb氏は、ポリシーマネージャーの責任は「必要な作業のすべてを確実に追跡すること」であり、経営幹部のプロセスオーナーの役割は「組織がポリシーに準拠していることを確認すること」であると述べました。
US-CERTが2017年3月8日のApache Struts脆弱性に関するアラートを配布したとき、2016年版のパッチ管理ポリシーが有効になりました。2016年版では、David Webb氏が経営幹部のプロセスオーナーで、Susan Mauldin女史がポリシーマネージャーでした。
2016年版のパッチ管理ポリシーでは、管理下におかれた環境にパッチを適用することについて、様々な個人の役割と責任を特定しました(図12を参照)。このポリシーでは、事業主はパッチの必要性について通知され、パッチ適用できるようにダウンタイムを承認する責任を負います。システム所有者がパッチを適用する責任を負い、その後アプリケーション所有者はパッチが正しく適用されたことを確認する責任を負います。委員会に提供された証言によれば、役割と責任はポリシーで定義されていますが、この役割を担う担当者は指名されていませんでした。
図12:2016年のパッチ管理ポリシーに基づく緊急脆弱性パッチプロセス
a. 2017年3月9日のApache Strutsアラートに続くパッチ適用プロセスの失敗
セキュリティチームとITチームは、Global Threat and Vulnerability Management(GTVM)チームが配布した電子メールアラートを通じて、Equifaxシステム内のApache Strutsにパッチを適用する必要性を認識しました。各パッチは、ベンダーによって(低・中・高・緊急)という具合に、深刻度(Criticality)の分類が割り当てられているので、どれぐらいパッチを素早く当てなければいけないか認識することができます。Susan Mauldin女史によると、セキュリティチームはベンダーが出した分類を変更することができますが、通常Equifaxはベンダーの分類を採用しています。
Apache Strutsの脆弱性パッチは緊急に分類されていました。Equifaxのポリシーでは、Apache Strutsの脆弱性パッチは2017年3月9日のパッチの公開から48時間以内に適用されるべきでした。 Equifaxは、この脆弱性について、48時間以内に適用していませんでした。Apache StrutsはACISシステムで利用されていましたが、2017年7月下旬に情報漏洩が発覚するまでパッチは適用されませんでした。Equifaxの担当者は、最初の侵入は、Apache Struts脆弱性を悪用して行われたことを確認しています。
誰がACISシステムにApache Strutsパッチを適用する責任があるか判断するため、委員会はPayne氏に対し、パッチ管理ポリシーに記載されている役割により、担当となる従業員を特定するように依頼しました。具体的には、委員会は彼にACISシステムに責任があるビジネス所有者、システム所有者、アプリケーション所有者を特定するように頼みました。ペインは以下のように証言しました。
- Q. ACISのアプリケーション所有者は、どの担当者、どの部門に所属になっているのでしょうか?
- A.アプリケーション所有者の明示的な担当は決められていないと思います。もし、誰がアプリケーション所有者として適当と考えられるか尋ねられているのであれば、私の考えを述べることはできます。
- Q.お願いします。
- A.私の考えでは、(ACISは消費者苦情ポータルコンポーネントであるため、)ACISのアプリケーション所有者は[Equifax IT担当者1]と[Equifax IT担当者2]であると思います。繰り返しになりますが、具体的な担当がアサインされているわけではないので、もし誰かが私に「誰が指名する上で適当だろう?」と聞いてきたら、私は先ほど挙げた2名が適当であると回答するだろうという話です。
====
- Q.それで、その2名はパッチを当てる必要性を携行したGTVMからのメールを受け取ったはずの人々でしたか?
- A.はい。システム所有者も同様です。
- Q.わかりました。 システムの所有者はだれですか。
- A. 同じ理由で、誰も指定されていませんでした。 だから私は…
- Q.あなたが誰だと思いますか?
- A.システム所有者は、おそらく[Equifax IT担当者3]の下にある基盤グループの誰かになると思います。なぜなら…グローバルプラットフォームサービスグループの一部なので、彼のチームがサーバ運用を担っていたと思います。
====
- Q. 定義を見れば…システム所有者は、電子資産にパッチを適用する責任があります。それでは、[Equifax IT担当者3]が実際にパッチをACISに適用する責任を負っていたのでしょうか。
- A.おそらく。繰り返しますが、私たちは自分たちが関与していなかったレベルの話ですので…、誰が実際にパッチをインストールするために当該システムに物理的にアクセスできたのか具体的に話すことはできません…
ペイン氏は、ACISシステムに経営幹部としてパッチを当てるための特別な役割や責任はないと述べ、「ポリシーで定められた役割を果たすチームを管理するマネージャのマネージャ」であると述べた。
それぞれの証言者は、特定の脆弱性にパッチを当てるために適切な個人がGTVMアラートを受信することを保証するために冗長性が存在するかどうかを尋ねられました。Mauldin女史とWebb氏はどちらも、適切な個人にパッチを適用する必要性があることを確実に知らせるための冗長性が、パッチ適用プロセスにないことを証言しました。Mauldin女史は以下のように証言しています。
- Q.パッチ適用ポリシーについては、出てきたこの[GTVM] Eメールがあったことを私は理解しています。このメールを見てアクションを取るべき担当者に対する冗長性やフォローアップがあったでしょうか。
- A. 私の記憶する限りはそうでありません。
- Q.その[GTVM] メールが、システム所有者に届いた唯一のアラートであるかどうかを理解しようとしています。
- A.つまり…セキュリティチームがアラートを繰り返すかどうかを尋ねていますか?
- Q.プロセスに基づいて、あなたの知る限りにおいて、送信されたアラートについて何らかのリマインダがありましたか。それをやるのは、たぶんセキュリティチームかITチームだと思いますが。
- A.私が記憶しているのは…私がその3月16日の会議において、GTVMチームのリーダーから渡されたその会議のPowerPoint資料です。あるページに [Apache Struts]の特定の脆弱性について、強調された記載がありました。そこには、特定のバージョンのApache Strutsを使用している場合は、パッチを適用する必要があると述べてありました。そして彼は、その(3月16日の)GTVM電話会議でそのことについて議論したことを伝えました。
Webb氏は証言しました:
- Q. 400人に宛てたこの電子メールの他に、Equifaxやアプリケーション所有者などに情報を提供する他の方法はありますか。
- A. ありません。
Payne氏は、パッチ管理ポリシーが、システムオーナーとアプリケーションオーナーが、US-CERTやソフトウェアベンダなどの外部ソースからの脆弱性情報を購読するように求めていると証言しました。こうした脆弱性情報は、システムオーナーやアプリケーションオーナーにパッチの存在を教えてくれます。Payne氏が述べたように、システムオーナーとアプリケーションオーナーの正式な指定がないことは、どちらの人もこうした脆弱性情報の購読要件に確実に従うためのメカニズムがないことを意味していました。
Equifaxのパッチ適用プロセスの実行における説明責任とコンプライアンスへの取り組みの欠如は、2017年の情報漏洩につながった重要な要因でした。Webb氏は、このインシデントにおいて、パッチ管理ポリシーが機能しないことを確認しました。彼は以下のように証言しています。
- Q. あなたの意見では、この場合Equifaxのパッチ管理ポリシーは機能しましたか?
- A. Noと言わざるを得ません。
- Q. それはなぜだと思いますか?
- A. 技術の問題を取り上げるのであれば、人(People)、プロセス(Process)、技術(Technology)の観点から考える必要があります。 私はプロセス自体は整っていたと思います。しかし、担当者(人)が必ずしもその手順に従っていたとは思いません。そして…技術面でも潜在的な問題があったと考えています。
b. Equifaxはパッチ適用プロセスに関する問題への認識していた
Equifaxのリーダーたちは、Apache Strutsへのパッチ適用が失敗する前から、パッチ適用プロセスに関する多くの問題に気づいていました。 2015年に、Equifaxはパッチ管理プロセスの監査を実施しました。 この監査では、Equifaxのパッチ適用プロセスに多数の重大な欠陥があることが判明しました。この監査には、8つの詳細な調査結果と、それぞれの調査結果に対応する推奨管理措置があります(図13参照)。
図13:Equifaxの2015年パッチ管理監査の指摘事項
Equifaxは、2017年の情報漏洩以前に、2015年の監査で判明した問題の多くを修正しませんでした。 たとえば、ACISシステムの脆弱なソフトウェアへ修正を加えるため、同社はパッチ適用プロセスの冗長性を確保するため自動パッチ適用ツールを実装していませんでした。
2015年の監査では、資産管理に関するコントロールが改善が必要な分野として指摘されました。パッチ適用プロセスを効果的に実装するため、企業はIT資産の包括的な棚卸リストを持っている必要があります。組織がそのネットワーク上にあるものがわからないと、パッチが必要な場所もわかりません。 2017年7月の時点で、同社はIT資産やシステム上で動作するソフトウェアの包括的かつ最新の棚卸リストを持っていませんでした。Equifaxの従業員は以前、2017年1月時点んで別のApache Strutsの脆弱性を修正する際にACISアプリケーション上のApache Strutsを識別していました。しかし、同社はこの情報を文書化し追跡することに失敗し、2017年7月にこの環境内にApache Strutsが存在することを発見して驚くことになりました。
2. Equifaxの証明書管理プロセス
ポリシー開発と実施におけるギャップの別例として、Equifaxの証明書管理プロセスが挙げられます。同社は、SSL証明書を更新するプロセスがないことを明確に認識していました。Apache StrutsのシグネチャルールをIPSへ適用する計画を考えていたセキュリティ担当者は、SSL証明書の更新に関するより大きい問題提起を行いました。具体的には、1人の従業員によれば、(1)SSL証明書を「誰が所有し、メンテナンスしているのか」、その担当者を定義すること、(2)SSL証明書の作成・検証プロセスを定義することを挙げています。
Equifaxは、期限切れのSSL証明書がもたらす潜在的なセキュリティリスクを知っていました。 2017年1月20日付けで作成された社内の脆弱性評価トラッカーへの記録を見ると、「SSLVデバイスに証明書がないため、Webベースの攻撃に対するIPSの検知が制限されてしまう」と述べています。情報漏洩が発生した時点で、しかしながら少なくても324個のSSL証明書が期限になっていました。そして、有効期限切れのSSL証明書のうち、79個の証明書は、ビジネスクリティカルなドメインを監視するデバイス向けのものでしたです。Equifaxが役割と責任を明確にした証明書管理プロセスを実装していたら、ACISプラットフォームを監視するデバイスのSSL証明書は侵入がおきた2017年5月13日時点で有効のはずです。同社は、ACISプラットフォームとの間でやり取りされる疑わしいトラフィックをはるかに早く確認することができたはずでした。さらに言えば、情報漏洩を軽減、さらには防止することができた可能性があります。
===
Equifaxは、パッチ管理と証明書管理プロセスに欠陥があり、このプロセスを有効にするために改善が必要であることを知っていました。Apache Strutsによるパッチ適用の失敗は、ポリシー策定と実施・運用間の断絶を物語っています。パッチ管理ポリシーには、パッチ適用作業を担当する担当者の役割が定義されていましたが、Equifaxはこれらの役割を果たす担当者を指定することができませんでした。Equifaxはパッチプロセスが「試験監督者なしの状態」で運用され、説明責任とコンプライアンスを確実にするメカニズムを確立できていませんでした。
効果的なパッチ管理ポリシーを実施し、一貫して実行していれば、2017年の情報漏洩は防止可能でした。 Webb氏はこの結論に同意しました。彼は以下のように証言しています。
- Q. Equifaxが48時間以内にシステムに効果的にパッチを適用した場合、これは予防可能な事件である可能性があることに同意するでしょうか?
- A.はい。その通りです。
C. Equifaxは、指摘されたセキュリティリスクを伴うレガシーIT環境においてビジネスクリティカルシステムを実行
Equifaxは、複雑かつレガシーなIT環境のため、セキュリティリスクの増大に直面しました。レガシーな技術はセキュリティの問題のみならず、技術革新への障害でもあります。また、レガシーシステムはパッチの適用、監視、アップグレードが時々非常に困難であるため、安全な状態を保つことが非常に困難です。 Equifax社は、多くのビジネスクリティカルなシステムをレガシーなIT基盤で動かし続け、その中には2017年の情報漏洩で攻撃者に侵害されたACISシステムも含まれています。
1. Equifaxの会社拡張により、非常に複雑なITインフラストラクチャが構築された
2005年にRichard Smith氏がCEOに就任したとき、彼は野心的な成長戦略に着手しました。Richard Smith氏は、企業の市場価値を拡大するため、主に買収を行いました。
Payne氏は、Equifaxの技術基盤の複雑さについて証言しています。彼曰く、Equifaxは過去10年間における多大な買収や統合により、テクノロジーの複雑さを増し、セキュリティ手法やツールの適用がさらに困難になってきたと述べています。Payne氏は以下のように証言しています。
当時のEquifaxは、非常に買収を好んでいた。私が着任した時から会社の成長度合いを見れば」、7年~10年の間に著しく成長しました。しかし、私が着任する前でさえ、この企業は急成長していました。大量の買収があり、多くの統合が行われていました。なので、成長のためのプラットフォームを構築し、将来へ向けた標準化を図る一方で…、新しいシステムを持ち込んで、それらをどこかに管理体制の下に置くことは…ここではだれかの管理者のもとに置くという意味ではなく組織として管理するという意味ですが…すべての技術を管理する方法で一貫性を保つことが、大きな課題となっています。
Equifaxは、ITシステムの多くを自社開発していました。Payne氏は、次のように述べています。「この会社はたくさんのシステムを独自開発していました。そのため、システムを構築すると、さらに複雑になります。そして、あなたは外部から、紛争・情報開示システムを調達することはできません。つまり、構築しなければなりませんよね?だから、どんどんと…複雑さが増していくのです。」
2.レガシーなACISの環境構成
1970年代から2017年にかけてEquifaxで使用されていた独自開発のレガシーITシステムの1つにACIS環境がありました。これは、インターネット公開の業務システムであり、信用ファイル内で見つけた不正確な情報の修正を申し出るために個人が利用するシステムです。2017年の情報漏洩時において、Graeme Payne氏はACIS環境の管理責任をIT分野の側面から担っていました。Payne氏は以下のように証言しています。
ACISは、独自開発された紛争・情報開示システムであり…、公正信用取引法(FCRA:The Fair Credit Reporting Act)の要件に対処する為1970年代後半に構築されたシステムです。そしてその法律下では、信用調査機関とデータ提供者(ファーニッシャー)は、情報を消費者に開示するだけでなく、消費者の信用ファイルに関する紛争を管理するためのプロセスを整備することを要求されます…。 そのため、当時は当該プロセスを管理するためのシステムが必要でした。そのため、私がEquifaxに着任する前からシステムが構築されていました。私が2014年にこの役職に就いたとき、それまでに構築されたACISシステムをまだ現役稼働していました。
Equifaxがレガシー技術やアプリケーションを継続して使用することに対する懸念の1つは、老朽化したシステムの運用および維持方法に関する知識を持つ従業員が減少していることです。 Payne氏は、Equifax社は「ACISシステムのベテラン開発者を今でも従業員として擁していたことは幸運だった」と証言した。
- A. ACISシステムを支えるベテラン開発者が転職してしまう潜在的リスクがあり、その時点でACISシステムに関する知見・ノウハウを失う可能性がありました。
- Q. 元の開発者はまだ従業員として働いている…どれぐらいの人がいるのでしょうか?
- A. 複数人です。
ACISシステムは非常に複雑であり、何度も修正された経緯があります。ACIS環境の要素について説明を求めると、Payne氏は以下のように証言しています。
システムについて話すと、明らかにアプリケーション、データベース、ミドルウェア、そしてOSとネットワーク…などの技術スタックがあります。さらに、ACISには様々なコンポーネントもあり、これが複雑さを増しています。つまり、多数のスタックがあり、多くのコンポーネントがあったので、様々な方法で幅広く深く複雑さが増していきました。
ACISプラットフォームをサポートするハードウェアとOSはどちらも古く、レガシーな技術であった。Webb氏は、このレガシーな技術群を「老朽化した環境であり、近い将来に稼働停止する予定のシステム」と表現しています。ACISアプリケーションは、ジョージア州AlpharettaにあるEquifaxのデータセンター内のサーバに収容されていました。このデータセンターは現存していない会社Sun Microsystemsによって作成され、Equifaxでは内部的に「Sunサーバ」と呼ばれていました。
Sunサーバは、Sun Microsystems社が開発した混合オープンソースOSであるSolaris OSで実行されています。つまりこれは、OSが独自仕様(クローズドソース)とオープンソースソフトウェアを組み合わせて実行したことを意味しています。Apache Strutsは、オープンソースのWebアプリケーションフレームワークです。具体的には、Apache Strutsはミドルウェアであり、OSとアプリケーションの間で動作し、アプリケーションをOS上で正常に動作させるためのものです。
Webb氏によると、「Apache Strutsは、Sunサーバプラットフォーム上でアプリケーションを実行していた多くのレガシー環境で使用されている」そうです。Webb氏は以下のように証言しています。
- Q. Apache StrutsソフトウェアはEquifax内でどのくらい広く使用されていましたか?
- A.基本的には、Sunサーバ環境に限られていました。そして…前提として、私たちが何千ものサーバを実行していたこと、そしてその時点で私たちは200以下のサーバのみがダウンしていました。つまり、Sunサーバでは、Strutsには様々なバージョンが存在していたため、どれぐらい異なるバージョンのStrutsを利用していたか述べることがd系ません。
- Q. Sunサーバは主に配置にありましたか。
- A. ジョージア州Alpharettaのデータセンターにありました。
- Q.サーバが何台あるか思い出しますか。
- A. Sunサーバに関しては合計で200未満ですが、私はStrutsを実行していたサーバの台数、もっと具体的に言えば、脆弱性が発生した特定のStrutsバージョンを持つサーバが何台いたかは把握していません。
2. Equifaxは、そのレガシー環境内でどのようなソフトウェアが使用されていたか把握していませんでした。
Webb氏の証言が示すように、EquifaxはACISアプリケーション内で使用されるソフトウェアの包括的な全体像を理解していませんでした。レガシーなIT環境で使用されているソフトウェアに関する同社の知識不足が、2017年の情報漏洩の主な要因でした。Equifaxのパッチ管理ポリシーは、パッチ適用プロセスを手動で開始するため、特定のアプリケーションで実行されているすべてのソフトウェアのソースとバージョンを知る従業員に頼っていました。そのため、Equifax環境におけるApache Strutsの利用状況の「見える化」の欠如は、パッチが当てられていない脆弱性が見過ごされる可能性を大きくなりました。
ACIS環境の最終責任者であるペイン氏は、「情報漏洩が発表された時点では、ACIS環境でApache Strutsを実行していることすら気付いていませんでした」と述べています。彼は、「7月30日に、Susan Mauldin女史がシステムをシャットダウンするため手を貸してほしいと電話で依頼された時」、ACIS環境でApache Strutsが稼働していると知りました。EquifaxがApache Strutsソフトウェアをどの程度広く使用しているかについて尋ねられたとき、Mauldin女史は「わからない」と証言しています。
証言者は、EquifaxがApache Strutsソフトウェアの利用状況に関する完全な棚卸リストを保持しているかどうかについて矛盾する証言をしました。Mauldin女史は、Apache Strutsの利用状況について追跡する一つ一つの登録状況がすべての従業員に利用可能かどうかについて自信を持っていませんでした。彼女は、セキュリティとITチームが別々のリストを保持していると言って、複数の棚卸リストの可能性を言及しました。Mauldin女史は証言した。
- Q. この種のソフトウェアに対する棚卸リストをEquifax社は保持していますか?それは、Equifax社のソフトウェア棚卸リストの一部ですか?
- A. 私が知る限り、棚卸リストは複数種類存在していました。私はセキュリティチームが保持しているものについては知っています。我々は自分独自のリストを持っており…そしてそのリストをもとに仕事をしていました。ITが保持しているリストについてはよく知りません。
- Q. 異なるリストを持っていたということですか?
- A. 私と一緒に働いていた人が複数のリストを持っていました。
Payne氏は、ITシステムに関する包括的な棚卸リストを作成するという実施中のイニシアティブについて議論しました。そのリストには、各システム内にあるテクノロジースタックをすべて網羅しています。彼曰く、「棚卸リストは存在したが、包括的ではなかった」と述べています。Equifax社が資産管理について適切な注意を向けていたか否かにかかわらず、Payne氏は以下のように証言しています。
私は、私が担当した2011年~2014年の期間についてコメントすることができます。私が思うに…当時人とプロセスを持っていたため、投資は継続されていました。
しかし、私たちは必要性を感じていましたが、投資は中止になりました。私の意見では、より投資が必要で得あるため、追加投資をしてもらうようリクエストをしましたが、結局得られませんでした。その投資の一部も継続されませんでした。
時間が経過して、IT資産管理と検出により投資が行われるようになりました。しかし、すでに述べた通り、それは非常に複雑なエリアでした。棚卸リストは存在しましたが、包括的ではなく、稼働しているすべてのシステムのすべての属性情報について、私たちが望む情報が含まれているわけではありませんでした。
そして、そうした古いシステムについては特に困難でした。最新のシステムでは、エージェントソフトやスキャナを使って実際にその情報を収集することができるからです。一部のソフトは、全ての情報にタグ付けができるようなものもあります。
ACISのような独自開発のアプリケーションについて話しているのであれば、それらのツールがそれらのシステムのすべてのコンポーネントを識別することさえ難しいです。そのため、独自に作る必要があります。それは別のレベルの複雑さを追加することを意味します。
4. ACISレガシー環境固有のセキュリティ上の懸念
ACIS紛争システムは、何百万もの消費者が、ローンを拒否されたり、高い利子率につながってしまうEquifaxの信用報告書内にある不正確と考えられる情報に異議を唱えるために使用されています。 EquifaxはレガシーなITシステムに内在するセキュリティリスクについて知っていましたが、ACIS環境のセキュリティと近代化を優先することに失敗しました。
セキュリティ担当者は、Mauldin女史とPayne氏への2017年8月17日のEメールでACIS環境に関する6つの主要なセキュリティ上の懸念を特定しました。
下記に詳述する6つの主要なセキュリティ問題は、2017年8月には新たに発見されたものではありません。実際、2015年のパッチ管理手順の監査では、上記6つの問題のうち3つを特定しました。
セキュリティ上の懸念1:SunアプリケーションサーバとEquifaxネットワークの他の部分との間にセグメンテーションはありません。インターネットからアプリケーションサーバを遠隔操作できた攻撃者は、グローバルに、Equifaxネットワーク内の他のデバイス、データベース、サーバへ移動することができます。
適切なネットワークセグメンテーションは、「悪意のあるソフトウェアや攻撃者によるネットワーク上の横断的侵害を防ぎ、ネットワーク全体に広がる感染・侵害を防止するための制御の基礎を構築する」役割を持ちます。セグメント化されていない平坦なネットワークに攻撃者が侵入した場合、ネットワーク全体を自由に動き回り、重要システムや貴重なデータにアクセスすることができます。
2015年の監査では、ACISを含むレガシーなSolaris環境において、適切なセグメンテーションが行われていませんでした。暫定CSOのRuss Ayres氏によると、ACISアプリケーションは機能するために3つのデータベースへのアクセスしか必要としませんでしたが、不必要に多くのネットワークセグメントへ接続されていました。Mandiant社は、ネットワークセグメンテーションがあれば、攻撃者がアクセスできるデータ量を軽減していたでしょう。
Mauldin女史とPayne氏はどちらも、事件発生前にACIS環境にセグメンテーションがないことに気付いていないと証言しました。Mauldin女史は次のように述べています。「攻撃者の行動を軽減できたのでしょうか。はい、そうだと思います。」
セキュリティ上の懸念2:ファイル整合性監視(FIM:File Integrity Monitoring)は、環境内における許可されていない変更を警告・検出できますが、アプリケーション、Webサーバのどちらにも設定されていませんでした。
ファイル整合性監視(FIM)は、OS、データベース、およびアプリケーションソフトウェアのファイルが改竄されているかどうかを検出するためのセキュリティプロセスです。外部のサイバー攻撃の大部分は、ITシステムと構成の変更を伴います。社内システムへバックドアとして機能するWeb Shellのインストールなど、ネットワーク上で許可されていない変更をファイル整合性監視が検出し、アラートを出します。Mandiant社は、ファイル整合性監視があれば、Equifaxネットワーク内に作成された30種類のWeb Shellを検出できたと考えます。Mauldin女史は、ファイル整合性監視がACIS環境内に設置されていないことを知らなったと証言しました。
セキュリティ上の懸念3:Sunシステムは、環境全体で共有ファイルシステムを使用しているため、あるシステムから別のシステムへどの管理ファイルにもアクセスできます。これにより、あるシステムにあるメモや設定ファイルに、他のシステムからアクセスできるようになります。
システム間でのファイル共有は、特に適切に設定されたアクセス許可がない場合、非常に脆弱なプラクティスです。システム管理者は、必要性を持つ認証されたユーザーに特定のファイルへのアクセスのみを許可するようにファイルアクセス許可を設定する必要があります。ベストプラクティスは、ユーザーの権利とアクセスをその役割を果たすために必要な最小限に制限する「最小権限の原則」を実施することです。さらに、別々のファイルシステムにまたがるアカウントアクセスは制限し、監視する必要があります。
Equifaxの脆弱性トラッカーは、侵入されたACISサーバの1つにあるレガシーなSolaris OSが、「あらゆるソースポートからのNFS(Network File System)クライアントの要求を受け入れることを発見しました。NFS要求を、権限が付与された送信元ポートからのアクセスに絞ることにより、サーバは攻撃者が完全な管理権限を掌握していないシステムからの攻撃を回避することができました。」
Equifaxがシステム全体にわたり機密ファイルへのアクセスを制限していた場合、攻撃者はACIS環境外の機密データベースへのアクセスに必要な、保存されたアプリケーション認証情報を見つけていない可能性がありました。
セキュリティ上の懸念4: Webサーバログは14日間、オンラインで30日間しか保持されないため、悪意のあるアクティビティを再現することは困難で、ほぼ不可能です。
ログは、組織内のシステム・ネットワーク内で発生したイベントの記録です。ログを使用すると、攻撃者がそのネットワーク内で行った手順を再構成できるため、セキュリティインシデントのフォレンジック調査には不可欠です。ログは、保存されている期間に対してのみ役に立ちます。金融部門への高度な標的型攻撃を検出するのに平均98日かかるといわれています。米国国立標準技術研究所(NIST)は、影響の大きいシステムのログについて、3〜12ヶ月間保持することを推奨しています。脅威インテリジェンス提供サービスを展開するCrowdStrikeは、調査の実施にどれほど有用か、ログデータの種類に基づいて、3〜12ヶ月間保持する、類似した推奨を行っています。
Mauldin女史は、インターネット公開システムであるACISプラットフォームでは、ログの保存期間を延長することの重要性を否定しました。彼女は以下のように証言しています。
- A.それは必ずしも短すぎるわけではありません。私は、…ログ取得とその保存は常に「状況や性質に依存する」種の議論だと考えているためです。例えば…、何に使う目的なのか、どれだけの容量が必要なのか、どんな種類なのか、などです。そのため、ログを使用した様々な考え方がありますが、私の考えでは、環境に依存しています。
- Q.なるほど。ACIS環境は外部公開システムだと思いますが、14日/ 30日で十分…
- A.十分であると考えています。
ACISシステムによりアクセスされるデータの機密性とシステムがインターネットへ接続しているという事実から、セキュリティ業界の多くの専門家はMauldin女史の結論に反対するでしょう。Mandiant社はEquifaxのロギング機能の拡張と改善も推奨しています。
セキュリティ上の懸念5:アプリケーション内で使用されているリソースの完全なソフトウェア棚卸が管理されていません。これは、個々のオープンソースコンポーネントが十分に理解されず、文書化されていないため、個々のコンポーネントの脆弱性を迅速に特定することよりも、潜在的な脆弱性を特定するための完全なコードレビューが必要です。
包括的な資産棚卸ができていない点は、2015年の監査でも指摘され、報告書に記載されています。
包括的なIT資産の棚卸は存在せず、正確なネットワークドキュメントも存在しません。 ITインフラストラクチャに対するグローバルな視点は、組織に存在しません。正確な資産棚卸リストがないため、すべての資産に適切なパッチを適用し、構成することを困難にしています。また、セキュリティチームがすべての資産に対して脆弱性スキャンを行うことも困難にしています。全てのIT資産の状況をしっかり理解していないと、Equifaxシステムのセキュリティと安定性を確保することは非常に困難です。
議会で質問されたとき、Mauldin女史は2015年の監査結果にもかかわらずセキュリティチームのための包括的な棚卸リストの重要性を却下したようでした。Mauldin女史は、棚卸リストがないことが必ずしもセキュリティチームが「自分たちの仕事を適切に行う」ことを妨げないと述べています。彼女は以下のように証言しています。
- Q. あなたは、このような環境に完全な棚卸リストがないことを驚きませんでしたか?
- A. 驚いたとは言えないですね。しかしセキュリティの観点からすると、仕事を適切に行えなくなることはありません。
- Q. ただし、Apache Strutsがこの環境で動作していることを知っておく必要はありませんか?棚卸リストがなければわかりませんよね?
- A.まあ、わからないかもしれませんが、セキュリティの観点から適切に実行することの妨げになるとは考えていません。
脆弱なシステムにいつどのようにパッチを適用するかなど、正確で情報に基づくリスクを判断するには、組織がIT環境内に存在する資産を把握することが非常に重要です。2015年に発生した、連邦人事管理局(OPM:Office of Personnel Management)の情報漏洩が発生した際に、人事管理局の監察官が警告したように、「正確な棚卸リストが維持できなければ、OPMの情報システムを保護するためのあらゆる試みを台無しにする」わけです。
ITリスクを適切に管理する責任は、ITチームとセキュリティチームの間で分担する必要があります。Equifax環境内に存在する脆弱性を検出するのはセキュリティチームの責任でした。 EquifaxはACISアプリケーション内のApache Strutsの存在を追跡していなかったため、セキュリティチームはACISに対して適切な対応を行うことができませんでした。つまり、包括的な棚卸リストがないために、セキュリティチームは適切に自分たちの責任を果たすことができなかったのです。
セキュリティ上の懸念6:一般的な観察として、レガシーなSun / Solarisシステムへの一貫したタイムリーなパッチ適用が懸念事項です。
エクイファックスは、パッチ管理プロセスが有効ではないことを認識していました。2015年に実施したパッチ管理の監査では、「脆弱性は適時に修正されなかった」こと、および「システムは適時に修正されていなかった」と結論付けました。つまり、Equifaxはパッチ適用プロセスが適切に実施されていないことを知っており、適時に是正措置を講じることができなかったということです。
====
Mauldin女史は、情報漏洩が発生したとき、EquifaxはACISアプリケーションのペイメントカード業界のデータセキュリティ基準(PCI DSS)に準拠させる作業を行っていると述べた。PCI DSS要件は、カード会員データを保存、処理、送信する事業体に適用されます。PCIの準備は、主にセキュリティ担当者からMauldin女史への電子メールに記載されているセキュリティ上の問題を大幅に解決するためのものであり、2016年8月に開始され、2017年8月までに完了する予定でした。
PCI DSSのコンプライアンス要件には、以下が含まれます。
- ファイルの整合性監視の使用
- 強力なアクセス制御対策
- 少なくとも1年間のログの保存
- すぐに分析可能な直近3か月分のログ
- 既知の全ての脆弱性に対するパッチのインストール
- システム構成要素の最新の棚卸リストの作成と更新
Mauldin女史は、PCI DSSの実装について「計画は遅れ、これらの項目については解決していなかった」と述べています。彼女は以下のように証言しています。
- A. PCIの準備は約1年前に始まりましたが、非常に複雑です。非常に複雑で…非常に複雑な環境でした。
- Q. 1年前、2016年8月という意味ですか?
- A.はい、その期間内です。
- Q.そしてそれは2017年8月までに完成する予定ですか?
- A.そうです。
- Q.しかし遅れましたか。
- A.遅れました。
- Q.あなたはその理由をどう考えますか?
- A.まあ、私がアプリケーションチームから言われたことを思い出すと、システムが非常に複雑であり、彼らが思っていたよりも変更を加えるにはずっと時間がかかるということでした。そして、彼らはた時間内にすべてを準備することができませんでした。
5.侵害時における近代化への取り組み
Equifaxは、レガシーITシステムを継続的に運用することによって生じる固有のセキュリティリスクを認識していました。例えば、新しいセキュリティの方法論やツールを導入するよりも、一部互換性はないですが、Equifaxは新しいシステムを開発しようと決定していました。ペインは証言しました:
セキュリティ方法論、アプローチ、ツール、テクノロジなどの多くを適用しようとしているのですが、古い家を修復しようとしているようなものですね…一度に1つの部屋で作業することも、どこを直したいと計画することもできるでしょう。ただ実際には最も良い方法は、おそらく家を倒してもう一度建物を作り直すことです。それは私たちがとっていたアプローチでした。私たちは新しいシステム、そして新しいデータセンターを構築していました。それが、受け継がれてきた技術的負債を解消し、必要なすべてのコントロールを配置して最善を尽くすことができる究極的な方法だと思います…
2017年の情報漏洩の前は、Equifaxは、Project Bluebirdというプロジェクト名で、テキサス州キャロルトンに近代的なソフトウェア・デファインド・データセンター(SDDC:Software Defined Data Center)を構築していました。2015年に、「脅威ベクターはすぐに変わり、これはリスクを低減する唯一の方法」ということで、レガシーなSunサーバから全てのアプリケーションを新しい環境に移管するため、Webb氏がProject Bluebirdを開始しました。新しいデータセンターには、「高度な自動化とオーケストレーションが組み込まれており、Equifaxが持つ近代化への障壁を解決してくれる」ものでした。Webb氏、Payne氏、Mauldin女史は、全員Project Bluebirdの計画と運営に深く関わっていました。
EquifaxはACISアプリケーションをレガシーサーバからBluebirdデータセンターに移動することを計画していました。 2017年に攻撃者がACISポータルを介してEquifaxネットワークに侵入したとき、アプリケーションは依然としてレガシーなSunサーバ上で動作していました。Webb氏は証言した:
そのため、Equifax内には、2つの環境がありました。一つは私たちはBluebirdと呼んでいた次世代環境で、本質的に最先端の技術で真新しい環境でした。それから、引っ越すつもりでいたレガシー環境です。
そしてそれを移動させる計画がありました。レガシー環境から最先端の環境にすべてを引っ越しさせるまで、おそらくもう3〜5年かかりました。 もちろん、引越が完了した時点でそれはレガシーな技術になっているでしょう。まぁそれこそが、テクノロジーにかかわる楽しさですが。
Webb氏は、IT環境近代化するイニシアチブProject Bluebirdに関する、追加の課題について証言しました。彼は以下のように述べています。
- Q.レガシーな環境から移行する上での最大の障害は何ですか?
- A.古い技術では移動やリファクタリングが困難になる可能性があるため、移動してもアプリケーションが正しく動くようにする必要があります。
- Q.コストの問題はありますか?
- A.コストの問題はありませんでした。もし…もし制約があるのであれば、アプリケーションをリファクタするためのその分野の専門家が必要でした。なぜなら、アプリケーションが新しい環境に置かれても同じことをするには、アプリケーションの機能を理解している専門家が必要だからです。
IT基盤の移行に加えて、Equifaxは消費者対応管理システム(CCMS:Customer Care Management System)と呼ばれるACISシステムの代わりとなるシステムを構築していました。CCMSプロジェクトは2014年以前に進行中で、会社が他のイニシアチブの完了を優先したため複数の遅延をしていました。Payne氏は以下のように証言しています。
そのため、ACIS環境に関連してリスクが確実にあり、私たちはそれに対応しようとしました。そのため、CCMSのアップグレードを行っていました。
ACISの最大の問題の1つは、やはり公正信用取引法(FCRA:The Fair Credit Reporting Act)に準拠するように1970年代に設計されたことです。それ以来、多くの州が、紛争や開示に関する独自の法律を制定し…、これらの規則は頻繁に変更されます。そのため、規則や法律に変更があるたびに、システムを変更する必要がありました。システムは1970年代のFCRAを前提に構築された方法であるため、こうしたルールはシステムにハードコーディングされていました。だから私たちはシステムに入り込んで修正しなければなりませんでした。 それは…それは本当に時間がかかる作業でした。そしてそれは、リスクでした…システムの初期開発者がまだスタッフとして働いてくれたことは本当に幸運でした。 ですから、私がこの役割に就いたとき、これらすべてが私が心配していたリスクでした。セキュリティもおそらくリスクですが、それが主な要因ではありませんでした。管理や保守が非常に困難だったため、古いシステムを引退させることが主要なモチベーションでした。
=====
どの組織もリスクに対する許容度を決定する必要があります。リスクを管理するために、組織はイベントが発生する可能性、そして潜在的な影響を理解する必要がありました。大規模なセキュリティ投資は、必ずしも企業全体で同等のレベルで必要とされるわけではありませんが、ビジネスクリティカルなシステムと極めて機密性の高いデータは、ビジネスとその顧客に対する潜在的な大きい影響があるため、より高いレベルの対応が必要です。
Equifaxは、Project BluebirdとCCMSを使用して正しい方向に進んでいました。同社は、レガシーなITシステムを継続的に運用することによってもたらされるリスクを認識し始めたためです。しかし、同社は2017年の侵害時において、依然としてレガシー環境でACISプラットフォームを運用していたため、十分な速度で対応することができませんでした。
VI. Equifax修復の取り組み
情報漏洩の発見と、不正アクセスと情報流出を阻止するために講じられた短期的な対策の後、Equifaxは修復策を行いました。 Equifaxは、セキュリティの弱点を修正するために、この侵害後でいくつかの措置を取りました。
A. Mandiant社の改善策の推奨事項
2017年9月19日、Mandiant社は、情報漏洩に関するフォレンジック調査結果レポートを発表しました。 Mandiant社は、攻撃者は2017年5月13日から2017年7月30日までEquifaxシステムにアクセスしていたと結論付けました。この間、攻撃者はACISポータルをサポートする2つのシステムと複数のデータベーステーブルを侵害しました。攻撃者は、データにアクセスしてデータを漏洩させるために、30のユニークなWeb Shellを配置し、他の偵察活動を使用しました。Mandiant社は当初、この侵害の結果、1億4,300万人の米国消費者の個人情報が危険に晒されていると結論付けました。 Mandiant社のレポートには、Equifaxに関する11の改善提案が含まれていました。
- 脆弱性スキャンおよびパッチ管理のプロセス・手順を強化する。
- バックエンドデータベースに保持されている機密データの範囲を縮小する。
- 重要なデータベース内に格納されているデータにアクセスするための制限と管理を強化する。
- インターネット公開システムからバックエンドデータベースおよびデータ保存先へのアクセスを制限するため、ネットワークセグメンテーションを強化する。
- 追加のWAF(Web Application Firewall)を展開し、シグネチャを有効にして攻撃をブロックする。
- アプリケーション、Webサーバへのファイル整合性監視技術の展開を急ぐ。
- ネットワーク、アプリケーション、データベース、システムレベルにおいて、追加のログ取得を行う。
- 特権アカウント管理(PAM:Privileged Account Management)製品の展開を急ぐ。
- 追加のインラインネットワークトラフィック復号装置を導入し、暗号通信への「みえる化」を行う。
- 追加のEDR(Endpoint Detection and Response)テクノロジーを導入する。
- 追加の電子メール保護・監視技術を導入する。
攻撃者がEquifaxシステムにアクセスできなくなったことを確認した後、Equifaxはこれらの修正推奨事項の実装を開始しました。Mandiant社の調査が終了した翌日である2017年10月3日、元CEOのRichard Smith氏は、Equifaxの対策にについて、米国下院エネルギーおよび商業対策委員会の前に出頭しました。Smith氏は以下のように証言しています。
ここ数週間で、脆弱性スキャンおよびパッチ管理のプロセス・手順が強化されました。損失のリスクを最小限に抑えるために、バックエンドデータベースに保持されている機密データの範囲が縮小されました。重要なデータベース内に格納されているデータにアクセスするための制限と管理が強化されました。インターネット公開システムからバックエンドにあるデータベースおよびデータ保存先へのアクセスを制限するために、ネットワークセグメンテーションを増やしました。追加のWebアプリケーションファイアウォールが導入され、攻撃をブロックするように設計されたシグネチャが追加されました。アプリケーションとWebサーバへのファイル整合性監視テクノロジーも展開を進めています。同社はまた、ネットワーク、アプリケーション、データベース、およびシステムレベルの追加のログ取得を実装しています。これらは、セキュリティプロトコルを強化するためにEquifaxが最近数週間で講じた手順のほんの一部です。
重要なのは、Equifaxのフォレンジックンサルタントが、今後30日、60日、90日の期間にわたって導入する予定である一連の改善を推奨していることです。これは、会社が私の退職する時点で既に実施中だったためです。さらに、私の指示で、(Mandiant社に加え、別の)有名な独立系コンサルティング会社の専門家が、会社の情報セキュリティシステムの総合評価を行うため契約しています。
Susan Mauldin女史は、Mandian社の11の改善提案について証言しました。
- A.そうです、確かに、これら改善提案のうちいくつかは進行中であり、私たちがすでにセキュリティプログラムとして取り組んでいたものでした。 改善提案のいくつかはよりスピードを上げて取り組みました。それらを実装するため、Mandiant社と追加のリソースを用意した結果、早く完了したようです。
- Q.「スピードを上げて取り組んだ」と言った場合、それは2017年7月現在、あるいはそれ以前の話ですか?
- A.私が言及しているのは、Mandiant社が調査を支援するためにやって来た後、私たちが想定していたタイムラインよりも早く、一部の推奨事項の完了を支援するため、リソースを追加してくれたことです。
証言の別の部分では、Mauldin女史はACIS環境におけるセキュリティ上の懸念について指摘した、彼女の直属部下からの電子メールについて証言しました。これらのセキュリティ上の懸念の多くは、Mandiant社の推奨事項の一部と一致します。例えば、Mauldin女史の部下は、アプリケーションサーバとネットワークの他の部分との間にセグメンテーションがないため、攻撃者がアプリケーションサーバを制御し、Equifaxネットワーク上の他の場所に侵入できる可能性があることを発見していました。これと対応するように、Mandiant社の推奨事項にもネットワークセグメンテーションについて言及されています。この部下は、ファイル整合性監視がないことについてもセキュリティ上の問題を提言しています。これは、ファイル整合性監視技術の展開を急ぐというMandiant社の推奨に対応しています。この従業員は、Webサーバのログ取得期間が短いため、悪意のある活動を再構成することが難しいという門d際も取り上げています。Mandiant社は、7番目の推奨事項で、追加のログ取得を実施する音を強く推奨しています。
David Webb氏は、情報漏洩前に、Mandiant社の推奨事項のいくつかは既に進行中であることを確認した。彼は以下のように証言しています。
インフラ全体を見直すために、大きな努力が払われていました。それで、私が以前述べたように、私達はBluebirdと呼ばれるプロジェクトを進めていました。そして、そのプロジェクトは多くの問題を解決してくれるソフトウェア・デファインド・データセンターでした。繰り返しになりますが、そのプロジェクトの目的は、インフラストラクチャの全般的な見直しを通じてこれらの問題に対処することでした。
2018年8月、Mandiant社とEquifaxの関係者は、Equifaxが11の推奨事項をすべて実装したことを確認しました。
B. 州規制機関との2018年同意審決
Mandiant社からの推奨事項に加えて、2018年6月25日、Equifaxは8州の規制当局との間で締結された同意審決(Consent Order)の下でいくつかの措置を取ることに同意しました。 2018年の同意審決に基づき、エクイファックスは取締役会が90日以内に次の事項を含むリスク評価書を承認することに同意しました。(1)個人情報に対する予測される脅威と脆弱性(2)脅威の発現可能性(3)ビジネス運営に対する潜在的な損害(4)各脅威と脆弱性に対するセーフガードと低減コントロールの実施。2018年の同意審決の締結後30日以内に、Equifaxは監査機能を改善し、情報技術管理を評価することができる正式かつ文書化された内部監査プログラムを確立しなければなりませんでした。
Equifaxは、特にITと情報セキュリティのポリシーを見直し、承認することにより、90日以内に情報セキュリティプログラムの監督プロセスを改善することに同意しました。同じタイムフレームで、Equifaxは重要なベンダーが情報を安全に取り扱っていることへの監督責任を改善することで合意しました。
2018年の同意審決では、パッチ管理の基準と管理を改善することが要求していました。2018年の同意審決では、「パッチが適用されていないシステムの数とパッチ適用に時間がかかるインスタンスを減らすため、効果的なパッチ管理プログラムが実装されていること」と規定されています。そのため、Equifaxは次のことに同意しました。(1)包括的なIT資産棚卸リストを作成する。(2)必要なパッチを定期的に特定するプロセスを定式化する。(3)レガシーシステムを廃止するための行動計画を作成する。(4)そのパッチ管理ポリシーを定式化する。
2018年同意審決におけるパッチ管理に関する項目は、Mandiant社からの第一の推奨事項、Equifaxはパッチ管理手順とプロセスを強化すること、という項目に対応しています。2018年同意審決における内容は、Equifax社内部で行われた2015年のパッチ管理監査の指摘事項も反映されています。2015年の監査は、レガシーシステムをできるだけ早く廃止し、システムにタイムリーにパッチを適用するための自動ツールを実装し、予防的なパッチ適用プログラムを作成し、包括的なIT資産棚卸リストをまとめることを推奨しました。
Equifaxは、2018年の同意審決で、IT運用の災害復旧(Disaster Recovery)と、事業継続(Business Continuity)の機能への監督を強化することに同意しました。Equifaxは、同意審決への準拠状況の詳細について、報告書を提出する必要があります。 2018年同意審決に関して、Graeme Payne氏は次のように証言した。
私は州[検事総長]との審決を見て、約束事項をすべて読みました。私は、Equifaxの幸運を祈っています。なぜなら、彼らが合意した内容には、多くの要求事項が含まれており、多くの投資が必要であり、構築するにあたり多くの努力が必要なものばかりだからです、
C. 米国政府監査院の調査結果
2018年8月30日、米国政府監査院(GAO:U.S. Government Accountability Office)は、Equifaxがこれまで取り組んだ情報セキュリティ改善活動を詳述した報告書を発表しました。この情報漏洩インシデント後、米国政府監査院はEquifaxがシステムレベルの是正措置とより広範なプログラムによる措置の両方を講じたことを確認しました。米国政府監査院のドラフトレポートによる検出事項は、米国公正取引委員会の訴訟に関する公開情報と、Equifax社の担当者からの情報をもとに作成されています。
Equifaxは、侵害の原因となった弱点に対処するためのシステムレベルの修正措置を講じました。米国政府監査院の報告書によれば、Equifaxの担当者は、この侵害の一因となった5つの主要な弱点を提示しています。
- ソフトウェアの更新
- ソフトウェア構成
- アクセス制御
- ネットワーク監視
- 境界防御
ソフトウェアアップデートが適切に管理されておらず、Apache Strutsパッチが適用されていないという事実に対処するために、GAOは「Equifaxはソフトウェア脆弱性を識別および修正し、脆弱性が解決されたことを確認するための新しい管理プロセスを導入した」と記載しています。スキャンツールによるApache Strutsの脆弱性の検出を妨げていた脆弱な設定管理に対応するため、GAOは「Equifaxは、脆弱なレガシーシステムをアップグレードまたは排除します。そして、新しいエンドポイントセキュリティシステムを導入して、設定ミスを検出し、潜在的なIOCを評価し、自動的に特定された脆弱性をシステム管理者へ知らせます。」と記載しています。Equifaxは、「新しいセキュリティ制御フレームワークと、特定のシステム、アプリケーション、およびネットワークへのアクセスに対する厳格な制御」を実装することにより、侵入者が多数のクエリを実行し、個人情報を含むファイルへアクセスを許してしまった脆弱なアクセス制御へ対応することに同意しました。
GAOによると、監視装置の設定が誤っていると、暗号化されたWebトラフィックがEquifaxネットワークを介して検査されないようになります。これを防ぐために、ネットワーク通信が継続的に監視することを確実にするため、Equifaxは新しいポリシーを開発し、新しいツールを実装したとGAOは報告しています。様々なデータベースへのアクセスを許してしまった脆弱な境界防御を修正するため、Equifaxは、通信を監視し、内部サーバ間のトラフィックをさらに制限するため、外部境界に追加の制御を実装しました。
GAOによると、Equifaxはより広範なプログラムレベルの対策を実施しました。これらの対策の1つは、CSOの組織体制の変更でした。CISO(以前のCSO)はCEOに直接報告し、トップマネジメントによるサイバーセキュリティリスクの可視化を可能にしました。
D. SECに報告された是正措置
Equifaxの2017年の年次SEC(10-K)申告は、同社が侵害調査中に特定された弱点に対処するため、様々な是正措置を講じたことを示しています。10-Kの申告では、Equifaxは以下のように述べています。「弊社は、この種のインシデントが再発することを防ぎ、消費者、顧客、および規制当局の信頼を取り戻すことを目的とした広範な措置を講じています。」そして、レポートは、次のように続きます。
サイバーセキュリティインシデントの後、私たちはデータセキュリティインフラストラクチャを強化するために重要なステップを踏み出しました。これらの取り組みに関連して、当社は、当社のシステムおよび当社が維持するデータへの不正アクセスを防止する目的でさらなる措置を講じるため、多大な費用を負担し、さらに多額の費用を負担することを想定しています。私たちが行った行動はサイバーセキュリティインシデントの原因調査に基づいていますが、同様の事件を防ぐために追加の対策が必要となるでしょう。また、サイバーインシデントが速やかにエスカレートされ、調査され、上級管理職に報告されるよう、また必要に応じて取締役会に報告されるように、開示管理と手続き、関連するプロトコルを強化しました。また、独立した外部コンサルティング会社と契約し、戦略的な対策活動を支援してもらい、サイバーセキュリティのフレームワークを、統制の枠組み、そして経営陣と従業員の役割と責任を見直しています。
E.サイバーセキュリティに対するEquifaxの最新アプローチ
Equifaxは、2018年の投資家への年次委任状の中で、Equifaxのサイバーセキュリティ態勢を強化するために取締役会の監督をどのように強化してきたかを報告しています。取締役会の監督を強化には以下が含まれます。(図14参照) 図14:Equifax取締役会の監視プラン
Equifaxは、情報漏洩後のITおよびサイバーセキュリティへの支出を増加させました。2017年11月、暫定CEOであるPaulino do Rego Barrosは、情報漏洩が発見されてからEquifaxのセキュリティ支出は4倍にまで増加したと発表しています。Equifaxは、2018年最初の9ヶ月間にサイバーセキュリティ事故に関連して2億2,150万ドルの費用を報告しました(図15参照)。 図15:サイバーセキュリティインシデントに関連する2018年のEquifaxコスト
それとは対照的に、Susan Mauldin女史は、2017年9月にEquifaxを去った時点における、セキュリティチームの年間予算は3800万ドルであると証言しました。
F.修正策に関するEquifax担当者
Equifaxの新しいCEO(最高経営責任者)として任命されたMark Begorは、以下のようにコメントした。「我々は正しい防御を持っていなかった。しかし、二度と起こることがないように事業を守るため投資している」と報道した。委員会がインタビューした3人の証言者全てが、Equifaxがセキュリティに適切に投資していると証言していました。Begor氏のコメントに対して訪ねた時、Payne氏は以下のようにコメントしています。
私は思うに…たくさんのギャップがあったと思います…私たちはそのことを知っており、取り組んでいたと思います…。防衛策を講じていなかったという問題ではありません…正しい対応がたくさん行われてきました。問題は、我々が必ずしも十分かつ包括的ま取り組みを行ってこなかったことだと思います。
資産の棚卸リストはありましたが、包括的なものではありませんでした。パッチを適用するプロセスはありましたが、十分なものではありませんでした…(脆弱性の)通知はありましたが…通知が必要なすべての人に行き渡っていませんでした…スキャンはしましたが、全てをスキャンしたわけではありません…そのため、防御を行っていなかったというわけではありません。
Webb氏は、Equifaxがこの情報漏洩を防止できなかったことは支出の問題ではなく、むしろ実行の失敗であると述べています。彼は、以下のように証言しています。
- A.やはり、結局のところ、私たちはかなりの金額を支出していました。私たちはツールと機能を持っていました。人員とプロセスコンポーネントが機能しているかどうかは、支出ではなく評価する必要があることです。
- Q.その通りですが、ITとセキュリティに適切に費やしていたとしたら、このサイバー攻撃を検出したセキュリティツールがないのはなぜですか。
- A.これらのツールは、人とプロセスが適切に機能し機能するためにも必要です。
Mauldin女史は、Equifaxが情報漏洩を防ぐための努力を行ってきたか証言しました。彼女は以下の証言をしています。:
私たちはたくさんの良い仕事をしたと思います。しかし、今回のインシデントは非常に残念でした。多くの人と同様、私は深く後悔しています。しかし私は、意識を保ち、警戒を続け、攻撃グループより一歩先にいくことが重要だと考えています。彼らは非常に洗練されており、資金も充実しているので、すべての企業が継続的に努力し、推進していく必要があります…精力的に物事を成し遂げ、計画を完成させるなどです。私にとっては、その重要性が最も重要だと考えます。
VII. 推奨事項
推奨1:透明性を通じた消費者へのエンパワーメント
消費者信用情報サービス(CRA)は、どのデータが収集され、どのように使用されるかについて、消費者に対してより透明性を提供すべきです。Equifaxの情報漏洩発表後、多くの人の懸念事項は、消費者信用情報サービスが保有している個人の広範なデータの理解不足から生じています。消費者信用情報サービスは、消費者が自身のデータをより適切に管理できるように、追加のツールに投資し、展開する必要があります。例えば消費者信用情報サービスは、個人に関して収集されたデータを説明する無料の簡単なサマリを消費者に提供するべきです。サマリには、消費者信用情報サービスが過去1年間にデータをビジネスに提供した回数を含める必要があります。サマリは、無料の年間信用レポートの提供以外に、いつでも閲覧できるように消費者に提供されるべきです。これにより、消費者は消費者信用情報サービスが持っている情報を追跡し、収集された情報が共有される頻度を知ることができます。信用レポートに対する「凍結」機能は、消費者が自分のデータをより強力に管理できる機能を提供します。 消費者信用情報サービスは、すべての消費者に無料で信用レポートの凍結を提供することを義務付けられています。信用レポートの凍結を含むこれらの透明性対策のどれも、消費者に追加サービスへのサインアップ、あるいは別のコミットメントを要求するべきではありません。
推奨2:FTCの監視および執行当局の十分性を検討する
現在FTCは、連邦取引委員会法第5条に基づく法定権限を使用して、データセキュリティについて虚偽または誤解を招くような主張をしたり、合理的なセキュリティ対策を講じなかったことに対して企業に責任を負わせています。情報漏洩の発生有無によらず、FTCが消費者信用情報サービスのデータセキュリティの取り組みを効果的に監視し、消費者信用情報サービスに保存されている消費者データを適切に保護するよう奨励するためには、追加の監督当局の関与や実行ツールが必要になる場合があります。
推奨3:情報漏洩被害者に提供されたアイデンティティ監視・保護サービスの有効性の確認
GAOは現在のアイデンティティ保護・保護サービスの有効性を検討し、議会に勧告を提供すべきです。特にGAOは、個人情報の盗難リスクを軽減するため、情報漏洩後にクレジット監視・保護サービスが必要とされる期間を見直すべきです。 Equifaxは、1年間無料のクレジット監視・保護サービスを要望した消費者に対して提供しました。信用監視サービスの価値と保護を提供すべき推奨期間の両方について、様々な意見が委員会に提供された。このGAO調査は、信用監視サービスの価値とそのようなサービスを維持すべき期間を明確にするのに役立ちます。 GAOの調査では、信用監視サービスの代替案を検討し、信用監視サービスによって提供される保護を強化するための追加または無料のサービスを検討する必要があります。
推奨4:民間部門におけるサイバーリスクの透明性の向上
連邦機関と民間部門は協力して、企業のサイバーセキュリティリスクの透明性とそのようなリスクを軽減するための対策を強化する必要があると考えます。民間事業体がどのように会社のサイバーリスクに関連する透明性を高める方法の一例はとして、米国証券取引委員会(SEC)の提出書類に開示を行うことです。2011年米国証券取引委員会は、企業がサイバーセキュリティのリスクとインシデントを開示を支援するガイダンスを作成しました。米国証券取引委員会のガイダンスによると、サイバーセキュリティのリスクとインシデントが「投資家にとって重要な要素」である場合、非公開企業は当該情報を登録届出書、財務諸表、および8-Kフォームに開示することを求められる可能性があります。Equifaxは、2017年の情報漏洩の前において、サイバーセキュリティリスクとインシデントを米国証券取引委員会の提出書類に開示していませんでした。 米国証券取引委員会などの連邦機関は、企業のサイバーセキュリティの姿勢に対する意識を高めるために、サイバーリスクの一般への開示を引き続き促進する必要があります。
推奨5:連邦機関の外部委託業者は、明確な要件を持つサイバーセキュリティへの責任を持たせる
Equifaxによる情報漏洩と政府系顧客によるEquifaxアイデンティティ検証サービスの使用は、連邦政府が調達を行う上でサイバーセキュリティリスクの軽減に注意する必要があることを浮き彫りにしています。米国行政管理予算局(OMB:The Office of Management and Budget)は、特に個人情報処理に関連している部署であるため、増大するサイバーセキュリティリスクに対処するために、外部委託業者に明確なサイバーセキュリティ要件を策定する努力を継続する必要があります。サイバーセキュリティとデータセキュリティのリスクベース要件に関する政府統一のフレームワークがあるべきだと考えます。
2016年、委員会は米国行政管理予算局に対し、連邦政府が調達を行う際に、買収のためのサイバーセキュリティ要件の改善・更新を行うように要請しました。特に、外部委託業者のためのサイバーセキュリティ要件に対処するために、2016年に複数の調達要件と条項が確定しました。アメリカ国立公文書記録管理局(NARA:The National Archivers and Records Administration)は、個人情報のような管理下にある未分類情報(CUI:Controlled Unclassified Information)の取り扱いと保護方法について、ルールを定め、機関への指示を行いました。CUIプログラムは、各機関と外部委託業者が未分類のセンシティブ情報を取り扱う際の、標準化プロセスと取り扱い方法を確立しました。2019年3月には、CUI処理について、契約条項を含む関連調達規則についてルール策定が行われることが通知される予定である。委員会は米国行政管理予算局に対し、連邦政府機関と調達専門家へ指針を提供するため、長期間約束されていたサイバーセキュリティの調達覚書の作成を促進するよう要請します。
その間、連邦機関は既存のツールを利用し、外部委託業者にサイバーセキュリティの説明責任を負わせるべきです。 たとえば、政府機関は、外部委託業者のサイバーセキュリティ実行・リスクの監督、外部委託業者の過去の実績情報の検討、調達時の評価要素へサイバーセキュリティ要件導入、(過去問題を発覚した企業の)一時停止と入札参加停止メカニズム(The Suspension and Debarment)の活用を積極的に検討する必要があります。 Equifaxは3つの連邦機関に本人確認サービスを提供し、これらの機関は情報漏洩事件の影響を受けて行動を起こしています。米国内国歳入庁(IRS:The Internal Revenue Service)、米国社会保障局(SSA:Social Security Administration)、米国郵政公社(USPS:the U.S. Postal Service)はセキュリティコントロールの状況を評価するため、ジョージア州AlpharettaにあるEquifaxのデータセンターに訪問し、オンサイト評価を行いました。米国社会保障局(SSA)はEquifaxのコンプライアンス状況について、NISTセキュリティベースライン管理を使って評価し、この情報を米国内国歳入庁(IRS)と米国郵政公社(USPS)と共有しました。
推奨6:個人識別番号としての社会保障番号の利用削減
行政部門は、社会保障番号(SSN)への依存を減らすため、民間企業と協力するべきです。社会保障番号は、個人を識別・認証するため、公共部門および民間部門で広く使用されています。認証情報は、機密に保たれている場合にのみ役立ちます。攻撃者は、Equifaxから推定1億4,500万人の消費者の社会保障番号を盗みました。この情報漏洩の結果、国民の社会保障番号の約半分がもはや機密情報ではなくなりました。こうした情報の盗難から消費者をより適切に保護するためには、米国行政管理予算局、そしてその他の関連連邦機関は、社会保障番号の使用の代わりに、新しい技術的解決策を追求する必要があります。
推奨7:最新ITソリューションの実装
重要な消費者データを保存する企業は、レガシーなIT環境から移行し、最新のITセキュリティソリューションを実装する必要があります。Equifaxは、IT環境を適切なタイミングにIT環境を刷新することに失敗しました。 ACISアプリケーションが置かれているレガシーなIT環境が複雑であるため、攻撃者はEquifaxネットワーク内を移動し、関係のない消費者の個人情報へアクセスすることができました。EquifaxのレガシーIT環境は、スキャン、パッチ適用、修正が困難でした。委員会は、連邦機関にとって、最新のITソリューションがもたらすセキュリティ上の重要な利点を強調しました。委員会は、核組織がIT環境刷新の内部留保金を再投資できるようにすることで、新技術導入を奨励する政府機関技術近代化法(MGTA:Modernizing Government Technology Act)を可決しました。民間企業、特にEquifaxのような機密性の高い消費者データを保持している企業は、最新のツールや技術への投資を優先しなければなりません。