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

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

ドメイン保護手法に関する整理

ドメインは、企業ブランドを守る上で非常に重要な情報資産です。有名な企業のドメインを乗っ取ることができればフィッシング攻撃などへの悪用は非常にやりやすくなります。

今回は、ドメイン保護手法について、予防・検知・対応の観点から整理をしていきましょう。（参考： ドメイン名のライフサイクルマネージメント）

予防の観点から

まずは、予防の観点から議論をしましょう。

基本戦略

ドメイン保護手法の基本戦略は、基本的に以下の通りです。

自社のブランディングに影響するドメインは取得しておき、他人に取得されないようにする。

以下の記事によれば、Appleなどは240近いドメインを取得しているそうですし、こうしたドメイン管理はブランディング維持の上で重要な役割となります。

domain-girls.guide

とはいえ、該当する可能性があるドメインを全て登録することは現実的ではありません。完璧ではないですが、以下の仕組みで部分的には対応ができるでしょう。

TMCH（商標保護プログラム）

TMCH（商標保護プログラム・TrademarkClearinghouse）に登録して、他社が登録することを防ぐという方法があるそうです。具体的には、商標として登録しておくと、新しいgTLDが出た際に優先的に登録することができるというものです。また、第三者が申請に来た場合、商標保有者に通知してくれるという仕組みです。（Trademark Clearinghouse - Wikipedia）

ムームードメインの説明がわかりやすいために以下に記載しておきます。

muumuu-domain.com

他にも、Donuts社などで提供しているDPML（Domain Protect Marketing List）というサービスがあるそうです。

ドロップキャッチ攻撃への対策

既に取得したドメインがある場合、ドロップキャッチ（Drop Catch）と呼ばれる悪用手法が存在します。これは、有効期限が切れ、誰でも購入できるようになったドメインについて、購入して悪用する手口です。過去良いレピュテーションを持っている場合、フィッシングなどに悪用しやすいため、この手口はたびたび悪用されています。

ドロップキャッチを防ぐためには、基本はドメインの永代供養を基本とします。逆に言えば、使い捨て感覚でドメインを取得することはあまり推奨できません。（日本

日本DNSオペレーターズグループのページに面白い画像があります）

検知の観点から

次に検知の観点から見ると、攻撃者がいつドメインを取得したのか検知できるようにする必要があります。思いつく限り、２つの手法が考えられます。

TMCH（商標保護プログラム）による検知

TMCH（商標保護プログラム）を利用している場合、この登録を軸にアラートを挙げるようにする方法があります。

ツールによる検知

最近では、ツールを利用して、変な登録がないか検知する方法も考えられます。

  • 例１）RiskIQなどの棚卸製品ベースで検知を行う場合
  • 例２）TIP（Threat Intel Platform）を利用して検知を行う場合
  • 例３）DomainTools PhishEyeなどを利用する。

個人的には、Domain Toolsを活用した方法が有益ではないかと考えています。

Domain Toolsとは、DNSレコードを記録しているデータベースで、過去の登録情報などを追いかけることができます。そのため、Domain Tools Irisという主力製品は、Threat Intelligenceの調査などによく使われます。例えば、あるC2通信に使われていたドメインがどのIPに過去紐づいていたか、どんな登録情報を持っていたかを調査するために使われます。

最近では、当該データベースを活用して、Phishyなドメインを探すというDomain Tools PhishEyeというサービスを始めています。こうしたツールは、検知の観点から非常に有益なのではないかと考えています。

対応の観点から

対応の観点では、既に誰かに奪取されたドメインを取り換えすという作業がメインになります。おれは、レジストラなどと協力して行う対応方法ですが、有効な手段として　二種類の方法があることを知っておくことが重要だと思います。

ドメインを取り戻す手法（UDRP）

UDRP（Uniform Domain Name Resolution Policy）と呼ばれる方法で、ドメインを実際に取り戻す方法です。但し、ある程度時間がかかるため、あくまでも積極的に取りたい手段ではないかと思います。なお、JPCERT自らドメイン名紛争処理をした時の内容がブログに乗っているため、参考として読まれると良いかと思います。

ドメインを停止させる（URS）

