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

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

Threat Huntingとは何か?(その4)

前回は、Trailhead & Hypothesisについて取り上げました。

www.scientia-security.org

Sqrrl社はThreat Huntingについては様々なことを提唱していますが、"A Framework of Cyber Threat Hunting"というレポートの中で、Threat Hunting Reference Model(Threat Hunting参照モデル)という考え方を提示しており、この分野で重要となる3種類の考え方を提示しています。

  • The Hunting Maturity Model(HMM)
  • The Hunting Loop
  • The Hunt Matrix

今回は、その中からHunting Loopを取り上げてみたいと思います。

なお、以前にAPD(Advanced Persistent Defense)フレームワーク というものを紹介しましたが、現在のSqrrl社はこちらのHunting Loopのほうをよく紹介しています。

www.scientia-security.org

キーワード5:The Hunting Loop

Hunting Loopとは、以下のようなループです。(図は、Sqrrl社のレポートから引用)

f:id:security_consultant:20170115130234p:plain

1. 仮説構築フェーズ(Hypothesis Generation)

仮説構築フェーズは、前回取り上げたのでそちらを参照してください。

www.scientia-security.org

 2. 調査フェーズ(Tools and Technique Enabled Investigation)

調査フェーズとは、仮説を検証するためのツール・テクニックを利用して調査を行うフェーズです。テクニック自体は既存のインシデント・レスポンス技術、IOCを使った調査など様々ありますが、レポートでは、Link Data Analysisという手法や、分析技術についても言及しています。この手法については、長くなるので別途紹介します。

3. 発見フェーズ(Patterns & TTP Discovery)

発見フェーズとは、攻撃者の行動と攻撃的なTTPsについて発見するフェーズです。このフェーズが終わる時には、Huntingに必要な特徴を把握したことになります。

4. 共有フェーズ(Automated Analytics)

共有フェーズとは、発見したTTP・パターンをIOCとして定義し、各種分析ツール・チームに共有するフェーズです。重要なことは、なるべく手動で同じ調査をすることを減らし、自動化することが重要となります。やり方としては、Apache SparkやRを使って統計的に分析するなど様々なやり方が存在します。

まとめ

今回は、Threat Hunting Loopを解説しました。このステップはThreat Huntingの重要な要素になるため、知っておいて損はないと思います。

Threat Huntingとは何か?(その3)

先日は、APDフレームワークについて取り上げました。

www.scientia-security.org

今回は、Trailheadというキーワードとその背後にある仮説構築について、ホワイトペーパーを読み解きながらまとめていきたいと思います。

キーワード4:Trailhead & Hypothesis

Trailhead(調査の起点)とは、Threat Huntingに関するプロセスを開始するトリガーのことです。Threat Huntingで分析担当者の重要な役割のひとつに、どんな脅威を捕捉したいのか、どのような方法で見つけられるのか、といった課題設定が挙げられます。この課題設定を「仮説」(Hypothesis)と呼んでいます。つまり、Trailheadとは「設定した仮説」のことを意味します。

それでは、仮説が持つべき要素、仮説を構築する方法論とはどのようなものでしょうか?

仮説が持つべき要素

Threat Huntingの文脈における仮説とは以下の2要素を兼ね備えている必要があります。

  1. 観察(Observation)に基づくこと
  2. 検証可能(Testable)であり、検証に必要なデータにアクセスできること

3つの仮説のタイプ

なお、Sqrrl社によれば、仮説の構築方法は大きく3種類あるとしています。

  • Intelligence-Driven Hypotheses
  • Situational-Awareness
  • Domain Expertise
 Intelligence-Driven Hypotheses

Intelligence-Driven Hypothesesとは、Cyber Threat Intelligenceチームの情報、マルウェア分析や脆弱性スキャンの結果、既知のIOC(Indicator of Compromise)やTTP(Tactics, Technique, Procedure)などを元に仮説を構築する手法です。IOCなどをもとに仮説を構築する手法は一般的な仮説構築手法だといえます。

Situational-Awareness

