インシデントによる深刻な被害を防ぐために大切な「己を知る」こと

2021年6月18日
著者：セキュアワークス株式会社　カウンター・スレット・ユニットリサーチチーム

セキュアワークスでは、大量の機密情報暗号化・暴露を用いた金銭脅迫、脆弱性を起点とした情報漏洩、サプライチェーン攻撃を起点としたクラウド環境侵害など、多種多様なインシデント対応をサポートさせていただいています。

その中で、特に直近において「自組織をよく知る」ことで被害を回避・低減できたケースがよく観測されています。本記事ではセキュアワークスのインシデント対応事例をベースに、これが把握できていれば被害を回避・低減できていたと考えられる点を4つ紹介します。

1. 社内システム・ネットワークを知る

セキュアワークスが日本で対応したインシデント対応事案の約25%が海外拠点で発生したものですが、ランサムウェア事例のみに絞ると約50 %まで上昇します。これは、海外拠点がどのような構成を持ちどのような管理が行われているかなど知らなかったことが侵害・脅迫へと繋っていると考えられます。具体例として、以下に示すようにインターネットに公開されたVPNやリモートデスクトップサービスの正規アカウントを用いて侵入されたケースが多く、どのようなアカウントが存在しているか、パスワード管理がずさんであることを認識していなかったことが読み取れます。また、海外拠点とどう繋がっているか知らなかったことなどが重なった結果、国内拠点や他の海外拠点へと被害が拡大した事例も存在しています。

図 1: ランサムウェアインシデントにおける侵入経路

そもそもインターネットに公開しているデバイスを認識していない、また公開する必要のないものが公開されていたといった認識違いがあったことから発生したインシデントも存在しています。コロナ禍におけるテレワーク推進によって外部からのアクセスポイントが増え、それらの把握・管理が難しくなる一方、攻撃者はインターネット上を絶えずスキャンして脆弱な場所を探していることを自覚しておかなければなりません。

これらの事例はすべて、システム・ネットワーク構成を正しく把握できていればその被害を回避・軽減できるものです。具体的に以下の内容も含めて構成情報が正しく存在しているかを一度確認してみることを推奨します。

仮想マシンホストを含めた全サーバ・端末
セグメント・フィルタリング設定なども含めたネットワーク構成
存在するアカウントとその使用用途
各種ログの保存先や保存期間

なお、システム・ネットワーク構成図が存在していたとしても、記載されていないサーバや経路が存在していたり、（意図せず）記載とは異なる設定がされていたりする場合もあるため、それらの情報が正しいことを定期的に確認することも重要です。

2. 情報資産を知る

機密情報の窃取を目的とした標的型攻撃事例や、機密情報を窃取し金銭を要求するランサムウェア事例において、自社の情報資産がどのように管理されているかを知っているかどうかが、その対応速度に影響します。侵害されたファイルサーバやデータベースサーバにどのような情報が保存されているかを知らなかったために調査・復旧・情報公開に想定以上の時間がかかってしまった事例を複数確認しています。

また、近年のインシデントにおいて、ソースコード情報の流出からクラウド環境への侵害、個人情報窃取につながる事案がいくつも発生しています。これらは本体保存すべきではない場所に認証情報や個人情報が保存されていて、それを把握していなかったために被害が広がったと言えます。情報資産がどのような場所に保存されているか、だけではなく、保存されてはいけない場所に保存されていないかという点も確認することが重要です。

3. システムの監視状況を知る

インシデント対応では、インシデントの起点（過去）を調べつつ今潜んでいる脅威を排除し、再度インシデントが発生しないクリーンな環境を取り戻すことをゴールとして対応を進めます。しかしながら、侵害されたシステムの調査に必要な情報が無いことがよくあります。エンドポイント監視をしていたが対象マシンには入っていなかった、ログは取っていたがデフォルト設定で必要な情報が記載されていなかった、インシデント発生時のログはすでにローテートで消えていた、など理由は様々です。図2のとおり、インシデントにおける侵入経路が不明だったケースはこの点に確実に問題があったことを示しています。

図 2: インシデント対応で確認した侵入経路の傾向

インシデントが発生すること想定した上で、対応にはどのような情報が必要となり、自組織の監視状況でそれらをどれだけカバーできているかを知っておくことが必要とされます。エンドポイントだけでなくクラウド環境も含めて、そのログ取得・監視状況を確認することを推奨します。

また、調査では複数のログを関連付けして事象を把握することがあります。ログの取得設定だけでなく、システムの時刻設定にズレがあるかどうかも合わせて確認しておく必要があります。また、DNSやプロキシログから端末を特定できるかどうかなど、インシデント発生時を想定し実際に手を動かしてどのように調査すれば良いかを理解しておくことも重要です。

4. サプライチェーンリスクを知る

自組織のパートナーや使用製品など、サプライチェーン上の脆弱なポイントを攻撃するサプライチェーン攻撃は様々なパターンがあります。最近では製品提供者が侵害され、アップデートファイルや公式のスクリプトとしてマルウェアが配信される事例も珍しくありません。このような事例では脆弱性対応の枠組みだけでは対処することができません。

IT技術は絶えず進化しており、その環境は複雑さを増しています。例えば一部の部署でのみ使用しているツールがインシデントの起点となった場合に迅速な対応が可能でしょうか？特定部署でのみ使用しているツールなども含め、自組織が使用していることを把握している状態を維持することは難しいですが重要なことです。一元管理ができなくとも、誰に・どのように確認すれば良いかなど、組織全体として「知っている」状況を維持しましょう。