URS（Uniform Rapid Suspension）と呼ばれ、ドメインを一時停止する機能です。

JPNICの記事では、以下のように説明されています。

インターネット用語1分解説～Uniform Rapid Suspension (URS)とは～ - JPNIC

申請受領後の事務的なチェックが済み次第、 24時間以内にドメイン名の登録内容がロックされ、 ドメイン名の移転やレジストラ変更等ができない状態になります。 その後、裁定で申請者の主張が認められれば、当該ドメイン名の利用が差し止められ、 そのドメイン名を持つWebサイトなどにアクセスしても、 利用差し止め中である旨を表示する紛争処理機関のWebサイトにリダイレクトされるようになります。

 まとめ

予防・検知・対応の枠組みで考えると、万が一変なドメインを取られても取り返すことは可能だと思われますが、まずは適切な予防策を取ることが非常に重要だと思われます。

また、上記以外にも保険的対策として考えらえる方法はいくつか挙げられます。但し、実際に使ったことがある方法ばかりではないので、対策の検討案の参考としてご検討いただければと思います。

  • 検索エンジン会社に申請して、検索エンジンに引っかからない、あるいは Safe Browsingなどに登録してもらうように働きかける。
  • ブラックリストエンジンなどに登録する。（例えば、https://www.phishtank.com/など）
  • EV-SSL証明書を使って、サイトの真正性を証明し、それ以外については自社でないことを宣言する。
  • サービスで利用しているドメイン名リストを公開する。

TLPT・TIBERに関する動向まとめ

金融庁より、TLPT（Therat-Lead Penetration Test）というキーワードが登場してきています。また、TIBER（Threat Intelligence Based Ethical Red Teaming）という概念が欧州系金融系を中心に話題になっています。

今回は、その動向と読むべき資料について整理をしたいと思います。

背景

2018年7月に発表されたNISC（内閣サイバーセキュリティセンター）の「サイバーセキュリティ戦略2018」では以下のように言われており、「脅威ベースのペネトレーションテスト」が登場しています。

金融庁において、大規模な金融機関に対して、そのサイバーセキュリティ対応能力をもう一段引き上げるため、「脅威ベースのペネトレーションテスト（テスト対象企業ごとに脅威の分析を行い、個別にカスタマイズしたシナリオに基づく実践的な侵入テスト）」等、より高度な評価手法の活用を促していく。

一方、金融庁でも「平成29事務年度 金融行政方針について」という資料で以下のようなコメントを述べています。

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

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

また、海外のペネトレーションテストについて研究レポートを提示し、TLPT（Threat-Lead Penetration Test）という概念を提唱して海外動向についてまとめています。

その中で、いくつか知っておくべき付随する概念があるので今回はその概念をまとめておきたいと思います。

専門用語の定義

その前に、いくつか言葉を整理しておきましょう。但し、それぞれの言葉の定義はあくまで筆者が実務や文献をもとに考える定義になり、企業によっては別の意味・別の範囲で使っていることも多いので注意しましょう。

脆弱性スキャン（Vulnrability Scan・Vulnrability Assessment）

Nessus、Qualys、Nexposeなどの脆弱性スキャナを使った機械的なプロセスのことです。少し前にCyber Hygiene（サイバー衛生）という単語が登場し、いわゆるパッチ管理や適切なパスワード管理などの基本動作を徹底する意味で使われていましたが、その一つとしても挙げられる項目だと言えます。海外では、VA（Vulnerability Assessment）と呼ばれますが、多くはこのことを指しています。

セキュリティ診断（Security Assessment）

セキュリティ診断とは、脆弱性スキャンの実施に加え、手動診断を行うイメージです

脆弱性スキャン＋手動テスト（追加テスト and/or 誤検知の排除）

手動診断を行う目的は様々ですが、Webアプリケーションなどの場合は手動でしか発見が難しい仕様・設計関連の脆弱性を洗い出すために、プラットフォーム診断の場合はスキャナの結果に対する誤検知排除などが挙げられます。セキュリティ診断の目的は、「脆弱性を全て洗い出すこと」を目的とした行為になります。

ペネトレーションテスト（Penetration Test）

