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

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

Cyber Threat Intelligenceとは何か?(その1・2018年度版)

(修正履歴)

  • 過去のエントリをいろいろ改善して再投稿しました。
  • 2019年2月9日に一部更新を行いました。

今回のエントリーでは、Cyber Threat Intelligence(CTI)について解説をしていきます。

第1回では、Cyber Threat Intelligenceの概要について定義していきたいと思います。

Intelligenceとは何か?

インテリジェンスとは、諜報活動や情報分析に関する軍事用語です。

諜報機関として有名なCIA(Central Intelligence Agency)はアーカイブ上で過去の資料(コレとかコレ)を複数公開していますが、少し古く、議論が尽くされていないと筆者は考えています。本書では、アメリカ統合参謀本部(JCS:Joint Chiefs of Staff)が発表している資料(DOD:Dictionary of Military and Associated Terms)からインテリジェンスの定義を見てみましょう。(ちなみにですが、Cyber Threat Intelligence の単語の多くは軍事用語を転用しています。そのため、なにか気になるキーワードがあれば、まず上記の辞書に当たるのがよいと思います。)

  1. The product resulting from the collection, processing, integration, evaluation, analysis, and interpretation of available information concerning foreign nations, hostile or potentially hostile forces or elements, or area of actual or potential operations.
  2. The activities that result in the product.
  3. The organizations engaged in such activities.

 (筆者簡易訳)

  1. 海外諸国、(現在もしくは将来において)敵対的な組織や集団、軍事行動を行っている地域について利用可能な情報の収集・加工・統合・評価・分析・解釈の結果、作成された成果。
  2. 当該成果をもたらすための工作・活動。
  3. 当該活動に従事する組織。

 ここの定義をもとに他の定義を見てみましょう。

データ形式としてのインテリジェンス

第一に、インテリジェンスを情報のひとつの形式としてみた場合です。以下の図は、インテリジェンスは収集されたデータを整理・加工して、分析・評価を加えたものであると定義されています。(画像は、The Sliding Scale of Cyber Securityから引用)

f:id:security_consultant:20170119142400p:plain

プロセスとしてのインテリジェンス

 第二に、インテリジェンスをプロセスしてみた場合です。以下の図は、Intelligence Cycleと呼ばれ、インテリジェンスを作成する際に重要となるプロセスのことです。基本的に、要求→収集→評価→分析→配布というプロセスを経て実施します。(画像は、The Sliding Scale of Cyber Securityから引用)

f:id:security_consultant:20170119142044p:plain

組織としてのインテリジェンス

組織としてのインテリジェンスとは、組織としてインテリジェンスを持っていることを意味します。一般に、一つの組織で全てのインテリジェンスをカバーすることはできないため、インテリジェンス・コミュニティ(IC)を構成し、必要に応じて情報収集を行う。Cyber Threat Intelligenceの場合も、情報共有の枠組みとなるコミュニティが存在し、情報を共有し活用するというプロセスを行っています。

Cyber Threat Intelligenceとは何か?

上記を踏まえて、Cyber Threat Intelligenceについて考えていきましょう。

Cyber Threat Intelligenceでは、上記で紹介したサイバーの脅威(Threat)に対してデータを加工して役立てていくことを目的としています。その前に、Threat(脅威)を定義したいと思います。具体的には、以下の3要素で定義されます。

Threat(脅威) = Hostile Intent(敵対的な意図) × Capability(能力)  × Oppotunity (機会)

上記のThreatの定義を発展させると、Threat Intelligenceとは以下のように定義できます。

Cyber Threat Intelligence とは、敵対的な組織、集団、攻撃者および脅威(意図・能力・機会)に関する情報について収集・加工・統合・評価・分析・解釈を行い、自組織のセキュリティ維持と意思決定に役立てること

Gartner社の定義

ちなみに、この定義は数ある定義の一つであり、様々な定義が存在します。

