組織CSIRTにおけるインシデント対応あるある

これから30年もおんなじことを繰り返すのかと思うと絶望的なため、思ったことを文字にして対策を考えることにします。

脆弱性対応のたびに、一覧になかったインターネット公開システムが増える。

システムの一覧を早期に作成し、確定させる。これまでとは違ったことをいわれたら、報告書に書いて幹部にエスカレーションする。

そのシステムが、インターネットに接続されているのか接続されていないのか、主管が把握していない。たまに実際には接続されていないのに、「接続してます」と言い張られる。その逆もある。

インシデントにおける混乱もあるので、ある程度は仕方がない。主管はあくまで発注のみしていて、管理は別のベンダなどが実施している場合もある。人事異動の功罪ともいえる。

パッチを当てた後にサーバを再起動させたら、装置が故障してあがってこない。

今夜は君を帰らせないよ。

ずいぶん前からもうすぐEoLだと勧告してもらっているのに、EoL後に「パッチが出ないので脆弱性が修正できないんですけどどうすればいいですか？」といってくる。

Windows XPとか2003とかIE6とかRHEL3とかApahce Struts 1とか..。お手上げ。主管の責任にして、幹部にエスカレーションする。新規開発では最新のソフトウェアで開発させる。

脆弱性に該当したシステムの主管から「いつまでに対応すればいいですか？」と尋ねられる。

いますぐやりなさい。責任をCSIRT側にとらせるのはやめて！

ソフトウェア開発できない発注するだけの社員が、一般公開前脆弱性の詳細を教えろと言い張る。

気持ちはわかるけど遠慮して。プログラミングもできないのに、詳細情報を知ったところで役に立たないから。20160117追記。

知らぬ間に新しい公開システムが増える。そういうシステムに限って、担当者が繁忙で土壇場では連絡が取れない、もしくはOEMで社員はただの取次役である。

OEM契約によるサービス提供の場合、自社でのソフトウェア開発が不要なため、早くサービス提供が開始できるメリットがある。しかし、早すぎてCSIRT側が把握するのがサービス開始後になりがち。またOEMは、瑕疵が発見されたときの責任の所在が曖昧になりやすく、改修に時間が掛かるおそれがある。20160117追記。

開発部門が自分たちは検証設備のみを管理しているので、商用設備のことは把握していないと言い張る。

DevOps時代なのに、開発しかしない組織はなくすべき。ミッションを縦割りになっていると、関係組織同士でセキュリティのミッションが押し付け合いになる。これにより、対応も遅くなる。20160117追記。