とあるセキュリティチームの2020年 第1回 セキュリティインシデントへの対応
セキュリティチームは、情報漏洩など社内外で発生してしまったインシデントに対して、どのように対応していくべきなのでしょうか。実際の取組みを通して考えてみます。
編集部より
セキュリティ分野やアクセシビリティ分野に詳しい太田 良典さん（弁護士ドットコム所属）に、企業や団体におけるセキュリティチームの役割に関して寄稿いただきました。昨今のさまざまな事故の例も取り上げ、セキュリティインシデントへの対応とはどのようにしていくべきなのかを考えます。
はじめに
弁護士ドットコムの太田です。
個人的な話になりますが、2020年度になって所属が変わりました。2019年度までは「UXデザインチーム」に所属していましたが、2020年の4月に「セキュリティチーム」という部署が新設されることになり、そこに移りました。ユーザビリティやアクセシビリティ関連の活動もこれまで通り続けていますが、社内では情報セキュリティ関連の業務が相対的に増えています。
ここ数年、CodeGridには一年のアクセシビリティを振り返る記事を寄稿していましたが、今年は少し趣向を変えて、セキュリティチームとしての一年を振り返ってみたいと思います。
これまでの記事
セキュリティチームのミッション、インシデントレスポンス
セキュリティチームの大きなミッションの一つが、セキュリティインシデントへの対応です。
インシデント（incident）は「事象」というような意味ですが、ここでは「事故」という言葉の範囲を広げたものと考えてください。外部から攻撃を受けて情報が漏洩した、というケースは明確に事故であり、これは当然インシデントでもあります。
中には、事故かどうか判断が難しいものもあります。たとえば、攻撃を受けたものの、防御できており被害がなかったケースはよくあります。また、システムに脆弱性があって攻撃が可能であると指摘されたものの、実際に攻撃されてはいない、というようなケースもあります。これらは一般に事故とは言いませんが、インシデントにはこういったものも含みます。
外部からの攻撃に限らず、社内のミスによるものもインシデントになります。典型例はメールの誤送信です。特に、個人情報を含むメールを誤送信した場合、明確に事故という扱いになり、状況によっては個人情報保護委員会への報告義務も生じます。
このように、インシデントは社内外で頻繁に発生します。インシデントへ対応することを「インシデントレスポンス」と言います。インシデントレスポンスには技術的な対応だけでなく、社内調整も必要になりますし、状況によっては顧客や監督省庁への対応、マスコミ対応まで必要になることがあります。単一の部署だけでは対応しきれないため、多くの企業では部署横断的なインシデントレスポンスチームを編成しています。筆者の所属する弁護士ドットコムでもインシデントレスポンスチームを組織しており、情報システムセキュリティ委員会と称しています。セキュリティチームのメンバーは全員参加しており、それに他部署の担当者を加えた編成です。
インシデントの報告を受けたら、まずはその内容を暫定的に分析し、重大性や緊急性を評価します。その結果、重大性が高く、緊急対応が必要と判断された場合は「重大インシデント」と認定します。このように、インシデントの重大性を評価して分類することを「トリアージ」と呼んでいます。
重大インシデントが発生した場合、即座に関係者を招集して対応チームを編成し、最優先で対応に当たることになります。幸か不幸か、重大インシデントは滅多に発生しません。
トリアージの結果、インシデントが重大でないと判断した場合は、軽微なインシデントと分類します。便宜上「軽微」と呼んでいるものの、実際には無視して良いものばかりではありません。また、後から重大性が明らかになって重大インシデントに昇格するということもあり得ます。
定型的なインシデントの扱い
軽微なインシデントの中にも、定型的なもの、つまり「よくある」パターンが存在します（本当はよくあってもらっては困るのですが）。典型例は、メール誤送信や端末の紛失といった不注意によるものです。以下、メールの誤送信があった場合を例に、取り扱いのフローを少し紹介してみます。
時期と対象の確認
メール誤送信をしてしまった際は、報告をする必要があります。インシデントの報告を受けた側では、まず以下のような点を確認します。
- いつ発生したか
- 具体的にどのような情報が漏洩したか（あるいは漏洩リスクがあったか）
- その情報が誰に渡ったか
これらの情報がないと、どのような情報が誰に渡ったのか判断することができません。要するに「いつ」「何が」「誰に」漏洩したかという基本的な話なのですが、意外に報告から漏れていることがあります。たとえば、メール誤送信の報告の際、メールの本文にどんなことが書いてあったか言及がないケースがしばしばあります。メール漏洩時の最大のポイントは本文であり、本文に何が書かれていたか、個人に関する情報が含まれていたか、といった点が重要になります。
エンジニアの方なら、エラー報告を受けた際に「エラーが起きる」とだけ言われ、肝心のエラーメッセージが何も書かれていないという経験をしたことがあるはずです。インシデント報告でも、それと似たようなことが起きるわけですね。
報告者も不慣れでしょうから（慣れてもらっても困りますが）、報告には過不足があって当然です。そのような場合、報告者にヒアリングして、必要な情報を聞き取るようにします。
業務影響有無の判断と対応
さて、どの情報が誰に渡ったかを確認できたら、業務への影響の有無を検討します。
- 当社の業務にどのような影響が出るか
- 影響が社外に及んだか、及んだ場合どのような影響が出るか
難しい書き方をしていますが、どういう被害があるかという話です。影響が社外に及んだ場合、謝罪や説明などのアクションが必要になります。注意が必要なのは、一見、事故に直接関与しないように見える人にも影響があり得るということです。たとえば、Aさん宛てにメールを送ったが、本当はBさん宛てだったという誤送信の場合、Bさんは何も受け取っておらず、事故そのものに気づいていない可能性が高いでしょう。しかし、この場合の最大の被害者はBさんなのです。
影響を検討したら、対応を検討したり指示したりします。メール誤送信は定型的なインシデントですので、事故報告書の雛形も用意してありますし、関係者への謝罪など、ある程度やることも決まっていますから、漏れがないように指示を出します。そうでない不定形のインシデントの場合は、対応を定型化できないので、対応をその都度検討する必要があります。
再発防止策
最後に、再発防止策をチェックします。
- どのように再発防止を行うか
- 再発防止策は機能するものか、現実的に実行できるものか
- 再発防止策が機能したかどうかをいつどのように確認するか
再発防止策は意外と難しいものです。当然ですが、「担当者にいっそう注意させる」のようなものは再発防止策として認められません。組織として、システムとして対応できる内容にする必要があります。関係者の発案した再発防止策は有効でなかったり、実施に無理がある場合もあります。施策が有効でも、膨大なコストがかかるようなものは見合わないことになりますので、いろいろな視点で視点でチェックするようにしています。
再発防止策は作りっぱなしではなく、時間が経ってから振り返りをすることも必要です。有効に思えても、実際やってみたら効果がなかったということがあり得るからです。実際のところ、この振り返りがあまり徹底できていないことがあり、現在の悩みのタネになっています。
ソフトウェア利用申請とインシデント対応
メール誤送信は事故に近い例でしたが、インシデントの中には、事故に至らないものもあります。言い方を変えると、事故に至らないものでも、対応しなければならないケースがあるということです。
ソフトウェアの脆弱性への対応
事故に至らないインシデントの典型例は、脆弱性の情報を認知した場合です。脆弱性とは、情報セキュリティ上の侵害に繋がる可能性のある問題点のことで、多くはソフトウェアのバグや、仕様の欠陥によるものです。JPCERT/CC*が出している情報を見ても、その多くが脆弱性に関する情報であることがわかります。
*注：JPCERT/CC
JPCERTコーディネーションセンター（JPCERT/CC）はコンピュータセキュリティインシデントについて、日本国内に関するものの報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討や助言などを、技術的な立場から行っている、非営利団体です。
見慣れない製品の名前も多いと思いますが、Adobe Flash PlayerやWordPressなど、Webに携わる方にはおなじみの製品にも脆弱性が報告されています。Flashは今さら感がありますが、WordPressは現役で使っているという方も多いでしょう。
このように、ソフトウェアには、しばしば脆弱性が報告されます。脆弱性を放置すると、不正アクセスやウィルス感染の原因となる可能性があるため、無視することはできません。社内で利用しているソフトウェアの脆弱性情報が出た場合、内容を確認して、社内告知をしたり、アップデートを要請したりといった対応を行います。
ソフトウェア利用申請の許可判断
脆弱性情報への対応を行うためには、社内でどんなソフトウェアが利用されているのか、事前に把握しておく必要があります。そのため、弁護士ドットコムでは、社内で新たにソフトウェアを利用する際には申請をしてもらうルールにしています。申請内容を審査した上で、許可したものは台帳に登録して把握できるようにしています。
利用申請を行う理由は、ほかにもあります。ソフトウェアの中には、無断で情報を社外に送信するようなものもあります（アドウェア、マルウェア）。そのようなソフトウェアは情報漏洩を起こす可能性があるため、利用を許可するわけにはいきません。申請時の審査によって、導入にリスクがあるようなソフトウェアを排除しているのです。
ソフトウェアのリスク判断は難しいのですが、主に以下のような点をチェックしています。
- 既存のソフトウェアで賄えないか
- ベンダーによってメンテナンスされているか
- ポリシーが明確かどうか
まず、既存のソフトウェアで賄えないかどうかを確認します。これは単純に、管理するソフトウェアをできるだけ増やしたくないためです。この判断は厳格なものではなく、「既存のものは使いにくい」「新しいものを試したい」といった理由でも許可するようにしています。「既存のものがあることを知らなかった」「既存のものでできることを知らなかった」という場合のみNGとします。
次に、ソフトウェアのベンダーを確認し、開発元のサイトなどをチェックしてサポート状況を確認します。誰が制作したのか不明なものは許可しません。個人制作の場合やOSS（オープンソースソフトウェア）の場合は、GitHubのリポジトリを見て最終コミットやstar、forkの数をチェックすることもあります。メンテナンスされていないもの、メンテナンス終了が告知されているものは許可しませんし、ほとんど人の目に触れられていないものは許可しないことがあります。
そして、プライバシーポリシー、セキュリティポリシーを確認します。出自がある程度しっかりしていても、情報を無断で外部に提供する可能性があるものは許可できません。有名なベンダーのソフトウェアであっても、ここはしっかりとチェックする必要があります。なぜなら、過去に有名なソフトウェアがプライバシーの問題を起こしたケースが多数あるからです。
たとえば、2018年には、トレンドマイクロ社のウィルスバスターがプライバシーの問題を指摘され、AppStoreでの公開を停止されるという事件が起きました。この際には、ユーザーに無断でブラウザの履歴を外部に送信していることが問題視されました。
このように、名のある企業が問題のあるソフトウェアを提供するケースもあるため、ポリシーはしっかり確認します。以下のような観点でチェックを行います。
- どのような情報を扱うことになるのか、その情報の機密性はどの程度か
- その情報がどのように扱われる可能性があるか
プライパシーポリシーが掲げられていても、肝心な情報の扱いが書かれていないことがあるため注意が必要です。
最近申請があった例では、カレンダーと連携してスケジュールを調整するアプリがありました。このとき重要になる情報は、カレンダーに入力したスケジュールそのものです。スケジュールのタイトルやメモには、社内の情報や取引先の情報、顧客から預かった情報を記載することがあります。これが漏洩したり、第三者に渡されたりすると大きな問題になりますので、その扱いを確認しなければなりません。
しかし、そのアプリ側のポリシーを見ると、カレンダー情報の扱いに一切言及がなく、利用者が問い合わせを行った際の氏名やメールアドレスの扱いだけが書かれていました。企業で利用する場合、利用者の氏名やメールアドレスは、そこまで機密性が高いものではありません。これはもとより名刺に記載して配っている情報です。それよりも、業務上の秘密情報や、顧客から預かった情報のほうがはるかに重要なのです。このように、保護すべき重要な情報は何か、という基本的な認識がずれている場合がありますので、ポリシーは注意深く確認します。
余談ですが、プライバシーポリシーを真面目に読んでいると、誤字やコピペミスなどの明確な誤りを見つけることもしばしばあります。提供している側はあまりチェックしていないものなのかもしれません。しかし、こちらは容赦なくポリシーを読んで判断し、不許可の意見を出します。みなさんがポリシーを出す側になったときは、真剣に読む人もいること、その結果として採用見送りになる場合があることを心に留めておいてください。
SaaSサービスの利用許可と事故対応
近年では、SaaSの形式で提供され、Webブラウザのみで利用できるサービスも増えました。弁護士ドットコムでは、SaaSサービスもソフトウェアと同様に扱っています。つまり、ソフトウェア利用申請をして、許可を得てから利用する必要があります。
SaaSサービスの場合、脆弱性情報を追う必要はありません。脆弱性の修正やソフトウェアのアップデートが運営側の責任で行われるため、利用者の側で対応を行う必要がないのです。この点は管理が楽なところではあります。
ただし、これは「SaaSなら脆弱性への対応が必要ない」という意味ではありません。SaaSの場合、脆弱性への対応が運営側の責任になるというだけで、対応そのものが不要になるわけではないのです。運営側が適切な対応をしないと、むしろリスクが高まることもあります。実際、Webサービスが情報漏洩などの事故を起こしたケースでは、脆弱性への対応が適切でなかったと見られるケースも散見されます。
そのため、SaaSサービスの利用時には、セキュリティリスクに対応する運営側の体制について、よりいっそうの注意が必要になります。
SaaSサービスの事故時の対応
選定時に注意していても、SaaSサービスが事故を起こしてしまうことはあります。また、そもそも許可していないはずのサービスが密かに利用されていて、そのサービスが事故を起こすというケースもあります。ファイルのやりとりに利用できるストレージサービス「宅ふぁいる便」が2019年に事故を起こしたことは記憶に新しいでしょう。
このような有名サービスが事故を起こした際は、「もしかして、社内に利用者がいるのでは?」と疑ってかかるようにしています。実際、「宅ふぁいる便」は許可していなかったのですが、調査したところ、一部で外部ライターとのやりとりに使われていたことが判明しました。
もちろん、普通に許可したサービスが事故を起こすこともあります。つい最近、2020年11月にイベント告知・集客サービスの「Peatix」が事故を起こしましたが、これは社内で認められた上で利用されていました。
もうひとつ、2020年の事件で大きな影響があったのが、記事・メディア投稿サービス「note」の情報漏洩事故です。
SaaSサービスを利用している場合、サービスに様々な情報を預けているはずです。事故が起きた場合、情報が漏洩したり、サービスを悪用されたりする危険があるかもしれません。そのため、SaaSサービスが事故を起こした場合にも、インシデントとして対応を行なっていく必要があります。
ここまでのまとめ
セキュリティーチームの役割とその活動について、筆者の経験を元に紹介しました。次回はSaaSサービス事故時の対応について、実際の事例を見ながら紹介していきます。