セキュリティ

Hardening 2017 Fes 参加レポート

瓜倉格
2017年12月21日

11 月に淡路夢舞台にて開催された Hardening Project 第 11 回目のイベント「Hardening 2017 Fes」に、マーケットプレイスとして参加してきました。
マーケットプレイスの視点から学んだことを振り返ってみたいと思います。

Hardening Project とは？

Hardening Project というイベントについて、初めて耳にする方も多いかもしれません。
主催者である Web Application Security Forum （通称 WASforum）の言葉を借りると、

「守る技術」の価値を最大化することを目指す、全く新しいセキュリティ・プロジェクト

です。

他のセキュリティ競技では、技術力に特化した CTF (Capture The Flag) が有名ですが、Hardening Project ではセキュリティ技術はあくまでビジネスを遂行するための一つの要素として位置付けています。

ルールとしては、競技者は 10 名弱のチームで架空の EC サイトを運用し、運営チーム扮する凶悪なサイバー攻撃集団（kuromame6）からの洗練された攻撃を防ぎつつビジネスの最大化を目指して競い合います。

評価項目も年々多角化しており、今回は、以下 7 つの観点で競い合いました。

見込み販売力
顧客点
技術点
対応点
経済点
協調点
引継点

そのため、顧客からのメール問合せに対応したり、在庫の補充をしたり、情報漏洩やサービス停止時には記者会見を開いたり、攻撃キャンペーンや脆弱性を発見したら JPCERT/CC や兵庫県警へ情報提供したり、実際の業務にとことん忠実です。

面白いことに、仮に情報漏洩をしてしまっても適切な記者会見を行うことができれば加点対象となります。競技と言えどもリアルな設定に、初参加の身としては驚くばかりでした。

マーケットプレイスとは？

EC サイトを構成する約 20 台の端末群には、あらかじめ脆弱性のある OS やアプリケーションなどが含まれていますが、競技者には直前まで EC サイトの環境は伝えられておらず、限られた時間の中で効率的な対策を講じる必要があります。そこで登場するのがマーケットプレイス（市場）です。

マーケットプレイス参加者は、EC サイトを防御するために必要なセキュリティ製品/ソリューションや、インシデントレスポンス支援やコンサルティングのようなサービスを販売します。競技参加者は、自分たちのチームに足りない部分や強化したい部分については、実際のセキュリティ運用と同じく外部のリソースを活用することができるのです。

今回、シスコはネットワークを守る IPS（Intrusion Prevention System）製品として Firepower 4140 を、エンドポイントを守る EDR（Endpoint Detection and Response）製品として AMP for Endpoint を携えて臨みました。日頃はプリセールスエンジニアとして携わっている製品を使って、いかに競技者の EC サイトを守ることができるのか、腕の見せ所になります。

IPS/EDR 導入イメージ

競技開始からマーケットプレイス販売まで

競技が開始すると各チームは一斉に環境の現状確認と堅牢化をします。デフォルトの弱いパスワードを変更したり、空いたままのポートを閉じたりと大忙しとなります。

しばらくしてマーケットプレイスが開店すると、わずか数分で予想を上回る 6 チームからの購入依頼を頂きましたが、残念ながら Firepower の物理ポート数の都合から 4 チームまでとさせていただきました。この場を借りてお詫び申し上げます。m(_ _)m

その後 StarBED （今回の競技環境：後述）に連絡してチームごとにインラインでの物理構成変更を実施いただき、11 時前には FMC でトラフィックおよび侵入イベントを検知しはじめていました。

FMC における Context Explorer

競技開始後の 1 シーン：支援するシスコ片山（手前）と吉池（奥）

本格稼働

Step0：運用方針

マーケットプレイス参加者も環境の詳細を知らされたのは、競技者と同じく前日でした。そのため、最初は現状把握に努めながらの作業となります。資料によると、競技環境に流れる通信は大きく 3 種類に分類できそうです。

(1) 業務トラフィック（顧客から EC サイトへの問合せなど）
(2) 攻撃トラフィック（kuromame6 が様々な方法で行う攻撃）
(3) 採点トラフィック（EC サイトの擬似的な売上を作るクローラ、安定稼働状況や評判によって売上に差がついていきます）

購入いただいた 4 チームに対して、シスコでは Firepower 4140 の管理ツール Firepower Management Center（FMC）でチームごとのルールを作って運用しながら AMP for Endpoint のインストールを進めていくという 2 本立てで進めていきました。

競技環境であれば運営チームがこの日のために準備した未知の攻撃（ゼロデイ攻撃）が多いと予測されるため、IPS のルールでは (2) 攻撃トラフィックだけを止め、逆に (1) 業務トラフィックや (3) 採点トラフィックは止めないよう慎重に運用する必要があります。

この（当たり前だけど難しい）方針に従って次のような運用をしました。

Step1：おすすめルールの生成

Firepower は、守る対象となる内側セグメントの端末や利用するアプリケーション、含まれる脆弱性などを可視化する、Network Discovery 機能を持っています。まずは、現状を可視化し学習するために Network Discovery を実行し、レコメンデーションに従ってルールを作成しました。

Step2：現場の要求の反映

Firepower はデフォルトでは各チームごとにインラインで導入され IPS によるインスペクションが主な用途となります。各チームごとに Linux の Firewall も用意されており、Firepower に IPS 機能だけを求めるか、ベーシックな Firewall 機能までやらせるかはチームの方針次第となります。

