314
327

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

OSINTによるセキュリティ情報調査方法まとめ

Last updated at Posted at 2017-05-07

最近(2016年頃)、サイバー攻撃の脅威を調べる方法として、公開情報を活用したOSINT(Open Source INTelligence/オシント)に注目が集まっています。私もトレーニングを受けましたが、かなり奥が深く、使いこなせるには時間と経験が相当必要と実感しているところです。それと同時に、OSINTを活用するためには、基本的なテクニックはオープンで共有するほうが効率的だと感じましたので、ここでは、エッセンスをご紹介したいと思います。

ここでは、ポイントを絞ってまとめていきますので、正しい活用にあたっては、インテリジェンスを専門で取り組んでいる教育機関や企業等の提供するサービスの利用をご検討ください。

前提

  1. ファイアウォールやIPS、WAFなどの遮断機器を導入
    サイバー攻撃の予兆をつかんだとしても、止めることができなければOSINTの効果は非常に小さいです。

  2. ログ取得
    最良のインテリジェンスは、自分が運用しているシステムのログです。外の情報(OSINT)だけでは片手落ちになります。

情報収集

情報ソース

「人的ネットワークに勝るものなし」ですが、便利なサイト・団体がありますのでご紹介。

(2021-06-01追記)
こちらのサイトが多数のOSINT調査サイトをまとめておられます。ぜひご参照ください。

配信型

(後で書きます)

検索型

OSINTでは、見逃し(FalseNegative)を最小にするアプローチをとるため、誤検知(FalsePositive)は多めです。そのため、複数の検索サイトを使って信憑性を高める工夫が必要となります。

  1. OSINT Search Tool
    GoogleやFacebookなど、大体の検索が一度にできます。とりあえず、ここだけでよいでしょう。
    image.png

  2. ThreatMiner
    IPアドレスやハッシュ値など、主にIOC(Indicator of Compromised)を検索できます。
    image.png

  3. IBM X-Froce Exchange
    同上。但し、レピュテーションが古く、誤検知も多い。参考値の一つとして使うこと。
    image.png

  4. VirusTotal
    ファイルやそのハッシュ値をアップロードすると、複数のウイルス対策ソフトで一斉に検索してくれるサイト。アップロードしたファイルは誰でも見れるようになるので、営業秘密をアップロードしないように注意(笑)

  5. Shodan
    自組織のIPアドレスを入力することで、攻撃者からどのように見えているのか知るためのサイト。

  6. DomainTools
    高機能版whois。レピュテーションも調べられます。Irisというサービスは可視化性能が高いです(有償)。

  7. RecordedFuture
    有償ですが、産業別・時系列別・攻撃傾向別など、様々な切り口で脅威分析できます。特に、特定キーワード(会社名)を指定して、未来のイベントを可視化する機能は、対策の計画を練るときに大変役に立ちます。年500万円とかなりお高いことがネックです。

  8. have i been pwned?
    メールアドレスが漏洩しているかどうか検索できるサイト。

ツール紹介

  1. Maltego
    デファクトな関連情報自動検索ツール。PCにインストールするタイプのツールです。構造化データなら、AI(?)がなくてもこれで十分。複数のインテリジェンス提供サービスとのAPIがあるため、網羅的に検索できる。
    image.png

  2. OSINT tools security auditing
    Pythonで書かれたOSINT検索ツール。結構便利そう。

  3. SpiderFoot
    OSINT系を自動で検索・集めてくれるプラットフォーム。

その他

たくさんありすぎます。インデックスサイトを置いておきますので、そちらをご参照ください。
https://i-sight.com/resources/101-osint-resources-for-investigators/

