6/5から6/7に白浜で開催された、「第3回情報危機管理コンテスト」という大会に出場させて頂きました。
大会の概要は以下の通り。
(1) 参加チームは、本委員会の監視チーム、および審査委員のもとで本コンテストを実施します。
(2) 参加チームは、各仮想企業の情報セキュリティ担当部署を演じていただき、提供されたインシデントの発生したシステム環境を調査し、かっこよく対応していただきます。
(3) 当該システム環境には、あらかじめ監視チームにより、インシデントあるいはこれを発生させるためのセキュリティホールが内包されています。
(4) 参加チームには、事前に当該システム環境と運用のフレームワーク概要をお知らせします。
(5) Bot系ツール、フィッシング、DoS(サービス不能攻撃)、パスワード走査と侵入、SQLインジェクション等、経路アナウンスの妨害など、さまざまなインシデントを想定してください。
(6) 監視チームは、ネットワーク上のトラフィック監視を中心に参加チームの対応状況を把握するとともに、顧客あるいは外部ユーザーを演じて適宜問い合わせや苦情のメールを送信します。
http://www.sccs-jp.org/SCCS2008/sccs03.html
五つの教育機関から五つのチームが出場し、それぞれが一つのブース(ネットワークやサーバが設置されている)を担当します。
一体何を競い合うのかというと、
- 復旧までの時間
- インシデントの対応手法
- 上司への報告・提案
の3つが主な評価指標だったと思います。
これらを総合的に判断し、どのチームが一番かっこよく対応できたかを決める大会です。
僕が参加した同志社大学チームは、過去2大会で最優秀賞を頂いているチームです。(僕は昨年度の大会から参加)
今年はやはり、3連覇という気持ちの良い数字がかかっていることと、僕は今年で卒業してしまうこともあってか、「絶対に最優秀賞を頂いてみせるぞ!」と意気込んで、それなりにたくさん準備をして大会に臨みました。
結果、苦しみながらもなんとか最優秀賞(Best Award 賞)を頂くことができました。
表彰式で講評を頂いたのですが、その中で最も嬉しかったのが、前回課題とされいたことが克服できていたと評価していただいたことです。
前回は、
- ネットワークに弱い(実はそうでもなかったのですが、実力を発揮できずorz)
- トラブルチケット(上司への報告)が最悪(前々回も同じ評価)
という評価を頂いていました。
この2点(特にトラブルチケット)を改善するのがチームの一員としての僕のテーマであったので、感無量になってしまいました。
ありがとうございます。
このような手の掛かる大会を主催されている方々は、本当に大変だっただろうなと思います。
主催者の皆様の血のにじむような準備のおかげで、僕たち参加者は素晴らしい経験をコンテストを通して得ることができました。
この場をお借りして、感謝の言葉を述べさせていただきます。
ありがとうございました。
もう少し時間があるので、僕たちのチームはどのようなことを考えて準備をしたか、について差し支えない程度に一部だけ紹介したいと思います。
(まずかったらすぐ消します)
1.トラブルチケットをできるだけ詳しく
トラブルチケットはできるだけ詳しく、詳しすぎるほど詳しく書いた方が良いみたいです。
(実社会においてはどうなのかわかりませんが、少なくともコンテストにおいては)
駄目なトラブルチケットの例を挙げますと(実際に一昨年の第1回コンテストで作成したチケット)、
Open Date: 2006/05/27 14:59
Close Date: 2006/05/27 15:11
報告者:hoge
担当者:hoge
内容:hogehoge(有)トップページにて、再び改竄を確認
対応:
調査したところWebDAVが有効になっていることを確認
http.confで阻止
こんな感じになります。
これだと、
- トラブルの具体的な内容がわからない。事細かに書くべき。
- 「調査したところ」でとあるが、担当者がいつ・何を考え・どのように調査したのかわからない。
- WebDAVが有効になっていることが何故問題なのかがわからない。
- 「http.confで阻止」とあるが、何をどう対処したのか全くわからない。
- 今後同じトラブルが起こらないようにするにはどのようにすればいいのかがわからない。
が問題になってしまうと思います。
これらの点をきちんとカバーできるチケットを書けるようになるためのトレーニングが必要だと考えます。
2. メンバー間における情報共有のためのインフラを作る
上で紹介したようなチケットしかかけなかった最大の理由は、「メンバー間の情報共有が上手くできていなかった」ことだと考えます。
そのため、メンバー間の情報共有をシームレスに行うためのインフラ・仕組みを構築して持って行くことが重要です。
具体的には、次のような情報の共有をメンバー間で行う必要があると思います。
- 時系列に並んだ各メンバーの詳細な作業履歴
- 各メンバーの状態
- 各メンバーの考えていること
これらの情報を、時を遡ってメンバー全員が閲覧することができたとしたら、トラブルチケットを書く人もかなり楽になります。
問題は、どうやってこれらの情報を共有するためのインフラを作るか、なのですが、実現するための手段としては数え切れないくらいあると思います。
もちろん、メンバー全員が常に詳細な情報をコンテスト中に発信し続ける必要がありますが、その手間を上回る効果があると考えます。
3. まとめ
上に挙げたのは、チームとして準備したことのほんの一部です。
他にいろいろと準備しなければならないことがたくさんあると思います。
そもそも、トラブルを解決できるだけの技術力がないと、情報を共有できたってらちがあかないですし・・・・orz
情報危機管理コンテストは、普段の大学・大学院生活ではほとんどの人が考えないようなことを真剣に考えることができる、素晴らしい大会だと思います。
僕は今年の大会で卒業してしまいますが、次回があれば、我こそはという人はエントリーしてみてはどうでしょうか?
貴重な体験が待っていると思います。
- Newer: 自宅サーバ(Debian)にOpenVPNを導入(サーバ編)
- Older: 2008年5月の人気記事