mcpField
T
testing-ransomware-recovery-procedures

testing-ransomware-recovery-procedures

github.com/mukul975セキュリティ35.2k113 回インストール8 週間前に更新
リポジトリ

testing-ransomware-recovery-procedures について

隔離環境での復元テスト、机上演習、実地訓練を通じて、ランサムウェア復旧計画を検証するスキルです。復旧・セキュリティチームがRTOとRPOを測定し、復元データやアプリケーションを確認して課題を記録できます。進行中のインシデント対応には使用しません。

主な機能

  1. 01システム階層と復旧目標に沿った範囲設定
  2. 02隔離された復旧環境の準備
  3. 03復元とサービス再開時間の測定
  4. 04復元データとアプリケーションの検証
  5. 05復旧後のセキュリティ制御の確認
  6. 06RTO/RPOの差分記録

活用シーン

  1. 01暗号化を想定したバックアップ復元テスト
  2. 02業務上のRTO/RPO目標に対する復旧測定
  3. 03ランサムウェア復旧訓練の実施
  4. 04災害復旧準備状況の監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill testing-ransomware-recovery-procedures

インストール後、Claude Code で/testing-ransomware-recovery-proceduresを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
references/
api-reference.md
scripts/
agent.py

詳細

ランサムウェア復旧手順のテスト

使用する場面

次の場合にこのスキルを使用します。

  • ランサムウェア復旧計画が現実的な条件下で実際に機能することを検証する場合
  • RTO（目標復旧時間）とRPO（目標復旧時点）をビジネス要件と照らし合わせて測定する場合
  • 暗号化をシミュレーションした後、バックアップからの復元操作をテストし、データの整合性と完全性を確認する場合
  • ランサムウェアのシナリオを想定した机上演習や実地復旧訓練を実施する場合
  • コンプライアンス要件やサイバー保険の要件に関連して、災害復旧への準備状況を監査する場合

ランサムウェア攻撃が発生している最中のインシデント対応には使用しないでください。専用のIRプレイブックを使用してください。

前提条件

  • 隔離された復旧テスト環境（エアギャップ環境またはネットワーク分離されたラボ）
  • バックアップインフラストラクチャへのアクセス（Veeam、Commvault、Rubrik、AWS Backup、Azure Backup）
  • ビジネスインパクト分析に基づき、アプリケーションの各ティアについて文書化されたRTO/RPO目標
  • 復元テストに利用できるバックアップコピー（本番環境のレプリカまたはテスト用スナップショット）
  • 重要な各システムについて、手順を段階ごとに記載した復旧手順書

ワークフロー

ステップ1：復旧テストの範囲を定義する

重要なシステムと、ティアごとの復旧目標を特定します。

ティアシステムの種類RTO目標RPO目標例
ティア1ミッションクリティカル< 1時間< 15分Active Directory、コアデータベース
ティア2ビジネスクリティカル< 4時間< 1時間ERP、メール、CRM
ティア3ビジネス運用上重要< 24時間< 4時間ファイル共有、内部アプリ
ティア4重要度が低い< 72時間< 24時間開発／テスト、分析
ステップ2：テスト環境を準備する
# Verify isolated recovery network is segmented
# No routes to production should exist
ip route show | grep -v "192.168.100.0/24"  # recovery VLAN only

# Verify backup catalog is accessible
restic snapshots --repo s3:s3.amazonaws.com/backup-bucket --password-file /etc/restic/pw
# Or for Veeam:
# Get-VBRBackup | Where-Object {$_.JobType -eq "Backup"} | Select Name, LastPointCreationTime
ステップ3：復元を実行し、RTOを測定する

ティアごとの各システムについて、復旧にかかる全時間を測定します。

  1. 検知から判断まで - シミュレーションしたアラートから復元の判断までにかかる時間
  2. バックアップの特定 - 適切なクリーンな復元ポイントを特定して選択するまでにかかる時間
  3. 復元の実行 - バックアップからデータ／VM／アプリケーションを復元するのにかかる時間
  4. 検証 - データの整合性とアプリケーションの機能を確認するのにかかる時間
  5. サービスの復旧 - システムが完全に稼働するまでの時間
