今すべきことは何だろう？

Japan Security Team

/ By Japan Security Team / June 11, 2015 / 15 min read

6 月に入って、立て続けに深刻なセキュリティ侵害が明らかになり、大きな社会的な問題となっています。事件について興味深いディスカッションが行われていますが、サイバー攻撃を受けることは、もはや特別なことではありません。事件を自らの組織の今後に役立てていくことが重要だと考えています。このような視点から、自社や自組織が、今確認をすべき内容についての考察しました。

マルウエアの活動から見る日本の状況

カスペルスキー・ラボ社の、「侵入されているのは日本年金機構だけではない」、との発表が話題を呼んでいます[1]。一見すると煽っている内容にも思えますが、筆者は、想像以上に深刻になっている、日本の実状の一端を伝えた発表だと考えています。

今年の２月に品川オフィスに開設した、サイバークライムセンターサテライトー日本サテライトでは、ボット（ウィルスの一種）に感染した PC 等の活動を観測しています。このデータによると、日本におけるボットの感染数は相当数にのぼり、長期間にわたって活動をしていることが確認できます。検知・駆除が可能な既知のボットでさえ活動が続いている状況を考えると、標的を絞った、意図性の高い攻撃が成功する可能性は、きわめて高いと考えるのが自然です。また、侵入から発見までは長い時間がかかっている場合が多い[2]ことも考えると、どのネットワークでも、既に侵入を受けている可能性を前提とした方が合理的に思えます。

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/20/CCC-JP1.png)

図 1 サイバークライムセンターサテライトー日本サテライト:日本におけるボットの活動状況

また、今回話題になっている事件に限らず、セキュリティ侵害に対して「悪いのは犯人」であり、攻撃を受けた組織は「被害者」という主張を目にすることも少なくありません。一般論として「誰が悪いのか」を考えることも重要な作業ですが、主語が抜けた議論に終始しているようにも思えます。

いずれにしても、事件が明らかになったときには、既に何らかの被害が出ているので、「誰が悪いか」の議論の前に「事件の当事者」としての視点・責務を最優先すべきだと考えています。

自分の組織に事故が起きたと仮定しよう

事件が起きると、事件の当事者の対応に注目が集まりますが、私たちが、その組織を何らかの形で正すことは難しいように思います。これに対して、自らが所属する企業や組織が、同様の事件の当事者になったと仮定し、当然の対策であると指摘されている項目を、確実に実施できるかを確認することは、有意義であると思います。

たとえば、これらの項目に対して、適切な対応ができそうでしょうか？

ネットワークを遮断する・しないの判断
ネットワークが止まれば本来業務に支障があり、収益に影響を与えるばかりではなく、顧客へのサポートや、売上の計上、支払いなど、広範囲な問題に波及します。
誰が、どのような手順で、何を根拠に判断をし、実施するのか、影響を最小限にとどめるためには何をすればよいかなどを明確にする必要があり、相当に難しい課題であることは、間違いありません。
遠隔地を含めて指示が実施されるまでの時間
実施に必要な時間についても考慮する必要がります。疑わしい通信の連絡から、ネットワークからの切断まで３時間では遅いという指摘もあります。どの程度の時間であれば、合理的なのかをあらかじめ考えておく必要があります。
夜間や休日の対応
上記項目について、営業時間内だけではなく、深夜や休日にも実施できるかを確認する必要があります。年末年始やお盆などの長期休暇のタイミングも考慮してください。
事件はなぜか休日前の夕方以降に発生する場合が多く、判断すべき役職者が捕まりにくい事も少なくありません。
報告の流れ
判断と実施だけではなく、報告の流れも確認してください。営業部門や、総務部門、経理部門なども、報告が必要かもしれません。想定外の影響、顧客とのコンタクト、電話窓口を設けるための費用、従業員の時間外労働など、事案を具体化して考えると、必要な報告先を体系化しやすいように思います。

悔いを残さないために、今すべきことは何だろう？

事件の当事者として考えると、再発防止策の立案も必要になります。「今、攻撃が明らかになったとしたら、どんな再発防止策を立案するか」という視点で考えると、現状の対策で欠けている事がらを明らかにし、これから実施する対策の優先順位が明確にすることができると思います。

典型的な対策項目としては、以下のようなものを上げることができます。

対応手順の確認
前述した内容ですが、インシデントが発生した際の手順を確認し、対応すべき人がこれを理解する必要があります。訓練やシミュレーションができれば、さらに効果的です。
機密情報の保護状況の確認
機密情報に対して、アクセス権や暗号による保護が適切に実施されていることを実査します。場合によっては、実査の前に「機密情報」の定義を確認した方が良いかもしれません。
機密情報の保護にドキュメントのパスワード機能を使っている場合は、他の技術に置き換を検討して下さい。ドキュメントのパスワードでは、十分な機密保護とは考えにくいため、技術的な担保（保証）ができる手法を採用すべきだと考えています。
ホストレベルのセキュリティ対策の確認
「耳にタコ」だとは思いますが、セキュリティ更新プログラム等アップデーターの適用状況や、セキュリティソフトの更新状況を確認する必要があります。アプリケーションなどについても確認が必要です。また、単に指示するだけではなく、何らかの方法で実査を行うことが重要になります。
加えて、アカウントの権限も確認してください。Administrator など、特に権限の高いアカウントやグループに注意し、最小権限の原則に基づいて権限を付与してください。
役職に基づいて権限を付与する場合もありますが、実際にオペレーションを行わない人に、高い権限を付与するのは百害あって一利なしだと思います。
ログの確認
まずは、必要なログがきちんと取られていて、管理されていることを確認します。ログの入手に時間がかかる（例えば一週間など）こともあるので、この点も確認します。
その上で、大変な作業と覚悟して、ログから疑わしいものを見つけていきます。筆者の経験では、なにがしかの疑わしい記録は、必ず残っています（侵入の痕跡とは限らない）。
megrep ができる人以外は、何らかの機械的な処理を併用したほうが良いでしょう。
企業経営・組織運営への影響の分析
自社が保有する情報の、どの情報が、企業運営、組織運営への影響が大きいのかを分析します。IT 部門だけでは判断できないので、経営部門や、事業責任者と一緒に分析をする必要があります。過去の事件が参考になりますが、組織には固有条件があります。日常的に使っている情報やデータが、思わぬ影響を与える可能性も考慮します。