Situational-Awareness Driven Hypothesisとは、環境におきた変化に気付き、仮説を構築する方法で、ベースラインをよく知っていることが条件となります。このとき、攻撃者は価値のある資産、もしくは一番リスクが高い場所から狙いを定めてくることが前提となることから、Crown Jewel analysisやリスク・アセスメントなどを事前にしておくことで集めるべき情報が明確になり、仮説が立てやすくなります。

大きなネットワークではマニュアルで対応することには限界があるため、自動化・リスクアルゴリズムなどAnalytics-Driven Approachを併用するように述べています。具体的には、UEBA・EDR・SIEMなどの各種分析ツール、もしくは機械学習など各種アルゴリズム分析によって抽出された結果をもとに分析を進めていく必要があります。

Domain Expertise

Domain Expertiseとは、過去の経験に基づく仮説です。具体的には、各アナリストは異なる経験を持っているために、文書化による情報共有をして、全員が同じ過去の事例を知っていることが重要だと指摘しています。また、過去の経験に基づく仮説は認知的バイアスにかかっている可能性があるため、その点についても注意する必要があります。なお、分析における認知的バイアスについては、Threat Intelligenceの分野で必ず取り上げられる話題なので、別の機会にまとめたいと思います。

まとめ

仮説構築については、いかがだったでしょうか。Cyber Threat Intelligenceの授業でもこれらのことについて触れられます。次は、この仮説を基にした、Threat Hunting Loopについて解説をしたいと思います。

Threat Huntingとは何か?(その2)

先日、Threat Huntingについて、IOCとPyramid of Painについてまとめました。 

www.scientia-security.org

第2回目は、引き続きSqrrl社の記事を元に、別のキーワードを取り上げます。

キーワード3:APDフレームワーク

APD(Advanced Persistent Defense)フレームワークとは、Sqrrl社のセキュリティ・アーキテクトであるDavid Biancoが提唱した標的型攻撃に対する防御フレームワークThe Defense Chainを精緻化したモデルです。

一般に、標的型攻撃への対応フレームワークとして、Cyber Kill Chainというモデルが有名ですが、よりそれをアクティブに対応できるようにしたフレームワークだと述べています。APDフレームワークの最終的なゴールは、Pyramid of Painで提唱されていたように、一番強力なIOCであるTTP(Tactics, Technique, Procedure)を利用して高度な対応をすることにあります。

APDフレームワークは大きく3種類のフェーズ(Intelligence → HuntingResponse)で構成されており、これらを継続的に実施していうことでTPPを効率的に発見し、適用していくことを推奨しています。また、各フェーズごとに実施すべきサイクルが定義されています。(図は、Sqrrl社のブログより引用)

 

f:id:security_consultant:20170114153027p:plain

Intelligence Cycle

Intelligence Cycleとは、方針(Direct)→ 収集(Collect)→ 分析(Analyze)→ 配信(Disseminate)という情報分析のサイクルです。Cyber Threat Intelligenceの講義などでは、以下のようなインテリジェンス・サイクルという分析フローを学びますが、基本的には同じ考えかたです。

インテリジェンス・サイクル - Wikipedia

Hunting Cycle

Hunting Cycleとは、ネットワーク・システム内に隠れている高度な脅威を検出するために、データを積極的かつ反復的に検索することに重点を置いたサイクルです。こちらも、情勢判断(Orient)→ 検索(Query)→ 分析(Analyze)→ 修正(Revise)という4ステップで構築されています。情勢判断フェーズは、Intelligence Cycleによってもたらされたtrailhead(調査の起点)を把握するフェーズです。また、検索・分析フェーズではLinked Data Analysis(リンクデータ分析)という手法が活用されます。この手法については、別途解説します。

Response Cycle

Response Cycleとは、封じ込め(Contain)→ 調査(Investigate)→ 影響緩和(Remediate)という3つのステップで構成されています。各内容はインシデント・レスポンスで一般的な内容かと思いますので省略します。

まとめ

