S-Owl

S(ecurity)Owl

2018/07/06-07「Hardening II Collective」参加記録

先日、Hardeningに参加してきました。その内容と振り返り等を記録として残します。
参加して貴重な体験ができたことを、関係者の皆様に感謝いたします。

Hardening Project 2018 Hardening II Collective
https://wasforum.jp/hardening-project/

 

■参加のモチベーション
会社の同僚が以前に参加しており、HardeningProjectの存在は知っていました。
今回はじめて応募したのは、インシデント経験や自組織の技術レベルの伸びなさ等がきっかけになって、自分自身が個人としてセキュリティの業界で戦えるだけの技術を身につけなくてはいけない、と思うようになったからです。
インシデントレスポンスの経験値を積みながら、自分に足りない技術を認識したい、というのがモチベーションです。


■イベントの内容
HardeningProjectはざっくり言うと「脆弱なECサイトをハードニング(堅牢化)しながら、次々と来る攻撃から防御・復旧させながら売上を競う」もの。
毎回やり方を変えているらしいですが、今回は1チーム11人という大人数でCEO、経営BU、営業BU、技術BUに分かれ、現実の組織の壁の再現やコミュニケーションコストの増加が新規ポイントだったようです。


■やったこと
技術BUとして参加しました。主にMPの対応、活用が多かったです。
技術者の多くないチームだったためMPを活用する方針を取り、主にFWの導入による主要ポート以外の遮断とWAFの導入による攻撃の遮断とhttps化がチーム戦略の中心でした。
WAF経由以外の通信をFWで遮断したり、WAFの検知状況を確認し遮断強度を上げる等、MPを活用したハードニングは上手く実施できていたかと思います。
ただ、サービスに必要な通信全てを開けられていたかは不明です。実際のところどうだったかの解説はないので…。
最終的には攻撃は人手でさばくことが出来ない程の量が来ていたので、MPを活用するというのは最善の手だったかなと思っています。
MP導入、対応に追われ基本的なパスワード変更、バックアップ取得等が全サーバ、全ミドルウェアに対して実施できていなかった、というのは反省点です。
BU間の連携は一般的なレベルでは問題なく取れていたかと思います。
深いレベルで言えば、この設定入れたけどSLAどう変わるか見ておいて、というようなやり取りが出来ていると良かったなとは思います。

 

○終盤の得点グラフ(最終段階は非公開のため終盤のもの)
f:id:Sec-Owl:20180731013725p:plain

○Webアクセスログ件数(ただしアクセスログファイルの一部の可能性あり)
(FW誤設定による全断時間や終盤のアクセス件数の多さ)
f:id:Sec-Owl:20180731013556p:plain

f:id:Sec-Owl:20180731013621p:plain

○終盤のWAFの遮断件数と帯域
f:id:Sec-Owl:20180731013758p:plain

 

■求められる人材
主に技術BUに関してですが、ハードニングで活躍できる人材を求められる人材と考えた場合、
ハードニングはどうやって環境を堅牢化するか、ですので、インフラの技術者が求められています。
有効な技術としては、NW>OS>Web>DB>セキュリティ、くらいの感覚です。
セキュリティの技術はなくてもセキュリティの観点があれば大丈夫です。
診断やマルウェア解析の技術が役に立つ場面はほぼありません。そのスキルを身につける過程で身につけたインフラのスキルの方が役に立ちます。


■参加をオススメする人
今回のようにいくつかの組織に分かれている場合、ですが、
技術BUには他社のIRを行うような組織、相手先の環境も分からないままIRに入るような業務であれば活かせると思われます。
また、セキュリティエンジニアよりはインフラエンジニアの方が向いています。
それ以外のCEOや経営BUには主にCSIRTに属する人が向いていると思われます。


■イベントを振り返って
サイバーレンジと思って参加しましたが、どちらかと言うと、CTFに近い競技です。
あくまで、売上を競う“競技”であり、演習ではない、というのが参加しての印象です。
また、運営はノリで攻撃を決めており、明確な目的を持ったシナリオに基づいた攻撃ではなかったのも意外でした。
イベントの成熟度としては、規模は大きいですが、Compassで実施しているような有志の勉強会と同じく身内ノリと感じました。


■改善点
参加者にとってあると良かったと思うのは、以下の2点です。
・評価のオープン性
 どういった項目をどれだけの重みで評価したのか、それが公開されないため、納得感がなかったです。
 特に振り返り会でも不満が溢れていたところです。
 技術点○点、というのもどんな項目のうちどこの項目が評価されたのか、知りたいです。
 販売額は振り返り会で公開されたたけでしたし、見込み販売額はどのような評価項目でどれだけ増減したかオープンされませんでした。
 そのため何を評価したのか公平性がなく、穿った見方をすると恣意的な評価とも取れます。
・振り返りの機会の提供
 競技環境は当日のみしか利用できませんでした。後日種明かしをされても、それが競技環境にどのように現れていたのか、振り返って調べる機会がありませんでした。
 攻撃手法も幾つかは公開されましたが、攻撃側もノリによって攻撃シナリオを決めているようで細かいところまで説明できない、という感じでした。
 分からなかった攻撃を、攻撃手法を認識し再度環境を調査することで手がかりを見つけ、次の攻撃の対策に活かす、というのが最も成長できる機会だと思います。
 スキルアップのために是非とも、攻撃シナリオの公開と振り返りの為の環境の提供をしていただきたいと思います。


■学んだこと
・今回のような標的型ではない、どちらかというと一般的な攻撃の場合であれば、やはり遮断できる機器(FW,WAF等)はしっかりとチューニングしつつ即座に遮断できるよう運用することは大事だなと思います。
 特に終盤に来たような脆弱性を突く攻撃によるDoSのような場合、遮断できる機器がないと人手では対応できません。
 実際に攻撃者に執拗に狙われた場合にはそういったことも起こりうると考えられ、ビジネスリスクを考慮しながら如何にバランスをとって判断するかがインシデント対応では重要になるなと感じました。
・参加者やMPもやはりそれぞれ得意なセキュリティスキルがあり、フルスタックで持っている人は少なく、それぞれのスキルをいかに組み合わせて対応するかが重要だと感じました。
(今回の競技はあまりそういう形ではなかったですが)
・環境を熟知しておくことの大事さを再認識しました。
 どんな構成になっているか分からない、どんな機能があるかわからない、という環境では自信を持って判断をすることは難しく、場当たり的な対応になってしまい深掘りした対応ができないです。
 そのシステムにどんな脅威が想定されるか、通常はどんな通信が発生しているか、等を普段意識せずに実施できるようになっていることが、対応・判断の早さに繋がっていると実感できました。

 

以上。