シンジです。読み方はシーサート、ご存じですか？コンピューター・セキュリティ・インシデント・レスポンス・チームの略です。なんだかよく分かりませんが、要するにセキュリティをなんかうまいことやる組織の事です。セキュリティって範囲は広いし費用対効果が分かりづらいし、難しいですよね。だからこそCSIRTに注目すべきです。
そもそもCSIRTとは何なのか
日本企業の多くは、プライバシーマーク制度やISMSなどを活用して自社のセキュリティの高さを証明するわけですが、これらには大きな特徴があって、「内部的な統制を取ろうとする」傾向があります。代わってCSIRTは、「外部からの攻撃に対処する」という点が特徴的です。例えば、
- 標的型
- リスト型
- ブルートフォースアタック
- Dos攻撃/ DDoS攻撃
- SQLインジェクション
- クロスサイトスクリプティング
- ルートキット
- ガンブラー
他にもフィッシングがどうとかマルウェアがどうとかバックドアがどうとか多種多様な訳ですが、全てにおいて共通して言えることがあります。それは、
インターネットを通じて行われる攻撃
だということです。なので、もしあなたがCSIRTに興味をお持ちであれば、社内のサービスがインターネットに晒されているかを確認してください。自社ホームページとか、メールとかですね。そこのセキュリティを何とかしようじゃないかというのがCSIRTの大きな役割となります。
セキュリティにはお金がかかる、CSIRTはどうか
実はCSIRTは、監査方式でも無ければ認証でも無い為、「こうすれば完璧」といった基準がありません。その為、お金をかけるかは担当者次第ということになります。具体的には、攻撃の検出に何かしらのシステムを投入するとか、とはいえやってはならぬこともあって、丸投げ外注です。ちょっと極論ですかね。
cloudpackの場合は、CSIRTを立ち上げる為にかかった費用はありませんし、運用する上でかかっている人件費は通常業務内でこなせるレベルに納まっているため、費用がかかっていません。結果的に有償のコミュニケーションツール（Slack）を使ったりはしているものの、CSIRTのために導入したわけではありません。
そう、お金をかけずにカジュアルに始められるセキュリティ対策、それがCSIRTの利点です。
まず何から始めるか
インターネットに晒されている対象のシステムを特定しましょう。何を守りたいのかを把握するのは最低限必要です。で、ありがちなのが、これをリスト化するってやつです。例えば、対象のサーバーが何台あって、どれにはどんなミドルウェアが入ってて、いつ買ったやつで、どうでこうでって、それやってる間に攻撃されてたら身も蓋もないです。
リスト化が必要かどうかはここでは考えずに、とりあえず、ああこんなサーバーがあるなーくらいのレベルでいいのです。
とりあえずやってみる
チームっていうくらいですから、組織を作るんですが、いきなり組織作るのもしんどいので、自分でCSIRTを運用してみましょう。超簡単ですからさっそくやっちゃいましょう。
- ミドルウェアの脆弱性情報をネットで集める、SSLとかApacheとか
- 自分が管理しているシステムに入ってそうなミドルウェアを思い出す
- もしも脆弱性のあるバージョンだったとして、アップデートしても影響が無いか調べる
- 影響が無いか調べる方法が複雑だったら、それを考えて手順化する
- なんとしてでもパッチを当てる
別にCSIRTだって言われなくても、それくらいやってるよって人も多いのではないでしょうか？これらを組織的に運用しようというのがCSIRTです。
また、ここではミドルウェアの脆弱性に特化していますが、前述の通りセキュリティは範囲が広すぎるので、まずはここから始めましょう。やり出したら事前・事後・品質管理と様々な課題が出てくること間違いなしです。
1人でイメージできたら、いろんな人を巻き込む
脆弱性について、各種攻撃について、情報収集しまくるのがCSIRTの第一歩です。1人で集めるよりも、複数人で共有しあった方が効率抜群ですよね。とりあえず情報を集めまくってみます。
今度は、その情報が自社のシステムに影響するかどうか、そのメンバーで議論してみましょう。これはシミュレーションでも良いのです。むしろ本当に脆弱性が発見されたらつらぽよなので、想定しながらやってみましょう。
で、とあるミドルウェアのバージョンをアップデートすべきだと判断したと仮定しましょう。そしたら、アップデート後にもシステムは影響無く稼働出来るかどうか検証しましょう。
作業の前には必ずダブルチェック、別の人の承認フローもあると最高です。作業ログも取りたいですね。
晴れて脆弱性は回避されました。というストーリーを描いてみましょう。
CSIRTは部署である必要は無く、仮想組織でも機能します
cloudpackの場合は完全な仮想組織です。社員構成を見ると、サーバーエンジニアやプログラマーの比率が高いため、CSIRTという部署を作ってせっせと情報収集するよりかは、現場のエンジニアから上がってくる生の情報をSlackなどのチャットツールに集めた方が効率が良いのです。そう書くとちょっと語弊がありそうなので補足すると、専用の部署を立ち上げるほどの体力が無いのです。専用部署を立ち上げている会社さんもいらっしゃるので、すげーと思いながら指をくわえているわけです。
というわけで社内に対しては、「脆弱性見つかって、それ突かれて悲しい思いするのは嫌でしょ？たくさん情報共有して対象しようぜ！」ってなノリで始めたわけです。
CSIRTで完璧を求める必要は無い、分からなかったら分かりそうな人に聞く
CSIRTの良いところは、リスク無しで外部からの攻撃に対処していく組織作りを始められるところにあります。また、日本シーサート協議会という素晴らしい団体もあり、ときたまワーキンググループと呼ばれるセミナー的なものも開催しており、CSIRTまっただ中な人達と横の繋がりを作る場を提供してくださっています。
CSIRT – 日本シーサート協議会
まずはさくっとはじめて、少しずつ枝を伸ばしていきましょう。CSIRTに基準や認定が無いのは、会社ごとに守るべき資産や受ける攻撃が多種多様で、その会社にあったセキュリティ運用が必要だからです。
CSIRTは、まずやってみる。そうすることで、社内のセキュリティに対する意識が格段に変わっていく様をご覧頂けること間違いなしです。