ペネトレーションテスト（侵入テスト）は、攻撃者の視点から脆弱性の悪用可否を検証し、あらかじめ定義した目的（例えば、クレジットカードの漏洩）を達成できるか否か検証するテストです。ペネトレーションテストの場合、基本的なゴールはフラグ（多くの場合、カード情報・個人情報）を奪取できるかどうかが基本的なゴールになりますので、発券される脆弱性の網羅性はあまりスコープでなく、あくまでたどり着くまでの道筋があるかどうかを検証することに焦点が挙げられます。

Red Team Operation（Adversary Simulation）

Red Team Operationはペネトレーションテストの類似した概念です。一部のベンダーは同じ意味で使っていたり、マーケティング用語として了されているケースも多いですが、少し定義を当ててみたいと思います。

以下に、私が挙げるRed Team Operationの定義です。

  1. 攻撃者の視点 ＋ 脅威（攻撃シナリオ）ベースで目的の達成有無を検証するテスト。そのため、脆弱性は利用することが目的であり、脆弱性の網羅性はない。
  2. 評価の最終ゴールは、ビジネスに対する影響評価。
  3. 組織の耐性・回復能力（Resilience）も含めて評価する。言い換えれば、技術的なセキュリティ対策のみならず、プロセス面などを含めた評価になる。そのため、Blue Teamへ通知することなく、Security OperationとIncident Handlingを含めて評価を実施する。
  4. 上記の目的のため、実施時間帯を２４時間いつでも攻撃可能な前提とすることが多い。

Red Team Operationの重要な点として、具体的なTTPs（Tactics, Techniques and Procedures）をもっている攻撃者を想定し、攻撃シナリオを明確にして実施をすることを前提としています。また、最終的には「ビジネスへの影響を評価する」というゴールであるため、セキュリティ運用チームなどの対応を含めたり、２４時間いつ攻撃されることも前提に、単純な製品ベースの対策ではないプロセスを含めたテストのスコープに含まれると言えます。

金融庁が提示しているTLPT、これから説明するTIBERについてもこの概念を前提として構築されていると考えます。

TIBER

金融庁のレポートでは、ECB（欧州中央銀行）が提示したTIBER（Threat Intelligence Based Ethical Red Teaming）という概念を紹介しています。

TIBERについて具体的なレポートは執筆時点で２つあります。特に最初の資料については、どのようにTIBER-EUを進めていくべきなのか、比較的プロジェクト計画や進め方を定義したような内容で一読する価値がありますが、基本的にはRed Team Operationを意識していると思われます。*1

  1. TIBER-EU FRAMEWORK (How to implement the European framework for Threat Intelligence-based Ethical Red Teaming)
  2. TIBER-EU Framework（Services Procurement Guidelines）

なお、ECBが発行しているものは厳密にはTIBER-EUと呼ばれ、それを各国の基準も含めてカスタマイズしたものがTIBER-XXとして別途定義され、有名なものとしてTIBER-NLが挙げられます。

CBEST & CREST

CBEST & CRESTとは、イギリスで主流となりつつある基準＆資格です。個人的には下火になると思いあまり注目していなかったのですが、日本でも少しづつ注目されています。（現時点での整理とドキュメントのリンク整理を目的としています。）

CBEST

CBESTとは、イングランド銀行（BOE：Bank of England）が出したTLPTを実現するためのフレームワークです。詳しくは、以下のサイトに記載されている資料へのリンクがありますが、以下の３資料については読んでおくべきだと思われます。

www.bankofengland.co.uk

CREST

CREST（The Council of Registered Ethical Security Testers）とは、CBESTを実現するための資格団体・業界団体です。CRESTは、非常に４種類のドメイン（Penetration Testing・Threat Intelligence・Incident Response・Security Architecture）に対して、成熟度別の資格を提供しています。（実際に、資格を持ってサービスを提供している会社の一覧が提供されています。）

CRESTはCBESTをベースとしているため、CBESTの紹介資料も含めて読むべき資料をいかに列挙します。

まとめ 

今回の記事では、TLPT（Threat-Lead Penetration Test）に関する海外動向を整理しました。今後の動向を知る意味でも押させておくべき概念の一つといえるでしょう。

ちなみに、今後のテスト動向について著者の考えを整理しておきたいと思います。

