GREE Engineering

グリーの CSIRT “GREE-IRT” の歩み

グリーの CSIRT “GREE-IRT” の歩み

はじめに

このエントリは GREE Advent Calendar 2015 二日目の記事です。二日目はセキュリティ部の奥村が担当させていただきます。

みなさま、年末気分、盛り上がってきましたか?2015年一発目の記事はご存じ弊社CTO、ふじもとによる「Deep Learningでスケジュール調整してみる、ための自然言語処理をしてみた」 でした。例年は大トリを務めることが多かった(2013年2014年)のでもう12月も終わりなのかと思いましたが、今年は趣向を変えた、ということのようです。いかがでしたでしょうか。


本日のお題 「CSIRT(シーサート)」

CSIRT(シーサート)って、何?

さて、あらためて、本日のお題です。

エンジニアブログとしてはこれまた趣向を変えて、本日は「CSIRT(シーサート)」について、グリーの実例を交えてお送りします。沖縄で見られる伝説の動物か何かのような名前ですが、「CSIRT」は「Computer Security Incidents Response Team」の略称でして、これを「シーサート」と発音しているようです。直訳というか日本語読みすると「コンピューターセキュリティインシデント対応チーム」となり何やら物々しい雰囲気もありますが、「セキュリティ的に何か良からぬことが起きた時に駆り出される中の人たち(かわいそうに)」という理解でまずはよいかと思います、はい。
そして、本日のエントリはその中の人であるところの奥村がお送りします。よろしくお願いいたします。

そもそも「Incident(インシデント)」って何?

という点にも触れておきましょう。
医療過誤や航空機事故でも使われている用語ですが、ここでの「インシデント」は情報セキュリティ分野の話です。
「Incident」の適切な訳語がないので一言では言いにくいのですが、

「望まない」事象
情報漏洩、不正アクセス、データ不整合、データ消失、システム停止、サービス停止、など
「予期しない」事象で「悪影響がありそう」なもの
大小様々なバグ、脆弱性、原因不明の振る舞い、意図しない動作、など

といった事象を情報セキュリティ分野では「インシデント」と呼んでいます。
(以下、「インシデント」はこの情報セキュリティ分野でのインシデントを指します)

「情報セキュリティインシデント」- JIS Q 27002 より
望まない単独若しくは一連の情報セキュリティ事象、又は予期しない単独もしくは一連の情報セキュリティ事象であって、事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの

という定義が日本の政府機関などではよく用いられているようです。

聞いたことあるような、ないような?

20151202_graph1

graph1

さて、唐突に登場したこのグラフ、何だと思いますか。

使い慣れている方はすぐわかるかもしれません。これはGoogle Trends で「CSIRT」を表示したものです。Google Trends によると初登場は2007年の5月、それまでは「CSIRT」はほとんど知られていなかったようです。その後2013年くらいまでは横ばいですが、ここ2年くらいで上昇傾向にあることが見て取れると思います。

graph2

graph2 – 加盟数の推移(左)と設立年の分布(右)

こちらは、日本シーサート協議会(NCA: Nippon CSIRT Association)の加盟組織一覧ページ2014年版資料からのもので、CSIRT はやはりここ2年で協議会への加盟数が大きく伸び、設立もここ2年で急増しているのが見て取れますね。

なぜ最近耳にするようになったのか?

うーん、なぜでしょうか。答えは一つではなく、いくつかの要因が考えられそうです。

ですが、ごく単純に、コンピュータが発明されてプログラマやエンジニアといった職業が生まれたように、CSIRT も何かに呼応してできてきた組織、役割ではないか、という仮説が考えられます。CSIRT の名前が示す通り、やはり「インシデント」に対して「チーム」としての組織的な「対応」が必要になってきた、というのが大きな要因の一つではないでしょうか。

インシデントの発生状況は、数的には増える一方で、質的にも影響が大きくなってきている、というのは感覚としてみなさま異論ないところだと思います。実際の統計情報としては、IPA の情報セキュリティ事象被害調査、警察庁のサイバー空間をめぐる脅威の情勢インターネットバンキングに係る不正送金事犯の発生状況や総務省の情報通信白書を始め、民間の調査会社のレポートも多数出ています。となれば、何らかの対応が必要だ、備えたほうがいい、なるほど CSIRT というのがあるのか、と考える人が増えてくるのは自然なことにみえます。

なぜ「チーム」なのか?

