標的型サイバー攻撃への対応 標的型サイバー攻撃への対応 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 ガバナンスと経営責任を果 たすために役立っています。 Disclaimer ISACA 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 環境によって 提示された状況に対し、専門家として独自に判断する必要があります。 2 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 から文書による事前許諾を受けずに、いかなる方法、いかなる媒体（電子媒体、機械媒体、複写、 録音、その他）によっても無断で使用、複製、複写、変更、配布、表示、検索システムへの保存、転送するこ とは禁じられています。本書の一部あるいは全部について、本書の複写および使用は、学術的、内部的、 非営利的な目的、およびコンサルティング / アドバイザリー業務に限られ、情報源についてすべて記載する 必要があります。その他のいかなる権利や許可が与えられることはありません。 ISACA 3701 Algonquin Road, Suite 1010 Rolling Meadows, IL 60008 USA Phone: +1.847.253.1545 Fax: +1.847.253.1443 Email: info@isaca.org Web site: www.isaca.org Provide Feedback: www.isaca.org/Cyberattacks Participate in the ISACA Knowledge Center: www.isaca.org/knowledge-center Follow ISACA on Twitter: https://twitter.com/ISACANews Join ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficial Like ISACA on Facebook: www.facebook.com/ISACAHQ Responding to Targeted Cyberattacks 3 標的型サイバー攻撃への対応 Acknowledgments Development Team: Chris Crevits, CISSP, CCNA, Ernst & Young LLP, USA Jose Granado, CISSP, America’s Practice Leader, Information Security Services, Ernst & Young LLP, USA James O. Holley, CCE, NSA ISSO, NSA ISSP, Ernst & Young LLP, USA Patrick J. Hynes, CISA, CISM, CCNA, CISSP, NSAIAM, Ernst & Young LLP, USA David C. Kovar, CCE, CISSP, EnCE, GCFA, GCIH, GREM, Ernst & Young LLP, USA Mark G. Manglicmot, CEH, CISSP, GCIH, Security+, Ernst & Young LLP, USA Austin J. Murphy, GCFA, Security+, Ernst & Young LLP, USA Daniel J. Quealy, CAMS, CIWM, GSEC, HTCIA (past president), NSAIAM, Ernst & Young LLP, USA Joshua Theimer, CISA, CISSP, Security+, Ernst & Young LLP, USA Bryan C. York, CEH, CISSP, Linux+, Security+, Ernst & Young LLP, USA Subject Matter Expert Reviewers: Vilius Benetis, Ph.D., CISA, CRISC, BAIP, Lithuania Jeimy Cano, Ph.D., CFE, CMAS, Ecopetrol, Colombia Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, BRM Holdich , Australia, Director Rolf M. von Roessing, CISA, CISM, CGEIT, CISSP, FBCI, FORFA AG, Switzerland ISACA Board of Directors Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, International President Allan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK, Vice President Juan Luis Carselle, CISA, CGEIT, CRISC, Wal-Mart, Mexico, Vice President Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice President Ramses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, Six Sigma Black Belt, Dell, Spain, Vice President Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia, Vice President Jeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice President Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice President Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Past International President Emil D’ Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd., (retired), USA, Past International President John Ho Chi, CISA, CISM, CRISC, CBCP, CFE, Ernst & Young LLP, Singapore, Director Krysten McCabe, CISA, The Home Depot, USA, Director Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, BRM Holdich, Australia, Director Knowledge Board Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Chairman Rosemary M. Amato, CISA, CMA, CPA, Deloitte Touche Tohmatsu Ltd., The Netherlands Steven A. Babb, CGEIT, CRISC, Betfair, UK Thomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USA Phil J. Lageschulte, CGEIT, CPA, KPMG LLP, USA Jamie Pasfield, CGEIT, ITIL V3, MSP, PRINCE2, Pfizer, UK Salomon Rico, CISA, CISM, CGEIT, Deloitte, Mexico 4 Acknowledgments Guidance and Practices Committee Phil J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman Dan Haley, CISA, CGEIT, CRISC, MCP, Johnson & Johnson, USA Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France Aureo Monteiro Tavares Da Silva, CISM, CGEIT, Brazil Jotham Nyamari, CISA, Deloitte, USA Connie Lynn Spinelli, CISA, CRISC, CFE, CGMA, CIA, CISSP, CMA, CPA, BKD LLP, USA Siang Jun Julia Yeo, CISA, CPA (Australia), MasterCard Asia/Pacific Pte. Ltd., Singapore Nikolaos Zacharopoulos, CISA, CISSP, DeutschePost–DHL, Germany ISACA and IT Governance Institute® (ITGI®) Affiliates and Sponsors Information Security Forum Institute of Management Accountants Inc. ISACA chapters ITGI France ITGI Japan Norwich University Socitum Performance Management Group Solvay Brussels School of Economics and Management Strategic Technology Management Institute (STMI) of the National University of Singapore University of Antwerp Management School ASIS International Hewlett-Packard IBM Symantec Corp. ISACA thanks Ernst & Young for its generous donation of services to develop this publication. 監修 新日本有限責任監査法人 横川 晴良 CISA, CPA 新日本有限責任監査法人 大野 陽生 CISM, CISA, CISSP, CIA, PMP 翻訳・レビュー 新日本有限責任監査法人 小高 光雄 CISA Ernst & Young Australia Richard Keirstead CISM, CISA, CGEIT, CISSP 新日本有限責任監査法人 青波 久恵 CISA 新日本有限責任監査法人 宮崎 恵一 CISM, CISA, CFSA, MBA 新日本有限責任監査法人 阿部 耕平 CISM, CISA 新日本有限責任監査法人 国川 弓代 MBA 5 標的型サイバー攻撃への対応 目次 第 1 章 はじめに ............................................................................................................... 9 1.1 改革の必要性に関するケーススタディ ........................................................................ 9 1.2 脅威の進化 ............................................................................................................. 10 1.3 進化する攻撃経路 .................................................................................................. 13 1.4 転機 ....................................................................................................................... 15 1.5 APT のライフサイクル ............................................................................................. 16 1.6 さまざまな対応策 ................................................................................................... 20 1.7 まとめ .................................................................................................................... 21 第 2 章 準 備 .................................................................................................................. 23 2.1 2.2 チームの構築と計画の立案 ...................................................................................... 23 重要な関係の構築 ................................................................................................... 23 2.2.1 2.2.2 2.3 2.4 2.5 2.6 内部との関係 ............................................................................................ 24 権限の明確化 ......................................................................................................... 24 社内で利用されている技術の一覧化 ......................................................................... 25 調査プロセスの標準化 ............................................................................................. 26 トレーニングとガバナンス ....................................................................................... 28 2.6.1 2.6.2 2.7 外部との関係 ............................................................................................ 23 訓練 ......................................................................................................... 28 セキュリティプログラムと対応計画の見直し ................................................ 29 必要不可欠な能力の確立 ........................................................................................ 29 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 2.7.6 2.7.7 ホストレベルの活動把握 ............................................................................ 31 ネットワークレベルの活動認識 .................................................................. 34 検索 ........................................................................................................ 35 コンピュータ・フォレンジック分析 ............................................................. 36 マルウェア分析 ......................................................................................... 37 サイバー情報収集活動 ............................................................................. 37 脆弱性の特定............................................................................................ 41 第 3 章 調 査 .................................................................................................................. 43 3.1 セキュリティ侵犯の調査 .......................................................................................... 43 3.2 誰が攻撃しているのか ? .......................................................................................... 47 3.3 何が標的とされたか ? .............................................................................................. 47 3.4 さまざまな事象はいつ起きたのか ? .......................................................................... 48 3.5 攻撃はどこから来ているのか ? ................................................................................. 48 3.6 なぜ攻撃されたのか ? ............................................................................................. 49 3.7 攻撃者はどのように侵入し、潜伏し、データを持ち出したのか ? ...........................................50 3.8 その他検討が必要な重要分野 .................................................................................. 50 6 目次 3.9 情報収集の質 .......................................................................................................... 51 3.10 証拠の取り扱い ...................................................................................................... 51 3.10.1 文書の保全と収集 .................................................................................... 52 3.10.2 証拠保管の連続性 .................................................................................... 52 3.10.3 MD5ハッシュ値の取得 .............................................................................. 53 3.10.4 ライトブロッカー ....................................................................................... 53 3.10.5 レコード数の照合 ...................................................................................... 53 3.10.6 弁護士・依頼者間の秘匿特権または弁護士のワークプロダクトの秘匿特権 ..........54 3.10.7 保険金の請求............................................................................................ 54 3.11 調査の匿名性 .......................................................................................................... 54 3.12 調査活動の保護 ..................................................................................................... 55 3.12.1 データ ...................................................................................................... 55 3.12.2 移動中のデータ ........................................................................................ 55 3.13 調査活動の保護 ..................................................................................................... 55 3.13.1 認証情報の保護 ....................................................................................... 56 第 4 章 駆 除 .................................................................................................................. 57 4.1 駆除計画の立案 ...................................................................................................... 57 駆除活動チームの設立 ............................................................................. 57 4.1.1 駆除活動計画の立案 ................................................................................ 58 4.1.2 駆除日の決定 ........................................................................................... 59 4.1.3 攻撃者の戦術、方法、手順の理解 ............................................................... 59 4.1.4 コミュニケーションプロトコルの確立 .......................................................... 60 4.1.5 「対策本部（War Room）」の設置 .............................................................. 62 4.1.6 安全なコミュニケーションと情報共有のメカニズムの確立 ........................... 62 4.1.7 4.2 計画の実行 ............................................................................................................ 63 パスワード変更 ........................................................................................ 64 4.2.1 攻撃者による指令・制御のブロック ........................................................... 66 4.2.2 侵害されたシステムの再構築 .................................................................... 67 4.2.3 アンチウイルスベンダーへのマルウェアの提供 ........................................... 68 4.2.4 4.3 再侵入活動の監視 .................................................................................................. 68 第 5 章 駆除後の対応 ..................................................................................................... 71 5.1 駆除活動の検証 ..................................................................................................... 71 警戒態勢の維持 ........................................................................................ 71 5.1.1 コントロールの検証 .................................................................................. 73 5.1.2 5.2 利害関係者への状況説明 ........................................................................................ 74 5.3 教訓 ....................................................................................................................... 75 5.4 戦略的な変更−サイバーセキュリティ改革 ................................................................ 77 7 標的型サイバー攻撃への対応 第 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 8 第 1 章 はじめに 第 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 社を狙った攻撃が続いているという事実を受けて、サイバーセキュリティに対するこの企 業の態勢を評価することでした。端的に言えば、 「わが社が同様の攻撃を受けたとしたら、どうな るか ? 的確に対処できるか ? 攻撃を困難にするためにはどうすればいいか ? 攻撃の進行を 検知し、対処するためには、どうすればいいのか ?」といった問いに答えることです。 9 標的型サイバー攻撃への対応 チームは攻撃の動機や顧客企業の技術インフラへのアクセス手段などを基に 10の評価シナリ オ 1を作成し、実行しました（図 1）。 図 01 10の評価シナリオ 悪意あるインサイダー 外部からの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）合弁会社とのネットワークを 通じてイントラネットが攻撃された。 10 第 1 章 はじめに 図 02 脅威の進化 高度な攻撃 （ハッカー） 産業スパイ （インサイダー） 国家による攻撃 （APT: 高度で執拗な脅威） 標的は、インターネットと接続し、 かつネットワークに脆弱性が 存在する企業。 標的は、 インターネットと接続し、 かつ価値ある情報を 持っている企業。 現役社員か元社員が、 会社の知的財産を使って 金銭を得ようとしている。 標的は、攻撃者にとって 高い価値を持つ個人、 活動、 あるいは知的財産。 ＡＰＴ 単純な攻撃 （クラッカー） 個人の利益 情報収集 ハッカー リスク インサイダー 国家資金による スパイ活動・ サイバー兵器 データの 持ち出し 金銭目的 最初の悪用 APTの ライフサイクル クラッカー 特権獲得 指令・制御 気晴らし/ 実験/ 嫌がらせ 攻撃者のリソース/洗練度 2012 1980年代/1990年代 ➢ 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 3 4 Cohen, Fred, “Experiments With Computer Viruses,” 1984, http://all.net/books/virus/part5.html 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/ Morris ワーム（単に「1988 年のインターネットワーム」とも呼ばれる）は、インターネットを介して広まった黎明期のコンピュータ ワームであり、世界初のワーム（少なくとも主要メディアで報じられ、大きな話題となった初のワーム）として知られる。また、米国 の 1986 年コンピュータ不正行為防止法（Computer Fraud and Abuse Act）に基づく有罪判決が出たのも、この事件が最初であっ た。このワームはコーネル大学の学生だったロバート・タッパン・モリスが作成したもので、1988 年 11 月 2 日に MIT から放たれた。 5 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 ポリモルフィックコード（Polymorphic code）とは、ポリモルフィックエンジンを使って、元のアルゴリズムを保ったまま変化してい くコードのこと。コードは実行されるたびに変化するが、コードの機能（意味）は変化しない。ウイルスの作者たちはシグニチャによ るアンチウイルス検知を避けるために、ポリモルフィックコードの手法を取り入れるようになった。 11 標的型サイバー攻撃への対応 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 メールアカウ ントに送信されることになりました。残念ながら、企業の防御体制は技術の変化に追いついてい ません。 12 第 1 章 はじめに サイバーセキュリティの専門家たちは技術革新のスピードについていくために四苦八苦してい ますが、問題はそれだけではありません。ハッカー志望者のための “ 教材 ” が増え、その多く がオンラインで手軽に入手できるようになったのです。例えば脆弱性テストに革命を起こした Metasploit® フレームワークは、侵入テストの担当者（あるいは担当者を装った人物）が強力な 脆弱性スキャンの実行を可能にしました。Metasploit のオープンソースあるいは商用のテスト ツールは、信頼できる人物による侵入テストだけでなく、攻撃者が不純な目的を達成するために も利用されています。 自動化されたツールを使えば、今やたった一回の攻撃でも世界中の何十万台ものコンピュータ に損害を与えられるようになりました。例えば米連邦捜査局（FBI）の報告書によると、2010 年に ロシアのハッカー集団が銀行口座の認証情報を盗み出すために作った Coreflood ボットネット は、世界各国の 230 万台のコンピュータに損害を与えました。報告書にはこう書かれています。 （感染したシステムは）およそ 17の州政府と地方自治体政府の関連機関に及んだ。具体的に は、警察（1）、空港（3）、軍事関連業者（2）、銀行・金融機関（5）、大学（30 前後）、病院・医療 関連会社（20 前後）、そして何百もの企業である 6。 攻撃者たちは、標的を困らせ、面目を失わせるために、サーバ、デスクトップ / ワークステーション、 ラップトップクラスのシステムやアプリケーションソフトウェアの脆弱性を悪用しました。また、さ まざまなボットネットを使って銀行口座の認証情報を手に入れ、金銭的利益を得ようとしました。 そして高度なマルウェアを使って、大企業の知的財産を盗み出そうとしました。政府から資金供 与を受けている攻撃者グループは、自国の国有企業が競合企業よりも優位に立てるように、何 億米ドルもの価値を持つ知的財産を盗み出しました。今日では、正体を隠して標的に重大な損 害を与える悪意あるソフトウェアは兵器としても使われており、既にいくつかの国の政府が政治 的な思惑から現実の世界に影響を及ぼすためにサイバー兵器を活用しています。史上初のサイ バー空間における誘導爆弾として知られるスタックスネット（Stuxnet）は、その一例です 7。 1.3 進化する攻撃経路 企業が自社の防御戦略を見直しはじめている一方で、攻撃者も既存の攻撃経路や進化する攻 撃経路に新しい革新的な攻撃手法を取り入れているため、脅威は今後も進化し続けるでしょう。 図 3は、最近報道された 3つの事例を使って、進化する攻撃経路の概念（本来の標的である B 社 を攻撃するための手段として A 社を攻撃する）を説明したものです。 6 7 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 スタックスネット（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-waveofcyberattacks-against-iran.html?pagewanted=all. 13 標的型サイバー攻撃への対応 図 03 進化する攻撃経路 セキュリティ上の問題 セキュリティ上の解決策 進化する攻撃経路 単一要素認証（例：ユーザーが知っ て い る も の、ユ ー ザ ー ID や パ ス ワードなど）は、セキュリティを確 保する手段としては脆弱すぎる。パ スワードは盗まれやすく、推測され やすい。 多要素認証を採用する―ユーザー が知っているもの（ユーザー ID、パ スワード）とユーザーが持っている もの（トークンを利用して入手するパ スワード。パスワードの内容は、強 力な暗号アルゴリズムを用いて定期 的に変更される）を組み合わせる。 トークンベンダー（RSA 社、2011 年 ３月）に潜入し、実際の標的（トー クンベンダーの顧客）が使用してい る 暗 号 鍵 を 盗 み 出 す（Lockheed martin 社、2011 年 5 月）。 マルウェアの開発者は何千人も存 在する。その中には自分が書いた コードを、あたかも信頼できる企業 のコードであるかのように偽る者も いる。 デジタル証明書を導入し、ベンダー がコードの信頼性を保証するため に、自社のコードに「署名（シグネ チャ）」をつけられるようにする。 ほぼすべてのコンピュータに導入 されているソフトウェアの 開 発 元 （Adobe 社）に潜入し、その企業が コードに署名するために使用してい るインフラを使って、悪意あるコー ドに署名する（2012 年 9 月）。 アンチウイルス型のアプローチ（「有 害」ソフトウェアを定義し、それをブ ラックリストに載せたり、隔離したり する）では、マルウェアの開発ペー スについていくことはできない。今 日では、毎日 20 万を超えるブラック リストシグネチャが新たに作られて いる。 アプリケーションのホワイトリストを 作成する（「信頼できる」ソフトウェ アを定義し、それ以外のものはすべ て「有害」と判断する）。 アプリケーションのホワイトリストを 作成しているベンダー（Bit9 社）に 侵入し、そのベンダーがコードに署 名するために使用しているインフラ を使って、悪意あるコードに署名し、 そのコードがホワイトリストに掲載 されるようにする（2013 年 2 月）。 創造的で有能な攻撃者たちによる精力的な活動を通じて、脅威の世界は広がり続けています。 攻撃者が適応し、変化している以上、企業も適応し、変化しなければなりません。企業はサイバー セキュリティの辞書から「予防」という言葉を消す必要があります。高度な攻撃者の侵入を防ぐ ために、すべての企業が導入できるソリューションなどないからです（ネットワークから切り離さ れていたナタンズのウラン濃縮施設ですら、攻撃者の侵入を許したことを思い出してください）。 ひとたび潤沢な資金と高度な技術を持つ攻撃者の標的となったら、彼らの侵入を防ぐことはでき ません。今日の情報セキュリティ専門家に求められているのは、次のような態度です : ネットワー クは既に侵害されているか、まもなく侵害されることになる。そのとき、最重要データをどう守 るか ? どうすれば攻撃への守りを強化できるか ? どうすれば進行中の攻撃を検知できるか ? 今日の高度な攻撃に対応するには、どうすればいいのか ? ネットワークは既に侵害されているか、まもなく侵害されることになる。 そのとき、最重要データをどう守るか ? どうすれば攻撃への守りを強化できるか ? どうすれば進行中の攻撃を検知できるか ? 今日の高度な攻撃に対応するには、どうすればいいのか ? 14 第 1 章 はじめに 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 9 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 Bejtlich, Richard, “What APT Is (and What It Isn’ t),” Information Security, July/August 2010 15 標的型サイバー攻撃への対応 1.5 APT のライフサイクル 歴史をひもとくと、過去の優秀な攻撃者たちはみな、その動機、資金源、指示者を問わず、特定 のサイクル（図 4、5）に従って標的を攻撃していたことがわかります。 図 04 APTのライフサイクル 情報収集 データの 持ち出し 最初の悪用 APTの ライフサイクル 特権獲得 図 指令・制御 05 情報収集 背景調査 APTのライフサイクル （別の視点） 最初の悪用 最初の 攻撃 足場の 確保 指令・制御 潜伏 社内 ネットワークの 偵察 特権獲得 アクセス 範囲の 拡大 特権獲得 データの 持ち出し 目的情報の 収集と 暗号化 データの 持ち出し 潜伏の 継続 以下は、APT のライフサイクルを構成している各段階の説明です。 ・ 背景調査 APT は標的を詳細に調べ、攻撃に使う具体的な経路を見つけます。あなたが フォーチュン 100 社の幹部だとします。業界会議からオフィスに戻り、メールソフトを立ち上げ ると、会議の講演者を名乗る人物から、 「今日は私の講演をお聞きいただき、ありがとうござい ました」というお礼のメールが届いていました。その E メールには、講演で使われていたプレ ゼン資料の最新版が添付されていました。あなたなら、このファイルを開きますか ? あるい は、あなたが大企業の法務担当役員だとします。契約している社外弁護士を名乗る人物から、 地方裁判所に提出された新しい訴訟の情報と訴状のコピーを添付した E メールが届きまし た。あなたなら、そのファイルを開きますか ? これらのシナリオは、標的に望み通りの行動を とらせるために APT による詳細な調査の一例です。 16 第 1 章 はじめに ・ 最初の攻撃 一般に、最初の攻撃はソーシャルエンジニアリングの手法を使って、ひとりまたは複 数の個人に対して行われます。例えば Eメールやインスタントメッセージ、ソーシャルメディアへ の投稿といった攻撃経路に悪意あるコンテンツへのリンクを埋め込み、標的が添付ファイルを開く か、リンクをクリックすると、一つか複数の機器が悪意あるソフトウェアに感染します。 ・ 足場の確保 ユーザが行動を起こしたら、APT は悪意あるカスタムソフトウェアを使って、標 的とした環境に最初の足場を確保します。これらのカスタムソフトウェアは、アンチウイルスの アラートを引き起こすことはまずありませんが、攻撃が成功したことを APT に伝える経路とな ります。初期の感染ツール（一次マルウェア）には有害な機能はほとんどありませんが、攻撃 の経路となって、追加機能（二次マルウェア）をダウンロードします。 ・ 持 続 的 アクセス の 実 現 APT の 主 な 目 的 の 一 つ は、侵 害したコンピュータ内 に C&C （control-and-command: 指令・制御）の拠点を作ることです。つまり、たとえ標的とした機 器が再起動されても制御とアクセスを維持し、いつでも標的とした環境に接続できるようにす るのです。その手段として、たいていの攻撃者は起動時に自動的に実行されるサービス（C&C ソフトウェアを含む）を標的としたコンピュータにインストールします。ユーザが直接サービス に対して何かをすることはまずないため、多くのユーザはサービスが実行されていることに気 づきません。別の方法としては、システムレジストリを書き換え、コンピュータが起動するたび に悪意あるアプリケーションが自動的に実行されるようにすることで、標的環境への持続的な アクセスを実現する場合もあります。ただし、これは攻撃者にとってはリスクの高い方法です。 アプリケーションが実行されていることにユーザが気づき、アプリケーションを終了させる可能 性があるからです。あるいは、正当な OS やアプリケーションソフトウェアのコンポーネントの 代わりに C&C 機能を強化するようなコンポーネントをインストールすることで、持続的なアク セスを実現することもあります。 ・ 社内環境の偵察 標的とした環境に持続的にアクセスできるようになったら、次は目的の情 報が格納されているコンピュータ、サーバ、あるいは記憶領域を見つけるために社内環境を 偵察します。通常、偵察は侵入したコンピュータに既にインストールされているツールを使っ て行われますが、特定のシステム（例 : ID/ アクセス管理、認証、仮想プライベートネットワーク ［VPN］、データベース、E メールサーバ）を見つけるために、スキャニングツールがアップロー ドされる場合もあります。 ・ アクセス範囲の拡大 社内環境の偵察過程では、新しいシステムにアクセスして、その中身を 探ったり、他にアクセスできる場所はないかを見て回ったりする作業が発生します。また、持続 的なアクセスを実現するためには、新たにアクセスしたシステムに C&C ソフトウェアをインス トールすることも欠かせません。 ・ 特権獲得 攻撃者は標的企業のネットワークを偵察し、最初のいくつかの標的から盗み出し た認証情報を使ってネットワーク内を動きまわります。ネットワークをくまなく探るためには、 「ローカルユーザー」から「ローカル管理者」へ、そしてさらに高いレベルの管理者へとアクセ ス権限のレベルを上げていく必要があります。情報へのアクセスが厳しく制御されている企業 17 標的型サイバー攻撃への対応 でも、環境（通常は 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 攻撃を防ぐことは、別のものとし て考えなければなりません。 18 第 1 章 はじめに APT は自分たちの戦術、方法、手順を、一般的な情報セキュリティアーキテクチャにも適用しま した（図 6）。 図 06 APTの手口 従来のセキュリティ慣行 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 をリアルタイムでフィル サードパーティのサイトに侵入し、マルウェアを埋め込 タリングする。 む。侵入するサイトは標的や攻撃ごとに変える。 19 標的型サイバー攻撃への対応 1.6 さまざまな対応策 APT やその他の先進的な攻撃者は、標的企業の環境に合わせて攻撃の形を変えているため、 標的企業はさまざまな方法で―時には極めて先進的な方法で―対応できます。 （図 7） 図 07 さまざまな対応策 高度 インターネットからの切断 認証のパーティショニング 「ジャンプ」サーバー 重要データのエアギャップ（ネットワークの物理的な遮断） 諜報防止活動 中程度 アウトバウンドゲートウェイの強化 継続的な監視/SOC 独自のEメールスキャニング 重要なデータ/ネットワークの隔離 プロキシー認証 事前対策のためのAPT評価 定期的なフィッシングシミュレーション PCの仮想化 コアサーバー上のアプリケーションのホワイトリスト作成 アクセス制御の強化（2FA、パスワードの一元管理、HPA管理） 基礎 パッチ、 コンフィギュレーション管理の見直し 検索可能な状態でのイベント蓄積(SIEM） 先進的なマルウェア検知 ネットワーク機器（フルパケットキャプチャ） インシデント対応/フォレンジック捜査能力の整備 対応の複雑度 SOC＝セキュリティ・オペレーション・センター 2FA＝二要素認証 HPA＝ハイプロファイル資産 SIEM＝セキュリティ情報イベント管理 ※「ジャンプ」サーバー＝2つのセキュリティゾーンを分けている堅牢なシステムで、2つのゾーンを安全に行き来 するための手段を提供する。 すべての企業が先進的な対応策の導入を検討するわけではありません。例えばインターネットと の接続を切ってしまえば、パートナー、供給業者、顧客とのつながりを要件とする重要な業務プ ロセスが断絶されてしまうかもしれません。その他の対応策も効果はありますが、企業によっては 「やりすぎ」と判断されることがあります。グローバル企業では、ほぼ常に最高水準の仕事が求 められるからです。 多くの企業は一般的な対応策を採用しています。APT などの先進的で高度な攻撃は非常に成 功率が高いため、必要最低限の対応策はすべて導入することを推奨します。 20 第 1 章 はじめに 1.7 まとめ この 10 年で脅威を取り巻く環境は劇的に変わりました。ほとんどの企業は、その変化に対応でき ていません。この後のページでは、図 7で初級に分類した対応策のいくつかを取り上げます。それ は「ネットワークは必ず破られる」という新たな見解が企業にもたらす主要な疑問を解消します。 企業が高度な標的型サイバー攻撃を調査するためには、この種の攻撃についての基礎的情報が欠 かせません。こうした攻撃の中には、政府機関から資金供与を受けて、特定の企業の環境に足場を 確保することを目的としたものもあります。攻撃の主体は「APT」かもしれないし、APT 的なアプロー チや手法を採用した、別の機関かもしれません。いずれにしても、企業が相手にしなければならな いのは、先進的で、高度で、組織化され、潤沢な資金を持つ、執拗な敵です。企業に求められている のは、侵犯を調査すること、調査によって得られた脅威情報を基に詳細な改善・撲滅計画を立て、 実行すること、そして攻撃者を自社の環境から完全に駆除することです。 21 標的型サイバー攻撃への対応 白紙ページ 22 第 2 章 準 備 第 2 章 準 備 2.1 チームの構築と計画の立案 セキュリティ侵犯への対応準備に時間と資源を費やしている企業は、そうでない企業と比べて、は るかに上手く対応や駆除への取り組みを進めることができるでしょう。 目的 : セキュリティ侵犯の調査や駆除を徹底的かつ効率的に進めるための人材、計画、能力を整 備すること。 サイバーセキュリティ侵犯を調査するため綿密に準備された体制を整備することの必要性につ いて経営陣に納得してもらうことは難しいかもしれません。たいていの経営者は難色を示し、こう 質問してくるでしょう。 「最初から、誰も侵入できないようにすればいいのに、なぜ侵犯への対応 準備に労力を費やさなければならないのだ ?」 しかし現実には、企業がいかに強固な防御態勢を築いていようと、強力な手段と明確な意思を 持った攻撃者の手にかかれば、企業が導入するいかなる複雑な予防、検知対策の多寡にかかわ らず、それらは打破されてしまいます。つまり、特定の企業に標的を定めている攻撃者は、極め て高い確率で一定の成功を収めます。しかも、彼らは標的のネットワークに入り込み、しっかりと 足場を確保していることが多いため、駆除するのは至難の業です。 「攻撃は遅かれ早かれ成功する」という前提に最初から立って、サイバー攻撃に備えておけば、 調査・駆除活動を効率的かつ包括的に進めることができます。では、どのように準備を進めれ ばよいのでしょうか ? 以降のセクションでは、企業がサイバーセキュリティ侵犯を効率的かつ効 果的に管理する上で取りえる 6つの活動について触れていきます。 2.2 2.2.1 重要な関係の構築 外部との関係 セキュリティ侵犯を効率的かつ効果的に調査するためには、侵犯が実際に発生する前に、重要 な第三者との関係を築いておく必要があります。ここでいう第三者には、取引関係、合弁会社、 社内ネットワークに何らかの形でアクセスできる者、請負業者（常駐、非常駐の両方）の他、会社 の業務に悪影響が出た場合に影響を受ける可能性のある関係者すべてが含まれます。第三者 を特定したら、全員の連絡先情報を集め、適切な人物（管理責任者、ネットワーク・セキュリティ・ チームのリーダーなど）が簡単にアクセスできる場所に保管します。 このような関係を事前に築いていない企業は、セキュリティ侵犯が発生してから、迅速な対応を 助けてくれるセキュリティ会社や専門家を慌てて探す羽目になります。これに対して、こうした関 係を事前に築き、万一に備えて第三者と契約していた企業は、本格的な調査や駆除にはるかに 円滑に着手できます。企業の規模や社内のセキュリティ・オペレーションの成熟度が、侵犯の調 査や駆除対応に第三者がどれだけ関与させるかの決定において重要な位置を占めます。成熟 23 標的型サイバー攻撃への対応 度の高いセキュリティプログラムを持つ企業であれば、こうした活動の大半を社内で処理できる かもしれません。一方、不十分なセキュリティプログラムしか持たない企業は、第三者に全面的 に頼ることになるかもしれません。企業がそのような状況に陥っているかに関わらず、攻撃を受 ける前に、以下に示す数多くの第三者との関係を検討しておかなければなりません。 ・ 侵害調査チーム ・ セキュリティ監視管理サービス ・ DoS（Denial-of-service: サービス妨害）対応サービス ・ マルウェア分析支援 ・ フォレンジック支援 ・ 駆除対応チーム 2.2.2 内部との関係 中規模や大規模企業のネットワーク管理者なら、社内に知らない部署があっても不思議ではあり ません。社内の関係者すべての連絡先を包括的にまとめたリストがあれば、調査、封じ込め、駆 除といった取り組みを大幅に早めることができるでしょう。システムやユーザをネットワークから 切断する権限を持っているのは誰か、またはその他の方法で各部門の業務を縮退させる権限を 持っているのは誰かがわかっていれば、インシデント対応に大いに役立つはずです。調査や駆 除の最中に求められる、誰が何について責任を持ち、誰が決断を下す権限を持っているのかと いう情報を把握していないことほど、攻撃を受けている企業の人々を混乱させ、いらだたせるも のはありません。 上段で特定された担当者には、封じ込めの決断を迅速に下すためにセキュリティチームのリー ダーから連絡が入る可能性があることを伝える必要があるでしょう。また、責任分担表（例 : responsible, accountable, consulted, informed [RACI] matrix）を作成しておくと、役割、責任、 権限の所在を把握しやすくなります。プロセスや手順の文書化、机上シミュレーションの実施に より、調査や駆除対応に関わる関係者のコミュニケーションが促進されるでしょう。社内のすべ ての関係者の連絡先を明確にし、攻撃にすぐに対応できるように準備することで、その場しのぎ ではなく、事業の継続性を念頭において問題に対処できるようになるでしょう。 2.3 権限の明確化 チームは編成された後には、必要な権限が与えられなければなりません。チームの活動には、他 の部門には馴染みのないものもあるかもしれませんが、上層部はセキュリティチームのそのよう な活動をきちんと支援しなければなりません。事業への影響が許容できる範囲にとどまってい るかぎり、セキュリティチームは企業の長期的な利益のために行動することを認められていなけ ればなりません。権限の付与は、一般的にはチームのミッション、目標、目的、権限、責任を明記 し、CIO に承認された明快に記述されたチームの趣意書により実現されます。趣意書の写しは、 CIO が統括しているすべてのスタッフと主要な事業部門の長に配布すべきでしょう。セキュリ ティチームのミッション、目的、目標、責任は、すべての幹部職員の間で理解されていなければな りません。 24 第 2 章 準 備 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: セキュリティ情報 イベント管理）分析の際に注目すべきポイントをセキュリティチームに教えてくれます。分析はそ こから得られた特定の時間前後の限られた時間枠（できれば時間単位）を手始めに、最初の痕跡 と一致するような動きを探します。イベントが検知された時間は、最初の攻撃のものかもしれま せんが、攻撃の後半で攻撃者が犯したミスである可能性の方が高いです。一旦、最初の対象とし たとき間枠に対する調査が終わったら、最初の痕跡やその後に発見された痕跡と一致するイベ ントを探るべく、調査範囲を体系的に広げていくべきでしょう。これらのデータを使えば、何が起 きたのかを容易に見極めることができるものの、クリーニング・復旧活動に着手するのは駆除段 階まで待つのが賢明です。 25 標的型サイバー攻撃への対応 外部 IP アドレスやポート番号が確認された場合は、当該 IP アドレスに対する、または当該ポート を経由した全通信を調べる必要があるでしょう。まずは最初の時間枠のトラフィックを調べ、徐々 に対象を広げていきます。まずは、その IP アドレスと通信していた内部ホストをすべて見つけ、 その前後の時間にこれらのシステムで何が起きていたのかを徹底的に洗い出します。次は、例 えばこれらのシステムがイベント前後の時間帯で（内部または外部の）誰と通信していたかに注 目し、これらのホストも調べます。 内部 IP アドレスやポート番号が確認された場合も、前述したステップに従いますが、順序は逆で す（外部から内部ではなく、内部から外部）。反復的なパターンが認められたトラフィックの場合は （例 : 毎正時にパケットが送信される）、2つのホスト間に C&C チャネルが存在する可能性があ ります。こうしたトラフィックは「定期発信（beaconing）」と呼ばれ、攻撃者にシステムへのアクセ スがまだ存在し、悪用可能であることを知らせるものです。 攻撃者が特定のドメインを使用している場合も、ネットワークから当該ドメインへのトラフィック をすべて見つけ、これらのシステム調査はとても重要です。ドメインの IP アドレスは所有者の意 思で変えることができるため、これらの属性、ドメイン名や IP アドレスに関する古いデータを信 頼することには慎重になるべきでしょう。 最初の IOC が特定のシステム（サーバタイプやドメインコントローラ） と紐づいている場合は、同 じようなシステムをすべて調査すべきでしょう。これらのシステムは同様の設定、パッチ、脆弱性 を持つ可能性が高いため、かなりの確率で侵害される可能性があるからです。高度な攻撃者は 極めて用心深い完璧主義者であり、状況に応じて手法を変える攻撃（Campaign-style attacks） を冗長化させています。 すべての社内のネットワーク資産を網羅したリストなしには調査チームは不利な状況で活動せ ざるを得ません。企業の可視性を高めるための事前投資は、セキュリティコンプライアンスを維 持する上でも、またさらに重要なことにセキュリティ侵犯に迅速に対応する上でも、大きな見返り をもたらします。 2.5 調査プロセスの標準化 ネットワークの状況は企業によって異なりますが、企業が必要に応じて積極的に導入・適応でき る標準的な計画を可能にする共通した性質を持ちます。さまざまなシナリオに対応・適応してい くためには、計画は十分に包括的かつ機動的なものでなければなりません。これは上層部の主 導で計画を立てる必要があることを意味します。まずはセキュリティ侵害の発生に備えて、包括 的な調査・駆除計画を立てましょう。その後、新しい情報や発見に合わせて、計画に微調整を加 えていきます。 26 第 2 章 準 備 しっかりとした計画には、インシデントを特定するまでの標準的なプロセスが記載されています。 このプロセスはいくつかの重要な段階に分かれ、計画には各段階でとるべき行動が簡潔に説明 されています。一般に、このプロセスは以下のように分けられます。 • インシデント発生の判断 報告されたイベントがセキュリティインシデントなのか、それともポ リシー侵害等の悪意のないイベントなのかを判断します。 • インシデントの分析と分類 インシデントにカテゴリーと可能性のあるサブカテゴリーに分類 し、あらかじめ定められている対応活動を参照できるようにします。 • インシデントの格付けと優先順位の設定 対応活動の優先度とセキュリティレベルの決定の ために、インシデントの実際の影響もしくは予測される影響を分析します。 • インシデントの追跡 インシデントに追跡システム上の固有の識別子を付与し、解決、連絡、 復旧、教訓など、すべての段階を通じてインシデントを追跡できるようにします。 計画には、図 8、9に示したような基本的な優先度付けプロセスを含めてもよいでしょう。マルウェ アや脅威の研究結果から、そのイベントが大規模な脅威に発展する見込みはないとチームが判 断した場合は、標準的な改善手順を実行します。それ以外の場合は、インシデントを上層部に報 告し、本格的な調査と除去を実行します。 図 08 基本的なインシデント 優先度付けプロセス リアルタイムのアラート分析 • IDS/IPS/SIEMアラートの 詳細を調べる • ネットワークデータとの 相関関係を調べる • スレットインテリジェンス （攻撃への理解を深め 立てた対策） と比較する 調査チケットを作成し、 セキュリティチームに 送る セキュリティチームは 状況を調べ、 優先度を付ける： 組織に深刻な脅威を もたらす可能性があるか？ ない 標準的な 改善手順に従う ある マネジメントに 警告を出し、 インシデント 対応計画に従う 27 標的型サイバー攻撃への対応 図 09 アラート決定プロセス 初回アラートの分析 • アラートの詳細と相関関係 • 送信先IP：whoisと レピュテーション • パケットキャプチャー情報 • その他 有効 目標 約20分以内で 優先度付けと 分析の大部分を完了する 誤検知 アラートは 事前に定められた 脅威のプロフィールと 合致しているか？ はい マネジメントに 警告を出し、 対応に向けて 本格的に調査する いいえ 標準的な 改善手順に従う いいえ データが持ち出された 証拠があるか？ はい 「誤検知」 と 注釈を付け、 必要に応じて センサーを調整する フォレンジック 分析を実施し、 次のステップを 決定する 調査の実行に関する詳細は、本文書の「調査」、 「駆除」、 「事後対応」の各セクションをご覧くだ さい。 2.6 2.6.1 トレーニングとガバナンス 訓練 少なくとも年に一度は、調査、駆除チームの熟練度をテストする必要があるでしょう。総合演習 では、主な要素（連絡、調整、利用可能なリソース、対応など）をすべて盛り込みます。経営陣は、 計画の立案や実行からこれまで得られた教訓、ポリシーやセキュリティに関する態勢の見直しま で、すべての段階に関与しなければなりません。 演習はさまざまな形態をとります。 • 総合演習 • 机上シミュレーション • セミナー 総合演習では、シナリオに沿って、所与の状況に対処するための行動のほとんどまたはすべてを 実際に行います。セキュリティチームには、シナリオの内容や範囲についての事前情報を持たな 28 第 2 章 準 備 い場合もあります。それが演習だと伝えないまま、演習を実行することさえあります。この「抜き 打ちテスト」が、最もしっかりした、かつ、高度な形態になります。ほとんどの場合は、必要な行 動の大部分を事前に調整する大規模な演習企画グループが存在します。教訓を引き出し、強み を特定するために、評価担当者が指名される場合もあります。計画チームが小さいほど、参加者 へのサプライズの要素もより上手く抑えられ、実際の対応をより正確に模したものとなります。 演習の結果は必ず記録します。この記録には、演習日程（複数日にわたる場合）、演習範囲の予 定と実績（一致しない場合があります）、各活動の説明、参加者、観察記録、教訓、改善が必要と 指摘された分野を記載します。 2.6.2 セキュリティプログラムと対応計画の見直し 組織のニーズの変化に対応するためには、少なくとも年に一度は包括的なセキュリティプログラ ムと、それに続く調査・駆除対応計画の見直し・修正に取り組むことは得策です。プログラムの 達成目標はすべて見直し、達成状況や実行可能性を吟味した上で、必要があれば修正を加えま す。トレーニングの要件が満たされているかも評価し、翌年に必要な技術を検討・計画する必 要があります。セキュリティプログラムを見直す際は、技術の進歩、攻撃の進化、関連する脆弱性、 ユーザ行動の傾向などをすべて勘案する必要があります。 これらの見直しを実施する最適な時期は、年間予算計画や通常の財務管理プロセスがスタート する前です。次年度が始まる前に、翌年のプログラムの資金需要を考慮し、プログラムの目的、 ニーズ、計画投資（例 : 研修、意識向上活動、機器・技術、人件費・事業費）を検討する必要が あります。 2.7 必要不可欠な能力の確立 調査を徹底的かつ効率的に実行し、駆除活動を効果的に進めるためには、事前に必要な能力を 社内に整備しておく必要があります。 どんな調査でも、セキュリティ侵犯の範囲を明確にすることは必須です。これは非常に複雑な攻 撃の場合は特にいくつかの能力を必要とします。準備段階において、能力のギャップ分析を実 施し、セキュリティ侵犯に的確に対処するための能力を社内に確立する計画を策定することは重 要です。 技術を効果的に活用するためには、適切な能力を備えた人材と練られたプロセスが必要です。 徹底的な調査を実施し、環境に入り込んだ相手を駆除するためには、社内に適切な能力が漏れ なく揃っていることがとても重要になります。図 10は、効果的で効率的な調査や駆除に必要な能 力を示したものです。これらは「必須能力」と「推奨能力」に分けられます。必須能力とは、チー ムがセキュリティ侵犯を調査し、セキュリティ侵犯の複雑度に応じて、ある程度の成功を収める ために欠かせない能力のことです。セキュリティ侵犯が複雑であるほど（例 : 侵害されたシステ ムの範囲、マルウェアの洗練度）、推奨能力なしに効率的に運用することは難しくなります。 29 標的型サイバー攻撃への対応 「インシデント対応（IR: Incident Response）の強化」というと、技術やツールに注目が集まりが ちです。企業の技術力は、企業向けの高額な機器やソフトウェアを調達することによって高める こともできますが、まずは既に保有するツールを最大限に活用し、必要に応じてオープンソース のソリューションも取り入れながら、高い費用効果で不足している技術を補うこともできます。新 しいソリューションを購入する前に、まずは関係者が協力して、インシデント対応を効果的に進 めるにはどのような技術力が必要か、また、そのうちの社内にあるものは何か、を考える必要が あります。不足が見つかった場合は、製品を購入する前に、オープンソースの利用可能性を検討 すべきです。ツールの取得コストの削減に組織的に取り組むことで、資金を有能な人材の獲得 やチームのスキルを高めるためのトレーニング・教育に振り向けられるようになります。 インシデント対応を効果的かつ効率的に実施できるか否かは、特定の技術力を持ち合わせてい るかに左右されることは事実です。しかし、多くの場合は、人材やプロセスへの継続的な投資の 方が、企業の技術投資より大きな見返りをもたらすでしょう。 図 10は、CSIRT（Computer Security Incident Response Team）が、サイバーセキュリティ・イ ンシデントを効果的かつ効率的に管理するための人材、プロセス、技術力をまとめたものです。 この後のセクションでは、これらを個別に解説していきます。 図 10が示しているように、調査チームはホストレベルとネットワークレベルの活動の両方で可視 性を確保する必要があります。言い換えれば、企業のホストのネットワークにおいて、 「移動中の データ（data in motion）」、 「保管されているデータ（data at rest）」、 「使用中のデータ（data in use）」を把握することにあたります。分析を実行するために必要な能力の基本的な要件とは別 に、インシデント対応チームの有効性を高めるであろう、より高度な能力があります。もし企業が 基本的な能力で満足し、より頑強な能力の確立の検討を断念するならば、IOC を発見し、それを 体系的に使ってシステム侵害の全貌をつかむことは限定的なものとなり、深刻な被害が発生す る前に予防のために侵害を検知することは困難、かつ、多大な費用を伴うものとなるでしょう。本 章では、すべての企業が持っているべき基本的なもの、共通的なもの、さらには必須とされる能 力と、これらの能力が揃った段階で検討すべき、さらに高度な能力を概説していきます。 30 第 2 章 準 備 図 10 CSIRTに求められる 能力 能力 （人材、プロセス、技術） ホストレベルの活動認識 必須 • エンドポイントのソフトウェアエー • ホストベースの侵入検知 ジェントからのログ • 全社を対象とした遠隔フォレン （例：アンチウイルス） ネットワークレベルの活動認識 検索 推奨 ジック分析 • ネイティブ OS ログ （例：Microsoft Windows®） • エージェントベースのライブメモ • ネットワークフローデータ （例：レイヤー 3） • プロキシーのログ • ファイアウォールのログ • ネットワーク侵入検知のログ • すべての出口におけるフルパケッ システムごとに分散しているログの • 検索可能なログデータの集約 • イベントの相関関係（例：SIEM） 検索 リー分析 トキャプチャー • SSL 調査 • ローカルのログ • 手作業での取得 • 限定的な自動化 デジタルフォレンジック アドホック、ローカル • 遠隔作業（データ取得） • ケース・マネジメント・システム マルウェア分析 • 動的なマルウェア分析 • 基本的で自動化された静的分析 • 詳細な静的コード分析 • リバースエンジニアリング スレットインテリジェンス アドホック、オープンソースリサーチ • 登録型 • ビジネスパートナーとの情報 共有 • 反復可能で自動化された統合 脆弱性の特定 社内利用されているアプリケーショ 全社レベルでの脆弱性の特定 ンの一覧作成 2.7.1 ホストレベルの活動把握 企業ネットワークに接続されているホストはすべて、その企業を狙った攻撃の矢面に立つ可能性 があります。サーバ、デスクトップワークステーション、ノート PC、プリンター、ネットワーク機器 それぞれが、攻撃者によって踏み台とされ、ネットワークへのアクセスを拡大するために悪用さ れる可能性があります。このような活動を検知するためには、各ホスト内で何が起きているのか を理解することが不可欠です。企業の規模によっては、社内のセキュリティ監視部門だけで、全 ホストのすべての活動をリアルタイムで分析できないかもしれません。しかしながら、これらの データは調査が必要な場合には解析し、検索し、理解できるよう、集中管理しておく必要があり ます。 31 標的型サイバー攻撃への対応 デジタルフォレンジック実施者の最も基本的な仕事は、ホストの活動を時系列に再現することで す。これはマシン上のマルウェアの能力をチームが理解する手助けとなり得る他、企業内の他 の侵害されたホストを探すための IOC を形にする助けになるかもしれません。こうした情報は、 攻撃者の意図を理解する上でも有効です。企業は、公開することで企業の名誉の毀損や損害 を与えるための情報を探している政治目的のハッカー（hactivist）を相手にしているのでしょう か ? 非常に重要な特許情報が格納されている研究、開発サーバに APT（Advanced Persistent Threat: 高度で執拗な脅威）を仕掛けようとしているのでしょうか ? それとも動機は単純に金銭 目的で、クレジットカード番号や社会保障番号のような個人情報を集めようとしているのでしょう か ? 企業は、攻撃者が自分たちのネットワークを侵害した理由を考えなければなりません。攻 撃者は何を狙っているのでしょうか ? また、なぜ自社が標的にされたのでしょうか ? ホストレベルの活動を把握するためには、ローカルマシンの活動を記録する必要があります。少 なくとも、以下の活動がローカルと中央レポジトリの両方に記録されるようにホストの設定は見 直すべきです。 • • • • • • • ローカルおよびネットワークへのログオン / ログオフの状況 ウイルス対策ソフトウェアからのアラート プロセス実行 アカウント作成 / 削除、やグループのメンバーシップの変更 サービスの作成 / 開始 / 停止 ウェブブラウザの履歴 ネットワークセキュリティ機器の ALLOW/DENY レコード 必要最低量のログを保存するのに、ログファイルの最大保存容量が十分であるかを確認してお くことは重要です。システムやアプリケーションの初期設定のままでは、場合によっては足りるか もしれませんし、不足する場合もあるかもしれません。Windows イベントログファイルの最大値 （ロールオーバー前で 20 MB）は、利用の仕方によっては、一台のワークステーションの数週間 分の活動を追跡するには十分かもしれません。しかしながら、頻繁に利用されるサーバやドメイ ンコントローラの場合は、一日分の活動すら記録することはできないかもしれません。問題の発 生から数日から数週間が過ぎてもインシデントが発見されない場合、攻撃者の活動に関する貴 重な情報が既に上書きされている可能性があります。 攻撃者の中には、サーバを侵害した後で、ログファイル上の痕跡の消去を試みる者もいます。し かしデジタルフォレンジックの専門家は、さまざまなアーティファクト（artifacts: マルウェアを始 めとするサイバー攻撃で使われるツールや技術による痕跡）を手掛かりに、ホスト上の活動に相 関関係を見つけ出します。システムからアーティファクトを削除しようとする試みは、ベテラン分 析担当者に悪意ある活動の存在を強く疑わせるような、新たなアーティファクトを生み出すこと が少なくありません。 32 第 2 章 準 備 ログファイル以外にも、極めて重要かつ有用なタイムスタンプを含むシステム上のアーティファク トがあります。以下に、その一例を示します。 • ファイルシステムのメタデータレイヤーのタイムスタンプ（MACB（modified、accessed、 changed birth の略）値） • ショートカットやシンボリックリンク等のリンクファイルの生成と関連するタイムスタンプ • レジストリ修正のタイムスタンプ • プリフェッチファイルの作成・修正のタイムスタンプ（プロセス実行のタイミング） • Shellbags エントリー • 削除された $MFT エントリーのリカバリー • 削除されたレジストリーエントリーのリカバリー • AT ジョブや cron ジョブといったスケジュールされたタスク これらのタイムスタンプを順番に分析していけば、攻撃者の行動を鮮明に描き出し、社内ネット ワークのどこかで行われている悪意ある活動を特定するための有用な IOC の一覧を作成するこ とができるでしょう。 オープンソースのツールを使って、すべてのデータ構造を解析し、イベント間の相関関係を見つ け出す方法を知っている熟達した分析担当者は、これらのアーティファクトをホストごとに分析で きます。しかし、この方法はシステムの規模が大きすぎる場合は利用できません。ホストベース の監視システムの多くは、より高度で集約されたレベルで、この種の分析を実行できます。一般 に、最も詳細で意味を持つ IOC は、侵害されたホストで徹底的なフォレンジックを実施した後で 生成されます。続いて、企業内のどこかにあるこれらの IOC を検索するために集中型ソリューショ ンを活用し、侵入の範囲をさらに詳しく調べ、調査の際に着目すべきサーバを特定します。 ホストベースの活動の把握においては、ホスト型侵入検知システム（HIDS）、企業レベルでの フォレンジック分析能力とライブメモリー分析能力の導入が推奨されます。HIDS は、SIEM 機 能を拡張するもので、集中ログ管理だけでなく、ホスト上のアーティファクトを分散検索できます。 ログデータ以外のものも検索できる HIDS は、調査担当者に有用な分散検索機能を与えてくれ ます。以下には、調査担当者が HIDS を使って検索できるものの一例を示します。 • • • • ディスク上の悪意あるファイルの存在（ファイルパスごと、ファイル名ごと、ハッシュごと） サービス 実行中のプロセス ネットワーク接続またはサービスを提供可能な状態にあるエージェント 33 標的型サイバー攻撃への対応 2.7.2 ネットワークレベルの活動認識 ネットワークレベルの活動に注目し、 「移動中のデータ」を可視化することも重要です。ネットワー クレベルでの痕跡が、インシデント検知のきっかけとなることは少なくありません。ほとんどの ネットワークインフラ機器は、ネットワークトラフィックの計測や分析をするための NetFlow デー タを生成し、それを中央サーバに送る能力を持っています。ネットワークを認識するための最も 基本的な方法の一つは、条件検索可能な NetFlow データを生成することです。NetFlow データ が入手できない場合のもう一つの手段は、ファイアウォールやプロキシーのログを監視すること です。多くの企業は、プロキシーデータや少なくとも特定のファイアウォールのルールを記録し ているため、プロキシーやファイアウォールを通じて外部と交信しようとしている攻撃者を調べる 上で大いに役立ちます。ネットワークレベルの活動を把握するために、最低限必要な情報は以 下のとおりです。 • • • • • タイムスタンプ 送信元 IP アドレス 送信先 IP アドレス ポート番号 パケットサイズ 同種の情報はファイアウォールやプロキシーからも集められます。これらの情報は、単体では役 に立たないかもしれませんが、条件検索可能な形で集約すれば、攻撃に関する有用な結論を導 き出せます。また、このような機能は、ネットワークのベースラインを策定する助けにもなり得ま す。企業のポリシーや基準を十二分に理解した上で、一定期間にわたってネットワークレベルの 行動を監視していくと、詳細な分析を必要とする、ベースラインから逸脱した活動を見つけられ ます。ただし、このベースラインは企業によって異なるため、調査担当者は企業ネットワーク上の IP 空間やホストの役割、およびそれらの標準的な通信方法を理解していなければなりません。 企業にもよりますが、以下はベースラインから逸脱している可能性のあるネットワークレベルの 活動の例です。 • 研究部門および開発部門のサブネット上にあるホスト間との頻繁な通信している事業部門の セグメントに新たに設置されたホスト • ウェブトラフィックの通信を初期化中のウェブサーバ • 通常は社内での使用が禁止されている、安全性の低いファイル転送方法（例 : FTP、Trivial FTP [TFTP]） • ネットワーク外から遠隔で管理されている機器（例 : Secure Shell [SSH]、Remote Desktop Protocol [RDP]、Telnet） • データの受信量を送信量が上回っている、ポート番号 80または 443のトラフィック • (特定の国との取引を行っていない場合）地理位置情報データと NetFlow データの重ね合わ せによる、多国間とのトラフィックの検索 多くのネットワーク管理チームは、ベースラインとなる痕跡を何ページ分も挙げられます。分析 担当者は、これらの痕跡を手掛かりにして、最小限のネットワーク監視能力を使って検索し、ア ラートを発信します。 34 第 2 章 準 備 ネットワーク分析では、プロトコルデコーダーなどのネットワーク検知機器に投資することが 推奨されます。例えばファイアウォールやプロキシーのログ、ネットワーク型侵入検知システム （NIDS: Network-based Intrusion Detection System）、NetFlow データ、フルパケットキャプ チャなどを組み合わせましょう。これらは基準値と一致していない、あるいは管理者が設定した 閾値 / 基準値を逸脱している異常なトラフィックを探すように設定できます。より詳細な分析をす るにあたり、他のデータと併せた検索や、他のデータとの相関関係を調べるために、これらの機 器が生成するアラートを中央レポジトリに送信できます。 ネットワーク全体を把握したい場合は、フルパケットキャプチャが有効です。ただし、設計・実装 の方法は吟味しなければなりません。フルパケットキャプチャでは、短時間のうちに大量のデー タが収集されるため、ソリューションの設計に不備があるとストレージが足りなくなる恐れがあり ます。フルパケットキャプチャを使えば、セッションを再現し、ネットワークに送信された疑わしい ファイルを抽出し、分析できます。フルパケットキャプチャは、持ち出された可能性のあるデータ を特定し、マルウェアに感染したインストールファイルの復元を助けることで、マルウェアの分析 担当者がシグネチャベースとふるまいベースの（heuristic）IOC を特定することを可能にします。 2.7.3 検索 重要なログデータはすぐに利用・検索できるようにしておかなければなりません。調査・駆除 段階で検索を効果的に実行できるようにするためには、ログファイルを中央システムログやこれ らのデータを格納しているサーバに送ることが不可欠です。基本的な検索機能は、オープンソー スのツールを使うか、ログデータ検索用の技術を購入し、カスタムスクリプトを書くことによって 実現できます。この機能があれば、ネットワークの可視性は即座に高まり、インシデント対応に必 要なデータを保存できます。 企業はまず、各ログソースを定期的に監視するためのプロセスや手順の作成に注力すべきです。 この種類の監視の良い候補に挙げられるものとしては、ファイアウォール、プロキシー、アンチウ イルスのログなどがあります。例えばアンチウイルスプログラムのログを監視すれば、プログラム が削除・隔離できなかったマルウェアを発見し、対応できます。 さらに成熟した企業は、相関関係を示す、アラートを発信することを実現するログを管理・検索 するための拡張性の高いアーキテクチャを有している傾向があります。こうした機能は、現在流 通している多くの SIEM ソリューションで提供されています。SIEM には 2つの検知機能がありま す。一つは、他の手段で生成されたアラートのためのレポジトリと相関関係のプラットフォームと しての機能、もう一つはネットワークフローと過去ログを基にアラートを発信する機能です。この ソリューションは、最初から社内のすべてのログソースをカバーすることを要求されてはいませ んが、将来の需要増に応えるためには拡張性は不可欠です。現在流通しているログ管理・検索 製品には、この要件を満たしているものがあります。限られた重要なログソースを集約している 企業は、オンデマンド検索において素早く回答を得ることができます。これはより高度な相関関 係の発見、行動に基づいた不正行為の検知の基盤となります。 35 標的型サイバー攻撃への対応 SIEM を導入する場合、ログは段階的に取り込むようにします。取り込むのは、特定の攻撃者の 戦術、方法、手順に合ったログのみとします。誰かの思いつきとか、いつか役に立つかもといっ た理由でログを取り込んではいけません。不要なログソースを取り込めば、システムに余分な負 荷をかけたり、不要なライセンス料金を請求されたりする可能性があります。SIEM を導入した 場合は、システムから不要なデータを削除し、最も適切なアラートのみに集中するようにします。 最適化された企業は、最も適切なアラートを理解し、明確に定義されたプロセスに沿って、極め て短時間でインシデントを検知し、対応できます。 2.7.4 コンピュータ・フォレンジック分析 どんなユーザ活動もホストに無数の足跡を残します。分析担当者はこれらのデータをふるい にかけ、有益なデータを抽出し、それらがユーザ活動を示すアーティファクトなのか、システム 活動によるアーティファクトなのかを見極めます。データの中には、ユーザとの対話処理（user interaction）によるシステム活動の結果、記録されたものもあります。こうしたデータは、ユーザ の活動についてさらに詳しい情報を得るために活用できます。この技術でもあり科学でもある活 動は、一般には「デジタルフォレンジック」と呼ばれています。 フォレンジックは、科学的な手法・技術を使って、刑法・民法上の事実を立証することと考えら れてきました。企業は感染の規模を明らかにするために、法的手段に訴えるのではなく、独自に 調査するかもしれません。その場合、 「フォレンジック」という表現は必ずしも妥当とはいえませ んが、たどるプロセスは同じです。基本的には、企業は自らホストが設置されている場所に訪れ、 手動でメモリの内容をまとめて書き出し（ダンプ）、フルディスクイメージを取得するアプリケー ションを実行することで、徹底したフォレンジックレビューができるようになります。これらの情報 は、ホスト上の割り当てられていないディスクスペースを上書きすることがないように、取り外し 可能なデバイスかネットワーク上にダンプします。 フォレンジック分析に「必須」「推奨」といったレベルの差はありません。しかし、証拠の取得や ケースマネジメントに必要な機器に投資することは可能です。揮発性メモリやフルディスクイメー ジの取得、証拠のハッシュと遠隔保管といった作業を遠隔から実施してくれる業者もあります。 従業員を物理的な場所に派遣するのは時間がかかるため、こうしたサービスは時間の節約にな ります。事業の性質上、システムを長期間稼働させる必要がある場合は、サーバをシャットダウ ンし、ドライブを物理的に回収することは難しいかもしれません。また、いくつかの企業は、ワー クフローを追跡したり、分析された証跡についての検出事項についての文書を標準化したりして くれるケース・マネジメント・システムに投資することで分析担当者の成果を整理することに役 立てられると考えています。 36 第 2 章 準 備 2.7.5 マルウェア分析 マルウェア分析には、基本的に「動的分析」と「静的分析」の 2 種類があります。どちらも分析担 当者やリバースエンジニアに、マルウェアの目的、方法、影響、およびマルウェアの機能や出所に 関する IOC を理解するための情報を与えてくれます。しかしながら、 「動的分析」と「静的分析」 はそれらの結論を導き出すまでに異なった方法を利用します。例えば動的分析の自動化フォー ムは、調査・駆除を効果的に進めるための必須能力ですが、推奨されているのは両方の分析手 法の利点を活かし、調査段階でできるかぎりの情報を発見することです。 動的なマルウェア分析では、制御・抑制された環境（通常は仮想環境）で潜在的マルウェアを 実行し、その行動を観察します。この環境には、実行ファイルの行動を監視するセンサーが仕込 まれています。ここでいう実行ファイルとは、ディスクに書き込まれたファイル、ネットワークトラ フィック、修正されたレジストリキー、生成プロセスなどです。動的分析を自動化すると、静的分 析よりもはるかに速く分析を完了でき、一般的に技術的リソースもあまり必要としません。しかし 動的分析では、マルウェアを最小単位まで分解することはできないため、分析の精度には限界が あります。 動的分析は、静的マルウェア分析と組み合わせて行うとよいでしょう。静的分析には、リバースエ ンジニアリングや、コードの一部を取り出して、その中身や機能を分析することなどが含まれま す。静的分析で用いられるツールは、逆アセンブラ、デバッガー、逆コンパイラなどです。最終目 標はマルウェアのソースコード、つまりコードの最も基本的な部分にアクセスすることです。セキュ リティ専門家のデニス・ディストラーが書いているように、 「コード分析の実行中は、ウイルス対 策ソフトウェアがマルウェアの上で動作し、文字列検索が実行され、シェルスクリプトなどのファ イルが分析される」ことになります 10。高度な標的型攻撃では、攻撃者の意図と正体はさらに明 確になります。たいていのマルウェアは何らかの指揮統制機能を備えており、感染したシステム の制御権の獲得や、攻撃者に対して情報の送信ができるため、攻撃者を推定する手掛かりにな ります。しかし、マルウェアは進化を続けています。マルウェアの中には、不正使用を発見するた めのツールを検知時には、自分を無害な存在であるように見せかけたり、目的を隠したりする機 能を備えたものもあります。 2.7.6 サイバー情報収集活動 自社のネットワークセキュリティを強化するためには、準備活動の一環として、社外の脅威にも目 を向ける必要があります。脅威をプロファイリングすることで、最も強い動機を持ち、最も高い確 率で攻撃を成功させられる攻撃者を特定できます。論理的な防衛判断を迅速に下すためには、 社内と社外の両方にバランスよく目を向けていく必要があります 11。 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 37 標的型サイバー攻撃への対応 サイバー攻撃の脅威についての情報収集活動とは、言い換えれば悪意ある攻撃者を研究し、そ の能力、動機、予想される行動を見極めることです。こうした情報収集活動を実行し、その成果 を適用していくことで、セキュリティチームは攻撃者の戦術、方法、手順をより明確に理解できま す。攻撃活動を遮断したり、抑制したりすることで、攻撃者を打ち負かすことさえできるもしれま せん。しかも、情報収集活動は、セキュリティチームが攻撃を知らされてから（たいていは被害の 発生からだいぶ経ってから）対策に乗り出すのではなく、攻撃者が攻撃の準備を整えている段階 や最初の攻撃が起きた段階で、攻撃を検知さえできる可能性があります（図 11）。 図 11 サイバー情報収集が 攻撃のライフサイクルに 与える潜在的影響 標的となった企業が、 強力なスレットインテリジェンスに より攻撃を検知するタイミング 情報の収集 背景の調査 最初の悪用 最初の攻撃 足場の確保 ほとんどの標的企業が 攻撃を知るタイミング （通常はサードパーティから） 攻撃検知にかかる期間の短縮 指揮・統制 潜伏 社内 ネットワークの 偵察 データの 持ち出し 特権獲得 アクセス 範囲の 拡大 特権獲得 侵入した 目的情報の システムからの 収集と 潜伏の継続 データの 暗号化 持ち出し 脅威情報は、 システム侵害が既に起きたことを示す重要な IOC にもなり得ます。こうした情報は、 攻撃者がネットワーク内に足場を固めるまで入ってこないかもしれませんが、ネットワーク SIEM とログを検索し、侵害の証拠を見つけるために利用できます。 注目すべき脅威情報を見極めるためには、企業はいくつかの質問に答える必要があります。 「私 たちを攻撃したいと考えているのは誰か ?」「私たちのシステムの弱点はどこか ?」「社内にはど んな機器があり、各機器にはどんな弱点があるのか ?」―こうした問いは、大量の情報から定期 的に検証するために、適切な情報量を取捨選択する助けになります。 脅威情報はさまざまな方法で入手できます。理想的とはいえませんが、最も一般的なのは場当た り的な情報収集です。例えばセキュリティチームのメンバーが知人から無作為に情報を受け取る とか、技術系のウェブサイトを見て回っているときに有益な情報を見かけるとか、社内ネットワー クで利用されている設定やツールに関するニュース記事を見るといった形態の情報収集です。 38 第 2 章 準 備 場当たり的な情報収集より一段進んだ情報収集方法としては、脅威の研究を反復的なタスク、兼 任の仕事、あるいは専任の調査業務とすることがあります。この方法が上手くいくかは、スタッフ のスキル、脅威の内容や検索場所についての知識、あるいは運に左右されます。 ほとんどの企業にとって有効な方法の一つは、脅威データの定期的な収集です。Web サイトの フィードに登録する利点はいくつもあります。さまざまな専門会社、アンチウイルスベンダー、そ の他のセキュリティプロバイダーが、 カスタマイズ可能な法人向けサービスを提供しています。こ うした企業は世界中のエンドポイントやソースのフィードを集め、傾向や異常を分析し、価値あ るデータを登録者に提供しています。 サービス提供会社はデータ分析が完了すると、その結果をさまざまな報告書にまとめて、登録者 に提供します。例えば脆弱性報告書には、特定のソフトウェアやハードウェアで発見されたセキュ リティホールが記載されます。速報ニュースの目的は、現在進行中のイベントに関する情報をセ キュリティチームに知らせ、注意を喚起することです。悪質なコードに関する報告書はマルウェア の性質、攻撃方法、影響を細かく分析したもの、同様に脅威報告書は APT レベルまでの具体的 な攻撃者の情報を伝えるものです。これらのサードパーティベンダーは、多様な企業の情報にア クセスできるため、単独で調査を進めている企業よりも広範に分析を実行できます 12。これらの 報告書は、セキュリティチームの要望に合わせて、業界別にカスタマイズすることも可能です。 多くの業界では、脅威情報をリアルタイム分析の担当者からシニアリーダーまで、さまざまなレ ベルで共有しています。最高情報セキュリティ責任者（CISO）は、会議やトップ会談などで定期 的に集まり、最新動向を情報収集しています。分析担当者は、適切な場合には他の分析担当者 に問い合わせることができます。公式・非公式を問わず、情報共有のためのパートナーシップは いくつもあります。その一つが ISAC（Information Sharing and Analysis Center: セクター別 の情報共有・分析センター）です。商業的なパートナーシップの例としては、 「レッド・スカイ・ アライアンス」があります 13。このアライアンスのメンバーは、対 APT 研究に共同で取り組んだり、 データを交換したり、詳細な ICO 表に登録したりしています。この表は、APT の標的となってい る業界の報告書をまとめ、読者向けに一覧化したものです。 業界パートナーシップも脅威情報の情報源となります。企業は将来の競合他社と脅威情報を共 有し、共通の敵に対して共同戦線を張ることで利益を得ています 14。技術セクターでは、複数の 大手技術企業が「CSRA（Cyber Security Research Alliance）」15を共同で立ち上げ、単にデー タや報告書を共有するだけでなく、画期的な技術を開発することで、 「大いなる課題」に取り組も うとしています。この非営利アライアンスでは、メンバー企業が力を合わせて、長期的で先進的 なネットワーク・セキュリティ・ソリューションを開発しようとしています 16。 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-idUSBRE89O03120121025 16 Ibid., 39 標的型サイバー攻撃への対応 カスタム 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/ 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 18 40 第 2 章 準 備 脅威情報を最近のログの評価と組み合わせれば、高度なトラフィック分析が可能になります。 NIST（National Institute of Standards and Technology: 米国標準技術局）が SP 800-61で推 奨している分析活動は、利用動向だけでなく、高度な対象となる攻撃者を発見するためにも利用 できます 20。対象の攻撃は検知を避けるために、通常のトラフィックに紛れ込もうとする場合もあ ります。その場合は、熟達したログ分析担当者にしか、その存在を発見できないかもしれません。 対象の攻撃者は、ネットワーク上の痕跡をなるべく小さくするために、検出の閾値を超えないよう に行動することもあります。熟達したログ分析担当者は、こうした「時間をかけて少しずつ行う」と した動きに注目することで、特異な活動を見つけ、それを正当な、あるいは正当でないトラフィッ クと関連づけます。 高度なトラフィック分析は、ネットワーク傾向から逸脱した動きを発見する助けにもなります。こ のような動きを察知したときは、 さらに詳細に分析するようにします。検討すべき傾向には次のよ うなものがあります。 • セキュリティインシデントが最も頻繁に起きている場所はどこか ?（部門、場所、機器の種類） • 最も頻繁に発生しているインシデントの種類は何か ?（マルウェア、キーロギング、フィッシング によるインシデント、ソーシャルメディア関連攻撃の具体的な種類） • インシデントは速やかに解決できるか ?（ログの取得、ネットワークの可視性、利用規定・調査 ポリシー、ユーザの協力度） • 最近、発信された IDS/IPS/SIEM アラートにはどのようなものがあるか ? アラート発信のきっ かけになったものは何か ? 情報 / 侵害のソースは何か ? 2.7.7 脆弱性の特定 セキュリティチームは、全社規模の詳細な脆弱性スキャンを定期的に実施する必要があります。 頻度は企業の規模によりますが、スキャンはネットワークセグメントごとに段階的に実施する必 要があるかもしれません。中小企業なら四半期ごとのスキャンで十分かもしれませんが、大企業 の場合は月に一度は実施する必要があるでしょう。 どんなスケジュールを選ぶにせよ、脆弱性スキャンの目的は既知の脆弱性に対して無防備な状 態にある社内の機器を発見することです。重要なのは、スキャンを実施し、その結果を分析し、 何者かによって脆弱性が発見され、悪用される前に、発見された問題を解決することです。 企業向けスキャナーには、無料のものと登録制のものがあります。最終的な目標はどれも同じで すが、スキャン対象のデータ、OS、ハードウェアの種類には違いがあります。スキャナーによって 特徴があるため、スキャナーを選ぶ際は、評価対象の機器にスキャナーが及ぼす影響や評価の 精度を比較します。 20 NIST, “Computer Security Incident Handling Guide,” SP 800-61, 2012, http://csrc.nist.gov/publications/drafts/800-61-rev2/draft-sp800-61rev2.pdf 41 標的型サイバー攻撃への対応 スキャンが完了したら、脆弱性は体系的に対処されるべきです。たいていの場合、問題に対処す るためのパッチや更新ファイルは各ベンダーから提供されています。事業や政治上の理由から、 特定のシステムへのパッチ適用が遅れる場合もあるでしょう。これは上層部への定期的な状況 報告が効果を発揮するケースであり、セキュリティ強化の必要性を関係者に説得するためにも活 用できます。 更新ファイルが適用できない場合は、システムの監視を強化する方法を見つけなければなりませ ん。脆弱性が見つかった場合は、当該システムを対象に、さらに詳細なトラフィック分析を実行し ます（高度な攻撃者であれば、既にシステムへの侵入を成功させているはずです）。脆弱性スキャ ンは主に予防のためのツールとして使われていますが、会社全体の検知機能の一部と捉えること もできます。情報セキュリティの格言にあるように、 「予防は理想、検知は必須」なのです。 42 第 3 章 調査 第 3 章 調 査 3.1 セキュリティ侵犯の調査 どの調査においても、核となるのは問題に関連した事実を収集し、分析することです。サイバー 侵犯に関する事実は、目撃者の証言、インフラのログ、コンピューターシステム、サードパーティ など、複数の情報源から集めることができます。APT（Advanced Persistent Threat: 高度で執 拗な脅威）によるサイバー攻撃の場合は、駆除・改善計画に寄与する情報を提供することが、調 査の主目的となります。駆除計画は通常、攻撃者を当該環境から排除することを目的としていま すが、これを成功させるためには以下の 2 点が必要です。 • 攻撃者の戦術、手法、手順、意図に関する詳しい情報 • 侵害されたシステム、盗み出された認証情報、狙われたデータ、アクセスを維持するために攻 撃者が使った（または使っている）C&C（command-and-control: 指令・制御）システムにつ いての知識 駆除計画の詳細は第 4 章をご覧ください。 事実の収集・分析は、簡単には進まないものです（例 : まずは聞き取りを実施し、次にログをレ ビューおよび・分析する）。事実の収集は、動的、流動的、かつ、循環的なプロセスであり、正し い判断力と経験が求められます。新しい情報が見つかった、当初の仮定が正しかった（あるいは 間違っていた）ことがわかった、といった状況に応じて、最初からやり直さなければならないこと もあります。したがって、調査は聞き取りから着手し、次にログレビューを実施し、さらに入手した 新しい情報を元に補足的な聞き取りを行うといった流れで進むこともあります。 インシデント対応（または調査）のプロセスは、 「特定」 「封じ込め」 「駆除」 「復旧」 「フォローアッ プ」の 5つのフェーズに分けられます（図 12）。 これらのフェーズは連続したものではありますが、各フェーズは完全に独立しているわけではあり ません。調査の内容によっては、重複、あるいは繰り返し実行されることもあります。しかし、 「特 定されなかったインシデントは封じ込めることはできず、そのインシデントは駆除できない」とい う事実に変わりはありません。 以下は、インシデント対応プロセスの主な目標です。 • • • • 特定 関連するデータソースをすべて特定する。 保全 これらのデータをフォレンジック的に適切な方法で保全する。 分析 データを分析し、問題と関連している事実を見つける。 報告 発見事項を報告する。 43 標的型サイバー攻撃への対応 図 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-handlingprocesssmall-medium-businesses_1791でも閲覧可） SANS のモデルは「PICERL（準備（Preparation）、識別（Identification）、封じ込め（Containment）、 駆除（Eradication）、復旧（Recovery）、教訓（Lessons learned））」と呼ばれています。NIST の モデルは、複数のステップを 4つのフェーズ（準備、検知と分析、封じ込め・駆除・復旧、事後対 応）にまとめています（図 13）。 44 第 3 章 調査 図 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 利害関係者に詳細を報告する。 45 標的型サイバー攻撃への対応 コモディティ化したマルウェア（エクスプロイトキット等を用いて作成される特殊性が見出しにく いマルウェア）によって、外部で生じたセキュリティインシデントやセキュリティ侵犯は、たいてい は社内に既に導入されているセキュリティメカニズムによって検知できます。しかし、高度で執 拗でかつ洗練された攻撃者により攻撃を受けている企業が、国内の捜査当局や情報収集組織に よって攻撃を知らされているケースが良く見られます。企業が独力で攻撃を検知できた例はほと んどありません。 攻撃の事実を知った経営陣は、調査の実施により解明されることとなるさまざま質問を抱くこと になります。中でも重要なのは、 「誰が攻撃しているのか ?」「攻撃はいつ起きたのか ?」「何が 奪われたのか ?」「攻撃の目的は何か ?」といった質問です。一般に、経営陣は攻撃の手法や場 所にはあまり関心を示しませんが、侵害の範囲や深度、および広がりを理解するために、調査 チームがこうした質問にもきちんと答えられるように対処することを期待します。 調査チームは攻撃者の戦術、手法、手順―端的に言えば、 「攻撃はどのようにして起きたのか ?」 ―の理解に努める一方、同じタイミングで駆除チームは駆除イベントの計画に着手します。 調査・駆除チームが自らの役割、責任、期待を理解できるように、適切なガイダンスが提供され る必要があります。計画には必ず、必要な意思決定を迅速に下せる権限をチームに与えることの リスク分析を盛り込む必要があります。 調査開始前に、追跡プロセスを細かく設計しておくと良いでしょう。もし既に追跡機能を持つケー スマネジメントやチケットソフトウェアを導入しているのであれば、そのソフトウェアを計画の中 で使用することは可能です。しかしサイバー侵犯調査では、こうしたシステムから一般的に得ら れる情報よりも詳細な情報が求められることがあります。標準的なヘルプデスク・チケット追跡 システムは、ワークフローの段階を決定するのには適していますが、サイバー侵犯における調査 追跡プロセスにおいては、協力を促進し、極めて技術的な情報を保管し、直接的には関係のな い複数の活動を同時に管理することが求められます。 アラートを受け取ったら、その情報がどこ（IDS アラート、ユーザ報告、ログ分析、システム管理 者報告など）から来たかを問わず、一貫した方法で追跡されるべきです。そうすることで、原因、 属性、応答時間の長期間にわたる傾向分析を可能にします。こうした傾向により、セキュリティ チームは、ネットワークの保護と迅速なインシデント解決の両方に必要な適切なリソースを配備 する必要性について経営陣に提言できるようになります。 インターネット上には、しかるべき情報源が調査の方法を詳細に説明した資料がいくつもありま す。どのアプローチを採用するかは、企業が現状利用可能か、あるいはすぐに入手・実装でき る技術ツールにより決まります。例えば、全社横断的なフォレンジック機能は必要になります。こ の機能がなければ、調査は難航することになります。 46 第 3 章 調査 どのような照会の仕方を採用するにせよ、以降の質問への回答に重点を置くことは、会社を正し い方向に導くことにつながります。 3.2 誰が攻撃しているのか ? これは一般に「属性（attribution）」と呼ばれるもので、この質問への回答は調査の他の面でも役 立ちます。ある攻撃者は特定の業界を標的とするか、もしくは特定の種類の情報を入手しようと します。もし攻撃者 X が主に財務データを狙っているのであれば、その情報により財務システム を調査することになります。この節に関連する経営陣や取締役会が尋ねる可能性の高い質問と して、以下のようなものが挙げられます。 • • • • • • • • • 攻撃者は特定の政治目的のハッカー（hactivist）や組織と関わりを持っているか ? 攻撃者は外国政府から資金提供を受けているか ? 攻撃者は競合他社から資金提供を受けているか ? 攻撃グループは複数か ? その場合協力しあっている複数のグループか ? 複数の攻撃者が連携して活動しているのか ? 攻撃者は米国の捜査当局や情報機関から監視されているか ? 攻撃者は攻撃経路として第三者（例 : 請負業者、クライアント、合弁会社）を使っているか ? 攻撃者に協力している内部関係者入るか ? 攻撃者は会社の施設やネットワークに物理的にアクセスできるか ? 会社の海外オフィスにアク セスできるか ? 調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。 • 攻撃は誰から通知されたか（例 : 捜査当局、社外のサードパーティ、社内の人物 / プロセス）? いつ通知されたか ? どのように通知されたか ? • 攻撃の詳細を知っているのは誰か（例 : 従業員、請負業者、ベンダー、クライアント、捜査当局、 その他）? 調査・改善活動の責任者は誰か（例 : プロジェクト管理オフィス［PMO］）? • 社外からサポートを受けているか ? 我々の調査・改善活動の実施を認識しているのは誰か （例 : 従業員、請負業者、ベンダー、クライアント、その他）? 3.3 何が標的とされたか ? まず初めに、攻撃者が接触したシステムのリストが、この質問への回答となります。少なくとも、 これらのシステムは改善活動に含める必要があります。攻撃者が接触したシステムについての 情報は、他の質問に回答する上でも役立ちます。この節に関連する経営陣や取締役会が尋ねる 可能性の高い質問として、以下のようなものが挙げられます。 • • • • 攻撃者は何を狙っているのか ? 彼らの目的は何か ? 攻撃者の目的は既に達成されたか ? どのデータが持ち出されたか ? 会社の最重要データは危険にさらされたか ? どのコンピュータがマルウェアに感染したか ? 47 標的型サイバー攻撃への対応 • 攻撃者がアクセスした（が侵害はされなかった）コンピュータはどれか ? 攻撃者が侵害した のはどのアカウントか ? • 攻撃者がアクセスないし侵害したネットワーク機器は何か（例 : ルーター、ファイアウォール、 スイッチ、プリンター）? • 攻撃者が C&C のために使用しているネットワーク /ドメイン /IP アドレスは何か ? • C&C ネットワークを隠ぺいするために、攻撃者は第三者のシステムを使っているか ? 調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。 • 外部の脅威に関する情報源との攻撃者に関する情報の連携の関係性はどのような状況か ? • 攻撃について、既にマスコミに発表されている内容は何か ? • 攻撃に関する情報がマスコミや一般市民に漏れた場合、外部向けの声明をどのように準備し ているか ? 3.4 さまざまな事象はいつ起きたのか ? 調査の重要なポイントの一つが時系列情報です。時系列情報は事象を大局から捉える助けにな るでしょう。調査を実行すると、事象全体の時系列情報はもちろん、接触を受けたシステムごと の詳細な時系列情報も明らかになります。この節に関連する経営陣や取締役会が尋ねる可能性 の高い質問として、以下のようなものが挙げられます。 • • • • • 最初の攻撃活動はいつ起きたか ? 攻撃者はいつから潜伏しているか ? 最後の攻撃活動が起きたのはいつか ? 攻撃に明らかなパターンはあるか（時間帯、曜日、週末、祝日など）? 攻撃のタイミングは、会社が重要な情報を発表したタイミングと一致しているか ? 調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。 • 取締役会やその他の利害関係者に初めて詳細を説明するのはいつがいいか ? • 取締役会 / 利害関係者には、どのようなスケジュールで補足説明するか ? • 攻撃者のアクセスを遮断するための改善計画をいつ実行するか ? 3.5 攻撃はどこから来ているのか ? 攻撃の出元を見つけるための質問としては、以下のようなものが挙げられます。 「水 飲 み 場 / たまり場 • 最 初の攻 撃 経 路は、インターネット上の正 当なホストが 侵 害され、 （watering hole: 標的がよく使うWeb サイトにウイルス感染の罠を仕掛ける）」に仕立てられ たものだったのか ? • 取引先企業をかたったフィッシングメールか ? • 侵害されている疑いのある社外のホストか ? 48 第 3 章 調査 この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙 げられます。 • • • • • 最初の攻撃はどこから始まったのか ? 最初の攻撃では、攻撃者はどこを狙ったのか ? バックドアアクセスはどこにしかれているか ? 攻撃者は他にどこを探索しているか（地理的位置、事業部、オフィス、役割）? リポジトリ（データの格納場所）はどこに設置されているか ? 調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。 • 環境全体を眺めたとき、攻撃に対して最も脆弱な部分はどこか ? • その脆弱性は、合弁事業のパートナー、クライアント、顧客、その他のサードパーティ取引関係 者のリスクを高めているか ? • 最も重要なデータは何か ? それらのデータはどのくらい強固に守られているか ? • 重要情報の一覧が最後に更新されたのはいつか ? 重要情報の例 : – 幹部のコミュニケーションや意思決定 – 人事 / 法務に関するデータ – 特許 / 登録商標 / 企業秘密に関するデータ – 合併 / 買収 / 会社分割に関する計画と進捗状況 – 研究 / エンジニアリング / 製造に関するデータ – PCI（Payment Card Industry: クレジットカード業界）制御データ – 個人情報 – その他の重要データ 3.6 なぜ攻撃されたのか ? 攻撃の理由を明らかにするための質問としては、以下のようなものが挙げられます。 • • • • 攻撃者が狙っていたのは知的財産か、それとも財務情報か ? 企業の意思決定に影響を及ぼそうとしていたのか ? 将来の攻撃に利用できる認証情報を集めようとしていたのか ? 別の人物に対する攻撃を実現するためのものだったのか ? この節に関連する経営陣や取締役会が尋ねる可能性の高い質問として、以下のようなものが挙 げられます。 • • • • • • • マルウェアに感染したコンピュータ内のデータは、攻撃の動機を示唆しているか ? 攻撃者がアクセスしたコンピュータ内のデータは、攻撃の動機を示唆しているか ? 攻撃者が侵害したアカウントは、攻撃の動機を示唆しているか ? 攻撃のタイミングは、攻撃の動機を示唆しているか ? 持ち出されたデータは、攻撃の動機を示唆しているか ? 攻撃者のネットワーク偵察は、攻撃の動機を示唆しているか ? 攻撃の動機を示唆するような攻撃者がネットワーク内で侵入拡大する動きの傾向があるか ? 49 標的型サイバー攻撃への対応 調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。 • なぜ最初の攻撃を検知できなかったのか ? • なぜ攻撃の事象が拡大していく過程で検知できなかったのか ? 3.7 攻撃者はどのように侵入し、潜伏し、データを持ち出したのか ? これは調査の中で、最も技術的な難度の高い部分であり、幅広いスキル（数例を挙げると、ネッ トワーク分析、フォレンジック分析、リバースエンジニアリングなど）と豊富な経験を兼ね備えた 調査担当者が求められます。この節に関連する経営陣や取締役会が尋ねる可能性の高い質問と して、以下のようなものが挙げられます。 • 攻撃者が攻撃経路として使用したのは、E メールか、クラウドか、ソーシャルか、それともモバ イルか ? • 攻撃の標的となったのは従業員が所有する機器か、それとも企業が所有・管理する資産か ? • 会社のウェブサイト上で、攻撃を容易にするようなデータを公開していたか ? • 攻撃者はどうやって我々の環境への継続的なアクセスを手に入れたのか ? • 攻撃者はどのように偵察を実行しているか ? • 攻撃者はどのようにローカルからドメイン管理者へ権限を昇格させたのか ? • 攻撃者は我々の環境内でどのようにして移動しているか ? • 最初の攻撃後、攻撃者はどのように足場を拡大したか ? • 攻撃者はどうやって目的のデータを探し、見つけているか ? • 攻撃者はどうやってデータを持ち出しているか ? 調査中は、以下の質問への回答について、こまめに経営陣に報告することが重要です。 • どうすれば、これらの攻撃やその他の攻撃から自社をより上手く防御することができるか ? • 今回の事象のどのような事実が従業員向けの意識向上プログラムを強化するために利用でき るか ? • 従業員や幹部職員は、新たな攻撃を招くような情報をソーシャルメディアサイトで公開してい ないか ? 3.8 その他検討が必要な重要分野 これまで触れてきた 6つの基本的質問の他にも、調査において検討すべき追加の質問の一覧が あります（付録 A）。これらの質問への回答は、経営陣へ伝えられる必要があります。調査チーム は必ずしも最適の回答者ではないかもしれませんが、経営陣や取締役会は遅かれ早かれ、これ らの質問の一部あるいはすべてを尋ねてきます。したがって、これらの質問に答えられるように 準備をしておくことが必要です。 良いとされる調査・駆除計画には、IOC（Indicator Of Compromise: 脅威が存在することを示 す痕跡）の特定に関わる人、プロセス、技術がまとめられています。セキュリティ侵犯を特定する ための情報源はいくつもありますが、ほとんどの場合、侵犯はまず外部の情報源によって発見さ れ、何らかの方法で被害を受けた組織に伝えられます。伝えられる情報はあいまいなことが多い ため、具体的にどのシステムが侵害されたのかを明らかにするには、さらなる調査が必要になり 50 第 3 章 調査 ます。例えば、もし侵害の事実が連邦政府機関から通知された場合、被害を受けた組織に伝えら れるのは「既知の悪意ある IP アドレスやドメイン名から大量の情報が送られた形跡がある」とい う情報だけです。よって、被害を受けた組織は、送信先の国も、IP アドレスも、ドメインもわから ないということがよくあります。 その他の IOC に関する情報源となるかもしれないものには以下のものがあります。 • • • • • • • 外部の情報源（政府、ビジネスパートナー、脅威情報に関する情報配信） セキュリティ監視・対応プロセス ネットワークやエンドポイントの自動分析機能 脆弱性スキャンのフォローアップ分析 侵入テスト ユーザからの報告 脅威情報に関する情報配信 3.9 情報収集の質 攻撃が起きた際に、経営陣が調査チームに尋ねるのは前述した質問の一部かもしれないし、全 てかもしれません。これらの質問に答えられるように準備をしておくことは、時には大変な作業と なり得ます。調査チームは、経営陣と進んで率直に対話することが求められます。サイバー侵犯 の調査は「責任のなすりあい」になるべきではありませんが、経営陣は当然ながら「誰が何を知っ ていたのか」「いつ知ったのか」「得られた情報に対して、どんな対応をとったか（あるいはとら なかったか）」と尋ねてきます。これらの質問を避けてとおることはできません。 調査チームは経営陣の質問に回答し、収集した情報を提供できなければなりません。企業のリー ダーは、時には正確な情報がないまま決断を下さなければなりません。そのため、自らの意思決 定の拠り所となる情報の質を理解している必要があるのです。 前述した質問への回答は、調査だけでなく、セキュリティ関連のさまざまなプログラムに活用され ます。すべての情報を記録し、集めた情報を調査関係者やその他の人々に提供し、状況を細部 まで理解するためには、適切な文書化と関係者との連携が不可欠です。 このように調査チームが対応すべきことはたくさんありますが、今日の攻撃者の能力や執拗さを 考えると、企業の防御手段に少しでもすきがあれば、そこを突かれることになってしまいます。 3.10 証拠の取り扱い 証拠を適切に取り扱うことは、企業や経営の観点から見て優れた実践であるだけでなく、刑事・ 民事訴訟において、証拠が却下される可能性を最小化することにつながります。 51 標的型サイバー攻撃への対応 そのためには、調査期間中に収集され、保全され、分析された証拠資料が変更されていないこと を証明できることが重要です。提出された証拠が完全なものか、それとも変更されたのかと追及 することや、被告の無罪を証明するような証拠が不適切かつ意図的に排除されているのではな いかと追及することは、法廷で被告側弁護士がよく使うテクニックの一つです。 以降で、証拠の正当性を疑われるリスクを最小化するために、調査担当者が活用できるテクニッ クや優れた実践について簡単に触れます。もちろん、こうしたアドバイスは顧問弁護士の指示に とって代わるものではありません。 3.10.1 文書の保全と収集 調査の着手時より、文書やメモの保全と収集を同時に行っていくことは必要不可欠です。複雑な 調査の過程で、数十から数百のハードドライブが保全され、何百ものログファイルがコピーされ、 何千ものシステムアーティファクト（artifacts: マルウェアを始めとするサイバー攻撃で使われる ツールや技術による痕跡）が特定され、抽出されることがあるかもしれません。文書を保全・収 集する際には、以下の点に留意すべきです。 • • • • • • 各証拠の出所（ホスト、人物） 証拠の保全・収集日 その証拠を収集した調査担当者の氏名 保全・収集の環境と手法 収集した証拠の追跡（番号やインデックスを使用） 証拠の収集・処理過程で明らかになった例外（例 : セクター読み込みエラー、ログファイルの 部分的欠落） 3.10.2 証拠保管の連続性 証拠、特に証拠原本は、調査担当者だけがアクセスできる、鍵のかかる保管室や引き出しの中に 入れ、適切に保管することが重要です。調査担当者以外の人物が分析のために証拠を必要とす る際、または、証跡の保護が移送する必要がある際の（例 : 社内の調査担当者から捜査当局へ）、 証拠の「貸し出し」手順を定めるべきです。証拠を移送する際は、以下の情報とともに追跡でき るようにします。 • • • • • 移送先担当者の氏名 移送元担当者の氏名 移送日時 移送方法（手渡し、または配送サービスを利用） 追跡番号（該当する場合） 52 第 3 章 調査 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 のようなツールもレコード数を出力するため、調査担当者は送信先でのコピーファイルの数が、 パーミッションやコピーエラーなどが原因で、元ファイルのカウント数よりも減っていないかを確 認できます。 53 標的型サイバー攻撃への対応 3.10.6 弁護士・依頼者間の秘匿特権または弁護士のワークプロダクトの秘匿特権 調査を、弁護士・依頼者間の秘匿特権のもとで、顧問弁護士または契約している法律事務所の 弁護士とともに実行するか、あるいは弁護士のワークプロダクトとして保護するかは早めに決定 されるべきです。この件については、調査の早い段階で法的助言を求めることが強く推奨され ます。 3.10.7 保険金の請求 多くの保険会社は、企業向けにハッキングやセキュリティ侵犯によって生じた損害を補償する保 険を提供しています。契約内容によって実際の補償額、控除免責額、条件は異なりますが、多く の保険はセキュリティ侵犯によって生じた金銭的損失だけでなく、侵犯を調査し、損害額を明ら かにするために外部の調査担当者やセキュリティコンサルタントの支援を受けるためのコストも 補償しています。 会社がこうした保険契約を結んでいる場合、調査担当者は以下に留意する必要があります。 • 調査に要した時間とその内容（調査タスクごとの所要時間とタスクの簡単な説明）を詳細に記 録します。保険金の請求時は、たいていの保険会社がこうした情報の提供を求めます。 • 企業が被った損害を数値化します。財務やクレジットカード関連の侵犯の場合は、かなり具体 的に損害額を計算できるでしょう。損害額にはクレジットカード発行会社から請求される罰金 も含めます。知的財産の窃盗を目的とした侵犯の場合は、数カ月、あるいは数年経たなけれ ば問題が明らかにならないことがあるため、損害額の算出は難しくなる傾向があります。 3.11 調査の匿名性 攻撃者の C&C サーバは、対象としている環境を支配するために、アクセス範囲を広げるための ファイルを保持したり、マルウェアへ更新を加えたり、自分たちのマルウェアを強化したりするこ とがあります。対象とされた会社は、侵害された稼働中システムのライブメモリーから、攻撃者 のマルウェアの一部を復旧することはできるかもしれませんが、ファイルをフォレンジック的に繋 ぎ合わせて再現することはできないかもしれませんし困難です。C&C サーバから攻撃ファイル の完全コピーを取り出したい、またはその他の方法で、C&C サーバの一部を特定したいという 誘惑にかられるかもしれませんが、攻撃者の C&C サーバに直接接触するようなネットワーク活 動（例 : マルウェアを制御するためのインターフェースへのアクセス、C&C サーバ等に対するス キャン、ping による死活状態の検査、curl を用いたデータ転送、wget を用いたコンテンツ取得） に従事する場合は必ず、外部のマシン（感染しておらず、標的企業と何の関係もないもの）を使 用することが重要です。これを怠れば、攻撃者に、会社がその攻撃者の存在を検知したというこ とを知らせてしまうことに繋がるかもしれません。 54 第 3 章 調査 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 機能をインストールし、検知されないように一定 期間、これらの機能を「スリープ」状態に置くことは珍しくありません。攻撃者は賢く、創造性に富 んでいます。甘く見るべきではありません。 55 標的型サイバー攻撃への対応 3.13.1 認証情報の保護 調査チームは調査の過程で、社内のさまざまなマシンにログオンします。イメージを収集すると きも、ログファイルを取得するときも、エージェントを配備するときも、認証情報は慎重に扱うよう にしなければなりません。 調査環境で使用・作成する認証情報は必ず、通常業務に使用されている認証情報とは別のもの にします。侵害されていないと 100 ％断言できないかぎり、既存のアーキテクチャはなるべく信 頼しないようにします。侵害されたシステムを分離しておくことが、安全対策上は決定的に重要 です。 徹底的な監視と調査なしに、攻撃者がネットワーク内を移動する速度を見極めることは困難で す。企業は情報収集やインシデント対応を急ぐあまり、ドメインアカウントの認証情報を保護す ることを忘れがちです。これらのアカウントがあれば、環境内を自由に動きまわり、さまざまなホ ストに管理者としてアクセスできます。インシデント対応チームの経験の浅いメンバーや不注意 なメンバーが、このような強力なアカウントを手にすれば、認証情報を攻撃者に奪われることに なりかねません。管理者アカウントさえあれば、攻撃者は、ハッシュ値はおろか、最終的には調査 担当者のキャッシュされた認証情報にもアクセスできるようになります。多くの企業が、製品に初 期設定されている管理者アカウントに同じパスワードを設定しています。このような単純な問題 が、インシデント対応の調査全体を台無しにする可能性があるのです。 調査の全期間を通じて、こうした重要な質問への回答はこまめに経営陣に伝える必要がありま す。そしてさらに重要なことは、それら調査によって得られた洞察や情報を、環境から攻撃者を 排除するために設計された駆除計画へときちんと組み込むことです。 56 第 4 章 駆 除 第 4 章 駆 除 高度なサイバーセキュリティ侵犯の調査がマラソンだとすれば、侵犯の駆除は短距離走です。 つまり駆除活動においては、効率的なアプローチが成否を分けます。攻撃の全体像を把握し、 攻撃者がアクセス・侵害したシステムを漏れなく特定し、盗み出された認証情報をリスト化し、 社内ネットワークに埋め込まれた悪意あるソフトウェアを見つけ、奪われたすべての重要情報を 分類し、駆除活動を効果的に実行する準備を整える―こうした調査活動に何カ月もかかること は珍しくありません。しかし一度調査が終われば、駆除活動は完璧かつ迅速に実行する必要が あります。 効果的な駆除計画にはスピードと正確さが求められます。たいていの攻撃者は、自分の存在が 発見され、駆除の準備が進んでいることに気づいたとたん、体勢を立て直し、ネットワークへの 再侵入を試みます。例えば、ある攻撃者は駆除活動の実行中に特権アカウントにアクセスできな くなったことに気づきました。この攻撃者は、一年近く前に DMZ（Demilitarized Zone: 非武装 地帯）サーバにインストールし、調査チームに発見されないままになっていた web shell にアクセ スし、それを使って再侵入を果たしました。IP アドレスが駆除チームによってブロックされたこと に気づくと、ドメイン名の IP アドレスを変更する攻撃者もたくさんいます。 侵害を検知した企業は、問題の全貌を捉える前に、感染経路や潜伏ポイントをブロックし、早急 に駆除活動に取り掛かろうとするものです。しかし、十分な対応計画を練らないまま対応すると、 攻撃者はそのたびに戦術を変えるため、絶えず敵を追い回している状態に陥りかねません。 これはコストの面でも労力の面でも、企業に大きな負担をかけることになります。駆除は関係者 が連携して、自社の環境から侵入者を計画的に排除するものでなければなりません。サイバーセ キュリティ侵犯を完全に回避することはできないとすれば、時間と労力を費やして慎重に準備を 整えることは、大きな投資効果を得るためのデューデリジェンス―すなわち当然払うべき注意な のです。 4.1 駆除計画の立案 駆除活動を組織的かつ計画的に実行するためには、あらかじめ作業のスケジュールやタイミング 等の詳細を十分に検討しておく必要があります。 4.1.1 駆除活動チームの設立 駆除活動の準備は、さまざまな作業の担当チームを決めるところから始まります。こうした準備 は調査段階から始まるため、駆除活動は調査の完了後すぐに始めることができます。熱心なチー ムリーダーが駆除計画の調整役となり、駆除活動の実行状況を確認します。チームのメンバー は社内のさまざまなグループから任命すべきです。すべてのメンバーが駆除計画の一つまたは 二つの部分で重要な役割を果たし、場合によっては計画実行における特定分野の責任者となり ます。 57 標的型サイバー攻撃への対応 駆除日までの期間は、全員が専任でイベントの準備に取り組むことになります。駆除日には、チー ムのメンバーは駆除活動の効果の測定に集中し、駆除活動によって引き起こされた活動に対応 します。緊急事態に対処するための計画を練り、攻撃者の反応に備えることも重要です。チーム と主要な利害関係者には、この時点で包括的で入念に組み立てられたエンゲージメント計画を 配布すべきです。計画の最初のステップから最後の教訓学習セッションまで、すべての段階を机 上シミュレーションで実施するのもよいアイディアです。これは重要な質問に回答し、計画のあい まいな部分を明確にする助けになります。 駆除活動では、攻撃者のアクセスの切断から始まり、駆除計画を迅速に実行するため、チーム メンバーの業務スケジュールを調整し、24 時間のサポート体制を築くことが必要になる場合が 多々あります。そのためにどんな方法をとるかは、駆除活動の範囲やチームの規模・スキルセッ トに大きく左右されます。 4.1.2 駆除活動計画の立案 駆除活動計画の立案にあたっては以下の点に留意します。 • 調査計画と同期のとれた包括的な駆除計画を立案する 調査・駆除チームを収集したら、役 割と責任、および駆除を成功させるために達成すべき目的とタスクをチーム内で共有します。 リーダーは調査・駆除計画を作成し、関係者の賛同を得て、計画を他の主要な利害関係者に 周知します。計画には必ず、調査チームと駆除チーム（およびその他の事業部）との関係を明 記します。計画を成功させるためには、調査チームと駆除チームが各段階で協力しながら、効 果的、効率的、かつ包括的に調査・駆除活動を実行できるようにする必要があります。 • 駆除活動の前後で完了しておくべきタスクを明確にする 計画には、調査が必要なさまざまな こと、実行すべきプロセス、必要な技術的修正、最適化、開発、ないし購入する必要のある機 能をすべて盛り込みます。侵害の性質に合わせて、計画のさまざまな側面に優先順位を付け ましょう。例えば、ある企業は駆除前にドメインコントローラにアプリケーションのホワイトリス トを実装することを優先するかもしれません。別の企業は、暗号化メカニズムが既に攻撃者に 悪用されていることを踏まえ、駆除の前に環境から LAN マネージャのパスワードハッシュを削 除したいと考えるかもしれません。いずれにしても、企業は駆除活動の前に完了すべきことと、 駆除活動が終わるまで待てることを見極める必要があります。対応する脅威に合わせてリスク を分析し、悪用の可能性や自社のセキュリティ体制を検討します。 • 駆除活動を維持・拡大する 計画は駆除で終わるわけではありません。攻撃者は駆除活動 が進行していることを察知すると、ただちにアクセス権を取り戻そうとします。駆除後数週間は 警戒を解かずに、駆除活動後、少なくとも一週間は厳戒態勢を維持すべきです。その後でメン バーの任務を解除することを検討します。 58 第 4 章 駆 除 4.1.3 駆除日の決定 駆除活動を実施する日時は重要です。日時を選ぶときは、メンバーのスケジュールやネットワー クの休止時間を優先したくなるかもしれません。これらも重要な要素ではありますが、攻撃者 の行動パターンを検討することも重要です。例えば攻撃者の行動を分析した結果、特定のスケ ジュールで活動していることが明らかになるかもしれません。週末は活動せず、通常の業務時間 の間しか活動しない攻撃者もいれば、週末に活発に行動する攻撃者もいます。後者の場合は、 月曜の朝に駆除活動を始めると、攻撃者がアクセスを失ったことに気づく前に、計画を完了でき る確率を最大化できます。しかし攻撃者が活動しているとわかっている時間帯に駆除活動を実 行すれば、攻撃者はアクセス権を取り戻すため活発に活動するかもしれません。 新米の攻撃者は、存在を検知され、厳しい警告を受けたら、それだけで攻撃をあきらめてしまう かもしれませんが、高い技術と根気を備えたベテランの攻撃者は、ネットワークでのアクセスを 維持するために積極的に戦うことが少なくありません。検知され、ブロックされた場合、高度な攻 撃者は何カ月、あるいは何年もかけて侵入し、潜伏してきたネットワークへのアクセスを取り戻す ために、ただちに積極的な行動を起こす可能性があります。もし攻撃者がネットワークにアクセ スする日時が予測できるなら、この情報を駆除チームの有利になるように活用します。攻撃者に ついての知識は、駆除日を決める際にも重要な役割を果たします。 4.1.4 攻撃者の戦術、方法、手順の理解 攻撃者を理解することは、防御体制を強化するためだけでなく、調査・駆除を効率的かつ包括 的に進める上でも重要です。標的型脅威では、社内ネットワーク上に多くのアクセスポイントや 侵入経路が作成・維持されていることが珍しくありません。攻撃者はアクセスを維持するために、 さまざまな手段を講じます（ユーザや特権アカウントを悪用する、ホストに侵入してバックドアを しかける、Web Shell を活用するなど）。こうしたアクセス経路は何カ月、時には何年もかけて育 まれたものですが、攻撃者の主要なアクセス手段が切断されるまでは利用されることはないかも しれません。協調的で包括的な調査・駆除計画を立てる必要があるのはそのためです。このよ うな計画がなければ、攻撃者がこれらの代替的なアクセス手段を使って、ネットワークへのアク セスを再び確立するリスクは大幅に上昇するでしょう。 59 標的型サイバー攻撃への対応 4.1.5 コミュニケーションプロトコルの確立 駆除活動の最中は、チーム内のコミュニケーションを明確化し、進捗状況や未解決の問題にタイ ムリーに注意を払うことが重要です。 24 時間体制でシフトを組んでいる場合は、チームとすべ ての利害関係者にスケジュールや連絡先情報を提供します。上層部に進捗を定期的に報告すれ ば、情報提供を求められる頻度を減らすことができます。こうした定期報告を円滑に行うために は、チームの活動を漏れなく記録し、すべてのシフトのメンバーがそれまでの活動を理解できる ようにする必要があります。教訓や駆除活動全般に関する報告書の作成プロセスも簡略化すべ きです。 調査・駆除活動を成功させるためには、トップダウンとボトムアップの両方のコミュニケーション が必要です。駆除日までに必要な許可・承認を確実に得られるように、重要な利害関係者と経 営層にはかなりの時間に余裕を持って、計画に関する情報を提供します。同様に、利害関係者と 経営層は計画の詳細を理解し、必要な変化が組織全体に与える影響を把握しておかなければな りません。これらの変化の中には、組織の重要なプロセスや技術に関わるものもあるかもしれま せん。あらゆるレベルの人々を巻き込むことで、調査・駆除の過程で組織の目的や業務に影響 を及ぼす可能性のある重要なプロセスや技術を発見できます。 調査・駆除チームが単独で行動している場合、調査・駆除段階で起こりうる問題に備えることは 極めて難しくなります。一方、調査・駆除チームが IT 部門の関係者と連携すれば、調査・駆除 活動の効果と効率を高めることができます。迅速な判断や行動が求められる調査の場合はなお さらです。計画には、ヘルプデスク、ワークステーション、ネットワーク、セキュリティチームの交 流を促すような仕組みを盛り込みます。マルウェアを削除するために、感染したシステムをワー クステーションチームに渡す時期と手順も事前に定義しておきます。調査の実行中は、ワークス テーションチームに逐次状況を報告し、作業が必要になる時期を予想できるようにします。 大規模な調査・駆除活動を計画する際は、セキュリティチームが IT チームと日常的にどう連携 するかを定義しておく必要があります。セキュリティチームが IT チームとリーダーに状況を説明 する進捗会議を毎日開くと、調査を速やかに完了し、システムを正常化する助けになります。計 画の中で明らかにすべき問題には次のようなものがあります。 • IT 関 連 の 問 い 合 わ せ は す べ て ヘ ルプ デ スクが 受 ける の か、そ れとも SOC（Security Operation Center）が直接ユーザに対応するのか ? • セキュリティチームとネットワークチームで行動方針に差がある場合、次の行動を決める権限 を持っているのは誰か ? 60 第 4 章 駆 除 これらは事前に考えておくべき重要な質問です。企業の中には調査を応援するために、ヘルプデ スク、ワークステーションチーム、またはネットワークチームのメンバーを（兼任で）セキュリティ チームに派遣しようと考えることもあるかもしれません。しかし、その場限りのチームではスピー ドが重視されるセキュリティ調査には対応できず、むしろスピードダウンを招く可能性がありま す。可能な場合は常に、明確な役割とプロセスを持ったチームを作りましょう。 コミュニケーション計画を立てる際は、調査に関する情報を誰に伝えるかを考えます―これは真 剣に検討すべき問題です。調査がある程度進んだら、社内の一部のメンバーには何が起きてい るのかを伝える必要が出てくるかもしれません。しかし、たいていの企業は、選定したグループ だけに重要情報を限定したいと考えるものです。計画には、情報を知る権利を持つ人と持たな い人を明確に定めましょう。 社外とのコミュニケーションは、より繊細な問題を含んでいます。もし攻撃の事実が外部に漏れ たら、マスコミに直接対応することは不可避であり、必須でもあるため、事前に計画を立てておく 必要があります。マスコミへの情報提供は、積極的にというより、受動的に行われるのが普通で すが、マスコミが状況を知った場合にどう対応するかを検討し、必要な計画を立てておくことは 不可欠です。まずは社内の担当者にマスコミに話すべきポイントを事前に伝えておきましょう。 主要なビジネスパートナーに接触することが有益、あるいは必須である場合もあります。ネット ワークを常時接続している企業間では、ネットワークの状況を率直かつ正直に話し合うことが事 前に合意されている必要があります。これは一般的ではありませんが、そうあるべきです。この ようなつながりがある場合、二つのネットワークは実質的には一つのものであり、ネットワークを 健全な状態に保つため相互に依存することになります。もし一方の企業のネットワークが業務契 約やサプライチェーン契約に影響が出るような形で侵害されたときは、できるだけ早くビジネス パートナーにアラートを発信します。これは将来の混乱を避ける助けになります。また、ビジネス パートナーの中には、もし自社のネットワーク上にあれば、脅威についてさらに多くの情報を集め られるような検知機能を持つところもあるかもしれません。しかし、 もし企業間のコミュニケーショ ンを可能にするプロセスがなければ、こうした情報を共有することはできません。 他に連絡が必要になる可能性のあるサードパーティには、政府と捜査当局があります（先に先方 から問い合わせがくる可能性もあります）。継続中の侵害の種類に応じて、どのような報告が義 務付けられているかを十分に理解する必要があります。 61 標的型サイバー攻撃への対応 4.1.6 「対策本部（War Room）」の設置 高度なインシデントに対応する場合は、 「対策本部」を設置するのも良策です。通常、個々のイン シデント対応計画は短期間しか継続しないため、対策本部も常設のものではなく、一週間程度し か使用されることはありません。対策本部は、チームの会議や連携の拠点であり、すべての関係 者（インシデント対応の担当者、IT 部門の担当者、利害関係者、その他のリーダー）が集う場所 となります。 チームリーダーが対策本部の司令官となり、駆除計画に沿ってメンバーに指示を出します。リー ダーはインシデント対応に関する議論、調整、行動を促進し、メンバーの行動のタイミングを調 整し、すべての活動が調和のとれたものとなるように尽力します。 チームの規模やプロジェクトの範囲によっては、複数の対策本部が必要になる場合もあります。 例えば全体の活動の調整はリーダーシップ本部が担当し、具体的な活動は小規模なセキュリ ティ監視、ネットワーク、ワークステーションチームが別の対策本部で実行するといった具合で す。各シフトの担当者が、それまでに行われた活動の内容を理解できるように、またプロジェクト の完了後に教訓を導きだせるように、各チームの活動は漏れなく記録します。 対策本部の解散後にフォロー活動が必要になった場合は、セキュリティチームのリーダーの判断 で、必要に応じて再招集をかけることができます。 4.1.7 安全なコミュニケーションと情報共有のメカニズムの確立 駆除チームの構成や駆除活動の性質を考えると、安全なコミュニケーションを確立することは極 めて重要です。駆除チームのメンバーには、駆除活動の前後にも最中にも、必要な情報を提供 しなければなりません。今日では社内コミュニケーションの多くがデジタルネットワーク上で行わ れていますが、これはコミュニケーションの内容が攻撃者に監視される可能性があることを意味 します。このため、セキュリティ運用ガイドラインを策定し、厳守することが重要です。 セキュリティ運用ガイドラインには、インシデント関連の情報はその情報を知るべき人だけに開 示することを明記します。企業にもよりますが、 このグループには通常、駆除チーム、調査チーム、 IT 部門の一部、経営陣の一部が含まれます。これらの情報は、侵犯に関する情報が攻撃者の手 に渡ったり、誤って公開されたりすることがないように、極秘に扱う必要があります。開示するこ とが法で定められている侵犯もありますが、開示の判断は必ず経営幹部や法律顧問、およびそ の他のしかるべき関係者に相談した上で下します。 チームは、攻撃者がネットワークを監視できるという仮定に基づいて、業務を遂行しなければな りません。標的型攻撃の実行者は、この能力を使って自分たちの存在が発見されているかを探 ることがあります。調査の手が及んでいることに気づいた攻撃者は、戦術を変えるか、長期にわ たってネットワークに接続しない可能性があります。数週間、あるいは数カ月後に、既に埋め込 んである多くのアクセス経路のいずれか使って、標的に再侵入すればいいと考えています。攻撃 者に発見されないように、調査・駆除プロジェクトにはコードネームを付けます。また、インバウ ンド通信（例 : E メール、ファイル共有）には強力な暗号化技術を使います。チームの連絡には 62 第 4 章 駆 除 別の暗号・パスワードを使用し、メンバーには繰り返し、プロジェクトの機密性と、コミュニケー ションには慎重に取り組む必要があることを伝えます。セキュリティ運用ガイドラインには、アウ トバンド通信（例 : 対面の会議、電話、ショート・メッセージ・サービス［SMS］）を優先すべき 旨を随所で明記します。 駆除を迅速かつ完璧に実行するためには、駆除前に必要な許可・承認が得られるように、十分 な時間的余裕を持って、主要な利害関係者と意思決定者に計画に関する情報を伝えなければな りません。経営陣は計画の詳細に関わり、必要な変化の影響を理解しておく必要があります。こ れらの変化の中には、組織の重要なプロセスや技術に影響を及ぼすものもあるかもしれません。 経営陣の関与は、組織の目的や業務に影響を及ぼす可能性のある重要なプロセスや技術を特 定する助けになります。こうした会話や意思決定は簡単ではないかもしれませんが、計画への合 意は駆除の前に形成しておく必要があります。 高度な調査・駆除を実行するためには、よく練られたコミュニケーション計画が不可欠です。い つ、誰と、どのような方法で安全なコミュニケーションをとるかを定めておきます。侵入の第一報 は電話で来るのが一般的です。最初のステップは、社内の連絡先を見つけることです。通知者 は情報を直接提供するのではなく、対面の会議を設定します。侵入に関するデータそのものは、 通知の段階ではかなり古くなっているものですが、影響を受けた組織を特定し、最初の連絡をと るために時間がかかることもあります。 4.2 計画の実行 計画の実行中は以下の点に留意します。 • チームメンバーが作業に集中できるようにする 駆除中は、メンバーが作業に集中できるよう に独立した環境を与えます。チームに「助っ人」として参加したがる人もいるかもしれません が、準備に参加していなかった人が途中から参加しても、 ミスをして作戦を狂わせるだけです。 こうした人々には、駆除チームを見守っていてほしいと丁寧に頼みます。 • 情報に適切なラベルを付ける 懸念が生じたときは、ただちに検討できるようにします。伝え られた情報には必ずラベルを付けましょう。明確で適切な情報ラベルは、意思決定者が正し い決断を下す助けになります。誰かの勘が事実として伝えられ、後になって事実でないとわ かった場合、その人と駆除活動にマイナスの結果が生じる可能性があります。 • 駆除計画を忠実に実行する 駆除活動の間、チームメンバーは解決を焦るあまり、あらゆるこ とを一度にやろうとするかもしれません。このような衝動には抵抗しなければなりません。計 画を信頼します。もし準備・調査にしかるべき時間とエネルギーを投じたなら、駆除は関係者 との協同プロジェクトになっているはずです。計画の変更を完全に避けることはできませんが、 それを最小限にするために全力を尽くします。大幅な逸脱が予測される場合は、あらかじめ駆 除チームのリードで調整し、チーム内でコミュニケーションをとりながら実行します。 63 標的型サイバー攻撃への対応 • 緊密な調整を行う 調整は必須です。例えば攻撃者がアクティブ・ディレクトリ・サーバに侵 入し、複数のドメイン管理者アカウントの認証情報を手に入れた場合、関係者は連携して侵害 されたパスワードを変更しなければなりません。一部のパスワードしか変更しなければ、攻撃 者は別のアカウントを使って攻撃を続ける可能性があります。アクセスさえ維持されていれば、 攻撃者は新しいパスワードのハッシュをキャプチャするか、必要な特権を持つ別のアカウント を作成できる可能性があります。 もし可能なら、駆除の実行中は他のネットワークから隔離します。しかし通常（特に攻撃者が既 にネットワークに深く侵入し、大きな足跡を残している場合は）これは不可能です。もし駆除中に ネットワークを切断できれば、駆除の成功率は高まります。 4.2.1 パスワード変更 高度な侵犯に対応する場合は、全社規模でパスワードを変更するのが一般的です。たいていの 攻撃者は通常のネットワークトラフィックに紛れながら、盗んだパスワードを使って企業の資産に アクセスします。他のツールやマルウェアが検知され、削除されたとしても、パスワードがあれば 管理者レベルのアクセスを取り戻すことができます。このため、パスワード管理と全社規模のリ セットは、検知された攻撃者をネットワークから駆逐するための重要なステップとなります。 しかし、全社規模のパスワード変更は事業上の理由から、実行できない場合があります。そ の場合も、調査チームが侵害された（あるいはその疑いがある）と特定したアカウントについ ては、駆除活動の開始に合わせて無効にするか、パスワードを変更します。SIEM（Security Information and Event management: セキュリティ情報イベント管理）やその他の監視・検索 ツールにルールを適用し、これらのアカウントからのログオンが失敗したケースを見つけます。 このルールは駆除後にネットワークに再侵入する試みを特定できる可能性があるため、優先度 の高いアラートとして扱います。 ネットワークへの再侵入を防ぐには、駆除日の前に侵害されたドメインのセキュリティの基準レ ベルを定め、順守することが重要です。セキュリティの基準レベルを満たしている活動には、次 のようなものがあります。 • 完全なアカウントリストの作成 ドメインで利用されているアカウントの一覧を作成します。 すべてのアカウントを、現在アクセスを必要としている個人と結びつけます。このリストに は、パスワードの最終変更日とパスワードの保存に使われているアルゴリズムも記載します。 アカウントリストができたら、削除する必要のあるアカウントと、パスワード変更が必要なアカ ウントを駆除計画に組み込みます。これは、駆除計画と同時に実行すべき作業の一つです。 駆除日の前に突然パスワードを変更すると、攻撃者は検知されたことに気づき、調査が困難に なる可能性があります。ネットワークの点検と修正は、徐々にではなくできるかぎり一気に行 いましょう。 64 第 4 章 駆 除 • ドメイン管理者アカウントの見直しと合理化、および（可能な場合は）削減 ドメイン管理者ア カウントは “ 城門を開く鍵 ” であり、それに見合った保護が必要です。この権限を持つユーザ の数は厳しく制限し、ユーザの活動はできるかぎり詳細に記録します。 • パスワードポリシーの改訂 必要に応じて、パスワードポリシーを見直し、改訂します。LAN マネージャのハッシュの悪用を防ぐために、ウィンドウズのパスワードは 15 文字以上とします。 パスワード・ハッシュ・データベースを評価し、推測しやすいパスワードや短すぎるパスワー ドを見つけるツールはたくさんあります。 • パスワードの強化 適当なパスワード強度を持つパスワードを再設定したら（図 14）、それら のパスワードを適切に管理するためのプロセスを導入します。標準ユーザのパスワードは四 半期ごとに、管理者のパスワードはもっと頻繁にリセットします。アカウントのロックアウトを実 行するのもよいアイディアです。例えばユーザがパスワード入力に最大 5 回失敗したときは、 ヘルプデスクがパスワードをリセットするまでアカウントをロックします。これはパスワードを 見つけるための総当たり攻撃を防ぐ効果があります。 予算に余裕があるときは、2 要素以上の認証を導入する企業が増えています。2 要素認証とは、 ユーザが知っていること（例 : パスワードや個人識別番号［PIN］）、ユーザが持っているもの（例 : 何らかのトークン、スマートカード）、あるいはユーザ自身のもの（例 : 指紋、網膜スキャン）のう ちの 2つを使用したパスワード認証です。多要素認証はパスワードの弱点の多くを解決してくれ ますが、導入・維持コストが高くなる傾向があります。 65 標的型サイバー攻撃への対応 図 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ピクセルの画像ファイルを、すべてのテキストページのリク エストに対して警告メッセージページを「応答する」ように設定されたローカルの社内ウェブ サーバ • パーソナルファイアウォールを使用しているマシン 66 第 4 章 駆 除 IP アドレスはブロックされていても、マルウェアはまだ 完 全 修 飾ドメイン 名（FQDN: fully qualified domain name）と通信するように設定されている場合、攻撃者は IP アドレスを変更し て、別の IP アドレスを指すようにネームサーバを更新することで、マルウェアを更新せずにブロッ クを回避できます。 上記の 3つの設定のうち、最後の 2つ―「応答する」ように設定されているローカルの社内ウェ ブサーバまたはパーソナルファイアウォールを使用しているマシン―には、調査用のログファイ ルを生成する、あるいはトラフィックを監視するために Snort® やその他の IDS システムを利用で きるという利点もあります。DNS ブラックホールを効果的に活用するためには、DNS リゾルバに よってルートされていないトラフィックはブロックする必要があります。もし DNS が会社の所有・ 管理するネームサーバを経由していない場合は、マルウェアは外部のパブリック DNS リゾルバ を使ってデータを誘導したり、持ち出したりするようにプログラムできます。 ホワイトリストに入っているネットワーク以外の外部ネットワークと通信することで社内にサービ スを提供しているサーバをブロックするのはよいアイディアです。例えば、パッチやセキュリティ 定義を手に入れるために特定のソフトウェアベンダーと通信する必要がある場合、そのベンダー をホワイトリストに加え、通信を許可します。 4.2.3 侵害されたシステムの再構築 ついに脅威の駆除に取り組むときがやってきました。脅威情報の収集は侵犯のソースを特定す る助けになります。こうした情報は駆除のタイミングを決める上でも有効です。例えば、もし脅威 の出元が中国なら、旧正月の期間は活動量が減る可能性があるため、この時期は駆除を実行し、 予防措置を導入する最高のタイミングと言えるかもしれません。逆に、もし攻撃者が活動してい るとわかっているときに駆除を実行すれば、攻撃者はアクセスを取り戻すために積極的な行動に 出るかもしれません。攻撃者に全力で戦う機会を与える理由はありませんから、攻撃者が警戒を ゆるめたときに行動を起こすのは理にかなっています。 もし可能なら、侵害されたホストはすべてドメインから切り離し、再構築します。侵害の証拠は深 刻に受け止めるべきです。高度な攻撃者はアンチウイルスやシステムスキャニングでは検知で きないルートキットをシステムにインストールしている可能性があります。もし可能なら、これら のシステムは再イメージングし、攻撃者がシステム内にもはや足場を持っていないことを確認し ます。リソースに余裕があるなら、駆除活動の前に侵害されたホストを再構築し、駆除日にはそ のホストが「完全に交換（swapped out）」されるようにするべきです。そうすれば、駆除活動をよ り迅速に、かつ組織的に行うことができます。 67 標的型サイバー攻撃への対応 侵害されたシステムのユーザにその事実を伝えるかは、慎重に検討する必要があります。クリー ニングのために侵害されたシステムを移送するときは、ユーザやシステム・クリーニング・プロ セスの関係者が駆除活動に干渉するリスクを減らす方法を考えましょう。 4.2.4 アンチウイルスベンダーへのマルウェアの提供 調査チームは、攻撃に使用されたツールや、ネットワーク上に展開・保存されているマルウェア を見つけ、アーカイブする必要があります。次は、少なくとも動的に、これらのマルウェアのアー ティファクト（ artifacts: マルウェアを始めとするサイバー攻撃で使われるツールや技術による痕 跡）を分析し、攻撃者の意図を明らかにします。駆除チームは、アンチウイルスベンダーやホスト ベースの侵入検知ベンダーと連携して、このコードのシグネチャを作成します。駆除日には定義 ファイルを全社に配布し、このコードのコピーや変種がネットワーク上に残っていないかを確認 し、検知された場合は隔離します。 4.3 再侵入活動の監視 ネットワークを厳重に監視する準備を整えます。駆除日が近づいたら、一歩離れて状況を眺め、 どんな緊急事態が起こりうるかを予測します。計画された活動が期待したほどの効果を上げな かったり、マイナスの二次効果を生んだりする可能性は十分にあります。駆除チームは以下の点 を考えておかなければなりません。 • 駆除活動の二次効果と将来の予防活動にはどのようなものがあるか ? 一つの方法は、こうした 隠れた因果関係を意識しながら計画を立てることです。もう一つの方法は、チームに新しいメン バーを入れ、新しい視点から駆除計画を見直すことです。 • 計画に含まれている仮定のうち、間違っている可能性があるのはどれか ? その仮定が間違って いた場合、どんな結果が引き起こされるか ? 計画の全体像を眺めるようにすると、これらの仮定 の多くを解決できます。残りの仮定については、不測の事態が起きた場合の対応計画を準備して おき、駆除計画を円滑に進めましょう。敵は新しい戦術を用意しているかもしれません。脅威情 報の収集は、こうした戦術を特定し、予測する助けになります。 • 調査チームは、攻撃者の活動の全貌をつかむだけの IOC（Indicator OF Compromise: 脅威 が存在することを示す痕跡）を見つけたか ? 攻撃者が別のアクセス方法を使って社内に侵入す るのを防ぐために、迅速に組織的な努力がなされたか ? 脅威を駆除する上で最も困難なタスク は、駆除活動の成否を判断することです。 ネットワークは安全であると明言できない可能性は人々 を不安にさせるかもしれません。 監視チームが「すべての IOC とアーティファクトは駆除された」と十分に納得できる段階まで来 たら、SOC は経営幹部に駆除活動が成功裏に完了したことを報告し、もしあれば例外や評価活 動によって判明したことを伝えます。 68 第 4 章 駆 除 高度な脅威を検知したときは、攻撃者の行動を監視・観察して相手の戦術を理解し、潜伏の仕 組みを明らかにする必要があります。あらゆる方法を使って、感染経路、アクセスポイント、潜伏 の仕組み、悪用された脆弱性、ネットワークに再侵入するための方法を見つけましょう。一つの 間違いや見落としのために、攻撃者はいつのまにかネットワークに再侵入するかもしれません。 このような悲劇的なミスを回避するためには、企業は以下に焦点を合わせる必要があります。 • 駆除活動を支える、質の高い調査報告書を作成する。 • 調査・駆除を完璧に実行するための計画を立てる。 • プロセスの全段階を通じて、健全なプロジェクト管理原則に従う。 駆除計画は、調査報告書に記載された問題のすべてに対処するようになっていなければなりま せん。また、計画には活動の開始日と目標期日を具体的に記載します。 駆除計画に着手する前に、駆除チームは調査報告書に記載されている活動をすべて監視できる かを確認する必要があります。攻撃者が再侵入を試みる場合に備えて、駆除日の後も数週間は 監視を続けましょう。具体的なユースケースを書き、テストし、微調整を加え、駆除チームの指定 されたメンバーにアラートを発信する SIEM ソリューションに統合すれば、駆除の効果を記録、 追跡、監視できます。 69 標的型サイバー攻撃への対応 白紙ページ 70 第 5 章 駆除後の対応 第 5 章 駆除後の対応 駆除のプロセスは時間との競争であり、大変な労力を要するものとなりがちです。事業に与える 影響を最小限に抑えるために、作業は通常業務の終了後か、週末の保守時間内で行わなければ ならないことも少なくありません。SOC（Security Operation Center）のメンバーは、IT 部門の さまざまな専門家と協力しながら、一刻を争う状況で困難なタスクを遂行します。駆除のための 作業が一通り終わった後も、SOC は引き続き細心の注意を払いながら仕事を続けます。次の攻 撃は、駆除後の数週間以内に起きる可能性が極めて高いからです。攻撃者は体勢を立て直して 攻撃を再開するでしょう。初期戦術が阻止された場合は、迅速に戦略を変えてきます。それは攻 撃が成功するか、再侵入に要する労力が、盗み出す情報の価値や侵入に要する時間の価値を上 回ると攻撃者が判断するまで続きます。初期感染の規模や狙われている情報の重要性によって は、このような攻撃パターンは動揺を引き起こします。SOC の分析担当者は、駆除段階で導入さ れたコントロールの有効性を確認すると同時に、再攻撃の兆候を監視し、迅速に対応する必要 があります。 5.1 5.1.1 駆除活動の検証 警戒態勢の維持 適切に計画したならば、駆除活動は短時間で終わるはずですが、攻撃者が攻撃を進化させて いく場合に備えて、企業は監視体制を整え、数週間から数カ月間はネットワークの監視を続け る必要があります。この段階で最も重要になるのは、ネットワークの状況を把握することです。 NetFlow データを生成し、動向に変化がないか、基準から外れた活動がないかなどを分析し ます。攻撃者の戦術、方法、手順のユースケースは SIEM（Security Information and Event Management: セキュリティ情報イベント管理）に集約し、駆除の完了後もしばらくは慎重に監視 を続けます。特に注意する必要があるのは、前回の攻撃と類似した行動に対するアラートです。 前述したように、攻撃者は利用できるあらゆる手段を使ってネットワークへの再侵入を試みます。 しかも、自分たちは捜索されており、これまでの戦術、方法、手順は既に暴かれていることを知っ ています。このような攻撃者は、もはや検知されることを恐れず、これまでよりも積極的に攻撃を しかけてくる可能性があります。過去数カ月間は検知されないように息をひそめて活動していた が、その必要はもうなくなった、というわけです。この場合、攻撃者はネットワークから永久追放 される前にできるかぎりの情報を盗み出そうと、必死の行動に打って出るかもしれません。例え ばパスワードを盗み出すために総当たり攻撃をしかけてきたり、ネットワークをスキャンしたり― こうした方法は多くの痕跡を残すため、SIEM の初期設定のルールでも容易に攻撃と認識されま す。このような攻撃が検知された場合、最も重要なのは迅速に対応することです。 71 標的型サイバー攻撃への対応 経営陣はアクティブ監視（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 を厄介な状況に置くことになります。というのも、次の攻撃が迫っているにもかかわ らず、その攻撃はこれまでのセキュリティ監視システムの設定では検出できない可能性が高いか らです。この場合も、駆除日から少なくとも二週間はデバイスを厳密に監視し、いつでも迅速に 行動できるようにしておきます。 72 第 5 章 駆除後の対応 攻撃者はまず、自分たちのマルウェアが C&C サーバ（Command-and-Control server）にアクセ スできなくなったことに気づきます。しばらくは原因を探ろうとするかもしれません。次に、攻撃 者は自分たちの IP アドレスがファイアウォールでブロックされていることを発見します。ファイア ウォールのログを調べ、DENY（拒否）イベントを把握することは重要です。これらのイベントは 攻撃者が戻ろうとしている場所を示しているため、知らないうちにバックドアをしかけられ、侵害 されていたシステムの発見につながる可能性があります。 攻撃者はシステムを侵害し、それを最初の侵入手段が利用できなくなった場合の「プラン B（第 二の手段）」とすることがあります。しかし、調査の段階で「プラン B」のために悪用されているシ ステムを発見することは至難の業です。これらのシステムは攻撃に使用されているわけではない ため、ネットワーク分析やフォレンジック（デジタル捜査）では浮かびあがってきません−しかし、 これを見逃さないようにします。例えば侵害された内部ホストが C&C サーバにチェックインしな くなった場合、攻撃者は数カ月前にウェブサーバに仕込んでおいたウェブシェルにアクセスしよう とするかもしれません。しかし攻撃者のソース IP アドレスをブロックするようにファイアウォール の設定が変更されていれば、もはやネットワークのどこにもアクセスすることはできないのです。 ここから、SOC チームと攻撃者の知恵比べが始まります。もしチームがこのアラートに気づき、 攻撃者が別の場所を経由してトラフィックを確立するよりも早く、ウェブサーバが侵害されている ことに気づいたなら、SOC の勝ちです。逆に、もし攻撃者が別の場所経由でトラフィックを確立 したり、何らかの方法で IP アドレスをブロックされていないアドレスに変え、隠しておいたバック ドアにアクセスすることに成功したりした場合は、SOC の負けとなるかもしれません。システムの アーキテクチャによっては、プロセス全体を再起動する必要もあります。SOC の分析担当者とセ キュリティチームの責任は極めて重大です。たとえ駆除活動は成功したとしても、その後に入念 で周到で積極的な監視を実行しなければ、駆除プロジェクトに費やした多大な労力とコストは瞬 く間に水泡に帰してしまうのです。 5.1.2 コントロールの検証 駆除が成功し、ネットワークも強化できたら、次は組織全体に導入されたコントロールとブロックが、 類似の攻撃が起きた場合に IR（Incident Response: インシデント対応）チームの注意を喚起するも のとなっているかを検証します。その方法として効果的なのは「外部評価」 です。あるチームが（ネッ トワーク所有者の許可を得て）会社のネットワークへの侵入を試み、未知の脆弱性を探ります。この チームには、最近ブロックした攻撃者が用いていたのと同様の手法と、評価したいシステムを識別 するためのフラグを与えます。ただし、評価の目的にかなうのであれば、チームが自由裁量で他の 手法も試せるようにしておきましょう。 駆除段階で導入されたコントロールは必ずテストしなければなりません。その理由はさまざまです。 例えば、こうしたテストは企業のネットワーク防衛体制の弱点を発見する助けになります。重要な資 産やデータがどれだけ厳重に守られているかを把握できるだけでなく、経営陣にネットワークの状 況を伝える助けにもなります。本格的なテストであれば、セキュリティ侵害の証拠も発見できるかも しれません。 73 標的型サイバー攻撃への対応 中・大規模企業の場合は、その後も少なくとも年に一度は社内ネットワークを対象に、コントロール 監査や侵入テストを実施するようにします。このような監査・テストは、社員（必要な能力の持ち主 がいるなら）が実施してもかまいませんが、できれば外部の機関に委託します。侵入テストに要する 時間は、企業の規模、テストの目的、テスト担当者に与えられる情報の量によって変わってきます。 下記は、セキュリティコントロールの評価目標の例です（テストチームには企業名以外、ネットワー クに関する情報は一切与えないものとします） 。 • テスト担当者が基幹システムにアクセスできるかを確認する。 • テスト担当者が検知されることなくネットワークから脱出できるか、重要データを盗み出せる かを確認する。 • ソーシャルエンジニアリング攻撃に対する自社の脆弱性を評価する。 • トレンドマイクロ社のサイバーセキュリティ担当バイスプレジデント、トム・ケラーマンの言葉 を借りれば、 「（既に）侵害されているデータベース（等のシステム）の観点から、システム内で 攻撃者がどこまでアクセス範囲を広げ、バックドアをしかけられるか検討する」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 74 第 5 章 駆除後の対応 5.3 教訓 駆除後の活動として、特に重要なのは得られた教訓についてのセッションを実施することです。 これはチームのメンバーが連携し、経験から学ぶための長期的なプロセスと考えましょう。公式 の教訓学習プログラムを立ち上げ、会議の進行や要対応事項への対応に責任を持つ人物を明 確に定めることは、組織が過去の間違いやインシデント、経験から効果的に学ぶ助けとなるはず です。こうしたセッションを駆除後の段階でしか行わない企業もありますが、多くの企業は調査 や駆除の段階でも定期的に実施することで効果を実感しています。 教訓学習プログラムを円滑に実施するためには、駆除段階での議論や意思決定を漏れなく書面 で記録しておく必要があります。駆除後に教訓を共有するためには、文書化と協調が欠かせませ ん。一刻を争う段階を過ぎたら、必ずインシデント対応に対するフィードバックを集めましょう。 記録しておくべき情報には次のようなものがあります。 • • • • 上手くいったことは何か ? 改善の余地のあることは何か ?（セキュリティ関連の人、プロセス、技術を検討する） 不測の事態の発生を予防できたか ? 予防できた場合は、どのような方法をとったか ? フォローアップとして、ただちにすべきことは何か ? 駆除活動が完了した後は、参加者を集めて報告会を開き、上手くいったことや改善の余地がある ことについて意見を交換します。ここで出た意見は、駆除段階で記録された教訓と合わせて、事 後報告書に盛り込みます。図 15は事後評価表の例です。 評価表を作成しても、教訓学習プログラムが修正しようとしている問題を解決できるわけではあ りません。しかし、予測可能で反復可能な教訓学習プロセスを作るためには、重要なステップで す。このプロセスには分析担当者から管理職、一般職員まで、あらゆる関係者が参加するべきで すが、関与の度合いは組織の文化や個人の能力に大きく依存します。 75 標的型サイバー攻撃への対応 図 15 事後報告書の テンプレート 調査に要した時間 調査の種類 トリガー 対策本部の指揮担当者 情報の伝達手段 初期感染の経路（攻撃の標的、または実 際に侵害されたもの） 対策本部による活動 活動を列記してください。 あらゆるレベルでタイムリーな情報伝達 が行われたか ? 伝達された情報は正確だったか ? 実行された活動のうち、手元の調査と関 係なかったものは何か ? 被害が拡大しないように、チームメン バーは安全な方法を用いたか ? 適切な設備を利用できたか ? 本来は 必要だが、今回は利用できなかったもの は何か ? そのために対応の速度に影 響が出たか ? チェックリストを使用したか ? 作成すべきチェックリスト / プロセスはあ るか ? 改善すべきチェックリスト / プロセスはあ るか ?（詳細は下に記載すること） 特殊な状況や予想外の深刻な問題が生 じたか ? 他にどんな問題が生じる可能性があるか ? 問題が生じた場合、どう対処するか ? 業務は適切な担当者に割り振られたか ? 必要な調整が行われたか ? 各担当者の仕事ぶりはどうだったか ? いつ対策本部の活動を完了するか ? 76 第 5 章 駆除後の対応 図 15 事後報告書の テンプレート（続き） 対策本部の活動が完了した後の活動 具体的な活動内容を列記してください。 教訓 対象分野 分野を列記してください。 改善の余地のある分野（人、プロセス、技術） 分野を列記してください。 どうすればインシデントの発生を避けら れたか ? 全社に技術 / プロセスを追加 （変更）するとすれば何か ? 要対応事項 アクションを列記してください。 5.4 戦略的な変更−サイバーセキュリティ改革 駆除イベントの成果物として、特に重要なのは当該インシデントの教訓を活かして、将来の攻撃 に対するレジリエンスを高める方法をまとめたロードマップです。このロードマップには、攻撃の 成功率を下げ、攻撃をより迅速かつ効果的に検知し、対処するための技術的・非技術的なプロ ジェクトやイニシアティブがまとめられています。セキュリティ侵害を分析する際には、攻撃が成 功したのは技術的な問題か、それとも人やプロセスの問題に主因があったのかを検討します。 計画の段階で、チームは駆除前に実施すべき「修正」活動を明らかにしなければなりません。そ れ以外の活動は、駆除が終わるまでは達成できない可能性のある長期イニシアティブと見なし ます。以下に掲げる活動は、企業によっては長期戦略に分類されるものですが、攻撃者が用いる 侵入・潜伏戦術によっては、駆除前に実施する必要があるかもしれません。長期戦略活動として は、以下のようなものが考えられます。 • デスクトップ環境 企業ネットワーク上のホストはすべて攻撃の対象となり得ます。一般に、 数、監視・管理の難しさ、ユーザの技術教育水準の観点から、最も攻撃の対象となりやすいの はデスクトップホストです。可能なら、駆除日より前に新しいセキュリティ・ベースライン（自社 において遵守が必要なセキュリティ対策のレベル）を定めるようにします。エンドユーザーの 行動は予測できないため、デスクトップワークステーションの悪用は不可避であり、未然に防ぐ 77 標的型サイバー攻撃への対応 ことはできないかもしれません。しかし、デスクトップ環境のセキュリティ・ベースラインを引 き上げておけば、デスクトップホストが悪用されたとしても、ネットワークにつきつけられるリス クは大幅に下がります。主な方法は以下のとおりです。 – ローカル管理者グループからエンドユーザーを除外する。 – ポリシーに定められているとおりに、アプリケーションとシステムにパッチが速やかに適用さ れていることを確認する。 – エンドポイントを守るためのウイルス定義ファイルを常に更新する。 – 高い特権を必要としない作業については、管理者も非管理者アカウントで作業するようにす る。また、Windows 7® のような安全性の高い OS を導入する時間がない場合は、まず管理 者グループのメンバーの環境に導入する。 • サーバ環境 サーバがネットワーク攻撃の始点になることはまれですが、一般に非公開の 機密情報を探している攻撃者が標的とするのはサーバです。攻撃者がサーバを狙うのは、 なるべく多くのパスワードを盗んでアクセスを拡大するため、またネットワークから持ち出す データを得るためです。駆除チームは、サーバ環境へのパッチ適用状況を確認し、適用す べきパッチのリストを作成しなければなりません。サービスの利用状況を調べ、不必要な DAEMON（ディスク・実行監視）ツールを実行しているサーバやリスナーを見つけること も不可欠です。例えば、もしサーバ上で CIFS（Common Internet File System）ファイル共 有をする必要がないなら、ホストに対する攻撃リスクを減らすために、この機能は無効にす べきです。ファイル共有が必要なサーバには、必ず最新のパッチを適用するようにします。 管理上の目的のためだけに直接サーバにアクセスすることがないように、ネットワーク管理を 導入します。管理上の目的でサーバにアクセスする必要がある場合は、ジャンプサーバを経由 するようにします。ジャンプサーバとは、2つのセキュリティゾーンを分けている堅牢なシステ ムで、2つのゾーンを安全に行き来するための手段を提供します。これらのデバイスへのユー ザーアクセスは厳密に管理・監視されます。ジャンプサーバを利用すれば、侵害されたホスト と、特定の管理されたパスの外にあるサーバ間のコミュニケーションを制限できます。さらに、 不要なアクセスチャネルを経由してサーバが交流することを防ぐために、アクセス制御も導入 する必要があります。例えば、 もしジャンプサーバとドメインコントローラの間で RDP（Remote Desktop Protocol）が使われているなら、そのドメインコントローラと RDP から、別のドメイン コントローラに移動できないようにしなければなりません。管理者がサーバ間を移動する必要 がある場合は、ジャンプサーバから別のセッションを開くようにします。こうすれば、管理上の 活動を制御、記録、監視、制限できます。 • その他の取り組むべき分野 デスクトップ / サーバ環境を強化し、攻撃の成功率を下げること 以外にも、サイバーセキュリティに関してすべきことはあります。以下に掲げた重要なテーマ は、ほぼすべて複数のプロジェクトを必要とします。また、他のプロジェクトに依存しているも のも少なくありません。サーバセキュリティのロードマップにおいて、プロジェクト管理が重要 になる理由はここにあります。特に影響範囲の広いテーマには次のようなものがあります。 78 第 5 章 駆除後の対応 – – – – – – – – – – – – – サイバーセキュリティのための PMO（プロジェクト管理オフィス）の設置と運営 セキュリティ教育・意識向上プログラムの開発 フィッシング詐欺の自己演習の定期的な実施 社内の電子調査能力の強化 企業パスワード変更管理プロセスの設計 迅速なグローバルパスワード変更の実施 パスワードの一元管理ソリューションの選択と展開 脆弱性の受容プロセスの策定 サイバーセキュリティについての企業ポリシーの改訂 情報分類プログラムの開発 社内の LAN マネージャの無効化 環境内の匿名ユーザによる接続の制限 以下に対する管理・技術的制御の改善 : ・ ドメイン管理アカウント ・ ローカル管理者アカウント ・ サービス・機能アカウント ・ パスワードが無期に設定されているアカウント ・ ドメインアカウント – アクティブディレクトリのセキュリティの強化（例 : 組織構造の見直し） – 以下のセキュリティツールの使用の最適化 : ・ 社内における暗号化 ・ ホストベース / エンドポイントの保護テクノロジー ・ DLP（Data Loss Prevention: 情報漏洩防止）とアンチウイルスソフトウェア – – – – – – – – – – – – – – – – – – 初期設定の認証情報の変更 パッチ管理の強化 データベースのセキュリティ強化（Oracle, SQL, MySQL） 高価値情報を保護するためのプログラムの開発 専門的技術情報ゾーンの設置 社内の技術コントロールの強化 イントラネットからの現場の隔離 egress（出口）フィルタリングの拡大 PoP（Point-of-Presence）の数の削減 ウェブメールのセキュリティの改善 多要素認証の導入 SIEM システムの導入 アプリケーションのホワイトリストソリューションの選択と実装 メッセージングインフラの強化 ウェブアプリケーションのスキャンと安全性の確保 インターネットの PoP におけるフルパケットキャプチャとパケット調査の実行 財務・電子送金機能のセキュリティの改善 情報セキュリティ機能の設計の見直し 79 標的型サイバー攻撃への対応 – – – – – – – 80 セキュリティコンプライアンスの強化 セキュリティガバナンスの能力の強化 アイデンティティとアクセスの管理機能の向上 情報セキュリティガバナンス、リスク、およびコンプライアンスのためのシステムの導入 ベンダーリスク管理プログラムの確立 インサイダー脅威プログラムの実行 SOC の立ち上げ 第 6 章 結 論 第 6 章 結 論 サイバーセキュリティにおけるインシデント管理のための段階的アプローチは、問題の発生その ものを防ぐことはできませんが、組織のレジリエンスを高めるという意味では大きな利点があり ます。入念に準備している企業は、準備が不十分または、まったくしていない企業と比べ、はる かに効果的に問題へ対処できます。 「準備」、 「調査・駆除」、 「事後対応」と段階を踏んで対処していくことで、企業は将来のセキュリ ティプログラムの基礎を築くことができます。まずは駆除活動が成功したことを確認し、その結果 を利害関係者に簡潔に報告したのち、教訓を学ぶためのセッションを開催します。その後で、組 織を変革するための戦略的な変化に取り組みます。 組織変革は、企業のセキュリティレベルを引き上げ、どんな事態にも対処できる体制を作る助 けになります。ISACA は現在、企業のセキュリティ担当者による組織変革を支援するために、 COBIT 5を利用した追加ガイダンスを作成中です。本ガイダンスは 2013 年第 3 四半期に発行 され、www.isaca.org で配布される予定です。 81 標的型サイバー攻撃への対応 白紙ページ 82 付録 A 調査チームが対応するその他の問題 付録 A 調査チームが対応するその他の問題 調査チームは攻撃の「実行者、標的、時期、場所、方法」に加えて、以下の問題も検討します。 • 現在、会社が攻撃検知のために実行している基本的活動は、今日の新しい脅威に即したもの となっていますか ? • 社内のコンピュータ資産をまとめた信頼できるリストはありますか ? リストの内容は随時更新 されていますか ? • 社内の許可・無許可ソフトウェアをまとめた信頼できるリストはありますか ? リストの内容は 随時更新されていますか ? • システム特権を持つアカウントは、通常のユーザーアカウントとは異なる方法で扱われていま すか ? • 機密性の極めて高いアカウントへのアクセスを管理するために、パスワードの一元管理システ ムを導入していますか ? • ユーザをコンピュータのローカル管理者グループから削除していますか ? • パスワードの有効期限が無期限に設定されているアカウント、あるいはパスワードがほとんど 変更されていないアカウントはありますか ? • 複数のドメインで利用できるシステム特権アカウントはありますか ?（ユーザ ID とパスワード が同じなど） • アカウント管理が難しい、入れ子式のグループが採用されていませんか ? • ドメイン管理アカウントを適切に管理していますか ? ドメイン管理アカウントは、他のグルー プに参加できないようになっていますか ? • 脆弱性検知のために定期的にシステム全体をスキャンしていますか ? 脆弱性が発見された ときは、リスクの度合いに応じて速やかに対処していますか ? • コンピュータの盗難に備えて、ディスク全体を暗号化する機能が導入されていますか ? • 最新の企業向けアンチウイルスソリューションを導入していますか ? すべてのエンドポイント （ネットワークと接続された端末）は最新のシグネチャとなっていますか ? • 企業データのリポジトリや共有ファイルに対して、定期的なウイルススキャンを実行していま すか ? • PKI（Public Key Infrastructure: 公開鍵基盤）は保護されていますか ? • 特に重要な鍵と証明書は、エアギャップによるネットワークからの物理的な遮断がされていま すか ? • 以下のテクノロジーのセキュリティは適切な形で強化されていますか ? – ファイアウォール、ルーター、プリンター、スイッチなどの機器 – データベースとアプリケーション – ノートパソコン、ワークステーション、サーバ • デバイス、データベース、アプリケーションの初期アカウントはすべて変更されていますか ? • 最近、テクノロジーコントロールを見直したり、更新したりしましたか ? – テクノロジーコントロールへの準拠状況を自動的かつ継続的に評価する仕組みはありますか ? 83 標的型サイバー攻撃への対応 • 以下のソフトウェアを常に最新の状態で利用できるように、信頼できるパッチ管理システムを 導入していますか ? – マイクロソフト製ソフトウェア – 他社製ソフトウェア（例 : 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、ウェブフィルター機器 • インターネットに接続しているウェブアプリケーションを保護するために、アプリケーションファ イアウォールを使用していますか ? • インターネットに提供しているウェブアプリケーションのコードを定期的にテストし、悪用可能 な脆弱性がないかチェックしていますか ? • アプリケーション開発者は全員、安全なコーディングのための専門訓練を受けていますか ? • 買掛金や資金データを扱うワークステーションは、安全性を確保するために、特定の目的以外 には利用できないようになっていますか ? • 外部専門家による侵入テストを定期的に実施していますか ? • セキュリティ意識向上プログラムの内容は刷新していますか ? すべての従業員、請負業者、 オンサイトベンダー、合弁事業のパートナーに対し、毎年トレーニングを受けることを義務付 けていますか ? • 情報セキュリティ担当者に対し、毎年適切なトレーニングイベントに参加し、スキルを磨くこと を義務付けていますか ? • 組織を守るために、より先進的な対策を講じていますか ? • 会社の情報セキュリティに関するカルチャーは、今日の脅威環境にマッチしていますか ? – アクティブマネジメントでは、情報は資産とみなされていますか ? – ニーズに応じて明確に信頼（トラスト）が割り当てられていますか ? – 一般に、自分たちが高いリスクあるいは高い価値を有する標的だと自覚していますか ? 84 付録 A 調査チームが対応するその他の問題 – 「攻撃は防げない」という事実は周知されていますか ? ―ネットワークは既に危険にさらさ れているか、近くそうなる可能性があり、そのような環境下で機密情報を保護する必要があ るという理解は共有されていますか ? – 人とデータが「新たに防御すべき境界線 」であることが理解されていますか ? • 標準に基づいて、独立した評価を実施していますか ? • 会社は、社外における情報セキュリティの一般的な動向を把握していますか ? • 情報セキュリティに対するアプローチは、リスクに基づいた、ビジネス志向のものとなっていま すか ? • ポリシー・エクセプション・プロセスに代わって、リスク許容プロセスを採用していますか ? • 自社の環境にアクセスできるベンダーやサードパーティを主体的に管理していますか ? • 情報セキュリティポリシーは組織の中枢から生まれたものですか ? • 情報セキュリティはビジネス成功の鍵とみなされていますか ? • データセンターのトラフィックは包括的に管理されていますか ? • 承認されていない、または異常なネットワークトラフィックを間断なく監視し、警告を発する仕 組みがありますか ? • 特に機密性の高い環境は、イントラネットの中心から、あるいはイントラネットそのものから切 り離されていますか ? – アクセス履歴は記録し、定期的に妥当性評価を実施していますか ? • 社内に SOC（Security Operation Center）機能がありますか ? ない場合、マネージド・セキュ リティ・サービス（MSS）を介して、同様の機能を提供していますか ? • シグネチャベースでない、マルウェア（悪意あるソフトウェア）の検知機能はありますか ? • 不審な行動を見つけるために、E メールトラフィックやその他のネットワークトラフィックを チェックしていますか ? • 社内にはフォレンジック調査する機能がありますか ? その機能にはスタッフが十分に配置さ れており、専門訓練を受けたインシデント対応チームが存在しますか ? • メンバーサーバ環境へのアクセスを厳しく管理・監視するための踏み台サーバがありますか ? • セキュリティリスクを減らすために、PC とサーバを仮想化していますか ? • コアサーバと高いリスクを有するサーバで使用するアプリケーションのホワイトリストを作成し ていますか ? • 認証情報（credentials）は以下のように区分されていますか ? – ワークステーション管理アカウントでは、メンバーサーバやドメインコントローラは利用でき ない。 – メンバーサーバ管理アカウントでは、ワークステーションやドメインコントローラは利用でき ない。 – ドメイン管理アカウントでは、ワークステーションやメンバーサーバは利用できない。 – ドメイン管理アカウントで利用できるのはドメインコントローラのみとし、必ず専用のノート PC を使い、多元的なスマートカード認証を実行するものとする。 – アプリケーションアカウントで利用できるのは、特定のアプリケーションまたはシステムのみ とする。 • 過去にさかのぼって、潜在的な脅威を含むセッションを再現できるように、すべての出口 （egress point）に強力なフルパケットキャプチャ機能を導入していますか ? 85 標的型サイバー攻撃への対応 • フィッシング詐欺の自己演習を実施し、これらの脅威を従業員がどれだけ認識しているかを把 握するようにしていますか ? • 機密データを守るために、ネットワークやエンドポイントに DLP（Data Loss Prevention: 情 報漏洩防止）ソリューションを導入していますか ? • すべてのエンドポイントにローカルファイアウォールを設定していますか ? – エンドポイントには必ず、IDS/IPS ソリューションを導入していますか ? • イントラネットとインターネットの接点を制限していますか ?（出口の統合など） • 意思決定のプロセスを後押ししている情報セキュリティ戦略はありますか ? • 社内の情報セキュリティ組織は、今日の脅威環境に即したものとなっていますか ? また、これ らの組織にはトレーニングを受けたスタッフが十分に配置されていますか ? • ソーシャル、モバイル、クラウドのための本格的なセキュリティプログラムは開発されていま すか ? • インサイダー脅威プログラムは開発・展開されていますか ? • 以下の分野で強力な体制を整えていますか ? – セキュリティ・カバナンス・チームおよび組織 – ガバナンス・リスク・コンプライアンス（GRC）プログラム（組織を定期的にテストするため のセキュリティ・コンプライアンス・プログラムを含む） – アイデンティティ& アクセス管理（IAM）プログラム – 脅威・脆弱性管理（TVM: Threat and Vulnerability Management）プログラム – エンタープライズリスク管理（ERM）機能に組み込まれた情報セキュリティリスク管理プロ グラム – ベンダーリスク管理プログラム • 情報セキュリティポリシー、標準、手続き、ガイドライン、推奨事項は、すべて更新されていま すか ? 86 付録 B 調査ツール 付録 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 87 標的型サイバー攻撃への対応 白紙ページ 88
© Copyright 2024 Paperzz