「外から中への通信は全てブロックしてください」
「ただし x.x.x.x への SSH をホワイトリストに入れてください」
「y.y.y.y と z.z.z.z の通信が通らないので Firepower で止まっていないか確認してください」

こんなやりとりをしながらチームごとの要求をルールに反映していきました。

要件は、紙に手書きしながら進めましたが、想定の倍のチームの要件を満たすのは慣れるまで大変でした。次回はルール作成の自動化やタスクのチケット管理などを検討したいです。

また、面白い取り組みとして、JPCERT / CC による脅威情報の警告があります。先ほど、脅威情報を JPCERT / CC に提供すると加点されると書きましたが、集まった脅威情報はチームやマーケットプレイスに警戒情報として共有されます。ここで共有された情報も取り入れて URL フィルタやファイル検査のためのルールをその場で作成して適用しました。

検体が FMC 上のログから得られた場合は、ハッシュ情報を AMP for Endpoint のコンソール上でもブラックリストとして登録しておくことができました。

JPCERT / CC による早期警戒情報の一例

FMC における Access Control Policy の画面

Step3：誤検知と過検知の調査

午前中から運用を開始して、14 時頃にやっと Step2 までが一通り完了しました。そこから更なる品質向上を目指す場合に考えるポイントは以下の2点です。

Allow されている通信の中に悪意のある通信がないか？
Block されている通信の中に正規の業務通信や採点通信がないか？
（余談ですが、これらは日頃セキュリティ製品のご提案をする中でお客様からよく質問されるポイントでもあります。）

しかし競技開始直後から、4 チーム合計でおよそ毎分 100 弱の侵入イベントを検知していました。未知の攻撃が多く含まれる前提で考えると “目 grep” （目視でのログ確認行為）での判断は追いつかないと判断し、FMC が自動でイベントの優先順位付けを行う Impact Flag 機能を活用することにしました。

FMC における Impact Flag ごとの侵入イベント数

FMC における Impact Flag 1 の侵入イベントテーブル表示

上のように FMC のダッシュボードで確認したところ、Impact Flag 1（=最も影響度の大きい検知イベント）のイベント数は初日の15時頃まででわずか 3 件でした。中身を確認すると、いずれも特定の外部ホストを宛先とする侵入検知イベントであることがわかりました。

今度は、宛先ホストを起点に他の通信ログを見てみたところ、ランダムに生成されたような怪しい URL への外部アクセスを Firepower が遮断していました。さらにドリルダウンしていくと、この時点で遮断されずに通過しているものも数件あったため、この外部ホスト宛ての通信はばっさり遮断するルールを追加しました。

この外部ホストとの通信の挙動は、AMP for Endpoint がインストールされた Windows 端末でも同じように追いかけることができました。ただし、AMP for Endpoint のインストールの前からすでにこのプロセスが実行されていたようで、ファイルの侵入経路を時間を遡って捉えることができなかったのは残念でした。

FMC から CSV エクスポートしたイベントログよりランダムに生成された URL の一部

AMP console における Device Trajectory から確認できた感染端末での挙動

顕著な攻撃

上記の他にも定常的に主に Web の脆弱性をつく攻撃が数多く仕掛けられていました。

XSS（Cross-Site Scripting）
/etc/passwd を狙った攻撃
WordPress デフォルト設定のままの管理者ページへのアクセス

特に、Wordpress に関する攻撃は、予め今年の環境を推測して用意したカスタムシグネチャによる検知であったため、仕込んでおいた甲斐がありました。

番外編：User-Agent kuromame6？

とあるチームから「Firewall にて不審な User-Agent からの GET が頻発しているので、Firepower のカスタムシグネチャを使って止められませんか？」との声が。コネクションイベントログで該当の通信を確認したところ、たしかに複数の送信元 IP アドレスからわざとブラウザ情報を分散させたうえで “kuromame6” という文字列を挿入されたウェブ通信が多数確認できました。

得られたログから急いでカスタムシグネチャを作成してルールを適応したところ、そのチームのスコアが Death 状態（EC サイトで買い物ができていない状態）になってしまいました。

スコアボード写真

どうやら、上記 (3) の通信、つまり EC サイトを巡回して買い物行動をエミュレートしていたクローラからの通信を止めてしまったようでした。こちらは失敗しても許される競技環境ならではの事件だったのではないかと思います。

FMC にて kuromame6 という文字列を User-Agent に持つパケットの詳細情報

競技環境について

競技期間中は WannaCry のような動きをするマルウェアや脆弱性を突く攻撃がネットワーク内を横行します。そのため競技は全て StarBED と呼ばれる仮想化基盤上に構築されたクローズドな環境にて行われ、競技者や運営者はそこに VPN 接続して競技に参加します。

最終日に発表されていた情報によると物理サーバ 81 台、仮想マシンは 541 台と非常に大規模な環境ですが、オーケストレーションの仕組みを使ってわずか 1 ヶ月強で用意してしまうようです。

まとめ

通常の環境と比べ、より多くのサイバー攻撃に晒される過酷な競技環境の中で、Firepower および AMP for Endpoint の特長を活かしながら運用することができたことは貴重な経験となりました。実際にはここに書ききれないほどの様々な気付きを得ることができましたので、次の Hardening Project への還元はもちろんのこと、個人としても日々の業務の中で活かせるよう模索していきます。

最後となりましたが、素晴らしいイベントを企画・実行された運営者ならびに競技参加者、マーケットプレイスの皆様、本当にありがとうございました。