セキュリティコンサルタントの日誌から

セキュリティに関するエッセイなど

Intelligence-Driven Threat Intelligenceの解説

先日、Internet Week 2019にてActive Defenseに関する講演を行ってきました。その中の一つとして、Threat Huntingについて紹介を行いました。

www.slideshare.net

今回は、Threat Huntingについて講演の内容から外した部分も含めてまとめたいと思います(一年前ぐらいに同じような記事を書いているため、一部重複します)。

www.scientia-security.org

Threat Huntingの定義(復習)

Amazonのクラウド部門に買収された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. 

(筆者簡易訳)

既存のセキュリティ対策を回避する高度な脅威を検知・隔離するために、能動的かつ再帰的にネットワーク内を探索するプロセス

プロセスモデル(復習)

プロセスモデルも様々存在します。但し、「どのようにThreat Huntingをやるか?」という点に尽きる為、好きなモデルを使えばよいと考えています。

Intelligence Driven Threat Hunting

最近色々研究した中は、SANS CTI Summit 2018でKeith Gilbert氏が発表したモデル(Intelligence-Driven Threat Intelligence)が一番実効性が高いのではないかと考えています。理由としては、Threat Intelligenceの活用を意識していることが挙げられます。

f:id:security_consultant:20191214135123p:plain

以下にそのプロセスを説明していきます。また、以下に彼の講演ビデオを示します。

www.youtube.com

Step 1 : Intelligence Inputs(脅威インテリジェンスの入手)

第一のステップでは、脅威インテリジェンスを入手し、脅威ハンティングのネタ・手がかりを入手します。ここでは、「良い脅威インテリジェンス」を入手することが重要となり、そのためには、4要素(4A)を満たすことだといえます。*1

  • Acuracy(正確性)
  • Audience Focusd(消費者目線)
  • Actionable(アクショナブル)
  • Adequate Timing(適切なタイミング)

また、入手先として、以下の3種類が挙げられます。

  • 外部ソース(Open):ベンダーレポート・ブログ・無償の脅威インテリジェンス情報
  • 外部ソース(Closed):有償の脅威インテリジェンスサービス・情報コミュニティ
  • 内部ソース:アラート・ベースラインからの差異・ユーザからの通報

Step 2 : Decompose Action(アクションの分解)

第2ステップは、脅威インテリジェンスを読み解き、検証可能な単位に分割するフェーズです。これを正確に理解するためには、IOCの文脈、どんな攻撃手法やツールが利用されているか、攻撃者による可変性(変更しやすいIOCなのか?)について分析を行う必要があります。

Step 3 : Create Hypothesis(仮説構築)

第3ステップは、仮説構築フェーズです。Threat Huntingは「既存のセキュリティ対策を回避する」未知の攻撃を洗い出すことです。そのため、(野生の勘が鋭い人を除き)闇雲に探しても時間を浪費してしまいます。そのため、科学的アプローチ(検証可能な仮説→検証)を行う必要があります。

仮説構築は、大きく2種類の方法があります。

アプローチ1:初級者向け(IOCをそのまま適用)

最近のベンダーレポートは、IOCが一覧として載っているケースも少なくありません。そのため、はじめてThreat Huntingをやられる方々には、当該IOCを利用して仮説構築を行うことを推奨しています。

但し、こうしたIOCは既に公開されている時点で過去の攻撃であり、多くの製品にはシグニチャとして反映されていることが想定されます。そのため、セキュリティ製品が十分でない場合を除き、ほとんどの場合引っかかることはないとは言えます(とはいえ、Threat Huntingのイメージを持つうえでは非常に有効です)

また、クローズドな情報(例:ISACからAmberなどで共有される情報)にアクセスできる場合、その情報はまだセキュリティ製品に反映されている可能性は低いのでそのままIOCを活用することは意味があるといえるでしょう。

アプローチ2:中級者向け(IOCを活用する)

中級者の場合、IOCをそのまま活用するのではなく、一歩踏み込み、攻撃手法(TTPs・IoA)に注目する方法が一般的です。本プロセスを提唱したKeith Gilbert氏によれば、IOCの一般化(Generalization of IOC)という手法を取り上げています。これは、IOCを一段高い目線に引き上げるという考え方です。

f:id:security_consultant:20191214142750p:plain

例えば、攻撃者がマルウェアの持続性メカニズムとして、サービスを悪用したとします。その時、当該サービス名がIOCと共有されるはずです。但し、サービス名はいくらでも変更できますので、直接探してもヒットする可能性は低いでしょう。そのため、この点について一般化を行い、サービス名の作成・変更を検知するというIOCを作成すれば、名前に依存せず検索で引っ掛けることができます。