では、次になぜ「チーム」なのか、を考えてみます。
仮にインシデントが起こる確率が一定であったとしても、IT の普及につれてインシデントの発生数は増大し、繰り返し対応が必要になってきます。繰り返し起こるならエンジニアとしては自動化を、業務の現場ではマニュアル化を、経営者であれば専任の担当を置くとか組織化を考えるところです。
また、はじめは個人で解決できるような小さなインシデントばかりかもしれませんが、海岸に打ち寄せる波の高さが時に思いがけず高くなるように、影響範囲も広く被害も大きな重大なインシデントにいつ遭遇するかはわかりません。というか、いつかは必ず遭遇する、という方がより正しい表現で、これに備えるならエンジニアとしては対策を仕込み、現場ではホウレンソウを徹底させ、経営者であればヒトなりカネなりを投入しておく、みたいな話になります。

会社の経営者なり偉い人が、「組織的な対応が必要だ」ということに気づき、「ヒトとカネを投入しよう」と決断して初めて「チーム」であるCSIRT というのができるのですね。これ大事。

グリーの場合:CSIRT のお仕事とは?

一般論が長くなりましたが、ここからはグリーの CSIRT である「GREE-IRT」の歩み(事例)をお伝えしようと思います。

「GREE-IRT」 の設立:Preparation

グリーの CSIRT である「GREE-IRT」の設立日は2012年1月4日ということになっています。これはシーサート協議会へ加盟したタイミングでして、2011年には原型というべき組織が立ち上がっていました。今を遡ること4年以上も前から既に誰かがインシデントへの対応を行っており、誰か偉い人が「組織的な対応が必要だ」ということに気づき、「ヒトとカネを投入しよう」と決断していた、ということです。

誰なのか。
勘のいい方ならお気づきでしょう。そう、弊社 CTO ことふじもとです。

拝命:Detection and Analysis

2012年に奥村が入社したその初日、まだトイレの場所すらよく分かってない僕の前にその人は現れました。

「あ、ふじもとです、CTO やってます、奥村さん?」「はい?」「セキュリティ担当っつーことでIRT をやって欲しいんだけどわかる?IRT?」「はあ、言葉と概念は知ってますが、」「あー、んじゃ、ここのwiki とかドキュメントあるから、で、今はEさんが担当やってるから引き継いで。」「あ、はい、(なう?)」(スタスタスタ)「Eさーん、セキュリティ担当の奥村さん」「あ、初めまして」「初めまして」「んじゃ、後よろしく!」(ピューッ)「え?」「あ、よろしく。」「よろしくお願いします。。」

(ほぼ)実話です。

無茶振りのようにも見えますが、そもそもインシデントはいつも不意打ちみたいなものですから、慌てず騒がず受け止めて冷静に評価することが必要です。

一般的な CSIRT のお仕事としては、次のようなものがあります。

  • Detection and Analysis (検知と分析)
    • 受付の窓口をつくる(社内外とも)
    • 社内各部門とホットライン的なものをつくり知らせてもらう
    • 各種センサから alert をあげる
    • 各種脆弱性情報をキャッチする
    • 通常のシステム状態を把握しておき影響を見極める
    • 判断基準とか作っておくと便利

いきなり大々的にCSIRT の受付窓口をブチあげると入口からして既に業務が溢れてしまう恐れもありますが、原則としては日々様々な情報が入って来やすい態勢にすることが大事です。見えもしないもの、検知できないものには何も対処できません。
また、何か検知したらそれがどれくらい重要か、危険か、緊急かどうか、というところを判断する必要があります。判断は「高中低」でも「Critical/High/Middle/Low」でもなんでもいいのですが、「対応不要」「スコープ外」の線引きができているとより捗ります。

黎明期(2012年〜2013年はじめ頃):Containment, Eradication and Recovery

その後丸一年くらいの間は、創業以来積み重なっていた課題、日々寄せられる質問や相談、やはり起きてしまうインシデントやヒヤリハット事案に次々と対応する日々でした。ヒトもカネも時間も足りず、すべての案件を100% のクオリティでこなすのは不可能です。それでもロードマップらしきものを描き、Issue list を作り、定期的にレポートをし、重大なものはエスカレーションし、と地道に荒野を耕していきました。

一般的な CSIRT のお仕事としては、次のようなものがあります。

  • Containment, Eradication and Recovery (封じ込め、根絶と復旧)
    • 被害拡大の防止
    • とりあえず遮断
    • いわゆる応急処置
    • これらの優先順位付けと進捗管理
    • レポーティング大事
    • 恒久対策

大なり小なりセキュリティインシデントがあればおおよそ上記のような仕事が発生します。血が出ていればまずは止血、何かが燃えていればまず消火。ここで大事なのはスピードなのですが、闇雲に急いでも混乱に拍車はかかるし疲れるしそれでまたミスが出たりといいことないです。非常時は誰もが対応を急ぐのになかなか解決しない、という状況に陥りがちで、これは不確実な情報、断片的な情報を基に推測や憶測を交えて議論し判断し対応するという「空中戦」が行われていることが原因であることが多いです。

