先日開催された、Intenet Week 2019の「D2-3 組織を更に強くする「攻めの」サイバー攻撃対策」のセッションで機会をいただき、講演をしてきました。
スライドは以下で公開されていますので、よろしければご参照ください。（Internet Week 2019）
レポートで振り返るEquifax事件
Equifax情報漏洩事件とは、Apache Strutsの脆弱性を悪用され、約1.5億件のレコードが漏洩した事件で、史上TOP10入りする規模のインシデントです。この事件については、その規模や攻撃ベクタが顕著であることもあり、色々学ぶべき点が多いインシデントだと考えています。
2018年12月19日に、米国下院監査政府改革委員会（The US House of Representatives Committee on Oversight and Government Reform）がEquifaxに関する包括的なレポートを公開しました（その後、トランプ政権によるGovernment Shutdownの影響でアクセスできないようになっていましたが、現在はアクセスできるようです）。
非常に面白いレポートであるため、条件付き翻訳を行いました。
- Google翻訳を下訳として、その後人間による翻訳
- 注釈については翻訳を省略
- 見直しなし（そのため、翻訳の単語がずれている可能性があります）
非常に包括的であり、また企業ドラマのようなレポートですので、ぜひ翻訳をお読みいただきたいと思います。
また、以下は、読んでおくべきレポートだと思います。
一つは、米国政府監査院（GAO）レポートです。
もう一つは、上位議員Elizabeth Warren女史のレポートです。
いかに、これを踏まえたサマリを作成します。（参照URLがないものは基本的に上記レポートを参照して記載しています）
基礎情報
Equifax社とは？
- 米国内で三大消費者信用情報サービスの一つ（残り２社：Experian社とTransUnion社）
- 全世界24か国でビジネスを展開しており、10億人（厳密には、8億2000万人）近い消費者個人の信用情報と１億人（厳密には9100万人）企業の信用情報を取り扱っている。そのデータ量は、「毎日、米国議会図書館の1200倍のデータを取り扱っている」ことに相当する。
- クレジットスコアを評価するため、クレジットカード利用歴、入出国履歴、収入、資産、銀行口座、住所、借入履歴、支払い履歴など各種個人情報を収集している。個人資産データの価値は、20兆ドルに相当する資産を持っている。
- CEO Richard Smith氏が2005年に就任して以降、買収を重ねて事業を拡大。株価が38ドル（2005.12）→ 138ドル（2017.09）まで上昇。インシデント公表前日の市場価値は、約170億ドルであり、33億の収益を持つ大企業に成長した。
ACISシステム
- 消費者苦情ポータルであるACISシステム（Automated Customer Interview System）
- 法規制対応のため、1970年代にインターネット公開向けに開発されたシステムで、、信用ファイルの誤りを訂正したり、異議を申し立てることができるサービスの根幹を担うサービス
インシデント詳細
インシデント詳細をいかに示します。
タイムライン
翻訳「主要なイベントのタイムライン」を参考にしてください。
最低限のタイムラインを以下に示します。
- 2017/03/06：Apache Strutsの脆弱性が公開
- 2017/03/10：Apache Strutsの脆弱性を使った偵察行為が行われた痕跡あり
- 2017/03/15：Apache Strutsの脆弱性を発見するためにスキャンを実行
- 2017/05/13：（調査より）情報漏洩につながる侵入を受けたとされる最初の日
- 2017/07/29：Equifaxが不正な通信を検知し、サイトを完全停止
- 2017/09/07：Equifaxが情報公開。株価は、35%下落
侵害原因
2017年3月7日に公開されたWebアプリケーションフレームワーク Apache Struts2の既知の脆弱性 CVE-2017-5638（S2-045/S2-046）を悪用されたためです。
以下の不随情報は以下の通りです。
- Equifax内部でUS-CERTから当該脆弱性に関する情報が共有されていた。脆弱性の危険度から、Equifax内部では48時間以内にパッチを当てるルールとなっていた。しかし、「人為的なミス」によりパッチ適用は行われなかった。
- その後、03/15に内部でスキャンを実行したが、Apache Strutsが使われているインベントリが行われていないこともあり、発見できず。そのため、7月末にインシデントが発覚するまでの約4.5か月間、パッチが適用されていなかった。
- CVE-2017-5638は、CVSS Base Scoreが10.0（Critical）を持つ「リモートから任意のコマンド実行」の脆弱性である。そのため、公開から数日間に攻撃が発生し、攻撃コードやGUI攻撃ツールが公開された。
- 当該脆弱性は、日本でも大きな影響をもたらした。GMOペイメントゲートウェイ社が構築した２つのサイト（都税クレジットカードお支払いサイト、住宅金融支援機構）では、クレジットカード情報を一部含む70万件の情報漏洩という大きなインシデントになった*1。
- 一方、NTTコミュニケーションは、OCN IDサーバでApache Struts 2を利用していることが判明し、3/7の脆弱性公開後、3/8の朝サイト停止を行う判断したことで知られている。*2
より詳しいまとめは、piyologを参照してください。
漏洩した情報
1億4550万件の米国消費者情報が漏洩し、大規模漏洩の一つとして知られています。
米国証券取引委員会の発表により、以下の情報が漏洩したとして知られています（以下に、翻訳版を載せています）。約1.5億の社会保障番号が漏洩していることから、国民の約半数の情報が漏洩したと考えられます。
調査は主に米国主導で行われていますが、グローバル企業であるため米国消費者以外の情報も漏洩しています。例えば、BBCによると、役69万件の情報が漏洩したと報道されています。
事故対策費用
事故対応費用については、現在も動いているため確定的なことが言えませんが、財務報告書から以下のことが読み取れます。
- 2018年12月末までの２年間の総費用は、5億6520万ドル（$565.2M）になる。
- サイバー保険は、1億2500万ドル（$125M）を払う契約になっており、２年間にわたり全額支払われている。カバー率は22.1%であり、これは既存のターゲット社やホーム・デポ社のカバー率と比較すると低い。（詳細はコチラ）
- 実質的負担額は、4億4020万ドル（$440.2M）である。
2017年の支出
2017年の四半期報告書をまとめると、以下の通りです。
2018年の支出
2018年の四半期報告書をまとめると、以下の通りです。
- ITとデータセキュリティは、アプリケーション、ネットワーク、データセキュリティ、システム開発費、Lock & Alertサービスの立ち上げなど、技術基盤の移行コストである。
- リーガル・調査費用とは、法的、政府対応、規制対応などの対応費用である。
- Product Liablityとは、TrustedIDサービスを利用するためのコストを意味する。
- 2017年に5000万ドル支払われた保険金が、2018年は7500万ドル支払われた。
ACISシステムに対する攻撃
- 3月10日時点で、本脆弱性を利用した攻撃の痕跡あり。但し、whoisコマンドの実行痕跡のみであり、「偵察」の要素が強いと判断される。本件の技術的調査に当たったMandiant社は、今回の情報漏洩につながる5月13日から始まった情報漏洩攻撃との関連性を示す証拠を確認できていない。
-
5月13日、攻撃者はEquifaxへのサイバー攻撃を開始。攻撃は76日間続く。
-
Equifaxのネットワークを遠隔操作するため、Web Shell（Webベースのバックドア）を配置。内部のネットワーク、データベースがセグメント化できていないこと、暗号化されていない認証情報（ユーザ名とパスワード）を含むファイルがファイル共有上に配置されていることなどから、ACISシステムと無関係なデータベース48個へアクセスして情報を取得。約9000回のリクエストを発行し、うち265回は個人情報を引き出すクエリだと推定されている。
- 取得した個人情報はファイルを圧縮して、Webからアクセス可能なディレクトリへ配置して情報持出を行う。（一部、Web Shellの機能も利用した模様）
- 攻撃を通じて、35種類のIPアドレスを使ってACISシステムとやり取りしている。
Project Sierra：インシデント対応
インシデント対応として、以下を実施している。
- 法律事務所（King and Spalding）と契約しリーガルアドバイザとして契約
- Equifaxのセキュリティチーム + Mandiant社による技術調査
Project Sparta：９月７日への情報公開に向けた顧客対応
情報公開の準備のため、以下の作業を行っている。
- 専用サイトの作成（情報漏洩有無＋各種サービスへの登録）
- 500名規模のスタッフを配置した緊急コールセンターの立ち上げ
- インシデントを受けた事後対応サービスへの案内（１年間無償）
- クレジットカード利用監視サービス（Credit Monitoring）
- アイデンティティ盗難監視サービス（Identity Theft Service）
根本原因・推奨策
米国下院監査政府改革委員会による推奨策
セキュリティ上の今回の問題点として、本レポートでは６種類挙げています。
-
セキュリティ上の懸念１：SunアプリケーションサーバとEquifaxネットワークの他の部分との間にセグメンテーションはありません。インターネットからアプリケーションサーバを遠隔操作できた攻撃者は、グローバルに、Equifaxネットワーク内の他のデバイス、データベース、サーバへ移動することができます。（さらにいえば、データベース内も分離されていなかったと考えられます）
-
セキュリティ上の懸念２：ファイル整合性監視（FIM：File Integrity Monitoring）は、環境内における許可されていない変更を警告・検出できますが、アプリケーション、Webサーバのどちらにも設定されていませんでした。
-
セキュリティ上の懸念３：Sunシステムは、環境全体で共有ファイルシステムを使用しているため、あるシステムから別のシステムへどの管理ファイルにもアクセスできます。これにより、あるシステムにあるメモや設定ファイルに、他のシステムからアクセスできるようになります。
-
セキュリティ上の懸念４： Webサーバログは14日間、オンラインで30日間しか保持されないため、悪意のあるアクティビティを再現することは困難で、ほぼ不可能です。
-
セキュリティ上の懸念５：アプリケーション内で使用されているリソースの完全なソフトウェア棚卸が管理されていません。これは、個々のオープンソースコンポーネントが十分に理解されず、文書化されていないため、個々のコンポーネントの脆弱性を迅速に特定することよりも、潜在的な脆弱性を特定するための完全なコードレビューが必要です。
-
セキュリティ上の懸念６：一般的な観察として、レガシーなSun / Solarisシステムへの一貫したタイムリーなパッチ適用が懸念事項です。
その他、レポートから読み取れる課題を以下に列挙します。
Mandiant社による推奨策
セキュリティ上の今回の問題点として、Mandiant社は１１種類の推奨策を上げています。
- 脆弱性スキャンおよびパッチ管理のプロセス・手順を強化する。
- バックエンドデータベースに保持されている機密データの範囲を縮小する。
- 重要なデータベース内に格納されているデータにアクセスするための制限と管理を強化する。
- インターネット公開システムからバックエンドデータベースおよびデータ保存先へのアクセスを制限するため、ネットワークセグメンテーションを強化する。
- 追加のWAF（Web Application Firewall）を展開し、シグネチャを有効にして攻撃をブロックする。
- アプリケーション、Webサーバへのファイル整合性監視技術の展開を急ぐ。
- ネットワーク、アプリケーション、データベース、システムレベルにおいて、追加のログ取得を行う。
- 特権アカウント管理（PAM：Privileged Account Management）製品の展開を急ぐ。
- 追加のインラインネットワークトラフィック復号装置を導入し、暗号通信への「みえる化」を行う。
- 追加のEDR（Endpoint Detection and Response）テクノロジーを導入する。
- 追加の電子メール保護・監視技術を導入する。
米国政府監査院によるレポート
米国政府監査院によるレポートによれば、５種類の弱点を指摘しています。
- ソフトウェアの更新
- ソフトウェア構成
- アクセス制御
- ネットワーク監視
- 境界防御
補足的な課題
上記に上がらない付随的な課題を以下に示します。
課題１：メーリングリストの管理
- US-CERT経由で本脆弱性に関する通知を受け取っており、GTVMチーム（Global Threat and Vulnerability Managementチーム）のメーリングリスト経由で430名に対してこの内容を共有している。また、3/16時点でも、GTVMチーム資料にてパッチ適用をリマインドしている。
- GAOレポートによれば、このメール受信者リストは更新されておらず、適切な担当者に対してメールが届いていなかったと指摘されている。
- 10月２日に、ACIS環境の担当であったGraeme Payne氏は、3月9日のApache Strutsパッチアラートの転送に失敗したことを理由に解雇された。
課題２：パッチ管理プロセスとスキャン
- パッチ管理プロセスが適切に行われておらず、ACISシステムへのビジネス所有者、担当者、パッチ適用の責任者が明確化されておらず、パッチ適用についても実運用レベルで責任範囲が不明確であり、知識を持つ個人によりカバーされていたと考えられる。
- 脆弱性スキャンを実施しているが、検出されていない（レポートでは、インベントリ管理ができていないこと、コンテキストパスに脆弱性スキャンを実施していないことが検出できなかったとしている。但し、このApache Struts脆弱性は、ツールによるスキャンでは検出できない可能性があると考えられる。）
課題３：証明書管理プロセス（管理セキュリティ機能設定の不備）
内部のセキュリティ証明書の有効期限が切れており、SSL可視化アプライアンスは、証明書がないため、暗号化通信を複合しない状態で、IDS/IPSを通過していたことになります。そのため、IDS/IPSは検知することができませんでした。
セキュリティ証明書は、2016年1月31日で有効期限が切れており、324個の証明書が有効期限切れになり、19か月間通信を監視できていない状態が続いています。
また、本報告書には書かれていないため推測になりますが、19か月もアラートがなければSecurity Operationチームも検知率の低さに気付くべきだとも考えられます。
課題４：IT組織構造の不備
Equifaxのレポートを読み解くと、セキュリティチームとITチームのサイロ化があったことが浮き彫りになっています。特に、セキュリティチームはCLO（Chief Legal Officer）配下にあるため、ITチームとの連携や責任範囲が明確にならず、今回の事象が発生していたと考えられます。
- CIO Robert Webb氏とCSO Tony Spinelli氏が基本的に意見の不一致が多いため、セキュリティ機能をIT部門から法務部に移管した。以降、CLO（Chief Legal Officer）が "Head of Security"として機能していた。
- その体制は情報漏洩インシデント発覚まで変化せず、担当者が変化した後も、CIOとCSOとのパートナーシップは進まず、サイロ化されていた（そのため、両チームの責任範囲が明確になっていなかったと考えられる）。
- 2016年にIT内の組織体制変更を受け、Graeme Payne氏がIT Risk and Compliance Groupを担当することになった。そのため、Payne氏はCLO配下にいるセキュリティチームとの調整・連携を担当とすることになった。
- また、CSO Susan Mauldin女史は、1983年からHewlett Packard社のソフトウェアエンジニアとしてテクノロジー分野のキャリアを開始し、他の企業でITとセキュリティの役職を経験した後、この役職についている。しかし、大学でITやセキュリティを専門的に学んだ経験がなく、ログ取得が３０日で十分であるなどと少しセキュリティ専門家として常識とは異なる考えを持っている。
課題５：サイバーセキュリティに関する経営層の優先度
Equifaxでは、セキュリティが重視されていませんでした。
- CEO Richard Smith氏は、四半期に一度の経営会議でしか、セキュリティの状態を確認しておらず、タイムリーに情報を受け取って」いなかった。
- CSO Susan Mauldin女史は、経営層だと見なされていないため、このミーティングに参加しておらず、CLO経由で報告を行われていた。
- 2015年のパッチ管理プロセスの監査で８項目の指摘を受けていたが、対策が行われていなかった。
課題６：複雑かつレガシーなIT環境
- ACIS環境は、1970年代後半に構築されたシステムであり、複雑かつレガシーなIT環境を継続して使い続けていた。ACISシステムは、現在も雇用されているベテラン開発者によってなんとか存続していた（Sun Microsystems社が開発したSolaris OSに独自開発を組み込んでおり、かなり老朽化していると思われる）。
- IT環境が複雑であるため、フォレンジック調査に時間がかかったといわれている。また、漏洩件数を特定する上で、データの意味・整合性を維持する上で、データベース管理者と協力する必要があるが、そのリストが適切に管理されていなかった。
- インシデント発覚後の調査から、SQLインジェクション、アクセスコントロールの不備なども検出されています。そのため、脆弱性診断などの実施プロセスなども適切に行われていなかったと考えられる。
- 現在では、Project Bluebirdと呼ばれるプロジェクトが動いており、ACISシステムの再構築が行われている。
不随する被害状況
本インシデントに伴い、以下のような影響が出ています。
企業価値の定価と格付け
- インシデント公開後、約140ドルで安定していた株価が、35％程度急落して、93ドル程度になった。
- Moody's社は2017年の大量データ漏洩により損失を出し続けたことから、Eguifax社の格付け見通しをステーブルからネガティブに引き下げた。格付け見通しの修正は、Equifax社が今月初めSEC（米証券取引委員会）に提出した文書を受けて実施された。2017年に発生した1億4000万件を超える情報流出関連で要した2019年1Qの6億9000万ドルの支出を理由に挙げている。これは信用格付け機関が、サイバー攻撃による財政的影響を理由に、企業の格付け見通しを引き下げた初の事例として知られている。
法規制への抵触と政府機関等による調査
- 今回の情報漏洩は、以下の法規制に関係している。
- 連邦取引委員会法（Federal Trade Commission Act）
- ドッド・フランク法（Dodd-Frank Act）
- 公正信用報告法 (Fair Credit Reporting Act)
- グラム・リーチ・ブライリー法（GLBA：Gramm-Leach-Bliley Act）
- 各州が定める情報漏洩通知法
- FBI、FS-ISAC、SEC、FTCなどに対しても情報連携を行う。
- 政府機関にもサービスを提供していたため、政府機関による調査を行った。米国社会保障局（SSA）はEquifaxのコンプライアンス状況について、NISTセキュリティベースライン管理を使って評価し、この情報を米国内国歳入庁（IRS）と米国郵政公社（USPS）と共有した。
訴訟
- サンフランシスコ市が、「1500万人以上のカルフォルニア住人の個人情報保護に失敗した」として訴訟を開始。*3
-
Equifax社が州と連邦政府による捜査の和解、顧客からの要求への対応として、最高で7億USドルを支払うことを決定。同社は州政府、米消費者金融保護局、途上与信ファンドに対し5億7500万USドルを支払う。また必要に応じて、ファンドに対し追加で1億2500万USドルを支払うことを合意している。*4
事後対応における批判
批判1：情報公開用特設ページ＋コールセンターへの批判
- コールセンターを急いで構築したため、電話がつながらない、明確な回答が得られないなどの批判が出る。
- 顧客が自分の情報が漏洩しているか否か確認するため、equifaxsecurity2017.comというサイトを構築したが、本来の会社ドメインequifax.comとは異なるためわかりづらいと指摘を受ける。
- Twitterの公式アカウントも、誤ったURL（securityequifax2017.com）と書いてしまい、2週間の間フィッシングサイトへ誘導。当該ドメイン自体は、セキュリティ研究者により取得されており、フィッシングサイトというより、啓蒙サイトとして機能した。
- サイトがうまく機能せず、クレジット監視サービスへの登録がうまく機能しない、同じユーザで携帯電話とPCで結果が異なるなど、不具合を指摘されている。
- サイトのセキュリティ対策がお粗末だと指摘される。具体的には、サーバ証明書としてCloudFlareの共用証明書を利用し、実在性証明が担保されていない、WordPressで構築されており、広告会社Edelman PRを使っていることなどがBrian Krebs氏によって露呈する。
Not only did @Equifax suffer a massive data breach, but their site about the breach is using a free shared CloudFlare SSL cert. ಠ_ಠ pic.twitter.com/r4bvPpde1i
— Daniel Lo Nigro (@Daniel15) September 8, 2017
批判2：幹部の退職
９月７日にインシデントを公開した後、Mandiant社の調査が終了する前に、３人の幹部社員が退職しています。
- ９月１５日：CIO David Webb氏、CSO Susan Mauldin女史
- ９月２６日：CEO Richard Smith氏
批判３：Equifaxの経営陣によるインサイダー取引
情報漏洩事実が社内で発覚した後、８月１日～２日に３人の上級幹部が株を売却したと知られ、インサイダー取引疑惑が挙げられました。*5*6
- Chief Financial Officer & Corporate VP：John Gamble (946,374ドルの株価)
- President of U.S. Information Solutions：Joseph Loughran（584,099ドルの株価）
- President of Workforce Solutions：Rodolfo Ploder（250,458ドルの株価）
また、ほかにもインサイダー取引をした社員はほかにもいたらしく、ソフトウェア製品開発マネージャーSudhakar Reddy Bonthuが有罪判決を受けたり、Equifax CIO Jun Yingも批難されているという記事が出ています。
まとめ
Equifax社の情報漏洩は、非常に学びの多いインシデントです。こうしたインシデントの組織内部の状態などは、大手企業を中心に他人事とは思寝ない部分もあるのではないでしょうか。
*1:https://piyolog.hatenadiary.jp/entry/20170311/1489253880
*2:https://www.nic.ad.jp/ja/materials/iw/2017/proceedings/d1/d1-3-kamiyama.pdf
*3:https://blog.hatena.ne.jp/security_consultant/scientia.hatenadiary.com/edit?entry=17680117126997303370
*4:https://www.ftc.gov/system/files/documents/cases/172_3203_equifax_proposed_order_7-22-19.pdf
*5:https://techcrunch.com/2017/09/07/equifax-managers-dumped-stock/
*6:https://www.bloomberg.com/news/articles/2017-09-07/three-equifax-executives-sold-stock-before-revealing-cyber-hack
『The Sliding Scale of Cyber Security』を再考する
『The Sliding Scale of Cyber Security』とは、Robert M. Leeにより提唱された概念で、サイバーセキュリティ態勢の成熟度を表すモデルです。このモデルによると、サイバーセキュリティの成熟度を脅威対応の観点からみて、５段階（Architecture・Passive Defense・Active Defense・Intelligence・Offense）に分類を行っています。
以前、「脅威の検知レイヤーモデル」という概念を考えましたが、基本的な考え方は同じだと思うので、その考え方も踏まえていきたいと思います。
その内容を具体的に見ていきましょう。
Architecture
Architectureとは、「セキュリティを念頭において、システムの計画・構築・維持を行うこと」と定義されています。例を挙げれば、適切にネットワークをセグメンテーション（分割）する、各サーバの設定にハードニングの考え方を導入する、などが挙げられます。筆者の考えでは、セキュリティのガイドラインに従って計画・実装を行うという議論に近いと思います。実際、このホワイトペーパーでは、参考になるモデルとして、NIST SP-800シリーズやPCI-DSSを参照すべきと書かれています。
Passive Defense
アメリカ統合参謀本部の資料『DOD Dictionary of Military and Associated Terms』（2019年02月版）では、Passive Defenseは以下のように定義されています。
passive defense - Measures taken to reduce the probability of and to minimize the effects of damage caused by hostile action without the intention of taking the initiative.
（筆者簡易訳）
受動的防御 - 主導権を取る意図はなく、敵対的行動によって引き起こされる被害の可能性を低減し、影響を最小限にするための対策
攻撃者は脅威の条件がそろえば、上記のArchitectureをすり抜けようと攻撃を仕掛けてきます。そのため、被害の発生確率を低減し、影響を最小限に押させる対策が必要となります。
サイバーセキュリティの文脈に置き換えれば、セキュリティ製品、例えばウイルス対策ソフト、ファイアウォール、IDSなどの伝統的なツールを導入して被害を防ぐことを意味します。この文脈から、本モデルの提案者は、「人間の継続的な関与なく、攻撃者に対して一貫性のある防御を提供するため、Architectureに追加されたシステム」と定義しています。言い換えれば、シグニチャベースの検知が基本となり、基本的には伝統的かつ汎用的な攻撃への対処を行うレベルです。その代わり、非常に早く対応できるレベルでもあります。
このホワイトペーパーでは、参考になるモデルとして、Defense-In-Depth（多層防御）、NIST SP-800シリーズ、NIST Cybersecurity Frameworkなどを挙げています。
Active Defense
Passive Defenseでは、多くの資金・リソース・能力を持つ高度な攻撃者には対抗できなくなります。そこででてきるのが、Active Defenseです。以前Active Defenseに関する定義に関する記事を書きましたが、ここでは、以下の定義を使っていきます。
アメリカ統合参謀本部の資料『DOD Dictionary of Military and Associated Terms』（2019年02月版）では、Passive Defenseは以下のように定義されています。
active defense — The employment of limited offensive action and counterattacks to deny a contested area or position to the enemy.
（筆者簡易訳）
能動的防御 - 限定的な攻撃的活動と反撃の一部を行い、攻撃者に略奪された地域・位置を否定すること
本ホワイトペーパーでは、「アナリストがネットワーク内部に潜む脅威を監視し、対応し、学び、自分の知識を応用するプロセス」と定義されています。そのため、検知をツール任せにするのではなく、ログを分析したり、ツールで検知された内容を分析していくレベルです。
ここからはホワイトペーパーからは異なりますが、このActive Defenseにはレベルが３種類あると考えています。ここでは、以前提唱した「脅威の検知レイヤーモデル」をもとに考えてみましょう。
- レイヤー１：振る舞い検知型
- レイヤー２：サイバー脅威インテリジェンス型
- レイヤー３：脅威ハンティング型
- レイヤー４：Offensive Countermeasure（上記に記載なし）
このモデルは、レイヤーが大きくなればなるほど高度な脅威に対応できる一方、時間やリソースが必要になります。
第一のレイヤーは、振る舞い検知型です。これは、アノマリー型検知ツールから出てきた結果をログなどを分析して検知する方法です。この方法は、半分ツールベース、半分人間ベースの方法です。
第二のレイヤーは、サイバー脅威インテリジェンス型です。これは、外部から取得した脅威インテリジェンス（IoC）をもとに分析する方法です。脅威インテリジェンスは、基本的にはツールのシグニチャにはなっていない最先端のIoCが共有されるものになりますので、ツールでは検知できない内容ばかりです。
第三のレイヤーは、脅威ハンティング型です。これは、サイバー脅威インテリジェンスの情報や自分の経験から、Aという攻撃手法が脅威インテリジェンスで共有されているのであれば、Bという攻撃手法があるのではないか？などを考えて新しい脅威を見つける方法です。より詳細な考え方については、こちらの記事をご覧ください。
第四のレイヤーは、Offensive Countermeasureと呼ばれる手法です。この手法は、日本では推奨されていませんが、考え方としては知っておく必要があります。
Intelligence
Active DefenseとIntelligenceの違いは分かりづらいと思います。
Active Defenseができたとしても場当たり的であったり、一過性の対応では意味がありません。Intelligenceとは、Active Defenseで作成された結果をもとに、脅威インテリジェンスを作成し、共有したり、次の脅威ハンティングに活用できるレベル、つまり再現性をもって取り組める状態を意味します。
このActive Defense、Intelligenceの状態をうまく表現したモデルとして、Active Cyber Defense CycleとF3EADモデルが挙げられます。
Active Cyber Defense Cycle
Active Cyber Defense Cycleは、４つのフェーズで構成されているモデルです。
Phase 1 : Threat Intelligence Consumption
このフェーズでは、組織の目的を正確に理解し、それに関連する脅威インテリジェンスを収集します。その後、Blue Teamがすぐに活用できるように、脅威インテリジェンスを取捨選別し、IoCのような形に情報を翻訳して挙げる必要があります。
Phase 2 : Network Security Monitoring（= Threat Hunting）
Phase 1の情報をもとに、脅威ハンティングを行うフェーズです。具体的には、収集、検知、分析の３フェーズによって構成されており、データを分析しながら攻撃の兆候を見つける脅威インテリジェンスを行うフェーズです。
Phase 3 : Incident Response
脅威インテリジェンスで見つけられた脅威について、封じ込め、脅威の排除などを行うインシデント対応プロセスです。
Phase 4 : Threat and Environment Manipulation
インシデント対応プロセスで収集できた脅威情報をもとに、改善を行うパートです。脅威情報をより深く知るため、フォレンジック、ログ分析、マルウェア解析などいろいろな手法で分析し、よりよいIoCを作成する、あるいは環境を変更してより安全なシステム構成を作成するプロセスです。
F3EAD
F3EADモデルは、以下の６つのフェーズが挙げられます。
- Find：調査フェーズ
- Fix：決定フェーズ
- Finish：完了フェーズ
- Exploit：活用フェーズ
- Analyze：分析フェーズ
- Disseminate：配布フェーズ
詳しい内容はこちらの本をご参照ください。
インテリジェンス駆動型インシデントレスポンス ―攻撃者を出し抜くサイバー脅威インテリジェンスの実践的活用法
- 作者: Scott J. Roberts,Rebekah Brown,石川朝久
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/12/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Offense
Offenseとは、Legal CountermeasureやHack-Backを行うという方法です。残念ながら基本的にはこれは推奨できず、基本的には法的に許可された国家レベルの対応になるので、ここまで考える必要はありません。
まとめ
この記事では、Sliding Scale of Cyber Securityについて解説をしました。こうしたフレームワークを知っておくことで、自分の組織がどこにあるのか、何を目指せばよいのか知ることができます。もちろん、ベンダーの態勢評価でも組織の状態は把握できますが、大局的な観点で理解しておくことも重要でしょう。
Anti-Intelligence技術について考えてみる
（変更履歴）ある目的で執筆していたのですが、諸般の事情で執筆を中断したので、ブログに投稿しました。
攻撃者（Adversary）や脅威を理解する上でインテリジェンス技術の幅は様々であり、OSINTやAttributionなどの技術的分析手法や、ダイアモンドモデルなどの情報整理技術などが挙げられます。
一方、インテリジェンス技術に対抗する技術（Anti-Intelligence手法）、言い換えれば「インテリジェンス調査により情報が露呈させないための技術」も少しづつ発達しています。インテリジェンス技術自体は、攻撃者・防御者それぞれの立場で使うことができますが、活用の具体的手法が異なります。本ポストでは、攻撃者・防御者それぞれの目線から、Anti-Intelligence技術について考えて行きたいと思います。
Anti-Intelligence技術とは？
Anti-Intelligence技術とは、インテリジェンス技術に対抗する技術、言い換えればインテリジェンス調査により情報が露呈させない技術の総称です。インテリジェンス技術は攻撃者や防御者の情報を可視化する強力な手法である一方、その技術を応用される立場とすれば、当然不要な情報は露呈しないように対抗したいと考えるようになります。軍関係では、このような情報をOpSec（Opeartional Security）とよんだりすることもあります。逆に、OpSecの失敗は、Cyber Threat Attributionを行う際の一つのきっかけにもなってしまいます。
Anti-Intelligence技術は、こうしたインテリジェンス調査に対抗する技術として開発された手法です。この手法、攻撃者、防御者それぞれが活用できる技術である一方、その立場により応用する具体的手法は異なります。本章では、それぞれの立場からAnti-Intelligenceについて検討してみたいと思います。
攻撃者目線でのAnti-Intelligence技術
攻撃者側（Adversary）から見れば、インテリジェンス調査で自分たちに関する情報が露呈することは決して好ましいことではありませんし、できる限りその姿を隠したいと考えるのが一般的です。Hactivistのような特定の主張を行う団体でも、その団体の存在意義については露呈したいと考える一方、実際の攻撃手法を隠したいと考えます（実際の攻撃手法が露呈し対抗されてしまえば、Hactivistとしてインパクトを与えられないからです）。そのため、攻撃者（Adversary）が自分たちの脅威やTTPを漏らさないために、自分たちの情報を隠したり、露呈しないようにする技術を開発し、応用するようになりました。
インテリジェンス工作技術の一つとして、外部からの情報収集を困難にさせるフレームワーク「D&D理論」（Denial & Deception - 拒否・欺瞞）がありますが、ここではこの枠組を応用してAnti-Attribution技術を整理したいと思います。
アプローチ１：Denial（拒否）
このアプローチの目的は「敵側の情報収集能力を知ることにより、それに対してカモフラージュ等によって情報へのアクセスや収集を制限すること」です。基本的には、攻撃者が持つ脅威要素・属性情報（Attribution）・TTPを露呈しないために、インテリジェンスによる情報収集・分析をしづらくして情報を秘匿するアプローチです。具体的考え方として以下が挙げられます。
Anti-Forensic
フォレンジック調査によりIOCを作成したり、攻撃手口・目的を特定されないようにするため、フォレンジック調査を妨害する技術をAnti-Forensicと呼びます。この技術を利用することで、攻撃の痕跡を残さない、あるいは調査を妨害し、混乱に落とし入れることが行われます。例えば、マルウェアを難読化して分析をしづらくする、sdeleteを利用して悪性ファイルを復元できないように削除する、ログを改竄して時系列分析ができないようにする、Metasploit Timestompを使ってタイムスタンプ情報を改竄する等の手法が考えられます。
Anti-Attribution
Anti-Attributionとは、攻撃者の属性や攻撃基盤や地理的拠点、あるいは攻撃手法（TTP）を特定されないようにする技術です。具体的には、「利用するマルウェア・攻撃ツールを毎回変更する」、「複数の地理的拠点や踏み台を経由して攻撃する」、「攻撃インフラを定期的に変更する」などの方法が考えられます。昔のスパイ映画では、電話を逆探知する際にあちこちの交換台を経由して発信元にたどり着くまでの時間を稼ぐシーンがよくあると思いますが、これも一つのAnti-Attribution技術です。そのほかにも、「本来の攻撃とは別に、DDoS攻撃など目立つ攻撃を仕掛ける」ことでで本来の攻撃に気付かせないようにする「Loud & Silent」というアプローチなどもここに分類されます。
Anti-OSINT
OSINTで本来の情報にたどれないようにする技術を、Anti-OSINTと呼びます。具体的には、「そもそもOSINTによる情報収集がされないように痕跡を消す」アプローチ以外にも、「まったく関係のないゴミ情報をたくさん発信する」ことにより本来たどり着いてほしくない情報にたどり着きにくくする方法などが存在します。
アプローチ２：Deception（欺瞞）
欺瞞（Deception）とは、「発信する情報の内容を操作することによって、情報収集側の分析者及びユーザの考えをコントロールする工作技術」を意味します。簡単に言えば、意図的に広められる虚偽・不正確な情報（False Flag） を残し、脅威インテリジェンスがその偽情報を追跡する、あるいは別の攻撃者が攻撃したように誘導することでAttributionを避ける攻撃的なアプローチで、Disinformation（偽情報）工作とも呼ばれます。その意味では、攻殻機動隊でよく出てくるセリフのように、「あるいは、我々にそう思わせたい第三者の意図が介在している」を実践でいく技術だといえます。
Disinformation技術については、以下の情報を参照してください。
防御者目線でのAnti-Intelligence技術
次に、防御者の観点からAnti-Intelligence技術を検討してみたいと思います。
攻撃者側もこうしたインテリジェンス技術の一部を活用して、攻撃対象に対して入念な調査を行っていることが一般的になっています（攻撃モデルのCyber Kill Chainにおいて、最初の第一段階が偵察（Reconnaissance）といわれ、必ず様々な調査を使って調査を着てきます）。そのため、防御者（Defenders）の立場からすれば、攻撃者のこうした「偵察フェーズへの対抗技術」としてAnti-Intelligence技術を応用したいと考えることが重要です。ちなみに、伝統的なインテリジェンスでは、こうした「攻撃側のインテリジェンスへの対抗技術」のことをCounter-Intelligenceとよんでいます。実際に、CIAの公開資料では、以下のように定義されています。
More specifically, it is the job of US counterintelligence to identify, assess, neutralize and exploit the intelligence activities of foreign powers, terrorist groups, and other entities that seek to harm us.
（筆者簡易訳）
特に、米国の対抗諜報の役割は、外国勢力、テロリスト集団、その他我々に危害を与えようとする集団の諜報活動を特定・評価し、無効化し、利用することである。
そのため、Cyber Intelligenceの文献でも、最近ではCyber Counter-Intelligenceという概念が登場していますが、主に攻撃者の「偵察フェーズに対抗する具体的手法」として理解することがわかりやすいかと考えられます。こちらの具体的手法についても、「D&D理論」の枠組で整理していきましょう。
アプローチ１：Denial（拒否）
このアプローチの目的は、すでに述べた通り「カモフラージュ等によって情報へのアクセスや収集を制限すること」にあります。そのため、基本的には攻撃者から見て情報が取れないような状態を作り上げることが重要だといえます。
Cyber Hygine
第一に、Cyber Hygine（サイバー衛生）と呼ばれるような攻撃者に付け入る隙を与えない、パッチ管理などのセキュリティの基本動作を徹底することが重要だといえます。
Red Team Operation
また、Tripwire社はブログポストにおいてこのアプローチの重要な要として、セキュリティ診断とレッドチーム診断を挙げています。既に説明した通り、レッドチームは攻撃者のTTPに熟知しているため、この目線でシステムやネットワークのセキュリティレベルをチェックすることでアクセスや収集を制限することが可能となります。
Anti-OSINT
Anti-OSINTと呼ばれる、OSINTで本来の情報にたどれないようにする技術も有効です。具体的なアプローチとして、第三者のコンサルティング会社等に依頼してOSINT調査をいてもらい露呈した情報を洗い出し、削除するというのが一般的アプローチです。
アプローチ２：Deception（欺瞞）
前述でも記載した通り、このアプローチでは「発信する情報の内容を操作することによって、情報収集側の分析者及びユーザの考えをコントロールする」ことを目的としています。
この技術は、Cyber Deceptionと呼ばれ、SNS、ネットワーク、アプリケーション、データベース上などにDecoy（おとり）を仕掛けることにより、攻撃者のリソースを無駄遣いさせたり、Decoyに攻撃を行わせることにより時間を稼いだり、あるいは本来絶対にアクセスが発生しない端末・パラメータへのアクセスが発生したことにより攻撃を検知するなど、様々なベネフィットが存在します。
より詳しくは、以下の記事をご覧ください。
まとめ
今回は、脅威インテリジェンス収集に対抗する技術として、攻撃側・防御側それぞれの目線でのどのような活用がされるか記載しました。基本的に、ANti-Intelligence技術は防御・攻撃にもどちらにも利用される技術であるため、攻撃側サービス（Red Team Operation）を行う担当者も防御側を担当する人も知っておくべき技術となります。特に、企業のセキュリティ担当者は自社を攻撃されるリスクを低減するため、Anti-OSINT技術などから初めてみるのがよいのではないでしょうか？
Threat Huntingとは何か？（2019年度版）
（変更履歴）過去のThreat Huntingに関する記事をいろいろ改善しながら執筆していたのですが、諸般の事情で執筆を中断したので、ブログに投稿しました。
Threat Huntingとは、セキュリティベンダーがシグニチャを提供するまでのゼロデイ期間において攻撃が行われていないか、プロアクティブに調査する一連のプロセスのことです。
Threat Huntingの定義
そもそも、Threat Huntingとは何でしょうか？ここでは、複数のホワイトペーパーからその定義を確認してみましょう。
Sqrrl社の定義
Sqrrl社は、Threat Huntingの分析技術の中でもUEBA（User Entity Behavior Analytics）という技術サービスを専門する企業として知られており、Threat Huntingに関するホワイトペーパーを積極的に発表していることでも有名な企業でした。
ちなみに、Sqrrl社がだしたホワイトペーパー３部作は今もサイトで公開されており、一読の価値はあるのでダウンロードしておいた方が良いかもしれません。
2018年1月には、Amazonのクラウド部門に買収され、AWS（Amazon Web Services）に取り込まれる用です。このことから、ますますAWSのセキュリティ機能も強化されるでしょう。
Sqrrl社のホワイトペーパー``A Framework for Cyber Threat Hunting''によれば、以下のように定義されています。
We define hunting as the process of proactively and iteratively searching through networks to detect and isolate advanced threats that evade existing security solutions.
（筆者簡易訳）\
既存のセキュリティ対策を回避する高度な脅威を検知・隔離するために、能動的かつ再帰的にネットワーク内を探索するプロセス
SANSの定義
他のセキュリティ組織の定義についても確認してみましょう。SANSは、有名な米国のセキュリティ研究教育期間であり、Threat Huntingについてもホワイトペーパーを出しています。ここでは、ホワイトペーパー``The Who, What, Where, When, Why and How of Effective Threat Hunting''の定義を確認してみましょう。
Threat hunters focus their search on adversaries who have those three characteristics and who are already within the networks and systems of the threat hunters’ organization, where they have authority to collect data and deploy countermeasures.
（筆者簡易訳）
Threat Hunterとは、データを収集し、対策を展開できる権限を持つ環境において、脅威の三つの特徴（敵対的意図・能力・機会）を持ち、既に自組織のシステム・ネットワークに侵入している攻撃者の検索に焦点を当てる。
Carbon Black社
Carbon Black社は、EDR（Endpoint Detection \& Response）製品で有名な企業です。端末（Endpoint）は、Threat Huntingでも重要な情報ソースとなり、以下のように定義しています。（参考文献：What is Threat Hunting? | Carbon Black）
Threat hunting is, quite simply, the pursuit of abnormal activity on servers and endpoints that may be signs of compromise, intrusion, or exfiltration of data.
（筆者簡易訳）
Threat Huntingとは、サーバとエンドポイントにおいて、不正アクセス、侵入、データ漏洩等の兆候を示す不審な挙動の追跡を意味する。
補足事項
このブログでは、「既存のセキュリティ対策を回避する高度な脅威を検知・隔離するために、能動的かつ再帰的にネットワーク内を探索するプロセス」というSqrrl社の定義をもとに議論を進めていきますが、Threat Huntingで重要について少し追加しましょう。
第一に、Threat Huntingは能動的なプロセスであり、既存のセキュリティ機器から通知されるアラートを待つのでは無く、Security Analystが攻撃者に侵入された痕跡がないかを能動的に探索する試みだということです。
第二に、上記の性質からSecurity Analystが主体的に行うプロセスだという点です。当然、各種セキュリティ機器からの通知や機械学習などによるツールによる支援を活用はしますが、あくまでも人による分析がメインという点が重要となります。
なぜThreat Huntingが重要か？
Threat Huntingが重要な理由は、昨今の攻撃手法は高度化してきており、既存の製品を導入していたとしても、攻撃を完全に防ぐことは困難な状況となっています。そのため、セキュリティ機器から通知されるアラートを待っているだけでは、攻撃者に既に社内に侵入されているにも関わらずその事実にすら気付かないという事態が発生してしまいます。
実際に少し前の記事ですが、FireEye 社の年次セキュリティレポート「M-Trends 2017」によると調査対象の組織がセキュリティ侵害を検知するまでグローバルで99 日、アジア太平洋地域に限定すると172 日間もの日数( 中央値) を要しています。これだけの長期間にわたり侵害に気付いていない状況であり、また、半数の組織は外部からの指摘で侵害が発覚したとされています。
Threat Hunting は、積極的に自社組織で侵害を検知することで、侵害から検知までの期間をできる限り短縮するために行われます。このような背景から、昨今、各セキュリティベンダがThreat Hunting という用語を使い出しているのです。
このブログでは、以前脅威に気付く検知レイヤーモデルとして紹介していますが、こうした活動を検知するためにはThreat Huntingは重要になると思います。
www.scientia-security.org
プロセス・モデル
Threat Huntingを行うプロセスについては、プロセス・モデルという形で概念化されています。ここでは、Sqrrl社の代表的なモデル``The Hunting Loop''を紹介します。このほかにも、Carbon Black社が提唱する『The Carbon Black Hunt Chain』モデルやCyberReason社『8 Steps To Start Threat Hunting』モデルなどがありますので、興味がある方は原文に当たってみてください。
Sqrrl社によれば、Hunting Looとは、以下の通り４種類のフェーズにより構成されています。（図は、Sqrrl社のレポートから引用）
Step１. 仮説構築フェーズ（Hypothesis Generation）
Threat Huntingを行う上で一番最初にやるべき重要なフェーズとして、仮説の構築（Hypothesis Generation）が挙げられます。いきなり、「脅威を探し出す」といっても何を調べていいかわからないため、どんな脅威があるか仮説（Hypothesis）を構築し、その仮説を検証する形で脅威を探し出す流れとなります。仮説を構築することでTrailhead（調査の起点）を設定することができるようになります。
Threat Huntingの仮説を構築する際には、大きく２要素が重要となります。
- 観察（Observation）に基づくこと
- 検証可能（Testable）であり、検証に必要なデータにアクセスできること
まず第一要素である「観察」とは様々なことが含まれます。過去の経験や知識、あるいは脅威インテリジェンスで得られた知見や共有された情報、「なにか不審に見える挙動」など様々なものが該当し、これらに基づいて仮説を構築します。
また、第二要素で述べられている通り、これらは自分の環境において適切なログが取られており、検証可能でなければなりません。
SANSのホワイトペーパーによれば、仮説の構築方法は大きく３種類あると指摘しています。
Intelligence-Driven Hypotheses
Intelligence-Driven Hypothesesとは、サイバー脅威インテリジェンスチームの情報、すなわちマルウェア分析や脆弱性スキャンの結果、既知のIOCやTTP（Tactics, Technique, Procedure）などを元に仮説を構築する手法です。
インテリジェンスを活用した場合、以下のような仮説が一般的には構築されるはずです。
- 某攻撃キャンペーンは、X国のインフラストラクチャよりフィッシングメールを送付している。そのため、もし自分の組織が攻撃されているのであれば、メールのログを分析し、送信元IPアドレスとしてX国のログがあるか分析してみる必要がある。
- ある攻撃グループが利用するマルウェアは、1AM ~ 3AMの時間帯にY国所属のIPアドレスに対して」HTTPで疎通確認を行う傾向が存在する。そのため、もし自分の組織が攻撃されているのであれば、当該時間帯にY国のIPアドレスに対してHTTP通信が発生しているか、プロキシのログを分析する必要がある。
Intelligence-Driven Hypothesesでは、注意すべきことが２点あります。
第一に、「Pyramids of Painの下位にあるIOCsへの過剰な依存を避け、上位概念であるTTPsに焦点を当てる」という点です。マルウェアのハッシュ値やC2通信のIPアドレスなどのIOCsは膨大に存在し、その質も情報源や状況によりバラバラであるため、全部を検証するとほとんど合致せず、膨大な負荷に追われることになります。そのため、IOCsはあくまで素早く成果を出すために活用し、Pyramid of Painの一番上記概念であるTTPsに焦点を当てて分析を行うことに焦点を当てる必要があります。
第二に、このプロセスは動的なプロセスであるという点です。言い換えれば、調査過程で新しい仮説が出てきたり、複数の仮説が構築できる場合もあるという点です。一方、Threat Huntingやツールでは検知できない脅威を見つけるプロセスであるため、いくらでも時間は費やすことができます。そのため、時間に制約がある前提のもと、新しい仮説や複数の仮説が出てきた倍には、もともとの仮説をきちんと完了させることに焦点を当てる一方、新しい仮説はきちんと記録しておき将来のThreat Huntingのために活用することが重要となります。
Situational-Awareness
Situational-Awarenessとは、環境のベースラインをよく把握している環境において、その環境において発生した変化に気付き、仮説を構築する方法です。
ここで重要なことは、「当該環境のベースラインをよく知っていること」です。このとき、攻撃者は価値のある資産、もしくは一番リスクが高い場所から狙いを定めてくることが前提となることから、Crown Jewel analysisやリスク・アセスメントなどを事前にしておくことで集めるべき情報が明確になり、仮説が立てやすくなります。
大きなネットワークではマニュアルで対応することには限界があるため、自動化・リスクアルゴリズムなどAnalytics-Driven Approachを併用するように述べています。具体的には、UEBA・EDR・SIEMなどの各種分析ツール、もしくは機械学習など各種アルゴリズム分析によって抽出された結果をもとに分析を進めていく必要があります。
Domain Expertise
Domain Expertiseとは、過去の経験に基づく仮説です。具体的には、各アナリストは異なる経験を持っているために、文書化による情報共有をして、全員が同じ過去の事例を知っていることが重要だと指摘しています。また、過去の経験に基づく仮説は認知的バイアスにかかっている可能性があるため、その点についても注意する必要があります。
Step 2. 調査フェーズ（Tools and Technique Enabled Investigation）
調査フェーズとは、仮説を検証するためのツール・テクニックを利用して調査を行うフェーズです。テクニック自体は既存のインシデント・レスポンス技術、IOCを使った調査など様々あります。
Step 3. 発見フェーズ（Patterns & TTP Discovery）
発見フェーズとは、攻撃者の行動と攻撃的なTTPsについて発見するフェーズです。このフェーズが終わる時には、Huntingに必要な特徴を把握したことになります。
Step 4. 共有フェーズ（Automated Analytics）
共有フェーズとは、発見したTTP・パターンをIOCとして定義し、各種分析ツール・チームに共有するフェーズです。重要なことは、なるべく手動で同じ調査をすることを減らし、自動化することが重要となります。そのため、IOC化して以降自動検知できるようにする必要があります。
まとめ
脅威ハンティングは、攻撃者の痕跡を能動的に見つけようという試みですが、常に新しい手法で攻撃者を見つけようとする探偵のような研究のような試みで知的好奇心をくすぐられますので、成熟した組織の方々はぜひご検討ください。（前に米国滞在中にまねごとみたいなことをやりましたが、非常に面白いです。ただ誤検知が多かったですが）
