標的型サイバー攻撃への対応 - Information Technology ...ª $ ± Ì È 8 w 0 4 Acknowledgments Development Team: Chris Crevits, CISSP, CCNA, Ernst & Young LLP, USA Jose

標的型サイバー攻撃への対応


2

About ISACA®

With more than 100,000 constituents in 180 countries, ISACA (www.isaca.org) is a leading global provider of knowledge, certifications, community, advocacy and education on information systems (IS) assurance and security, enterprise governance and management of IT, and IT-related risk and compliance. Founded in 1969, the nonprofit, independent ISACA hosts international conferences, publishes the ISACA® Journal, and develops international IS auditing and control standards, which help its constituents ensure trust in, and value from, information systems. It also advances and attests IT skills and knowledge through the globally respected Certified Information Systems Auditor® (CISA®), Certified Information Security Manager® (CISM®), Certified in the Governance of Enterprise IT® (CGEIT®) and Certified in Risk and Information Systems ControlTM (CRISCTM) designations.

ISACA continually updates and expands the practical guidance and product family based on the COBIT® framework. COBIT helps IT professionals and enterprise leaders fulfill their IT governance and management responsibilities, particularly in the areas of assurance, security, risk and control, and deliver value to the business.

ISACAとはISACA®（www.isaca.org）は、世界180ヵ国100,000人を超える会員から構成される団体で、情報システムのアシュアランスとセキュリティ、ITガバナンス、システム運用、そしてIT関係のリスクやコンプライアンスにおける、知識、資格認定、コミュニティ作り、支援活動、教育機会等を、グローバルで先導的な立場で提供しています。ISACAは独立の非営利団体として1969年に設立され、国際会議の主催、「ISACA Journal®」の刊行、国際的な情報システム監査およびコントロール基準の開発に従事しており、それらは、情報システムが信頼でき、そこからの価値が得られることを確実にするために、ISACA構成員の手助けをしています。さらに、世界的に高く評価されている公認情報システム監査人 [Certified Information Systems Auditor® (CISA®)]、公認情報セキュリティマネージャ[Certified Information Security Manager®, (CISM®)]、Certified in the Governance of Enterprise IT® (CGEIT®)、そしてCertified in Risk and Information Systems Control™ (CRISC™)などの資格認定を通じ、ITスキルと知識の向上と能力の証明を行っています。

ISACAはCOBIT®を定期的に更新しており、これらは、特にアシュアランス、セキュリティ、リスクとコントロール、ビジネスへの価値提供の分野において、IT専門家や企業の幹部が ITガバナンスと経営責任を果たすために役立っています。

DisclaimerISACA has designed and created Responding to Targeted Cyberattacks (the “Work”) primarily as an educational resource for security, governance and assurance professionals. ISACA makes no claim that use of any of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, security governance and assurance professionals should apply their own professional judgment to the specific circumstances presented by the particular systems or information technology environment.

免責事項ISACAでは、セキュリティ、ガバナンス、アシュアランスの専門家を支援する教材として本書「標的型サイバー攻撃への対応」を出版しています。ISACAは、本書の内容に関して一切の責任を負いません。本書はすべての適切な情報、手順、テストを包括するものではありません。すなわち、均質な結論を生み出す専門的な情報、手順、テストを示すものではありません。いかなる特定の情報、手順やテストの妥当性を決定する際においても、セキュリティガバナンスとアシュアランスの専門家は、特定のシステムや IT環境によって提示された状況に対し、専門家として独自に判断する必要があります。

3

Reservation of Rights© 2013 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of all or portions of this publication are permitted solely for academic, internal and noncommercial use and for consulting/advisory engagements, and must include full attribution of the material’s source. No other right or permission is granted with respect to this work.

著作権© 2013 ISACA. 本著作物の著作権は ISACAが所有しています。本書の一部あるいは全部について、ISACAから文書による事前許諾を受けずに、いかなる方法、いかなる媒体（電子媒体、機械媒体、複写、録音、その他）によっても無断で使用、複製、複写、変更、配布、表示、検索システムへの保存、転送することは禁じられています。本書の一部あるいは全部について、本書の複写および使用は、学術的、内部的、非営利的な目的、およびコンサルティング /アドバイザリー業務に限られ、情報源についてすべて記載する必要があります。その他のいかなる権利や許可が与えられることはありません。

ISACA3701 Algonquin Road, Suite 1010Rolling Meadows, IL 60008 USAPhone: +1.847.253.1545Fax: +1.847.253.1443Email: [email protected] site: www.isaca.org

Provide Feedback: www.isaca.org/CyberattacksParticipate in the ISACA Knowledge Center: www.isaca.org/knowledge-centerFollow ISACA on Twitter: https://twitter.com/ISACANewsJoin ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficialLike ISACA on Facebook: www.facebook.com/ISACAHQ

Responding to Targeted Cyberattacks

　


4

AcknowledgmentsDevelopment Team:Chris Crevits, CISSP, CCNA, Ernst & Young LLP, USAJose Granado, CISSP, America’s Practice Leader, Information Security Services,

Ernst & Young LLP, USAJames O. Holley, CCE, NSA ISSO, NSA ISSP, Ernst & Young LLP, USAPatrick J. Hynes, CISA, CISM, CCNA, CISSP, NSAIAM, Ernst & Young LLP, USADavid C. Kovar, CCE, CISSP, EnCE, GCFA, GCIH, GREM, Ernst & Young LLP, USAMark G. Manglicmot, CEH, CISSP, GCIH, Security+, Ernst & Young LLP, USAAustin J. Murphy, GCFA, Security+, Ernst & Young LLP, USADaniel J. Quealy, CAMS, CIWM, GSEC, HTCIA (past president), NSAIAM, Ernst & Young LLP, USAJoshua Theimer, CISA, CISSP, Security+, Ernst & Young LLP, USABryan C. York, CEH, CISSP, Linux+, Security+, Ernst & Young LLP, USA

Subject Matter Expert Reviewers:Vilius Benetis, Ph.D., CISA, CRISC, BAIP, LithuaniaJeimy Cano, Ph.D., CFE, CMAS, Ecopetrol, ColombiaChristos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., GreeceJo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, BRM Holdich , Australia, DirectorRolf M. von Roessing, CISA, CISM, CGEIT, CISSP, FBCI, FORFA AG, Switzerland

ISACA Board of DirectorsGregory T. Grocholski, CISA, The Dow Chemical Co., USA, International PresidentAllan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK,

Vice PresidentJuan Luis Carselle, CISA, CGEIT, CRISC, Wal-Mart, Mexico, Vice PresidentChristos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice PresidentRamses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, Six Sigma Black Belt, Dell, Spain,

Vice PresidentTony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia,

Vice PresidentJeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice PresidentMarc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice PresidentKenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA,

Past International PresidentEmil D’ Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., (retired), USA,

Past International PresidentJohn Ho Chi, CISA, CISM, CRISC, CBCP, CFE, Ernst & Young LLP, Singapore, DirectorKrysten McCabe, CISA, The Home Depot, USA, DirectorJo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, BRM Holdich, Australia, Director

Knowledge BoardMarc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, ChairmanRosemary M. Amato, CISA, CMA, CPA, Deloitte Touche Tohmatsu Ltd., The NetherlandsSteven A. Babb, CGEIT, CRISC, Betfair, UKThomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USAPhil J. Lageschulte, CGEIT, CPA, KPMG LLP, USAJamie Pasfield, CGEIT, ITIL V3, MSP, PRINCE2, Pfizer, UKSalomon Rico, CISA, CISM, CGEIT, Deloitte, Mexico

5

Guidance and Practices CommitteePhil J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, ChairmanDan Haley, CISA, CGEIT, CRISC, MCP, Johnson & Johnson, USAYves Marcel Le Roux, CISM, CISSP, CA Technologies, FranceAureo Monteiro Tavares Da Silva, CISM, CGEIT, BrazilJotham Nyamari, CISA, Deloitte, USAConnie Lynn Spinelli, CISA, CRISC, CFE, CGMA, CIA, CISSP, CMA, CPA, BKD LLP, USASiang Jun Julia Yeo, CISA, CPA (Australia), MasterCard Asia/Pacific Pte. Ltd., SingaporeNikolaos Zacharopoulos, CISA, CISSP, DeutschePost–DHL, Germany

ISACA and IT Governance Institute® (ITGI®) Af�liates and SponsorsInformation Security ForumInstitute of Management Accountants Inc.ISACA chaptersITGI FranceITGI JapanNorwich UniversitySocitum Performance Management GroupSolvay Brussels School of Economics and ManagementStrategic Technology Management Institute (STMI) of the National University of SingaporeUniversity of Antwerp Management School

ASIS InternationalHewlett-PackardIBMSymantec Corp.

ISACA thanks Ernst & Young for its generous donation of services to develop this publication.

監修新日本有限責任監査法人横川晴良 CISA, CPA新日本有限責任監査法人　大野陽生 CISM, CISA, CISSP, CIA, PMP

翻訳・レビュー新日本有限責任監査法人　小高光雄 CISAErnst & Young Australia　 Richard Keirstead CISM, CISA, CGEIT, CISSP新日本有限責任監査法人　青波久恵 CISA新日本有限責任監査法人　宮崎恵一 CISM, CISA, CFSA, MBA新日本有限責任監査法人　阿部耕平 CISM, CISA新日本有限責任監査法人　国川弓代 MBA

Acknowledgments


6

目次第1章　はじめに ............................................................................................................... 91.1 改革の必要性に関するケーススタディ ........................................................................ 91.2 脅威の進化 ............................................................................................................. 101.3 進化する攻撃経路 .................................................................................................. 131.4 転機 ....................................................................................................................... 151.5 APTのライフサイクル ............................................................................................. 161.6 さまざまな対応策 ................................................................................................... 201.7 まとめ .................................................................................................................... 21

第2章　準備 .................................................................................................................. 232.1 チームの構築と計画の立案 ...................................................................................... 232.2 重要な関係の構築 ................................................................................................... 23

2.2.1 外部との関係 ............................................................................................ 232.2.2 内部との関係 ............................................................................................ 24

2.3 権限の明確化 ......................................................................................................... 242.4 社内で利用されている技術の一覧化 ......................................................................... 252.5 調査プロセスの標準化 ............................................................................................. 262.6 トレーニングとガバナンス ....................................................................................... 28

2.6.1 訓練 ......................................................................................................... 282.6.2 セキュリティプログラムと対応計画の見直し ................................................ 29

2.7 必要不可欠な能力の確立 ........................................................................................ 292.7.1 ホストレベルの活動把握 ............................................................................ 312.7.2 ネットワークレベルの活動認識 .................................................................. 342.7.3 検索 ........................................................................................................ 352.7.4 コンピュータ・フォレンジック分析 ............................................................. 362.7.5 マルウェア分析 ......................................................................................... 372.7.6 サイバー情報収集活動 ............................................................................. 372.7.7 脆弱性の特定 ............................................................................................ 41

第3章　調査 .................................................................................................................. 433.1 セキュリティ侵犯の調査 .......................................................................................... 433.2 誰が攻撃しているのか? .......................................................................................... 473.3 何が標的とされたか? .............................................................................................. 473.4 さまざまな事象はいつ起きたのか? .......................................................................... 483.5 攻撃はどこから来ているのか? ................................................................................. 483.6 なぜ攻撃されたのか? ............................................................................................. 493.7 攻撃者はどのように侵入し、潜伏し、データを持ち出したのか? ...........................................503.8 その他検討が必要な重要分野 .................................................................................. 50

7

3.9 情報収集の質 .......................................................................................................... 513.10 証拠の取り扱い ...................................................................................................... 51

3.10.1 文書の保全と収集 .................................................................................... 523.10.2 証拠保管の連続性 .................................................................................... 523.10.3 MD5ハッシュ値の取得 .............................................................................. 533.10.4 ライトブロッカー ....................................................................................... 533.10.5 レコード数の照合 ...................................................................................... 533.10.6 弁護士・依頼者間の秘匿特権または弁護士のワークプロダクトの秘匿特権 ..........543.10.7 保険金の請求 ............................................................................................ 54

3.11 調査の匿名性 .......................................................................................................... 543.12 調査活動の保護 ..................................................................................................... 55

3.12.1 データ ...................................................................................................... 553.12.2 移動中のデータ ........................................................................................ 55

3.13 調査活動の保護 ..................................................................................................... 553.13.1 認証情報の保護 ....................................................................................... 56

第4章　駆除 .................................................................................................................. 574.1 駆除計画の立案 ...................................................................................................... 57

4.1.1 駆除活動チームの設立 ............................................................................. 574.1.2 駆除活動計画の立案 ................................................................................ 584.1.3 駆除日の決定 ........................................................................................... 594.1.4 攻撃者の戦術、方法、手順の理解 ............................................................... 594.1.5 コミュニケーションプロトコルの確立 .......................................................... 604.1.6 「対策本部（War Room）」の設置 .............................................................. 624.1.7 安全なコミュニケーションと情報共有のメカニズムの確立 ........................... 62

4.2 計画の実行 ............................................................................................................ 634.2.1 パスワード変更 ........................................................................................ 644.2.2 攻撃者による指令・制御のブロック ........................................................... 664.2.3 侵害されたシステムの再構築 .................................................................... 674.2.4 アンチウイルスベンダーへのマルウェアの提供 ........................................... 68

4.3 再侵入活動の監視 .................................................................................................. 68

第5章　駆除後の対応 ..................................................................................................... 715.1 駆除活動の検証 ..................................................................................................... 71

5.1.1 警戒態勢の維持 ........................................................................................ 715.1.2 コントロールの検証 .................................................................................. 73

5.2 利害関係者への状況説明 ........................................................................................ 745.3 教訓 ....................................................................................................................... 755.4 戦略的な変更－サイバーセキュリティ改革 ................................................................ 77

目次


8

第6章　結論 .................................................................................................................. 81

付録A　調査チームが対応するその他の問題 .................................................................... 83

付録B　調査ツール ......................................................................................................... 87

図表一覧図01 ― 10の評価シナリオ ................................................................................................. 10図02 ― 脅威の進化 .......................................................................................................... 11図03 ― 進化する攻撃経路 ................................................................................................ 14図04 ― APTのライフサイクル .......................................................................................... 16図05 ― APTのライフサイクル（別の視点） ......................................................................... 16図06 ― APTの手口 ......................................................................................................... 19図07 ― さまざまな対応策 ................................................................................................ 20図08 ― 基本的なインシデント優先度付けプロセス ............................................................. 27図09 ― アラート決定プロセス ........................................................................................... 28図10 ― CSIRTに求められる能力 ...................................................................................... 31図11 ― サイバー情報収集が攻撃のライフサイクルに与える潜在的影響 .............................. 38図12 ― インシデント対応のプロセス ................................................................................. 44図13 ― インシデント対応のライフサイクル（NIST SP 800-61） ........................................... 45図14 ― 『xkcd』コミック: 「パスワード強度」 ....................................................................... 66図15 ― 事後報告書のテンプレート ................................................................................... 76

第1章　はじめに

9

第1章　はじめに方法を示すのではない。何をすべきかを示すのだ。そうすれば、思いもよらない独創的な解決

策がもたらされるだろう。

― ジョージ・S・パットン著 “War As I Knew It” （1947年）

1.1 改革の必要性に関するケーススタディフォーチュン100社の最高情報責任者（CIO）として、最高経営責任者（CEO）と取締役会に以下のような報告をすることになったと想像してみましょう。

わが社の防衛線は、わずか6分で突破されました。それから12時間も経たないうちにドメイン管理者権限が奪われました。そして1週間も経たないうちに、わが社の30のグローバルドメインのすべてが攻撃者の手に落ちました。彼らは20万以上の認証情報を手に入れ、正規ユーザとしてネットワークにログインできるようになりました―401k（退職金制度）の投資先を変えることも、会社の資金を社外に送金することもできる状況でした。わが社のグローバルネットワー

クの中に、攻撃者がアクセスできない場所はなく、ごく少数の例外を除けば、どのコンピュータ

にも容易にアクセスできました。わが社の製造設備のうち、ファイアウォールでネットワークか

ら隔離されているものは1割しかありません。攻撃者たちは買掛金システムを通じて、わが社の銀行口座から何百万ドルもの資金を電子的に送金できる立場にありました。彼らのツールに

対して、わが社のアラームは無力でした―アンチウイルスソフトウェアも何のアラートも発しま

せんでした。わが社の製造環境は無防備で、生産工程の質も現場の安全もリスクにさらされて

いました。攻撃者は、わが社の最も重要な知的財産にもアクセスできました。具体的には、過去、

現在、将来の主な買収・売却計画、わが社がこの10年間に数十億ドルを費やしてきた研究開発の成果などです。彼らはこれらのデータのすべてを盗み出すことができました。そして我々

には、彼らを止めることはもちろん、彼らがネットワークのどこに潜んでいるのかを見つけること

すらできなかったのです。

背筋の凍るような話です !　しかし、これはEYの顧客である大企業のCIOが、EYの侵入テストチームによる詳細なサイバーセキュリティ態勢評価を受けた結果、自社のCEOと取締役会に実際に報告した内容でした。

評価の項目は多岐にわたりました。目的は、ポリシーがどれだけ守られているかを調べることでも、標準的な慣行や技術的対応策がどれだけ実践されているかを測ることでもなく、フォーチュン100社を狙った攻撃が続いているという事実を受けて、サイバーセキュリティに対するこの企業の態勢を評価することでした。端的に言えば、「わが社が同様の攻撃を受けたとしたら、どうなるか?　的確に対処できるか?　攻撃を困難にするためにはどうすればいいか?　攻撃の進行を検知し、対処するためには、どうすればいいのか?」といった問いに答えることです。


10

チームは攻撃の動機や顧客企業の技術インフラへのアクセス手段などを基に10の評価シナリオ 1を作成し、実行しました（図1）。

図0110の評価シナリオ

「政治目的のハッカー」

悪意あるインサイダー

公開前情報へのアクセス

組み込みシステムへの攻撃

アプリケーションへの攻撃

統制環境リスク低減の優先度付け

不正な電子送金

外部からのDoS攻撃

生産工程システムへの攻撃

買収した企業への攻撃

APT（ネット上でのスパイ）

評価の結果、冒頭で引用したCIOの言葉にもあるように、サイバーセキュリティに対する会社のアプローチを早急かつ抜本的に見直す必要があることがわかりました。インターネットに接続することで企業が直面する脅威は、企業の情報セキュリティアーキテクチャ、技術、プロセスの進化をはるかに上回るペースで進化しているためです。

インターネットに接続することで企業が直面する脅威は、企業の情報セキュリティアーキテクチャ、技術、プロセスの進化を

はるかに上回るペースで進化している。

1.2 脅威の進化図2は、サイバー脅威の進化の過程（実験→嫌がらせ→金銭目的→産業スパイ→サイバー兵器）を示したものです。

1 10のシナリオは以下のとおり。1）悪意あるインサイダーが企業秘密にアクセスできるようになった、2）収益を生み出している重要なウェブアプリケーションに対して、DDoS（Distributed Denial of Service: 分散型サービス妨害）攻撃が行われた、3）政治的ハッカーによって、最も重要なウェブサイトが書き換えられた、4）会社の資金を不正に持ち出すために、財務ワークステーションを狙った組織犯罪が進行している、5）不満を抱いている従業員が、リモートサイトにある自動化された設備管理システムに変更を加えた、6）工場のプログラマブル論理制御装置（PLC）が変更（またはシャットダウン）され、生産活動が中断した（または品質管理上の問題が生じている）、7）公表前の財務データに内部関係者がアクセスしている、8）インターネットと接続しているウェブアプリケーションが攻撃され、バックエンドのデータベースに保存されている顧客の個人情報が社外からアクセスできる状況にある、9）重要な知的財産を盗み出すために、特定の標的に対してAPTによるサイバースパイ攻撃が行われている、10）合弁会社とのネットワークを通じてイントラネットが攻撃された。


11

図02脅威の進化

情報収集

APTのライフサイクル

データの持ち出し最初の悪用

特権獲得指令・制御

インサイダーリ

スク

ＡＰＴ

ハッカー

クラッカー

攻撃者のリソース/洗練度

個人の利益

金銭目的

国家資金によるスパイ活動・サイバー兵器

気晴らし/実験/嫌がらせ

単純な攻撃（クラッカー）

標的は、インターネットと接続し、かつネットワークに脆弱性が

存在する企業。

高度な攻撃（ハッカー）

標的は、インターネットと接続し、かつ価値ある情報を持っている企業。

産業スパイ（インサイダー）現役社員か元社員が、会社の知的財産を使って金銭を得ようとしている。

国家による攻撃（APT: 高度で執拗な脅威）

標的は、攻撃者にとって高い価値を持つ個人、活動、あるいは知的財産。

1980年代/1990年代 2012� BrainBoot/Morrisワーム� ポリモルフィックウイルス� Michelangelo

� Concept Macro Virus� Melissa� “I Love You”

� Anna Kournikova� Sircam� Code Red and Nimda

� SQL Slammer� Blaster� Sobig

� MyDoom� Netsky� Sasser

� Storm botnet� Koobface� Conflicker

� Aurora� Mariposa� Stuxnet

� WikiLeaks� Anonymous� LulzSec

� SpyEye/Zeus� Duqu� Flame

1983年11月、南カリフォルニア大学の大学院生だったフレッド・コーエンは、自己複製型コンピュータコードのセキュリティリスクを証明するために実験しました。「コンピュータウイルス」という言葉は、その少し前にレン・エーデルマン（コーエンの指導教授でRSA暗号の発明者。RSAのAはエーデルマンの頭文字）が考案したもので 2、まだ一般には知られていませんでした。それから30年が過ぎた今、コンピュータウイルスが何かを知っている人は何億人もいます。そして、これらのウイルスに感染したコンピュータもまた、何億台にも上っています。コーエンのウイルス研究はUNIX®上で稼働するメインフレームVAX（Virtual Address eXtension）マシン上で行われましたが、彼が立証した自己複製型コードの概念は、その後まもなくPCの世界にも移植されました。

IBM® PCに感染する最初のウイルスはBrain（フロッピーディスク内のブートセクタに寄生するウイルス）でした 3。Brainは1986年1月に登場し、続く1988年11月にはMorrisワームが登場しました 4。1990年になると、ウイルス開発者たちは登場したばかりのアンチウイルス技術を迂回するために、コーディングにポリモーフィズム（polymorphism）5の手法を取り入れるようになりました。

2 Cohen, Fred, “Experiments With Computer Viruses,” 1984, http://all.net/books/virus/part5.html 3 Leyden, John, “PC Virus Celebrates 20th Birthday,” The Register, UK, 19 January 2006, http://www.theregister.co.uk/2006/01/19/pc_virus_at_20/ 4 Morrisワーム（単に「1988年のインターネットワーム」とも呼ばれる）は、インターネットを介して広まった黎明期のコンピュータワームであり、世界初のワーム（少なくとも主要メディアで報じられ、大きな話題となった初のワーム）として知られる。また、米国の1986年コンピュータ不正行為防止法（Computer Fraud and Abuse Act）に基づく有罪判決が出たのも、この事件が最初であった。このワームはコーネル大学の学生だったロバート・タッパン・モリスが作成したもので、1988年11月2日にMITから放たれた。Kehoe, Brendan P.; Zen and the Art of the Internet: A Beginner’s Guide to the Internet, Prentice Hall, USA, 1992, http://groups.csail.mit.edu/mac/classes/6.805/articles/morris-worm.html

5 ポリモルフィックコード（Polymorphic code）とは、ポリモルフィックエンジンを使って、元のアルゴリズムを保ったまま変化していくコードのこと。コードは実行されるたびに変化するが、コードの機能（意味）は変化しない。ウイルスの作者たちはシグニチャによるアンチウイルス検知を避けるために、ポリモルフィックコードの手法を取り入れるようになった。


12

