NFLabs. エンジニアブログ

セキュリティやソフトウェア開発に関する情報を発信する技術者向けのブログです。

無名のセキュリティエンジニアがたった2本のブログ記事からSoftware Designで連載をすることになった (技術編)

tl;dr

  • 前半をサイバー脅威インテリジェンスの理論、後半をハンズオンの形式で全6回の連載をしてきました
  • 連載は現実のインテリジェンス業務をなるべく反映させたものであり、戦術脅威インテリジェンスがアウトプットの中心になります
  • 実態のよくわからないバズワードに飛びつかず、企業は自組織の体制と世の中の脅威を正しく理解するところからはじめましょう

はじめに

本稿は前回の記事「無名のセキュリティエンジニアがたった2本のブログ記事からSoftware Designで連載をすることになった (非技術編)」の技術的内容部分を抜き出したものです。未読の方は先にそちらの記事を参考にしていただいた方が、内容を理解しやすいと思います。

blog.nflabs.jp


前回に引き続き @strinsert1Na です。事業推進部の Defensive チームで脅威インテリジェンスの生成やソフトウェアの開発をしています。
再掲となりますが、Software Design 2022年8月号を以って『今日から始めるサイバー脅威インテリジェンス』の連載が終了しました。

gihyo.jp

本稿は、2022年3月号から2022年8月号までに行った全6回分の連載のアウトラインと、筆者がどのような思いでこの連載を書いたかを綴った怪文書です。「サイバー脅威インテリジェンスにちょっと興味が湧いたから必要なところだけ読みたい」という方や、「連載読んだけど理解できなかったからもう少し詳しい内容を説明してほしい」という方がいらっしゃれば参考にしていただければと思います。

連載のテーマ

非技術編で簡単に触れましたが、本連載のテーマは「セキュリティを専門にしていない人でも馴染みやすく、そして手を動かしながら理解できるサイバー脅威対策」で一貫させてきました。これをテーマと決めた理由には編集さんと相談をして決めたということもありましたが、一番は「経営層/マネージャー/エンジニアすべてが同じ目線で、脅威やその対策を知ってもらいたい」という思いからです。

本連載は多少専門的な内容は含まれてはいますが、初心に返って「きちんと己を知り、脅威を理解する」こと、そして理解をもとに論理的な防御策を考えて適応するというセキュリティの基本を詰め込んだつもりです。連載をきっかけとして、多くの方に以下のような感想を抱いていただけたならば筆者としては喜ばしい限りです。

  • サイバーセキュリティの観点について考え直すことができた
  • 便利なツール・サービスを知ることができた
  • 攻撃コードを見て自分でシグネチャを作成することができた
  • 分析の自動化方法を知ったので業務が楽になりそう

これを機会に、技術を中心に学んでいるエンジニアは戦術(枝葉)だけでなく戦略(根幹)に、そして経営を考えている方はエンジニアが日々分析している戦術の重要性を理解していただければ幸いです。世の中の擦れ違いが少しでも減ることを切に願っております。

全6回分のアジェンダ

上記のようなテーマのもと、筆者は以下のような見出し案を作成しました。

  • 第1回(2022年3月号): サイバー脅威インテリジェンスの理論と分析環境構築
    • 情報って?
    • インテリジェンスって?
    • 実環境とは分離した環境の構築
  • 第2回(2022年4月号): 運用脅威インテリジェンスの概念
    • "攻撃者" に焦点を当てながら脅威を分析するという理論
    • 分析のWhy/How/Who
  • 第3回(2022年5月号): 通信先の調査/分析
    • 戦術脅威インテリジェンスの理論
    • IoC の分類
    • 通信先の調査に有用なWebサービスを通したハンズオン
  • 第4回(2022年6月号): ファイルの調査/分析
    • ハッシュ値の概念
    • ファイルの調査に有用なWebサービスを通したハンズオン
    • 簡単なコーディングによる分析/トリアージの自動化
  • 第5回(2022年7月号): シグネチャの生成
    • シグネチャの概念
    • Yara/Suricata/Sigma ルールを学んで脅威を捕まえる
  • 第6回(2022年8月号): インテリジェンスプラットフォームへの蓄積
    • インテリジェンスプラットフォーム "OpenCTI" の構築
    • これまでに紹介した情報源からの自動情報収集
    • OpenCTI を利用したインテリジェンスの生成と配布