収集における注意点

  • 目的は「敵意性(Adversary)」や「TTPs(Tactics, Technologies, Procedures)」の特定。
    すぐに変わるIPアドレスやハッシュ値がほしいのではありません。情報としては大切ですが、それらを過度に追い求めないようにします。

  • 汚れた情報の排除
    分析段階において、誤った情報は誤った結論を導きます。誤った情報の排除は大変手間がかかるので、収集には気を付けましょう。特に、素人からの情報は大体間違っていますので、真に受けてはいけません。(例:「何もしていないけど、パソコンが壊れたの!」)

  • 「事実(Fact)」と「推測(Assessment) 」の分離
    大本営発表(ベンダーの公式発表やマスコミなど)は、ある側面しか映しません。情報収集するときは、自分自身で確認したもの以外は、すべて「推測」情報として扱いましょう。
    (例:DoSの脆弱性として発表された脆弱性は、実はExploitに使える脆弱性だった)

情報分析

得られた情報同士を比較して、攻撃者やそのTTPsを特定します。必要に応じて、IPSやWAFなどのチューニングをしたり、侵入の痕跡がないか、過去のログや現在のシステムの動作状況を点検します。

##コツ・注意点

  • 複数名で行うこと
    一人で分析をすると、思い込みが強くなっていって、正しい結論を導けない可能性があります。複数名で分析することで、ディスカッションが生まれるようにします。この時、処遇評価を行える権限のある人(あるはそれに近い人)を参加させないように注意します。

  • フレームワークを使うこと
    思い込みをなくすために使いましょう。「知っていること」を整理するのと同時に、「知らないこと」は何であるかを明らかにしておきます。但し、フレームワークに定義できないものもあることを認識しておきましょう。そうしないと、無理やりフレームワークに収めて結論を誤ったり、情報を落とす可能性があります。検討状況はリアルタイムでわかるようにしたいですが、最終結論は急がないように。

  • カウンターインテリジェンスに気を付けること
    攻撃者も陽動してきます。頭の片隅に、そのことも意識しながら分析しましょう。上級者向けのテクニックとして、Deception(おとり)をシステムに組み込んでおくのも良いです。うまくいくと、攻撃者のPlaybookから外すことができます。(例:hostsファイルにダミー用の情報を書いておく、とか)

  • Common情報に気を付けること
    分析の過程で、公開プロクシのIPアドレスや枯れたマルウェアのハッシュ値だったり、そういったものが見つかります。それらはどの攻撃者(スキル高低問わず)も使いますので、それらを細かく調べても、特定の攻撃者にはたどり着けません。目を向けすぎないように注意しましょう。特徴となりえるものを探しましょう。

フレームワーク

好きなものを使いましょう。

  • Cyber Kill Chain
    ロッキードマーチンが開発したフレームワーク。サイバー攻撃を軍事行動と見立てて、サイバー攻撃の一連の流れを整理したもの。攻撃の進行度や対策のポイントの整理ができます。
    image.png

  • Diamond Framework
    ひし形の頂点に、脅威の関係者を埋めていくタイプのもの。前述のKill Chainと組み合わせるとよい。(但し相当難しい)

image.png

  • Veris Framework
    ベライゾンが開発したモデル。4つのA(action, asset, actor, attribute)で説明する方法で、脅威を記述・共有するためのモデル。目に見えるものが多いため、一般の人にはわかりやすい。

情報記録・報告・共有

好きなものを選択しましょう。ツールもあるようですが、現在調査中のため、まとまったらどこかでご紹介します。

表記方法

メジャーなものを3種類ご紹介

  • STIX 1.0
    XML形式で、IOCを表現するもの。FS-ISAC(金融機関のセキュリティ情報交換の集まり)や商用のインテリジェンスでは、この形でフィードされることが多いです。ある程度表現に自由度があるので使い方がむつかしく、また、XML形式なのでビューアがないとちょっと読みにくいです。

  • STIX 2.0
    STIX 1.0の欠点を補正したJSON形式のモデルです。1.0と2.0の比較はこちら。
    https://oasis-open.github.io/cti-documentation/stix/compare
    イメージはこんな感じ。結構使いやすそうです。
    image.png

  • Yara
    オープンソースのIDS/IPSであるsnortの定義ファイル形式。
    STIXとは異なって、脅威そのものではなく、IDSに投入するレベルに落とし込んだIOCの表現方法。特徴は、confidence(確からしさ)を設定できること。攻撃の方法は絶えず変化するので、confidenceを75%くらいに設定して、ルールを運用するとよいそうです。