例えば、Gartner社は少し異なる定義を出しています。(参考資料

Threat Intelligenceとは、脅威・危険に対する主体者の対応に関する決定を知らせるために利用できる、既存または今後発生する資産への脅威に関する文脈、メカニズム、指標、含意および実行可能な助言を含む、エビデンス・ベースの知識を意味する。

CBEST の定義

別の定義として、英国のセキュリティフレームワークCBEST の定義を見てみましょう。

CBEST とは、英国金融庁(FSA)が作成した侵入テストやインテリジェンス主導のセキュリティを定義したフレームワークです。この定義も非常にシンプルに、サイバースペースにおける脅威・攻撃者に関する情報収集だと位置づけています。(引用元:CBEST Intelligence-Led Testing - Understanding Cyber Threat Intelligence Operations

Information about threats and threat actors that provides sufficient understanding for mitigating a harmful event in cyber domain.

(筆者簡易訳)

サイバー空間における悪意あるイベントを緩和するために十分に活用可能な脅威と攻撃者に関する情報

Cyber Threat Intelligenceの分類

Cyber Threat Intelligenceは、その形式によりいくつか分類されます。

目的・期間による分類

Threat Intelligenceはその目的と期間で考えると、3種類に分類されます。

  • Tactical Threat Intelligence
  • Operational Threat Intelligence
  • Strategic Threat Intelligence

 以下の書籍では、上記3種類を以下のように説明しています。

サイバーセキュリティマネジメント入門 (KINZAIバリュー叢書)

サイバーセキュリティマネジメント入門 (KINZAIバリュー叢書)

 

以下のように、目的・利用サイクルにより情報の内容が変わります。

f:id:security_consultant:20180204130301p:plain

立場による分類

実際にThreat Intelligenceに携わる観点からすると、二つに分類されます。

  • Intelligence Production(生産者サイド)
  • Intelligence Consumption(消費者サイド)

生産者再度では、インテリジェンスサイクルに従い、攻撃モデル(Cyber Kill Chain)、ダイアモンドモデル、ACHなどを使いながら集めたデータを分析していく立場となります。

一方、消費者サイドでは、Threat Intelligence情報をいかに防御に利用していくか、ツールのインプットとして活用するかという視点が重要になります。

私見ですが、脅威インテリジェンス担当者はどちらか片方の立場に属するというより、まずは外部からのインテリジェンスを消費をしつつ、その過程で発見できたファクトについてはインテリジェンスに昇華させていくという両方の立場を言ったり来たりする形になると考えられます。

収集方法による分類

最後の分類は、収集方法からの分類です。

  • Defensive Approach(防御的アプローチ)
  • Offensive Approach(攻撃的アプローチ)

防御的アプローチとは、インターネット等で公開された情報を活用するOSINT(Open Source Intelligence)や、実際のインシデントから収集された情報をもとにインテリジェンスを生成する方法です。

一方、攻撃的アプローチとは、自社を狙った攻撃グループ、あるいは自社を潜在的に狙うであろう攻撃グループに対して、罠を仕掛けたり、より積極的に攻撃者とやり取りをして、より個別具体的な情報収集を行う技法です。Offensive Countermeasure とも呼ばれています。この手法は、攻撃者とやり取りをしたり、不用意に攻撃者を挑発する可能性もあるので、自社のセキュリティコントロールが高度かつ成熟していることに加え、法務などのにも相談しながら進める必要もあり、一部の攻撃技術等にも精通している必要があります。

詳しくはこちらの記事をご参照ください。 

www.scientia-security.org

良いCyber Threat Intelligenceの条件は?

次に良いCTIとはどうあるべきでしょうか。

Cyber Threat Intelligenceの消費・生成する目的は、「意思決定をするため」という点です。例えば、一番接しているインテリジェンスの代表例は、天気予報が挙げられます。なぜなら、気象予報士が生情報を分析し、明日の天気・降水確率などの判断に必要な情報を提供しているためです。

では、どのような天気予報であれば、意思決定に有効でしょうか。

この本の著者は、良いCyber Threat Intelligenceの3条件をあげています。

Actionable

第一の条件として、CTIの消費者がその情報をもとに次のアクションをできることが重要だと指摘しています。

先の天気予報の例でいえば、朝のお天気キャスターの「降水確率90%」という情報であれば、ほぼ確実に雨が降るので朝をもって出かけるというアクションにつながります。最近では、「傘を持って行った方がよい」、「洗濯物は干しっぱなしOK」、「厚手のコートが必要」などの情報もコメントされますので、より一歩踏みこんだインテリジェンスになっていると思います。

それでは、どのようなインテリジェンスが、Actionableな行動につながるのでしょうか。

結論とすると、CTIを消費する相手に依存します。天気予報の場合でも、外出する予定がない主婦の方であれば洗濯物に関連する情報が必要ですし、外出の多い営業担当であれば服装や傘の有無の方が気になります。

これは、Cyber Threat Intelligenceの場合も同じです。例えば、Struts2の脆弱性が公開され、自社の公開Webシステムでも利用している場合における、インテリジェンスを生成する場合を考えてみます。

運用チームとすれば、その脆弱性を未然に防ぐ必要があるため、例えばよく使われる攻撃元IPアドレスや、WAFにシグニチャを追加する具体的な攻撃リクエストなどが一番Actionableだと考えられます。

一方、相手が経営層だった場合はどうでしょうか。経営層は正直技術的詳細には興味がありません。むしろ、自社が被害を受けるのか否か、経営層として判断を支援するインテリジェンスが必要になります。

例えば、経営層に届けるべき情報として、以下のものが挙げられると思います。

  • Struts2を利用しているシステムではどんな情報を保有しているか?
  • 最悪の場合どんな情報が流出するか?
  • パッチの公開・適用までの間、攻撃にさらされるリスクをどのように考えるのか?
  • そのリスクを回避するためにどんな対策が取りえるのか?その対策の副作用は?他社の実績は?

例えば、2017年に公開されたStruts2の脆弱性に対して、NTTコミュニケーションズ社はサービスの一時停止を判断しています。ルールにもよりますが、意思決定をする人に説明する際には、上記のような情報を提供して、判断を仰いだはずと推測されます。ようするに、情報の受け手がきちんと理解して使えるように加工・精査してあげることが重要となると考えられます。

Certainty

第二に、インテリジェンスを受け取った担当者は、その情報をもとに次のアクションを行うため、情報の確からしさ、あるいは確度(The Degree of Certainty)を明確にすることが重要となります。

ここで注意すべきことは、正確さ(Accuracy)ではないです。当然、情報は正確である方がよいですが、インテリジェンスの性格上、絶対に正しい情報と言い切れないこともほとんどです。あくまでも限られた断片的な情報のみで判断を下すので、誤っている可能性もありますので常にUncertainty(不確実性)が付きまといます。その場合は、データの確からしさはどれぐらいなのか、その確度を明確にして伝える必要があるといえます。

天気予報の例に戻れば、雨が降れば遠足を中止するという場合、「雨が降るかも」というあいまいな状況では判断を誤る可能性がありますので、降水確率という形で確からしさを表現して意思決定者(視聴者)に判断を仰いでいます。但し、CTIの場合情報の確からしさを定量的に表現することは難しいため、定性的に表現することが多いといえます。

この辺の報告については、翻訳したこの本に詳しく議論されているので、ご参照ください。 

インテリジェンス駆動型インシデントレスポンス ―攻撃者を出し抜くサイバー脅威インテリジェンスの実践的活用法

インテリジェンス駆動型インシデントレスポンス ―攻撃者を出し抜くサイバー脅威インテリジェンスの実践的活用法

  • 作者: Scott J. Roberts,Rebekah Brown,石川朝久
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2018/12/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る
 

Timing

最後にインテリジェンスを提供するタイミングです。

インテリジェンスを受け取った担当者は、その情報をもとに次のアクションを行うため、適切なタイミングで情報を渡す必要があります。また、できれば意思決定をした後、アクションを行うためのリードタイムも考慮して伝えることが適切となります。

例えば、「午後から雨が降る」という情報を出勤中の電車に乗ってから知っても、傘を持たず、洗濯物を干しっぱなしにして出かけた人にとっては時すでに遅し、といえるでしょう。できれば、出かける前、できれば出かける直前ではなく少し余裕をもって知り、「傘を持つ」「洗濯物を取り込む」などのアクションができるリードタイムがあるとよいと思います。

脅威インテリジェンスの場合も同様です。例えば、DoS攻撃をネタに脅迫を行い、身代金を要求する攻撃グループ、DD4BCやArmada Collectiveが一時期はやりました。これもできれば自社に脅迫が届く前(=他社が脅迫を受けている時点)で情報を収集し、適切な人にインテリジェンスを連携し、対応の判断を仰げることが理想でしょう。少なくても、攻撃を受けてからでは遅いということになりかねません。

Cyber Threat Intelligenceをうまく活用する組織の条件は?

それでは、攻撃者について研究を行うCyber Threat Intelligenceをうまく活用するためには、どのような条件が必要なのでしょうか?

後の章で詳しく扱う「成熟度モデル」という観点から見ると、Intelligenceをサイバーセキュリティに活用する組織はかなりレベルの高い組織として位置付けられています。

例えば、CTIの専門家Robert M. Lee氏が提唱したサイバーセキュリティの成熟度モデルとして、『The Sliding Scale of Cyber Security』という概念があります。

f:id:security_consultant:20190209121259p:plain

この概念は、サイバーセキュリティの成熟度を脅威の対応の観点からみて、5段階に分類をしており、インテリジェンスを活用する組織は上から2番目に高い成熟度と位置付けられており、下の段階の要件を満たしているべきと指摘されています。

ここでは、有名な孫子の言葉を引用して、最低限の条件について考えましょう。

孫子の有名な言葉に、「彼を知り己を知れば百戦殆うからず」という格言がありますが、実はこの格言には続きがあります。

彼を知り己を知れば百戦殆うからず。彼を知らずして己を知るは一勝一負す。彼を知らず己を知らざれば戦う毎に殆うし。

 

(現代語訳)

敵を知り己を知っていれば、戦に負けることはない。敵を知らず、己のみを知っていれば勝負は運しだいである。そして、敵も味方も知らなければ、必ず戦争に負ける。

この格言で、孫子は「敵も味方も知らなければ、必ず戦争には負ける」と指摘しています。セキュリティの分野に読み替えれば、まずは己(自社の環境)をきちんと知らなければ、そもそも攻撃者からの攻撃を防ぐことができないと解釈でき、より解釈を付与すれば敵を知るサイバー脅威インテリジェンスこそが応用技術と位置付けられます。

そのため、この考え方をもとに、サイバー脅威インテリジェンスがうまく機能する最低限の前提条件は以下の三つだといえます。

重要資産の把握

第一に、重要な資産の把握が挙げられます。言い換えれば、攻撃者が何を狙ってくるであろう資産を正確に把握することが重要となります。このプロセスは、CJA(Crown Jewels Analysis)と呼ばれています。

成熟した機能するIT管理プロセス

「成熟した機能するITマネジメントプロセス」(Mature & Well-Functioning IT Management Process)とは、ITの管理プロセスがきちんとできていることを意味します。

例えば、資産管理・パッチング・アクセス制御・適切かつ十分なセキュリティ機器の導入などが挙げられます。これらがないと、そもそも自社の環境がきちんと管理できていないということになり、いくら敵の情報を集めても自社に適用して考えられないことになります。

全領域の可視化

全領域の可視化(Full Spectrum Visibility)とは、自社の環境(サーバ・ネットワーク)を正確とモニターできる機能を持つという意味です。これも自社の状況をリアルタイムに知ることができます。

具体的には、各種サーバのログ、EDRによるエンドポイント情報、プロキシやWebフィルタリングのログなどを収集し、SIEMと呼ばれる製品に一元的に収集し、ログ分析を行えるようにします。さらに、収集するだけでは宝の持ち腐れであるため、きちんと分析するためのプロセスも持っていることが望ましいと思います。 

まとめ

今回は、Threat Intelligenceの基礎についてまとめてみましたがいかがでしょうか。

Threat Intelligence分野はいろいろと学ぶべきことが多く今後も様々なアイディアを紹介していきたいと思います。

Offensive Countermeasuresとは何か?

Offensive Countermeasures(OCM)とは、2009年にSANSインストラクターであるJohn Strand氏らが提唱した概念です。当時はあまり流行した考え方ではなかったと思いますが、Threat IntelligenceやThreat Huntingへの注目と合わせて、再度注目を集めている概念です。(最近では、SEC550: Active Defense, Offensive Countermeasures and Cyber Deceptionというコースも準備されているようです。)

 今日のブログでは、Offensive Countermeasureとは何か、提唱者の本をもとに読み解いてみたいと思います。

Offensive Countermeasures: The Art of Active Defense (English Edition)

Offensive Countermeasures: The Art of Active Defense (English Edition)

 

OCMの特徴を示すAAAとは?

Offensive Countermeasuresの特徴を表すキーワードとして、AAAが挙げられます。

  • Annoyance(擾乱):攻撃者を妨害・攪乱すること
  • Attribution(特定):攻撃者の帰属を特定すること
  • Attack(攻撃):攻撃者の環境に対して能動的な攻撃コードを仕掛けること

それぞれ具体的にみていきましょう。

Annoyance(擾乱)

Annoyance(擾乱)とは、デセプション技術とよぶことのほうが多いと思いますが、攻撃者のリソースを無駄遣いさせることを意味します。この考え方の背後には、攻撃者がアクションをすればするほど、攻撃を成功させるまでの時間を稼ぎ、検知する機会が増えるという前提に基づいています。

本書では、不要なポートを多数開いているようにだますPortspoofや、Webアプリケーションスキャナが持つクローラー機能をだますためランダムなURLを生成するWebLabyrinthなど様々なデセプション機能が紹介されています。(様々なツールが紹介されているので、具体的なツールは実際に読んでみてください)

Attribution(特定)

Attribution(特定)とは、攻撃者がだれかを突き止めることを意味します。その理由としては、攻撃者を特定することで、どこまで自分たちのリソースを投入すればよいか決めることが可能となるためです。

このカテゴリについては、OSINTや各種ツール(Decloaking Engine・HoneyBadger)など攻撃者を特定するためのツールが紹介されています。

Attack(攻撃)

Attack(攻撃)とは、攻撃者の環境に対して能動的な攻撃ードを仕掛けることを意味します。ただし、ここで注意すべきことはHack Back(やり返し)をするわけではないという点です。むしろ、Attributionをより深いレベルで実施するため、あるいは抑止力を確保するための手法だと述べています(そしてやる場合には、法務担当や経営層とよく相談して合意をしたうえでやるように書かれています)

具体的なツールとすると、攻撃者の端末でスクリプトを動かすことを主な目的として、SET(Social Engineering Toolkit)・BeEF(Browser Exploitation Framework)などのクライアントサイド攻撃を利用をすることが議論が行われています。例えば、攻撃者しか絶対にアクセスしないと推測される場所にBeEFを仕掛けるなどが該当します。

Offensive Countermeasuresの法的側面について

Offensive Countermeasuresはよく誤解されますが、いわゆるHack Backとは異なります。その一方、最後のAttack(攻撃)については特に法的に問題がないかという点について議論がわかれますし、本書でも各読者にて判断してほしいとしています。

ツール群について

本書で紹介されていたようなツールについては、ADHD(Active Defense Harbinger Distribution)と呼ばれる仮想環境があり、こちらにツールがすべて含まれているとされています。興味がある方はこちらを動かしてみるとよいのではないかと思います。

www.blackhillsinfosec.com

まとめ

今回、Offensive Countermeasuresについてまとめてみました。言葉から想定するほどの過激な内容ではありませんでしたが、いずれにしても攻撃者を挑発する側面が少なからずあるため、これを採用するのであればある程度のセキュリティが確保できているという前提が重要だと思います。ただし、今後金融機関などセキュリティが進んでいる分野を中心に断片的にもこういった考え方を取り入れていくのではないかと感じています。

Active Defenseの定義とは?

2018/01/16 一部内容を更新しました。
2018/02/07 一部内容を更新しました。

Active Defenseという言葉をご存知でしょうか?

SANSでもSEC550: Active Defense, Offensive Countermeasures and Cyber Deceptionというコースが用意されていますし、CTI(Cyber Threat Intelligence)とも密接に関わる概念です。

色々調べてみると、いくつか考え方ありそうなので、その考え方について整理をしてみたいと思います。

Wikipediaの定義

Wikipediaによれば、Active Defenseは以下のように定義されています。

Active defense can refer to a defensive strategy in the military or cybersecurity arena.

The Department of Defense defines active defense as: "The employment of limited offensive action and counterattacks to deny a contested area or position to the enemy." This definition does not specify whether it refers to physical actions, or cyber-related actions.

In the cybersecurity area, active defense may mean "asymmetric defenses," namely defenses that increase costs to cyber-adversaries by reducing costs to cyber-defenders. For example, an active defense data protection strategy invented by CryptoMove leverages dynamic data movement, distribution, and re-encryption to make data harder to attack, steal, or destroy. Prior data protection approaches relied on encryption of data at rest, which leaves data vulnerable to attacks including stealing of ciphertext, cryptographic attack, attacks on encryption keys, destruction of encrypted data, ransomware attacks, insider attacks, and others. Three ACM computing conferences have explored Moving Target Defense as a strategy for network and application-level security as well, for instance by rotating IP addresses or dynamically changing network topologies.

Some have defined active defenses as including of deception or honeypots, which seek to confuse attackers with traps and advanced forensics. (中略) Other types of active defenses might include automated incident response, which attempts to tie together different response strategies in order to increase work for attackers and decrease work for defenders.

  

(簡易翻訳)

アクティブ・ディフェンスは、軍事またはサイバーセキュリティの分野における防衛戦略の一つです。

米国防総省は、アクティブ・ディフェンスを「敵に対して戦闘地域や立場を否定するための限られた攻撃行為や反撃の採用」と定義しています。この定義は、物理的なアクションはサイバー関連のアクションに依存せず成立します。

サイバーセキュリティの分野では、アクティブ・ディフェンスは、防御側のコストを削減することで、攻撃者のコストを増加させる防衛方法、すなわち「非対称防御」ともいえます。例えば、CryptoMoveが発明したアクティブ・ディフェンス・データ保護戦略では、データの動的な移動、配布、再暗号化を利用して、データを攻撃、盗難、破壊することをより困難にしています。以前のデータ保護アプローチでは、特定の場所に保存されたデータの暗号化に依拠しているため、暗号文の盗用、暗号学的攻撃、暗号化キーの攻撃、暗号化されたデータの破壊、ランサムウェア攻撃、インサイダー攻撃などの攻撃から非常に脆弱でした。 また複数の学術的な国際会議では、IPアドレスをローテーションしたり、ネットワークトポロジを動的に変更するなど、ネットワークおよびアプリケーションレベルのセキュティの戦略としてMoving Target Defenseという概念が提唱されています。

また、攻撃者をトラップや高度なフォレンジック技術を利用して攻撃者を混乱させるため、デセプション技術やハニーポットを利用することと定義するものもいます。他の定義では、攻撃者の負担を増やし、防御側の作業を減らすために、様々なインシデント対応戦略を自動化インシデント対応につなげていくという考え方も存在します。

定義の整理

Wikipediaでも複数の定義が書かれていましたが、各ベンダー等もActive Defenseについて様々な見解をもっています。Wikipediaや他の情報を参考にしながら、Active Defenseという概念をこの言葉の定義を筆者なりに整理してみます。

私見では、Active Defenseとという言葉の使われ方は、大きく5つの意味に大別されると考えており、読み解いてみたいと思います。

定義1:Auto Response

第一の定義は、振る舞い検知・機械学習などを利用して、攻撃の検知・遮断を自動化していくという意味での定義です幾つかのベンダーソリューションではこの定義が使った機能紹介が行われている様子です。

ただし、個人的にはActive DefenseよりAuto Responseと呼ぶべきだと思います。

定義2:Asymmetric Defenses

第二の定義は、デセプション技術・ハニーポット技術などを用いて攻撃者側の時間を稼ぎ、攻撃者の攻撃コストを高めるという考え方です。Asymmetric Defense(非対称防御)とか、Time Based Securityという考え方で知られています。(Time Based Securityについては、別の記事でまとめますので、そちらをご参照ください。)

Wikipediaでも書かれていたMTD(Moving Target Defense)という考え方は私も初めて知りましたが、この攻撃コストを高めるための一つの進化系だと推察します。

定義3:Threat Hunting

一部の文脈では、Threat Hunting(ログを相関分析などを利用してプロアクティブに分析し、シグニチャなどでは発見できないIOCを分析・導き出す技術)を行うことをActive Defenseと定義しているケースもあります。例えば、EY社の『Enhancing your security operations with Active Defense』ではその文脈で定義をしていると考えられます。

Active Defense is a deliberately planned and continuously executed campaign to identify and help eradicate hidden attackers and defeat likely threat scenarios targeting your most critical assets 

また、SANSも似たような定義を採用していると考えられます。”The Sliding Scale of Cyber Security”という論文でも以下のように定義され、アナリストが積極的に分析を行い、ツールに頼らない防御態勢を意味していると考えられます。

The process of analysts monitoring for, responding to, and learning from adversaries internal to the network

アナリストが内部ネットワークにいる攻撃者を監視し、対応し、敵から学ぶプロセス

また、SANSは独自のActive Cyber Defense Cycleを定義しています。この詳しい内容については、別エントリで整理します。

f:id:security_consultant:20180207214711p:plain

 定義4:Offensive Countermeasures

Active Defenseの文脈では、Offensive Countermeasuresという概念もあります。これは、定義2(Asymmetric Defenses)・定義3(Threat Hunting)に加えて攻撃技術を利用して攻撃者の情報を収集して防御に生かそうと考え方です。この考え方を正確に理解するためには、SANS550 Course AuthorでありOffensive Countermeasuresの提唱者であるJohn Strandの著書が参考になります。

Offensive Countermeasures: The Art of Active Defense (English Edition)

Offensive Countermeasures: The Art of Active Defense (English Edition)

 

 この本については、別のエントリにて議論していますので、よろしければご覧ください。

www.scientia-security.org

CrowdStrike社も独自のActive Defense Modelを提唱しています。基本的にOffensive Countermeasuresに近しい考え方だと考えられます。

www.itpro.co.uk

CrowdStrike社によれば、 「アクティブ・ディフェンスとは、攻撃者のコストとリスクを増大させ、彼らの行動への抑止を試みること」と定義しており、彼らのActive Defense Modelでは4つのユースケースを定義しているそうです。

  • Attack Detection
  • Attribution
  • Flexibility of Response
  • Intelligence dissemination

特に、Flexibility of Response(レスポンスの柔軟性)とは、デセプション、封じ込め、攻撃者リソースの浪費、疑念と混乱を攻撃者に植え付けるなどのアクションを意味し、Intelligence Dissemination(情報の拡散)は攻撃者への是正的・抑止的効果をもたらすと述べています。

定義5:Hack Back

一番過激な定義であり、要するに「やられたら、やり返す」という考え方です。特に、Offensive Countermeasureという言葉の響きからこの定義を連想する人も多いようですし、私もActive Defenseの定義はこの定義だと思っていました。(Offensive Countermeasuresの一部で攻撃という概念が出てくるため、こういった定義になることは無理もないと考えられます。Offensive Countermeasureのエントリーで違いについてても整理を行おうと考えています。)

基本的には、攻撃者にやり返して必要であれば盗まれたデータの破壊などを意図している考え方ですし、米国ではACDC法(Active Cyber Defense Certainty Act・通称Hack Back法)が議会に提出されている実情もあります。この法案によれば、サイバー攻撃の被害者は攻撃者に対して報復をすることを許しているようです。(参考:Revised 'Hack Back' bill encourages 'active-defense' techniques, sets parameters

ただし、この考え方は賛否両論あり、比較的否定的な意見が多いように見受けられます。

securingtomorrow.mcafee.com

www.slate.com

まとめ

Active Defenseは現在注目を集める考え方の一つであると思いますが、まだその定義・考え方にはいろいろな差異が存在すると思いますので、Active Defenseについて議論する際にはどのような意味で使っているのか正確に押させた上で議論することがよいと考えられます。

各規制はセキュリティ診断の頻度をどのように定めているか?

2018/01/09 金融庁関連の話題を追加しました。

少し前ですが、2017年8月にJPCERT/CCが「Web サイトへのサイバー攻撃に備えて」という報告を発表して、セキュリティ診断・ペネトレーションテストの頻度について言及をしています。今回は、各レギュレーションがどのようについてどのように言及しているか整理を行いました。

今回は、各レギュレーションがどのようにセキュリティ診断の頻度を定めているか整理したいと思います。

各レギュレーションが定義する頻度

 各レギュレーションが定義する脆弱性スキャン・ペネトレーションテストの頻度は以下の通りです(間違っていたらすいません)。これを見ると、少なくても年1回はペネトレーションテストをすることが求められていると考えられます。

f:id:security_consultant:20171227214733p:plain

JPCERT/CC

JPCERT/CCは、「Web サイトへのサイバー攻撃に備えて」にて以下のように定義しています。この規制が一番具体的な回数に踏み込んでいると感じています。

(1) 利用製品 (プラグインなど追加の拡張機能も含む) のバージョンが最新であることの確認
 目的:製品の脆弱性を狙ったサイバー攻撃を回避・低減するため
 対象:Web サーバなどの Web システム、Web サイト運用管理用 PC
 頻度:数週間~1ヶ月に1回程度

 

(3) Web アプリケーションのセキュリティ診断
 目的:自社の Web アプリケーションに脆弱性や設定の不備が存在しないか確認するため
 対象:Web アプリケーション
 頻度:1年に1回程度、および機能追加などの変更が行われた時

PCI-DSS

PCI-DSSは、クレジットカードを取り扱う企業が守るべき基準です。これによれば、脆弱性スキャンについて以下のように定義しています。

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades)

また、ペネトレーションテストについても以下のように定義しています。

11.3 Implement a methodology for penetration testing that includes the following:(中略)

11.3.1.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows:

  • Per the defined methodology
  • At least annually
  • After any significant changes to the environment

Critical Security Control

CSCでは、定期的な脆弱性スキャン・ペネトレーションテストを推奨しています。特に、このベストプラクティスでは、Red Team Exerciseについても言及していることが特徴だと考えられます。

www.cisecurity.org

CIS Control 4 Continuous Vulnverability Assessment and Remediation

CIS Control 20 Penetration Tests and Red Team Exercises

NYDFS Cybersecurity Regulation

詳しくは前のエントリーを見てください。

www.scientia-security.org

FFITC Information Security Booklet

FFITCの"Information Security Booklet"では以下のように定義しています。

IV.A.2(b) Penetration Tests

A penetration test subjects a system to real-world attacks selected and conducted by the testers. A penetration test targets systems and users to identify weaknesses in business processes and technical controls. The test mimics a threat source's search for and exploitation of vulnerabilities to demonstrate a potential for loss.(中略)

The frequency and scope of a penetration test should be a function of the level of assurance needed by the institution and determined by the risk assessment process. The test can be performed internally by independent groups, internally by the organizational unit, or by an independent third party. Management should determine the level of independence required of the test.

 

IV.A.2(c) Vulnerability Assessments
A vulnerability assessment is a process that defines, identifies, and classifies the vulnerabilities in a computer, network, or communications infrastructure. Technical vulnerabilities can be identified through the use of scanners and other tools. (中略)

Similar to penetration testing, the frequency of the performance of vulnerability assessments should be determined by the risk management process. Scanners and other tools can be run continuously, generating metrics that are reported and acted upon continuously. Alternatively, they can be run periodically. Vulnerability assessments can be performed internally or by external testers, but they are often run as part of internal testing processes.

MAS TRM

MAS TRM(Monetary Authority of Singapore Technology Risk Management Guidelines)とは、シンガポールの金融庁に相当する政府機関が出している技術リスク管理に関するガイドラインです。これについても、かなり具体的な内容が書かれています。

9.4 Vulnerability Assessment and Penetration Testing

9.4.1 Vulnerability assessment (VA) is the process of identifying, assessing and discovering security vulnerabilities in a system. The FI should conduct VAs regularly to detect security vulnerabilities in the IT environment.

9.4.2 The FI should deploy a combination of automated tools and manual techniques to perform a comprehensive VA. For web-based external facing systems, the scope of VA should include common web vulnerabilities such as SQL injection and cross-site scripting.

9.4.4 The FI should carry out penetration tests in order to conduct an in-depth evaluation of the security posture of the system through simulations of actual attacks on the system. The FI should conduct penetration tests on internetfacing systems at least annually

Penetration Testing Guidelines For the Financial Industry

ABS(The Association of Banks In Singapore)が、Penetration Testing Guidelines For the Financial Industry in Singaporeというガイドラインを出しています。このガイドラインによれば、外部委託先に対して年1回のペネトレーションテストを求めています。

Test Scope iv.

For outsourced environment, outsourcing vendor should also conduct annual penetration testing for their public Internet facing network infrastructures. Outsource vendors are expected to follow the methodology as laid out in this document. 

当局の指針・方針

頻度についてではないですが、「平成29事務年度 金融行政方針について」という金融庁の資料の中で以下のようなコメントが出ています。

大規模な金融機関については、そのサイバーセキュリティ対応能力をもう一段引き上げるため、より高度な評価手法*の活用を促す。また、金融機関に対し金融ISAC等を通じた情報共有の一層の推進を促す。

* 例えば、金融機関(外部ベンダー等の利用を含む)による脅威ベースのペネトレーションテスト(テスト対象企業ごとに脅威の分析を行い、個別にカスタマイズしたシナリオに基づく実践的な侵入テスト)。

ここでいうペネトレーションテストとは、Red Team Operationのようなテストを想定していると考えられます。また経済産業省からは、「情報セキュリティサービスの基準」というサービスの基準を示すガイドライン(?)のパブリックコメントが募集されています。

search.e-gov.go.jp

中を少し抜粋して整理すると以下の通りです。ただ内容を見ると、そこまで厳しい内容というより、基本的な部分に言及していると考えられます。

d(3)脆弱性診断サービス
システムやソフトウェア等の脆弱性に関する一定の知見を有する者が、システムやソフトウェア等に対して行う次に掲げる脆弱性診断サービスを行うサービス業をいう。
ア) Web アプリケーション脆弱性診断
イ) プラットフォーム脆弱性診断
ウ) スマートフォンアプリケーション脆弱性診断

 