全体をざっくり分けると、第1,2回の『理論編』、そして第3~6回の『実践編』の2部構成となります。「手を動かすことをテーマにしているのに全体の1/3理論はおかしくない?」と感じた方がいらっしゃるかもしれません。

.......おっしゃる通りだと思います。しかし、マルウェアをダウンロードできるサービスや1クリックで攻撃者のサーバへ接続してしまう可能性のあるサービスを紹介する以上、「やってみるとできます」だけを載せるというのはどうも無責任に感じてしまい筆者にはできませんでした。(これは世の中のやってみた系の記事を否定するものではありません。あくまで筆者の哲学です。)
そのため、1回目はしっかり環境を構築する話を、2回目は以降行う分析の目的の話をした結果、どうしても理論の話が多くなってしまったという顛末です。理論編に関してはもう少し短くできたかもしれないな、と今でも反省しています。

3回目以降については、筆者が実務で使用しているツールやWebサービスを通したサイバー脅威分析のハンズオンとなっています。ハンズオンの内容は筆者の所属したマルウェア解析チームおよびインテリジェンスチームでの実際の活動の一部であり、これらを深堀りしていくことでインテリジェンスチームの立ち上げまではできるのではないか、と自負しています。題名の通り、連載を通して多くの方に脅威インテリジェンスに興味を持っていただき、費用対効果の高いセキュリティ戦略をはじめていこう!.....という流れを作ったつもりです。

各回の詳細なテーマとキーワード

第1回: サイバー脅威インテリジェンスの理論と分析環境構築 (2022年3月号)

gihyo.jp

共通認識の整理と事前準備の回です。そもそも「データ」って何?「情報」との違いは? そして「インテリジェンス」の意味は? という言葉の定義や、戦略/運用/戦術という3つのインテリジェンスの抽象度の話をしました。戦略に行くほど抽象度が高い経営層向き、逆に戦術では非常に具体的な防御策の話になります。
手を動かせる内容にするとどうしても話が戦術に固まってしまうのですが、エンジニアの方にも抽象度が高い戦略の話を頭の片隅に置いてほしくてこの内容を詰め込んでしまいました。「戦局を左右するのは戦術ではなく"戦略"だ」なんて言葉を黒マントの皇子も言っていましたが、サイバーの世界でも戦略をミスるとそれだけで詰みます。楽しい戦術だけを見つめすぎないようにしましょう。

最後に、以降の連載で手を動かすための分析用環境を構築しました。前節にて述べた通り、慣れていない読者の方々がいきなり戦場に突撃しないための準備です。具体的には、

  • ホストから分離された Virtual Machine の構築
  • ProtonMail を使用することによる匿名でのVPN契約
  • その他、匿名でのWebサービス利用

の準備です。これにて、一通りの事前準備を完了としました。

これは余談ですが、第一回の校正を一通り終えた後に石川朝久さんが書かれた「脅威インテリジェンスの教科書」という本が技評さんから発売されました。クオリティがすごく高い上に前半は内容がほぼほぼ被っており「たいへん厳しい」というお気持ちになりました。(まさかインテリジェンスの例えで天気予報使って説明するところも被るとは思いませんでした。)

ネガティブな気持ちを差し込んでしまいましたが、こちらの本は筆者の連載なんかよりもインテリジェンス業務で参考になる点が詰まっています。興味が湧いた方は是非ともご一読ください。
gihyo.jp

第2回: 運用脅威インテリジェンスの概念 (2022年4月号)

gihyo.jp