IOCの議論において、Pyramid of Pain(痛みのピラミッド)と呼ばれる概念がありますが、まさに名前などのレイヤーが低い部分からTTPsという高い目線に切り替えることを推奨しているのが、この「IOCの一般化」という概念です。

f:id:security_consultant:20170113154400p:plain

 

また、仮説構築のベースとなるのは、入手した脅威インテリジェンスですが、それ以外にも加味する要素が2つあります。

第一に、「自社環境が置かれている状況」(IT環境・業種・ビジネス動向)です。脅威インテリジェンスには、IOCのような戦術的インテリジェンス(Tactical Intelligence)もありますが、そのIOCの原点となるThreat Actorは特定の技術を活用したり、特定の業種を狙いうちにするIntent(敵対的な意図)があるはずです。通常、それがマッチしていないと、狙われる可能性は低いといえるはずです。そのため、自社が置かれている環境などを正確に把握することは意味があるといえるでしょう。

第二に、「過去の経験」です。TTPsは色々なバラエティに変化しますが、検知の観点から攻撃に気付けるポイントという点については過去の知見に頼ることができます。また、自社の環境に詳しいアナリストであれば、攻撃されやすいポイントやCrown Jewelに基づいたHuntingができるはずです。以下に、IOCの優先度を高める観点から、検知によく使われるIOCのランキング(*2*3)を示します。

f:id:security_consultant:20191214154145p:plain

Step 4 : Hunt!!

第4ステップは、(仮説の)検証フェーズです。このステップを行う前提として、十分な可視化(Full-Spectrum Visibility)が確保されている必要があります。逆に言えば、行くら具体的で検証しやすい仮説を構築できたとしても、検証を行うすべがなければ、意味がありません。

もちろん、EDRやSIEMなど、可視化するツールが十分に整っている組織はそれらを使えばよいですし、別の方法としてフリーツールを活用する方法もあります。

以下に、Threat Hunting界隈で名前がよく上がるツールを示します*4

f:id:security_consultant:20191214165519p:plain

 

Step 4.5 : After Hunting

仮説検証が終わると、以下の二つの状態になるはずです。

ハンティング成功の場合

あまりないはずですが、「仮説が正しく、攻撃の痕跡を確認できた場合」です。つまり、これは攻撃が既に行われた、あるいは現在進行形でやられていることを意味します。すると、ハンティングプロセスを終了し、Incident Responseモードへ移行します。

また、ここでハンティングに成功した場合、ナレッジをISACなどの各種コミュニティに還元できると非常にベターです。

ハンティング失敗の場合

攻撃の痕跡が確認できない場合」です。原則的にはStep 1 ~ 3へ戻ります。

但し、ここでは「攻撃が行われていない」と短絡的な結論に飛びつかず、なぜ痕跡見つからないか、(いちいち原因究明しないまでも)その理由は意識しておくことが大事です。現在のような高度な攻撃が行われる場合、「攻撃が行われていない」と証明することは「悪魔の証明」で、検証することは難しいといえるでしょう。そのため、こうしたハンディングでも、「○○と××の痕跡がないから、APT XXの攻撃は受けていない」と、一定の蓋然性・合理性をもって判断ができるようにしなければいけないと考えます。

さて、元の議論に戻ると、「攻撃の痕跡が確認できない場合」の理由は複数挙げられます。この理由を考えながら、進めることにより、どのステップに戻るべきなのか、次のHuntingへ入る前に何を気を付けなければいけないか気付くことができます。

  • 「(攻撃の痕跡の)探し方が悪い」
  • 「仮説が正しくない」
  • 「選択した脅威インテリジェンスが適切ではない」

Step 5 & 6 : Enrich Actions & Form Activity Group

さて、Step 5 & 6とは、Diamond Modelを軸にした高度な分析手法を前提としており、Internet Week 2019では説明を省きました。また、通常の組織はStep 4.5までできれば十分だと思います。

ここでは、少し詳細に踏み込みたいと思います。

まず、Step 5 : Enrich Actions とは、今回活用できた仮説(IOC)を既存の情報と結び付け、脅威インテリジェンスの充実化を図ることを意味します。脅威インテリジェンスやフォレンジックの活動において、ピボット(Pivoting)という概念があります。『インテリジェンス駆動型インシデントレスポンス』によれば、「情報の1つを使って、既知、あるいは未知の情報群の特定につなげる技術」と定義されていますが、見つけた新しいIOCから、次のIOCを芋づる式に引き出していくイメージとなります。

