fsi-cyber-resilience

Files (20)

• SKILL.md
• SKILL_ja.md
• README-automated-isolation-architecture.png · assets/images/
• README-backup-restore.png · assets/images/
• access-policy-setting1.png · assets/images/
• access-policy-setting2.png · assets/images/
• automated-isolation-architecture.png · assets/images/
• completed-notification.png · assets/images/
• copy-setting1.png · assets/images/
• copy-setting2.png · assets/images/
• enabling-cross-account-access.png · assets/images/
• isolated-networkacl.png · assets/images/
• restore-procedures1.png · assets/images/
• restore-procedures2.png · assets/images/
• restore-procedures3.png · assets/images/
• restore-procedures4.png · assets/images/
• architecture.md · references/
• backup-procedures.md · references/
• isolation-procedures.md · references/
• restore-procedures.md · references/

SKILL.md (first lines)

# FSI Cyber Resilience

## Workload Overview

Cyber resilience is the ability to holistically strengthen an organization's
capacity to prevent, detect, respond to, and recover from cyber attacks, on the
assumption that attacks *will* happen. The traditional "focus on prevention"
mindset must shift to "continue the business even when attacked, and recover
quickly." Defending against availability-affecting cyber events such as DDoS and
ransomware is considered especially urgent.

This asset is a **documentation-only** reference architecture for financial
institutions. It builds on the BLEA for FSI **core-banking workload** and adds
three capabilities delivered as CDK samples in that core-banking usecase:

1. **Logically air-gapped backup** — replicating AWS Backup recovery points into
   an isolated **Data Bunker account** so ransomware-infected data cannot be
   silently propagated into, or tampered with in, the backup copy.
2. **Cross-account restore to a fresh environment** — recovering in a brand-new
   **Restore account** (assuming the production data center may still be infected),
   sharing the backup via AWS Resource Access Manager (RAM) rather than granting
   direct access to the Data Bunker account.
3. **Automated network isolation** — using Amazon GuardDuty to detect Critical
   threats and a Lambda function to rewrite Network ACLs, isolating the compromised
   core-banking workload to contain blast radius.

The design explicitly assumes a ransomware scenario: because infected data could
be copied into backups, backups are logically isolated, and recovery targets an
environment completely separate from production. Reference: FSA "Guidelines on
Cyber Security in the Financial Sector," section 2.3.3 (Data Protection).

## Best Practices and Key Components

### Best Practices

- MUST: Take backups in the workload account with AWS Backup and replicate the
  recovery points into a separate, logically isolated Data Bunker account.
- MUST: Store the replicated backups in an **AWS Backup Logically Air-gapped Vault**
  so that read, modify, and delete operations are impossible during the retention
  period — even for users with administrator privileges or an attacker.
- MUST: Keep the workload account and the Data Bunker account within the **same
  AWS Organizations**, which is required for the cross-account backup copy and RAM
  sharing to work.
- MUST NOT: Access the Data Bunker account directly when a restore is needed;
  share the backup vault to the Restore account via **AWS Resource Access Manager**
  instead, to prevent unauthorized access to and tampering with backup data.
- MUST: Recover into a fresh **Restore account** on the assumption that the
  production environment is compromised, rather than restoring back into production.
- SHOULD: Rebuild application and infrastructure in the Restore account
  automatically with CDK, and automate database restore-from-backup with AWS Step
  Functions.
- MUST NOT: Automate reconnection of recovered databases to the workload; business
  impact assessment and risk judgment are required, so keep the cutover as a manual
  operational step (update the ECS task definition environment variables to point
  at the restored database, then restart the ECS tasks).
- MUST: Before starting recovery from backup, evaluate the integrity of the backup
  data.
- MUST: On a cyber event, promptly isolate affected systems and preserve evidence
  for incident investigation.
- SHOULD: Trigger automated network isolation only on GuardDuty findings of
  **Severity 9.0 or higher (Critical)**; this mechanism reacts to Critical-level
  findings only.
- SHOULD: For isolation, dynamically create a Network ACL that permits only
  communication between the workload's subnets across the two Availability Zones
  and blocks all other inbound/outbound traffic.
- MUST: Notify administrators via Amazon SNS when isolation completes, and also
  send a notification on error.
- PREFER: Insert a human decision step between the Critical notification and the
  isolation action when isolation carries business impact, rather than isolating
  fully automatically.
- WILL: Because the core-banking workload runs on Amazon ECS Fargate, the container
  host is under AWS management responsibility, so investigation scope is limited and
  the Forensic account deploy/procedure is omitted from this asset.
- MAY: Deploy a separate Forensic account for tamper detection, malware scanning,
  and verification of data integrity and application dependencies; it is out of
  scope for this workload (see the AWS Security IR forensic resources).

### Key Components

#### Workload Account

- **Component Overview**: Production account running the core-banking system (and
  similar workloads). AWS Backup takes backups here, and its backup plan is
  configured to copy recovery points to the Data Bunker account's air-gapped vault.
- **Assumed AWS Services**: AWS Backup, Amazon ECS (Fargate), Amazon Aurora,
  Amazon DynamoDB, Amazon VPC.

#### Data Bunker Account

- **Component Overview**: A logically isolated account holding the backup data. It
  hosts an AWS Backup Logically Air-gapped Vault that receives cross-account copies
  of recovery points, and shares that vault to the Restore account via RAM on demand
  rather than allowing direct access.
- **Assumed AWS Services**: AWS Backup (Logically Air-gapped Vault), AWS Resource
  Access Manager, AWS Organizations.

#### Restore Account

- **Component Overview**: A fresh account that becomes the recovery target,
  assuming production is compromised. Application and infrastructure are rebuilt via
  CDK; database restore from the shared backup is automated with Step Functions;
  reconnection of the workload to the restored database is performed manually.
- **Assumed AWS Services**: AWS Step Functions, Amazon Aurora, Amazon DynamoDB,
  Amazon ECS (Fargate), Elastic Load Balancing (ALB), AWS Resource Access Manager.

#### Forensic Account (out of scope)

- **Component Overview**: Account for tamper detection, malware scanning, and
  verification of data integrity and application dependencies on compromised
  systems. Deployment and procedures are omitted because the ECS Fargate host is
  under AWS management responsibility, limiting investigation scope.
- **Assumed AWS Services**: Not deployed in this asset; see AWS Security Incident
  Response forensic resources.

#### Automated Network Isolation

- **Component Overview**: On a Critical GuardDuty finding, an EventBridge rule
  triggers a Lambda function that creates and applies a Network ACL to the
  core-banking Protected Subnets, permitting only inter-AZ subnet traffic and

From aws-samples/sample-fsi-reference-architecture-jp, MIT-0.

More from aws-samples/sample-fsi-reference-architecture-jp