レスポンス活動の網羅性を高めるための要求事項（前半）

投稿者：ASERT Japan名誉アドバイザー名和利男

投稿日：2017/5/15

　筆者の経験の限りであるが、2017年1月から4月までの日本国内で発生しているサイバー攻撃の動向変化として、次のような特徴を強く感じている。

個人情報の窃取は相変わらず発生しているが、個人情報以外の内部情報（営業秘密情報等）を根こそぎ外部流出させる攻撃が相対的に増加傾向にある。
マクロ型不正プログラム（ファイルレス・マルウェア）等の「環境寄生型」攻撃が、相次いで発生している。

　このような攻撃対処支援に相当数関与させていただいたが、前者は個人情報流出事案ではなく、後者は証跡不足のため被害特定と原因追求を断念した。そのため、現時点において、いずれも外部への公表・共有や関係する公的機関への報告は実施されていない。

　筆者は、組織を守る立場で関与しているため、当該組織の許諾を得ない限り、組織や業種を完全匿名にしたとしても、攻撃詳細をお知らせすることはない。（この記述を書くだけでも、関係する方々に慎重に確認いただいた。）

　しかし、外資系のセキュリティ企業がブログ等でレポートしているファイルレス・マルウェアの仕組みとは異なる点が多く、日本組織特有の内部システム・ネットワークの環境に適用させている可能性があるため、当該組織から許諾を得られ次第、このブログで紹介したいと考えている。

　今回のブログでは、このような攻撃対処支援等において、筆者が現場及び管理者に対して「レスポンス活動の網羅性を高めるための要求事項」として、実際に口頭や文書でアドバイスしたものの中で、あたりが良かったもの（効果が感じられたもの等）を紹介させていただく。すでに、IPAやJPCERT/CCが、素晴らしいガイドラインを公開しているので、そちらも確認していただきたい。

【攻撃を受ける前の状態】

サーバの運用保守

　サーバの運用保守の状況について、次の点を可能な限り確認することで、サーバにおける異変等の事象に対する判断状況を見極めることができる。

「サーバの直接的な運用保守の管理を外部に委託しているか？」

　外部の保守委託業者は、専門性及び客観性が高いため、発生する事象がシステム障害や性能劣化、或いはサイバー攻撃によるものか等の初度の切り分けが早いと期待できる。一方、内部の構成員が直接的に運用保守している場合は、担当する構成員の障害対応に関するスキルや経験によって、発生する事象に対する認知レベルが異なる。つまり、どの主体が運用保守を行っているかによって、判断すべき情報源の正確性や網羅性が異なる。

「サーバの運用保守の管理は、24時間365日体制を取っているか？」

　攻撃に関する挙動は、運用保守の管理が手薄な時間帯に集中していることが多いため、一部或いは全ての時間帯を監視システムに依存した状況では、他の攻撃が発生している可能性がある。

「サーバの運用保守に利用しているツールやシステムは何か？」

　深刻なAPT攻撃を受ける組織の多くは、サーバの運用保守のための特別なツールやシステムをせずに、稼働しているOSやサーバアプリケーションの標準的なログのみに頼る傾向がみられる。また、利用しているツールやシステムを把握しておくことで、そのログ情報の要不要を判断することができる。

「サーバのログのローテーション及び保存期間はどれくらいか？」

　昨今のAPT攻撃は、数ヶ月単位の長期間にわたる攻撃準備が行われることがあるため、ログが十分に残っているかどうかで、調査の可否や実態解明の実現レベル等を見通すことができる。

内部システムの運用保守

　内部システムの運用保守の状況について、次の点を可能な限り確認することで、内部システムにおける異変等の事象に対する判断状況を見極めることができる。

「内部システムの運用保守は、どのような体制になっているか？」

　一般的に、「IT／インフラ／プラットフォーム部門」が共通基盤としての内部ネットワークや内部サーバを管理し、「特定の事業／プロダクト部門」がその上で稼働するサーバを管理する傾向にある。そのため、内部のどのシステムがサイバー攻撃による直接的な被害を受けたかどうかによって、一次的に対応する主体が異なる。

「内部システムの運用保守の構成員のスキルや経験は、どの程度か？」

