皆さんこんにちは。 インフラ開発部の田中と申します。
10月12、13日に開催された、「Yahoo! JAPAN Hardening 2017」という演習型のサイバーセキュリティイベントに参加いたしました。今回はこちらのイベントを、参加者の視点を交えながら皆さんにご紹介いたします。
Hardeningとは
「Hardening」とは、インシデントへの対応力を磨くことを目的としたサイバーセキュリティイベントです。Web Application Security Forumというコミュニティが主催する「Hardening Project」というイベントを筆頭に、近年注目が集まっています。
「Yahoo! JAPAN Hardening」は、ヤフー社内で行われるHardeningのイベントです。第2回目の本イベントでは、当社を含むグループ会社の従業員もイベント参加者の対象となりました。
本イベントでは、参加者はチームに分かれ演習中の約7時間、架空のECサイトを運営し売り上げ高を競いました。演習に用いるECサイトの環境には多数の脆弱性が含まれており、演習中は運営スタッフからさまざまな攻撃が試みられました。 それに対して各チームは、脆弱性対応や復旧作業のみならず、お客様への問い合わせ対応や広報活動までの一連のフローを実施することで、売り上げ高への悪影響を抑えます。技術だけではなく、人対人のコミュニケーションまで含めた包括的な対応能力が問われることがポイントです。
また本イベントは当社も協賛しており、演習環境は当社サービスのIDCFクラウド上に構築されていました。
演習時間中の流れ
インシデント発生前の事前対策
IDCフロンティアからは私のほかに、ビジネス開発部の金杉と永岡、広報グループの山下が参加し、ヤフー社のシステム統括本部とCS本部との合同チーム「Benkei」として演習に取り組みました。
私はBenkeiの技術担当の1人として、序盤はrootパスワードの変更やssh接続における公開鍵認証の設定など、基本的かつ優先度の高い作業に取り組みます。またSYN flood攻撃に対するSYN cookiesの有効化や、Smurf攻撃に対するブロードキャスト無視のパラメータ有効化など、対処法が確立している攻撃については、事前に作成したスクリプトを流すことでセキュア化を進めていきます。
こうした脆弱性対応の作業中も、監視サーバを通してシステムの状態をチェックしECサイトの環境に異変が起きていないことを確認します。演習開始から数十分の間は特に何事も起こらず、売り上げ高の伸びも順調です。
「事前に想定していたよりも余裕があるのかな」と考えられていたのも、最初のインシデントが発生するまででした。
怒涛のサイバー攻撃とインシデント対応
商品画像の改ざん、価格の不正操作、ECサイトのダウン……。
怒涛の勢いで押し寄せてくるインシデントを前に、チームに緊張が走ります。中盤以降はこうしたインシデントに対して暫定対処、侵入経路の特定、原因究明など、ECサイトを守るために必要な作業へと食らいついていきます。 例えば価格の不正操作へのインシデント対応であれば、管理ページから手動で価格を元に戻す操作が暫定対処、アプリケーションサーバのアクセスログ分析が侵入経路の特定、ECサイトの管理システムにおけるSQLインジェクション脆弱性の特定が原因究明にあたります。
技術担当としては、つい目の前の作業に没頭してしまいがちになりますが、これらの作業中でもサイバー攻撃は待ってはくれません。ごく単純な暫定対処でもしばらくの間しのげそうであれば、一旦そのインシデントへの対応に区切りを入れ、新たなインシデントへの対応に切り替える必要もあります。
思わぬ伏兵の出現とチーム内コミュニケーション
インシデントはサイバー攻撃だけに留まりません。
「当社ではお客様の同意なく個人情報を提供する場合がございます。ご了承ください。」
企業ページに設定されていた不適切なプライバシーポリシーに、お客様役の運営スタッフから問い合わせによる突っ込みが入ります。慌てて修正してしまいそうになりますが、黙って行えばインシデントの発生を隠蔽したと取られかねません。お詫びの文言をお客様に対して、どのように、どのタイミングで周知するのか?技術担当もコンソール上で完結する作業だけではなく、チーム内での密なコミュニケーションが必要とされるのです。
終盤付近になると、Benkeiを含む多くのチームでサイバー攻撃によるECサイトへの影響が表面化していきます。そうしたなかで、記者役の運営スタッフからの取材対応に関する相談で、思わず言葉に詰まる場面がありました。
「『SQLインジェクション』を記者に説明するにはどうすれば良いか?」
SQLインジェクションはWebアプリケーションに対する典型的な攻撃手法であり、私もその概要については理解していたつもりでした。しかし、伝える相手は非専門家の記者です。 説明に際してSQL文という語彙は使えません。かといって、限られた時間で言葉の定義を長々しく伝えることもできません。正確に、簡潔に、平易な言葉で内容が説明できて初めてそのサイバー攻撃の手法を理解していることになるのだと痛感させられた局面でした。
終了後の振り返り
終了後は緊張感も解け、談笑を交えつつチーム内でも簡単な振り返りが行われます。事前に対策できた脆弱性もあれば、最後まで尾を引いてしまうインシデントもありました。 Benkeiチームでは、ポイントが商品価格より高額な値で付与されるという改ざんへの原因究明が遅れ、売り上げ高が低下し続ける状態に陥ってしまっていました。
もう少し時間があれば、アクセスログのあの部分に着目して、WordPressのあのプラグインを調べて……と後になって思いつくこともあります。約7時間もの間、昼食の離席時間も惜しいほどに集中して取り組んでさえ、もう少しやりたかったと自然に思えてしまうほどに夢中になれる演習でした。
演習での学び
本年度に新卒で入社した、まだまだエンジニアとして未熟な私にとって、本演習は多くのことが学べる貴重な機会になりました。演習の主目的であるセキュリティ・インシデント対応への実践力はもちろんのこと、個人的には「プレッシャー下での対応作業の難しさ」という点が強く印象に残りました。例えば、前述のssh接続における公開鍵認証の設定ですが、正しく設定できているはずなのになぜか接続できないというトラブルがありました。速やかに作業を完了させなければならない局面で、何度もやったことのある作業なのにうまくいかない……一瞬、頭が真っ白になってしまいます。最終的にはチームメイトの助けもありトラブルの原因はアクセス権の問題であることが判明しましたが、当初想定していた完了時間を超過してしまっていました。
プレッシャーの影響は作業時間の超過だけに留まりません。
実は演習中、誤操作で必要なプロセスをキルしてしまい、当該サーバに一切ssh接続ができなくなるというインシデントも起こしてしまっていました。ssh接続が切断されてから、会場の専用端末でサーバを再起動するまでの間は、1秒でも早く再起動が完了しますようにと冷汗三斗の思いでした。
私はこれまでセキュリティ・イベントに参加した経験はなかったため、必要以上に緊張してしまった側面もあるかもしれません。しかし、演習にも関わらずここまで心理的な影響が出るならば、本当のインシデント対応であれば推して知るべしです。焦ってしまう場面だからこそ、チーム内で密なコミュニケーションを行い、必要に応じて確認作業を実施しなければならない、という事を、実感を伴う形で学ぶことができました。
最後に
本記事では、インシデントへの包括的な対応力が試されるセキュリティ・イベント「Yahoo! JAPAN Hardening 2017」について、その概要を感想も交えつつご紹介いたしました。もし本記事をご覧になって、本イベントの雰囲気について理解の一助となりましたら幸いです。
ご興味がありましたら、ぜひ参加してみてください。