2 脆弱性診断サービスの審査基準
(1)技術要件
脆弱性診断サービスを提供しようとする者は、次に掲げる技術要件に該当するものであること。

 ア 専門性を有する者の在籍状況
サービス品質の確保のため、次のいずれかの要件を満たす者を業務に従事させるとともに、要件を満たす者ごとの人数を明らかにすること。

  • 高度資格(情報処理安全確保支援士・CISSP・CISA)のいずれかを有する者
  • 次の専門家コミュニティ(JNSA・ISOG-J・OWASP)における講師又はリーダーの経験を有する者
  • 次の事業(Web アプリケーション脆弱性診断・プラットフォーム脆弱性診断・スマートフォンアプリケーション脆弱性診断)において基準となる日から起算して過去3年間に合計5件以上の実績を有する者
  • サービス品質確保に資する研修を修了している者

イ サービス仕様の明示
サービス品質の確保に資する基準に従って、脆弱性診断サービスが行われていることとともに脆弱性診断の結果の取扱いを明らかにしていること。

(2)品質管理要件
脆弱性診断サービスを提供しようとする者は、次に掲げる品質管理要件に該当するものであること。

ア 品質管理者の割当状況
品質の維持のため、サービス品質の管理に関する担当者を割り当てていること。ただし、当該担当者が専属してサービス品質の管理を行うことを必ずしも求めるものではない。