Recovery Timeline Measurement:
  T0: Incident declared (simulated ransomware detection)
  T1: Recovery team assembled and backup identified
  T2: Restore initiated from clean backup
  T3: Restore completed, integrity checks passed
  T4: Application validated and service restored

  Actual RTO = T4 - T0
  Actual RPO = T0 - backup_timestamp
ステップ4：復元後のデータ整合性を検証する
# Compare file counts between backup manifest and restored data
find /restored/data -type f | wc -l
# Compare against pre-backup manifest

# Verify database consistency after restore
pg_isready -h localhost -p 5432
psql -c "SELECT count(*) FROM critical_table;" -d restored_db

# Hash verification of critical files
sha256sum /restored/data/critical_config.xml
# Compare against known-good hash from backup manifest
ステップ5：認証情報のローテーションとセキュリティ強化をテストする

復元後、セキュリティ制御が再確立されていることを検証します。

  1. すべてのサービスアカウントのパスワードとAPIキーをローテーションします
  2. すべての管理者アカウントでMFAが有効になっていることを確認します
  3. EDR／AVエージェントが稼働し、管理コンソールにレポートを送信していることを確認します
  4. ファイアウォールルールが既知のC2インジケーターをブロックすることを検証します
  5. 復元したシステムに最新のセキュリティパッチが適用されていることを確認します
ステップ6：結果を記録し、ギャップを算出する
Recovery Test Report:
  System: [Name]
  Tier: [1-4]
  RTO Target: [target]    Actual RTO: [measured]    Gap: [delta]
  RPO Target: [target]    Actual RPO: [measured]    Gap: [delta]
  Data Integrity: [PASS/FAIL]
  Application Validation: [PASS/FAIL]
  Security Controls Restored: [PASS/FAIL]

  Status: [MEETS TARGET / EXCEEDS TARGET / FAILS TARGET]
  Remediation Required: [description if FAILS]

主要な概念

用語定義
RTO目標復旧時間：災害発生後にシステムが許容される最大停止時間
RPO目標復旧時点：時間で測定した許容可能な最大データ損失
WRT作業復旧時間：復元完了後にシステムの整合性を検証する時間
MTD最大許容停止時間：許容できないビジネスへの影響が発生するまでの絶対的な限度
クリーンな復元ポイントランサムウェアの痕跡や暗号化がないことを確認したバックアップ
復旧の順序相互に依存するシステムを復元する必要がある順序
エアギャップバックアップネットワークから物理的に切り離されたメディアに保存されたバックアップ

ツールとシステム

ツール用途
Veeam Backup & ReplicationVMおよび物理サーバーのバックアップと復元
Commvaultエンタープライズデータ保護と復旧オーケストレーション
Rubrikランサムウェア復旧SLAを備えたクラウドネイティブのバックアップ
AWS BackupAWSサービス向けの一元化されたバックアップ
Azure Backupイミュータブルな保管庫を備えたMicrosoftクラウドのバックアップ
Resticオープンソースの暗号化バックアップツール
VeleroKubernetesクラスターのバックアップと復元

よくある落とし穴

  • 復元テストを定期的に行わない：一度もテストされていないバックアップは、必要なときに失敗することがよくあります。最低でも四半期ごとにテストしてください。
  • 復旧の順序を無視する：データベースに依存するアプリケーションを、データベースより先に復元すると、連鎖的な障害が発生します。
  • 認証情報のローテーションを省略する：復元したシステムに侵害された認証情報が残っていると、再感染につながるおそれがあります。
  • テストに本番ネットワークを使用する：本番ネットワークで復旧テストを行うと、シミュレーション上の感染や実際の感染が広がるリスクがあります。
  • WRTを考慮せずにRTOを測定する：復元の完了は、復旧の完了を意味しません。検証とセキュリティ強化にかかる時間も含めてください。
  • イミュータブルバックアップがない：ランサムウェアによってバックアップが暗号化または削除されると、復旧できません。エアギャップストレージまたはイミュータブルストレージを使用してください。

参考資料

コメント

Markdown 対応