セキュリティインシデントとは？種類や対策、有名な事例も紹介

セキュリティインシデントとは、情報セキュリティ上の予測できるが望ましくない問題や、事前には予期できなかった問題などで発生する事件・事故の総称です。主なセキュリティインシデントの例を挙げると、「マルウェアへの感染」「不正アクセス」「webサイトの改ざん」「機密情報の流出」などがあり、枚挙にいとまがありません。

また、セキュリティインシデントというと、攻撃者による高度なサイバー攻撃の被害などを思い浮かべる方が多いと思います。しかし、実はセキュリティインシデントは軽微なものが多く、「メールの誤送信」「パソコンや記憶媒体の紛失」などに類するものがほとんどです。 

それでも、軽微なものも含めてセキュリティインシデントへの対応を的確に実施することが、現在では社会的な責任を持つ企業や組織に求められています。なぜなら、割れ窓理論（※1）のように、軽微なインシデント（以下、セキュリティインシデントの意味で記します）を放置したことが重大インシデントにつながることも少なくないからです。

そのため、社会的な責任を果たすためにも、企業や組織としてインシデントへの対応が求められるようになりました。具体的には、インシデント発生時の被害を最小化するための体制を整備することが望ましいとされています。

このような、万が一のインシデント発生の際の対応（インシデントレスポンス）をするための組織として、SIRT（Security Incident Response Team）という専用の体制を整備することもまた、一般化しつつあります。これは、数千～数万人規模の知名度の高い大企業はもちろん、最近では1,000名未満の中堅・中小企業などでも珍しくなくなっています。

（※1） 割れ窓理論とは、アメリカの犯罪学者による、1枚の窓ガラスが割れていることを放置したままにすると複数の窓ガラスが割れていても気にしなくなり、結果的に街全体がすさんでしまうことにつながるという理論です。

サイバー攻撃以外のセキュリティインシデントの主な種類について以下に記します。

• 人為ミスによるセキュリティインシデント
• 内部不正によるセキュリティインシデント
• 自然災害などによるセキュリティインシデント

人為ミスによるセキュリティインシデント

セキュリティインシデントで多いのは、この人為ミスによるものだと考えられます。例えば、「メールの誤送信」や「意図しない機密情報の公開」などです。

少し古いデータになりますが、図1の通り、2016年のIPA「内部不正による情報セキュリティインシデント実態調査」でもこのことが示されています。

中でも多く発生するメールの誤送信は、人が操作している以上、皆無にするということは考えにくい性質だと言えます。また、PCやスマートフォン、オフィスへの入室用カードキーなどの紛失や盗難なども、メール誤送信に匹敵する「よくあるセキュリティインシデントの例」と言えるでしょう。

内部不正によるセキュリティインシデント

「人為ミスによるセキュリティインシデント」では、その原因は過失や、重篤な場合だと重過失のものですが、その行為が意図的だった場合は「内部不正」となります。人為ミスでも意図的であったとしても基本的には同様と考えてもよいのですが、内部不正の場合はより大きな被害になりやすい傾向があります。

そもそも、不正をした人物には、具体的なメリットや何らかの意図（組織への報復など）があるものです。外部の攻撃者によって実施されるサイバー攻撃と違い、「その情報がホンモノである裏付けがある」という点が大きな相違です。その裏付けは、その情報の価値をおのずと高める効果があるからです。

自然災害などによるセキュリティインシデント

避けられないセキュリティインシデントの原因として、自然災害も無視できません。具体的には地震、洪水、台風やそれによる破損、浸水、火災などです。自然災害によりデータセンターやサーバールームなどが物理的な被害を受けた場合、「システムダウン」「データ損失」が起こり、その結果として「業務停止」に追い込まれる状況にも成り得ます。

自然災害は、地震や、頻度としては少ないですが隕石の落下など、予測が難しいものが少なくありません。そして、日本はそもそも地理的にも災害を受けやすく、発生の際の被害も甚大になることが少なくないため、想定できる限りの「備え」が重要だと言えるでしょう。

セキュリティインシデントのレスポンス（Incident Response：IR）とは、インシデントが発生した際の適切な対応やその準備（攻撃検知機能と連携した体制整備など）を指します。

インシデントレスポンスの主な目的

インシデントレスポンスの目的は、説明方法や意図によっていろいろな表現方法がありますが、おおむね以下の四つが機能することだと言っていいでしょう。

