MINI Hardeningに参加しましたーセキュリティインシデントの体験から再認識したインシデント対応の基本

こんにちは。はてなでWebアプリケーションエンジニアをしているid:miki_beneです。社内では「セキュリティ会」にも参加しています。

2022年1月29日（土）に開催された「MINI Hardening Project #4.3@オンライン」に、セキュリティ会のメンバーで参加しました*1。MINI Hardeningは、与えられたシステムを堅牢化し、サイバー攻撃から守る技術を競う競技です。

当初は、セキュリティの専門性向上を目的に参加しました。しかし、競技を経て振り返ってみると、セキュリティの知識だけでなく、サービス運用で大切な意識やインシデント対応の基本に改めて気づく機会となりました。

このエントリでは、セキュリティ会でMINI Hardeningに参加したきっかけと、競技後に行った振り返りから得られたものを紹介します。

インシデントが発生する場を体験したい
- MINI Hardeningとはどういう競技か
はてなチームの取り組み方と結果
- 競技のレギュレーションと採点基準
- 項目によって明暗が分かれた結果
インシデントの現場を体験して得られたもの
参加して実感したHardening競技のよさ
- 最後に感謝を

インシデントが発生する場を体験したい

セキュリティ会では、セキュリティインシデントを防ぐため、セキュリティ関連情報をチェックし、社内に周知することを中心に活動しています。

日々の情報収集を続けるうちに、ただ注意喚起をするだけでなく、セキュリティに関する専門性を高め、セキュアな環境作りをしていきたいと考えるようになりました。そのためセキュリティ情報のレポートの輪読会などを行うなかで、セキュリティインシデントの対応を競うHardening競技の存在を知りました。

セキュリティ会のエンジニアは、普段それぞれのプロダクトを開発・運用しており、その中でシステム障害などさまざまなインシデント対応を経験しています。しかし、明確にセキュリティインシデントが発生する場を体験することで、普段とは違った知見や観点が得られるのではないか、それをセキュアな環境作りに活かせるのではないか。そう考えて、参加に至りました。

MINI Hardeningとはどういう競技か

MINI Hardeningは、与えられたシステムを参加者が堅牢化し、さまざまなセキュリティインシデントやトラブルに対応する競技です。システムはセキュリティ的に脆弱な状態で与えられるので、参加者はシステムをサイバー攻撃から守りながら、安定・継続稼動させることが求められます。詳しくはこちらの資料をご覧ください。

AWSクラスタに捧ぐウェブを衛っていく方法論と死なない程度の修羅場の価値

ISUCONに参加したことのある方なら、そのセキュリティインシデント対応版とイメージすると分かりやすいかと思います。

今回のMINI Hardening 4.3では、ソーシャルゲームのシステムを運営し、サイバー攻撃だけでなく、ゲームへのチート行為の対策にも取り組むシナリオが用意されました。

はてなチームの取り組み方と結果

参加にあたって、メンバー内で以下の目的を設定しました。

サイバー攻撃を受ける経験をし、振り返りと知見共有をする
攻撃を受けるにあたって、技術よりも対応・判断を意識する

前述の通り、当初のモチベーションはセキュリティの専門性向上でした。しかし、過去の参加エントリや事前に共有された資料から、インフラ構成やミドルウェアなど競技の技術スタックが、弊社のものと大きく異なることが分かっていました。そのため具体的な知識の獲得より、サイバー攻撃を受ける経験を大事にしようと考えました。

インシデントは、実際に経験してみないと、何が起こるのかというイメージや、対応能力が身に付きづらかったりします。今回のようにインシデントが発生しても問題がない環境で、実際に攻撃を受けてみると、攻撃のリクエストはどういったものなのか、攻撃が成功すると何をされるのか、などが経験できます。

さらに、その対応や判断を振り返ることで、実際にインシデントに遭遇した際の勘所を養えるのではないかと考えました。

この目的を定めるにあたって、技術よりインシデント対応や判断を意識するよう心掛けました。不慣れな環境では、技術的に優れた対応を取りづらい、それは予想できたので、発生したインシデントに対してどういう判断をしたのか、どういう体制で対応にあたったのか、などを意識するようにしました。

また、LayerXエンジニアブログに掲載された「Micro Hardeningに参加した話」という記事も参考になりました。

競技のレギュレーションと採点基準

今回の競技時間は5時間あり、クラウド環境に構築されたサーバー環境にアクセスし、それぞれのサーバー・ミドルウェアなどを堅牢化していきます。

競技としての評価軸には、次の3つがありました。

サービスの継続力（SLA・ゲームの課金額）
技術的な対応力
社長からの指示による対応

攻撃者（運営）は各種サーバー・ミドルウェアに対して、さまざまな攻撃を仕掛けてくるので、放っておくとサービスを安定稼動できなくなります。クローラからやってくるリクエストをたくさんさばけると得点になるので、なるべく落さずサービスを稼動させ続けることが求められます。

