こんにちは。freee PSIRTでマネージャーをやっています、ただただし（tdtds）です。この記事はfreee Developers Advent Calendar 2023 24日目です。昨日は最近freeeにグループジョインしたBundleのkouheiさんによる「Bundleの3年間をライブラリで振り返る」でした。
さて、「freeeでは新卒研修でHardeningをやってるらしい」という話は界隈ではちょっとは知られているものの、その内幕が伺えるのは、まだPSIRTがCSIRTから独立する前の2018年の記事しかありませんでした。
あれから5年。最近のHardening研修はどうなっているのか、アップデートしようというのが今回の記事になります。
Hardening 2023！
細かい話はあとまわしにして、さっそく今年行われたHardening研修についてみていきましょう！
freeeは毎年大きくなっていて、今年の新卒新入社員は開発者だけで20名以上。6チームにもなる大所帯です。迎え撃つPSIRTもだいぶ大きくなってはいるのですが、6チーム分の環境を用意して、攻撃を行い、採点をするのは相当たいへんです。通常業務を行いながらHardening研修の運営を行うので、期間中はかなりのハードワークになります。
新人たちはHardening本番の前に、座学でしっかりとセキュアコーディングについて学びます。従来は直前に4時間近くかけて詰め込み教育を行っていたのですが、定着率が低いという反省から、今年は1回1時間の講義を4回に分けて実施しました。内容はセキュリティの基礎から、アプリケーションの脆弱性、インフラの脆弱性、サービス監視やインシデントレスポンスまで多岐にわたります。文字どおり上から下までのフルスタックです。その他にも、自習用の教材や書籍も提供されて、事前に準備をする時間はたっぷりあります。
さて当日。いよいよHardeningのレギュレーションを伝えられます。最初に見せられるスライドがこれです：
この設定を考えたのは自分なんですが……なんど読んでもひどいですねぇ。こんな会社、とっとと逃げ出した方がいいと思うけどなぁ。まぁ、この3日間は逃げたくても逃げられないんですが。
攻撃開始！
レギュレーション説明のあとは、稼働中のサービスそのものとソースコードを与えられ、さっそくゲーム開始です。初めて触るシステム構成を把握して、脆弱性を見つけ出して塞ぎつつ、サービスを落とさないように運営しなければいけません。丸2日耐えきることを目指します。
Hardeningで使うシステムは、主にfreeeが使っている技術スタックを使って構築されています。インフラはAWS EKS、ソースコードはGitHubで管理され、アプリケーションフレームワークはRuby on Railsです。以前はfreeeのとあるサービスを改造して使っていましたが、今はどのサービスも大きくて複雑なので、研修の規模に合った専用の小規模なサービスを自作しています。また、脆弱性を見つけたらインシデントレポートを書かなければいけませんが、これもfreeeがいつも使っている様式のサブセットになっています。つまり、普段から使い慣れた技術を使って構築された未知のシステムのお守りをするわけです。
PSIRTはさっそく攻撃態勢に入ります。とはいえ序盤は探索行動程度で本格的な攻撃はしないのですが、このサービス、なぜかインターネットに公開されているので、ふらっと立ち寄った本物の悪いハッカーがいたずらをしていくこともあります。最近はロシアからのお客さんが多いですね。
次々と起きるインシデント
開始から12時間もたつと、PSIRTの攻撃も次第に激しくなっていきます。なにしろ与えられたアプリケーションは脆弱性がてんこ盛りです。XSSにCSRF、SQLインジェクション。あの手この手で侵入してはデータを改竄したり、クレデンシャルを盗み出したり。自分たちで発見した脆弱性を修正するだけでなく、攻撃によって落とされたサービスを復旧したり、盗み出されたデータの漏洩個所も突き止めて塞ぐなど、気が抜けない上にかなり忙しいです。
ずっと張り詰めた雰囲気ではつらいだろうと、PSIRTのメンバーがときおりお菓子を片手に陣中見舞いをしに行ったりもしますが、その間も攻撃の手は緩むことがありません。
研修終盤にもなると、DoS攻撃でシステムを落としたり、システムに侵入してDBを破壊したりと、容赦がありません。
採点と講評
激しい攻防(?)の末、ゲームは終了しました。実はここからが一番大変で、PSIRTのメンバーは手分けして採点にとりかかります。機械的に判断できるものは自動化していますが、インシデントレポートの評価は人間が読んで下さなければなりません。6つのチームが作成した山のようなレポートにはすべて目を通し、数時間後にすぐ講評します。
結果は、稼働率と脆弱性修正率はTeam-Aがトップ。それぞれ96%と52%でした。一方、レポートは件数がTeam-Fがもっとも多く、品質はTeam-Cが高いという結果に。毎年そうですが、突出して強いチームというのはあまりなくて、それぞれのチームの特性が出ています。
そういうチームごとの目の付け所や対応の違いをみんなでふりかえるのも大切にしています。特定のチームだけが気づいて対策した脆弱性や、大きな穴を見過ごしたばかりに破壊的な攻撃を許してしまったチームなど、特徴的なことがらを例示しながら、どう行動すればよかったのかを指摘します。
講評のあとは(もちろん)懇親会になだれ込むわけですが、そこでもHardeningでの出来事で盛り上がります。「ボコボコにやられて悔しかった」「でもすごく楽しかった」「明日からもっとがんばる」等々……明日のfreeeを背負って立つ若者たちの意気込みを聞きながら、PSIRTメンバーは「来年の新人もボコボコにしてやろう」と心に誓うのでした。
なぜfreeeは自前のHardeningをするのか
セキュリティ文脈での「Hardening」は日本語では「堅牢化」などと言われ、脆弱なサービスの穴を塞ぎ、サイバー攻撃から守りながら運営を続けるゲーム、ないし研修のことです。国内ではHardening Projectのような実績のある本格的な競技会も存在します。また、サイバー攻撃について学ぶだけなら、実際にシステムを攻撃してみるハンズオン研修などもいくつか存在します。なのになぜ、freeeでは自前のHardening研修にこだわるのでしょうか。
ひとつはなんと言っても「自社で使っている技術スタックを使える」という点です。社外の研修では、ここをそろえるのはまず不可能です。自前で環境をそろえれば、インフラから言語、フレームワーク、さらにインシデント対応プロセスまですべて「いつもと同じもの」が使えます。研修後、自分たちのチームに戻ったらすぐに研修で学んだことを活かせる。とりわけ仕事に不慣れな新卒メンバーにとって、これはかなり大きいです。
もうひとつは、サービス運用にはさまざまなチームが共同であたっていることを体験してもらうこと。freeeのエンジニアはできるだけ専門化せず、広い範囲を触れるフルスタックを目指すことを良しとしています。とはいうものの、これだけ大きな組織になり、サービスも複雑化してくると、どうしても分業が進み、自分で見られる範囲はどんどん小さくなっていきます。そうでなければ十分なスピードを維持できないので。
そうなると、他のチームの仕事を自分ごととして考えにくくなってきます。Hardening研修で、普段は他人任せになっている部分まで自分たちの手で扱うことで、自社サービス運用にどんな観点が存在しているのかを知り、そこに関わる人たちのことを想像できるようになります。
さらにもうひとつ、われわれPSIRTにとっても成長の機会になっています。日頃から多忙なセキュリティチームにおいて、実際にゼロから本格的なシステムを構築し、効果的な脆弱性を作りこむ体験はなかなかできるものではありません。新しい攻撃手法を試すプラットフォームとしても利用できるHardening環境は、セキュリティエンジニアとして格好の実験場です。自前のHardening研修は運用コストもそれなりにかかりますが、それを上回るメリットがあるので、今後も継続していきたいと思います。
明日の最終日は、jasonさんによるカッコイイお部屋の紹介！ お楽しみに！