個人的に一番書きたかった内容ですが、理論ばかりであまり面白くなかった人が多いんじゃないかなと思います。まず一番初めに語ったのは「中長期的なセキュリティ戦略」を考える上で避けては通れない「費用対効果」の問題です。セキュリティエンジニア界隈にいると世界がセキュリティを中心に回っているように見えてしまいますが、もちろん現実はそんなことはなく、その事象が果たして予算/稼働に対して見合ったものなのかというのは常に検討しなければなりません。

そして、その後は"攻撃者に焦点を当てて分析をする"というテーマで様々な分析手法を紹介していきました。具体的には以下のようなものです。

  • Cyber Kill Chain
  • CoA Matrix
  • Pyramid of Pain
  • ATT&CK Matrix for Enterprise
  • Analysis of Cometing Hypotheses (競合仮説分析)
  • Dyamond Model

ここで、1番伝えたかったことは「敵の何を知ることで組織の防御に最も貢献できるか」を考えるということです。筆者は攻撃者を分析する視点をミステリーと同じ「動機(Whydunit)/犯行のトリック(Howdunit)/犯人(Whodunit)」と例えますが、一般人が知りたがるのは「誰にやられたんだ」(Whodunit)であり、セキュリティエンジニアが求めるのは「どうして攻撃が成立したのか、どうすれば防御できるのか」(Howdunit)である場合が多いです。しつこく犯人の姿を聞いてくる経営層/マネージャーの方もいらっしゃいますが、「犯人がわかったところで防御の方法が変わらないなら、そこまで追い求める行為は費用対効果に見合っていますか?」ということは聞く側も頭に入れていて欲しいとなぁ思う次第です。

Whoに関わるアトリビューションの話は Neutral8✗9eR (@0x009ad6_810) さんが書いた『サイバー脅威インテリジェンスの非対称性』が面白いので皆さんぜひ読んでみてください。
medium.com

第3回: 通信先の調査/分析 (2022年5月号)

gihyo.jp

Pyramid of Pain と絡めた IoC の説明を簡単にした後、URL,domain,IPアドレスを起点とした通信先の調査の話をしました。深く分析するというよりも悪性かどうかをトリアージすることに焦点を当てています。キーワードとしては、以下のようなサービスがあります。

  • URLhaus (マルウェアの通信先)
  • PhishTank (フィッシングURLの調査)
  • GreyNoise (ネットワークスキャンの調査)
  • VirusTotal Graph (1つの通信先を起点とした関連性分析)
  • urlscan.io (ウェブクローラーサービス)

この回から触って試すのが中心になるので、直感的に理解/分析しやすい内容が多かったのではないかと思います。

第4回: ファイルの調査/分析 (2022年6月号)

gihyo.jp

ハッシュ値の説明およびハッシュ値を起点としたファイルの悪性/良性判定をすることをメインに説明した回です。調査に利用したサービスは以下になります。

  • MalwareBazaar
  • Intezer Analyze
  • ANY.RUN

さらに、ファジーハッシュ(imphash, ssdeep)を利用したファイルの類似度判定を行い、ハッシュ値は異なるけれども内部構造はほぼ同じのEmotetを検知する手法もやってみました。しかし、ちょうど執筆=>連載までの間にEmotetの初期感染フローがOfficeファイル=>LNKファイル形式に変わってしまったことにより、すぐ実践できない内容となってしまったのが悲しかったです。

第5回: シグネチャの生成 (2022年7月号)

gihyo.jp

TTPs (Tactics, Techniques, and Procedures) を学び、それを特徴としたシグネチャルールを記述して脅威を検知する内容です。全6回を通して最も実践的で、応用の効く面白い内容だったのではないかなと思います。キーワードは以下です。

  • Yara (ファイルに対するシグネチャ)
  • Snort/Suricata (ネットワーク通信に対するシグネチャ)
  • Sigma (ログに対するシグネチャ)

特に、Sigma を扱っている記事はまだ少ないイメージなので、この機会に勉強してみたい方はぜひ読んでみてください。Sigma はルールを書いた後にそれを検証することが難しく感じるかもしれませんが、今はYamato Securityさんが公開しているHayabusaを使用すればElasticsearchやSplunkを立てなくてもローカルだけで Sigma ルールの検証ができます。便利なのでこちらも併せて使ってみてください。

