結果

一次予選通過チームは以下の１２チームです。

• P01TERGEIST（名古屋工業大学）

• m1z0r3（早稲田大学）

• F.SE（大阪大学）

• KobApple.inc（関西大学）

• ftp_user（北陸先端科学技術大学院大学）

• kstm（信州大学）

• 詫間情報安全管理局A（香川高等専門学校）

• Enduring Pug（岡山大学）

• PandA 5号館（京都大学）

• ケモミミスク水美幼女（東京工業大学）

• †綾瀬川綾瀬†（東京工業大学）

• うまいみず（千葉大学）

講評

今年は新型コロナの渦中に実施した一次予選でしたが、例年と同等数のチームの参加がありました。参加されたチームの皆様におかれましては、チームメンバーとなかなか顔を合わせられない状況の中でのチーム編成は苦労されたのではないかと思います。また、ただ参加されただけでなく、授業が開始される中で例年よりもさらにレベルの高い回答書が集まりました。遠隔でもしっかりと相談をされて、チームワーク良く作業をされたのだと思います。様々な活動が制限される中でもこれだけのパフォーマンスを発揮された皆様に敬意を表するとともに、皆様のことを誇らしく思います。一次予選を通過できるチームは残念ながら１２チームに限られるため、皆様の中には涙をのむチームもあるわけですが、がっかりしないで、自信を持って今後も技術・スキルの研鑽に勤しんでいただけましたらと思います。

さて、今年の問題は新型コロナ下で有用なツールとして、遠隔地でも協調的にプログラム開発ができるサービスを考えてみました。コンテナやソーシャルログインなどの比較的新しい技術も入れての出題でしたが、どのチームもこれらの技術をしっかり理解した上で対応してこられたのはさすがでした。リモートワークにおいては、どのように他の人と協調してシームレスに作業を進められるか、という点が一つの鍵になります。これを、ビデオ会議システムと、柔軟な権限設定に基づいた共同編集機能によって補い、コンテナを用いて実行テストまでローカルでできてしまうという想定になっています。実用的には素晴らしいサービスですが、本当にこれをやろうとすると、皆さんがご指摘のように同期機構をどう作り込むかという問題や、そもそも実行テスト環境をどうやって作るのか、というような話が出てくるわけですし、また、システム開発は金額規模が大きい事業ですから実績がないサービスなのでじゃあ使ってみようなんて企業はなかなかないと思われるのですが、まあそれはそれ、ということでどうぞお許しいただきたく思います。

いざみなさんの回答書を拝見すると、多くのチームが可能性のある原因をほぼ網羅された指摘をされていて、驚きました。もはやこのコンテストでは、インシデントの可能性を洗い出す部分では競技が成り立たないのですね。つまり、問題になりそうな原因は全てわかった上で、それらにどのように優先度をつけて、どのように解決まで進めるのか、そのような解決までの戦略立案のところでの差を競うことになってきます。今回の場合であれば、ファイル同期の問題、人的問題、そして外部からの侵入という技術的問題がある中で、これらをどのような情報を用いてどう切り分けていくのか、そして作業の順番や時期はどう設計すれば良いのか、というところを説得力のある形で示してもらうことが、一次予選突破の鍵となると思います。

まずお伝えしたいのは、今回の場合に一番考えて欲しいのは、顧客のニーズだということです。システム開発というのは予算規模の大きな事業ですし、納期も厳しいわけですから、顧客側としてはできるだけ開発を止めずにスケジュール通りに進めたい、という要求が強くあります。このニーズに応えてあげるのが、信頼されるコンサルタントとして重要です。今回起きたことはソースコードの一部の不整合ですが、これが開発を止める必要のない問題から起きているのかどうか、これをまず特定してあげてほしいですし、もし応急措置を施せば開発が続けられるのであれば、そのような措置を講じてあげたいところです。もしインシデントが外部からの侵入ではなく単なる同期の問題だったり、誰かの勘違いであれば、それが可能になります。ログ等の解析ですぐにそれを判定できるならば（ログがあるとは書かれていませんが）、それがほぼ初動対応と言っても良い作業になるのではないでしょうか。そうやって顧客のニーズに基づいて事象を切り分けてあげることを意識したいものです。同様に、インシデントがあったと他の顧客に伝えるかどうかも、判断を挟む余地があります。もし顧客の勘違いであったら、インシデントの可能性を伝えることは無用な不安を招くだけです。すぐに対応できるバグフィックス程度のものの事案であれば、即時に対応して事後報告としても良いのです。