コツ・お作法

  • TLP (Traffic Lamp Protocol)
    情報の共有範囲を指定する共通のルール(紳士協定)です。種類は約4種類あって、Red、Amber/Yellow, Green, Whiteです。Redと書かれた情報をもらった人は、それ以上展開不可となります。また、もし、Whiteであれば、一般公開情報ということで、自由におしゃべりしてもOKです。

  • 専門家ネットワークを使う
    情報収集のときと同じように、専門家同士で行いましょう。話をする相手がいなければ、osada宛てにメッセージください。

意思決定

組織の根幹であるリスク管理に相当する事項のため、分析で得られた知見の使い方については、一意の正解はありません。ここでは、基本的な注意点をご紹介します。

誤謬

論理展開で注意すべき事項です。Wikipediaがとてもよくまとまっていますので、そちらを一読ください。
https://ja.wikipedia.org/wiki/%E8%AA%A4%E8%AC%AC

(例)間違ったジレンマ
選択肢をいくつか提示し、それ以外に選択肢がないという前提で議論を進めること。例えば、多重債務者の「このまま借金取りに悩まされる人生を送るか、自殺するか、二つに一つだ」という思考(自己破産という選択肢を除外している)。

手帳に貼っておきたいクオリティです。

特に避けたい誤謬

  • Middle ground earth(中間着地)
    ぼく「この攻撃は、〇〇〇(ロシアのギャング)によるものでしょう。」
    同僚「いやいや、×××(アノニマスの一過性のキャンペーン)によるものじゃない?」
    上司「あいだをとって、〇〇〇がxxxにのっているんだろう。様子見しよう。」
    ぼく・同僚「(関係を証明できるものはあるの??)」

  • 立証責任の転嫁
    同僚「この攻撃は、〇〇〇(ロシアのギャング)によるものです。」
    ぼく「違うと思います。」
    上司「ぼく、それを証明しなさい」
    ぼく「(白目)」

  • 悪魔の証明
    ぼく「ウイルス感染はありませんでした。」
    上司「それを証明してください。」
    ぼく「(ないものをどうやって証明するの・・・)」
    ※大体、ウイルス対策ソフト(権威)が見つけられなかったというログが証拠になりますが、そもそも、ウイルス対策ソフトも見逃すことが多いので、意味ないですよね(笑)更なる証明が必要になります。よって、こうならないためにも、悪魔の証明を求められるような報告をするべきではありません。(同時に、報告を受ける側は、それを知っていて、悪魔の証明が可能になるような報告を求めるべきではありません。)

  • 沈黙の合意
    ぼく「この攻撃は、〇〇〇によるものと考えて間違いないでしょう」
    一同「・・・」
    ぼく「よし、じゃあ、そこからくる通信を全部遮断しよう」
    ※だれも賛成も反対もしていない状態で、意思決定する

  • 時間優位
    ぼく「もう5時間も、ずーっと言ってるけど、攻撃手口はxxxだって!」
    一同「わかったわかった・・・、それでいい・・・」
    ※根負けして、変な結論に着地すること。

  • 被害者を責める
    ×:ウイルス感染したヤツはけしからん!
    〇:ウイルスを作ったヤツはけしからん!
    ※セキュリティの仕事ってなんでしたっけ?

認知バイアス