　直接的に対応する構成員のスキルレベルにより、発生した事象の認識が異なる。また、経験においては、特定の業務環境に偏重した経験が長い場合は、想定外の事象への把握や理解が難しい場合がある。

ネットワーク監視

　ネットワーク監視の状況について、次の点について確認しておくと、影響範囲を見極めることができる。

「ネットワーク監視を行っているか？」

　ネットワークを通じて、負荷の異常な高まり、サーバの障害、ネットワーク接続障害、ネットワーク機器障害などを監視しているかどうかにより、記録としての残る状態把握の記録の有無を把握することができる。

「ネットワーク監視を外部に委託しているか？」

　ネットワーク監視の委託業者は、高いレベルの検知能力を持っているため、発生事象に対する判断が期待でき、契約内容によっては、一時的な技術的対処を行ってくれる。しかし、内部でネットワーク監視を行っている場合は、検知能力に不足が見られることがある。

「ネットワーク監視の範囲はどこまでか？」

　コストの都合上、すべてのネットワークを監視していることがない。攻撃に関する挙動は、ネットワーク監視がされてないところを経由して行われることがあるため、その範囲を明確にしておく必要がある。

ヘルプデスク

　ヘルプデスクの活動状況について、次の点を可能な限り確認することで、内部端末PCの利用者の運用状況やITリテラシーを見極め、認知可能な事象の取りこぼしの存在の見極めることができる。明示的なヘルプデスクが存在しない場合は、事実上のヘルプデスク的な役割を持つ構成員とみなす。

「ヘルプデスクと、サイバー攻撃に対処する可能性ある部門との連携はあるか？」

　内部端末PCの利用者と直接やり取りをするヘルプデスクに集約される事象情報のうち、ヘルプデスクが判断することが難しい発生事象の情報が、円滑かつ速やかに、サイバー攻撃に対処する可能性のある部門に提供されているかどうかを確認することで、認知可能な事象の取りこぼしの存在の確認に役立つ。

「ヘルプデスクに対する問い合わせ内容はどのようなものか？」

　ヘルプデスクに集約される問い合わせ内容を把握することにより、内部端末PC利用者の運用状況やITリテラシーの傾向を把握することができ、サイバー攻撃の被害を受ける後の認知レベルを見積もることができる。

独自システム使用（保有）者

　IT／インフラ／プラットフォームが提供する内部ネットワークに連携した形で、異なる内部ネットワーク／システムを独自に構築及び運用保守している使用（保有）者の状況について、次の点を可能な限り確認することで、攻撃プロセス或いは攻撃範囲を見極めることができる。

「IT部門が管理していない内部ネットワーク／システムは存在しているか？」

　IT部門が直接的に管理していない内部ネットワークやシステムは、想定外の構成や運用がされている場合があるため、IT部門が全く関与していない場合は、そのシステム使用（保有）者に直接聞き取りをする必要がある。

「IT部門と独自システム使用（保有）者の部署の連携はあるか？」

　例えば、産業用制御システムは、IT部門がほとんど関与していない形で調達、構築、運用されており、サイバーセキュリティに関する取り組みの連携がないことがほとんどである。また、IT部門が把握している独自システムの構成や運用状況が、実態と異なっている場合もある。

CSIRTの設置

　CSIRTが設置されていても、十分な権限が与えられていない場合や、既存のセキュリティ関連部署との住み分けが厳しい場合があり、対処活動に制約を受けていることが多い。状況を正確に把握するためには、その点を重視した次のような確認をする必要がある。

「設置されているCSIRTは、どのようなセキュリティ部署と連携しているか？」

　多くのCSIRTは、独自システム使用（保有）者から遠い関係位置にあるため、IT部門やマネージメント層との密な連携をしておく必要があるが、それが実現できずに、限定的な活動（情報収集や注意喚起等）のみの活動に制約されていることがある。

脆弱性診断

　過去の脆弱性診断の結果を確認しておくことにより、サイバー攻撃の原因追求を見極めることができる。

「過去に、運用しているシステムの脆弱性診断を実施したことがあるか？」

　実施したことがある場合はその結果を、対処活動の資料の一部として保有しておくことにより、原因追求に非常に役立つことがある。

