2024.08.08
セキュリティインシデント対応(1/2)
目次
中小企業の経営者や情報システム担当者の皆さん、日々のセキュリティ対策、お疲れ様です。本記事では、これまでに「クラウドサービス利用時の注意点」について解説してきました。
今回は実際に何か問題が生じた際に対応が求められるセキュリティインシデントについて、重要なポイントを分かりやすく、具体的な事例も交えてお伝えします。
1.セキュリティインシデントとは
まず、セキュリティインシデントの定義を確認しましょう。
セキュリティインシデントとは、情報漏えいやシステムの停止などセキュリティに関わる事故や出来事(事象ともいう)を指します。単に「インシデント」と呼ばれることもあります。
事故は、情報の漏えいや改ざん、破壊・消失、情報システムの停止などが挙げられます。
事象は、事故につながる可能性がある出来事です。メールを誤送信したが情報漏えいにはいたらなかった、あるいは誤送信しそうになったが送信する前に気づいた場合などです。
2.インシデント対応の必要性
インシデントが発生しないように様々な対策を取っていても、予期せぬインシデントが起こる可能性はあります。万が一インシデントが発生した場合には、被害や影響範囲が最小限になるようにし、事業を継続できるようにする必要があります。
3.インシデント発生時の想定被害
インシデントが発生した場合の被害には、直接的な被害と、間接的な被害があります。
【直接的な被害】 攻撃者による不正送金や金銭要求
対応人件費
原因調査や復旧のための外部委託費
復旧までの代替品費
取引先や顧客への謝罪対応費
法的対応のための弁護士費用 など
【間接的な被害】 関係者への被害波及
会社の信用低下
事業停止による機会損失 など
実際にセキュリティインシデント対応を行った際の被害などを集計したデータでは、サイバー攻撃を受けた企業の約半数は業務停止の被害を受け、約2割の企業が直接的な金銭被害や復旧にあたった人件費などの金銭的コストが発生しています。
参照記事
https://www.trendmicro.com/ja_jp/jp-security/23/k/ciolounge-joint-survey-commentary.html
(出典:トレンドマイクロ株式会社 2023年11月1日 セキュリティサイト掲載記事)
https://www.nikkei.com/article/DGXZQOUE056JB0V01C23A0000000
(出典:株式会社日本経済社 2023年10月31日サイト掲載記事)
4.インシデント対応の目的
インシデントが発生したことで生じる被害とその影響範囲を最小限に抑え、迅速に復旧し、再発を防止することで、企業(組織)の事業が継続できるようにすることが目的です。
5.実際のインシデント対応
ここからは、実際にインシデントが発生した際にどのような対応が必要となるのか具体的なステップを説明していきます。
なお、インシデントの対応は、発生している事象・被害や影響範囲の大きさなどによって変わってきます。このため、インシデント対応時に下記情報をまとめて整理しておくことが大切です。
(1)インシデント対応時に整理すべき情報
インシデントの分類 | 情報漏えい、ウイルス感染、システム停止など |
事業者の名称 | 事業者の名称(受託案件の場合は委託元) |
責任者・担当者 | 本件に関する責任者及び担当者の所属、氏名 |
発覚日時 | インシデントを認知(発見したり、通報を受けた)した日時 |
発生日時 | 調査で判明したインシデントの発生日時 |
発生事象 | 表面化している事柄、被害、影響など |
対応経過 | 発生から現時点までの時系列での経過 |
想定原因 | 現時点で想定される直接的な原因 |
被害を受けたシステムの状況 | 被害を受けたシステムの概要と被害の詳細な状況 |
システム構成・運用状況 | システムの物理的な所在場所 OSやアプリケーションとそれぞれのバージョン構成 システムの構成図 システムの運用状況 使用しているセキュリティツールやサービスの利用状況 |
この中で、システム構成・運用状況はインシデントが発生してからでは整理できませんね。
普段から整理しておくようにしましょう。
それでは、いまからインシデント発生時の具体的な対応手順と内容を説明します。
(2)インシデント対応時のステップ1・2・3
<ステップ1>検知・初動対応
インシデントを発見した際(疑わしい場合を含む)は、すぐに社内の連絡ルールに従って、情報セキュリティ責任者に報告します。ネットワークの遮断やシステムの停止を必要に応じて行い、被害の拡大を防ぎます。社外など外部から通報を受けた場合は、通報した人の連絡先を控えておくことも大切です。なお、メール誤送信などの場合は、起こってしまったことを報告しやすい社内風土を作ることも大切です。内部であれ、外部であれ、セキュリティインシデントは人による報告が早期発見につながるからです。
責任者への報告を済ませた後は、初動対応へと移ります。
ネットワークの遮断、情報や対象機器の隔離、システムやサービスの停止を必要に応じて行います。
このステップの発見時の社内連絡フロー、初動対応の手順は平常時に定めておくことが大切です。
■事例A社の場合:A社では、セキュリティインシデントとして、パソコンの画面が突然フリーズし「ウイルスにかかっています」と書かれたメッセージが表示されるという事象が発生しました。初動対応としては、この時点で社内に報告し、そのパソコンをネットワークから遮断すべきです。しかし、早急に対処したいと画面に表示されたところに電話をかけ、指示されたとおりにパソコンを操作したところ、遠隔操作によって機密情報が盗まれるという事態に至ってしまいました。
<ステップ2>報告・公表
インシデントの影響が広範囲に及ぶ場合、Webサイトやメディアを通じて公表します。
第一報では、公表することで被害の拡大を招かないように、公表する時期や内容などを考慮します。
第二報以降では、被害者や、影響を及ぼした取引先や顧客に対して、インシデントの対応状況や再発防止策等に関して報告します。また、被害者に対する損害の補償等を必要に応じて行います。個人情報漏えいの場合は個人情報保護委員会、業法等で求められる場合は所管の省庁等、犯罪性がある場合は 警察、ウイルス感染や不正アクセスの場合は独立行政法人情報処理推進機構(IPA)へ届け出ます。
<ステップ3>復旧・再発防止策
適切な対応や判断を行うために状況を調査し、インシデント対応時に整理すべき情報(上記表)を参考に情報を整理します。続いて、訴訟対応等を見越して事実関係を裏付ける情報や証拠を保全します。並行して、システムやサービスを復旧させます。その後、再発防止策を講じ、同様のインシデントが再発しないようにします。例えば、新たなセキュリティツールの導入や従業員の教育強化などを行います。
■事例B社の対応:B社は、ランサムウェア攻撃を受けた際、速やかにバックアップデータを使ってシステムを復旧させました。事前にインシデント対応計画を策定していたおかげで、顧客への影響を最小限に抑えることができました。また、日常的にヒヤリハット事例を収集し、対策を強化していたこともあり、対応をスムーズに進めることができました。
(3)ヒヤリハット事例の活用
「ヒヤリハット」とは、重大な事故には至らなかったものの、注意を怠れば事故に繋がりかねなかった事例を指します。日常業務でのヒヤリハット事例を収集し、共有することで、潜在的なリスクを把握し、予防策を講じることができます。
6.まとめ
セキュリティインシデントへの対策は、事前に発生時の対応手順を定めておくことが大切だとわかっていただけたでしょうか。また、定めた計画や手順どおりに実行できるかを実際にシミュレーションしておくこともとても大切です。また、対応手順は定期的な見直しと改善が重要です。
今回ご紹介したポイントを基に、皆さんの企業でも改めて対策を見直してみてください。
ヒヤリハット事例の収集と対策も忘れずに行いましょう。
なお、本稿は、IPAが発行しいている「中小企業の情報セキュリティ対策ガイドライン 第3.1版」を中心に解説しています。セキュリティインシデント対応については、ガイドラインの「付録8 中小企業のためにセキュリティインシデント対応の手引き」にまとめられていますので、もっと詳しく知りたい方はそちらをご参照ください。
次回は、ランサムウェアに感染した場合を例にして、ステップを踏んだインシデント対応をより具体的に解説します。