GREE-IRT としては、ただただ記録を取ることに専念する、とにかく一箇所に情報を集める、起こっていることを可視化する、といったところに注力することが多いように思います。

発展期(2013年〜2014年半ば頃):Post-Incident Activity

徐々にセキュリティ部門のメンバも増え、同時に実質GREE-IRT に相当するメンバ(あ、GREE-IRT は設立以来ずーっとvirtual 組織です)も増え、2013年に入ると本格的に業務委託さんの力も借りながら、主に社外向けの「サービス領域」と社内向けの「オフィス領域」それぞれについてPDCA サイクルが回り始めました。サービス領域では定期的にプロダクトの脆弱性診断が実施されるようになりました。オフィス領域では2014年6月にいわゆるISMS 認証(JIS Q 27001, ISO/IEC 27001)を取得しています。

一般的な CSIRT のお仕事としては、次のようなものがあります。

  • Post-Incident Activity(インシデント後の活動)
    • インシデントの振り返り
    • 改めての報告
    • 再発防止策の策定、実施
    • 教訓の共有

大きなインシデントであれば上記すべてのお仕事を関係者交えて徹底的に行うのがよいでしょう。小さなインシデントであっても、件数の記録や対応履歴を整理しておくことは重要です。繰り返し襲ってくるであろうインシデントへの備えを行うために、客観的定量的なデータを揃えておくことで、平常時に次の一手が打ちやすくなります。

成熟期(2014年後半〜現在):Preparation (again)

発展の次は成熟だと収まりがいいので成熟と書きましたが、実質は第二次発展期、みたいな感じです。黎明期であればとても手が回らなかったところにも手が届きそうになってきました。Incident “Response” Team なので、事後対応、何かあってからの対応にフォーカスが当たりがちですが、事前に備える、先手を打つ、という方がより効果的ですし一般的にコストも低く済みます。事前と事後、両方できて初めて一人前とでもいいますか。
GREE-IRT の場合、脆弱性診断であればこれまではリリース済みのサービスについて追いかけで診断してきたものが、新サービスの導入前に診断するようになりました。あのサーバはどこにあったっけ、あの設定どうなってたっけ、というのを都度訊いたり調べたりするのではなく、事前に入手しておいたり、定期的に台帳と合っているかどうか棚卸したりするようになりました。インシデントへの「対応」だけでなく、徐々に「備え」もできるようになってきた、というのが最近の状況です。

一般的な CSIRT のお仕事としては、次のようなものがあります。

  • Preparation(準備)
    • インシデントに備えて体制を維持、発展させる
    • システム構成情報とかNW構成情報とか整理しておく
    • より上流工程でセキュリティの話をする、相談に乗る
    • 教育とか研修とか、注意喚起とか
    • リスク分析して先手先手に対策をする

非常時のお仕事だけでなく、平常時にいかに備えを厚くできるか、というのが今後また起こるであろうインシデントの発生確率を低減したり、発生時の影響を抑えたり、ということに繋がります。

さいごに

ということで、今日は、これまでの GREE-IRT の歩みを、CSIRT という組織の一般的なお仕事に(ちょっと無理やり)当てはめてお送りしてみました。

あなたが CSIRT の方でなくても、CSIRT ってインシデント対応やらされてるちょっとかわいそうなチームなんじゃないかとか、いやなんか怖そうなチームだとか、普段何やってるかわからんとか、そういうnegative な印象が少しでも和らぐと幸いです。

また、もしあなたが CSIRT の方であれば、何かしら参考になることがあれば幸いです。情報交換も歓迎です!

最後までお読みいただきありがとうございました。


参考文献

  1. CSIRT からみたインシデントレスポンス Internet Week 2014 奥村祐則
  2. 日本シーサート協議会加盟組織一覧ページ2014年版資料 日本シーサート協議会
  3. 情報セキュリティ事象被害調査 平成26年度 IPA
  4. サイバー空間をめぐる脅威の情勢 平成27年上半期 警察庁
  5. インターネットバンキングに係る不正送金事犯の発生状況 平成27年上半期 警察庁
  6. 情報通信白書 平成25年度 総務省
  7. Computer Security Incident Handling Guide, SP 800-61 rev.2 NIST
  8. 経営リスクと情報セキュリティ ~CSIRT:緊急対応体制が必要な理由~ JPCERT/CC
  9. 組織内 CSIRT の必要性 JPCERT/CC
  10. 組織内 CSIRT の役割とその範囲 JPCERT/CC
  11. 組織内 CSIRT の活動 JPCERT/CC
  12. 金融検査マニュアル新旧対照表)平成27年 金融庁

三日目の明日12/3 は、暮らしをデザインする住まいのビジュアルプラットフォーム「LIMIA(リミア)」のエンジニア 藤田@tgfjt さんによる記事です。お楽しみに!