例えば、先ほどの「IOCの一般化」で説明した通り、「サービスの作成・変更」という軸で調査を行うと、直近怪しいサービスが作成されていたとしましょう。その場合、サービスの作成時刻、作成したプロセスを新たなキーワードとすることでさらに新しいIOCを見つけ出すことができます。

次に、Step 6 : Form Activity Group です。まず、Activity Groupとは、以下のように定義されます。

common/similar malicious events, adversary processes, and threads

(筆者簡易訳)

共通/類似の悪意のあるイベント、攻撃プロセス、スレッド

 APT XXに狙われる企業で、かつ高度なセキュリティが施されている場合、複数回の侵入(インシデント)が発生しています。その場合、それらの複数のインシデントを横にならべ、共通となる手口・手法をならべ、APT XXの特徴をあぶり出すAttribution技術です。実際にこれを詳しくやるためには、Diamond Modelと呼ばれる手法を使いますが、(一般的な企業で)ここまで実際にやることはほとんどないため、その手法は別途解説したい思います。

 

The Diamond Model For Intrusion Analysis: A Primer (SANS CTI Summit 2014)

補足:専門ベンダーにやってもらうのはいいのでは?

こういう話をユーザ系企業にすると、専門業者(MSSP・MDR-SP)が提供するサービスを使うべき、任せるべきではないか?いう議論になります。確かに、全部とは言えませんが一部セキュリティ監視サービスを提供する企業は、サービスの一環としてこうしたThreat Huntingを実施してくれるでしょう。

それでも筆者は、(体力に余裕がある組織は)自社でもできれば実施したほうが良いと考えています。具体的には、MSSPを使いながら自社でも行う、ハイブリッドモデルを推奨しています。

第一の理由として、「脅威インテリジェンスが共有できないケースも多い」です。特に、ISACなどでは、TLP(Traffic Light Protocol)という情報共有の可能な範囲を定義しており、情報によっては自社内に閉じて検証を行わないといけないこともあるといえます。

また第二の理由として、「自社のおかれている環境」を踏まえ、コンテキストを踏まえて脅威ハンティングできる組織は自社だけだと思います。これは、自社のIT環境だけでなく、ビジネス環境なども踏まえた話になります。また、脅威ハンティングの一つの手法として、アノマリー(異常)に注目する方法がありますが、「何が異常であるか?」、「どこに弱点があるか?」は組織によって異なります。

以上のことから、自社でもやることが望ましいといえるでしょう。但し、私も実施した経験がありますが、こうしたThreat Huntingは終わりがないため、時間があれば限りなく実施することもできてしまいますので1時間なり時間を決めてやるのが望ましいと思います。

参考文献

Threat Huntingを勉強される方のため、いくつか勉強用コンテンツを紹介します。

ThreatHunting Project

このサイトは、Threat Huntingに関する情報が多数集まっているサイトです。特に、Threat Huntingの基礎作成に貢献したSqrrl社のコンテンツもアーカイブされています。私が個人的に3部作と呼んでいるコンテンツも公開されています。

  • 『Huntpedia』
  • 『A Framework for Cyber Threat Hunting』
  • 『Hunt Evil: Your Practical Guide to Threat Hunting』

SANS Institute: Summit Archives

SANSが『Threat Hunting & Incident Response Summit』や『SANS Cyber Threat Summit』と呼ばれるサミットを開いており、その中で関連するコンテンツを見るのも手です。一定の品質が担保されていると感じています。最近では、日本語でその様子をレポートしてくれているケースもあるようです。

jpn.nec.com

同様の手法として、SANSのReading Roomを利用して、関連するホワイトペーパーを読んだり、Irongeek.comなどで関連するカンファレンスの公演を聞くのも一つの手だと思います。

 

また、各種セキュリティベンダーのブログも非常に参考になるでしょう。

まとめ

この記事では、Intelligenceを軸としたThreat Huntingについて説明を行いました。こうした手法は、現在のようにツールでは検知が難しい高度な攻撃者には有効な攻撃手法です。脅威インテリジェンスを活用しようとしている組織の参考になれば幸いです。