イ 品質管理マニュアルの整備
品質維持のため、サービス品質の管理のためのマニュアルを整備していること。

ウ 品質を担保する手続等の導入状況
品質維持のため、次に掲げる手続等を行っていること。

  • 脆弱性診断サービスを行った案件について、当該案件に従事した者以外の者が検査実施報告書についてレビューを行っていること
  • 脆弱性診断サービスに従事する者に対して次に掲げる教育及び研修等を実施し又は受講させていること。
    • 診断従事者 年20時間以上の教育又は研修(資格維持のための研修を含む。)
    • 専門家コミュニティにおける活動をしている者 年20時間以上の活動
    • 高度資格を有する者 継続専門教育(以下「CPE」という。)による年20ポイント以上の取得
  • 顧客の情報を保護するための手続を設け、運用するとともに、当該手続について監査を実施することにより実効性の確保がされていること。

まとめ

このようにみると、様々なガイドラインなどで少なくても年1回のペネトレーションテストを求めているようです。内部ルール作成などの参考になればと思います。

脅威の検知レイヤーモデル

(修正履歴)一部追記しました。@  2019.02.10

現在、Cyber Threat IntelligenceやThreat Intelligenceに興味を持っていますが、脅威を検知手法について整理してみました。

時間軸による検知レイヤーモデル