「過去に実施した脆弱性診断の結果に基づいて、どのようなセキュリティ対策を行ったか？」

　過去に実施した脆弱性診断の結果に基づいて、取られたセキュリティ対策の変更管理がされていない場合が多いため、その変更部分だけでも把握しておくことで、手戻りの少ない対処活動を行うことが期待できる。

ペネトレーションテスト

　徹底的な脆弱性検査において、修正すべき箇所が見当たらなくても、システムの設定不備や特定サービスを利用してサイバー攻撃を仕掛けることが出来る場合があるため、実際の攻撃手法を試しながら、システムの安全性をテストする必要があるが、サイバー攻撃の被害を受けた組織は、このテストが十分でなかったことが多い、或いは、脆弱性検査とペネトレーションテストを同一視していることもある。そのため、次の点を確認することで、サイバー攻撃を受ける蓋然性を見積もりや、他の検知できていない攻撃に関する事象への調査の必要性の見極めに役立てることができる。

「過去にペネトレーションテストを実施したことはあるか？　もし、ある場合は、どのようなツールを使ってテストを行ったか？」

　国内には、ペネトレーションテストをツールの実行で済ませてしまう専門業者が少なくない、実際の攻撃手法は、ターゲットとする組織のサーバや内部システムの状況をよく把握した上で、防御側が想定することが難しい斬新なアイディアに基づくものが目立ってきているため、一般に流通しているツールでペネトレーションテストを実施しても、網羅性のある検証を行うことが難しい。

【攻撃の検知・認知】

事象の発見・通報

　誰が、どのようにして「サイバー攻撃の疑いのある事象」を発見するのかに着目する必要がある。また、全ての障害がサイバー攻撃とは限らず、システム（ハードウェアやソフトウェア等）の障害や発見者の誤認識を含まれていることに注意する必要がある。次の点を可能な限り確認することで、サイバー攻撃対処活動のトリガーと、サイバー攻撃の検知能力の見極めや向上策の立案に役立つ。

「サイバー攻撃と決定づけた事象情報は、誰が、どのようにして発見したものであるのか？」

　セキュリティ検知装置だけで、サイバー攻撃の事実を見出すことができないのが現状である。インターネットに公開しているサイトを閲覧したユーザー、外部のメールを受信、或いは、公的機関からの通知などにより、事象を発見できた場合が散見される。

「発見者は、どのような窓口に通報し、どこを経由して、サイバー攻撃の疑いのある事象の情報を通報してきたのか？」

　事象を発見した人が、発見した事象により、「直接的或いは間接的な被害を受ける場合」と「まったく関係ない場合」のいずれかによって、通報の仕方が異なるが、被害組織に対する直接連絡、JPCERT/CC、IPA、警察公安のサイバー担当窓口、契約しているISP、或いはセキュリティに詳しい技術者に通報することが多い。その後の経路は、通知を受けた窓口の独自の判断で事象情報の流れが決まる。

事象の情報受領

　発見者から、サイバー攻撃の疑いのある事象に関する情報を受け取った組織内の担当者は、どのような手段で受け取り、組織内に到着したタイミングと受領に気づいたタイミングとの差分に注目する必要がある。
次の点を可能な限り確認することで、サイバー攻撃の検知能力の見極めや向上策の立案に役立つ。

「組織のどこの担当者が、いつ、どのような手段で、サイバー攻撃の疑いのある事象の情報に気づいたのか？　また、その情報を機械的に受領していた場合、受領時刻からどのくらいの時間が経っていたか？」

　受領する方法は、Eメール、電話、FAX、組織の総合窓口で受けた内容の連絡メモや、セキュリティ検知装置等からのアラート情報などがある。特に、FAX や Eメールの場合は、受領に気づかなかったり、情報送信元の真正性を確認する必要がある。

外部から受領した担当者（組織窓口）から、本情報を利用すべき担当者（対処担当者）までの情報の伝達は円滑であったか？」

　稀に「外部から受領した担当者（組織窓口）」の認識不足により、情報の取りこぼし等が発生する場合があるため、過去の外部からの受領情報についても、念のため確認を行うことが望ましい。

事象の判断（初度認識）

