会社でセキュリティコンテストをやってきた

けっこう前の話になるが、社内でセキュリティコンテストをやってきた。

会社は某SIer. システム開発とか構築、運用やその他業務がある。
システム開発ではもちろんセキュリティについても考慮しなければならないわけで、その啓蒙、スキル底上げの一助になればと思い、一部のCTFチームメイトとともに運営側に参加した。

自分は、コンセプトとか全体的なやり方の策定、問題作成、当日の運営をメインにやらせてもらった。
すべては公開できないが、いろいろと悩んだこともあったので書ける範囲で書こうと思う。ボカすところはボカして書く。

コンセプト

まず、"SIer"でのコンテストは、どんな問題にしたら良いのか。
業務のどのフェーズでもセキュリティを考慮する必要はあるが、まずは開発時にしっかりしたものを作れるようにしたい。ということでスコープは「開発時に求めるセキュリティ」とした。
では、ここで求められるものは、どんなものがあるだろう。
たとえば次のようなものがあると思う。

脆弱性発見能力
- 脆弱性を見つけないと修正することはできない
- プログラムを直接書かなくても、設計やレビュー、試験にて発見することが求められる
脆弱性修正能力
- 当たり前だが修正できないと守れない
- プログラムを書く立場でなくても、修正方針の立案やその評価をする必要がある

これらは、プログラムを書く場合も、書かない立場の場合も同じなんじゃないかな。
ということから、開発時の観点としてこれを定めた。

次に、これを細分化しどんな力があれば発見や修正ができるのか、を分類した。
たとえば、脆弱性発見能力ならば、

ブラウザ上に表示される情報から発見ができる
ツールの使い方を知っており、それを利用することで発見できる
実際に悪用されるケースを考えた攻撃手法を発想できる
最近のセキュリティ動向に追従している
複数の脆弱性やテクニックを複合的に使用できる

脆弱性修正能力ならば、

画面やログ等からどんな攻撃が行われているか検知、判断できる
パッケージのアップデート等、ベンダ推奨の対策ができる
コンフィグの見直しで安全な環境を作れる
コードを修正しAPの脆弱性をなくせる
実際に攻撃されている状況を解決できる

といった具合。
これらを横軸に並べ、問題を考案するときにはこのマトリクスで○×を付けていった。

また、脆弱性発見のバリエーションは多岐にわたるが、修正のバリエーションは定番が多く実は少ない(最新版にアップデートする、エスケープ処理を施す、Prepared Statementを使う、 etc)特性があるのではないかという議論の流れから、「修正能力より、発見能力を重視する」方向性とし、

脆弱性発見は、難易度を分け「簡単に修正できるが、発見しにくい脆弱性」を見つけられることに重点を置く
脆弱性修正は、奇をてらわず基本をしっかりと修正できることに重点を置く

に二分し、それぞれを独立させた問題構成とした。（発見/修正バリエーションの話は、もちろん全てがそうではないと思うけど）
また、これらを満足するためには参加者vs参加者である必要はないことから、CTFで言うJeopardy形式とした。

ジャンル

開発している全ての分野を対象とすると広すぎるため、その中でも多いWebアプリケーションをメインとした。
この問題考案においては、OWASP TOP10や自社開発で試験時に多く発見される脆弱性などを参考とした。

また、技術以外の要素としても、セキュリティ動向に目を向けることへの啓発という観点から、セキュリティの知識があると解けるような問題も準備。
たとえば近年流行っているパスワードリスト攻撃を使って堅牢なサイトの情報を抜いたり、昨今に騒がれた攻撃手法(ShellShock, HeartBleed などなど)で情報を取得するといった、ググれば攻略できるけど知っていないとダメなものや、少ない手間でも大きな被害が出ることを体感できるものを用意した。

採点方法