色々な考え方があるますが、検知のインプットは大きく4種類あると考えています。

  • Signiture Based(シグニチャに基づく検知)
  • Behavior Based(振る舞い検知)
  • Cyber Threat Intelligence(脅威情報)
  • Threat Hunting(スレット・ハンティング)

上記の図では、その4つのインプットを時間軸、特性から分類をしています。

f:id:security_consultant:20171213000951p:plain

検知にかかる時間

上記の図にあるとおり、検知にかかる時間を考えるとシグニチャに基づく検知(Signiture Based)が一番早く、スレット・ハンティング(Threat Hunting)が一番時間がかかると考えられます。その理由としては、シグニチャに基づく検知の場合、ブラックリストと照合して該当するものがあるしか否か判断すれば脅威を見つけられます。しかしながら、脅威情報(Cyber Threat Intelligence)スレット・ハンティング(Threat Hunting)の場合、誤検知の可能性や、多く受け取った情報を検証する必要があり、脅威の確定に時間がかかるためです。

受動的アプローチ

図にあるとおり、上の方は受動的かつ自動的なアプローチになり、汎用的・伝統的・原始的な脅威に対抗する技術になります。シグニチャに基づく検知(Signiture Based)の場合、汎用的な脅威しか検知できないという欠点もあります。