みなさんの回答書を一通り読ませていただいたところ、上記のような顧客への対応ができているものが少なかったと思います。そして結果的には、このことも含めて、今後どのように対応を進めていけば良いのか、その戦略を書けているかどうかが、勝敗を分ける基準になりました。初動対応としてテンプレート的な事項（基本的な連絡事項や証拠保全など）のみを書いている人が多かったと思いますが、それだけでは不十分で、すぐに切り分けて対応できる事項は初動対応（にあたるくらいの初期対応）に含めてしまいたいところです。また、どのような情報からそれらの切り分けを行い、どのように対応していくのか、その展望を示せることも、顧客が何をすれば良いかを明確にするので重要です。予選突破チームの選出は、特にボーダーライン付近は僅差で悩ましい状況でしたが、このような対応戦略が（ある程度でも）書けているかどうかという基準で線引きができました。多くのチームは、原因可能性を列挙して個別に対応方法を書いていましたが、次回からは対応戦略を納得できる形で示すことを意識していただければと思います。

せっかくですので、もう少し細かいことも書いておきましょう。今回のインシデント対応では、（まあ、書面だけではそうなると思いますが）技術的内容はあまり深堀りすることができません。今回ですと、例えばdockerイメージ自体の漏洩や認証の問題、OAuthに関する一般的な技術的指摘などを求めたつもりですが、逆に言えば、その程度の深さまでしか皆さんに求めることができません。仮想マシンやコンテナ、クラウドへの侵入など細かい可能性を挙げればきりがありませんが、それらは一つ一つを分離して詳しく書くのではなく、例えば「サーバやコンテナ等への侵入」などと大きく括って記述量を減らす方がわかりやすいでしょう。技術的事項を細かく列挙された方は参考にしてもらえればと思います。また、今回の事象の中で「プログラムコードの書き換え」は、単なる同期機構の問題では発生しないと思われますが、当事者の勘違いや、複数人による同時編集の過程でそう思ってしまう可能性がある事象だと思います。つまり、セキュリティに関するインシデントと断定するのは早計で、その前段階の判断を計画に入れたいところです。

あとは長期的視野からの同期機構の改善問題ですね。これは私たちも深く考えずに問題文を書きましたが、多くのチームから複数の提案をいただいて、とても興味深く拝見させていただきました。現実にこの機能を実現する場合にはアプリケーションの設計とも連動した複数の選択肢が検討されるのだろうと思いますし、正解は存在しないでしょうけれども、皆さんの回答を合わせていくと検討すべき方向性が見えそうな気がしました。本件はシステム運用やセキュリティというよりはサービス設計の問題ですが、しっかり対応されていて皆さんの視野の広さを感じました。他の長期的改善の提案についても同様に、皆さんの提案を合わせると方向性が見えてきそうで、このサービスに関する皆さんの本質部分に対する理解を感じました。システム開発もそうですが、セキュリティ・運用支援分野も、顧客の業務に対する本質的な理解が基礎になります。そういう意味では、幅広く活躍できる真のセキュリティ技術者としての期待がもてそうだと喜んでいるところです。

我々からのコメントは以上です。
改めて、一次予選お疲れ様でした。楽しんでいただけたなら幸いです。
二次予選に進まれる方は、ぜひ本戦出場を目指して、頑張ってください！

第16回情報危機管理コンテスト一次予選担当

吉廣・藤本