github.com

第6回: インテリジェンスプラットフォームへの蓄積 (2022年8月号)

gihyo.jp

これまでの情報をインテリジェンスプラットフォームに一元的に収集する、総まとめの内容です。それっぽい画面やグラフを見ながらGUIで直感的に操作していくフェーズなので、「あ、なんかアナリストっぽいことしているかも!」と感じることができたのではないかなと思います。

インテリジェンスプラットフォームの紹介では多くの場面でMISPが登場しますが、今回は筆者のインテリジェンスチームが愛用している OpenCTI をご紹介しました。
www.opencti.io

OpenCTI はコネクターを docker-compose.yml に追記するだけで情報源の追加/データのエンリッチを簡単に行うことができるため、非常に拡張性が高いのが特徴です。

OpenCTI Dashboard

バックエンドが Elasticsearch で動いているのでデータ量の割に検索が早かったり、内部で扱っているデータがSTIX2で管理されているため直感的に扱いやすかったりと優れている点が多いのですが、筆者はまだ日本で使用している組織を聞いたことはありません。「MISPちょっと重いんだよねー」といった悩みを抱えている方々には現在布教中ですので、皆さんこの機会に試してみてください。

実際現場のサイバー脅威インテリジェンス業務ってどうなの?

「脅威インテリジェンス」って情報の価値を 100 に近づけていくイメージを最初持つけど、やってみると 60 くらいのものをなるべく手早くたくさん出すって感じだよねぇ

これはインテリジェンス業務を立ち上げたときの上司の言葉で、筆者も同じような感想を抱きました。本連載を読んでいただいた方には「サイバー脅威インテリジェンスってbellingcatのような調査やダークウェブOSINTを想像していたのにイメージと違った」と思った方もいらっしゃるかと思います。筆者も、そのような活動を想像していました。

しかし筆者レベルのアナリストの腕では、組織に成果としてアピールできるような情報を収集できなかったり、提供されるお客様側もダークウェブから生成したインテリジェンスをあまり求めていなかったりということがわかり、現場では本連載で語ってきたような「戦術脅威インテリジェンス」寄りのインテリジェンスを生成することが中心となっています。(どうしても戦術レベルのインテリジェンスの方が、KPI等で安定した成果を見せやすいというのも一因かもしれません。)
筆者のモチベーションでは「ダークウェブ調査はSNSを起点に情報を拾ってそこから後追いしよう」程度にまで下がっており、きちんとモニタリングしている世の中のインテリジェンスアナリストはすごいなぁと感心するばかりです。これを業務としてできる組織はあるかもしれませんが、それは人的リソースが豊富に用意されている環境だけではないか、というのが筆者の予想です。

これと同じような趣旨の内容は、NTTコミュニケーションズの西野さんが書かれた『サイバー脅威インテリジェンス(CTI)の処方箋』にも記述されています。
engineers.ntt.com

上記の記事に引用さている Bouwmanらの調査 *1 によれば、一般企業が利用しているインテリジェンスの用途として過半数を占めているものは、以下の3つであることがデータとして示されています。

  • ネットワーク上での検知
  • セキュリティ状況の把握
  • SOCの優先順位付け

いずれも戦術レベルのインテリジェンス、つまりは抽象的な分析よりも具体的な防御の指標(インディケータ)として求められているというのが現実ですね。そのためインテリジェンスを生成するアナリストには「PoCから脆弱性を利用した攻撃コードにはどのような特徴があるか理解すること」「OSINTをして通信先/ファイルが本当に悪性の可能性が高いかを判断すること」といった専門スキルが求められ、これらを素早く判定してなるべく多くの脅威をトリアージしていくことがアウトプットとして求められているわけです。(「スキャン元がどのようなbotnetに所属しているかわからなかったけど、SSHブルートフォースの試行をしているから遮断した方がいい」のような、満点とはいかないけれども及第点なトリアージを迅速に行うことをイメージしていただければと思います。)

