情報セキュリティ事故対応の優先順位～情報セキュリティは経営課題～

今年の2月中旬に産業技術総合研究所（産総研）の研究所内ネットワークに「サイバー攻撃」があり情報漏洩の被害があったというセキュリティ事故がありました。その対応として産総研は、一時的に研究所内ネットワークをインターネットの接続を切断したのですが、1ヶ月たってもインターネットとの接続は切断されたままという状況です。

そのため、産総研においては外部との電子メールのやり取りに支障があり、産総研が行っている研究活動にも支障が出ている、という記事がありました。また、インターネット接続が切断されたままの理由が、漏洩被害の範囲が確定できていないのでは？とか、サイバー攻撃の原因・経緯が解析できていないのでは？との推測もあります。

このようにサイバー攻撃によるセキュリティ事故が、組織の業務に大きな影響を与えることもあるわけなので、今回はセキュリティ事故の対応において何を優先すべきか？ということについて考えてみます。

事故対応では事故の状況把握と被害の拡大防止が最優先

セキュリティ事故が発生した場合、まずは事故による被害の拡大防止が最優先事項になります。事故が発生しているということは、大なり小なり事故による被害が発生している状況です。

被害の状況は事故の種類や各社の業務、システム、ネットワークがどうなっているか？などによって大きさ・内容は変わりますが、被害の拡大防止、つまり被害範囲の限定（封じ込め）を行うことが最優先になります。そうしないと、被害がえんえんと拡大した場合にその後の対応に大きな支障を来すことになってしまうのです。

ただ、被害の拡大防止のためには、どんな事故が起こっているのか？例えば、マルウェアへの感染、Webサーバの改竄、情報の漏洩といった、「セキュリティ事故の種別・状況として何が起こっているか？」ということを被害の拡大防止を検討する前に明らかにしておく必要が先にあります。

では、被害の拡大防止の次にやらなくてはいけないことは何でしょうか？実は、被害の拡大防止の次にやるべき事ですが、3つの観点があります。

観点1　原因究明および再発防止

観点の一つ目は原因の究明（分析）と再発の防止になります。

① 攻撃者は誰か？

分かりやすくいうと「犯人探し」ですね。情報セキュリティ的には正確には「攻撃者」というよりも「脅威（Threat）」という方がいいかもしれませんが、意図的か意図的でないかに関わらず、事故を引き起こすトリガーとなった人・モノ・事象が何であるのか？です。

例えば、「外部のXXX.XXX.XXX.XXXのIPアドレスからの攻撃」、「○○というマルウェア」、「IDがxxxxの利用者」等を明らかにします。

② どこを突かれたのか？

いわゆる「脆弱性」もしくは「セキュリティホール」です。実際の攻撃（攻撃者/脅威）がどの脆弱性を攻撃して、事故に繋がったのか？を分析します。

この場合の脆弱性は、ソフトウェアやアプリケーションの脆弱性のみならず、情報セキュリティや業務の運用（利用者側の手続きなんかも含む）における脆弱性、人・組織体制における脆弱性まで考慮する必要があります。

③ 攻撃の手法は？

攻撃者が実際に行った、攻撃の経路、攻撃の手法、実際に事故に繋がったシステムや運用上の経緯等を含めて分析を行います。「外部から○○サーバの脆弱性を突かれた」、「○○の設定ミスにより、不正アクセスされる状況になっていた」、「管理アカウントの不正利用によりXXサーバから情報が漏洩した」とかいったような、実際に使われた攻撃のシナリオを明らかにしていきます。

④再発防止策

事故が再発しないために何をすべきか？例えば「マルウェア感染」であれば「感染したマルウェアに対応したワクチンの導入」とか「対応するパッチの適用」等の話です。

ただし、実際には、事故の種類によっては再発防止策自体が存在しないものがあったりします。

このような形で、事故に対して「なぜ起こったのか？」「再発させないために、何が必要か？」ということを明確にしていきます。

観点2　被害解析・回復

観点の二つ目は、どのような被害が起こったのか？また、それをどのように回復するのか？を明らかにする観点です。

まず、被害解析ですが、例えば、情報漏洩であれば「どの情報が漏れたのか？何件漏れたのか？」というレベルの被害があり、さらに「当該の情報漏洩により業務や組織にどのような影響があるのか？」「顧客や取引先等の組織外部への被害はあるのか？」というレベルの被害に別れます。このように、被害を考える場合には、システム的/セキュリティ的な観点以外に、業務的・組織的な観点での被害を分析・推定する必要があります。

また、発生した被害を回復可能なのか？回復可能であるなら、どのように回復するのか？を考える必要があります。例えば、個人情報漏洩のような事故の場合には被害者への補償といったこと、データの改竄といったことであれば元データへの復旧といったことがこれに当たります。

観点3　サービス継続・復旧（事業継続）

観点の三つ目は、情報セキュリティ事故が発生した場合に、組織として実施している業務や提供しているサービスの継続の必要性がどの程度か？という観点です。

例えば、金融機関の場合、顧客や取引先の資金移動（入金、振込/送金）といった業務は顧客保護という観点で最優先で継続する業務として扱われており、事故が原因でシステムで銀行間での送金処理ができない、という場合には、実際に現金を送金先の銀行の窓口に持ち込む、ということをする場合もあり、システムによっては事故が発生したシステムを止めると業務的な影響が大きい場合、どの程度の時間システムを止めることが可能か？ということを考える必要があったりします。

これが、組織の基幹業務に関係のない「会社のWebサイトの会社案内のページが改竄された」というような事故の場合、組織によっては「3ヶ月くらいならそのページ見えなくてもいいよ」という判断が下される場合もあり、この場合組織としての業務継続（会社存続）に「ほぼ影響ない」という場合もあります。

また、システムが利用不可能となっても、システム的に、もしくは業務的に代替手段があり、そちらでの業務継続が可能という場合もあります。

事業継続管理/事業継続計画をきちんとやっている組織であれば、そのあたりについては整理されている場合もあります。

組織によって優先すべきことが異なる

さて、この3つの観点のうち、どの観点を優先すべきか？ということですが、組織によって変わります。

観点3で説明もしている感じもありますが、どの組織のどのシステムで事故が発生したかによって、優先的に対応することは変わります。

発生した事故がサービス継続にほとんど影響がないのであれば、観点1、観点2を優先する場合もあるでしょうし、事故の状況・対応の状況によっては原因究明は後回しにして事業継続を優先する場合もあります。

また、顧客個人情報漏洩といった事故の場合、「何件、何の情報が漏洩したのか？」を優先的に確認する必要がある場合もあります。

したがって、事故対応においては何を優先して取り組むかを、事故対応にあたっている現場の人間よりも、その組織で権限・責任をもった人間が何を行うかの優先順位を組織全体の視点から決める必要があるのです。その意味で、セキュリティ事故対応は経営陣が関わる必要がある事項であり、この切り口でいうと「情報セキュリティは経営課題」になるのです。