現時点で考えられているセキュリティテストの多くは、技術カットで脅威を取られている診断手法です。しかし、技術的脅威の対策が進めば攻撃者はさらに高度な観点から攻撃を仕掛けてくるでしょう。（技術的な攻撃ポイントが前と比べて減ってきたからこそ、Social-Engineering的手法を活用する手口が増えたとも言えるでしょう。）

その動向としては、大きく二つ挙げられます。

技術カットの観点からは、サプライチェーン攻撃などが挙げられます。要するに、対策の進んだ場所をいきなり攻撃をするわけではなく、周辺のベンダー・子会社・海外拠点から攻撃を仕掛け、徐々に内部に侵入する方法です。

一方、攻撃者が注目してくるのはビジネスプロセス（Business Process）だと思われます。BEC（Business Email Compromise）などはその先駆けで、今後はより手の込んだ手法が登場してくるでしょう。そのため、Red Team Operationの次は、ビジネスプロセス指向のアプローチ、BPOAS（Business Process Oriented Adversary Simulation）といったテストが流行してくるのではないかと考えています。

*1:ちなみに、ECBのページにはWhat is cyber resilience?などセキュリティの動向に関する欧州金融機関の考え方が整理されているため、定期的に見ておくと良いと思われます。

色で表すセキュリティ人材

エッセイ

色を使ってセキュリティチームの性質を説明することがよくあります。

例えば、攻撃技術（Offensive Technology）を専門とするチームをRed Teamと呼び、一方、セキュリティ監視やインシデント対応を行うセキュリティ運用チーム（Security Operation）のことをBlue Teamと呼びます。

また、最近では両方の観点を知り、各チームの知見を相互に生かすチームをPurple TeamとかPurple人材と呼ばれるようになりました。

今回は、色を基軸にセキュリティ人材の今後について考えてみたいと思います。

"Orange is the New Purple"

Black Hat USA 2017での講演『Orange is the New Purple』では、開発チームをYellow Teamと定義して、DevSecOpsの流れを踏まえ、Orange TeamとGreen Teamが提唱されていました。（ちなみに、このタイトルの元ネタはNetflixっで提供されている Orange is the New Blackという人気ドラマをもじったものです。）

Orange Team

Orange Teamの定義は、以下の通りです。

Orange Team = Red Team（攻撃チーム） + Yellow Team（開発チーム）

Orange Teamとは、攻撃チームであるRed Teamと開発チームであるYellow Teamを組み合わせてできるチームを指し、開発者が脅威に対するマインドセットをもって開発することにより、バグの作りこみを避けようという考え方です。

Green Team

Green Teamの定義は、以下の通りです。

Green Team = Blue Team（防御チーム）+ Yellow Team（開発チーム）

Green Teamとは、防御チームであるBlue Teamと、開発チームであるYellow Teamを組み合わせてできるチームを指し、開発者がインシデント対応やフォレンジックの考え方を持ってもらい、セキュリティ運用がしやすい開発を行ってもらうという考え方です。

White人材という考え方

『Orange is the New Purple』ででてくる考え方も面白いですが、私個人としては、今後三原色の考え方に倣い、White人材という考え方を提案したいと思います。この考え方自体は、2017年のRSA Conferenceで発表された、Business Driven Securityという考え方に比較的近いと思います。

it.impressbm.co.jp

私が想定している人材は大きく３種類を基本とします。

  • Red人材：セキュリティ診断やペネトレーション診断などの攻撃技術に精通する人材
  • Blue人材：セキュリティ監視やTherat Hunting、フォレンジックなどの防御技術に精通する人材
  • Green人材：ビジネス目線・マネジメント目線を持ったコンサルティング技術に精通する人材

Red人材・Blue人材は、今までの定義と変わらず、両方の技術に精通している人材はPurple人材と呼ぶ想定です。特徴として、この両人材は基本的に技術を中心としています。

Green人材とは？

Green人材とは、聞きなれない名称なので説明を付け加えておきたいと思います。

Green人材とは、マネジメント目線やビジネス目線など、ソフトスキルを専門とする人材です。こうしたスキルは今後よりいっそうセキュリティ人材に求められると思います。なぜならば、基本的にビジネスプロセスも攻撃対象になる上、セキュリティを実現し、ビジネスプロセスを踏まえてセキュリティを組み込むためには、予算・リソース・他部署の協力の面から、マネジメント目線で話を説明し、巻き込んでいかなければならないためです。