能動的アプローチ

一方下に行けば行くほど、プロアクティブ・手動的なアプローチとなり、ユニークかつ最新の脅威に対応する方法となります。上記の図では、脅威情報(Cyber Threat Intelligence)スレット・ハンティング(Threat Hunting)など、能動的に調査・収集をしなければいけない脅威を表現しています。

ちなみにこの二つの大きな違いは、脅威情報を自社で独自に見つけるのがスレット・ハンティング(Threat Hunting)、ベンダー・外部の専門家・同業者の知見を借りるのが脅威情報(Cyber Threat Intelligence)です。

脅威情報(Cyber Threat Intelligence)の場合、ベンダー・外部の専門家・同業者からもたらされる情報を元に脅威を発見する手法であり、最終的には独自シグニチャとして内部のセキュリティに組み込まれたり、次回のThreat Huntingのインプットにもなります。

一方、スレット・ハンティング(Threat Hunting)は自分の環境から脅威・攻撃を発見する方法です。こちらも、最終的には独自シグニチャとして組み込まれたり、脅威情報(Cyber Threat Intelligence)として外部などに共有されていきます。

Security Operation Maturity Model

成熟度の観点からすれば、成熟度が高くなるにつれて上から下へ階層を深めていく必要があると考えられます。

  • 成熟度0
    • 成熟度0とは、検知に関するメカニズム(センサー)が導入されていない状態、あるいは著しく限定的である状態です。この状態である場合、十分な検知は行えない可能性が高いと言えます。
  • 成熟度1
    • 成熟度1とは、検知に必要なセンサーは導入されていますが、基本的には提供されるシグニチャに基づいている状態、言い換えればSigniture Based(シグニチャに基づく検知)という状態です。そのため、流行したマルウェアなどには受動的に対応できるため、インシデント対応プロセスなどを日々走らせる必要があると考えられます。
  • 成熟度2
    • 成熟度2とは、Behavior Based(振る舞い検知)ができる状態です。但し、現在のプロダクトでは往々にして振る舞い検知型のメカニズムが入っていますので、その機能をオンにしておくことでは成熟度1と分類されるべきでしょう。
    • ここでいう「振る舞い検知ができる」とは、振る舞い上白黒判断がつかない内容について、自社やベンダーを活用して判断できるプロセスを持った状態を意味します。
  • 成熟度3
    • 成熟度3とは、脅威インテリジェンスを活用できる状態です。言い換えれば、他社で発生した攻撃の中でまだセキュリティ製品のベンダーが知らない情報(知られればシグニチャとして反映されるため)を取得し、自社でも分析を行い適応有無の判断をできるという状態です。
    • もちろん、何も考えずに反映することも可能ですが、この手のIOCはかなり玉石混合である可能性も高いので、自社で判断するプロセスがあることが重要だと考えています。
  • 成熟度4
    • Threat Hunting(スレット・ハンティング)が行える状態を意味します。各種センサーのログ等を分析し、プロセスとして疑義のある内容や振る舞いを検知できるか状態です。

まとめ

誤解なきように書くと、受動的な検知手法がダメということではなく、確実に脅威を検知する技術という意味では非常に有効な手段です。ここで大事なことは、それぞれの脅威の発見方法・特性を正確に理解し、いろいろな脅威を網羅的にカバーしていくことが重要だと考えています。