1. サイバー攻撃による損害を軽減すること（損害の軽減）
2. 侵害された脆弱性を速やかに修復すること（脆弱性への対応）
3. 業務の継続性を確保すること（BCP：事業継続計画/BCM：事業継続マネジメント）
4. 将来的に発生する同様のインシデント発生を防ぐ（再発防止）

本項では、セキュリティインシデント検知の重要性や、初動対応のプロセスについて解説します。

サイバー攻撃は、攻撃に気付けることが第一

インシデントレスポンスの具体的な方法・手順をあらかじめ定めておくことは非常に有効です。最初に行われ、最も重要だと思われる方法・手順は、「インシデントの検知」です。インシデント対応のためには、まず何はなくともインシデント自体に気付かなければならないからです。

ほとんどの人にとって、このことは当然のように感じるでしょう。そもそも攻撃者は自分が実行したシステム内の潜入や機密情報を窃取したことなどを基本的に誰にも知られたくはありません。だからこそ、ほとんどのサイバー攻撃では、攻撃者は自分の行動がばれないように隠ぺい工作を実施します。

一部に例外的なサイバー攻撃があります。それは、ランサムウェアを使った攻撃です。この攻撃は、身代金を要求する必要があることから、自ら攻撃をしたことを知らせます。しかし、これは例外と言った方が良いでしょう。ほとんどの場合で、攻撃者は巧みな隠ぺい工作を行います。

高いサイバー攻撃スキルを持った攻撃者の隠ぺい工作を見抜くことは、かなり難しいと言えます。攻撃に気付くことができるのは、攻撃者のミスが主要因であることが多いと考えられます。

攻撃に気付くためには、事前にネットワークゲートウェイ、サーバー、エンドポイント端末に多くの攻撃検知の仕組みを準備し、サーバーやネットワーク機器のログなども定期的に調査する必要があります。このような気付くための対策を実施していなければ、攻撃に気付くことすらできない状況に陥ってしまうのです。

インシデントへの初動対応と分析、復旧までのプロセス

攻撃者の侵入などのインシデント発生条件を検知することができれば、その後はあらかじめ準備していたプロセスに沿って対応するだけです。具体的には、「初動対応」することでインシデントの拡散を防ぎ、その上で「インシデントの分析」を行います。

分析のためには、ネットワーク機器のログ収集と共に侵害されている可能性の高いサーバーやエンドポイント端末へのフォレンジック調査（※2）などを実施します。それによって侵害の状況や程度を把握できれば、「復旧作業」に移ることになります。復旧ができれば、インシデントレスポンスという緊急対応のフェーズはおおむね終了したと言えるでしょう。

分析による調査にはそれなりの時間がかかるため、一般的には全体の復旧前に被害拡散の恐れがないシステムを暫定的に（部分的に）復旧させることなども、よくあることです。インシデントへの対応や復旧などは、その企業や組織が許容できるリスクはどこまでかということを複合的に考慮しながら経営判断で実施されます。

復旧までに、組織のステークホルダーに向けたインシデント報告を行います。この報告は、全く状況がつかめないままで実施しても、あまり意味がないものの、社会的な影響が大きな場合は、即座に被害を公表し、判明した事実を追加で都度発表する形式を取ることもあります。

インシデントが発生しても、ステークホルダーへの被害拡大の防止を最優先しながら、迅速な対応ができる企業は、その行動によってむしろポジティブに評価されることも珍しくありません。

（※2）フォレンジック調査とは、 元は法的な調査を行い、証拠を収集し調査することであり、セキュリティの観点では侵害されていることを証明するための記録や痕跡を調査することとして用いられます。

最後に忘れてはならないのが「再発防止策」です。なぜかというと、攻撃者は一度ターゲットにした企業や組織を再び狙うことが少なくないからです。インシデントが発生したシステムは何らかの脆弱性や不具合を持ったものであり、その脆弱性が根本的に解決されていない場合、再度攻撃対象になってしまうのです。

また、被害を受けたということは、すでに攻撃者にとって利益のあるターゲットと認識されていることを証明したようなものです。そのため、攻撃者が当初の目的を達成するため、複数回攻撃してくることも珍しくありません。

