セキュリティ Archive

6/5から6/7に白浜で開催された、「第3回情報危機管理コンテスト」という大会に出場させて頂きました。

大会の概要は以下の通り。

(１) 参加チームは、本委員会の監視チーム、および審査委員のもとで本コンテストを実施します。
(２) 参加チームは、各仮想企業の情報セキュリティ担当部署を演じていただき、提供されたインシデントの発生したシステム環境を調査し、かっこよく対応していただきます。
(３) 当該システム環境には、あらかじめ監視チームにより、インシデントあるいはこれを発生させるためのセキュリティホールが内包されています。
(４) 参加チームには、事前に当該システム環境と運用のフレームワーク概要をお知らせします。
(５) Bot系ツール、フィッシング、DoS（サービス不能攻撃）、パスワード走査と侵入、SQLインジェクション等、経路アナウンスの妨害など、さまざまなインシデントを想定してください。
(６) 監視チームは、ネットワーク上のトラフィック監視を中心に参加チームの対応状況を把握するとともに、顧客あるいは外部ユーザーを演じて適宜問い合わせや苦情のメールを送信します。
http://www.sccs-jp.org/SCCS2008/sccs03.html

五つの教育機関から五つのチームが出場し、それぞれが一つのブース（ネットワークやサーバが設置されている）を担当します。

一体何を競い合うのかというと、

• 復旧までの時間
• インシデントの対応手法
• 上司への報告・提案

の３つが主な評価指標だったと思います。
これらを総合的に判断し、どのチームが一番かっこよく対応できたかを決める大会です。

僕が参加した同志社大学チームは、過去2大会で最優秀賞を頂いているチームです。（僕は昨年度の大会から参加）
今年はやはり、3連覇という気持ちの良い数字がかかっていることと、僕は今年で卒業してしまうこともあってか、「絶対に最優秀賞を頂いてみせるぞ！」と意気込んで、それなりにたくさん準備をして大会に臨みました。
結果、苦しみながらもなんとか最優秀賞（Best Award 賞）を頂くことができました。

表彰式で講評を頂いたのですが、その中で最も嬉しかったのが、前回課題とされいたことが克服できていたと評価していただいたことです。

前回は、

• ネットワークに弱い（実はそうでもなかったのですが、実力を発揮できずorz）
• トラブルチケット（上司への報告）が最悪（前々回も同じ評価）

という評価を頂いていました。
この2点（特にトラブルチケット）を改善するのがチームの一員としての僕のテーマであったので、感無量になってしまいました。
ありがとうございます。

このような手の掛かる大会を主催されている方々は、本当に大変だっただろうなと思います。
主催者の皆様の血のにじむような準備のおかげで、僕たち参加者は素晴らしい経験をコンテストを通して得ることができました。
この場をお借りして、感謝の言葉を述べさせていただきます。
ありがとうございました。

もう少し時間があるので、僕たちのチームはどのようなことを考えて準備をしたか、について差し支えない程度に一部だけ紹介したいと思います。
（まずかったらすぐ消します）

１．トラブルチケットをできるだけ詳しく

トラブルチケットはできるだけ詳しく、詳しすぎるほど詳しく書いた方が良いみたいです。
（実社会においてはどうなのかわかりませんが、少なくともコンテストにおいては）

駄目なトラブルチケットの例を挙げますと（実際に一昨年の第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

情報危機管理コンテストは、普段の大学・大学院生活ではほとんどの人が考えないようなことを真剣に考えることができる、素晴らしい大会だと思います。

僕は今年の大会で卒業してしまいますが、次回があれば、我こそはという人はエントリーしてみてはどうでしょうか？
貴重な体験が待っていると思います。

今日Bookmarkしたページの紹介です。

研究テーマを探している学生のときに考えた事 | Lifehacking.jp

研究テーマをなかなか見つける事が出来ない人へのアドバイスが書かれた記事です。

著者が昔行っていた研究テーマ発見手法についての説明があります。

僕の周りにも「研究テーマがない」「見つからない」「自分で見つけることが出来ない」と言っている人が何人かいますが、その人たちに読ませてあげたいと思いました。

特に以下の部分。

なかには、あきらかに自分の情報不足を自分の能力不足と勘違いしている場合もあって、惜しいところで空回りしている場合も見受けます。Google を使うのは、同じところで回転している自由度のない０次元の自分に、興味のベクトルという新たな次元を与えて、視座を得るためでもあるのです。

考えが煮詰まったからといって自分を見限るのはとてももったいない事です。煮詰まったと感じたら、違う方法で、あるいは違う視点から物事と向き合うことが大事ですね！

「メールを読むだけでルーターが設定変更される」、驚異の新攻撃出現：ITpro

自分宛に送られてきたメールを読むだけでルータの設定が変更されてしまう、という攻撃の紹介記事。

メールに含まれるHTML・JavaScriptコードが読み込まれると、ブロードバンドルータのDNS設定が書き換えられ、特定のサイトへのアクセスが攻撃者のサーバに転送されてしまうという攻撃です。

これは攻撃する人も考えましたねー。

対策としては、ブロードバンドルータのログインパスワードをデフォルトの状態から変更する、あるいはHTMLメール自体読まない、などがあると思います。

用心用心！