*1:翻訳した『インテリジェンス駆動型インシデントレスポンス』によれば、3要件(Accuracy・Audience Focusd・Actionable)が定義されています。一方、Threat Intelligenceの別の書籍である『Effective Threat Intelligence: Building and Running an Intel Team for Your Organization』によれば、次の3要件(Actionable・Certainty・Timing)が説明されています。記載されていない1要素を加えることで、4要素として説明したいと考えています。

*2:https://www.youtube.com/watch?v=9Ndv0W2Uq0U

*3:https://www.darkreading.com/attacks-breaches/top-15-indicators-of-compromise/d/d-id/1140647

*4:一つ一つリンクを張るのが大変だったので、講演資料を張り付けています。気になるものが検索してみて下さい。名前が書かれていない眼のログのツールは、The Zeek Network Security Monitorというツールで以前はBroとして知られていたツールです。また最近では、RedHuntLabsという会社もいくつかという会社もいくつか面白いツールを出していそうです。

Internet Week 2019で講演してきました!!

先日開催された、Intenet Week 2019の「D2-3 組織を更に強くする「攻めの」サイバー攻撃対策」のセッションで機会をいただき、講演をしてきました。

 スライドは以下で公開しましたので、よろしければご参照ください。

www.slideshare.net

 

レポートで振り返る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翻訳を下訳として、その後人間による翻訳
  • 注釈については翻訳を省略
  • 見直しなし(そのため、翻訳の単語がずれている可能性があります)

scientia-security.github.io

非常に包括的であり、また企業ドラマのようなレポートですので、ぜひ翻訳をお読みいただきたいと思います。

また、以下は、読んでおくべきレポートだと思います。

一つは、米国政府監査院(GAO)レポートです。

www.gao.gov

もう一つは、上位議員Elizabeth Warren女史のレポートです。

www.warren.senate.gov

いかに、これを踏まえたサマリを作成します。(参照URLがないものは基本的に上記レポートを参照して記載しています)

基礎情報