そして、同様のスキルはインテリジェンスを生成するベンダー側だけでなく我々企業側にも求められます。なぜなら、上のような経緯で生成されたインテリジェンスが、自組織で有効に働くかはまた話が別だからです。こちらで観測された攻撃パケットが異なればもらったシグネチャを単純に適用するだけでは防御できませんし、環境の違いから誤検知が生まれやすいかもしれません。自組織でインテリジェンスを評価できる人材も必要となる以上、一般企業がサイバー脅威インテリジェンス業務として求める役割と人材像というのはこのような形になるのではないかなと考えますし、数年はこの傾向が変わらないのではないかと思います。

おわりに

最近発生したインシデントへの世間からの反応を眺めていると「日本のサイバーセキュリティは遅れている! レベルが低い!!」なんていう発言をポツポツ目にします。たしかにサイバーセキュリティに関する法整備やセキュリティ戦略が他国よりも多少遅れている部分があるとは思いますが、筆者の私見として、日本のセキュリティエンジニアが海外に比べて劣っているなんて感じたことは社会人生活4年を通して全くありません。むしろ、「トップレベルのエンジニアはすごいなぁ」と感嘆する機会の方が多かったです。

問題はできるエンジニアとそうでないエンジニアの差がかなり開いていることと、それ以上にエンジニアとマネージャー/経営層の理解に差がありすぎることだと思っています。世の中には、具体的に何が変わりどのような効果を与えるかについて理解をしていないのにゼロトラスト戦略を打ち出す人や、脆弱性とかTTPsとかよくわからないけどセキュリティ製品/ベンダー、インテリジェンスサービスの言葉を啓示として受け取って運用を回している人がいます。セキュリティエンジニアが集まった飲み会の愚痴を聞くと

  • 犬小屋にまで生体認証つけろみたいな指針打ち出すくせに、従業員端末を管理しているドメインコントローラーを侵害されただけで会社の機密情報までワンパスで通る設計書出してきた
  • IPSにとある脆弱性を検知するシグネチャをベンダーに入れてもらったが、確認されている数ある攻撃パターンのうちのたった2パターンしか検知できないものだった

なんて話を聞くこともあります。企業の経営層や一部のエンジニアもセキュリティ運用についてよくわかっていないですが、じゃあベンダーやサービス側に頼めばその方々はセキュリティを99%理解しているかというとそういうわけでもないというのは、エンジニア/非エンジニアを問わない全ての方に理解してもらった方がいいかなぁと思います。(これはセキュリティ運用を真面目に取り組んでいるエンジニアの多くが感じたことがあるのではないでしょうか?)
巷では「セキュリティ = 保険・オプション」という表現も聞きますが、筆者の認識では「サイバーセキュリティ = 紛争地帯におけるボディーガード」のレベルにまでその必要性と重要性は上がっていると考えています。己の命を他者に全面的に預けてもいいという覚悟がないならば、企業は脅威とリスクを理解してインテリジェンスを施行できる力を保有すべきです。サイバー脅威インテリジェンスがこれら全てを解決できるわけではありませんが、自組織の体制と世の中の脅威を正しく理解するための道具として、検討してみるのはいかがでしょうか。

たいへんお見苦しい怪文書を投下してしまい申し訳ありませんが、サイバー攻撃による日本での被害が少しでも減ることを願い、締めとさせていただきます。


※ NFLabs. はセキュリティを中心とした様々なエンジニアリングを行っています!
これからも皆様に有益な情報を発信していく予定ですので、Twitterのフォローと本ブログの「読者になる」ボタンのクリックをお願いします!! 今回は全面ポエムでしたが、次回以降は技術の話になる予定です。

twitter.com

*1:Xander Bouwman et al., 2020. 『A different cup of TI? The added value of commercial threat intelligence』, USENIX Security Symposium 2020: 433-450. https://www.usenix.org/conference/usenixsecurity20/presentation/bouwman