1980年代末と1990年代初頭のPCは、使われてないときは電源が落とされていることが多く、使用できるアプリケーションも比較的単純な機能のものに限られていました。そのため新たに出現したインターネットの力は、主にサーバの領域で発揮されていました。当時の攻撃の多くはオペレーティングシステム（OS）の脆弱性を悪用したもので、ハッカーたちの標的となったものは、主に教育施設、政府、軍のシステム、そして企業のデータセンターでした。ハッカーには高い技術力と複数のプログラミング言語の知識、さらにはサーバOSの構造やネットワークプロトコルの知識が必要でした。たいていのハッカーは独力で脆弱性を見つけ、攻撃ツールを開発しました。技術力が低く、他人が作った攻撃ツールやスクリプトを使って既知の脆弱性を攻撃する「技術力のないクラッカー（script kiddies）」は見下されていました。また、当時のハッカーには他のハッカーから新しいテクニックを学ぶ手段もほとんどありませんでした。

侵入できるシステムも2つか3つしかありませんでした。当時はまだ、インターネットに接続しているシステムは数えるほどしかなかったからです。しかし、このサイバー空間における戦いの黎明期においてすら、技術スパイを使って他国の政府を攻撃しようともくろむ国はありました。1989年に出版されたクリフォード・ストールの「カッコウはコンピュータに卵を産む（Clifford Stoll, “The Cuckoo’s Egg”）」は、ソビエトのKGBに雇われた西ドイツのハッカーが、1986年にARPANET（米国防高等研究計画局のコンピュータネットワーク）とMILNET（米軍の国防データネットワーク）のコンピュータに潜入し、ミサイル防衛構想「スターウォーズ計画」に関わる機密情報を盗み出すさまを描いたものです。

初期の実験段階ともいうべき1980年代と比べると、コンピューターシステム、アプリケーション、OSは劇的に進化しました。大半のもの、いや、すべてのものが変わりました。今日では多くのPCやサーバが長期にわたり、24時間365日インターネットに接続されています。技術的攻撃はOSの脆弱性だけでなく、ウェブとの連携機能を備えた、極めて複雑で双方向的なユーザーアプリケーション（例 : Adobe® Reader®, Microsoft® Office®、ウェブブラウザ、JAVA ™）を標的とするようになりました。入手しやすく、ユーザーフレンドリーなウェブ対応型のハッキングツールキット（現在、最も人気があるのはZeus）を使って、コンピューターユーザーに損害を与えようとしている攻撃者もいます（例 : スピアーフィッシング、各種のソーシャルエンジニアリング）。今ではウェブブラウザとマウスさえ使えれば、誰でもボットネットを構築・制御できるのです。

企業に侵入するためのアクセスポイントも劇的に増えました。インターネットと接続しているサーバは、以前はファイアウォールで仕切られた「DMZ（Demilitarized Zone: 非武装地帯）」の中にありました。ところがクラウドサービス、ソーシャルメディア、携帯機器、BYOD（Bring Your Own Device: 個人所有機器の持ち込み）ポリシーの登場以来、ファイアウォールという砦で厳重に保護されているのは会社の最重要データのみとなり、ラップトップ /デスクトップ /サーバは境界の外側に放り出されました。境界線が変わった結果、企業の最重要データが個人所有のタブレットにコピーされ、ファイルホスティングサービスにアップロードされ、個人のEメールアカウントに送信されることになりました。残念ながら、企業の防御体制は技術の変化に追いついていません。


13

サイバーセキュリティの専門家たちは技術革新のスピードについていくために四苦八苦していますが、問題はそれだけではありません。ハッカー志望者のための“教材”が増え、その多くがオンラインで手軽に入手できるようになったのです。例えば脆弱性テストに革命を起こしたMetasploit®フレームワークは、侵入テストの担当者（あるいは担当者を装った人物）が強力な脆弱性スキャンの実行を可能にしました。Metasploitのオープンソースあるいは商用のテストツールは、信頼できる人物による侵入テストだけでなく、攻撃者が不純な目的を達成するためにも利用されています。

自動化されたツールを使えば、今やたった一回の攻撃でも世界中の何十万台ものコンピュータに損害を与えられるようになりました。例えば米連邦捜査局（FBI）の報告書によると、2010年にロシアのハッカー集団が銀行口座の認証情報を盗み出すために作ったCorefloodボットネットは、世界各国の230万台のコンピュータに損害を与えました。報告書にはこう書かれています。

（感染したシステムは）およそ17の州政府と地方自治体政府の関連機関に及んだ。具体的には、警察（1）、空港（3）、軍事関連業者（2）、銀行・金融機関（5）、大学（30前後）、病院・医療関連会社（20前後）、そして何百もの企業である 6。

攻撃者たちは、標的を困らせ、面目を失わせるために、サーバ、デスクトップ /ワークステーション、ラップトップクラスのシステムやアプリケーションソフトウェアの脆弱性を悪用しました。また、さまざまなボットネットを使って銀行口座の認証情報を手に入れ、金銭的利益を得ようとしました。そして高度なマルウェアを使って、大企業の知的財産を盗み出そうとしました。政府から資金供与を受けている攻撃者グループは、自国の国有企業が競合企業よりも優位に立てるように、何億米ドルもの価値を持つ知的財産を盗み出しました。今日では、正体を隠して標的に重大な損害を与える悪意あるソフトウェアは兵器としても使われており、既にいくつかの国の政府が政治的な思惑から現実の世界に影響を及ぼすためにサイバー兵器を活用しています。史上初のサイバー空間における誘導爆弾として知られるスタックスネット（Stuxnet）は、その一例です 7。

1.3 進化する攻撃経路企業が自社の防御戦略を見直しはじめている一方で、攻撃者も既存の攻撃経路や進化する攻撃経路に新しい革新的な攻撃手法を取り入れているため、脅威は今後も進化し続けるでしょう。図3は、最近報道された3つの事例を使って、進化する攻撃経路の概念（本来の標的であるB社を攻撃するための手段としてA社を攻撃する）を説明したものです。

6 Russo, Tracy, “Coordinated Law Enforcement Action Leads to Massive Reduction in Size of International Botnet,” The United States Department of Justice, 27 April 2011, http://blogs.justice.gov/main/archives/1320

7 スタックスネット（Stuxnet）は、イランのナタンズにある大規模な核濃縮施設でのウラン生産を遅らせるために米国政府とイスラエル政府が作成したものと一部メディアで報じられた。Sanger, David, “Obama Order Sped Up Wave of Cyberattacks Against Iran,” The New York Times, 1 June 2012, www.nytimes.com/2012/06/01/world/middleeast/obama-ordered-wave-ofcyberattacks-against-iran.html?pagewanted=all.


14

図03進化する攻撃経路

セキュリティ上の問題セキュリティ上の解決策進化する攻撃経路

単一要素認証（例：ユーザーが知っているもの、ユーザー IDやパスワードなど）は、セキュリティを確保する手段としては脆弱すぎる。パスワードは盗まれやすく、推測されやすい。

多要素認証を採用する―ユーザーが知っているもの（ユーザー ID、パスワード）とユーザーが持っているもの（トークンを利用して入手するパスワード。パスワードの内容は、強力な暗号アルゴリズムを用いて定期的に変更される）を組み合わせる。

トークンベンダー（RSA社、2011年３月）に潜入し、実際の標的（トークンベンダーの顧客）が使用している暗号鍵を盗み出す（Lockheed martin社、2011年5月）。

マルウェアの開発者は何千人も存在する。その中には自分が書いたコードを、あたかも信頼できる企業のコードであるかのように偽る者もいる。

デジタル証明書を導入し、ベンダーがコードの信頼性を保証するために、自社のコードに「署名（シグネチャ）」をつけられるようにする。

ほぼすべてのコンピュータに導入されているソフトウェアの開発元（Adobe社）に潜入し、その企業がコードに署名するために使用しているインフラを使って、悪意あるコードに署名する（2012年9月）。

アンチウイルス型のアプローチ（「有害」ソフトウェアを定義し、それをブラックリストに載せたり、隔離したりする）では、マルウェアの開発ペースについていくことはできない。今日では、毎日20万を超えるブラックリストシグネチャが新たに作られている。

アプリケーションのホワイトリストを作成する（「信頼できる」ソフトウェアを定義し、それ以外のものはすべて「有害」と判断する）。

アプリケーションのホワイトリストを作成しているベンダー（Bit9社）に侵入し、そのベンダーがコードに署名するために使用しているインフラを使って、悪意あるコードに署名し、そのコードがホワイトリストに掲載されるようにする（2013年2月）。

創造的で有能な攻撃者たちによる精力的な活動を通じて、脅威の世界は広がり続けています。攻撃者が適応し、変化している以上、企業も適応し、変化しなければなりません。企業はサイバーセキュリティの辞書から「予防」という言葉を消す必要があります。高度な攻撃者の侵入を防ぐために、すべての企業が導入できるソリューションなどないからです（ネットワークから切り離されていたナタンズのウラン濃縮施設ですら、攻撃者の侵入を許したことを思い出してください）。ひとたび潤沢な資金と高度な技術を持つ攻撃者の標的となったら、彼らの侵入を防ぐことはできません。今日の情報セキュリティ専門家に求められているのは、次のような態度です : ネットワークは既に侵害されているか、まもなく侵害されることになる。そのとき、最重要データをどう守るか?　どうすれば攻撃への守りを強化できるか?　どうすれば進行中の攻撃を検知できるか ?　今日の高度な攻撃に対応するには、どうすればいいのか?

ネットワークは既に侵害されているか、まもなく侵害されることになる。そのとき、最重要データをどう守るか? どうすれば攻撃への守りを強化できるか? どうすれば進行中の攻撃を検知できるか?

今日の高度な攻撃に対応するには、どうすればいいのか?


15

1.4 転機 2010年1月、グーグルは自社のコンピュータネットワークが高度な攻撃を受けていることを発表しました。攻撃の出元は中国で、その目的は明らかに中国の人権活動家のGmail ™アカウントにアクセスすることでした 8。グーグルは、他にも20の大企業が同様の攻撃を受けている可能性があると示唆しました。企業セキュリティコミュニティの多くのメンバーにとって、これはAPT時代の幕開けでした。

しかし米国の連邦法執行機関、諜報機関、諜報防止活動のコミュニティは、グーグルがこの事実を発表する前から、「APT攻撃」のことをよく知っていました。2010年7月にリチャード・ベイトリックはこう指摘しています 9。

米国空軍（USAF）は2006年に「高度で執拗な脅威（APT: Advanced Persistent Threat）」という言葉を作りました。その理由は、軍関係者以外の人々とこの種の攻撃について話すためで

す。国防総省や諜報組織のメンバーは、攻撃者を発見するとコードネームを付けて表現してい

ました。しかし個々の侵入事件について軍関係者以外と話をする場合、コードネームは使えま

せん。そこでコードネーム以外の呼称として、APTという言葉を作ったのです。

APTという言葉は一般名詞として作られたわけではありませんでした（のちにマーケティング業者たちが一般名称として使うようになったのです）。本来、それはアジアにある国の政府の指示を受けて、特定の標的を攻撃している特定の集団を指す言葉でした。APT攻撃についてのグーグルの発表は、実際には何年も前から活動していながら、それまでは厳重に管理された特定集団の中でしか知られていなかった攻撃者集団の存在を広く一般の人々にも知らせることになりました。

APT時代の3年目にあたる今年は、さらに多くの企業が「高度な（sophisticated）」攻撃について語り始めました。APTという言葉が意味するものも広がり、現在では新しいタイプの攻撃者、すなわち「特定の目的を達成するために、特定の個人または企業を狙う攻撃者」を指すようになっています。今後もAPTの手法を採用した攻撃は増えていくでしょう。なぜなら、効果があるからです。攻撃を特定のAPT集団と関連づけることは、ますます困難になっていくでしょう。しかし、変わらないことが一つあります。それは、豊富な資金を持つ高度な攻撃者は、攻撃を成功させ、企業から価値ある情報を盗み出すことができるという事実です。

8 Eunjung Cha, Ariana; Ellen Nakashima; “Google China Cyberattack Part of Vast Espionage Campaign, Experts Say,” The Washington Post, 14 January 2010,

www.washingtonpost.com/wp-dyn/content/article/2010/01/13/AR2010011300359.html 9 Bejtlich, Richard, “What APT Is (and What It Isn’ t),” Information Security, July/August 2010


16

1.5 APTのライフサイクル歴史をひもとくと、過去の優秀な攻撃者たちはみな、その動機、資金源、指示者を問わず、特定のサイクル（図4、5）に従って標的を攻撃していたことがわかります。

図04APTのライフサイクル

情報収集

APTのライフサイクル

データの持ち出し最初の悪用

特権獲得指令・制御

図05APTのライフサイクル（別の視点）

情報収集

背景調査最初の攻撃

足場の確保潜伏

社内ネットワークの

偵察

アクセス範囲の拡大

特権獲得目的情報の収集と暗号化

データの持ち出し

潜伏の継続

最初の悪用指令・制御特権獲得データの持ち出し

以下は、APTのライフサイクルを構成している各段階の説明です。・背景調査　APTは標的を詳細に調べ、攻撃に使う具体的な経路を見つけます。あなたがフォーチュン100社の幹部だとします。業界会議からオフィスに戻り、メールソフトを立ち上げると、会議の講演者を名乗る人物から、「今日は私の講演をお聞きいただき、ありがとうございました」というお礼のメールが届いていました。そのEメールには、講演で使われていたプレゼン資料の最新版が添付されていました。あなたなら、このファイルを開きますか?　あるいは、あなたが大企業の法務担当役員だとします。契約している社外弁護士を名乗る人物から、地方裁判所に提出された新しい訴訟の情報と訴状のコピーを添付したEメールが届きました。あなたなら、そのファイルを開きますか?　これらのシナリオは、標的に望み通りの行動をとらせるためにAPTによる詳細な調査の一例です。


17

・最初の攻撃　一般に、最初の攻撃はソーシャルエンジニアリングの手法を使って、ひとりまたは複数の個人に対して行われます。例えばEメールやインスタントメッセージ、ソーシャルメディアへの投稿といった攻撃経路に悪意あるコンテンツへのリンクを埋め込み、標的が添付ファイルを開くか、リンクをクリックすると、一つか複数の機器が悪意あるソフトウェアに感染します。

・足場の確保　ユーザが行動を起こしたら、APTは悪意あるカスタムソフトウェアを使って、標的とした環境に最初の足場を確保します。これらのカスタムソフトウェアは、アンチウイルスのアラートを引き起こすことはまずありませんが、攻撃が成功したことをAPTに伝える経路となります。初期の感染ツール（一次マルウェア）には有害な機能はほとんどありませんが、攻撃の経路となって、追加機能（二次マルウェア）をダウンロードします。

・持続的アクセスの実現　APTの主な目的の一つは、侵害したコンピュータ内にC&C（control-and-command: 指令・制御）の拠点を作ることです。つまり、たとえ標的とした機器が再起動されても制御とアクセスを維持し、いつでも標的とした環境に接続できるようにするのです。その手段として、たいていの攻撃者は起動時に自動的に実行されるサービス（C&Cソフトウェアを含む）を標的としたコンピュータにインストールします。ユーザが直接サービスに対して何かをすることはまずないため、多くのユーザはサービスが実行されていることに気づきません。別の方法としては、システムレジストリを書き換え、コンピュータが起動するたびに悪意あるアプリケーションが自動的に実行されるようにすることで、標的環境への持続的なアクセスを実現する場合もあります。ただし、これは攻撃者にとってはリスクの高い方法です。アプリケーションが実行されていることにユーザが気づき、アプリケーションを終了させる可能性があるからです。あるいは、正当なOSやアプリケーションソフトウェアのコンポーネントの代わりにC&C機能を強化するようなコンポーネントをインストールすることで、持続的なアクセスを実現することもあります。

・社内環境の偵察　標的とした環境に持続的にアクセスできるようになったら、次は目的の情報が格納されているコンピュータ、サーバ、あるいは記憶領域を見つけるために社内環境を偵察します。通常、偵察は侵入したコンピュータに既にインストールされているツールを使って行われますが、特定のシステム（例 : ID/アクセス管理、認証、仮想プライベートネットワーク［VPN］、データベース、Eメールサーバ）を見つけるために、スキャニングツールがアップロードされる場合もあります。

・アクセス範囲の拡大　社内環境の偵察過程では、新しいシステムにアクセスして、その中身を探ったり、他にアクセスできる場所はないかを見て回ったりする作業が発生します。また、持続的なアクセスを実現するためには、新たにアクセスしたシステムにC&Cソフトウェアをインストールすることも欠かせません。

・特権獲得　攻撃者は標的企業のネットワークを偵察し、最初のいくつかの標的から盗み出した認証情報を使ってネットワーク内を動きまわります。ネットワークをくまなく探るためには、「ローカルユーザー」から「ローカル管理者」へ、そしてさらに高いレベルの管理者へとアクセス権限のレベルを上げていく必要があります。情報へのアクセスが厳しく制御されている企業


18

でも、環境（通常はActive Directory®ドメインだが、例外もある）内のすべての認証情報を手に入れることさえできれば、正規のユーザになりすまして、目的の情報に自由にアクセスできるようになります。

・目的情報の収集と暗号化　目的のデータが見つかったら、APTは通常、そのデータをアーカイブ化し、圧縮して暗号化します。そうすることでアーカイブの内容を企業が導入している高度なパケット監視機能やDLP（Data Loss Prevention: データ漏洩防止）機能から隠すことができるのです。

・データの持ち出し　APT攻撃の究極の目標は、標的企業から「価値あるもの」を盗み出すことです。その企業がFTP（ファイル転送プロトコル）を使って社外にデータを転送することを許している場合は、APTは伝統的なFTPアプリケーションを使用します。FTPの使用が禁止されている場合は、カスタマイズしたデータ転送技術を使って、標準 /非標準ポートからデータを送信します。

・潜伏の継続　最後に、APTは指令者から命じられた任務に取り組みます。それは標的環境へのアクセスを維持することです。この任務を遂行するために、APTが長期にわたって企業のネットワーク内に潜伏することは珍しくありません。ピンポイントで狙ったものしかAPTは攻撃しません。彼らがネットワーク内にいるのは、そう命じられたからです―そして退却の命令がないかぎり、彼らは永遠に居座り続けます !

このライフサイクルは、必ずしもAPTに特有のものではありません。APT攻撃の大きな特徴は、その標的に狙いを定める性質にあります。例えばCorefloodボットネットという高度なマルウェアアプリケーションの指令者は、このマルウェアを定期的に更新することで10年以上にわたってアンチウイルスソフトウェアを回避し続けました。マルウェアの拡散に用いられたのは、主にソーシャルエンジニアリングの手法でした。Corebloodは自己複製を繰り返しながら、感染ネットワークの内部を動き回り、買掛金システムにアクセスできるコンピュータを探りました。ドメイン管理者権限を手に入れる術はなかったため、標的にしたユーザの権限で活動しました。そして買掛金システムからのキーストロークを保存し、それを攻撃者に伝えました。具体的には、オンライン・バンキング・システムにアクセスし、電子的に資金を移動するためのユーザ IDとパスワードです。そして従業員になりすまし、盗み取った認証情報を使って何億米ドルもの資金を海外の口座に送金しました。

もっともCorefloodボットネットはAPTではありませんし、APTと表現されるべきでもありません。Corefloodの指令者は、金銭的な利益が見込めるという理由だけで標的を選んでいました。つまり標的企業は、インターネットと接続しているコンピュータがあり、かつオンライン・バンキング・システムを利用している可能性があるという理由だけで、攻撃を受けたのです。だからといって、Corefloodボットネットの指令者が標的企業に与えた影響が緩和されるわけではありませんが、Corefloodボットネットのような攻撃を防ぐこととAPT攻撃を防ぐことは、別のものとして考えなければなりません。


19

APTは自分たちの戦術、方法、手順を、一般的な情報セキュリティアーキテクチャにも適用しました（図6）。

図06APTの手口

従来のセキュリティ慣行 APTの手口

ネットワークの境界に、トラフィックの内容を詳しく調査するための機器を設置する。

SSL（Secure Socket Layer）、カスタム暗号、パスワード保護 /暗号化されたコンテナファイルを使って、パケットコンテンツの監視を困難（不可能）にする。

ネットワークファイアウォールを設置し、トラフィックのメタデータを監視・評価する。

標準的なポートやプロトコル（HTTP*、DNS*、SSL、SMTP*など）を使って、ネットワークの内部から通信を行う。* HTTP: Hyper Text Transfer Protocol* DNS: Domain Name System* SMTP: Simple Mail Transport Protocol

ホストにファイアウォールを設置し、ローカルのトラフィックメタデータを監視・評価する。

攻撃の初期に、マルウェアをホストのファイアウォールのホワイトリストに追加する。

サーバーとワークステーションに、リアルタイム評価・アラート機能を持つ侵入検知システム（IDS）と侵入防止システム（IPS）を導入し、実行する。

一般的なポートやプロトコルを使って通信を行うことで、ありふれた正当なトラフィックに紛れ込む。

すべてのサーバーとワークステーションにアンチウイルスソフトウェアをインストールし、1日数回シグネチャを自動更新する。

悪意あるコードは使用する直前にコンパイルし、最新のアンチウイルス定義でテストする。標的に合わせてコードをカスタマイズする。複数のリバースエンジニアリング対抗策（カーネルドライバー、パッカー、各種の難読化ツール）を使ってコードを保護する。

月次か四半期ごとに脆弱性を評価する。サーバーOSの脆弱性ではなく、ホスト/アプリケーションの脆弱性、ゼロデイ攻撃、ユーザー行動を利用して攻撃を行う。

二要素認証を導入する。カスタマイズしたマルウェアをユーザー権限でインストールする。ハッカーがマルウェアを認証することで、二要素要件を迂回する。

HTMLメールの使用を禁止し、Eメールの内容をリアルタイムでフィルタリングする。

標的に合わせて巧みに書かれたフィッシングメールを作成し、（マルウェアそのものではなく）マルウェアへのリンクを埋め込む。

悪意あるウェブサイトやURLをリアルタイムでフィルタリングする。

サードパーティのサイトに侵入し、マルウェアを埋め込む。侵入するサイトは標的や攻撃ごとに変える。


20

1.6 さまざまな対応策 APTやその他の先進的な攻撃者は、標的企業の環境に合わせて攻撃の形を変えているため、標的企業はさまざまな方法で―時には極めて先進的な方法で―対応できます。（図7）

図07さまざまな対応策

対応の複雑度

インターネットからの切断

認証のパーティショニング

「ジャンプ」サーバー

重要データのエアギャップ（ネットワークの物理的な遮断）

諜報防止活動

アウトバウンドゲートウェイの強化

継続的な監視/SOC

SOC＝セキュリティ・オペレーション・センター2FA＝二要素認証

HPA＝ハイプロファイル資産SIEM＝セキュリティ情報イベント管理

独自のEメールスキャニング

事前対策のためのAPT評価

定期的なフィッシングシミュレーション