いわゆる、セキュリティコンサルタントの中で技術コンサル系ではない人、ポリシーやセキュリティ戦略などを専門にする人はこの分野に基本的に属すとみなすべきでしょう。

私が思うGreen人材が持つべき特徴をいかに示します。

特徴１：ビジネスプロセスに精通した人材

第一に、Green人材に求められる条件として、ビジネスプロセスに精通していることが挙げられます。例えば、BEC（Business Email Compromise）などは、ビジネスプロセスを悪用した攻撃の一種です。今はまだプロセスが稚拙な場合に成立している攻撃である印象はありますが、Social-Engineeringなどの技術を使っていけば、こうしたより複雑なビジネスプロセス上の欠陥をつく攻撃が出てくるでしょう。あるいは、米軍需産業の例におけるサプライ・チェーン攻撃もその一つでしょう。技術という目線だけではなく、自分達を取り囲むサプライチェーンやプロセスなどを悪用した攻撃です。

一方、最近では金融庁が提唱しているTLPT（Threat-Led Penetration Test）やTIBER（Threat Intelligence Based Ethical Red Teaming Test）などが挙げられます。ここで想定している脅威は技術的脅威ですが、技術的脅威での攻撃が難しくなった場合、今度はビジネスプロセス上に脅威を向けてくると考えられます。

特徴２：マネジメントに精通した人材

第二に、Green人材に求められる条件として、マネジメントに精通した人材が挙げられます。ビジネスプロセスに何かセキュリティ施策を盛り込んだり、上層部と交渉をしたりする際に適切な言語でリスクや投資の必要性について会話をする必要があります。そのため、Green人材はこうした能力が求められます。

また、マネジメントの観点から、セキュリティ戦略やポリシーの策定についても必要があります。

特徴３：コンサルティング技術を要した人材

第三にコンサルティング技術を要した人材が挙げられます。Red Team・Blue Teamに対して、あるいは経営層に対して問題を提案し、解決策への道筋をつける能力が求められます。

結局、White人材とは？

White人材の定義は、以下の通りです。

White人材 = Red人材 + Blue人材 + Green人材

技術的には、攻撃技術＋防御技術に精通しつつ、ビジネスプロセスやマネジメントの側面からプロセスを強化したり、セキュリティ戦略を立案したりする人材です。こうした人材になることにより、ビジネス・リスクとしてセキュリティを考えることができるでしょう。

まとめ

セキュリティ人材も様々な分野が存在します。もちろん一分野に特化するスペシャリスト型も存在する一方、複合型を目指す人材のジェネラリスト型のキャリアパスも考えられます。基本的には、どこに自分の強みを持つのか、という点でキャリアを考える上での一助になればと思います。

BSides Tokyoが開かれるらしい

カンファレンス・研修

LinkedInのブログでたまたま見つけましたが、BSides Tokyoが開かれるらしいです。

www.linkedin.com

bsides.tokyo

BSidesシリーズとは？

米国から始まった（？）セキュリティカンファレンスシリーズ群で、各地の発起人が確か一定の条件を満たせば、BSidesという名前を付けて開けるカンファレンスです。（違っていたらすいません...）

米国にいた頃、BSides Charm、BSides Boston、BSidesLV、BSides DC、BSides Philadelphiaなど東海岸を中心に色々と参加していました。個人的に旅行次いでにバスで乗り継いでいったので思い出深いカンファレンス群です。

米国の特徴とすると、以下の通りだと思います。

特徴１：安価な参加費

参加費が非常に安価であるという特徴があります。大体無料から高くても３０ドルぐらい（BSides LVだけは別格で150ドルとかですがBlack Hatと比べれば全然安いです。）なので、非常に参加しやすい特徴があります。

特に有名企業や政府機関がスポンサーに入っている場合、参加バッジやSwag（参加記念品）も豪華で、昼食もサポートされたりします。

特徴２：幅広いコンテンツ