脆弱性発見方法は、CTFと同じように Flagワードを発見しサブミットする方式とすることで、大幅な採点簡略化を実現できた。
問題は修正問題の採点だった。実際に修正したものをどうやって採点するのか？
これは、採点自動化の施策として、社内で推奨される構成管理ソフトでのコミットをhookして、Jenkinsを使ってSeleniumの試験をまわす仕組みを導入した。
参加者がソースコードを修正したら自動でビルド・デプロイがかかり、試験が走って回答チームのOK/NGが出るという仕組み。
これにより、当日の稼働を大幅に削減でき運営をスムーズにすることができた。

f:id:f_rin:20170903174237p:plain

会場準備

NWの引き回しとか会場全体のレイアウトなどはやってもらっていた。ガラが出来上がったところから準備に加わったが、会場を見たら壮観だった。
ｗｋｔｋしながら当日の環境準備に参画。だがすべてうまくいくわけではなかった。

平等性を確保するために参加者PCを運営側で準備した。だが修正問題のAPがエラーなくビルドできるために整備し、参加者分のPCに構築するのがえらく大変だった。全て作りきってからクローンを作るようにすればよかった…
自動採点のテストパターンが足りておらず、全部通しの試験で動作しない。これは2日前の夜に顔が真っ青になった。試験ﾀﾞｲｼﾞﾀﾞﾖ試験（開発する会社で何当たり前のこｔ（ｒｙ

環境差異による問題も起こっていて、普段の業務とそうでない場合の意識の違いがこんな問題を生むことを身をもって知る体験をした。

当日

大会は業務時間で開催する。説明や表彰なども考えると、純粋な競技時間はそんなに長くない。
環境面の問題などは想定内のことが多く、着々と対応しながら順位を見たりチームの様子を見たり背中をかいたりしていた。
問題ページでヒントを出すタイミングを考えるのも面白い。

ひとつ失敗したと思ったのが、性能問題だった。
100人にいかないまでも、それに近い人数からアクセスが来る。
これは想定はしていても十分な性能試験ができておらず、たまに繋がりにくい状態になったりして、ここにも課題があると感じた。

実際にやってみての気付き

良かったところ

幅広く出題したけど「あ、実はうちの会社ここのジャンルは強いんだな。」とか意外なことがわかったりして、勉強にもなり新鮮だった。
CIツールを使って試験を自動でまわす仕組みは、自動化をよくやっている知り合いに手伝ってもらって導入したが、思ってたよりも簡単に運用でき、使い勝手も良く優秀だった。これは日常業務でも導入しようと思う。
Writeupを見るのって楽しい。これは、書く側でなく見る側になったのは始めてだったが、見るだけでなんだか嬉しくなる。自分が作ったものに真剣に取り組んでくれていることに、少しこみ上げるものがあった。
人脈が広がった！実は会社には年齢関係なく興味を持ってる人がたくさんいて、俺らもっと繋がれるじゃん！という刺激を大いに受けた。

次回への反省

試験の少なさがネックだった（機能試験、性能試験、本番リハすべて）。開催前数日の大変さに顕著に出てしまって、次回へのノウハウがガッツリと溜まった。
本業の片手間で取り組んだこともあり、しっかりと腰を据えて最初から最後まで見れたわけではなかった。これが原因で課題が出てきたりして、もっと専念しながらこういう営みをできるような働きかけを会社に対してできると良かった。
参加者以外への配慮。これは、リアルタイムでのスコアボードへの反映だったり、周りから見て中で何をやっているのか見えるようになる仕組みだったり。こういった配慮ができると、より周囲を巻き込んで盛り上がることができたと思う。

その他思ったこと

今回は「開発」というスコープの中で開催したわけだが、実際は張感のある中で顧客説明や解析を実施する場面もある。Hardening のような形式とするのも、今後の検討事項としてはありかもしれないと思った。
反省でも書いたけど、外の人が気軽に見れるようにする工夫はやはり必要だ。せっかく大勢を巻き込んでいるので、参加者意外への配慮はもっとしていくべきだと思った。参加していなくても「セキュリティって面白いんじゃない？うちでももっと力入れようよ！」って思えるように。
作ることで見えることが多かった。次、たとえば今回出場して満足した人がいたら、今度は作り出す側で出てみたら良いんじゃないか。より多くの人が関われて裾野がどんどん広がっていくんじゃないかな。