今回は、APD(Advanced Persistent Defense)フレームワークを紹介しましたが、いかがだったでしょうか。APT(Advanced Persistent Threat)に対してどう対応していくべきかわかりやすいグラフになっています。ただ、Sqrrl社はThreat Hunting参照モデルという概念モデルを提唱しており、そこで提唱されているThreat Hunting Loopはもっと簡素化されたモデルとなっています。このモデルについては別の機会に紹介しようと思います。

Threat Huntingとは何か?(その1)

Threat Huntingという概念をご存知でしょうか?

一言で言えば、「高度な標的型攻撃を検知・対応するための方法論」ですが、2015年度ごろから米国のカンファレンス等でよく耳にする単語です。しかしながら、Threath Huntingについて体系的に学べる資料がないため、しばらくの間学んだことをまとめて、Threat Huntingへの理解を深めたいと思います。

第1回目は、UEBA製品で有名なSqrrl社の記事を元に、2種類のキーワードを取り上げます。

キーワード1:IOC

IOC(Indicator of Compromise)とは、以下のようにに定義されます。

マルウェア・ハッキングなどにより侵害を受けたシステムにおいて、その脅威が存在することを示す痕跡

 例を挙げれば、悪性URLへのアクセス、不正なレジストリキーなどがそれに該当します。

無差別に配布されるマルウェアと異なり、標的型攻撃では攻撃対象企業用にカスタマイズされたマルウエアが利用されます。そのため、マルウェア対策ソフトでパッチが提供されることは期待できず、とはいえ自社の攻撃に利用されたマルウェアを外部に渡したくないという事情があります*1

そのため、各社ごとに標的型攻撃マルウェアを分析し、独自のシグニチャを作る必要があり、IOCをシグニチャ化して調査を効率化する、他に同じ攻撃を受けている端末がないか一斉スキャンをするなど、IOCは幅広く使われています。