講演は、正直開催される場所や知名度にも大きく依存します。但し、意外と小さいカンファレンスだと、あまりメジャーでない内容でも面白いものも多く、研究活動などをしていると結構参考になるセッションも多い印象があります。

また、講演ではなくトレーニングやCTFに参加することも可能です。BSides DCに行ったときは、Broというツールのトレーニングを受けて非常に勉強になりました。

トレーナーもお金儲けというよりは、コミュニティへの貢献、それに伴うプレゼンスの向上などお金以外のメリットが働きます（米国の流動的な就活市場ではそういったコミュニティへの貢献なども大きな要素となるため）。きちんとインセンティブが働く形になっているため、かなり質の高い講義が受けられた記憶があります。

BSides Tokyoについて

BSides Tokyoも無料らしいです。

日本で開かれるセキュリティ・カンファレンスといえば、AV TokyoやCode Blueなどが有名ですが、ぜひ盛り上がってほしいですね。

 

#ssmjp 04に参加してきました！！

エッセイ

#ssmjp ４月に参加してきました。

ブログ枠で参加したのでアップデートしました。（勘違いして、アップロードできていなかったので、アップロードしました。ご迷惑をおかけしました。）

講演１：私の情報収集法

最初のスピーカーは「タイムライン・インテリジェンス」という情報収集法に関する話でした。「私は昨晩、6時間寝てしまったから、すでに専門家でなくなってしまった」とまで言い切らずに情報収集を行うというコンセプトが面白かったです。

提案されていたポイントは、「時差を利用して、過去・未来にさかのぼるイメージで情報収集を行う」という点にあるかと思います。

  • 未来の話題は、海外ソースで先取り
  • 過去の話題は、「まとめ」を活用

未来の話題

海外の情報で日本で話題になるまでに先取りを行って、話題を先取りする方法です。

海外のニュースは日本の夜に公開されており、翻訳は大体翌日の午前中に公開されるため、朝の通勤電車などでこれらの情報を把握できれば、実質的に情報を先取りすることができるとのことです。

過去の話題

その反対に取りこぼすことも当然あるので、その部分については「まとめ」を活用して情報を一気に吸収する方法です。

補足（質疑の中から...）

  • 一時情報か否かについては、記事の量でその信憑性を図っているとのこと。
  • Twitterはあまり見ていない。
  • ある程度時間を区切ってみている。 

所感

  • 情報収集をうまくやろうとした際に、一番ネックになるのは「現在の情報を正確にいかに押させるか？」、「膨大な情報に呑まれないようにすること」だと思います。この方法を情報収集に取り入れてみたいと思います。

講演２：ペネトレーションテストの資格

北原さんによるペネトレ系資格に関する説明をでした。個人的には、過去記事でまとめた時に調査に挫折した部分を全部きれいにまとめてくれた内容で非常に参考になりました。

米国では、OSCPはペネトレーションテストの品質を保証する重要な資格として位置付けられているので受験に向けて非常に参考になりましたが、それにしてお５６のホストに侵入するとか、報告書をかなり細かく書かないといけないとかハードルが非常に高いですね...（ほかの資格は４択なので、勉強すれば基本的には取れると思います）

www.scientia-security.org

講演３：VyOSで挑むIPv6 IPsec

VyOS Kernelなるものを初めて知ったのですが、VyOSはルータなどを作る際に便利OSだが、本家でサポートが切れているので対応が大変らしいです。今回は、IPv6 IPSecへの対応に関するエピソードでした。

個人的にネットワークにそこまで詳しくないのですが、二分探索法でバグを探すとか思った以上にバグ調査って地道なんだな..と実感させられました。

講演４：なぜSphinxで手順書を作るのか

Sphinxで手順書を作る話（#ssmjpでシリーズ化されている話）でした。Sphinxを使ったことがないので感覚的にわからない部分もあるのですが、便利な側面も多いのですが、一方これの学習コストってどれぐらいなんだろうと思っています。（若干、慣れが必要な記述形式なのではと思っています）

現在、色々ドキュメントを作る作業をしているので少し試してみたいと思います。

まとめ

SSMJPは、いつもユニークなプレゼンテーションが多くいつも興味深く参加しています。もし参加したことがない方はぜひ参加してみると色々勉強になると思います。