だからこそ、インシデントが収まったことに安心せずに、侵害された脆弱性への対応とこれを機に「セキュリティ全体の見直し」を含めた再発防止を検討しておくべきなのです。サイバー攻撃を受け、その攻撃への対応が済んだと判断した企業や組織が、根本的な原因究明やその後の適切な対応を怠ったために、再び被害に遭ってしまうことは、残念ながら一定頻度で発生するという事実があることを忘れてはなりません。

サイバー攻撃の対策をする上で、過去の事例に学ぶことは非常に有益です。これまで示してきたセキュリティインシデントの種類やその原因、一時対応や復旧方法についての具体的な事例を紹介します。

もちろん、以下に述べるインシデントの事例は、非常に残念な被害でした。しかし、被害企業がきちんと情報を公開してくれたおかげで、われわれのサイバー攻撃対策の知見となり、セキュリティが強化され、皆さんの今後の安全につながっていくのです。

今回は、ランサムウェア感染の事例を二つ挙げます。

先に述べたように、一般的なサイバー攻撃は攻撃者が自身の行為を隠蔽するため、その攻撃の理由や経緯などが明確にならない場合が多いです。しかし、ランサムウェア感染を伴うサイバー攻撃（実際には、ランサムウェア感染だけでなく、機密情報の窃取やそれによる脅迫も実施される）は攻撃者が自らサイバー攻撃したことを被害者に伝える数少ない攻撃手法だといわれています。

攻撃者が身代金を要求するという行動および直接的な接点があることから、攻撃者の行動がつかみやすく、被害調査も行いやすいためです。

事例1：半導体製造企業のランサムウェアによる操業停止

2017～2018年頃にかけてWannaCry（WannaCryptor）と呼ばれるランサムウェア感染が世界中に猛威を振るい、150カ国で20万件を超える被害が発生しました。この事例は、その中の一つです。被害企業は、世界的な半導体製造企業であり、生産ラインの操業停止という重大なインシデントとなりました。

2018年8月、その半導体製造企業においてWannaCry感染を受けて3日間の生産停止という被害となった。その被害額は営業利益ベースで最大190億円に達した。攻撃の発端は、WannaCryの亜種に感染したコンピューターの持ち込みから始まる。このコンピューターを制御ネットワークに接続したことで、感染が広がったという。

WannaCryは、自己拡散（バラマキ）型と呼ばれるランサムウェアであり、ネットワークを介して次々と感染を拡大させることが特徴だ。この例でも、持ち込んだコンピューターのたった1台に潜むランサムウェアが、ネットワーク内の別のコンピューターをスキャンしながら、自身のコピーを繰り返した。

感染と同時にコンピューターのデータが次々暗号化したため、制御システムの機能が停止してしまった。この攻撃のステップは以下のとおり。

1. ランサムウェアに感染したコンピューターが制御システムエリアに持ち込まれた
2. 当該コンピューターを制御ネットワークに接続した
3. ランサムウェアがネットワークをスキャンし通信可能な機器にも感染拡大させた
4. 感染した複数のコンピューターはデータの暗号化のために機能停止に陥った

このインシデントの根本的な原因は、ランサムウェアに感染したコンピューターの持ち込み。ただし、報告の内容によるとそれ自体は攻撃意図があったものではなく、内部の関係者かそれに近い人による過失だったようだ。

事例2：グローバルに展開している企業におけるランサムウェア感染

この事例も全世界でランサムウェアの猛威による被害があり、日本国内でも大きな被害の可能性が懸念されていた状況で発生しました。インデントが発生した企業は、多数の海外拠点を有するグローバル企業です。海外支店で社内ネットワークに接続されたコンピューターがランサムウェアに感染したことを発端として、グループ会社全体に感染が拡大してしまった事例です。

ランサムウェアの感染は、公開された既知の脆弱性（OSの脆弱性）に対応していなかったことでシステムに侵入されたことから始まった。攻撃者に悪用された脆弱性は公知のものであり、設定不備などで発生したものではなかった。

被害範囲は、情報システム部門が管理する社内ネットワーク上の業務システムや端末などにとどまらず、工場に設置されていた生産管理システム、入退室管理システムなどにも及んだ。

攻撃の検知は、サーバー監視でのシステム障害を検知したことから始まり、原因調査に当たった運用担当者がランサムウェアの身代金請求画面を確認し、即緊急対策チームが立ち上がった。アンチウィルスソフトでのチェック、機器のログ分析、アンチウィルスソフトベンダーへマルウェア検体を送って解析を依頼するなどをしながら、現状を把握した。また、外部への悪影響がないことから、インターネットの切断はせず、部分的な社内LANの遮断のみの対応となった。

