経営層や他部門とのコミュニケーションを工夫し、自社のセキュリティ事故へ対応 - ソフトバンク・テクノロジー 辻 伸弘氏 「伝える」のでなく「伝わる」ように、相手の立場で説明を
IT・情報セキュリティ
目次
昨今、企業不祥事が相次ぐなか、発覚後の対応方法が企業への評価を左右するケースが少なくない。有事の際の事後対応としては、正確な情報を適切なタイミングで発信することが重要だが、そのためには部署を超えた社内での協力体制が必要となる。
本稿では、セキュリティリサーチャーとして活動し、自身の所属する会社が2017年に不正アクセスの被害を受けた経験をもつソフトバンク・テクノロジー株式会社の辻 伸弘氏に、インシデント発生時の対応策や事前にとるべき準備の方法、および他部門と協力関係を築くために意識すべきことについて伺った。
セキュリティリサーチャーとして情報を仕入れ、エバンジェリストとして自ら発信
辻さんの普段のお仕事を教えてください。
前職ではコンピューターに攻撃を行い穴があるかどうかを調べるセキュリティ診断と、その結果から問題点への対応の優先順位を決め、直す方法を教える仕事をしていました。またエバンジェリストとして、対外的な発信活動も行っていました。弊社には特に後者の経験を生かしてほしいと言われ、入社しています。
弊社へ入社するタイミングで扱う業務を変えたいと思い、エバンジェリストとしての活動とともに、自ら攻撃手法を調べるリサーチャーという仕事をはじめました。
いまはリサーチャーとエバンジェリストの仕事はどのような割合で行われているのでしょうか。
私の中では1つの仕事ですね。リサーチャーとして情報を仕入れ、それを加工してエバンジェリストとしてどう発信するかを考える仕事だと思っています。猟師と料理人を一緒にやっている感じです。サイバー攻撃の攻撃者にコンタクトするなど一次情報にあたって調べた内容をもとに資料を作り、講演しています。
プリンシパルセキュリティリサーチャー 辻 伸弘氏
事故の当事者を責めるのではなく、事故が起こり得た環境を見直す
2017年7月に「不正アクセスによる情報流出の可能性に関するお知らせとお詫び」 1 を公表されました。インシデントの概要と発覚の経緯を教えてください。
弊社のネットワーク内において、一部のコンピュータでマルウェア(仮想通貨採掘プログラム)が実行され、検証サーバーが不正アクセスを受けていたということがわかりました。
攻撃者が不正アクセスできる状況が生じてしまった理由としては、そのサーバーがインターネットに接続されているにも関わらず、不要なアカウントが存在し、そのアカウントのパスワードが脆弱であり、かつ外部アクセス対策が適切ではなかったことがあげられます。
また一番大きな問題だったのは、取引先情報を含んだ本番データを検証に用いていたことです。そのデータの管理が不十分だったことから、情報流出の可能性に発展しました。
事故の発覚からは、どのように社内へ情報が伝えられたのですか。
現場の担当部署から規定に沿って経営層に報告が上がり、必要な人間が呼ばれました。私に声がかかったのは発覚から3日後です。不正アクセスの痕跡があり、サーバー内に取引先情報が入っていたことがわかったタイミングでした。外出中に電話があり社に戻ると、営業をはじめ必要最低限の関係者が集められ、神妙な面持ちで待っていました。
そこではまず共通認識を持つための情報共有がはじまりかけたのですが、私は「少し待ってください」と制止しました。そして事故の原因となったサーバーのアカウントを放置していた担当者とその上司に手を挙げるよう頼んだのです。
この時、名乗り出てもらったのは、糾弾するためではありません。私は当事者に「大丈夫だ」と伝えたかったのです。彼らが責任を感じて思い詰め、気を病むことは防がなければなりません。
また調査を進めるなかで、一番協力をしてもらわなければいけないのも彼らです。はじめに責めてしまうと、少しでも責任を逃れるために事実を過小評価するような表現を用いる証言をしたり、新たな情報に気づいても教えてくれなくなったりしてしまうでしょう。そのため、みんながいま集まっているのは会社として何とかしなければいけないからであり、「『おまえのせいで休日出勤や残業が増えた』『こんなことをした者は評価を下げる!』などと咎められるような組織なのであれば、この会社はそれまでなので、すべてが終わったらみんなで転職でもしましょう(笑)」と話しました。
こうした発言は、当事者だけでなく、周りの人たちに聞かせる意図もありました。たまたま今回の件はこの人たちが発端となったけれども、次の事故はここにいる違う人が起こすかもしれないのだとわかってほしかったのです。
当事者が問題なのではなく、事故が起こり得た環境が問題だったということですね。
たとえばウイルスが来たメールを開くのは必ず特定のAさんだというわけではありませんよね。バタバタしていたらBさんが開くかもしれません。あくまで事故が起こり得た組織の問題だということを伝えました。
経営トップに背中を押され、セキュリティ被害に遭った会社の参考となるようなリリースを作成
それからの状況の整理はスムーズに進んだのでしょうか。
いえ、探り探り進みましたね。初めてインシデントを経験する出席者は、問題の大きさや影響の範囲などがよくわかりません。その場では聞き取りとブリーフィングのみを行い、改めて経営層が参加する会議体をつくって、事故の経緯報告と対応方針の話し合いを行いました。
情報流出の痕跡は確認されていない、という段階から非常に詳細な情報を公表されていたのが印象的だったのですが、経営層の方とはどのようなコミュニケーションを取りましたか。
経営者は判断に足る情報だけを求めており、技術面の話のような詳しい情報はあまり必要としません。問題のレベルや、わかっていること、いないことを、広報担当者と一緒にまとめ、報告しました。
私は毎年、セキュリティ事故を起こした企業のなかで事後の対応がよかったところを表彰するイベントに参加しているのですが、弊社のトップである阿多(編集部注:阿多 親市氏)からは「君がこの事故を講演で話し、世の中に共有できるぐらいの情報を出すように動いてくれ」と声をかけられました。それからはできるかぎり早く、多くの情報を都度出すことや、対応を終わらせる期限などを決めました。この時の判断がなければ、ここまで詳しいレポートは出さなかったと思います。
リリースではマルウェアが仮想通貨採掘プログラムであることも明らかにしています。セキュリティ事故が発生しても、どんなマルウエアだったのかまでは公表しないことが多いですよね。
事故対応のリリース文を見て「この情報が公表されていたのがよかった」などと表彰してきた中で培ったノウハウを生かしました。過去に見た良いリリース文を踏襲して、自分たちが他社に参考にされるぐらいのリリースを出したいと考えていました。
貴社が詳しく情報公開されたのは、セキュリティサービスを提供している会社だという理由もあるかと思いますが、他の業種の企業でもセキュリティ事故が発生した際は情報を公表すべきだと考えますか。
何のために公表するかによりますね。漏えいした情報に個人情報が含まれていた場合は、個人情報保護委員会への報告が努力義務とされていますので公表すべきでしょう。一方、法律に照らして問題がないからといって、何もしなくてもいいわけではないと思います。経験したセキュリティ事故について公表しないのは、同様の被害に遭うかもしれない人たちを見放すのと同じことのように感じますので、私としては社会貢献として公表してほしいですね。その公表を見た人たちも非難するだけではなく、きちんと背景や経緯も含めて受け止めてあげてほしいです。
起きたことの表層だけを見て批判するのではなく、自分であればどうするかを考えるべきだということですね。
次に漏れるのは自社の情報かもしれませんからね。他社で起きたセキュリティ事故は、あくまで味方が負傷しただけです。敵は攻撃者なのです。そうした見方をもう少し広めていきたいと思っています。そのためにも、不正アクセス被害に遭った会社の参考となるよう、広報担当者と協力してリリース文の体裁や内容を一緒に考え、まとめました。
辻さんが出したかった情報のうち、広報部門によりNGとなったものはあったのでしょうか。
なかったですね。対応のスタート時点で部門間の共通認識が持てており、上役が方針を推してくれたことがその理由だと思います。最初に方針が決まったことが、詳細な情報を公表できた理由のすべてだったのかもしれません。
また情報をたくさん発信したのには、もう一つ理由がありました。何か隠しているのではないかと疑われる部分があると、記者が取材に来てしまいます。来るのは構わないのですが、まずはお客さまへの対応が第一ですし、記者の疑いを晴らすことだけに注力するわけにはいきません。質問を受けても「リリースを見ていただけますか」と答えれば済ませられることを、もっと言えば質問が来ないくらいに情報をまとめたリリースを出すことを考えていました。
一方で、リリース文の表現には注意しました。いまも記憶に残っているのは「弊社の保持する検証サーバー(保守契約管理システムの検証サーバー、以下 当該サーバー)」とした箇所です。最初は「以下 検証サーバー」でしたが、検証サーバーという表現が何回も出てくると、「検証サーバーはテストをするものなので、セキュリティが甘くても許してほしい」という感じが出てしまうのではないかと思ったのです。しかし、中身は検証用のテストデータではありませんでしたし、過小評価しているように映る可能性があると思ったため、「以下 当該サーバー」に表現を変更しました。
「弊社の保持する検証サーバー(保守契約管理システムの検証サーバー、以下 当該サーバー)」という表現が用いられている。
もちろん当初の文面も事故を軽視する意図はありませんでしたが、一番大事なのはどう受け取られるかです。まずはインシデントが事実だと伝えることと、謝るところからスタートすべきだと考えました。「お知らせとお詫び」であって、弁明ではありませんから。「こう対策していた」というのも後から言えばいい話です。
クライアントには、会社としてどのように対応しましたか。
営業活動を止め、すべてのお客さまに営業担当者が訪問または電話で説明しました。想定問答や情報をまとめた資料を作り、そこにないことを質問された時のための管理表も用意しました。
まずすべきは情報の統制です。情報が間違って伝わることで、余計な混乱や不安を生みたくありませんでしたので、必要な関係者や対応に関わる営業担当者に絞って事前に対応方針を知らせ、わからないことがあれば後日回答するようにしました。その甲斐もあってか、質問管理表を見るかぎりは激怒されるお客さまはいらっしゃいませんでしたし、「きちんと知らせていただき、ありがとうございます」とおっしゃってくださったお客様もいました。
インシデントが起こる前に、自社のウィークポイントを把握する
組織としてはインシデントにどう備えておくべきでしょうか。
組織立って対応する場合、連絡マニュアルは最低限用意しておくべきです。問題が起きた際の伝達先や、各領域の責任者などがわからなければ、時間だけが経ってしまいます。
加えて、自分たちではできること、できないことを整理しておいてもらえたらと思います。インシデントが起きた際、社内で対処できるものは自分たちで対応すればよく、そうでないものは別の組織に対応をお願いすればいいのです。そうした整理、準備は大切です。あとは有事を想定して、どんなログが取れているかも再確認してほしいですね。通信を遮断する必要が生じた際に業務を可能なかぎり継続するために、最低限どの通信を許可すれば業務をある程度止めず、安全を継続できるのかということを把握して、有事の際のルールを作っておくことも推奨します。
社内の状況整理には、経済産業省が出している「サイバーセキュリティ経営ガイドライン」の「付録C インシデント発生時に組織内で整理しておくべき事項」が役に立ちます。基本項目、情報漏えい、ウイルス感染、不正アクセス、(D)DoS攻撃のシートにわかれており、表を埋めることで整理すべき事項を洗い出せます。
埋められない点は、自社で事故が起きたときにウィークポイントとなります。そのウィークポイントに対応するためには、製品を導入したり専門家に依頼したりする必要があるのか、どこに何をお願いするのかなどを明確化しておくのです。そうした対策をしていないとインシデントが起きた際の対応が遅れますし、証拠が消えてしまう可能性もあります。泥棒が入ったときに監視カメラが付いていなければ何も追えません。先に対策しておかなければいけないのです。
貴社も第三者機関に調査を依頼されていましたが、どういった理由だったのでしょうか。
サーバーにあったファイルが漏えいしているかどうかを調べていただきました。自分たちでもやろうと思えばできるのですが、専門の会社のほうが調査スピードも速いですし、まとまった情報が出てきます。また「自分たちで調べた結果、漏れていませんでした」というのは本当か疑わしいですよね。
他部門や経営層へは、「伝える」のでなく「伝わる」ように説明を
インシデントが起きたときのために、個々人が普段から意識すべきことはありますか。
有事の際に情報をやりとりするためには、日頃から誰が何をしているのかを知っている必要があります。インシデント時、最終的に対応するのは人間です。テクノロジーは買えばいいかもしれませんが、責任者などの「人」はすぐには買ってこられません。連絡マニュアルのように無機質なものも必要ですが、それを使うのは有機質の人間です。人と人との関係や日頃のコミュニケーションは重要でしょう。
難しい言葉をきちんと上層部に伝える力も必要ですね。経営者は経営者の言葉で話しますし、技術者は技術者の言葉で話します。たとえば何らかのセキュリティ対策の話をし、予算を要求するときも、技術者はそのシステムの有用性がわかっていますが、経営者にはよくわかりません。そこで経営者に技術者の言葉で説明してしまうと、「そんなわけのわからないものに、お金が払えるか」と破談になってしまうのです。技術者は「システムの必要性を理解しない経営者が悪い」と考えるかもしれませんが、経営者は「技術者の話はよくわからない」と思うでしょう。
理解しない者が悪いと思いがちですが、理解させられない者も悪いと考えるべきです。何かを説明する際、わからない人にはわかるまで気長に説明をしてあげてほしいですね。他部門の担当者とのやりとりも仲間ですから同様です。
スマートフォンの使い方を親に聞かれた時のことを考えるとわかりやすいかもしれません。頑張って使い方を説明しても、なかなか伝わらなかったり覚えが悪かったりすることがあると思います。でもそこでイライラしてはいけません。親にとってはあなたしか頼れる人がいないのです。同じように、社内で他の部門に説明する際も、相手に歩み寄って説明してあげるといいでしょうね。「伝える」のではなく、「伝わる」ように、わからない人の立場で話をしてあげてほしいと思います。
本日はありがとうございました。
(取材、構成:BUSINESS LAWYERS 編集部)
辻 伸弘(つじ・のぶひろ)
ソフトバンク・テクノロジー株式会社
技術統括 セキュリティソリューション本部 プリンシパルセキュリティリサーチャー
大阪府出身。2014年よりソフトバンク・テクノロジー株式会社に所属。診断事業に携わりながら、情報を対外発信するエヴァンジェリストとして活動。同時に、自身の業務の幅を広げるべく、自ら攻撃手法を調べるリサーチャーとしての活動を新たに開始。現在もセキュリティリサーチャーとして、国内外問わずサイバーセキュリティの最前線を調査・解析しながら、エヴァンジェリストとしてイベントや勉強会での講演、テレビ・新聞などメディアへの出演、記事や著書の執筆など、セキュリティに関する情報を発信し、普及・啓蒙活動を行っている。