Equifax社とは?

  • 米国内で三大消費者信用情報サービスの一つ(残り2社:Experian社とTransUnion社)
  • 全世界24か国でビジネスを展開しており、10億人(厳密には、8億2000万人)近い消費者個人の信用情報と1億人(厳密には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ペイメントゲートウェイ社が構築した2つのサイト(都税クレジットカードお支払いサイト、住宅金融支援機構)では、クレジットカード情報を一部含む70万件の情報漏洩という大きなインシデントになった*1
  • 一方、NTTコミュニケーションは、OCN IDサーバでApache Struts 2を利用していることが判明し、3/7の脆弱性公開後、3/8の朝サイト停止を行う判断したことで知られている。*2

より詳しいまとめは、piyologを参照してください。

piyolog.hatenadiary.jp

漏洩した情報

1億4550万件の米国消費者情報が漏洩し、大規模漏洩の一つとして知られています。

米国証券取引委員会の発表により、以下の情報が漏洩したとして知られています(以下に、翻訳版を載せています)。約1.5億の社会保障番号が漏洩していることから、国民の約半数の情報が漏洩したと考えられます。

f:id:security_consultant:20190322181531p:plain

調査は主に米国主導で行われていますが、グローバル企業であるため米国消費者以外の情報も漏洩しています。例えば、BBCによると、役69万件の情報が漏洩したと報道されています。

www.bbc.com

事故対策費用

事故対応費用については、現在も動いているため確定的なことが言えませんが、財務報告書から以下のことが読み取れます。

investor.equifax.com

  • 2018年12月末までの2年間の総費用は、5億6520万ドル($565.2M)になる。
  • サイバー保険は、1億2500万ドル($125M)を払う契約になっており、2年間にわたり全額支払われている。カバー率は22.1%であり、これは既存のターゲット社やホーム・デポ社のカバー率と比較すると低い。(詳細はコチラ
  • 実質的負担額は、4億4020万ドル($440.2M)である。

 

2017年の支出

2017年の四半期報告書をまとめると、以下の通りです。

f:id:security_consultant:20190322215715p:plain
2018年の支出

2018年の四半期報告書をまとめると、以下の通りです。

f:id:security_consultant:20190322220059p:plain

  • 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:9月7日への情報公開に向けた顧客対応

情報公開の準備のため、以下の作業を行っている。

  • 専用サイトの作成(情報漏洩有無+各種サービスへの登録)
  • 500名規模のスタッフを配置した緊急コールセンターの立ち上げ
  • インシデントを受けた事後対応サービスへの案内(1年間無償)
    • クレジットカード利用監視サービス(Credit Monitoring)
    • アイデンティティ盗難監視サービス(Identity Theft Service)

根本原因・推奨策

米国下院監査政府改革委員会による推奨策

セキュリティ上の今回の問題点として、本レポートでは6種類挙げています。

  • セキュリティ上の懸念1:SunアプリケーションサーバとEquifaxネットワークの他の部分との間にセグメンテーションはありません。インターネットからアプリケーションサーバを遠隔操作できた攻撃者は、グローバルに、Equifaxネットワーク内の他のデバイス、データベース、サーバへ移動することができます。(さらにいえば、データベース内も分離されていなかったと考えられます)

  • セキュリティ上の懸念2:ファイル整合性監視(FIM:File Integrity Monitoring)は、環境内における許可されていない変更を警告・検出できますが、アプリケーション、Webサーバのどちらにも設定されていませんでした。

  • セキュリティ上の懸念3:Sunシステムは、環境全体で共有ファイルシステムを使用しているため、あるシステムから別のシステムへどの管理ファイルにもアクセスできます。これにより、あるシステムにあるメモや設定ファイルに、他のシステムからアクセスできるようになります。

  • セキュリティ上の懸念4: Webサーバログは14日間、オンラインで30日間しか保持されないため、悪意のあるアクティビティを再現することは困難で、ほぼ不可能です。

  • セキュリティ上の懸念5:アプリケーション内で使用されているリソースの完全なソフトウェア棚卸が管理されていません。これは、個々のオープンソースコンポーネントが十分に理解されず、文書化されていないため、個々のコンポーネントの脆弱性を迅速に特定することよりも、潜在的な脆弱性を特定するための完全なコードレビューが必要です。

  • セキュリティ上の懸念6:一般的な観察として、レガシーなSun / Solarisシステムへの一貫したタイムリーなパッチ適用が懸念事項です。

その他、レポートから読み取れる課題を以下に列挙します。

Mandiant社による推奨策

セキュリティ上の今回の問題点として、Mandiant社は11種類の推奨策を上げています。

  1. 脆弱性スキャンおよびパッチ管理のプロセス・手順を強化する。
  2. バックエンドデータベースに保持されている機密データの範囲を縮小する。
  3. 重要なデータベース内に格納されているデータにアクセスするための制限と管理を強化する。
  4. インターネット公開システムからバックエンドデータベースおよびデータ保存先へのアクセスを制限するため、ネットワークセグメンテーションを強化する。
  5. 追加のWAF(Web Application Firewall)を展開し、シグネチャを有効にして攻撃をブロックする。
  6. アプリケーション、Webサーバへのファイル整合性監視技術の展開を急ぐ。
  7. ネットワーク、アプリケーション、データベース、システムレベルにおいて、追加のログ取得を行う。
  8. 特権アカウント管理(PAM:Privileged Account Management)製品の展開を急ぐ。
  9. 追加のインラインネットワークトラフィック復号装置を導入し、暗号通信への「みえる化」を行う。
  10. 追加のEDR(Endpoint Detection and Response)テクノロジーを導入する。
  11. 追加の電子メール保護・監視技術を導入する。

米国政府監査院によるレポート

米国政府監査院によるレポートによれば、5種類の弱点を指摘しています。

  • ソフトウェアの更新
  • ソフトウェア構成
  • アクセス制御
  • ネットワーク監視
  • 境界防御

補足的な課題

上記に上がらない付随的な課題を以下に示します。

課題1:メーリングリストの管理
  • US-CERT経由で本脆弱性に関する通知を受け取っており、GTVMチーム(Global Threat and Vulnerability Managementチーム)のメーリングリスト経由で430名に対してこの内容を共有している。また、3/16時点でも、GTVMチーム資料にてパッチ適用をリマインドしている。
  • GAOレポートによれば、このメール受信者リストは更新されておらず、適切な担当者に対してメールが届いていなかったと指摘されている。
  • 10月2日に、ACIS環境の担当であったGraeme Payne氏は、3月9日のApache Strutsパッチアラートの転送に失敗したことを理由に解雇された。
課題2:パッチ管理プロセスとスキャン
  • パッチ管理プロセスが適切に行われておらず、ACISシステムへのビジネス所有者、担当者、パッチ適用の責任者が明確化されておらず、パッチ適用についても実運用レベルで責任範囲が不明確であり、知識を持つ個人によりカバーされていたと考えられる。
  • 脆弱性スキャンを実施しているが、検出されていない(レポートでは、インベントリ管理ができていないこと、コンテキストパスに脆弱性スキャンを実施していないことが検出できなかったとしている。但し、このApache Struts脆弱性は、ツールによるスキャンでは検出できない可能性があると考えられる。)
課題3:証明書管理プロセス(管理セキュリティ機能設定の不備)

内部のセキュリティ証明書の有効期限が切れており、SSL可視化アプライアンスは、証明書がないため、暗号化通信を複合しない状態で、IDS/IPSを通過していたことになります。そのため、IDS/IPSは検知することができませんでした。

セキュリティ証明書は、2016年1月31日で有効期限が切れており、324個の証明書が有効期限切れになり、19か月間通信を監視できていない状態が続いています。

また、本報告書には書かれていないため推測になりますが、19か月もアラートがなければSecurity Operationチームも検知率の低さに気付くべきだとも考えられます。

f:id:security_consultant:20190323090418p:plain

課題4: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やセキュリティを専門的に学んだ経験がなく、ログ取得が30日で十分であるなどと少しセキュリティ専門家として常識とは異なる考えを持っている。image
課題5:サイバーセキュリティに関する経営層の優先度

Equifaxでは、セキュリティが重視されていませんでした。

  • CEO Richard Smith氏は、四半期に一度の経営会議でしか、セキュリティの状態を確認しておらず、タイムリーに情報を受け取って」いなかった。
  • CSO Susan Mauldin女史は、経営層だと見なされていないため、このミーティングに参加しておらず、CLO経由で報告を行われていた。
  • 2015年のパッチ管理プロセスの監査で8項目の指摘を受けていたが、対策が行われていなかった。
課題6:複雑かつレガシーな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万ドルの支出を理由に挙げている。これは信用格付け機関が、サイバー攻撃による財政的影響を理由に、企業の格付け見通しを引き下げた初の事例として知られている。

www.scmagazine.com

japan.zdnet.com

法規制への抵触と政府機関等による調査

  • 今回の情報漏洩は、以下の法規制に関係している。
    • 連邦取引委員会法(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

    krebsonsecurity.com

    www.nytimes.com

事後対応における批判

批判1:情報公開用特設ページ+コールセンターへの批判

  • コールセンターを急いで構築したため、電話がつながらない、明確な回答が得られないなどの批判が出る。
  • 顧客が自分の情報が漏洩しているか否か確認するため、equifaxsecurity2017.comというサイトを構築したが、本来の会社ドメインequifax.comとは異なるためわかりづらいと指摘を受ける。
  • Twitterの公式アカウントも、誤ったURL(securityequifax2017.com)と書いてしまい、2週間の間フィッシングサイトへ誘導。当該ドメイン自体は、セキュリティ研究者により取得されており、フィッシングサイトというより、啓蒙サイトとして機能した。
  • サイトがうまく機能せず、クレジット監視サービスへの登録がうまく機能しない、同じユーザで携帯電話とPCで結果が異なるなど、不具合を指摘されている。
  • サイトのセキュリティ対策がお粗末だと指摘される。具体的には、サーバ証明書としてCloudFlareの共用証明書を利用し、実在性証明が担保されていない、WordPressで構築されており、広告会社Edelman PRを使っていることなどがBrian Krebs氏によって露呈する。

krebsonsecurity.com

批判2:幹部の退職

9月7日にインシデントを公開した後、Mandiant社の調査が終了する前に、3人の幹部社員が退職しています。

  • 9月15日:CIO David Webb氏、CSO Susan Mauldin女史
  • 9月26日:CEO Richard Smith氏

批判3:Equifaxの経営陣によるインサイダー取引

情報漏洩事実が社内で発覚した後、8月1日~2日に3人の上級幹部が株を売却したと知られ、インサイダー取引疑惑が挙げられました。*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も批難されているという記事が出ています。

www.reuters.com

fortune.com

まとめ

Equifax社の情報漏洩は、非常に学びの多いインシデントです。こうしたインシデントの組織内部の状態などは、大手企業を中心に他人事とは思寝ない部分もあるのではないでしょうか。

 

『The Sliding Scale of Cyber Security』を再考する

The Sliding Scale of Cyber Security』とは、Robert M. Leeにより提唱された概念で、サイバーセキュリティ態勢の成熟度を表すモデルです。このモデルによると、サイバーセキュリティの成熟度を脅威対応の観点からみて、5段階(Architecture・Passive Defense・Active Defense・Intelligence・Offense)に分類を行っています。

 

f:id:security_consultant:20190209121259p:plain

以前、「脅威の検知レイヤーモデル」という概念を考えましたが、基本的な考え方は同じだと思うので、その考え方も踏まえていきたいと思います。

www.scientia-security.org

その内容を具体的に見ていきましょう。

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にはレベルが3種類あると考えています。ここでは、以前提唱した「脅威の検知レイヤーモデル」をもとに考えてみましょう。

f:id:security_consultant:20190317173248p:plain

  • レイヤー1:振る舞い検知型
  • レイヤー2:サイバー脅威インテリジェンス型
  • レイヤー3:脅威ハンティング型
  • レイヤー4:Offensive Countermeasure(上記に記載なし)

このモデルは、レイヤーが大きくなればなるほど高度な脅威に対応できる一方、時間やリソースが必要になります。

第一のレイヤーは、振る舞い検知型です。これは、アノマリー型検知ツールから出てきた結果をログなどを分析して検知する方法です。この方法は、半分ツールベース、半分人間ベースの方法です。

第二のレイヤーは、サイバー脅威インテリジェンス型です。これは、外部から取得した脅威インテリジェンス(IoC)をもとに分析する方法です。脅威インテリジェンスは、基本的にはツールのシグニチャにはなっていない最先端のIoCが共有されるものになりますので、ツールでは検知できない内容ばかりです。

第三のレイヤーは、脅威ハンティング型です。これは、サイバー脅威インテリジェンスの情報や自分の経験から、Aという攻撃手法が脅威インテリジェンスで共有されているのであれば、Bという攻撃手法があるのではないか?などを考えて新しい脅威を見つける方法です。より詳細な考え方については、こちらの記事をご覧ください。

www.scientia-security.org

第四のレイヤーは、Offensive Countermeasureと呼ばれる手法です。この手法は、日本では推奨されていませんが、考え方としては知っておく必要があります。

www.scientia-security.org

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は、4つのフェーズで構成されているモデルです。

f:id:security_consultant:20180207214711p:plain

Phase 1 : Threat Intelligence Consumption

このフェーズでは、組織の目的を正確に理解し、それに関連する脅威インテリジェンスを収集します。その後、Blue Teamがすぐに活用できるように、脅威インテリジェンスを取捨選別し、IoCのような形に情報を翻訳して挙げる必要があります。

Phase 2 : Network Security Monitoring(= Threat Hunting)

Phase 1の情報をもとに、脅威ハンティングを行うフェーズです。具体的には、収集、検知、分析の3フェーズによって構成されており、データを分析しながら攻撃の兆候を見つける脅威インテリジェンスを行うフェーズです。

Phase 3 : Incident Response

脅威インテリジェンスで見つけられた脅威について、封じ込め、脅威の排除などを行うインシデント対応プロセスです。

Phase 4 : Threat and Environment Manipulation

インシデント対応プロセスで収集できた脅威情報をもとに、改善を行うパートです。脅威情報をより深く知るため、フォレンジック、ログ分析、マルウェア解析などいろいろな手法で分析し、よりよいIoCを作成する、あるいは環境を変更してより安全なシステム構成を作成するプロセスです。

F3EAD

F3EADモデルは、以下の6つのフェーズが挙げられます。

  1. Find:調査フェーズ
  2. Fix:決定フェーズ
  3. Finish:完了フェーズ
  4. Exploit:活用フェーズ
  5. Analyze:分析フェーズ
  6. 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を行う際の一つのきっかけにもなってしまいます。

www.scientia-security.org

Anti-Intelligence技術は、こうしたインテリジェンス調査に対抗する技術として開発された手法です。この手法、攻撃者、防御者それぞれが活用できる技術である一方、その立場により応用する具体的手法は異なります。本章では、それぞれの立場からAnti-Intelligenceについて検討してみたいと思います。

攻撃者目線でのAnti-Intelligence技術

攻撃者側(Adversary)から見れば、インテリジェンス調査で自分たちに関する情報が露呈することは決して好ましいことではありませんし、できる限りその姿を隠したいと考えるのが一般的です。Hactivistのような特定の主張を行う団体でも、その団体の存在意義については露呈したいと考える一方、実際の攻撃手法を隠したいと考えます(実際の攻撃手法が露呈し対抗されてしまえば、Hactivistとしてインパクトを与えられないからです)。そのため、攻撃者(Adversary)が自分たちの脅威やTTPを漏らさないために、自分たちの情報を隠したり、露呈しないようにする技術を開発し、応用するようになりました。

インテリジェンス工作技術の一つとして、外部からの情報収集を困難にさせるフレームワーク「D&D理論」(Denial & Deception - 拒否・欺瞞)がありますが、ここではこの枠組を応用してAnti-Attribution技術を整理したいと思います。

アプローチ1: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による情報収集がされないように痕跡を消す」アプローチ以外にも、「まったく関係のないゴミ情報をたくさん発信する」ことにより本来たどり着いてほしくない情報にたどり着きにくくする方法などが存在します。

アプローチ2:Deception(欺瞞)

欺瞞(Deception)とは、「発信する情報の内容を操作することによって、情報収集側の分析者及びユーザの考えをコントロールする工作技術」を意味します。簡単に言えば、意図的に広められる虚偽・不正確な情報(False Flag) を残し、脅威インテリジェンスがその偽情報を追跡する、あるいは別の攻撃者が攻撃したように誘導することでAttributionを避ける攻撃的なアプローチで、Disinformation(偽情報)工作とも呼ばれます。その意味では、攻殻機動隊でよく出てくるセリフのように、「あるいは、我々にそう思わせたい第三者の意図が介在している」を実践でいく技術だといえます。

Disinformation技術については、以下の情報を参照してください。

www.scientia-security.org

防御者目線でのAnti-Intelligence技術

次に、防御者の観点からAnti-Intelligence技術を検討してみたいと思います。

攻撃者側もこうしたインテリジェンス技術の一部を活用して、攻撃対象に対して入念な調査を行っていることが一般的になっています(攻撃モデルのCyber Kill Chainにおいて、最初の第一段階が偵察(Reconnaissance)といわれ、必ず様々な調査を使って調査を着てきます)。そのため、防御者(Defenders)の立場からすれば、攻撃者のこうした「偵察フェーズへの対抗技術」としてAnti-Intelligence技術を応用したいと考えることが重要です。ちなみに、伝統的なインテリジェンスでは、こうした「攻撃側のインテリジェンスへの対抗技術」のことをCounter-Intelligenceとよんでいます。実際に、CIAの公開資料では、以下のように定義されています。

www.cia.gov

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理論」の枠組で整理していきましょう。

アプローチ1:Denial(拒否)

このアプローチの目的は、すでに述べた通り「カモフラージュ等によって情報へのアクセスや収集を制限すること」にあります。そのため、基本的には攻撃者から見て情報が取れないような状態を作り上げることが重要だといえます。

Cyber Hygine

第一に、Cyber Hygine(サイバー衛生)と呼ばれるような攻撃者に付け入る隙を与えない、パッチ管理などのセキュリティの基本動作を徹底することが重要だといえます。

Red Team Operation

また、Tripwire社はブログポストにおいてこのアプローチの重要な要として、セキュリティ診断とレッドチーム診断を挙げています。既に説明した通り、レッドチームは攻撃者のTTPに熟知しているため、この目線でシステムやネットワークのセキュリティレベルをチェックすることでアクセスや収集を制限することが可能となります。

www.tripwire.com

Anti-OSINT

Anti-OSINTと呼ばれる、OSINTで本来の情報にたどれないようにする技術も有効です。具体的なアプローチとして、第三者のコンサルティング会社等に依頼してOSINT調査をいてもらい露呈した情報を洗い出し、削除するというのが一般的アプローチです。

アプローチ2:Deception(欺瞞)

前述でも記載した通り、このアプローチでは「発信する情報の内容を操作することによって、情報収集側の分析者及びユーザの考えをコントロールする」ことを目的としています。

この技術は、Cyber Deceptionと呼ばれ、SNS、ネットワーク、アプリケーション、データベース上などにDecoy(おとり)を仕掛けることにより、攻撃者のリソースを無駄遣いさせたり、Decoyに攻撃を行わせることにより時間を稼いだり、あるいは本来絶対にアクセスが発生しない端末・パラメータへのアクセスが発生したことにより攻撃を検知するなど、様々なベネフィットが存在します。

より詳しくは、以下の記事をご覧ください。

www.scientia-security.org

まとめ

 今回は、脅威インテリジェンス収集に対抗する技術として、攻撃側・防御側それぞれの目線でのどのような活用がされるか記載しました。基本的に、ANti-Intelligence技術は防御・攻撃にもどちらにも利用される技術であるため、攻撃側サービス(Red Team Operation)を行う担当者も防御側を担当する人も知っておくべき技術となります。特に、企業のセキュリティ担当者は自社を攻撃されるリスクを低減するため、Anti-OSINT技術などから初めてみるのがよいのではないでしょうか?