パッチ、コンフィギュレーション管理の見直し検索可能な状態でのイベント蓄積(SIEM）

先進的なマルウェア検知

ネットワーク機器（フルパケットキャプチャ）

インシデント対応/フォレンジック捜査能力の整備

PCの仮想化

コアサーバー上のアプリケーションのホワイトリスト作成

重要なデータ/ネットワークの隔離

プロキシー認証

アクセス制御の強化（2FA、パスワードの一元管理、HPA管理）

高度

中程度

基礎

※ 「ジャンプ」サーバー＝2つのセキュリティゾーンを分けている堅牢なシステムで、2つのゾーンを安全に行き来するための手段を提供する。

すべての企業が先進的な対応策の導入を検討するわけではありません。例えばインターネットとの接続を切ってしまえば、パートナー、供給業者、顧客とのつながりを要件とする重要な業務プロセスが断絶されてしまうかもしれません。その他の対応策も効果はありますが、企業によっては「やりすぎ」と判断されることがあります。グローバル企業では、ほぼ常に最高水準の仕事が求められるからです。

多くの企業は一般的な対応策を採用しています。APTなどの先進的で高度な攻撃は非常に成功率が高いため、必要最低限の対応策はすべて導入することを推奨します。


21

1.7 まとめこの10年で脅威を取り巻く環境は劇的に変わりました。ほとんどの企業は、その変化に対応できていません。この後のページでは、図7で初級に分類した対応策のいくつかを取り上げます。それは「ネットワークは必ず破られる」という新たな見解が企業にもたらす主要な疑問を解消します。

企業が高度な標的型サイバー攻撃を調査するためには、この種の攻撃についての基礎的情報が欠かせません。こうした攻撃の中には、政府機関から資金供与を受けて、特定の企業の環境に足場を確保することを目的としたものもあります。攻撃の主体は「APT」かもしれないし、APT的なアプローチや手法を採用した、別の機関かもしれません。いずれにしても、企業が相手にしなければならないのは、先進的で、高度で、組織化され、潤沢な資金を持つ、執拗な敵です。企業に求められているのは、侵犯を調査すること、調査によって得られた脅威情報を基に詳細な改善・撲滅計画を立て、実行すること、そして攻撃者を自社の環境から完全に駆除することです。


22

白紙ページ

第2章　準備

23

第2章　準備2.1 チームの構築と計画の立案セキュリティ侵犯への対応準備に時間と資源を費やしている企業は、そうでない企業と比べて、はるかに上手く対応や駆除への取り組みを進めることができるでしょう。

目的 : セキュリティ侵犯の調査や駆除を徹底的かつ効率的に進めるための人材、計画、能力を整備すること。

サイバーセキュリティ侵犯を調査するため綿密に準備された体制を整備することの必要性について経営陣に納得してもらうことは難しいかもしれません。たいていの経営者は難色を示し、こう質問してくるでしょう。「最初から、誰も侵入できないようにすればいいのに、なぜ侵犯への対応準備に労力を費やさなければならないのだ?」

しかし現実には、企業がいかに強固な防御態勢を築いていようと、強力な手段と明確な意思を持った攻撃者の手にかかれば、企業が導入するいかなる複雑な予防、検知対策の多寡にかかわらず、それらは打破されてしまいます。つまり、特定の企業に標的を定めている攻撃者は、極めて高い確率で一定の成功を収めます。しかも、彼らは標的のネットワークに入り込み、しっかりと足場を確保していることが多いため、駆除するのは至難の業です。

「攻撃は遅かれ早かれ成功する」という前提に最初から立って、サイバー攻撃に備えておけば、調査・駆除活動を効率的かつ包括的に進めることができます。では、どのように準備を進めればよいのでしょうか ?　以降のセクションでは、企業がサイバーセキュリティ侵犯を効率的かつ効果的に管理する上で取りえる6つの活動について触れていきます。

2.2 重要な関係の構築2.2.1 外部との関係セキュリティ侵犯を効率的かつ効果的に調査するためには、侵犯が実際に発生する前に、重要な第三者との関係を築いておく必要があります。ここでいう第三者には、取引関係、合弁会社、社内ネットワークに何らかの形でアクセスできる者、請負業者（常駐、非常駐の両方）の他、会社の業務に悪影響が出た場合に影響を受ける可能性のある関係者すべてが含まれます。第三者を特定したら、全員の連絡先情報を集め、適切な人物（管理責任者、ネットワーク・セキュリティ・チームのリーダーなど）が簡単にアクセスできる場所に保管します。

このような関係を事前に築いていない企業は、セキュリティ侵犯が発生してから、迅速な対応を助けてくれるセキュリティ会社や専門家を慌てて探す羽目になります。これに対して、こうした関係を事前に築き、万一に備えて第三者と契約していた企業は、本格的な調査や駆除にはるかに円滑に着手できます。企業の規模や社内のセキュリティ・オペレーションの成熟度が、侵犯の調査や駆除対応に第三者がどれだけ関与させるかの決定において重要な位置を占めます。成熟


24

度の高いセキュリティプログラムを持つ企業であれば、こうした活動の大半を社内で処理できるかもしれません。一方、不十分なセキュリティプログラムしか持たない企業は、第三者に全面的に頼ることになるかもしれません。企業がそのような状況に陥っているかに関わらず、攻撃を受ける前に、以下に示す数多くの第三者との関係を検討しておかなければなりません。・侵害調査チーム・セキュリティ監視管理サービス・ DoS（Denial-of-service: サービス妨害）対応サービス・マルウェア分析支援・フォレンジック支援・駆除対応チーム

2.2.2 内部との関係中規模や大規模企業のネットワーク管理者なら、社内に知らない部署があっても不思議ではありません。社内の関係者すべての連絡先を包括的にまとめたリストがあれば、調査、封じ込め、駆除といった取り組みを大幅に早めることができるでしょう。システムやユーザをネットワークから切断する権限を持っているのは誰か、またはその他の方法で各部門の業務を縮退させる権限を持っているのは誰かがわかっていれば、インシデント対応に大いに役立つはずです。調査や駆除の最中に求められる、誰が何について責任を持ち、誰が決断を下す権限を持っているのかという情報を把握していないことほど、攻撃を受けている企業の人々を混乱させ、いらだたせるものはありません。

上段で特定された担当者には、封じ込めの決断を迅速に下すためにセキュリティチームのリーダーから連絡が入る可能性があることを伝える必要があるでしょう。また、責任分担表（例 : responsible, accountable, consulted, informed [RACI] matrix）を作成しておくと、役割、責任、権限の所在を把握しやすくなります。プロセスや手順の文書化、机上シミュレーションの実施により、調査や駆除対応に関わる関係者のコミュニケーションが促進されるでしょう。社内のすべての関係者の連絡先を明確にし、攻撃にすぐに対応できるように準備することで、その場しのぎではなく、事業の継続性を念頭において問題に対処できるようになるでしょう。

2.3 権限の明確化チームは編成された後には、必要な権限が与えられなければなりません。チームの活動には、他の部門には馴染みのないものもあるかもしれませんが、上層部はセキュリティチームのそのような活動をきちんと支援しなければなりません。事業への影響が許容できる範囲にとどまっているかぎり、セキュリティチームは企業の長期的な利益のために行動することを認められていなければなりません。権限の付与は、一般的にはチームのミッション、目標、目的、権限、責任を明記し、CIOに承認された明快に記述されたチームの趣意書により実現されます。趣意書の写しは、CIOが統括しているすべてのスタッフと主要な事業部門の長に配布すべきでしょう。セキュリティチームのミッション、目的、目標、責任は、すべての幹部職員の間で理解されていなければなりません。

第2章　準備

25

2.4 社内で利用されている技術の一覧化社内で利用されている技術や資産のリストを作り、こまめに更新するようにしておけば、調査・駆除活動を効率よく進めることができます。このようなリストの作成は準備の基本といってよいでしょう。リストには IDSや IPSだけでなく、ネットワークと接続しているすべての機器を記載します。これは、どんな機器も、攻撃者がネットワーク内で侵入を拡大するための踏み台となる可能性があるためです。また、業務に利用されている機器も侵害される可能性があるため、調査チームはこれらの機器の用途、重要度、担当者の連絡先を包括的にまとめたリストも必要となります。この種の機器の例としては、ネットワークに接続された、SCADA（Supervisory Control And Data Acquisition: 監視・制御データ収集型）ICSs（Industrial Control Systems: 産業制御システム）、PCI（Payment Card Industry: クレジットカード業界）設備、医療機器などがあります。このようなシステムが侵害されれば、事業上取り返しのつかないような事態につながる可能性があるため、完全なリストは欠かせません。

高度な攻撃においても、機器のリスト（各機器の主な特性をつけたもの）があれば、調査チームは小さな手掛かり（rabbit hole）をたどって、IOC（Indicator Of Compromise: 脅威が存在することを示す痕跡）を十分に調べることができるようになります。手掛かりをたどるとは、何であれ最初に検知された IOCを把握し、その特性を調査完了に至るまで、それぞれの特性を追跡調査することを指します。以下の特性はそれぞれ非常に重要ですので、徹底的に調査すべきでしょう。• 日付と時間• IPアドレス（内部 /外部） • ポート（送信元 /送信先） • ドメイン• ファイル（例 : .exe、.dll）• システム（ハードウェアベンダー、OS、アプリケーション、用途、設置場所）

日付と時間は、ログ・SIEM（Security Information and Event Management: セキュリティ情報イベント管理）分析の際に注目すべきポイントをセキュリティチームに教えてくれます。分析はそこから得られた特定の時間前後の限られた時間枠（できれば時間単位）を手始めに、最初の痕跡と一致するような動きを探します。イベントが検知された時間は、最初の攻撃のものかもしれませんが、攻撃の後半で攻撃者が犯したミスである可能性の方が高いです。一旦、最初の対象としたとき間枠に対する調査が終わったら、最初の痕跡やその後に発見された痕跡と一致するイベントを探るべく、調査範囲を体系的に広げていくべきでしょう。これらのデータを使えば、何が起きたのかを容易に見極めることができるものの、クリーニング・復旧活動に着手するのは駆除段階まで待つのが賢明です。


26

外部 IPアドレスやポート番号が確認された場合は、当該 IPアドレスに対する、または当該ポートを経由した全通信を調べる必要があるでしょう。まずは最初の時間枠のトラフィックを調べ、徐々に対象を広げていきます。まずは、その IPアドレスと通信していた内部ホストをすべて見つけ、その前後の時間にこれらのシステムで何が起きていたのかを徹底的に洗い出します。次は、例えばこれらのシステムがイベント前後の時間帯で（内部または外部の）誰と通信していたかに注目し、これらのホストも調べます。

内部 IPアドレスやポート番号が確認された場合も、前述したステップに従いますが、順序は逆です（外部から内部ではなく、内部から外部）。反復的なパターンが認められたトラフィックの場合は（例 : 毎正時にパケットが送信される）、2つのホスト間にC&Cチャネルが存在する可能性があります。こうしたトラフィックは「定期発信（beaconing）」と呼ばれ、攻撃者にシステムへのアクセスがまだ存在し、悪用可能であることを知らせるものです。

攻撃者が特定のドメインを使用している場合も、ネットワークから当該ドメインへのトラフィックをすべて見つけ、これらのシステム調査はとても重要です。ドメインの IPアドレスは所有者の意思で変えることができるため、これらの属性、ドメイン名や IPアドレスに関する古いデータを信頼することには慎重になるべきでしょう。

最初の IOCが特定のシステム（サーバタイプやドメインコントローラ）と紐づいている場合は、同じようなシステムをすべて調査すべきでしょう。これらのシステムは同様の設定、パッチ、脆弱性を持つ可能性が高いため、かなりの確率で侵害される可能性があるからです。高度な攻撃者は極めて用心深い完璧主義者であり、状況に応じて手法を変える攻撃（Campaign-style attacks）を冗長化させています。

すべての社内のネットワーク資産を網羅したリストなしには調査チームは不利な状況で活動せざるを得ません。企業の可視性を高めるための事前投資は、セキュリティコンプライアンスを維持する上でも、またさらに重要なことにセキュリティ侵犯に迅速に対応する上でも、大きな見返りをもたらします。

2.5 調査プロセスの標準化ネットワークの状況は企業によって異なりますが、企業が必要に応じて積極的に導入・適応できる標準的な計画を可能にする共通した性質を持ちます。さまざまなシナリオに対応・適応していくためには、計画は十分に包括的かつ機動的なものでなければなりません。これは上層部の主導で計画を立てる必要があることを意味します。まずはセキュリティ侵害の発生に備えて、包括的な調査・駆除計画を立てましょう。その後、新しい情報や発見に合わせて、計画に微調整を加えていきます。

第2章　準備

27

しっかりとした計画には、インシデントを特定するまでの標準的なプロセスが記載されています。このプロセスはいくつかの重要な段階に分かれ、計画には各段階でとるべき行動が簡潔に説明されています。一般に、このプロセスは以下のように分けられます。 • インシデント発生の判断　報告されたイベントがセキュリティインシデントなのか、それともポリシー侵害等の悪意のないイベントなのかを判断します。

• インシデントの分析と分類　インシデントにカテゴリーと可能性のあるサブカテゴリーに分類し、あらかじめ定められている対応活動を参照できるようにします。

• インシデントの格付けと優先順位の設定　対応活動の優先度とセキュリティレベルの決定のために、インシデントの実際の影響もしくは予測される影響を分析します。

• インシデントの追跡　インシデントに追跡システム上の固有の識別子を付与し、解決、連絡、復旧、教訓など、すべての段階を通じてインシデントを追跡できるようにします。

計画には、図8、9に示したような基本的な優先度付けプロセスを含めてもよいでしょう。マルウェアや脅威の研究結果から、そのイベントが大規模な脅威に発展する見込みはないとチームが判断した場合は、標準的な改善手順を実行します。それ以外の場合は、インシデントを上層部に報告し、本格的な調査と除去を実行します。

図08基本的なインシデント優先度付けプロセス

リアルタイムのアラート分析 • IDS/IPS/SIEMアラートの詳細を調べる• ネットワークデータとの相関関係を調べる• スレットインテリジェンス（攻撃への理解を深め立てた対策）と比較する

調査チケットを作成し、セキュリティチームに

送る

マネジメントに警告を出し、インシデント対応計画に従う

標準的な改善手順に従うない

ある

セキュリティチームは状況を調べ、優先度を付ける：組織に深刻な脅威を

もたらす可能性があるか？


28

図09アラート決定プロセス

いいえ

いいえ

はい

はい

誤検知

有効

初回アラートの分析• アラートの詳細と相関関係• 送信先IP：whoisとレピュテーション• パケットキャプチャー情報• その他

アラートは事前に定められた脅威のプロフィールと合致しているか？

フォレンジック分析を実施し、次のステップを決定する

データが持ち出された証拠があるか？

「誤検知」と注釈を付け、必要に応じて

センサーを調整する

標準的な改善手順に従う

マネジメントに警告を出し、対応に向けて本格的に調査する

目標約20分以内で優先度付けと

分析の大部分を完了する

調査の実行に関する詳細は、本文書の「調査」、「駆除」、「事後対応」の各セクションをご覧ください。

2.6 トレーニングとガバナンス 2.6.1 訓練少なくとも年に一度は、調査、駆除チームの熟練度をテストする必要があるでしょう。総合演習では、主な要素（連絡、調整、利用可能なリソース、対応など）をすべて盛り込みます。経営陣は、計画の立案や実行からこれまで得られた教訓、ポリシーやセキュリティに関する態勢の見直しまで、すべての段階に関与しなければなりません。

演習はさまざまな形態をとります。 • 総合演習 • 机上シミュレーション • セミナー

総合演習では、シナリオに沿って、所与の状況に対処するための行動のほとんどまたはすべてを実際に行います。セキュリティチームには、シナリオの内容や範囲についての事前情報を持たな

第2章　準備

29

い場合もあります。それが演習だと伝えないまま、演習を実行することさえあります。この「抜き打ちテスト」が、最もしっかりした、かつ、高度な形態になります。ほとんどの場合は、必要な行動の大部分を事前に調整する大規模な演習企画グループが存在します。教訓を引き出し、強みを特定するために、評価担当者が指名される場合もあります。計画チームが小さいほど、参加者へのサプライズの要素もより上手く抑えられ、実際の対応をより正確に模したものとなります。

演習の結果は必ず記録します。この記録には、演習日程（複数日にわたる場合）、演習範囲の予定と実績（一致しない場合があります）、各活動の説明、参加者、観察記録、教訓、改善が必要と指摘された分野を記載します。

2.6.2 セキュリティプログラムと対応計画の見直し組織のニーズの変化に対応するためには、少なくとも年に一度は包括的なセキュリティプログラムと、それに続く調査・駆除対応計画の見直し・修正に取り組むことは得策です。プログラムの達成目標はすべて見直し、達成状況や実行可能性を吟味した上で、必要があれば修正を加えます。トレーニングの要件が満たされているかも評価し、翌年に必要な技術を検討・計画する必要があります。セキュリティプログラムを見直す際は、技術の進歩、攻撃の進化、関連する脆弱性、ユーザ行動の傾向などをすべて勘案する必要があります。

これらの見直しを実施する最適な時期は、年間予算計画や通常の財務管理プロセスがスタートする前です。次年度が始まる前に、翌年のプログラムの資金需要を考慮し、プログラムの目的、ニーズ、計画投資（例 : 研修、意識向上活動、機器・技術、人件費・事業費）を検討する必要があります。

2.7 必要不可欠な能力の確立調査を徹底的かつ効率的に実行し、駆除活動を効果的に進めるためには、事前に必要な能力を社内に整備しておく必要があります。

どんな調査でも、セキュリティ侵犯の範囲を明確にすることは必須です。これは非常に複雑な攻撃の場合は特にいくつかの能力を必要とします。準備段階において、能力のギャップ分析を実施し、セキュリティ侵犯に的確に対処するための能力を社内に確立する計画を策定することは重要です。

技術を効果的に活用するためには、適切な能力を備えた人材と練られたプロセスが必要です。徹底的な調査を実施し、環境に入り込んだ相手を駆除するためには、社内に適切な能力が漏れなく揃っていることがとても重要になります。図10は、効果的で効率的な調査や駆除に必要な能力を示したものです。これらは「必須能力」と「推奨能力」に分けられます。必須能力とは、チームがセキュリティ侵犯を調査し、セキュリティ侵犯の複雑度に応じて、ある程度の成功を収めるために欠かせない能力のことです。セキュリティ侵犯が複雑であるほど（例 : 侵害されたシステムの範囲、マルウェアの洗練度）、推奨能力なしに効率的に運用することは難しくなります。


30

「インシデント対応（IR: Incident Response）の強化」というと、技術やツールに注目が集まりがちです。企業の技術力は、企業向けの高額な機器やソフトウェアを調達することによって高めることもできますが、まずは既に保有するツールを最大限に活用し、必要に応じてオープンソースのソリューションも取り入れながら、高い費用効果で不足している技術を補うこともできます。新しいソリューションを購入する前に、まずは関係者が協力して、インシデント対応を効果的に進めるにはどのような技術力が必要か、また、そのうちの社内にあるものは何か、を考える必要があります。不足が見つかった場合は、製品を購入する前に、オープンソースの利用可能性を検討すべきです。ツールの取得コストの削減に組織的に取り組むことで、資金を有能な人材の獲得やチームのスキルを高めるためのトレーニング・教育に振り向けられるようになります。

インシデント対応を効果的かつ効率的に実施できるか否かは、特定の技術力を持ち合わせているかに左右されることは事実です。しかし、多くの場合は、人材やプロセスへの継続的な投資の方が、企業の技術投資より大きな見返りをもたらすでしょう。

図10は、CSIRT（Computer Security Incident Response Team）が、サイバーセキュリティ・インシデントを効果的かつ効率的に管理するための人材、プロセス、技術力をまとめたものです。この後のセクションでは、これらを個別に解説していきます。

図10が示しているように、調査チームはホストレベルとネットワークレベルの活動の両方で可視性を確保する必要があります。言い換えれば、企業のホストのネットワークにおいて、「移動中のデータ（data in motion）」、「保管されているデータ（data at rest）」、「使用中のデータ（data in use）」を把握することにあたります。分析を実行するために必要な能力の基本的な要件とは別に、インシデント対応チームの有効性を高めるであろう、より高度な能力があります。もし企業が基本的な能力で満足し、より頑強な能力の確立の検討を断念するならば、IOCを発見し、それを体系的に使ってシステム侵害の全貌をつかむことは限定的なものとなり、深刻な被害が発生する前に予防のために侵害を検知することは困難、かつ、多大な費用を伴うものとなるでしょう。本章では、すべての企業が持っているべき基本的なもの、共通的なもの、さらには必須とされる能力と、これらの能力が揃った段階で検討すべき、さらに高度な能力を概説していきます。

第2章　準備

31

図10CSIRTに求められる能力

能力（人材、プロセス、技術）必須推奨

ホストレベルの活動認識 • エンドポイントのソフトウェアエージェントからのログ（例：アンチウイルス）• ネイティブOSログ（例：Microsoft Windows®）

• ホストベースの侵入検知• 全社を対象とした遠隔フォレンジック分析

• エージェントベースのライブメモリー分析

ネットワークレベルの活動認識 • ネットワークフローデータ（例：レイヤー3）• プロキシーのログ• ファイアウォールのログ

• ネットワーク侵入検知のログ• すべての出口におけるフルパケットキャプチャー

• SSL調査

検索システムごとに分散しているログの検索• ローカルのログ• 手作業での取得• 限定的な自動化

• 検索可能なログデータの集約• イベントの相関関係（例：SIEM）

デジタルフォレンジックアドホック、ローカル • 遠隔作業（データ取得）• ケース・マネジメント・システム

マルウェア分析 • 動的なマルウェア分析• 基本的で自動化された静的分析

• 詳細な静的コード分析• リバースエンジニアリング

スレットインテリジェンスアドホック、オープンソースリサーチ • 登録型• ビジネスパートナーとの情報共有

• 反復可能で自動化された統合

脆弱性の特定社内利用されているアプリケーションの一覧作成

全社レベルでの脆弱性の特定

2.7.1 ホストレベルの活動把握企業ネットワークに接続されているホストはすべて、その企業を狙った攻撃の矢面に立つ可能性があります。サーバ、デスクトップワークステーション、ノートPC、プリンター、ネットワーク機器それぞれが、攻撃者によって踏み台とされ、ネットワークへのアクセスを拡大するために悪用される可能性があります。このような活動を検知するためには、各ホスト内で何が起きているのかを理解することが不可欠です。企業の規模によっては、社内のセキュリティ監視部門だけで、全ホストのすべての活動をリアルタイムで分析できないかもしれません。しかしながら、これらのデータは調査が必要な場合には解析し、検索し、理解できるよう、集中管理しておく必要があります。


32

デジタルフォレンジック実施者の最も基本的な仕事は、ホストの活動を時系列に再現することです。これはマシン上のマルウェアの能力をチームが理解する手助けとなり得る他、企業内の他の侵害されたホストを探すための IOCを形にする助けになるかもしれません。こうした情報は、攻撃者の意図を理解する上でも有効です。企業は、公開することで企業の名誉の毀損や損害を与えるための情報を探している政治目的のハッカー（hactivist）を相手にしているのでしょうか ?非常に重要な特許情報が格納されている研究、開発サーバにAPT（Advanced Persistent Threat: 高度で執拗な脅威）を仕掛けようとしているのでしょうか?　それとも動機は単純に金銭目的で、クレジットカード番号や社会保障番号のような個人情報を集めようとしているのでしょうか?　企業は、攻撃者が自分たちのネットワークを侵害した理由を考えなければなりません。攻撃者は何を狙っているのでしょうか?また、なぜ自社が標的にされたのでしょうか?

ホストレベルの活動を把握するためには、ローカルマシンの活動を記録する必要があります。少なくとも、以下の活動がローカルと中央レポジトリの両方に記録されるようにホストの設定は見直すべきです。 • ローカルおよびネットワークへのログオン /ログオフの状況• ウイルス対策ソフトウェアからのアラート• プロセス実行 • アカウント作成 /削除、やグループのメンバーシップの変更 • サービスの作成 /開始 /停止 • ウェブブラウザの履歴• ネットワークセキュリティ機器のALLOW/DENYレコード

必要最低量のログを保存するのに、ログファイルの最大保存容量が十分であるかを確認しておくことは重要です。システムやアプリケーションの初期設定のままでは、場合によっては足りるかもしれませんし、不足する場合もあるかもしれません。Windowsイベントログファイルの最大値（ロールオーバー前で20 MB）は、利用の仕方によっては、一台のワークステーションの数週間分の活動を追跡するには十分かもしれません。しかしながら、頻繁に利用されるサーバやドメインコントローラの場合は、一日分の活動すら記録することはできないかもしれません。問題の発生から数日から数週間が過ぎてもインシデントが発見されない場合、攻撃者の活動に関する貴重な情報が既に上書きされている可能性があります。

攻撃者の中には、サーバを侵害した後で、ログファイル上の痕跡の消去を試みる者もいます。しかしデジタルフォレンジックの専門家は、さまざまなアーティファクト（artifacts: マルウェアを始めとするサイバー攻撃で使われるツールや技術による痕跡）を手掛かりに、ホスト上の活動に相関関係を見つけ出します。システムからアーティファクトを削除しようとする試みは、ベテラン分析担当者に悪意ある活動の存在を強く疑わせるような、新たなアーティファクトを生み出すことが少なくありません。

第2章　準備

33

ログファイル以外にも、極めて重要かつ有用なタイムスタンプを含むシステム上のアーティファクトがあります。以下に、その一例を示します。• ファイルシステムのメタデータレイヤーのタイムスタンプ（MACB（modified、accessed、

changed birthの略）値） • ショートカットやシンボリックリンク等のリンクファイルの生成と関連するタイムスタンプ • レジストリ修正のタイムスタンプ • プリフェッチファイルの作成・修正のタイムスタンプ（プロセス実行のタイミング） • Shellbagsエントリー• 削除された$MFTエントリーのリカバリー • 削除されたレジストリーエントリーのリカバリー • ATジョブやcronジョブといったスケジュールされたタスク

これらのタイムスタンプを順番に分析していけば、攻撃者の行動を鮮明に描き出し、社内ネットワークのどこかで行われている悪意ある活動を特定するための有用な IOCの一覧を作成することができるでしょう。

オープンソースのツールを使って、すべてのデータ構造を解析し、イベント間の相関関係を見つけ出す方法を知っている熟達した分析担当者は、これらのアーティファクトをホストごとに分析できます。しかし、この方法はシステムの規模が大きすぎる場合は利用できません。ホストベースの監視システムの多くは、より高度で集約されたレベルで、この種の分析を実行できます。一般に、最も詳細で意味を持つ IOCは、侵害されたホストで徹底的なフォレンジックを実施した後で生成されます。続いて、企業内のどこかにあるこれらの IOCを検索するために集中型ソリューションを活用し、侵入の範囲をさらに詳しく調べ、調査の際に着目すべきサーバを特定します。

ホストベースの活動の把握においては、ホスト型侵入検知システム（HIDS）、企業レベルでのフォレンジック分析能力とライブメモリー分析能力の導入が推奨されます。HIDSは、SIEM機能を拡張するもので、集中ログ管理だけでなく、ホスト上のアーティファクトを分散検索できます。ログデータ以外のものも検索できるHIDSは、調査担当者に有用な分散検索機能を与えてくれます。以下には、調査担当者がHIDSを使って検索できるものの一例を示します。• ディスク上の悪意あるファイルの存在（ファイルパスごと、ファイル名ごと、ハッシュごと） • サービス • 実行中のプロセス • ネットワーク接続またはサービスを提供可能な状態にあるエージェント


34

2.7.2 ネットワークレベルの活動認識ネットワークレベルの活動に注目し、「移動中のデータ」を可視化することも重要です。ネットワークレベルでの痕跡が、インシデント検知のきっかけとなることは少なくありません。ほとんどのネットワークインフラ機器は、ネットワークトラフィックの計測や分析をするためのNetFlowデータを生成し、それを中央サーバに送る能力を持っています。ネットワークを認識するための最も基本的な方法の一つは、条件検索可能なNetFlowデータを生成することです。NetFlowデータが入手できない場合のもう一つの手段は、ファイアウォールやプロキシーのログを監視することです。多くの企業は、プロキシーデータや少なくとも特定のファイアウォールのルールを記録しているため、プロキシーやファイアウォールを通じて外部と交信しようとしている攻撃者を調べる上で大いに役立ちます。ネットワークレベルの活動を把握するために、最低限必要な情報は以下のとおりです。• タイムスタンプ • 送信元 IPアドレス • 送信先 IPアドレス • ポート番号 • パケットサイズ

同種の情報はファイアウォールやプロキシーからも集められます。これらの情報は、単体では役に立たないかもしれませんが、条件検索可能な形で集約すれば、攻撃に関する有用な結論を導き出せます。また、このような機能は、ネットワークのベースラインを策定する助けにもなり得ます。企業のポリシーや基準を十二分に理解した上で、一定期間にわたってネットワークレベルの行動を監視していくと、詳細な分析を必要とする、ベースラインから逸脱した活動を見つけられます。ただし、このベースラインは企業によって異なるため、調査担当者は企業ネットワーク上のIP空間やホストの役割、およびそれらの標準的な通信方法を理解していなければなりません。企業にもよりますが、以下はベースラインから逸脱している可能性のあるネットワークレベルの活動の例です。• 研究部門および開発部門のサブネット上にあるホスト間との頻繁な通信している事業部門のセグメントに新たに設置されたホスト

• ウェブトラフィックの通信を初期化中のウェブサーバ• 通常は社内での使用が禁止されている、安全性の低いファイル転送方法（例 : FTP、Trivial

FTP [TFTP]）• ネットワーク外から遠隔で管理されている機器（例 : Secure Shell [SSH]、Remote Desktop

Protocol [RDP]、Telnet） • データの受信量を送信量が上回っている、ポート番号80または443のトラフィック• (特定の国との取引を行っていない場合）地理位置情報データとNetFlowデータの重ね合わせによる、多国間とのトラフィックの検索

多くのネットワーク管理チームは、ベースラインとなる痕跡を何ページ分も挙げられます。分析担当者は、これらの痕跡を手掛かりにして、最小限のネットワーク監視能力を使って検索し、アラートを発信します。

第2章　準備

35

ネットワーク分析では、プロトコルデコーダーなどのネットワーク検知機器に投資することが推奨されます。例えばファイアウォールやプロキシーのログ、ネットワーク型侵入検知システム（NIDS: Network-based Intrusion Detection System）、NetFlowデータ、フルパケットキャプチャなどを組み合わせましょう。これらは基準値と一致していない、あるいは管理者が設定した閾値 /基準値を逸脱している異常なトラフィックを探すように設定できます。より詳細な分析をするにあたり、他のデータと併せた検索や、他のデータとの相関関係を調べるために、これらの機器が生成するアラートを中央レポジトリに送信できます。

ネットワーク全体を把握したい場合は、フルパケットキャプチャが有効です。ただし、設計・実装の方法は吟味しなければなりません。フルパケットキャプチャでは、短時間のうちに大量のデータが収集されるため、ソリューションの設計に不備があるとストレージが足りなくなる恐れがあります。フルパケットキャプチャを使えば、セッションを再現し、ネットワークに送信された疑わしいファイルを抽出し、分析できます。フルパケットキャプチャは、持ち出された可能性のあるデータを特定し、マルウェアに感染したインストールファイルの復元を助けることで、マルウェアの分析担当者がシグネチャベースとふるまいベースの（heuristic）IOCを特定することを可能にします。

2.7.3 検索重要なログデータはすぐに利用・検索できるようにしておかなければなりません。調査・駆除段階で検索を効果的に実行できるようにするためには、ログファイルを中央システムログやこれらのデータを格納しているサーバに送ることが不可欠です。基本的な検索機能は、オープンソースのツールを使うか、ログデータ検索用の技術を購入し、カスタムスクリプトを書くことによって実現できます。この機能があれば、ネットワークの可視性は即座に高まり、インシデント対応に必要なデータを保存できます。

企業はまず、各ログソースを定期的に監視するためのプロセスや手順の作成に注力すべきです。この種類の監視の良い候補に挙げられるものとしては、ファイアウォール、プロキシー、アンチウイルスのログなどがあります。例えばアンチウイルスプログラムのログを監視すれば、プログラムが削除・隔離できなかったマルウェアを発見し、対応できます。

さらに成熟した企業は、相関関係を示す、アラートを発信することを実現するログを管理・検索するための拡張性の高いアーキテクチャを有している傾向があります。こうした機能は、現在流通している多くのSIEMソリューションで提供されています。SIEMには2つの検知機能があります。一つは、他の手段で生成されたアラートのためのレポジトリと相関関係のプラットフォームとしての機能、もう一つはネットワークフローと過去ログを基にアラートを発信する機能です。このソリューションは、最初から社内のすべてのログソースをカバーすることを要求されてはいませんが、将来の需要増に応えるためには拡張性は不可欠です。現在流通しているログ管理・検索製品には、この要件を満たしているものがあります。限られた重要なログソースを集約している企業は、オンデマンド検索において素早く回答を得ることができます。これはより高度な相関関係の発見、行動に基づいた不正行為の検知の基盤となります。


36

SIEMを導入する場合、ログは段階的に取り込むようにします。取り込むのは、特定の攻撃者の戦術、方法、手順に合ったログのみとします。誰かの思いつきとか、いつか役に立つかもといった理由でログを取り込んではいけません。不要なログソースを取り込めば、システムに余分な負荷をかけたり、不要なライセンス料金を請求されたりする可能性があります。SIEMを導入した場合は、システムから不要なデータを削除し、最も適切なアラートのみに集中するようにします。最適化された企業は、最も適切なアラートを理解し、明確に定義されたプロセスに沿って、極めて短時間でインシデントを検知し、対応できます。

2.7.4 コンピュータ・フォレンジック分析どんなユーザ活動もホストに無数の足跡を残します。分析担当者はこれらのデータをふるいにかけ、有益なデータを抽出し、それらがユーザ活動を示すアーティファクトなのか、システム活動によるアーティファクトなのかを見極めます。データの中には、ユーザとの対話処理（user interaction）によるシステム活動の結果、記録されたものもあります。こうしたデータは、ユーザの活動についてさらに詳しい情報を得るために活用できます。この技術でもあり科学でもある活動は、一般には「デジタルフォレンジック」と呼ばれています。

フォレンジックは、科学的な手法・技術を使って、刑法・民法上の事実を立証することと考えられてきました。企業は感染の規模を明らかにするために、法的手段に訴えるのではなく、独自に調査するかもしれません。その場合、「フォレンジック」という表現は必ずしも妥当とはいえませんが、たどるプロセスは同じです。基本的には、企業は自らホストが設置されている場所に訪れ、手動でメモリの内容をまとめて書き出し（ダンプ）、フルディスクイメージを取得するアプリケーションを実行することで、徹底したフォレンジックレビューができるようになります。これらの情報は、ホスト上の割り当てられていないディスクスペースを上書きすることがないように、取り外し可能なデバイスかネットワーク上にダンプします。

フォレンジック分析に「必須」「推奨」といったレベルの差はありません。しかし、証拠の取得やケースマネジメントに必要な機器に投資することは可能です。揮発性メモリやフルディスクイメージの取得、証拠のハッシュと遠隔保管といった作業を遠隔から実施してくれる業者もあります。従業員を物理的な場所に派遣するのは時間がかかるため、こうしたサービスは時間の節約になります。事業の性質上、システムを長期間稼働させる必要がある場合は、サーバをシャットダウンし、ドライブを物理的に回収することは難しいかもしれません。また、いくつかの企業は、ワークフローを追跡したり、分析された証跡についての検出事項についての文書を標準化したりしてくれるケース・マネジメント・システムに投資することで分析担当者の成果を整理することに役立てられると考えています。

第2章　準備

37

10 Distler, Dennis; Malware Analysis: An Introduction, SANS Institute, Information Security Reading Room, 2007, page 20, www.sans.org/reading_room/whitepapers/malicious/malware-analysis-introduction_210

11 The Mitre Corporation. “Standardizing Cyber Threat Intelligence Information with the Structured Threat Information eXpression (STIX ™ ),” 2012, http://makingsecuritymeasurable.mitre.org/docs/STIX-Whitepaper.pdf

2.7.5 マルウェア分析マルウェア分析には、基本的に「動的分析」と「静的分析」の2種類があります。どちらも分析担当者やリバースエンジニアに、マルウェアの目的、方法、影響、およびマルウェアの機能や出所に関するIOCを理解するための情報を与えてくれます。しかしながら、「動的分析」と「静的分析」はそれらの結論を導き出すまでに異なった方法を利用します。例えば動的分析の自動化フォームは、調査・駆除を効果的に進めるための必須能力ですが、推奨されているのは両方の分析手法の利点を活かし、調査段階でできるかぎりの情報を発見することです。

動的なマルウェア分析では、制御・抑制された環境（通常は仮想環境）で潜在的マルウェアを実行し、その行動を観察します。この環境には、実行ファイルの行動を監視するセンサーが仕込まれています。ここでいう実行ファイルとは、ディスクに書き込まれたファイル、ネットワークトラフィック、修正されたレジストリキー、生成プロセスなどです。動的分析を自動化すると、静的分析よりもはるかに速く分析を完了でき、一般的に技術的リソースもあまり必要としません。しかし動的分析では、マルウェアを最小単位まで分解することはできないため、分析の精度には限界があります。

動的分析は、静的マルウェア分析と組み合わせて行うとよいでしょう。静的分析には、リバースエンジニアリングや、コードの一部を取り出して、その中身や機能を分析することなどが含まれます。静的分析で用いられるツールは、逆アセンブラ、デバッガー、逆コンパイラなどです。最終目標はマルウェアのソースコード、つまりコードの最も基本的な部分にアクセスすることです。セキュリティ専門家のデニス・ディストラーが書いているように、「コード分析の実行中は、ウイルス対策ソフトウェアがマルウェアの上で動作し、文字列検索が実行され、シェルスクリプトなどのファイルが分析される」ことになります 10。高度な標的型攻撃では、攻撃者の意図と正体はさらに明確になります。たいていのマルウェアは何らかの指揮統制機能を備えており、感染したシステムの制御権の獲得や、攻撃者に対して情報の送信ができるため、攻撃者を推定する手掛かりになります。しかし、マルウェアは進化を続けています。マルウェアの中には、不正使用を発見するためのツールを検知時には、自分を無害な存在であるように見せかけたり、目的を隠したりする機能を備えたものもあります。

2.7.6 サイバー情報収集活動自社のネットワークセキュリティを強化するためには、準備活動の一環として、社外の脅威にも目を向ける必要があります。脅威をプロファイリングすることで、最も強い動機を持ち、最も高い確率で攻撃を成功させられる攻撃者を特定できます。論理的な防衛判断を迅速に下すためには、社内と社外の両方にバランスよく目を向けていく必要があります 11。


38

サイバー攻撃の脅威についての情報収集活動とは、言い換えれば悪意ある攻撃者を研究し、その能力、動機、予想される行動を見極めることです。こうした情報収集活動を実行し、その成果を適用していくことで、セキュリティチームは攻撃者の戦術、方法、手順をより明確に理解できます。攻撃活動を遮断したり、抑制したりすることで、攻撃者を打ち負かすことさえできるもしれません。しかも、情報収集活動は、セキュリティチームが攻撃を知らされてから（たいていは被害の発生からだいぶ経ってから）対策に乗り出すのではなく、攻撃者が攻撃の準備を整えている段階や最初の攻撃が起きた段階で、攻撃を検知さえできる可能性があります（図11）。

図11サイバー情報収集が攻撃のライフサイクルに与える潜在的影響

情報の収集

背景の調査最初の攻撃足場の確保潜伏社内

ネットワークの偵察

アクセス範囲の拡大

目的情報の収集と暗号化

侵入したシステムからのデータの持ち出し

潜伏の継続

最初の悪用

標的となった企業が、強力なスレットインテリジェンスにより攻撃を検知するタイミング

ほとんどの標的企業が攻撃を知るタイミング

（通常はサードパーティから）

指揮・統制

攻撃検知にかかる期間の短縮

特権獲得データの持ち出し

特権獲得

脅威情報は、システム侵害が既に起きたことを示す重要な IOCにもなり得ます。こうした情報は、攻撃者がネットワーク内に足場を固めるまで入ってこないかもしれませんが、ネットワークSIEMとログを検索し、侵害の証拠を見つけるために利用できます。

注目すべき脅威情報を見極めるためには、企業はいくつかの質問に答える必要があります。「私たちを攻撃したいと考えているのは誰か?」「私たちのシステムの弱点はどこか ?」「社内にはどんな機器があり、各機器にはどんな弱点があるのか?」―こうした問いは、大量の情報から定期的に検証するために、適切な情報量を取捨選択する助けになります。

脅威情報はさまざまな方法で入手できます。理想的とはいえませんが、最も一般的なのは場当たり的な情報収集です。例えばセキュリティチームのメンバーが知人から無作為に情報を受け取るとか、技術系のウェブサイトを見て回っているときに有益な情報を見かけるとか、社内ネットワークで利用されている設定やツールに関するニュース記事を見るといった形態の情報収集です。

第2章　準備

39

12 Verizon, “2012 Data Breach Investigations Report,” 2012, www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2012-ebk_en_xg.pdf 13 Red Sky Alliance, www.redskyalliance.org 14 Lange, Captain Adam M., USAFR; Captain Mark G. Manglicmot, USAFR, “Merging Industry Best Practices, Intelligence

Improvements, and Adversary Analysis to Enhance Cyber Defense,” Air and Space Power Journal, 2013 15 Shalal-Esa, Andrea, “Lockheed, Intel, Others Team up to Tackle Cyber Challenges,” Reuters, 24 October 2012, www.reuters.com/article/2012/10/25/net-us-cyber-companies-idUSBRE89O0312012102516 Ibid.,

場当たり的な情報収集より一段進んだ情報収集方法としては、脅威の研究を反復的なタスク、兼任の仕事、あるいは専任の調査業務とすることがあります。この方法が上手くいくかは、スタッフのスキル、脅威の内容や検索場所についての知識、あるいは運に左右されます。

ほとんどの企業にとって有効な方法の一つは、脅威データの定期的な収集です。Webサイトのフィードに登録する利点はいくつもあります。さまざまな専門会社、アンチウイルスベンダー、その他のセキュリティプロバイダーが、カスタマイズ可能な法人向けサービスを提供しています。こうした企業は世界中のエンドポイントやソースのフィードを集め、傾向や異常を分析し、価値あるデータを登録者に提供しています。

サービス提供会社はデータ分析が完了すると、その結果をさまざまな報告書にまとめて、登録者に提供します。例えば脆弱性報告書には、特定のソフトウェアやハードウェアで発見されたセキュリティホールが記載されます。速報ニュースの目的は、現在進行中のイベントに関する情報をセキュリティチームに知らせ、注意を喚起することです。悪質なコードに関する報告書はマルウェアの性質、攻撃方法、影響を細かく分析したもの、同様に脅威報告書はAPTレベルまでの具体的な攻撃者の情報を伝えるものです。これらのサードパーティベンダーは、多様な企業の情報にアクセスできるため、単独で調査を進めている企業よりも広範に分析を実行できます 12。これらの報告書は、セキュリティチームの要望に合わせて、業界別にカスタマイズすることも可能です。

多くの業界では、脅威情報をリアルタイム分析の担当者からシニアリーダーまで、さまざまなレベルで共有しています。最高情報セキュリティ責任者（CISO）は、会議やトップ会談などで定期的に集まり、最新動向を情報収集しています。分析担当者は、適切な場合には他の分析担当者に問い合わせることができます。公式・非公式を問わず、情報共有のためのパートナーシップはいくつもあります。その一つが ISAC（Information Sharing and Analysis Center: セクター別の情報共有・分析センター）です。商業的なパートナーシップの例としては、「レッド・スカイ・アライアンス」があります 13。このアライアンスのメンバーは、対APT研究に共同で取り組んだり、データを交換したり、詳細な ICO表に登録したりしています。この表は、APTの標的となっている業界の報告書をまとめ、読者向けに一覧化したものです。

業界パートナーシップも脅威情報の情報源となります。企業は将来の競合他社と脅威情報を共有し、共通の敵に対して共同戦線を張ることで利益を得ています 14。技術セクターでは、複数の大手技術企業が「CSRA（Cyber Security Research Alliance）」15を共同で立ち上げ、単にデータや報告書を共有するだけでなく、画期的な技術を開発することで、「大いなる課題」に取り組もうとしています。この非営利アライアンスでは、メンバー企業が力を合わせて、長期的で先進的なネットワーク・セキュリティ・ソリューションを開発しようとしています 16。


40

カスタムAPT-標的型マルウェアに取り組んでいる業界や企業にとって、こうしたデータ共有は有益です。VirusTotalのような無料アンチウイルスサービスも、出発点としては悪くありませんが、高度な攻撃に対処するには不十分です 17。たとえこの方法で一つのウイルスを撃退できたとしても、初期の感染経路（フィッシング）、指揮統制のパラメーターなど、APTに利用できるものは他にもたくさんあります。しかも高度な攻撃者は、自分たちのマルウェアをばらまく前に、それがアンチウイルスソフトウェアで検出されるかを確認しているため、脆弱性が見つかればコーディングをやり直し、作戦を続行します。つまりアンチウイルスサービスを使ったからといって、標的企業の安全性は高まるとはいえないのです。

US-CERT（US Computer Emergency Readiness Team: 米国国土安全保障省傘下のセキュリティ対応チーム）は以前から、個人、企業、政府、および ICS（Internet Connection Sharing）ネットワークの専門家と戦略・技術レポートを共有しています。US-CERTの官民連携窓口であるNational Council of ISACsは、セクターに焦点を合わせて、実効性のある脅威情報諜報活動を展開している専門機関です 18。US-CERTはウェブサイトを通じて、フィッシングやインシデント、ソフトウェアの脆弱性に関する情報提供をユーザに呼びかけ、それとその代わりに毎日の脅威アラート、脆弱性分析、マルウェア関連の調査文書を発行しています。

米軍では数年前から、分析担当者間で IOCが共有されてきました。こうした個人的関係が発展して生まれたのが、毎年開催されるCERTCON（軍のコンピュータネットワーク防御サービスプロバイダーの草の根カンファレンス）です。このカンファレンスを機に、米軍はアイディア、ツール、プロセス、事例研究の共有を公式に開始しました。まずは傾向と教訓を共有し、次にさまざまなIOCをリアルタイムで共有する―この米軍のモデルは多くの業界の手本となるでしょう19。

確かに、業界内での情報共有、つまり将来の競合他社や他のセキュリティ情報源と情報を共有することは、最初は受け入れにくいかもしれません。しかし、もしすべての関係者が平等に参加するなら、得られる利益はコストを上回ります。企業は自立とベンダーへの過度な依存との間で最適のバランスを模索するようになるでしょう。自立の道を選んだグループは、信頼できるビジネスパートナーとすらIOCを共有せず、独自のやり方でインシデントに対応しようとします。しかしこれは、実質的には何の品質の保証もないまま行動することになります。一方、外部のベンダーの支援に依存している企業は、以前は関係者しか知らなかったようなセキュリティイベントが、広く社外の人（々APTの攻撃者にすら）に知られるという事態に直面するかもしれません。

17 VirusTotal, www.virustotal.com/ 18 Pelgrin, Will, “The Role of Information Sharing And Analysis Centers (ISACs) in Private/Public Sector Critical

Infrastructure Protection,” January 2009, pp. 1-2, www.isaccouncil.org/index.php?option=com_docman&task=doc_download&gid=1&Itemid 19 Op cit, Lange and Manglicmot

第2章　準備

41

20 NIST, “Computer Security Incident Handling Guide,” SP 800-61, 2012, http://csrc.nist.gov/publications/drafts/800-61-rev2/draft-sp800-61rev2.pdf

脅威情報を最近のログの評価と組み合わせれば、高度なトラフィック分析が可能になります。NIST（National Institute of Standards and Technology: 米国標準技術局）がSP 800-61で推奨している分析活動は、利用動向だけでなく、高度な対象となる攻撃者を発見するためにも利用できます 20。対象の攻撃は検知を避けるために、通常のトラフィックに紛れ込もうとする場合もあります。その場合は、熟達したログ分析担当者にしか、その存在を発見できないかもしれません。対象の攻撃者は、ネットワーク上の痕跡をなるべく小さくするために、検出の閾値を超えないように行動することもあります。熟達したログ分析担当者は、こうした「時間をかけて少しずつ行う」とした動きに注目することで、特異な活動を見つけ、それを正当な、あるいは正当でないトラフィックと関連づけます。

高度なトラフィック分析は、ネットワーク傾向から逸脱した動きを発見する助けにもなります。このような動きを察知したときは、さらに詳細に分析するようにします。検討すべき傾向には次のようなものがあります。• セキュリティインシデントが最も頻繁に起きている場所はどこか?（部門、場所、機器の種類）• 最も頻繁に発生しているインシデントの種類は何か?（マルウェア、キーロギング、フィッシングによるインシデント、ソーシャルメディア関連攻撃の具体的な種類）

• インシデントは速やかに解決できるか?（ログの取得、ネットワークの可視性、利用規定・調査ポリシー、ユーザの協力度）

• 最近、発信されたIDS/IPS/SIEMアラートにはどのようなものがあるか?　アラート発信のきっかけになったものは何か?　情報 /侵害のソースは何か?

2.7.7 脆弱性の特定セキュリティチームは、全社規模の詳細な脆弱性スキャンを定期的に実施する必要があります。頻度は企業の規模によりますが、スキャンはネットワークセグメントごとに段階的に実施する必要があるかもしれません。中小企業なら四半期ごとのスキャンで十分かもしれませんが、大企業の場合は月に一度は実施する必要があるでしょう。

どんなスケジュールを選ぶにせよ、脆弱性スキャンの目的は既知の脆弱性に対して無防備な状態にある社内の機器を発見することです。重要なのは、スキャンを実施し、その結果を分析し、何者かによって脆弱性が発見され、悪用される前に、発見された問題を解決することです。

企業向けスキャナーには、無料のものと登録制のものがあります。最終的な目標はどれも同じですが、スキャン対象のデータ、OS、ハードウェアの種類には違いがあります。スキャナーによって特徴があるため、スキャナーを選ぶ際は、評価対象の機器にスキャナーが及ぼす影響や評価の精度を比較します。


42

スキャンが完了したら、脆弱性は体系的に対処されるべきです。たいていの場合、問題に対処するためのパッチや更新ファイルは各ベンダーから提供されています。事業や政治上の理由から、特定のシステムへのパッチ適用が遅れる場合もあるでしょう。これは上層部への定期的な状況報告が効果を発揮するケースであり、セキュリティ強化の必要性を関係者に説得するためにも活用できます。

更新ファイルが適用できない場合は、システムの監視を強化する方法を見つけなければなりません。脆弱性が見つかった場合は、当該システムを対象に、さらに詳細なトラフィック分析を実行します（高度な攻撃者であれば、既にシステムへの侵入を成功させているはずです）。脆弱性スキャンは主に予防のためのツールとして使われていますが、会社全体の検知機能の一部と捉えることもできます。情報セキュリティの格言にあるように、「予防は理想、検知は必須」なのです。

第3章　調査

43

第3章　調査 3.1 セキュリティ侵犯の調査どの調査においても、核となるのは問題に関連した事実を収集し、分析することです。サイバー侵犯に関する事実は、目撃者の証言、インフラのログ、コンピューターシステム、サードパーティなど、複数の情報源から集めることができます。APT（Advanced Persistent Threat: 高度で執拗な脅威）によるサイバー攻撃の場合は、駆除・改善計画に寄与する情報を提供することが、調査の主目的となります。駆除計画は通常、攻撃者を当該環境から排除することを目的としていますが、これを成功させるためには以下の2点が必要です。• 攻撃者の戦術、手法、手順、意図に関する詳しい情報• 侵害されたシステム、盗み出された認証情報、狙われたデータ、アクセスを維持するために攻撃者が使った（または使っている）C&C（command-and-control: 指令・制御）システムについての知識

駆除計画の詳細は第4章をご覧ください。

事実の収集・分析は、簡単には進まないものです（例 : まずは聞き取りを実施し、次にログをレビューおよび・分析する）。事実の収集は、動的、流動的、かつ、循環的なプロセスであり、正しい判断力と経験が求められます。新しい情報が見つかった、当初の仮定が正しかった（あるいは間違っていた）ことがわかった、といった状況に応じて、最初からやり直さなければならないこともあります。したがって、調査は聞き取りから着手し、次にログレビューを実施し、さらに入手した新しい情報を元に補足的な聞き取りを行うといった流れで進むこともあります。インシデント対応（または調査）のプロセスは、「特定」「封じ込め」「駆除」「復旧」「フォローアップ」の5つのフェーズに分けられます（図12）。

これらのフェーズは連続したものではありますが、各フェーズは完全に独立しているわけではありません。調査の内容によっては、重複、あるいは繰り返し実行されることもあります。しかし、「特定されなかったインシデントは封じ込めることはできず、そのインシデントは駆除できない」という事実に変わりはありません。

以下は、インシデント対応プロセスの主な目標です。 • 特定　関連するデータソースをすべて特定する。 • 保全　これらのデータをフォレンジック的に適切な方法で保全する。 • 分析　データを分析し、問題と関連している事実を見つける。 • 報告　発見事項を報告する。


44

図12インシデント対応のプロセス

特定

段階的な実施

フォローアップ

復旧駆

除

封じ込め

経営の視点

実務

上記のモデルの他に、NIST（National Institute of Standards and Technology: 米国の国立標準技術研究所）やSANSインスティテュートが公開しているインシデント対応モデルも高い評価を得ています。以下は、サイバー攻撃の調査方法を論じた公開資料や優れたガイドラインのうち、インターネット上で閲覧できるものの例です。• Computer Security Incident Handling Guide （コンピュータインシデント対応ガイド） http://csrc.nist.gov/publications/drafts/800-61-rev2/draft-sp800-61rev2.pdf • Guide to Industrial Control Systems (ICS) Security http://csrc.nist.gov/publications/nistpubs/800-82/SP800-82-final.pdf • Guide to Malware Incident Prevention and Handling （マルウェアによるインシデントの防止と対応のためのガイド）

http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf • Guide to Integrating Forensic Techniques into Incident Response （インシデント対応へのフォレンジック技法の統合に関するガイド）

http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf • http://computer-forensics.sans.orgに掲載されている幅広い情報 : 例 : An Incident Handling Process for Small and Medium Businesses （http://www.sans.org/reading_room/whitepapers/incident/incident-handlingprocess-

small-medium-businesses_1791でも閲覧可）

SANSのモデルは「PICERL（準備（Preparation）、識別（Identification）、封じ込め（Containment）、駆除（Eradication）、復旧（Recovery）、教訓（Lessons learned））」と呼ばれています。NISTのモデルは、複数のステップを4つのフェーズ（準備、検知と分析、封じ込め・駆除・復旧、事後対応）にまとめています（図13）。

第3章　調査

45

図13インシデント対応のライフサイクル（NIST SP 800-61）

準備検知・分析封じ込め・駆除・復旧事後対応

出典 : Cichonski, Paul; Tom Millar; Tim Grance; Karen Scarfone; Computer Security Incident Handing Guide, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-61, Revision 2, USA, August 2012.

NISTモデルが示唆しているように、インシデント対応チームはインシデントが解決され、事後対応が始まるまでに、「検知・分析」のフェーズと「封じ込め・駆除・復旧」のフェーズを繰り返す可能性があります。調査の中心は「検知・分析」フェーズであり、駆除は基本的に「封じ込め・駆除・復旧」フェーズで行われます。サイバー侵犯調査のフレームワークとして、どのモデルを採用するにせよ、主たる目的は変わりません。それは、「誰が、何を、いつ、どこで、なぜ、どのように」という基本的な問いに答えることであり、より重要なことは、その答えを駆除計画に活かすことです。以下は、サイバー侵犯調査の目的です。• 攻撃者の戦術、手法および手順、そして可能ならば意図を理解し、その情報を駆除計画に活かす。

• 侵害の範囲と規模を明らかにし、その情報を（社内外の）利害関係者に伝える。– 活動1　当該侵害と関係する、さまざまな電子記録を収集する。– 活動2　収集したデータを調査に有用な情報に変換する。– 活動3　これらの情報を分析し、侵害の詳細（誰が、何を、いつ、どこで、なぜ、どのように）を明らかにする。

– 活動4　利害関係者に詳細を報告する。


46

コモディティ化したマルウェア（エクスプロイトキット等を用いて作成される特殊性が見出しにくいマルウェア）によって、外部で生じたセキュリティインシデントやセキュリティ侵犯は、たいていは社内に既に導入されているセキュリティメカニズムによって検知できます。しかし、高度で執拗でかつ洗練された攻撃者により攻撃を受けている企業が、国内の捜査当局や情報収集組織によって攻撃を知らされているケースが良く見られます。企業が独力で攻撃を検知できた例はほとんどありません。

攻撃の事実を知った経営陣は、調査の実施により解明されることとなるさまざま質問を抱くことになります。中でも重要なのは、「誰が攻撃しているのか ?」「攻撃はいつ起きたのか ?」「何が奪われたのか?」「攻撃の目的は何か?」といった質問です。一般に、経営陣は攻撃の手法や場所にはあまり関心を示しませんが、侵害の範囲や深度、および広がりを理解するために、調査チームがこうした質問にもきちんと答えられるように対処することを期待します。

調査チームは攻撃者の戦術、手法、手順―端的に言えば、「攻撃はどのようにして起きたのか?」―の理解に努める一方、同じタイミングで駆除チームは駆除イベントの計画に着手します。調査・駆除チームが自らの役割、責任、期待を理解できるように、適切なガイダンスが提供される必要があります。計画には必ず、必要な意思決定を迅速に下せる権限をチームに与えることのリスク分析を盛り込む必要があります。

調査開始前に、追跡プロセスを細かく設計しておくと良いでしょう。もし既に追跡機能を持つケースマネジメントやチケットソフトウェアを導入しているのであれば、そのソフトウェアを計画の中で使用することは可能です。しかしサイバー侵犯調査では、こうしたシステムから一般的に得られる情報よりも詳細な情報が求められることがあります。標準的なヘルプデスク・チケット追跡システムは、ワークフローの段階を決定するのには適していますが、サイバー侵犯における調査追跡プロセスにおいては、協力を促進し、極めて技術的な情報を保管し、直接的には関係のない複数の活動を同時に管理することが求められます。

アラートを受け取ったら、その情報がどこ（IDSアラート、ユーザ報告、ログ分析、システム管理者報告など）から来たかを問わず、一貫した方法で追跡されるべきです。そうすることで、原因、属性、応答時間の長期間にわたる傾向分析を可能にします。こうした傾向により、セキュリティチームは、ネットワークの保護と迅速なインシデント解決の両方に必要な適切なリソースを配備する必要性について経営陣に提言できるようになります。

インターネット上には、しかるべき情報源が調査の方法を詳細に説明した資料がいくつもあります。どのアプローチを採用するかは、企業が現状利用可能か、あるいはすぐに入手・実装できる技術ツールにより決まります。例えば、全社横断的なフォレンジック機能は必要になります。この機能がなければ、調査は難航することになります。

第3章　調査

47

どのような照会の仕方を採用するにせよ、以降の質問への回答に重点を置くことは、会社を正しい方向に導くことにつながります。

3.2 誰が攻撃しているのか? これは一般に「属性（attribution）」と呼ばれるもので、この質問への回答は調査の他の面でも役立ちます。ある攻撃者は特定の業界を標的とするか、もしくは特定の種類の情報を入手しようとします。もし攻撃者Xが主に財務データを狙っているのであれば、その情報により財務システムを調査することになります。この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙げられます。• 攻撃者は特定の政治目的のハッカー（hactivist）や組織と関わりを持っているか? • 攻撃者は外国政府から資金提供を受けているか? • 攻撃者は競合他社から資金提供を受けているか?• 攻撃グループは複数か?　その場合協力しあっている複数のグループか?• 複数の攻撃者が連携して活動しているのか? • 攻撃者は米国の捜査当局や情報機関から監視されているか?• 攻撃者は攻撃経路として第三者（例 : 請負業者、クライアント、合弁会社）を使っているか?• 攻撃者に協力している内部関係者入るか?• 攻撃者は会社の施設やネットワークに物理的にアクセスできるか ?会社の海外オフィスにアクセスできるか ?

調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。• 攻撃は誰から通知されたか（例 : 捜査当局、社外のサードパーティ、社内の人物 /プロセス）?　いつ通知されたか?　どのように通知されたか?

• 攻撃の詳細を知っているのは誰か（例 : 従業員、請負業者、ベンダー、クライアント、捜査当局、その他）? 調査・改善活動の責任者は誰か（例 : プロジェクト管理オフィス［PMO］）?

• 社外からサポートを受けているか ?　我々の調査・改善活動の実施を認識しているのは誰か（例 : 従業員、請負業者、ベンダー、クライアント、その他）?

3.3 何が標的とされたか? まず初めに、攻撃者が接触したシステムのリストが、この質問への回答となります。少なくとも、これらのシステムは改善活動に含める必要があります。攻撃者が接触したシステムについての情報は、他の質問に回答する上でも役立ちます。この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙げられます。 • 攻撃者は何を狙っているのか?　彼らの目的は何か?• 攻撃者の目的は既に達成されたか?　どのデータが持ち出されたか? • 会社の最重要データは危険にさらされたか? • どのコンピュータがマルウェアに感染したか?


48

• 攻撃者がアクセスした（が侵害はされなかった）コンピュータはどれか ?　攻撃者が侵害したのはどのアカウントか ?

• 攻撃者がアクセスないし侵害したネットワーク機器は何か（例 : ルーター、ファイアウォール、スイッチ、プリンター）?

• 攻撃者がC&Cのために使用しているネットワーク/ドメイン /IPアドレスは何か? • C&Cネットワークを隠ぺいするために、攻撃者は第三者のシステムを使っているか?

調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。• 外部の脅威に関する情報源との攻撃者に関する情報の連携の関係性はどのような状況か? • 攻撃について、既にマスコミに発表されている内容は何か?• 攻撃に関する情報がマスコミや一般市民に漏れた場合、外部向けの声明をどのように準備しているか ?

3.4 さまざまな事象はいつ起きたのか? 調査の重要なポイントの一つが時系列情報です。時系列情報は事象を大局から捉える助けになるでしょう。調査を実行すると、事象全体の時系列情報はもちろん、接触を受けたシステムごとの詳細な時系列情報も明らかになります。この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙げられます。• 最初の攻撃活動はいつ起きたか?• 攻撃者はいつから潜伏しているか? • 最後の攻撃活動が起きたのはいつか? • 攻撃に明らかなパターンはあるか（時間帯、曜日、週末、祝日など）? • 攻撃のタイミングは、会社が重要な情報を発表したタイミングと一致しているか?

調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。• 取締役会やその他の利害関係者に初めて詳細を説明するのはいつがいいか?• 取締役会 /利害関係者には、どのようなスケジュールで補足説明するか? • 攻撃者のアクセスを遮断するための改善計画をいつ実行するか?

3.5 攻撃はどこから来ているのか? 攻撃の出元を見つけるための質問としては、以下のようなものが挙げられます。 • 最初の攻撃経路は、インターネット上の正当なホストが侵害され、「水飲み場 /たまり場（watering hole: 標的がよく使うWebサイトにウイルス感染の罠を仕掛ける）」に仕立てられたものだったのか ?

• 取引先企業をかたったフィッシングメールか? • 侵害されている疑いのある社外のホストか?

第3章　調査

49

この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙げられます。 • 最初の攻撃はどこから始まったのか? • 最初の攻撃では、攻撃者はどこを狙ったのか?• バックドアアクセスはどこにしかれているか?• 攻撃者は他にどこを探索しているか（地理的位置、事業部、オフィス、役割）? • リポジトリ（データの格納場所）はどこに設置されているか?

調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。• 環境全体を眺めたとき、攻撃に対して最も脆弱な部分はどこか?• その脆弱性は、合弁事業のパートナー、クライアント、顧客、その他のサードパーティ取引関係者のリスクを高めているか?

• 最も重要なデータは何か?　それらのデータはどのくらい強固に守られているか? • 重要情報の一覧が最後に更新されたのはいつか?　重要情報の例 :

– 幹部のコミュニケーションや意思決定 – 人事 /法務に関するデータ – 特許 /登録商標 /企業秘密に関するデータ– 合併 /買収 /会社分割に関する計画と進捗状況 – 研究 /エンジニアリング /製造に関するデータ– PCI（Payment Card Industry: クレジットカード業界）制御データ – 個人情報 – その他の重要データ

3.6 なぜ攻撃されたのか? 攻撃の理由を明らかにするための質問としては、以下のようなものが挙げられます。 • 攻撃者が狙っていたのは知的財産か、それとも財務情報か?• 企業の意思決定に影響を及ぼそうとしていたのか? • 将来の攻撃に利用できる認証情報を集めようとしていたのか? • 別の人物に対する攻撃を実現するためのものだったのか?

この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙げられます。• マルウェアに感染したコンピュータ内のデータは、攻撃の動機を示唆しているか? • 攻撃者がアクセスしたコンピュータ内のデータは、攻撃の動機を示唆しているか? • 攻撃者が侵害したアカウントは、攻撃の動機を示唆しているか?• 攻撃のタイミングは、攻撃の動機を示唆しているか? • 持ち出されたデータは、攻撃の動機を示唆しているか?• 攻撃者のネットワーク偵察は、攻撃の動機を示唆しているか? • 攻撃の動機を示唆するような攻撃者がネットワーク内で侵入拡大する動きの傾向があるか?


50

調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。• なぜ最初の攻撃を検知できなかったのか? • なぜ攻撃の事象が拡大していく過程で検知できなかったのか?

3.7 攻撃者はどのように侵入し、潜伏し、データを持ち出したのか?これは調査の中で、最も技術的な難度の高い部分であり、幅広いスキル（数例を挙げると、ネットワーク分析、フォレンジック分析、リバースエンジニアリングなど）と豊富な経験を兼ね備えた調査担当者が求められます。この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙げられます。 • 攻撃者が攻撃経路として使用したのは、Eメールか、クラウドか、ソーシャルか、それともモバイルか?

• 攻撃の標的となったのは従業員が所有する機器か、それとも企業が所有・管理する資産か? • 会社のウェブサイト上で、攻撃を容易にするようなデータを公開していたか?• 攻撃者はどうやって我々の環境への継続的なアクセスを手に入れたのか?• 攻撃者はどのように偵察を実行しているか? • 攻撃者はどのようにローカルからドメイン管理者へ権限を昇格させたのか?• 攻撃者は我々の環境内でどのようにして移動しているか? • 最初の攻撃後、攻撃者はどのように足場を拡大したか?• 攻撃者はどうやって目的のデータを探し、見つけているか? • 攻撃者はどうやってデータを持ち出しているか?

調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。• どうすれば、これらの攻撃やその他の攻撃から自社をより上手く防御することができるか?• 今回の事象のどのような事実が従業員向けの意識向上プログラムを強化するために利用できるか?

• 従業員や幹部職員は、新たな攻撃を招くような情報をソーシャルメディアサイトで公開していないか ?

3.8 その他検討が必要な重要分野これまで触れてきた6つの基本的質問の他にも、調査において検討すべき追加の質問の一覧があります（付録A）。これらの質問への回答は、経営陣へ伝えられる必要があります。調査チームは必ずしも最適の回答者ではないかもしれませんが、経営陣や取締役会は遅かれ早かれ、これらの質問の一部あるいはすべてを尋ねてきます。したがって、これらの質問に答えられるように準備をしておくことが必要です。

良いとされる調査・駆除計画には、IOC（Indicator Of Compromise: 脅威が存在することを示す痕跡）の特定に関わる人、プロセス、技術がまとめられています。セキュリティ侵犯を特定するための情報源はいくつもありますが、ほとんどの場合、侵犯はまず外部の情報源によって発見され、何らかの方法で被害を受けた組織に伝えられます。伝えられる情報はあいまいなことが多いため、具体的にどのシステムが侵害されたのかを明らかにするには、さらなる調査が必要になり

第3章　調査

51

ます。例えば、もし侵害の事実が連邦政府機関から通知された場合、被害を受けた組織に伝えられるのは「既知の悪意あるIPアドレスやドメイン名から大量の情報が送られた形跡がある」という情報だけです。よって、被害を受けた組織は、送信先の国も、IPアドレスも、ドメインもわからないということがよくあります。

その他の IOCに関する情報源となるかもしれないものには以下のものがあります。 • 外部の情報源（政府、ビジネスパートナー、脅威情報に関する情報配信） • セキュリティ監視・対応プロセス • ネットワークやエンドポイントの自動分析機能 • 脆弱性スキャンのフォローアップ分析 • 侵入テスト • ユーザからの報告• 脅威情報に関する情報配信

3.9 情報収集の質攻撃が起きた際に、経営陣が調査チームに尋ねるのは前述した質問の一部かもしれないし、全てかもしれません。これらの質問に答えられるように準備をしておくことは、時には大変な作業となり得ます。調査チームは、経営陣と進んで率直に対話することが求められます。サイバー侵犯の調査は「責任のなすりあい」になるべきではありませんが、経営陣は当然ながら「誰が何を知っていたのか」「いつ知ったのか」「得られた情報に対して、どんな対応をとったか（あるいはとらなかったか）」と尋ねてきます。これらの質問を避けてとおることはできません。

調査チームは経営陣の質問に回答し、収集した情報を提供できなければなりません。企業のリーダーは、時には正確な情報がないまま決断を下さなければなりません。そのため、自らの意思決定の拠り所となる情報の質を理解している必要があるのです。

前述した質問への回答は、調査だけでなく、セキュリティ関連のさまざまなプログラムに活用されます。すべての情報を記録し、集めた情報を調査関係者やその他の人々に提供し、状況を細部まで理解するためには、適切な文書化と関係者との連携が不可欠です。

このように調査チームが対応すべきことはたくさんありますが、今日の攻撃者の能力や執拗さを考えると、企業の防御手段に少しでもすきがあれば、そこを突かれることになってしまいます。

3.10 証拠の取り扱い証拠を適切に取り扱うことは、企業や経営の観点から見て優れた実践であるだけでなく、刑事・民事訴訟において、証拠が却下される可能性を最小化することにつながります。


52

そのためには、調査期間中に収集され、保全され、分析された証拠資料が変更されていないことを証明できることが重要です。提出された証拠が完全なものか、それとも変更されたのかと追及することや、被告の無罪を証明するような証拠が不適切かつ意図的に排除されているのではないかと追及することは、法廷で被告側弁護士がよく使うテクニックの一つです。

以降で、証拠の正当性を疑われるリスクを最小化するために、調査担当者が活用できるテクニックや優れた実践について簡単に触れます。もちろん、こうしたアドバイスは顧問弁護士の指示にとって代わるものではありません。

3.10.1 文書の保全と収集調査の着手時より、文書やメモの保全と収集を同時に行っていくことは必要不可欠です。複雑な調査の過程で、数十から数百のハードドライブが保全され、何百ものログファイルがコピーされ、何千ものシステムアーティファクト（artifacts: マルウェアを始めとするサイバー攻撃で使われるツールや技術による痕跡）が特定され、抽出されることがあるかもしれません。文書を保全・収集する際には、以下の点に留意すべきです。 • 各証拠の出所（ホスト、人物） • 証拠の保全・収集日• その証拠を収集した調査担当者の氏名 • 保全・収集の環境と手法 • 収集した証拠の追跡（番号やインデックスを使用）• 証拠の収集・処理過程で明らかになった例外（例 : セクター読み込みエラー、ログファイルの部分的欠落）

3.10.2 証拠保管の連続性証拠、特に証拠原本は、調査担当者だけがアクセスできる、鍵のかかる保管室や引き出しの中に入れ、適切に保管することが重要です。調査担当者以外の人物が分析のために証拠を必要とする際、または、証跡の保護が移送する必要がある際の（例 : 社内の調査担当者から捜査当局へ）、証拠の「貸し出し」手順を定めるべきです。証拠を移送する際は、以下の情報とともに追跡できるようにします。 • 移送先担当者の氏名 • 移送元担当者の氏名• 移送日時• 移送方法（手渡し、または配送サービスを利用） • 追跡番号（該当する場合）

第3章　調査

53

3.10.3 MD5ハッシュ値の取得証拠のMD5ハッシュ値の取得は、収集したデータのフォレンジック用コピーが、元のデータとフォレンジック的に同一のものであることを証明するために広く認められている方法です。このハッシュ値は、物理的機器レベルでも（例 : ディスク全体のフォレンジックイメージを作成する場合）、各ファイルレベルでも（例 : 各ログファイルのコピー）生成できます。データのイメージを作成するとき、あるいは収集するときに、証拠原本とそのコピーの両方に対してMD5値を求め、両者が一致しない場合はデータの収集時点で対処するようにします。イメージを作成する過程で読み込み・書き込みエラーが発生したとき、あるいはデータの収集中に元データが変更されたとき（例 : 稼働中システムでデータを「ライブ」で取得する場合）は、MD5ハッシュ値が一致しないことがあります。

3.10.4 ライトブロッカーデジタルフォレンジックでは証拠を保全する際、調査担当者が使用しているOSプラットフォームが、証拠原本となる機器や証拠保全機器内のデータを書き変えることがないように、ライトブロッカーが広く使用されています。あとで証拠を法廷に提出する予定がある場合は、イメージを作成する過程で証拠原本となる機器が変更されないようにすることが重要です。例えばMicrosoft WindowsのようなOSプラットフォームは、Windowsが走っている別のシステムと接続すると、ごみ箱を作成したり、ドライブ上の別のメタデータを変更したりします。ハードウェアベースのライトブロッカーは、調査担当者のOSが証拠原本となる証拠に変更を加えることを防いでくれます。その他のOS（例えば、Helix ™やそれをベースとしたLinuxディストリビューションなど）は、ソース /証拠保全用ドライブに勝手にアクセスして自動的に書き込むことはありません。適切に設定されたHelixインスタンスは、証拠の収集中に証拠となるドライブに変更が加えられるのを防ぐためのソフトウェアベースのライトブロッカーとして使用できます。

インシデント対応の調査段階では、多くの場合、稼働中システムからデータを収集する能力が必要になります（メモリのダンプやディスクイメージの作成を含む）。これらの作業には必ずしもライトブロッカーは必要ありませんが、最終的に法廷証拠として使用されるすべてのデータを変更しないことが文書化、立証されている手法を使うことがとても重要になります。

3.10.5 レコード数の照合収集過程でデータが変更されていないことを確認するもう一つの方法は、証拠の原本と保全用の複製の2つについてレコード数を照合することです。特に非テキストフォーマットからログエントリーのようなレコードを抽出するためにユーティリティを使う場合、この方法は必須です。収集時にレコード数を書きとめ、収集中に発生するズレ（例 : レコード数の減少、記録されたイベントの日時の理由もなくずれている）を照合するは、収集時にデータの完全性が失われたときに、調査担当者が問題に気づくことを助け、完全性の問題を修正することにつながります。Robocopyのようなツールもレコード数を出力するため、調査担当者は送信先でのコピーファイルの数が、パーミッションやコピーエラーなどが原因で、元ファイルのカウント数よりも減っていないかを確認できます。


54

3.10.6 弁護士・依頼者間の秘匿特権または弁護士のワークプロダクトの秘匿特権調査を、弁護士・依頼者間の秘匿特権のもとで、顧問弁護士または契約している法律事務所の弁護士とともに実行するか、あるいは弁護士のワークプロダクトとして保護するかは早めに決定されるべきです。この件については、調査の早い段階で法的助言を求めることが強く推奨されます。

3.10.7 保険金の請求多くの保険会社は、企業向けにハッキングやセキュリティ侵犯によって生じた損害を補償する保険を提供しています。契約内容によって実際の補償額、控除免責額、条件は異なりますが、多くの保険はセキュリティ侵犯によって生じた金銭的損失だけでなく、侵犯を調査し、損害額を明らかにするために外部の調査担当者やセキュリティコンサルタントの支援を受けるためのコストも補償しています。

会社がこうした保険契約を結んでいる場合、調査担当者は以下に留意する必要があります。 • 調査に要した時間とその内容（調査タスクごとの所要時間とタスクの簡単な説明）を詳細に記録します。保険金の請求時は、たいていの保険会社がこうした情報の提供を求めます。

• 企業が被った損害を数値化します。財務やクレジットカード関連の侵犯の場合は、かなり具体的に損害額を計算できるでしょう。損害額にはクレジットカード発行会社から請求される罰金も含めます。知的財産の窃盗を目的とした侵犯の場合は、数カ月、あるいは数年経たなければ問題が明らかにならないことがあるため、損害額の算出は難しくなる傾向があります。

3.11 調査の匿名性攻撃者のC&Cサーバは、対象としている環境を支配するために、アクセス範囲を広げるためのファイルを保持したり、マルウェアへ更新を加えたり、自分たちのマルウェアを強化したりすることがあります。対象とされた会社は、侵害された稼働中システムのライブメモリーから、攻撃者のマルウェアの一部を復旧することはできるかもしれませんが、ファイルをフォレンジック的に繋ぎ合わせて再現することはできないかもしれませんし困難です。C&Cサーバから攻撃ファイルの完全コピーを取り出したい、またはその他の方法で、C&Cサーバの一部を特定したいという誘惑にかられるかもしれませんが、攻撃者のC&Cサーバに直接接触するようなネットワーク活動（例 : マルウェアを制御するためのインターフェースへのアクセス、C&Cサーバ等に対するスキャン、pingによる死活状態の検査、curlを用いたデータ転送、wgetを用いたコンテンツ取得）に従事する場合は必ず、外部のマシン（感染しておらず、標的企業と何の関係もないもの）を使用することが重要です。これを怠れば、攻撃者に、会社がその攻撃者の存在を検知したということを知らせてしまうことに繋がるかもしれません。

第3章　調査

55

3.12 調査活動の保護調査活動そのものも最終的に侵害の一部となったということにならないためにも、講じられるべき必要な予防策が存在します。

3.12.1 データ調査では、通常の業務に使用されているマシンが使われることがよくあります。侵害の深刻度によっては、これは問題を引き起こす可能性があります。例えば調査に使用されているマシンがドメインに参加している場合、攻撃者が環境内のすべての従業員のパスワードハッシュ値を手に入れていれば、そのマシンは攻撃を受ける可能性があります。可能な場合は常に、現在の環境から切り離されたソフトウェアやハードウェアを使うべきです。

3.12.2 移動中のデータ今日の環境下では、ほとんどのEメールは、その認証プロセスをドメイン参加型アーキテクチャに依存しています。よって、ドメインを侵害した攻撃者は、企業全体のパスワードハッシュ値はもちろん、最終的には全員のEメールにアクセスできるようになります。この場合はEメール以外の方法でコミュニケーションをとらなければなりません。調査チームは、調査のためにコンテンツ管理システムを利用できます。どうしてもEメールを使う必要がある場合は、少なくとも256ビットのAES暗号を使って、すべての通信を暗号化すべきです。

暗号化について、端的に表現すると、パスワード保護スキームはどれも同じではないということです。例えばMicrosoft Office®のパスワード保護機能は、一見すると安全であるように見えますが、実際はクラッキングの試みや認証回避メカニズムに脆弱です。重要な調査データは、PGP、TrueCrypt®などの暗号化技術を使っての保護が推奨されます。

3.13 調査活動の保護サイバー攻撃が起き、ネットワークが侵害されたことが明らかになったら、すぐに調査を始めなければと気が急くのも無理はないでしょう。しかし全社規模の調査は困難を伴う作業であり、さまざまな地域や事業部門のチームに情報を提供してもらわなければなりません。攻撃者に活動を悟られないように、もっと言えば、調査そのものが攻撃対象となることがないように、コミュニケーション、データの収集、調査といった作業はひそかに進める必要があります。駆除の準備が整う前に、攻撃者が検知されたことに気づけば、彼らは企業に損害を与えるような行動に打って出るかもしれません。例えば攻撃者は、C&Cシステムが検知され、ブロックされてもシステムへのアクセスを維持できるように、企業がまだ検知していないC&C技術を新たにインストールする可能性があります。攻撃者がバックアップのC&C機能をインストールし、検知されないように一定期間、これらの機能を「スリープ」状態に置くことは珍しくありません。攻撃者は賢く、創造性に富んでいます。甘く見るべきではありません。


56

3.13.1 認証情報の保護調査チームは調査の過程で、社内のさまざまなマシンにログオンします。イメージを収集するときも、ログファイルを取得するときも、エージェントを配備するときも、認証情報は慎重に扱うようにしなければなりません。

調査環境で使用・作成する認証情報は必ず、通常業務に使用されている認証情報とは別のものにします。侵害されていないと100％断言できないかぎり、既存のアーキテクチャはなるべく信頼しないようにします。侵害されたシステムを分離しておくことが、安全対策上は決定的に重要です。

徹底的な監視と調査なしに、攻撃者がネットワーク内を移動する速度を見極めることは困難です。企業は情報収集やインシデント対応を急ぐあまり、ドメインアカウントの認証情報を保護することを忘れがちです。これらのアカウントがあれば、環境内を自由に動きまわり、さまざまなホストに管理者としてアクセスできます。インシデント対応チームの経験の浅いメンバーや不注意なメンバーが、このような強力なアカウントを手にすれば、認証情報を攻撃者に奪われることになりかねません。管理者アカウントさえあれば、攻撃者は、ハッシュ値はおろか、最終的には調査担当者のキャッシュされた認証情報にもアクセスできるようになります。多くの企業が、製品に初期設定されている管理者アカウントに同じパスワードを設定しています。このような単純な問題が、インシデント対応の調査全体を台無しにする可能性があるのです。

調査の全期間を通じて、こうした重要な質問への回答はこまめに経営陣に伝える必要があります。そしてさらに重要なことは、それら調査によって得られた洞察や情報を、環境から攻撃者を排除するために設計された駆除計画へときちんと組み込むことです。

第4章　駆除

57

第4章　駆除高度なサイバーセキュリティ侵犯の調査がマラソンだとすれば、侵犯の駆除は短距離走です。つまり駆除活動においては、効率的なアプローチが成否を分けます。攻撃の全体像を把握し、攻撃者がアクセス・侵害したシステムを漏れなく特定し、盗み出された認証情報をリスト化し、社内ネットワークに埋め込まれた悪意あるソフトウェアを見つけ、奪われたすべての重要情報を分類し、駆除活動を効果的に実行する準備を整える―こうした調査活動に何カ月もかかることは珍しくありません。しかし一度調査が終われば、駆除活動は完璧かつ迅速に実行する必要があります。

効果的な駆除計画にはスピードと正確さが求められます。たいていの攻撃者は、自分の存在が発見され、駆除の準備が進んでいることに気づいたとたん、体勢を立て直し、ネットワークへの再侵入を試みます。例えば、ある攻撃者は駆除活動の実行中に特権アカウントにアクセスできなくなったことに気づきました。この攻撃者は、一年近く前にDMZ（Demilitarized Zone: 非武装地帯）サーバにインストールし、調査チームに発見されないままになっていたweb shellにアクセスし、それを使って再侵入を果たしました。IPアドレスが駆除チームによってブロックされたことに気づくと、ドメイン名の IPアドレスを変更する攻撃者もたくさんいます。

侵害を検知した企業は、問題の全貌を捉える前に、感染経路や潜伏ポイントをブロックし、早急に駆除活動に取り掛かろうとするものです。しかし、十分な対応計画を練らないまま対応すると、攻撃者はそのたびに戦術を変えるため、絶えず敵を追い回している状態に陥りかねません。

これはコストの面でも労力の面でも、企業に大きな負担をかけることになります。駆除は関係者が連携して、自社の環境から侵入者を計画的に排除するものでなければなりません。サイバーセキュリティ侵犯を完全に回避することはできないとすれば、時間と労力を費やして慎重に準備を整えることは、大きな投資効果を得るためのデューデリジェンス―すなわち当然払うべき注意なのです。

4.1 駆除計画の立案駆除活動を組織的かつ計画的に実行するためには、あらかじめ作業のスケジュールやタイミング等の詳細を十分に検討しておく必要があります。

4.1.1 駆除活動チームの設立駆除活動の準備は、さまざまな作業の担当チームを決めるところから始まります。こうした準備は調査段階から始まるため、駆除活動は調査の完了後すぐに始めることができます。熱心なチームリーダーが駆除計画の調整役となり、駆除活動の実行状況を確認します。チームのメンバーは社内のさまざまなグループから任命すべきです。すべてのメンバーが駆除計画の一つまたは二つの部分で重要な役割を果たし、場合によっては計画実行における特定分野の責任者となります。


58

駆除日までの期間は、全員が専任でイベントの準備に取り組むことになります。駆除日には、チームのメンバーは駆除活動の効果の測定に集中し、駆除活動によって引き起こされた活動に対応します。緊急事態に対処するための計画を練り、攻撃者の反応に備えることも重要です。チームと主要な利害関係者には、この時点で包括的で入念に組み立てられたエンゲージメント計画を配布すべきです。計画の最初のステップから最後の教訓学習セッションまで、すべての段階を机上シミュレーションで実施するのもよいアイディアです。これは重要な質問に回答し、計画のあいまいな部分を明確にする助けになります。

駆除活動では、攻撃者のアクセスの切断から始まり、駆除計画を迅速に実行するため、チームメンバーの業務スケジュールを調整し、24時間のサポート体制を築くことが必要になる場合が多々あります。そのためにどんな方法をとるかは、駆除活動の範囲やチームの規模・スキルセットに大きく左右されます。

4.1.2 駆除活動計画の立案駆除活動計画の立案にあたっては以下の点に留意します。

• 調査計画と同期のとれた包括的な駆除計画を立案する　調査・駆除チームを収集したら、役割と責任、および駆除を成功させるために達成すべき目的とタスクをチーム内で共有します。リーダーは調査・駆除計画を作成し、関係者の賛同を得て、計画を他の主要な利害関係者に周知します。計画には必ず、調査チームと駆除チーム（およびその他の事業部）との関係を明記します。計画を成功させるためには、調査チームと駆除チームが各段階で協力しながら、効果的、効率的、かつ包括的に調査・駆除活動を実行できるようにする必要があります。

• 駆除活動の前後で完了しておくべきタスクを明確にする　計画には、調査が必要なさまざまなこと、実行すべきプロセス、必要な技術的修正、最適化、開発、ないし購入する必要のある機能をすべて盛り込みます。侵害の性質に合わせて、計画のさまざまな側面に優先順位を付けましょう。例えば、ある企業は駆除前にドメインコントローラにアプリケーションのホワイトリストを実装することを優先するかもしれません。別の企業は、暗号化メカニズムが既に攻撃者に悪用されていることを踏まえ、駆除の前に環境からLANマネージャのパスワードハッシュを削除したいと考えるかもしれません。いずれにしても、企業は駆除活動の前に完了すべきことと、駆除活動が終わるまで待てることを見極める必要があります。対応する脅威に合わせてリスクを分析し、悪用の可能性や自社のセキュリティ体制を検討します。

• 駆除活動を維持・拡大する　計画は駆除で終わるわけではありません。攻撃者は駆除活動が進行していることを察知すると、ただちにアクセス権を取り戻そうとします。駆除後数週間は警戒を解かずに、駆除活動後、少なくとも一週間は厳戒態勢を維持すべきです。その後でメンバーの任務を解除することを検討します。

第4章　駆除

59

4.1.3 駆除日の決定駆除活動を実施する日時は重要です。日時を選ぶときは、メンバーのスケジュールやネットワークの休止時間を優先したくなるかもしれません。これらも重要な要素ではありますが、攻撃者の行動パターンを検討することも重要です。例えば攻撃者の行動を分析した結果、特定のスケジュールで活動していることが明らかになるかもしれません。週末は活動せず、通常の業務時間の間しか活動しない攻撃者もいれば、週末に活発に行動する攻撃者もいます。後者の場合は、月曜の朝に駆除活動を始めると、攻撃者がアクセスを失ったことに気づく前に、計画を完了できる確率を最大化できます。しかし攻撃者が活動しているとわかっている時間帯に駆除活動を実行すれば、攻撃者はアクセス権を取り戻すため活発に活動するかもしれません。

新米の攻撃者は、存在を検知され、厳しい警告を受けたら、それだけで攻撃をあきらめてしまうかもしれませんが、高い技術と根気を備えたベテランの攻撃者は、ネットワークでのアクセスを維持するために積極的に戦うことが少なくありません。検知され、ブロックされた場合、高度な攻撃者は何カ月、あるいは何年もかけて侵入し、潜伏してきたネットワークへのアクセスを取り戻すために、ただちに積極的な行動を起こす可能性があります。もし攻撃者がネットワークにアクセスする日時が予測できるなら、この情報を駆除チームの有利になるように活用します。攻撃者についての知識は、駆除日を決める際にも重要な役割を果たします。

4.1.4 攻撃者の戦術、方法、手順の理解攻撃者を理解することは、防御体制を強化するためだけでなく、調査・駆除を効率的かつ包括的に進める上でも重要です。標的型脅威では、社内ネットワーク上に多くのアクセスポイントや侵入経路が作成・維持されていることが珍しくありません。攻撃者はアクセスを維持するために、さまざまな手段を講じます（ユーザや特権アカウントを悪用する、ホストに侵入してバックドアをしかける、Web Shellを活用するなど）。こうしたアクセス経路は何カ月、時には何年もかけて育まれたものですが、攻撃者の主要なアクセス手段が切断されるまでは利用されることはないかもしれません。協調的で包括的な調査・駆除計画を立てる必要があるのはそのためです。このような計画がなければ、攻撃者がこれらの代替的なアクセス手段を使って、ネットワークへのアクセスを再び確立するリスクは大幅に上昇するでしょう。


60

4.1.5 コミュニケーションプロトコルの確立駆除活動の最中は、チーム内のコミュニケーションを明確化し、進捗状況や未解決の問題にタイムリーに注意を払うことが重要です。24時間体制でシフトを組んでいる場合は、チームとすべての利害関係者にスケジュールや連絡先情報を提供します。上層部に進捗を定期的に報告すれば、情報提供を求められる頻度を減らすことができます。こうした定期報告を円滑に行うためには、チームの活動を漏れなく記録し、すべてのシフトのメンバーがそれまでの活動を理解できるようにする必要があります。教訓や駆除活動全般に関する報告書の作成プロセスも簡略化すべきです。

調査・駆除活動を成功させるためには、トップダウンとボトムアップの両方のコミュニケーションが必要です。駆除日までに必要な許可・承認を確実に得られるように、重要な利害関係者と経営層にはかなりの時間に余裕を持って、計画に関する情報を提供します。同様に、利害関係者と経営層は計画の詳細を理解し、必要な変化が組織全体に与える影響を把握しておかなければなりません。これらの変化の中には、組織の重要なプロセスや技術に関わるものもあるかもしれません。あらゆるレベルの人々を巻き込むことで、調査・駆除の過程で組織の目的や業務に影響を及ぼす可能性のある重要なプロセスや技術を発見できます。

調査・駆除チームが単独で行動している場合、調査・駆除段階で起こりうる問題に備えることは極めて難しくなります。一方、調査・駆除チームが IT部門の関係者と連携すれば、調査・駆除活動の効果と効率を高めることができます。迅速な判断や行動が求められる調査の場合はなおさらです。計画には、ヘルプデスク、ワークステーション、ネットワーク、セキュリティチームの交流を促すような仕組みを盛り込みます。マルウェアを削除するために、感染したシステムをワークステーションチームに渡す時期と手順も事前に定義しておきます。調査の実行中は、ワークステーションチームに逐次状況を報告し、作業が必要になる時期を予想できるようにします。

大規模な調査・駆除活動を計画する際は、セキュリティチームが ITチームと日常的にどう連携するかを定義しておく必要があります。セキュリティチームが ITチームとリーダーに状況を説明する進捗会議を毎日開くと、調査を速やかに完了し、システムを正常化する助けになります。計画の中で明らかにすべき問題には次のようなものがあります。 • IT関連の問い合わせはすべてヘルプデスクが受けるのか、それともSOC（Security

Operation Center）が直接ユーザに対応するのか? • セキュリティチームとネットワークチームで行動方針に差がある場合、次の行動を決める権限を持っているのは誰か?

第4章　駆除

61

これらは事前に考えておくべき重要な質問です。企業の中には調査を応援するために、ヘルプデスク、ワークステーションチーム、またはネットワークチームのメンバーを（兼任で）セキュリティチームに派遣しようと考えることもあるかもしれません。しかし、その場限りのチームではスピードが重視されるセキュリティ調査には対応できず、むしろスピードダウンを招く可能性があります。可能な場合は常に、明確な役割とプロセスを持ったチームを作りましょう。

コミュニケーション計画を立てる際は、調査に関する情報を誰に伝えるかを考えます―これは真剣に検討すべき問題です。調査がある程度進んだら、社内の一部のメンバーには何が起きているのかを伝える必要が出てくるかもしれません。しかし、たいていの企業は、選定したグループだけに重要情報を限定したいと考えるものです。計画には、情報を知る権利を持つ人と持たない人を明確に定めましょう。

社外とのコミュニケーションは、より繊細な問題を含んでいます。もし攻撃の事実が外部に漏れたら、マスコミに直接対応することは不可避であり、必須でもあるため、事前に計画を立てておく必要があります。マスコミへの情報提供は、積極的にというより、受動的に行われるのが普通ですが、マスコミが状況を知った場合にどう対応するかを検討し、必要な計画を立てておくことは不可欠です。まずは社内の担当者にマスコミに話すべきポイントを事前に伝えておきましょう。

主要なビジネスパートナーに接触することが有益、あるいは必須である場合もあります。ネットワークを常時接続している企業間では、ネットワークの状況を率直かつ正直に話し合うことが事前に合意されている必要があります。これは一般的ではありませんが、そうあるべきです。このようなつながりがある場合、二つのネットワークは実質的には一つのものであり、ネットワークを健全な状態に保つため相互に依存することになります。もし一方の企業のネットワークが業務契約やサプライチェーン契約に影響が出るような形で侵害されたときは、できるだけ早くビジネスパートナーにアラートを発信します。これは将来の混乱を避ける助けになります。また、ビジネスパートナーの中には、もし自社のネットワーク上にあれば、脅威についてさらに多くの情報を集められるような検知機能を持つところもあるかもしれません。しかし、もし企業間のコミュニケーションを可能にするプロセスがなければ、こうした情報を共有することはできません。

他に連絡が必要になる可能性のあるサードパーティには、政府と捜査当局があります（先に先方から問い合わせがくる可能性もあります）。継続中の侵害の種類に応じて、どのような報告が義務付けられているかを十分に理解する必要があります。


62

4.1.6 「対策本部（War Room）」の設置高度なインシデントに対応する場合は、「対策本部」を設置するのも良策です。通常、個々のインシデント対応計画は短期間しか継続しないため、対策本部も常設のものではなく、一週間程度しか使用されることはありません。対策本部は、チームの会議や連携の拠点であり、すべての関係者（インシデント対応の担当者、IT部門の担当者、利害関係者、その他のリーダー）が集う場所となります。

チームリーダーが対策本部の司令官となり、駆除計画に沿ってメンバーに指示を出します。リーダーはインシデント対応に関する議論、調整、行動を促進し、メンバーの行動のタイミングを調整し、すべての活動が調和のとれたものとなるように尽力します。

チームの規模やプロジェクトの範囲によっては、複数の対策本部が必要になる場合もあります。例えば全体の活動の調整はリーダーシップ本部が担当し、具体的な活動は小規模なセキュリティ監視、ネットワーク、ワークステーションチームが別の対策本部で実行するといった具合です。各シフトの担当者が、それまでに行われた活動の内容を理解できるように、またプロジェクトの完了後に教訓を導きだせるように、各チームの活動は漏れなく記録します。

対策本部の解散後にフォロー活動が必要になった場合は、セキュリティチームのリーダーの判断で、必要に応じて再招集をかけることができます。

4.1.7 安全なコミュニケーションと情報共有のメカニズムの確立駆除チームの構成や駆除活動の性質を考えると、安全なコミュニケーションを確立することは極めて重要です。駆除チームのメンバーには、駆除活動の前後にも最中にも、必要な情報を提供しなければなりません。今日では社内コミュニケーションの多くがデジタルネットワーク上で行われていますが、これはコミュニケーションの内容が攻撃者に監視される可能性があることを意味します。このため、セキュリティ運用ガイドラインを策定し、厳守することが重要です。

セキュリティ運用ガイドラインには、インシデント関連の情報はその情報を知るべき人だけに開示することを明記します。企業にもよりますが、このグループには通常、駆除チーム、調査チーム、IT部門の一部、経営陣の一部が含まれます。これらの情報は、侵犯に関する情報が攻撃者の手に渡ったり、誤って公開されたりすることがないように、極秘に扱う必要があります。開示することが法で定められている侵犯もありますが、開示の判断は必ず経営幹部や法律顧問、およびその他のしかるべき関係者に相談した上で下します。

チームは、攻撃者がネットワークを監視できるという仮定に基づいて、業務を遂行しなければなりません。標的型攻撃の実行者は、この能力を使って自分たちの存在が発見されているかを探ることがあります。調査の手が及んでいることに気づいた攻撃者は、戦術を変えるか、長期にわたってネットワークに接続しない可能性があります。数週間、あるいは数カ月後に、既に埋め込んである多くのアクセス経路のいずれか使って、標的に再侵入すればいいと考えています。攻撃者に発見されないように、調査・駆除プロジェクトにはコードネームを付けます。また、インバウンド通信（例 : Eメール、ファイル共有）には強力な暗号化技術を使います。チームの連絡には

第4章　駆除

63

別の暗号・パスワードを使用し、メンバーには繰り返し、プロジェクトの機密性と、コミュニケーションには慎重に取り組む必要があることを伝えます。セキュリティ運用ガイドラインには、アウトバンド通信（例 : 対面の会議、電話、ショート・メッセージ・サービス［SMS］）を優先すべき旨を随所で明記します。

駆除を迅速かつ完璧に実行するためには、駆除前に必要な許可・承認が得られるように、十分な時間的余裕を持って、主要な利害関係者と意思決定者に計画に関する情報を伝えなければなりません。経営陣は計画の詳細に関わり、必要な変化の影響を理解しておく必要があります。これらの変化の中には、組織の重要なプロセスや技術に影響を及ぼすものもあるかもしれません。経営陣の関与は、組織の目的や業務に影響を及ぼす可能性のある重要なプロセスや技術を特定する助けになります。こうした会話や意思決定は簡単ではないかもしれませんが、計画への合意は駆除の前に形成しておく必要があります。

高度な調査・駆除を実行するためには、よく練られたコミュニケーション計画が不可欠です。いつ、誰と、どのような方法で安全なコミュニケーションをとるかを定めておきます。侵入の第一報は電話で来るのが一般的です。最初のステップは、社内の連絡先を見つけることです。通知者は情報を直接提供するのではなく、対面の会議を設定します。侵入に関するデータそのものは、通知の段階ではかなり古くなっているものですが、影響を受けた組織を特定し、最初の連絡をとるために時間がかかることもあります。

4.2 計画の実行計画の実行中は以下の点に留意します。

• チームメンバーが作業に集中できるようにする　駆除中は、メンバーが作業に集中できるように独立した環境を与えます。チームに「助っ人」として参加したがる人もいるかもしれませんが、準備に参加していなかった人が途中から参加しても、ミスをして作戦を狂わせるだけです。こうした人々には、駆除チームを見守っていてほしいと丁寧に頼みます。

• 情報に適切なラベルを付ける　懸念が生じたときは、ただちに検討できるようにします。伝えられた情報には必ずラベルを付けましょう。明確で適切な情報ラベルは、意思決定者が正しい決断を下す助けになります。誰かの勘が事実として伝えられ、後になって事実でないとわかった場合、その人と駆除活動にマイナスの結果が生じる可能性があります。

• 駆除計画を忠実に実行する　駆除活動の間、チームメンバーは解決を焦るあまり、あらゆることを一度にやろうとするかもしれません。このような衝動には抵抗しなければなりません。計画を信頼します。もし準備・調査にしかるべき時間とエネルギーを投じたなら、駆除は関係者との協同プロジェクトになっているはずです。計画の変更を完全に避けることはできませんが、それを最小限にするために全力を尽くします。大幅な逸脱が予測される場合は、あらかじめ駆除チームのリードで調整し、チーム内でコミュニケーションをとりながら実行します。


64

• 緊密な調整を行う　調整は必須です。例えば攻撃者がアクティブ・ディレクトリ・サーバに侵入し、複数のドメイン管理者アカウントの認証情報を手に入れた場合、関係者は連携して侵害されたパスワードを変更しなければなりません。一部のパスワードしか変更しなければ、攻撃者は別のアカウントを使って攻撃を続ける可能性があります。アクセスさえ維持されていれば、攻撃者は新しいパスワードのハッシュをキャプチャするか、必要な特権を持つ別のアカウントを作成できる可能性があります。

もし可能なら、駆除の実行中は他のネットワークから隔離します。しかし通常（特に攻撃者が既にネットワークに深く侵入し、大きな足跡を残している場合は）これは不可能です。もし駆除中にネットワークを切断できれば、駆除の成功率は高まります。

4.2.1 パスワード変更高度な侵犯に対応する場合は、全社規模でパスワードを変更するのが一般的です。たいていの攻撃者は通常のネットワークトラフィックに紛れながら、盗んだパスワードを使って企業の資産にアクセスします。他のツールやマルウェアが検知され、削除されたとしても、パスワードがあれば管理者レベルのアクセスを取り戻すことができます。このため、パスワード管理と全社規模のリセットは、検知された攻撃者をネットワークから駆逐するための重要なステップとなります。

しかし、全社規模のパスワード変更は事業上の理由から、実行できない場合があります。その場合も、調査チームが侵害された（あるいはその疑いがある）と特定したアカウントについては、駆除活動の開始に合わせて無効にするか、パスワードを変更します。SIEM（Security Information and Event management: セキュリティ情報イベント管理）やその他の監視・検索ツールにルールを適用し、これらのアカウントからのログオンが失敗したケースを見つけます。このルールは駆除後にネットワークに再侵入する試みを特定できる可能性があるため、優先度の高いアラートとして扱います。

ネットワークへの再侵入を防ぐには、駆除日の前に侵害されたドメインのセキュリティの基準レベルを定め、順守することが重要です。セキュリティの基準レベルを満たしている活動には、次のようなものがあります。

• 完全なアカウントリストの作成　ドメインで利用されているアカウントの一覧を作成します。すべてのアカウントを、現在アクセスを必要としている個人と結びつけます。このリストには、パスワードの最終変更日とパスワードの保存に使われているアルゴリズムも記載します。アカウントリストができたら、削除する必要のあるアカウントと、パスワード変更が必要なアカウントを駆除計画に組み込みます。これは、駆除計画と同時に実行すべき作業の一つです。駆除日の前に突然パスワードを変更すると、攻撃者は検知されたことに気づき、調査が困難になる可能性があります。ネットワークの点検と修正は、徐々にではなくできるかぎり一気に行いましょう。

第4章　駆除

65

• ドメイン管理者アカウントの見直しと合理化、および（可能な場合は）削減　ドメイン管理者アカウントは“城門を開く鍵”であり、それに見合った保護が必要です。この権限を持つユーザの数は厳しく制限し、ユーザの活動はできるかぎり詳細に記録します。

• パスワードポリシーの改訂　必要に応じて、パスワードポリシーを見直し、改訂します。LANマネージャのハッシュの悪用を防ぐために、ウィンドウズのパスワードは15文字以上とします。パスワード・ハッシュ・データベースを評価し、推測しやすいパスワードや短すぎるパスワードを見つけるツールはたくさんあります。

• パスワードの強化　適当なパスワード強度を持つパスワードを再設定したら（図14）、それらのパスワードを適切に管理するためのプロセスを導入します。標準ユーザのパスワードは四半期ごとに、管理者のパスワードはもっと頻繁にリセットします。アカウントのロックアウトを実行するのもよいアイディアです。例えばユーザがパスワード入力に最大5回失敗したときは、ヘルプデスクがパスワードをリセットするまでアカウントをロックします。これはパスワードを見つけるための総当たり攻撃を防ぐ効果があります。

予算に余裕があるときは、2要素以上の認証を導入する企業が増えています。2要素認証とは、ユーザが知っていること（例 : パスワードや個人識別番号［PIN］）、ユーザが持っているもの（例 : 何らかのトークン、スマートカード）、あるいはユーザ自身のもの（例 : 指紋、網膜スキャン）のうちの2つを使用したパスワード認証です。多要素認証はパスワードの弱点の多くを解決してくれますが、導入・維持コストが高くなる傾向があります。


66

図14『xkcd』コミック: 「パスワード強度」

出典 : xkcd: A Webcomic of Romance, Sarcasm, Math, and Language, http://xkcd.com/936/. 許可を得て掲載（http://xkcd.com/license.html）

4.2.2 攻撃者による指令・制御のブロック調査報告書のフォレンジック・キー・セクションには、攻撃者が使用しているすべてのコミュニケーションパスの詳細を記載します。指令・制御メッセージの送受信に使われているIPアドレスをまとめ、これらの IPアドレスを解決するために使われているドメイン名とURLの一覧を作成します。通信の方向づけに使われている情報（例 : インターネットの匿名プロキシーソース、URLの難読化・短縮サービス）も詳しく記載します。駆除日には、これらのURL、ネットワーク、IPアドレスのすべてをegressポイントでブロックします。ファイアウォールは IPアドレスをブロックするために使いますが、もし攻撃者が自身の IPアドレス空間内の名前解決サーバを使っている場合は、それらのURLやドメイン名用の「ブラックホール」を作成します。それらは社内DNSリゾルバに置き、以下のいずれかを指すようにします。 • ループバックアドレスまたは0.0.0.0 • すべての画像リクエストに対して1ピクセルの画像ファイルを、すべてのテキストページのリクエストに対して警告メッセージページを「応答する」ように設定されたローカルの社内ウェブサーバ

• パーソナルファイアウォールを使用しているマシン

第4章　駆除

67

IPアドレスはブロックされていても、マルウェアはまだ完全修飾ドメイン名（FQDN: fully qualified domain name）と通信するように設定されている場合、攻撃者は IPアドレスを変更して、別の IPアドレスを指すようにネームサーバを更新することで、マルウェアを更新せずにブロックを回避できます。

上記の3つの設定のうち、最後の2つ―「応答する」ように設定されているローカルの社内ウェブサーバまたはパーソナルファイアウォールを使用しているマシン―には、調査用のログファイルを生成する、あるいはトラフィックを監視するためにSnort®やその他の IDSシステムを利用できるという利点もあります。DNSブラックホールを効果的に活用するためには、DNSリゾルバによってルートされていないトラフィックはブロックする必要があります。もしDNSが会社の所有・管理するネームサーバを経由していない場合は、マルウェアは外部のパブリックDNSリゾルバを使ってデータを誘導したり、持ち出したりするようにプログラムできます。

ホワイトリストに入っているネットワーク以外の外部ネットワークと通信することで社内にサービスを提供しているサーバをブロックするのはよいアイディアです。例えば、パッチやセキュリティ定義を手に入れるために特定のソフトウェアベンダーと通信する必要がある場合、そのベンダーをホワイトリストに加え、通信を許可します。

4.2.3 侵害されたシステムの再構築ついに脅威の駆除に取り組むときがやってきました。脅威情報の収集は侵犯のソースを特定する助けになります。こうした情報は駆除のタイミングを決める上でも有効です。例えば、もし脅威の出元が中国なら、旧正月の期間は活動量が減る可能性があるため、この時期は駆除を実行し、予防措置を導入する最高のタイミングと言えるかもしれません。逆に、もし攻撃者が活動しているとわかっているときに駆除を実行すれば、攻撃者はアクセスを取り戻すために積極的な行動に出るかもしれません。攻撃者に全力で戦う機会を与える理由はありませんから、攻撃者が警戒をゆるめたときに行動を起こすのは理にかなっています。

もし可能なら、侵害されたホストはすべてドメインから切り離し、再構築します。侵害の証拠は深刻に受け止めるべきです。高度な攻撃者はアンチウイルスやシステムスキャニングでは検知できないルートキットをシステムにインストールしている可能性があります。もし可能なら、これらのシステムは再イメージングし、攻撃者がシステム内にもはや足場を持っていないことを確認します。リソースに余裕があるなら、駆除活動の前に侵害されたホストを再構築し、駆除日にはそのホストが「完全に交換（swapped out）」されるようにするべきです。そうすれば、駆除活動をより迅速に、かつ組織的に行うことができます。


68

侵害されたシステムのユーザにその事実を伝えるかは、慎重に検討する必要があります。クリーニングのために侵害されたシステムを移送するときは、ユーザやシステム・クリーニング・プロセスの関係者が駆除活動に干渉するリスクを減らす方法を考えましょう。

4.2.4 アンチウイルスベンダーへのマルウェアの提供調査チームは、攻撃に使用されたツールや、ネットワーク上に展開・保存されているマルウェアを見つけ、アーカイブする必要があります。次は、少なくとも動的に、これらのマルウェアのアーティファクト（artifacts: マルウェアを始めとするサイバー攻撃で使われるツールや技術による痕跡）を分析し、攻撃者の意図を明らかにします。駆除チームは、アンチウイルスベンダーやホストベースの侵入検知ベンダーと連携して、このコードのシグネチャを作成します。駆除日には定義ファイルを全社に配布し、このコードのコピーや変種がネットワーク上に残っていないかを確認し、検知された場合は隔離します。

4.3 再侵入活動の監視ネットワークを厳重に監視する準備を整えます。駆除日が近づいたら、一歩離れて状況を眺め、どんな緊急事態が起こりうるかを予測します。計画された活動が期待したほどの効果を上げなかったり、マイナスの二次効果を生んだりする可能性は十分にあります。駆除チームは以下の点を考えておかなければなりません。

• 駆除活動の二次効果と将来の予防活動にはどのようなものがあるか?　一つの方法は、こうした隠れた因果関係を意識しながら計画を立てることです。もう一つの方法は、チームに新しいメンバーを入れ、新しい視点から駆除計画を見直すことです。

• 計画に含まれている仮定のうち、間違っている可能性があるのはどれか?　その仮定が間違っていた場合、どんな結果が引き起こされるか?　計画の全体像を眺めるようにすると、これらの仮定の多くを解決できます。残りの仮定については、不測の事態が起きた場合の対応計画を準備しておき、駆除計画を円滑に進めましょう。敵は新しい戦術を用意しているかもしれません。脅威情報の収集は、こうした戦術を特定し、予測する助けになります。

• 調査チームは、攻撃者の活動の全貌をつかむだけのIOC（Indicator OF Compromise: 脅威が存在することを示す痕跡）を見つけたか?　攻撃者が別のアクセス方法を使って社内に侵入するのを防ぐために、迅速に組織的な努力がなされたか?　脅威を駆除する上で最も困難なタスクは、駆除活動の成否を判断することです。ネットワークは安全であると明言できない可能性は人々を不安にさせるかもしれません。

監視チームが「すべての IOCとアーティファクトは駆除された」と十分に納得できる段階まで来たら、SOCは経営幹部に駆除活動が成功裏に完了したことを報告し、もしあれば例外や評価活動によって判明したことを伝えます。

第4章　駆除

69

高度な脅威を検知したときは、攻撃者の行動を監視・観察して相手の戦術を理解し、潜伏の仕組みを明らかにする必要があります。あらゆる方法を使って、感染経路、アクセスポイント、潜伏の仕組み、悪用された脆弱性、ネットワークに再侵入するための方法を見つけましょう。一つの間違いや見落としのために、攻撃者はいつのまにかネットワークに再侵入するかもしれません。このような悲劇的なミスを回避するためには、企業は以下に焦点を合わせる必要があります。 • 駆除活動を支える、質の高い調査報告書を作成する。 • 調査・駆除を完璧に実行するための計画を立てる。• プロセスの全段階を通じて、健全なプロジェクト管理原則に従う。

駆除計画は、調査報告書に記載された問題のすべてに対処するようになっていなければなりません。また、計画には活動の開始日と目標期日を具体的に記載します。

駆除計画に着手する前に、駆除チームは調査報告書に記載されている活動をすべて監視できるかを確認する必要があります。攻撃者が再侵入を試みる場合に備えて、駆除日の後も数週間は監視を続けましょう。具体的なユースケースを書き、テストし、微調整を加え、駆除チームの指定されたメンバーにアラートを発信するSIEMソリューションに統合すれば、駆除の効果を記録、追跡、監視できます。


70

白紙ページ

第5章　駆除後の対応

71

第5章　駆除後の対応駆除のプロセスは時間との競争であり、大変な労力を要するものとなりがちです。事業に与える影響を最小限に抑えるために、作業は通常業務の終了後か、週末の保守時間内で行わなければならないことも少なくありません。SOC（Security Operation Center）のメンバーは、IT部門のさまざまな専門家と協力しながら、一刻を争う状況で困難なタスクを遂行します。駆除のための作業が一通り終わった後も、SOCは引き続き細心の注意を払いながら仕事を続けます。次の攻撃は、駆除後の数週間以内に起きる可能性が極めて高いからです。攻撃者は体勢を立て直して攻撃を再開するでしょう。初期戦術が阻止された場合は、迅速に戦略を変えてきます。それは攻撃が成功するか、再侵入に要する労力が、盗み出す情報の価値や侵入に要する時間の価値を上回ると攻撃者が判断するまで続きます。初期感染の規模や狙われている情報の重要性によっては、このような攻撃パターンは動揺を引き起こします。SOCの分析担当者は、駆除段階で導入されたコントロールの有効性を確認すると同時に、再攻撃の兆候を監視し、迅速に対応する必要があります。

5.1 駆除活動の検証 5.1.1 警戒態勢の維持適切に計画したならば、駆除活動は短時間で終わるはずですが、攻撃者が攻撃を進化させていく場合に備えて、企業は監視体制を整え、数週間から数カ月間はネットワークの監視を続ける必要があります。この段階で最も重要になるのは、ネットワークの状況を把握することです。NetFlowデータを生成し、動向に変化がないか、基準から外れた活動がないかなどを分析します。攻撃者の戦術、方法、手順のユースケースはSIEM（Security Information and Event Management: セキュリティ情報イベント管理）に集約し、駆除の完了後もしばらくは慎重に監視を続けます。特に注意する必要があるのは、前回の攻撃と類似した行動に対するアラートです。

前述したように、攻撃者は利用できるあらゆる手段を使ってネットワークへの再侵入を試みます。しかも、自分たちは捜索されており、これまでの戦術、方法、手順は既に暴かれていることを知っています。このような攻撃者は、もはや検知されることを恐れず、これまでよりも積極的に攻撃をしかけてくる可能性があります。過去数カ月間は検知されないように息をひそめて活動していたが、その必要はもうなくなった、というわけです。この場合、攻撃者はネットワークから永久追放される前にできるかぎりの情報を盗み出そうと、必死の行動に打って出るかもしれません。例えばパスワードを盗み出すために総当たり攻撃をしかけてきたり、ネットワークをスキャンしたり―こうした方法は多くの痕跡を残すため、SIEMの初期設定のルールでも容易に攻撃と認識されます。このような攻撃が検知された場合、最も重要なのは迅速に対応することです。


72

経営陣はアクティブ監視（active monitoring）の期間を決定しなければなりません。いつまで監視を続けるかは、駆除後に攻撃者がどれくらい積極的に再攻撃をしかけてくるかで決まります。アクティブ監視の終了後も、SIEMに設定したルールは削除しないようにします。攻撃者の関心は、時間をかけて戦略的にネットワークにアクセスすることだからです。彼らはネットワークから締め出された後、再び侵入を成功させるための最も効果的な戦略は、数週間から数カ月の間、接続をしないことだと知っているのです。

駆除後の環境でSOCがなすべき重要な仕事の一つは、調査で発見された IOC（Indicator Of Compromise: 脅威が存在することを示す痕跡）のすべてについて、あらためて環境スキャンを実行することです。SOCチームは、これらの IOCアーティファクト（artifacts: マルウェアを始めとするサイバー攻撃で使われるツールや技術による痕跡）を熟知していなければなりません。ホストベースの検出機能を使って感染マシンをすべてチェックし、ディスクにもメモリにもマルウェア（悪意あるソフトウェア）がないことを確認します。さらにネットワークベースの機能を使って、今回のインシデントで悪用された IPアドレスへのトラフィック、あるいはこれらの IPアドレスからのトラフィックを見つけます。ネットワーク内から使用されたFQDN（Fully Qualified Domain Name: 完全修飾ドメイン名）についても、漏れなく再解決を試し、それらが本来の場所を指定しているかを確認します。さらにネットワーク外のFQDNもこまめに解決して、IPアドレスが更新されていないかを確認します。攻撃者がマルウェアのソースコードにIPアドレスを直接書き込むことはほとんどありません。通常はURLを使い、IPアドレスがブロックされたときはDNSエントリーを更新して、ブロックを迂回します。ネットワークの外側から定期的にFQDNの解決を試み、DNSレコードが更新されていることに気づいたら、新しい IPアドレスを脅威情報データベースに加え、ブロックします。

この時点では、SOCは監視モードにありますが、それには特別な目的があります。攻撃者はネットワークから締め出されたことに気づいた場合、時をおかずに再侵入を試みる可能性が高いため、ある程度の期間は警戒態勢を維持する必要があるのです。こうした攻撃は、再侵入が成功するか、攻撃者が疲弊するまで続きます。SOCの仕事は、徹底した監視と迅速な対応によって攻撃者を疲弊させることです。しかし、これは容易ではありません。SOCはインテリジェンスに関して、変わった矛盾を抱えているからです。 • SOCの分析担当者は、攻撃者が数カ月、場合によっては数年をかけてネットワークに侵入し、潜伏し、少しずつアクセス範囲を広げてきたこと、そしてつい最近、そのネットワークから締め出されたことを知っています。攻撃を検知する方法も知っています。攻撃者の行動を観察し、学習し、数々の IOCを研究してきたからです。

• 攻撃者は、再度ネットワークに侵入したいと考えています。以前の方法はもう通用しないことはわかっているため、戦術、ツール、手順を変えなければなりません。

これはSOCを厄介な状況に置くことになります。というのも、次の攻撃が迫っているにもかかわらず、その攻撃はこれまでのセキュリティ監視システムの設定では検出できない可能性が高いからです。この場合も、駆除日から少なくとも二週間はデバイスを厳密に監視し、いつでも迅速に行動できるようにしておきます。


73

攻撃者はまず、自分たちのマルウェアがC&Cサーバ（Command-and-Control server）にアクセスできなくなったことに気づきます。しばらくは原因を探ろうとするかもしれません。次に、攻撃者は自分たちの IPアドレスがファイアウォールでブロックされていることを発見します。ファイアウォールのログを調べ、DENY（拒否）イベントを把握することは重要です。これらのイベントは攻撃者が戻ろうとしている場所を示しているため、知らないうちにバックドアをしかけられ、侵害されていたシステムの発見につながる可能性があります。

攻撃者はシステムを侵害し、それを最初の侵入手段が利用できなくなった場合の「プランB（第二の手段）」とすることがあります。しかし、調査の段階で「プランB」のために悪用されているシステムを発見することは至難の業です。これらのシステムは攻撃に使用されているわけではないため、ネットワーク分析やフォレンジック（デジタル捜査）では浮かびあがってきません－しかし、これを見逃さないようにします。例えば侵害された内部ホストがC&Cサーバにチェックインしなくなった場合、攻撃者は数カ月前にウェブサーバに仕込んでおいたウェブシェルにアクセスしようとするかもしれません。しかし攻撃者のソース IPアドレスをブロックするようにファイアウォールの設定が変更されていれば、もはやネットワークのどこにもアクセスすることはできないのです。

ここから、SOCチームと攻撃者の知恵比べが始まります。もしチームがこのアラートに気づき、攻撃者が別の場所を経由してトラフィックを確立するよりも早く、ウェブサーバが侵害されていることに気づいたなら、SOCの勝ちです。逆に、もし攻撃者が別の場所経由でトラフィックを確立したり、何らかの方法で IPアドレスをブロックされていないアドレスに変え、隠しておいたバックドアにアクセスすることに成功したりした場合は、SOCの負けとなるかもしれません。システムのアーキテクチャによっては、プロセス全体を再起動する必要もあります。SOCの分析担当者とセキュリティチームの責任は極めて重大です。たとえ駆除活動は成功したとしても、その後に入念で周到で積極的な監視を実行しなければ、駆除プロジェクトに費やした多大な労力とコストは瞬く間に水泡に帰してしまうのです。

5.1.2 コントロールの検証駆除が成功し、ネットワークも強化できたら、次は組織全体に導入されたコントロールとブロックが、類似の攻撃が起きた場合にIR（Incident Response: インシデント対応）チームの注意を喚起するものとなっているかを検証します。その方法として効果的なのは「外部評価」です。あるチームが（ネットワーク所有者の許可を得て）会社のネットワークへの侵入を試み、未知の脆弱性を探ります。このチームには、最近ブロックした攻撃者が用いていたのと同様の手法と、評価したいシステムを識別するためのフラグを与えます。ただし、評価の目的にかなうのであれば、チームが自由裁量で他の手法も試せるようにしておきましょう。

駆除段階で導入されたコントロールは必ずテストしなければなりません。その理由はさまざまです。例えば、こうしたテストは企業のネットワーク防衛体制の弱点を発見する助けになります。重要な資産やデータがどれだけ厳重に守られているかを把握できるだけでなく、経営陣にネットワークの状況を伝える助けにもなります。本格的なテストであれば、セキュリティ侵害の証拠も発見できるかもしれません。


74

中・大規模企業の場合は、その後も少なくとも年に一度は社内ネットワークを対象に、コントロール監査や侵入テストを実施するようにします。このような監査・テストは、社員（必要な能力の持ち主がいるなら）が実施してもかまいませんが、できれば外部の機関に委託します。侵入テストに要する時間は、企業の規模、テストの目的、テスト担当者に与えられる情報の量によって変わってきます。

下記は、セキュリティコントロールの評価目標の例です（テストチームには企業名以外、ネットワークに関する情報は一切与えないものとします）。• テスト担当者が基幹システムにアクセスできるかを確認する。• テスト担当者が検知されることなくネットワークから脱出できるか、重要データを盗み出せるかを確認する。

• ソーシャルエンジニアリング攻撃に対する自社の脆弱性を評価する。• トレンドマイクロ社のサイバーセキュリティ担当バイスプレジデント、トム・ケラーマンの言葉を借りれば、「（既に）侵害されているデータベース（等のシステム）の観点から、システム内で攻撃者がどこまでアクセス範囲を広げ、バックドアをしかけられるか検討する」21

侵入テストの報告書が完成したら、発見された問題点を修正し、ネットワークを強化するために万策を尽くします。テストの結果、攻撃者によって発見され、悪用される可能性のある弱点があることが証明された以上、手をこまねいているわけにはいきません。

5.2 利害関係者への状況説明すべてのIOCとアーティファクトが駆除され、駆除コントロールが全社に導入されたことがある程度確認できたら、SOCは経営陣に状況を説明する必要があります。駆除活動の成功を報告するとともに、検証段階で何らかの例外や事実が発見された場合は、それらについても情報を提供します。

利害関係者への報告は、計画性を持って、速やかに行います。上層部にはイベントから一日以内に最初の連絡を入れ、その後で具体的な活動内容を報告します。こうした連絡は明確で、簡潔で、問題解決に焦点を合わせたものでなければなりません。まだ残っているギャップと、それを解消するための計画を明確に伝えましょう。駆除活動を通じて得た教訓を明記するとともに、同様の駆除イベントや活動を効率化し、会社への負担を減らすためのプロセスを駆除段階で導入した場合は、それも必ず伝えるようにします。

21 Homeland Security News Wire, “South Carolina Exploring Different Cybersecurity Plans,” 13November 2012 http://www.homelandsecuritynewswire.com/dr20121113-south-carolina-exploring-different-cybersecurity-plans


75

5.3 教訓駆除後の活動として、特に重要なのは得られた教訓についてのセッションを実施することです。これはチームのメンバーが連携し、経験から学ぶための長期的なプロセスと考えましょう。公式の教訓学習プログラムを立ち上げ、会議の進行や要対応事項への対応に責任を持つ人物を明確に定めることは、組織が過去の間違いやインシデント、経験から効果的に学ぶ助けとなるはずです。こうしたセッションを駆除後の段階でしか行わない企業もありますが、多くの企業は調査や駆除の段階でも定期的に実施することで効果を実感しています。

教訓学習プログラムを円滑に実施するためには、駆除段階での議論や意思決定を漏れなく書面で記録しておく必要があります。駆除後に教訓を共有するためには、文書化と協調が欠かせません。一刻を争う段階を過ぎたら、必ずインシデント対応に対するフィードバックを集めましょう。記録しておくべき情報には次のようなものがあります。 • 上手くいったことは何か?• 改善の余地のあることは何か?（セキュリティ関連の人、プロセス、技術を検討する）• 不測の事態の発生を予防できたか?　予防できた場合は、どのような方法をとったか? • フォローアップとして、ただちにすべきことは何か?

駆除活動が完了した後は、参加者を集めて報告会を開き、上手くいったことや改善の余地があることについて意見を交換します。ここで出た意見は、駆除段階で記録された教訓と合わせて、事後報告書に盛り込みます。図15は事後評価表の例です。

評価表を作成しても、教訓学習プログラムが修正しようとしている問題を解決できるわけではありません。しかし、予測可能で反復可能な教訓学習プロセスを作るためには、重要なステップです。このプロセスには分析担当者から管理職、一般職員まで、あらゆる関係者が参加するべきですが、関与の度合いは組織の文化や個人の能力に大きく依存します。


76

図15事後報告書のテンプレート

調査に要した時間

調査の種類

トリガー

対策本部の指揮担当者

情報の伝達手段

初期感染の経路（攻撃の標的、または実際に侵害されたもの）

対策本部による活動

活動を列記してください。

あらゆるレベルでタイムリーな情報伝達が行われたか?

伝達された情報は正確だったか?

実行された活動のうち、手元の調査と関係なかったものは何か?

被害が拡大しないように、チームメンバーは安全な方法を用いたか?

適切な設備を利用できたか?　本来は必要だが、今回は利用できなかったものは何か?　そのために対応の速度に影響が出たか?

チェックリストを使用したか?

作成すべきチェックリスト/プロセスはあるか?

改善すべきチェックリスト/プロセスはあるか?（詳細は下に記載すること）

特殊な状況や予想外の深刻な問題が生じたか?

他にどんな問題が生じる可能性があるか?　問題が生じた場合、どう対処するか?

業務は適切な担当者に割り振られたか?　必要な調整が行われたか?各担当者の仕事ぶりはどうだったか?

いつ対策本部の活動を完了するか?


77

図15事後報告書のテンプレート（続き）

対策本部の活動が完了した後の活動

具体的な活動内容を列記してください。　

教訓

対象分野

分野を列記してください。　

改善の余地のある分野（人、プロセス、技術）

分野を列記してください。　

どうすればインシデントの発生を避けられたか?　全社に技術 /プロセスを追加（変更）するとすれば何か?

要対応事項

アクションを列記してください。　

5.4 戦略的な変更－サイバーセキュリティ改革駆除イベントの成果物として、特に重要なのは当該インシデントの教訓を活かして、将来の攻撃に対するレジリエンスを高める方法をまとめたロードマップです。このロードマップには、攻撃の成功率を下げ、攻撃をより迅速かつ効果的に検知し、対処するための技術的・非技術的なプロジェクトやイニシアティブがまとめられています。セキュリティ侵害を分析する際には、攻撃が成功したのは技術的な問題か、それとも人やプロセスの問題に主因があったのかを検討します。

計画の段階で、チームは駆除前に実施すべき「修正」活動を明らかにしなければなりません。それ以外の活動は、駆除が終わるまでは達成できない可能性のある長期イニシアティブと見なします。以下に掲げる活動は、企業によっては長期戦略に分類されるものですが、攻撃者が用いる侵入・潜伏戦術によっては、駆除前に実施する必要があるかもしれません。長期戦略活動としては、以下のようなものが考えられます。

• デスクトップ環境　企業ネットワーク上のホストはすべて攻撃の対象となり得ます。一般に、数、監視・管理の難しさ、ユーザの技術教育水準の観点から、最も攻撃の対象となりやすいのはデスクトップホストです。可能なら、駆除日より前に新しいセキュリティ・ベースライン（自社において遵守が必要なセキュリティ対策のレベル）を定めるようにします。エンドユーザーの行動は予測できないため、デスクトップワークステーションの悪用は不可避であり、未然に防ぐ


78

ことはできないかもしれません。しかし、デスクトップ環境のセキュリティ・ベースラインを引き上げておけば、デスクトップホストが悪用されたとしても、ネットワークにつきつけられるリスクは大幅に下がります。主な方法は以下のとおりです。 – ローカル管理者グループからエンドユーザーを除外する。– ポリシーに定められているとおりに、アプリケーションとシステムにパッチが速やかに適用されていることを確認する。

– エンドポイントを守るためのウイルス定義ファイルを常に更新する。 – 高い特権を必要としない作業については、管理者も非管理者アカウントで作業するようにする。また、Windows 7®のような安全性の高いOSを導入する時間がない場合は、まず管理者グループのメンバーの環境に導入する。

• サーバ環境　サーバがネットワーク攻撃の始点になることはまれですが、一般に非公開の機密情報を探している攻撃者が標的とするのはサーバです。攻撃者がサーバを狙うのは、なるべく多くのパスワードを盗んでアクセスを拡大するため、またネットワークから持ち出すデータを得るためです。駆除チームは、サーバ環境へのパッチ適用状況を確認し、適用すべきパッチのリストを作成しなければなりません。サービスの利用状況を調べ、不必要なDAEMON（ディスク・実行監視）ツールを実行しているサーバやリスナーを見つけることも不可欠です。例えば、もしサーバ上でCIFS（Common Internet File System）ファイル共有をする必要がないなら、ホストに対する攻撃リスクを減らすために、この機能は無効にすべきです。ファイル共有が必要なサーバには、必ず最新のパッチを適用するようにします。管理上の目的のためだけに直接サーバにアクセスすることがないように、ネットワーク管理を導入します。管理上の目的でサーバにアクセスする必要がある場合は、ジャンプサーバを経由するようにします。ジャンプサーバとは、2つのセキュリティゾーンを分けている堅牢なシステムで、2つのゾーンを安全に行き来するための手段を提供します。これらのデバイスへのユーザーアクセスは厳密に管理・監視されます。ジャンプサーバを利用すれば、侵害されたホストと、特定の管理されたパスの外にあるサーバ間のコミュニケーションを制限できます。さらに、不要なアクセスチャネルを経由してサーバが交流することを防ぐために、アクセス制御も導入する必要があります。例えば、もしジャンプサーバとドメインコントローラの間でRDP（Remote Desktop Protocol）が使われているなら、そのドメインコントローラとRDPから、別のドメインコントローラに移動できないようにしなければなりません。管理者がサーバ間を移動する必要がある場合は、ジャンプサーバから別のセッションを開くようにします。こうすれば、管理上の活動を制御、記録、監視、制限できます。

• その他の取り組むべき分野　デスクトップ /サーバ環境を強化し、攻撃の成功率を下げること以外にも、サイバーセキュリティに関してすべきことはあります。以下に掲げた重要なテーマは、ほぼすべて複数のプロジェクトを必要とします。また、他のプロジェクトに依存しているものも少なくありません。サーバセキュリティのロードマップにおいて、プロジェクト管理が重要になる理由はここにあります。特に影響範囲の広いテーマには次のようなものがあります。


79

– サイバーセキュリティのためのPMO（プロジェクト管理オフィス）の設置と運営– セキュリティ教育・意識向上プログラムの開発– フィッシング詐欺の自己演習の定期的な実施– 社内の電子調査能力の強化– 企業パスワード変更管理プロセスの設計– 迅速なグローバルパスワード変更の実施– パスワードの一元管理ソリューションの選択と展開– 脆弱性の受容プロセスの策定– サイバーセキュリティについての企業ポリシーの改訂– 情報分類プログラムの開発 – 社内のLANマネージャの無効化– 環境内の匿名ユーザによる接続の制限 – 以下に対する管理・技術的制御の改善 :・ドメイン管理アカウント・ローカル管理者アカウント・サービス・機能アカウント・パスワードが無期に設定されているアカウント・ドメインアカウント

– アクティブディレクトリのセキュリティの強化（例 : 組織構造の見直し）– 以下のセキュリティツールの使用の最適化 : ・社内における暗号化・ホストベース /エンドポイントの保護テクノロジー・ DLP（Data Loss Prevention: 情報漏洩防止）とアンチウイルスソフトウェア

– 初期設定の認証情報の変更 – パッチ管理の強化– データベースのセキュリティ強化（Oracle, SQL, MySQL） – 高価値情報を保護するためのプログラムの開発 – 専門的技術情報ゾーンの設置 – 社内の技術コントロールの強化 – イントラネットからの現場の隔離 – egress（出口）フィルタリングの拡大 – PoP（Point-of-Presence）の数の削減 – ウェブメールのセキュリティの改善 – 多要素認証の導入 – SIEMシステムの導入 – アプリケーションのホワイトリストソリューションの選択と実装 – メッセージングインフラの強化 – ウェブアプリケーションのスキャンと安全性の確保 – インターネットのPoPにおけるフルパケットキャプチャとパケット調査の実行– 財務・電子送金機能のセキュリティの改善 – 情報セキュリティ機能の設計の見直し


80

– セキュリティコンプライアンスの強化 – セキュリティガバナンスの能力の強化 – アイデンティティとアクセスの管理機能の向上– 情報セキュリティガバナンス、リスク、およびコンプライアンスのためのシステムの導入 – ベンダーリスク管理プログラムの確立 – インサイダー脅威プログラムの実行– SOC の立ち上げ

第6章　結論

81

第6章　結論サイバーセキュリティにおけるインシデント管理のための段階的アプローチは、問題の発生そのものを防ぐことはできませんが、組織のレジリエンスを高めるという意味では大きな利点があります。入念に準備している企業は、準備が不十分または、まったくしていない企業と比べ、はるかに効果的に問題へ対処できます。

「準備」、「調査・駆除」、「事後対応」と段階を踏んで対処していくことで、企業は将来のセキュリティプログラムの基礎を築くことができます。まずは駆除活動が成功したことを確認し、その結果を利害関係者に簡潔に報告したのち、教訓を学ぶためのセッションを開催します。その後で、組織を変革するための戦略的な変化に取り組みます。

組織変革は、企業のセキュリティレベルを引き上げ、どんな事態にも対処できる体制を作る助けになります。ISACAは現在、企業のセキュリティ担当者による組織変革を支援するために、COBIT 5を利用した追加ガイダンスを作成中です。本ガイダンスは2013年第3四半期に発行され、www.isaca.orgで配布される予定です。


82

白紙ページ

付録A　調査チームが対応するその他の問題

83

付録A　調査チームが対応するその他の問題調査チームは攻撃の「実行者、標的、時期、場所、方法」に加えて、以下の問題も検討します。• 現在、会社が攻撃検知のために実行している基本的活動は、今日の新しい脅威に即したものとなっていますか ?

• 社内のコンピュータ資産をまとめた信頼できるリストはありますか?　リストの内容は随時更新されていますか?

• 社内の許可・無許可ソフトウェアをまとめた信頼できるリストはありますか?　リストの内容は随時更新されていますか?

• システム特権を持つアカウントは、通常のユーザーアカウントとは異なる方法で扱われていますか?

• 機密性の極めて高いアカウントへのアクセスを管理するために、パスワードの一元管理システムを導入していますか ?

• ユーザをコンピュータのローカル管理者グループから削除していますか? • パスワードの有効期限が無期限に設定されているアカウント、あるいはパスワードがほとんど変更されていないアカウントはありますか?

• 複数のドメインで利用できるシステム特権アカウントはありますか?（ユーザ IDとパスワードが同じなど）

• アカウント管理が難しい、入れ子式のグループが採用されていませんか? • ドメイン管理アカウントを適切に管理していますか ?　ドメイン管理アカウントは、他のグループに参加できないようになっていますか ?

• 脆弱性検知のために定期的にシステム全体をスキャンしていますか?　脆弱性が発見されたときは、リスクの度合いに応じて速やかに対処していますか?

• コンピュータの盗難に備えて、ディスク全体を暗号化する機能が導入されていますか?• 最新の企業向けアンチウイルスソリューションを導入していますか ?　すべてのエンドポイント（ネットワークと接続された端末）は最新のシグネチャとなっていますか ? • 企業データのリポジトリや共有ファイルに対して、定期的なウイルススキャンを実行していますか ?

• PKI（Public Key Infrastructure: 公開鍵基盤）は保護されていますか? • 特に重要な鍵と証明書は、エアギャップによるネットワークからの物理的な遮断がされていますか ?

• 以下のテクノロジーのセキュリティは適切な形で強化されていますか? – ファイアウォール、ルーター、プリンター、スイッチなどの機器 – データベースとアプリケーション – ノートパソコン、ワークステーション、サーバ

• デバイス、データベース、アプリケーションの初期アカウントはすべて変更されていますか? • 最近、テクノロジーコントロールを見直したり、更新したりしましたか?

– テクノロジーコントロールへの準拠状況を自動的かつ継続的に評価する仕組みはありますか?


84

• 以下のソフトウェアを常に最新の状態で利用できるように、信頼できるパッチ管理システムを導入していますか ?　– マイクロソフト製ソフトウェア – 他社製ソフトウェア（例 : Sun®/Oracle®Java、Adobe Acrobat/Flash、Apple QuickTime、

Google Chrome、WinZip ™、その他のブラウザー） • 重要なデータベースサーバやデータベースに安全にアクセスできますか? アクセス履歴は記録し、定期的に妥当性評価を実施していますか?

• サポートされていないOSやアプリケーション（例 : Windows NT®、Windows 2000®、Microsoft Office 2000®）は漏れなく環境から削除していますか?

• ファイアウォールやプロキシーサーバでは、不要なポート、プロトコル、サービスを利用できないようになっていますか?

• ワイヤレス・アクセス・ポイントは厳重に管理され、会社のセキュリティポリシーに沿って設定されていますか?

• ユーザがインターネットにアクセスする際は、事前にプロキシーサーバで認証されるようになっていますか ?– カテゴライズされていないサイトはプロキシーサーバでブロックしていますか? – ダイナミックDNSルックアップを禁止していますか?

• リモートアクセス（ウェブメールを含む）では必ず、多要素認証を行っていますか? • 一元的なロギング&監視システムを導入し、少なくとも次のシステムや機器からイベントログを収集していますか?– アクティブディレクトリ、ファイアウォール、DNS、DHCP、VPN、プロキシーサーバ、メッセージングシステム、アンチウイルスソフトウェア、IDS、IPS、DLP、ウェブフィルター機器

• インターネットに接続しているウェブアプリケーションを保護するために、アプリケーションファイアウォールを使用していますか?

• インターネットに提供しているウェブアプリケーションのコードを定期的にテストし、悪用可能な脆弱性がないかチェックしていますか?

• アプリケーション開発者は全員、安全なコーディングのための専門訓練を受けていますか? • 買掛金や資金データを扱うワークステーションは、安全性を確保するために、特定の目的以外には利用できないようになっていますか?

• 外部専門家による侵入テストを定期的に実施していますか? • セキュリティ意識向上プログラムの内容は刷新していますか?　すべての従業員、請負業者、オンサイトベンダー、合弁事業のパートナーに対し、毎年トレーニングを受けることを義務付けていますか ?

• 情報セキュリティ担当者に対し、毎年適切なトレーニングイベントに参加し、スキルを磨くことを義務付けていますか?

• 組織を守るために、より先進的な対策を講じていますか? • 会社の情報セキュリティに関するカルチャーは、今日の脅威環境にマッチしていますか?

– アクティブマネジメントでは、情報は資産とみなされていますか? – ニーズに応じて明確に信頼（トラスト）が割り当てられていますか? – 一般に、自分たちが高いリスクあるいは高い価値を有する標的だと自覚していますか?

付録A　調査チームが対応するその他の問題

85

– 「攻撃は防げない」という事実は周知されていますか? ―ネットワークは既に危険にさらされているか、近くそうなる可能性があり、そのような環境下で機密情報を保護する必要があるという理解は共有されていますか?

– 人とデータが「新たに防御すべき境界線」であることが理解されていますか? • 標準に基づいて、独立した評価を実施していますか? • 会社は、社外における情報セキュリティの一般的な動向を把握していますか? • 情報セキュリティに対するアプローチは、リスクに基づいた、ビジネス志向のものとなっていますか?

• ポリシー・エクセプション・プロセスに代わって、リスク許容プロセスを採用していますか? • 自社の環境にアクセスできるベンダーやサードパーティを主体的に管理していますか? • 情報セキュリティポリシーは組織の中枢から生まれたものですか? • 情報セキュリティはビジネス成功の鍵とみなされていますか? • データセンターのトラフィックは包括的に管理されていますか? • 承認されていない、または異常なネットワークトラフィックを間断なく監視し、警告を発する仕組みがありますか?

• 特に機密性の高い環境は、イントラネットの中心から、あるいはイントラネットそのものから切り離されていますか? – アクセス履歴は記録し、定期的に妥当性評価を実施していますか?

• 社内にSOC（Security Operation Center）機能がありますか?　ない場合、マネージド・セキュリティ・サービス（MSS）を介して、同様の機能を提供していますか?

• シグネチャベースでない、マルウェア（悪意あるソフトウェア）の検知機能はありますか? • 不審な行動を見つけるために、Eメールトラフィックやその他のネットワークトラフィックをチェックしていますか?

• 社内にはフォレンジック調査する機能がありますか?　その機能にはスタッフが十分に配置されており、専門訓練を受けたインシデント対応チームが存在しますか?

• メンバーサーバ環境へのアクセスを厳しく管理・監視するための踏み台サーバがありますか?• セキュリティリスクを減らすために、PCとサーバを仮想化していますか?• コアサーバと高いリスクを有するサーバで使用するアプリケーションのホワイトリストを作成していますか?

• 認証情報（credentials）は以下のように区分されていますか? – ワークステーション管理アカウントでは、メンバーサーバやドメインコントローラは利用できない。

– メンバーサーバ管理アカウントでは、ワークステーションやドメインコントローラは利用できない。

– ドメイン管理アカウントでは、ワークステーションやメンバーサーバは利用できない。 – ドメイン管理アカウントで利用できるのはドメインコントローラのみとし、必ず専用のノート

PCを使い、多元的なスマートカード認証を実行するものとする。– アプリケーションアカウントで利用できるのは、特定のアプリケーションまたはシステムのみとする。

• 過去にさかのぼって、潜在的な脅威を含むセッションを再現できるように、すべての出口（egress point）に強力なフルパケットキャプチャ機能を導入していますか?


86

• フィッシング詐欺の自己演習を実施し、これらの脅威を従業員がどれだけ認識しているかを把握するようにしていますか ?

• 機密データを守るために、ネットワークやエンドポイントにDLP（Data Loss Prevention: 情報漏洩防止）ソリューションを導入していますか?

• すべてのエンドポイントにローカルファイアウォールを設定していますか? – エンドポイントには必ず、IDS/IPSソリューションを導入していますか?

• イントラネットとインターネットの接点を制限していますか?（出口の統合など） • 意思決定のプロセスを後押ししている情報セキュリティ戦略はありますか?• 社内の情報セキュリティ組織は、今日の脅威環境に即したものとなっていますか?　また、これらの組織にはトレーニングを受けたスタッフが十分に配置されていますか?

• ソーシャル、モバイル、クラウドのための本格的なセキュリティプログラムは開発されていますか ?

• インサイダー脅威プログラムは開発・展開されていますか? • 以下の分野で強力な体制を整えていますか?

– セキュリティ・カバナンス・チームおよび組織 – ガバナンス・リスク・コンプライアンス（GRC）プログラム（組織を定期的にテストするためのセキュリティ・コンプライアンス・プログラムを含む）

– アイデンティティ&アクセス管理（IAM）プログラム – 脅威・脆弱性管理（TVM: Threat and Vulnerability Management）プログラム – エンタープライズリスク管理（ERM）機能に組み込まれた情報セキュリティリスク管理プログラム

– ベンダーリスク管理プログラム • 情報セキュリティポリシー、標準、手続き、ガイドライン、推奨事項は、すべて更新されていますか ?

付録B　調査ツール

87

付録B　調査ツール調査に必要なツールには、自由に利用できる仮想マシン・インスタンスが組み込まれていることがあります。これらの仮想マシンには、あらかじめ認証情報（credentials）が設定されていますが、その内容は多くの場合、初期値から変更する必要があります。下記は、ごく一般的なオープンソースの仮想マシンとそのパスワードの一覧です。これらのパスワードを使うと、仮想マシンと、設定によってはホストの一部に管理者としてアクセスできます。• SANS SIFTワークステーション : Investigative Forensic Toolkit

– ログイン : sansforensics – パスワード: forensics – http://computer-forensics.sans.org/community/downloads#login

• REMnux: A Linux Distribution for Reverse-Engineering Malware – REMnuxでのユーザ名 : remnux – このアカウントの初期パスワード: malware – http://zeltser.com/remnux/remnux-malware-analysis-tips.html

• Backtrack: A Linux Security Distribution – 初期ユーザ名 : root – 初期パスワード: toor – http://www.backtrack-linux.org/wiki/index.php/Basic_Usage#Changing_the_root_

password


88

白紙ページ

Documents

標的型サイバー攻撃 への対応 - Information Technology ...ª $ ± Ì È 8 w 0 4 Acknowledgments Development Team: Chris Crevits, CISSP, CCNA, Ernst & Young LLP, USA Jose

標的型サイバー攻撃への対応 - Information Technology ...ª $ ± Ì È 8 w 0 4 Acknowledgments Development Team: Chris Crevits, CISSP, CCNA, Ernst & Young LLP, USA Jose