今回の題材はソーシャルゲームなので、アプリケーションの不具合を利用してチート行為を行うユーザー（リクエスト）が登場します。チート行為が大量に発生すると、正規のユーザーがゲームに課金する気持ちが薄れるので、課金額の点数が下がります。

また面白いことに、行った対策を報告シートに書いたり、定期的にやってくる社長からの依頼をさばくことも評価に入っています。

このようにMINI Hardeningのよいところは、堅牢化してサービスを稼動させ続けるだけでなく、サービス品質や障害報告、急な指示への対応も求められる点です。実際の業務でも、サービスの売上が立たないと意味がありませんし、インシデント時には対応だけでなくプロダクト責任者へ報告する場面があります。このように実際の業務を意識する設計が、生きた知見につながると感じます。

項目によって明暗が分かれた結果

はてなチームでは、インフラとアプリケーションで領域を分担して臨みました。具体的なことは競技のレギュレーションにより書けませんが、対応することやありそうな脆弱性を事前に予想して向かったためか、SLAにおいては高得点を獲得できました。

一方、アプリケーションの仕様の把握に手間取って、チートなどの不正行為対策がうまくできず、課金額は今一つでした。

嬉しかったのは、社長からの指示による対応や、報告シートの内容に関して、運営の方から報告が丁寧だと何度もほめられたことです。これは事前に設定した目標により、対応を意識したことがうまく働いたように思います。

結果、総合評価としては5チーム中で見事、2位を獲得できました！結果を残すことが目的ではなかったのですが、日頃のセキュリティに関する活動や、競技に対する意識が実を結んだ結果と捉えて、素直に喜んでいます。

インシデントの現場を体験して得られたもの

競技後に、参加したメンバーで振り返りを行いました。たくさんのKPTが上げられましたが、ここでは振り返りの中心となった話題をピックアップして紹介します。

攻撃者視点を持つこと

我々のチームは、SLAで高得点を獲得できました。その理由として、事前に配られた競技環境の資料から、発生しそうなインシデントを想定していたことがよかったという意見がありました。

当日に渡されるサービスが利用するシステム構成やミドルウェアなどは、事前に伝えられていました。そこから「このミドルウェアの脆弱性を利用できるんじゃないか」とか「この設定が甘いんじゃないか」などと予想し、競技開始から対策できるように準備していました。実際、多くの予想が当たり、スムーズにスタートダッシュを切れた感覚があります。

これは競技をうまく進める上でもよかったことですが、攻撃者視点の考え方ができた点が、一番よかったように思います。守る側の視点では、自分が認知しているツールや設定を、どう攻撃を受けないようにするかだけで考えがちです。

一方、攻撃者の視点では、全く違う攻撃の手法もあるのではないかと、発想が自由になり、視野が広がったように感じます。

システムのあるべき状態を意識する

SLAで高得点が取れたことの別の観点として、異常をすぐに見つけて対処できたこともあります。なぜすぐ見つけられたのかと掘り下げていくと、システムのあるべき状態を意識・把握するという観点に気づきました。

例えば、不要なポートが開いている、動かないはずのプロセスが動いているなど、あるべき状態と実態の乖離に注目したことが、素早い発見と対処につながります。

これもセキュリティに限らず、普段のサービス・システム運用で意識したい観点です。見方を変えると、システム監視の指標や閾値は、この「あるべき状態を」設定したものだと言えそうです。

振り返りでも、あるべき状態が分かっているのであれば、監視を入れられるとよかったという話が出ていました。

改めてインシデント対応の基本の大切さに気づく

振り返りの課題として最も多く上がったことは、うまく障害対応フォーメーション*2を取れず、指揮官役が機能しなかった問題でした。

我々のチームでは、インフラとアプリケーションで担当領域を分けて対応しました。この時点で、全体指揮を置いていなかったことは問題です。始めはうまく対応を進められましたが、対応すべきことが増えるにつれ、情報が錯綜したり、複数ある脆弱性のどれから手をつけるべきか判断できず、手当たり次第の対応になってしまいました。

業務における障害対応では、インシデント対応を円滑に進める体制を意識しているはずです。しかし、今回はできませんでした。この理由として、普段インシデントが発生する状況と、競技ということの違いが、意識の差を生んだと考えています。

MINI Hardeningは競技イベントなので、他チームとの点差や、制限時間といった焦りから、普段と違うことをしてしまいやすい状況にありました。また、競技では次々と発生するインシデントに対応しつつ、脆弱な部分を修正する必要があります。業務ではここまで短期間にインシデントが連続することは考えにくく、これも普段と異なる対応を取ってしまった原因になったと考えています。

以上のように、MINI Hardeningの状況と、現実に発生する状況との違いは意識しておく必要があります。しかし、焦りがあったり、フォーメーションが組めなかったりと、基本ができていなかったことも事実です。

月並な気づきですが、インシデント対応の基本の大切さと、焦りを生む状況ではそれも疎かになりがちだということを、改めて認識できました。