　対処すべき担当者が、受領した「サイバー攻撃の疑いのある事象の情報」を、どのような判断基準あるいは根拠等をもって取り扱うべき事象と認識したのかを確認しておく必要がある。
　次の点を可能な限り確認することで、受領した事象の情報から実際の対処活動に移行するまでの繋がりのプロセスを明確にすることができる。

「事象の判断を直接的或いは主体的に行った担当者は、どのようなスキルと業務経験を有しているか？」

　事象判断は、多くの場合、それを行った担当者の独自能力に依存することが多い。たとえマニュアル等が整備されていても、それを事細かく把握し、正確に準拠した対処活動を行った事例はほとんどみられない。

「既存の情報セキュリティ規則類に、事象判断に役立つ規定事項は存在しているか？　もし、その規程類に該当箇所がみられない場合、何をよりどころとしたか？」

　国内組織のほとんどの規程類は、「組織の情報資産について、機密性、完全性、可用性をバランスよく維持し改善すること」を基本コンセプトとしているため、情報資産と直接的な関係性を見出すことが難しい事象については、既存の情報セキュリティ規則類に対処する事項が欠落しているか、不十分さが目立つ。

初度認識の攻撃種類

　実際の対処活動を行うにあたっては、予測或いはほぼ断定的に判断された攻撃の種類に基づいて行われることが多い。このため、あらかじめ、この攻撃の種類を想定し、対処活動の道筋を定めて、インシデント対応関連の規程類に記述しておく必要があるが、実際には、この部分が欠落しているか、記述の粒度が粗すぎるものがほとんどである。
　次の事項を可能な限り確認することで、本格的な対処活動に着手するまでに準備しておくべき事項を抽出することができる。

「発生した攻撃の種類は、あらかじめ適切に想定されるものであったか？もし、想定が不十分であった場合、具体的にどのような部分で、その理由は何であったと考えるか？」

　最近、国内でよく発生する「内部情報を大量に窃取するサイバー攻撃」は、完全に想定外のものであるが、その背景や理由として、競争激化による「システムの開発期間の短縮化」、高いレベルの要求事項の実現による「システムの高度化・複雑化」、利用者の急拡大による「システム運用負荷の増大」等により、被害を受ける可能性のある攻撃の種類が増えてしまう傾向にある。しかし、安定的な運用を確立することに多くのリソースがとられるため、相応するセキュリティ対策の検討が不十分になってしまう結果を招いている。

初度認識の対処優先度

　最近のサイバー攻撃は、同一組織に対して、複数の攻撃種類が同時多発的に発生するものや、内部の価値ある情報を窃取する目的のために中長期間に渡り、異なる種類のサイバー攻撃が順次行われることがある。
次の事項を可能な限り確認することで、限られた人的リソースで最善の対処活動をするための見通しをつけることに役立つ。

「既存のセキュリティ規則類或いは現場担当者の認識において、対処を行うべき攻撃の種類の優先付けはあるか？もし、ある場合、その優先順位とその考え方や根拠はどのようなものであるか？」

　組織に、対処優先度が、形式知或いは暗黙知にいずれかでも存在しているということは、何かしらの経験にもとづく背景や理由があるはずである。そのため、それを徹底的に把握することで、宣言された攻撃に対する対処活動の重要なトリガーを見極めることが期待できる。

初度認識の対処範囲

　初度認識により、対処活動の道筋を立てた後に、関与させるべき主体と対処の範囲を決める必要がある。攻撃の種類や対処優先度が明確に設定されている場合は、必然的に対処の範囲が決まる。しかし、実際には、この対処範囲は、都度都度の判断で、特定の担当者の知見や経験に基づくもので決定されることが多い。
次の事項を可能な限り確認することで、実際の対処活動に移行するまでの現実的な手続きを見極めることに役立つ

「対処活動に関与させるべき関係者と技術的対処を行うべきシステムの範囲を決定した担当者は、どのようなスキルと経験を有しているか？」

　もし、規則類に明示的に取り決め事項の記述があれば、それを把握することが必要である。しかし、その記述が存在していても、現状にそぐわない、或いは、記述の粒度が粗いために、実際に活用可能な状態でない場合があることに考慮すべきである。

＜後半に続く＞