「WordPressのJSが改竄された話」の３本目です。（この話はこれで終わりです。）
このインシデント対応について振り返り、教訓として再発防止方針をまとめてみました。

対応経緯と対策の図

①＜未然防止＞コンテンツ提供に不要な資材は全て削除しよう

当たり前レベルなので、お恥ずかしいですが、できていなかったので反省点です。
セットアップ用のスクリプト類、未使用のプラグイン、テーマ等を削除しました。

以下、徳丸先生の記事から引用。

WordPressのプラグインDuplicator 1.2.40以前にリモートコード実行の脆弱性
一般論としても、このようなセットアップ用のスクリプト類は、セットアップ完了後はただちに削除すべきですし、セットアップ中も外部からアクセスできないように、アクセス制御すべきです。

プロダクトで利用中のソフトウェアの脆弱性情報をウォッチして
早めにセキュリティホールを塞げるような仕組みを作りましょうって話です。

具体的な仕組み化は検討中ですが、今考えているのは、Slackのチャンネルに関連性の高い脆弱性情報が流れてくるような仕組み化を検討しています。

※「情報源の選定」と「フィルターの仕組み」がまとまれば後日、記事を書くかもです。

この③以降は、事後いかにして影響を極小化することを焦点にした対策です。

今回はHTML内に不正なJSが埋め込まれる形のコンテンツ改竄だったので、
ポートの死活監視、URL監視では検知が難しく、それ以上の改竄を検知する高度な監視設定を行う必要があります。例えば、HTML差分で検知する方式など。

※以下サイトが改竄検知の概要がまとまっていて理解が進みました。
参考-Webサイト改ざんの検知の仕組みとは？

サービスレベルによって Too Much にならないようバランスを意識して監視内容を決めれば良いと思っています。ちなみに今回被害にあったこのサービスではサービスレベルがそこまで高く求められないため、改ざん検知の仕組みは導入しない予定です。

異常検知後は、できるだけ早いリカバリ・同じ攻撃をされないような対策に迫られると思います。
主に、以下２つの手がかり情報を明らかにしたり、推測するなりして、インシデント対応を進める形になると思います。

手がかり１．どのファイルがどんな変更をされたのか？
手がかり２．どのような攻撃手法で変更されたのか？

手がかり１については、
その1 にも書きましたが、手軽に改ざん箇所を知る手段として、リリース後に資材をgit管理化にする対策を予定しています。

手がかり２については、
サーバログ、持ちうる脆弱性情報を元に、仮説検証する形で攻撃手法を推測する進め方なので
特定できるか難しいかもしれません。(私はさっぱりで周囲にセキュリティに明るい方がいないのもあり Qiita に情報提供を求めました。)

※ Linux ログ種別のインデックスとして参考になった記事を張っておきます。
/var/log以下のログ一覧

今回サーバ側で任意のPHPコードが実行される状態になりましたが、
AWS EC2 Roleに与えていた権限をある程度絞っていた、セキュアな情報にアクセスできないサーバだったので、情報漏えい、過剰な請求被害、AWS内のリソース破壊等はされずに済みました。

基本的な話ですが、必要最小限のアクセス権限に絞った権限設計をすることで、
もし、侵入・コードインジェクトされた時の影響範囲を最小限に留めることができます。

インシデント対応は突然やってくる。
サービスレベルに見合った防衛策を。ノーガードはダメ。