そして、翌日には対策ソリューションの検討と実装が始まり、３日目には感染元の一次特定までが済み、システム全体の詳細調査を開始し、一次特定した部分以外の原因分析も並行して実施された。

これを踏まえて4日目にはメディアに対して公式発表がなされ、6日目までに被害を受けたシステム復旧がおおむね完了する所までこぎ着けることができたという。このインシデントの対応と復旧はお世辞抜きで迅速だったと言っていいだろう。

このインシデントの原因は、OSの脆弱性の悪用だ。従って、パッチの適用が適切になされていれば本事象は、防止できた可能性が高い。また、パッチが適用しにくいIoTのような機器もあり、その部分はリスクとしての検討がなされていないのが問題だったと言える。

そして、ワームによるサイバー攻撃を前提としたネットワーク設計がされていなかったことも被害の範囲を拡大させた。さらに、ディザスタリカバリを想定したオンライン（リアルタイム）バックアップと世代管理されたバックアップがあったが、オンラインバックアップのデータはランサムウェアによって暗号化されており、世代管理されたバックアップのデータからの復旧を行わざるを得なかった。（*2）

上記のようなインシデントを再び発生させないために、リスクの低減策を網羅的に行う必要があります。以下の10項目は、上記の事例を含むサイバー攻撃による被害の要因になりそうな対策をまとめたものです。

［代表的なセキュリティリスク低減策（再発防止策）10項目］

1. 攻撃者が改ざんできないバックアップを作成、迅速なリストアを実行可能化
2. システムが常に最新の状態（パッチ適用済み）であることの確認
3. アンチウィルスソフトの実行などマルウェア対策の実施
4. ファイル共有やリモートデスクトップなどの不要なポートの遮断
5. 不要なレガシープロトコル（マイクロソフトのSBM v1など）の無効化
6. ネットワークのアクセス制御（セグメンテーション他）の実施
7. 物理的な入退館管理の実施
8. 持ち込み機器（主にコンピューター）へのマルウェア対策
9. サプライヤーを含めたセキュリティ要件の設定と徹底
10. 自動的な検疫ができるセキュリティソリューションの導入

上記で提示した二つの事例について、一つ目の原因は持ち込んだコンピューターがランサムウェアに感染していたこと、二つ目はＯＳの脆弱性を突かれたことが直接的な原因でした。

しかし、上記のサイバー攻撃の発端がたまたまそうだっただけと言った方が正しいかもしれません。ランサムウェアの被害に遭いたくなければ、上記に挙げた「代表的なセキュリティリスク低減策」はもちろん、該社特有と思われる状況の考慮や許容できるダウンタイムなどを勘案して対策すべきでしょう。

セキュリティインシデントはさまざまなものがあり、どれも予測はもちろん対策が難しいものが散在していることから、都度対応することは非常に難しいと言えるでしょう。

なぜなら、セキュリティインシデントの発生は、究極的には平常時とは異なる「緊急事態」になったということを示しているだけだからです。対応がそれほど難しくない事象であれば、そもそも緊急事態とはならないはずで、だからこそ平常時とは全く異なる対応が必要な事象であると言えるのです。

セキュリティインシデントは、企業や組織にとって避けられない脅威であるものの、適切な事前準備（対策）を講じることができれば、被害を最小限に抑えることは可能です。それには、技術的対策だけでは対応が難しく、組織体制の整備を含む運用面での対策も必要となります。

また、想定外の新たな脅威が出現する可能性も考慮しなければなりません。それらの情報を収集し、常に最新にアップデートし、対策をブラッシュアップさせることがセキュリティインシデントへの対応には必要です。言い換えると、このサイクルを継続的に実施し続けることこそが、セキュリティインシデントへの対応に最も重要なことなのです。

——関連する当社のソリューション・サービス——

セキュリティコンサルティング

デジタルフォレンジックサービス

ランサムウェア対策ソリューション

■参考■

（*1）「内部不正による情報セキュリティインシデント実態調査」2016年3月3日 IPA 独立行政法人 情報処理推進機構

（*2）サイバー攻撃を受けた組織における対応事例集（実事例における学びと気づきに関する調査研究）2022年4月内閣官房内閣サイバーセキュリティセンター（NISC）