なお、IOCをシグニチャとして記述する方法として、OpenIOC・STIX・VERIS・YARAなど様々あり、それぞれツールが開発されています。(参考資料

キーワード2:Pyramid of Pain(痛みのピラミッド)

Pyramid of Pain(痛みのピラミッド)とは、Sqrrl社のセキュリティ・アーキテクトであるDavid BiancoがIOCを分類するために提唱した概念です。

いかに、その図を示します。(図は、Bianco氏のブログより引用

f:id:security_consultant:20170113154400p:plain

簡単に言えば、一番下が防御者・攻撃者の痛みは少なく、上に行けば行くほど両者にとっての痛みが増すことを示した図です。

例えば、ハッシュ値をIOCとして収集して各種セキュリティ製品に適用することは簡単である(=防御側の痛みが少ない)といえます。一方、ハッシュ値は簡単に変更できてしまうため、攻撃者にとってもIOCとしてハッシュ値が与えるダメージはほとんどない(=攻撃者側の痛みが少ない)といえます。逆も然りで、TPPは作成・適用ともに難しい反面、きちんと実装できれば攻撃者に対しても大きなダメージを与えるといえます。これを理解したうえで、どのレベルのIOCを作るべきなのか考える上で役に立ちます。

いかに、各レイヤーの中身を簡単に見てみましょう。

ハッシュ値

特定の疑わしいファイルや悪意のあるファイルに対応するSHA1、MD5などのハッシュです。マルウェアの同一性の証明でもよく利用されます。但し、ハッシュ値を変更するのはとても簡単です。多くの場合、ハッシュ値を追跡する価値がない場合もあります。

IPアドレス & ドメインネーム

これも、基本的な指標ですが、攻撃発生元を調べるのに有益な指標です。

アーティファクト

ネットワークやホストに攻撃者により意図的に作成された痕跡のことです。これにより、正規ユーザとの区別をつけやすくなります。具体的には、URLパターンやC2通信の存在、レジストリ・キーや特定の場所に存在するファイルなどが該当します。

ツール

攻撃者が利用するソフトウェア・実行ファイルのことです。例えば、PowerShellや、特定のコマンド、ツールなど関連ソフトウェアは大きな指標となります。

TTP

TTP(Tactics, Techniques and Procedures)とは、本来安全保障などの分野でテロリズム脅威分析などに利用する分析手法で、行動パターンを分析するためのものです。サイバーセキュリティの文脈でいえば、スピア・フィッシングにより「ライセンス更新」を装うメールで攻撃をしてくるなど、具体的な攻撃パターンを意味します。行動パターンを変更することは攻撃者にとって高いコストが伴うため、TTPを適切に定義できれば、攻撃を防ぐ上で非常に有益になります。そのため、Threat HuntingではこのTPPをいかに発見し、IOCとして定式化するかという点が一番重要となってきます。

まとめ

今回は2つのキーワードを取り上げましたが、いかがだったでしょうか。

Threat Huntingには様々な理論・考え方が存在しますので、今後も引き続き紹介していきたいと思います。

*1:とはいえ、各社だけで対応していくことに限界があることから、信頼できる仲間内(同じ業界関係者)で攻撃関連の情報を共有したり、IOCを共有するISAC(Information Sharing and Analysis Centers)という情報共有組織が立ち上がりつつあります。有名な組織として、FS-ISAC(金融ISAC)・NH-ISAC(ヘルスケアISAC)などが挙げられます。

NY州金融サービス局のサイバーセキュリティの規制について

米国金融系企業の中で現在話題となっているトピックの一つに、ニューヨーク州金融サービス局が提案しているサイバーセキュリティに関する規制が挙げられます。

全文翻訳したので、内容をごらんになりたい方は以下のリンクへどうぞ。

(翻訳・法律の専門家ではないため、利用は自己責任でお願いします。)

 

今日の記事では、その詳細と内容について取り上げたいと思います。

  • WHO:「ニューヨーク州金融サービス局」とは?
  • WHOM:だれが対象となるのか?
  • HOW:どのような経緯で?
  • WHAT:サイバーセキュリティ規制の内容とは?
  • WHEN:準拠までのタイムラインとは?

WHO:「ニューヨーク州金融サービス局」とは?

ニューヨーク州金融サービス局(NYDFS : New York Department of Financial Services)とは、ニューヨーク州(以下、NY州)を管轄する金融庁みたいな州政府機関です。セキュリティに対して積極的な施策を打つことで知られています*1

例をあげれば、2015年2月にAnthemという保険会社で情報漏洩が発生した場合、全保険会社にサイバーセキュリティ検査を実施するよう通達を出していることでも知られています。(詳しくは、詳しくは笹原先生の資料を参照のこと)

WHOM:だれが対象となるのか?

全金融機関です。ちなみに、NY州法なので、NY州に本社・拠点がないから関係ないと考えてしまいがちですが、NY州で金融サービスを提供している全ての金融サービス企業が対象となるため、本社・支店がNY州にない場合でも、サービスを提供している限り対応義務が生じます。対応をしない場合、当局によりライセンスが剥奪され*2、ニューヨーク州内で金融サービスを提供できなくなる可能性さえ考えられます。

HOW:どのような経緯で提示されたのか?

提示までの経緯は以下のとおりです。

  • 2016/09/13:NY州金融サービス局より各企業へ通達。ドラフト版を公開。
  • 2016/09/28:45日間のパブリックコメント期間を開始。
  • 2016/11/14:パブリックコメント期間終了。
  • 2016/12/28:パブリック・コメントを反映した修正版が公開。

詳しい内容については後で記載しますが、ドラフト版はかなり踏み込んだ内容で、対応方法についてはかなり議論がなされた内容でした。

例えば、9月時点のルールでは以下のように言及されていました。

Section 500.12 多要素認証

(a) 多要素認証. 対象企業は以下を満たす必要がある。

 (1) 外部ネットワークからの内部システム、およびデータに対する全てのアクセスに対して、多要素認証を実装すること

 

 (2) 非公開情報を保持するデータベースサーバへの高い権限によるアクセスに対して、多要素認証を実装すること

 

 (3) 非公開情報を取り扱うWebアプリケーションにアクセスに対して、リスクベース認証を実装すること

 

 (4) 非公開情報を取り扱うWebアプリケーションにアクセスに対して、多要素認証をサポートすること

実際に、ロイター通信によると150以上のコメントが当局側に寄せられており、企業規模に関わらず同じルールが適用されることについて、あるいは定義が曖昧であるなど色々なコメントがされたようです。

WHAT:サイバーセキュリティ規制の内容とは?

12月末に公開された修正版の内容を紹介しようと思います。個人で訳を作成し、SlideShareに公開しています。あくまでも自己研鑽と規制の雰囲気を理解する上で作りましたので、利用についてはは自己責任でお願いします。内容は全文を読んでいただければ一番良いのですが、簡単にその概要を説明します。

◆全文(日本語版)のダウンロード先

構成

基本的に23条の条文にわたる内容です。そのうち何章かは法律的文言、および定義に割かれているため、実施的には16種類程度の要件と考えられます。以下に、各章のタイトルを示しています。

  • Section 500.00 はじめに
  • Section 500.01 定義
  • Section 500.02 サイバーセキュリティ・プログラム
  • Section 500.03 サイバーセキュリティ・ポリシー
  • Section 500.04 最高情報セキュリティ責任者
  • Section 500.05 侵入テストと脆弱性診断
  • Section 500.06 監査証跡
  • Section 500.07 アクセス権限
  • Section 500.08 アプリケーション・セキュリティ
  • Section 500.09 リスク・アセスメント
  • Section 500.10 サイバーセキュリティ人材とインテリジェンス
  • Section 500.11 外部委託先に対するセキュリティ・ポリシー
  • Section 500.12 多要素認証
  • Section 500.13 データ保持に関する制限
  • Section 500.14 トレーニングとモニタリング
  • Section 500.15 非公開情報の暗号化
  • Section 500.16 インシデントレスポンス・プラン
  • Section 500.17 監督当局への通知
  • Section 500.18 機密性
  • Section 500.19 免除規定
  • Section 500.20 施行
  • Section 500.21 発効日
  • Section 500.22 移行期間
  • Section 500.23 法的分離条項

いくつか注目すべき内容について言及しようと思います。

スコープについて

Section 500.01 定義 によれば、スコープは非公開情報(Nonpublic Information)と情報システムを守るという定義になっていますが、この非公開情報の定義は9月のドラフト版でも不明瞭だといわれており、明確に定義されました。

以下に訳の抜粋を示します。

非公開情報(Nonpublic Information)は公開情報ではない電子情報と以下に示す情報を指す。


(1) 改竄・不正な開示・アクセス・不正利用により、対象事業者のビジネス業務、もしくはセキュリティに対して重大な悪影響を及ぼす対象事業者のビジネスに関する情報。

 

(2) 名前・番号・個人商標・他の識別コードなどにより、あるいは以下のデータ要素の一つもしくは複数の組み合わせにより、個人を特定可能な情報

 

(3) 医療サービス提供者・個人により作成される、もしくは以下の事象から派生・関連する情報(但し年齢または性別を除く)

一言で言えば、業務関連情報、個人情報(PII : Personal Identifiable Information)、医療情報(PHI:Personal Health Information)を意味していると考えられます。米国では、守るべきデータとしてPII・PHIはよく登場する呼び名です。

セキュリティ監査の回数

Section 500.05 侵入テストと脆弱性診断によれば、本規則では最低1年に1回の侵入テスト(ペネトレーション・テスト)と2回の脆弱性スキャン(ツールなどによるスキャン)が定義されています。文脈から類推するに、全エリア(Webアプリケーション、ネットワーク、およびビジネスOA環境)に対して実施することを義務付けているように見えます。この基準自体は、PCI-DSS*3を参考に作成されたのではないかと類推します。

多要素認証について

Section 500.12 多要素認証によれば、先ほど例に挙げた多要素認証については、かなり方針転換したように見受けられます。

Section 500.12 多要素認証

(a) 多要素認証。リスク・アセスメントに基づき、各対象事業者は多要素認証やリスクベース認証などを含む効果的なコントロールを用いて、非公開情報や情報システムを不正アクセスから守らなければならない。

 

(b) 多要素認証は、対象事業者のCISOが合理的に判断して、同等もしくはより安全なアクセスコントロールの利用について書面にて承認しない限り、外部から対象事業者の内部ネットワークに対するあらゆるアクセスに対して適 用されなければならない。

特に、「リスク・アセスメント」の結果を踏まえて優先度をつけて導入可否が決められるようになったこと、代替コントロールが認められたという点で、企業の対応負荷はけったと推測されます。

当局への通知義務について

Section 500.17 監督当局への通知によれば、以下の2つが規定されています。

Section 500.17 監督当局への通知

(a) サイバーセキュリティ・イベントの通知。 各対象事業者は、以下のようなサイバーセキュリティ・イベントが発生したと判断してから、72時間以内に監督当局に対してできるだけ迅速に通知しなければならない。


 (1) 政府機関、自主規制期間、もしくは他の監督当局への通知が義務付けられているサイバーセキュリティ・イベント。

 (2) 対象事業者の通常のビジネス業務に被害を与えている合理的な可能性があるサイバーセキュリティ・イベント。

 

(b) 各対象事業者は、毎年2月15日までに対象事業者が本規則の要件に従い準拠していることを示す書面を、付録Aの形式で、監督当局に提出しなければならない。各対処事業者は5年間において、監督当局からの検査に備えて、本証明書の根拠となるすべての記録、スケジュールデータを保持しなければならない。(後略)

 大きく2種類の報告義務があり、一つは年に1回当該規制に準拠していることを示すCOC(Certification of Compliance)という資料を提出することです。また、申請内容が正しいことを証明できる証拠は全てそろえ、過去5年間分は要求されたらいつでも提示できるようにする必要があります。

第二に、特定のインシデントについては発生してから72時間以内に当局に届け出なければいけないという点です。具体的な運用は始まっていないのでわかりませんが、比較的時間との勝負になると考えられます。

免除規定

以下の企業については、本内容の一部が免除されるようです。詳しくは原文をご覧ください。

WHEN:準拠までのタイムラインとは?

Section 500.21・Section 500.22によれば、2017年3月1日から発効となり、そこから180日間の移行期間が与えられますので、8月末までに対応を完了させる必要があります。但し、Section500.22に例外規定が定義されており、いくつかの内容についてはさらに猶予期間が設けられています。

1年間の猶予がある項目

  • Section 500.04(b) 最高情報セキュリティ責任者(年1回、CISOから経営取締役会への書面での報告義務に関する条項)
  • Section 500.05 侵入テストと脆弱性診断
  • Section 500.09 リスク・アセスメント
  • Section 500.12 多要素認証
  • Section 500.14(a)(2) トレーニングとモニタリング(一般ユーザに対するセキュリティ教育に関する条項)

1年間半(18ヶ月)の猶予がある項目

  • Section 500.06 監査証跡
  • Section 500.08 アプリケーション・セキュリティ
  • Section 500.13 データ保持に関する制限
  • Section 500.14(a)(2) トレーニングとモニタリング(モニタリングに関する項目)
  • Section 500.15 非公開情報の暗号化

2年間の猶予がある項目

  • Section 500.11 外部委託先に対するセキュリティ・ポリシー

まとめ

9月時点のドラフト版はかなり踏み込んだ内容であったため対応が大変そうだという印象しかなったのですが、比較的わかりやすく、またリーズナブルな内容になっていると思います。今後、他の州も同様の規制を行ってくると思いため、今後の動向にも注目する必要があると考えられます。

*1:ちなみに米国現地の同僚によると、こういうセキュリティ関連の施策はCA州(カルフォルニア州)ちなみに、カリフォルニア州は、2002年に米国初のSecurity Breach Notification Law(データ漏洩通知法)を採択し、個人情報が漏洩した可能性があると判断される場合、企業は各消費者にその旨を通知することを義務付けています。ちなみに、他の多くの州もその法律に追従していまや全米でも一般的に知られる法律となっています。かNY州のどちらかが実施する傾向にあるらしいのですが、今回はNY州側が規制をだした様子です。

*2:アメリカは州単位で異なるため、各州ごとにライセンスを取得する必要があるなど日本よりも色々複雑です。

*3:PCI-DSSでは、ASVによる年4回の脆弱性スキャンと、毎年1回のペネトレーションテストが義務付けられています。