バイアスには色々ありますが、セキュリティ分野で意識したほうが良いものは、この認知バイアスです。経験を積めば積むほど、バイアスで苦しみます。経験を積む前から、意識しましょう。また、バイアスにかかっている人を見つけたら、教えてあげましょう(本人には悪気はなく、気づいていないのです)。

  • 確証バイアス
    正しいと思う証拠ばかり集めようとすること。反証材料を集めないこと。
    例:「情報漏洩は絶対ウイルスの仕業である。ウイルスのログがあるはずだ。内部不正であるはずがない。」

  • アンカリング
    最初に得た情報を過度に大きく評価してしまうこと。
    例:「SANSのトレーニングでOSINTを最初に学んだので、OSINTのやり方はSANSのやり方が正義。」

  • 確率バイアス
    確率の観点から、特定の仮説をサポートすること。
    例:「前回の攻撃は日本からだったから、今回の攻撃もそうだろう。」

  • 正常性バイアス
    正常な状態が続いてほしいという願望からくる思い込み。
    例:「インシデント対応したくない・・・。きっと、これは誤検知だ。」

  • 代表性バイアス
    ステレオタイプ的な発想で、物事をとらえること。
    例:「プログラムのコメントが中国語だから、きっと攻撃者は中国人だ。」

  • xxxバイアス(名前失念)
    現在の環境に基づく前提をもとに、物事をとらえること。
    例:「自国の政府機関が、国内企業を攻撃するはずがない。」

  • 後知恵バイアス
    後からわかる情報を使って、自分を優位に立とうとすること。後出しじゃんけん。
    例:被害を受けて「ほら、やっぱり、俺が言ったとおりじゃん。」

バイアスが係った分析・判断をしないように心がけましょう。事実を淡々と集めて、早とちりせず、仮説検証プロセス(ACH)を進めましょう。

ACH

Analysis of competing hypothesesのことで、対立仮説(帰無仮説含む)を立てながら分析を進める方法です。一定のやり方を決めることで、思い込みを排除することができます。必ず複数人で行うことがポイントです。

  1. 仮説立案
    可能性のある仮説はすべてあげます。すべてあげる理由は、認知バイアスを排除することに意味があります。もう一つ、「自分たちが出した仮説以外」という仮説(帰無仮説)も立てておくとよいでしょう。

  2. 証拠収集
    ある仮説を支持したり、また逆に棄却したりする証拠(反証)を集めます。この時も認知バイアスに注意です。

  3. 分析
    マトリクス(表)を使って、仮説と証拠の対応マッピングを作ります。このとき、例えば、ある証拠が全部の仮説を支持したり、全く指示しなかったりといった偏りが生じたときは、誤った証拠であるか、仮説が十分でない可能性があります。

  4. 精練
    分析で発見した事柄から、仮説とのギャップ分析や追加の情報を集めます(生き残っている仮説だけでOKです)。このとき、証拠が仮説に対してオーバーフィッティングしていないか見ていきましょう。そうなっていた場合、確証バイアスが入っている可能性が高いです。

  5. 棄却
    マトリクスが示す仮説・証拠対応を使って、仮説を棄却します。この時もオレオレルール(バイアス・経験)が入らないように特に注意します。

  6. 受入れ
    生き残った仮説が複数ある場合、証拠の重みづけ(マイナス方向に3段階、プラス方向に3段階程度の計7段階)を、複数のアナリストで行い、どの仮説が最も確からしいか評価します。重みづけの方法は、アナリスト固有のスキルで、方法論はないようです。

  7. まとめと評価
    仮説が棄却されていく理由を整理し、最終結論を導きます。仮説棄却理由は、将来の分析にも使うので、大切に記録しておきます。

どれも暗黙のうちにやっていると思いますので、改めてプロセスを明文化しておくと、バイアスや誤謬に支配されることなく、プロセスとして正しい結論を導くことができます。
但し、たいていの場合、情報が不足していますので、結論を確定させることがむつかしいです。
繰り返しになりますが、Confidenceという概念を使い、FalseNegativeを恐れましょう。そして、最終結論は急がないようにしましょう。

その他

  • ここに記載の内容で被害を受けたとしても、助けることができませんので、自己責任でご利用ください
  • フォレンジックやリバースエンジニアリング、モニタリングなどの取り組みは別の時にご紹介します

参考

以下のトレーニングコース/企業サービスを参考にしています。どれもよいコンテンツですので、ぜひ活用を検討してみてください。

314
327
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
314
327

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?