fsi-ransomware-detect

Files (10)

• SKILL.md
• SKILL_ja.md
• 01-detection-strategy.md · references/
• 01-detection-strategy_ja.md · references/
• 02-log-analysis-and-investigation.md · references/
• 02-log-analysis-and-investigation_ja.md · references/
• design-proposal-template.html · report-templates/
• evaluation-report-template.html · report-templates/
• roadmap-detail-template.html · report-templates/
• template-spec.md · report-templates/

SKILL.md (first lines)

---
name: fsi-ransomware-detect
description: >-
  Provides design/assessment support for the detection/analysis aspect of ransomware countermeasures on AWS, for financial services organizations. Use when: (1) designing a detection/analysis posture from scratch, or (2) assessing an existing posture for gaps. Covers service impact detection (resource/service/synthetic/application monitoring), security attack detection (Amazon GuardDuty, third-party products), alert-triggered root-cause triage (manual checks) for external attacks, log-based analysis (Amazon Detective, SIEM on OpenSearch, infection checks), detection aggregation/delegated admin, and forensic vendor engagement prep. Activate on ransomware detection, service monitoring, attack detection, GuardDuty, or incident investigation mentions. Do NOT use for protection/backup, evidence preservation/forensics/isolation, on-prem detection, or unclear phase -- use fsi-ransomware-overview first. Target: FSI detection/analysis staff, incl. security/infra/DevOps and risk/compliance.
license: MIT No Attribution
metadata:
  author: aws-jp-fsi-sa
  version: "1.0"
---

# Ransomware Countermeasures for Financial Institutions: Detection and Analysis (Detect)

## Overview

This skill supports the design and existing-posture assessment of the posture for "detecting" damage and threats and "analyzing" detected events, within the ransomware countermeasures that financial services industry organizations build on AWS. What this skill provides:

- Design support for detection of service impact (whether the mechanism can quickly detect service impact, going beyond resource monitoring to service monitoring, synthetic monitoring, and application-level monitoring (business metrics))
- Design support for detection of security attacks (Amazon GuardDuty protection plans, third-party products)
- The concept of initiating the incident response process triggered by alerts, and design support for the root-cause triage (manual checks) that determines, after an alert, whether it is caused by an external attack (ransomware, etc.)
- Design support for analysis and investigation of detected events (analysis of suspicious activity via Amazon Detective / SIEM on Amazon OpenSearch Service leveraging already-collected logs, and checking for signs of infection)
- Aggregation and delegated administration of detection and analysis (centralizing organization-wide detection and management by aggregating into a security account)
- The positioning of advance preparation for engaging forensic vendors when the analysis bar is high
- A phased design/improvement roadmap for the detection and analysis posture based on the above, and the generation of customer-facing reports

The scope this skill covers:

- Focuses on the "Detect" phase of ransomware countermeasures, and in addition to detection, covers the analysis of detected events
- The Protect, Respond (response/isolation), and Recover phases are handled by separate skills
- The design of log collection and protection is within the scope of the Protect phase; this skill operates on the premise of "leveraging already-collected logs"
- Executing evidence preservation, full-scale forensic analysis, and isolation are within the scope of the Respond phase; this skill covers up to "organizing the scope handled in-house versus the scope delegated to specialist organizations, and bridging to preservation and specialist investigation"
- Detection of impact/attacks in on-premises environments is out of scope. On-premises detection is mainly realized through a combination of on-premises monitoring products, antivirus products, forensic tools, and operations, rather than being efficiently realized with AWS services, so it is not handled by this skill

The detailed guides and report generation templates of this skill are stored in the `references/` folder and the `report-templates/` folder at the same level as this skill file. When a workflow's processing steps instruct you to "refer to references/XX" or "refer to report-templates/XX," search for the relevant file using the following procedure, load it, and then compose your response.

1. Try `.kiro/skills/fsi-ransomware-detect/{references,report-templates}/` under the workspace
2. If not found, try the user-level `~/.kiro/skills/fsi-ransomware-detect/{references,report-templates}/`
3. If neither is found, ask the user for the deployment path of this skill

Even if loading a reference or template fails, do not compose a response based on general knowledge alone; always inform the user of the situation before deciding how to proceed.

This skill is designed to ensure the accuracy of responses by referring to official AWS documentation. When using it, we recommend setting up the AWS Documentation MCP server in advance (see the README.md attached to this skill for setup instructions).

## Reference Foundations

This skill is structured to complement the design considerations required in the context of financial institutions, based on the following authoritative sources. Links are kept, in principle, at the service-top / major-category level; deep references to individual features are made as needed within the body text and references/.

### Official AWS guidance (comprehensive best practices)

- AWS Well-Architected Framework — Operational Excellence pillar, "Implement observability" (the core of the monitoring/observability concept)
- Choosing an AWS monitoring and observability service (AWS Decision Guide; guidance on selecting monitoring services)
- AWS Observability Best Practices (per-service monitoring recipes)
- AWS Security Incident Response guide (the flow from detection to analysis)

### Per-service official documentation

- Amazon GuardDuty
- Amazon Detective
- Amazon OpenSearch Service (SIEM on Amazon OpenSearch Service)
- Amazon CloudWatch
- AWS Security Hub

### Reference in the context of financial institutions

- IPA "Strengthening the upstream process of system development (Non-Functional Requirements Grades)" (a reference for the concept of designing monitoring levels according to system importance; the project has ended, but the deliverables remain publicly available)

## Common Tasks

### 0. Classify the Request

From the user's question, tentatively select a workflow using the following correspondence.

| User intent | Workflow |
|---|---|
| Want to newly design a detection/analysis posture for ransomware damage in an AWS environment / want to consult on where to start | A |
| Want to assess the sufficiency of an existing detection/analysis posture as a ransomware countermeasure, identify gaps, and improve | B |
| Want an overview-level understanding of detection/analysis best practices / want to drill down interactively for learning purposes | C |
| Want pinpoint, in-depth consultation on a specific detection/analysis topic (service monitoring, attack detection, GuardDuty, log-based analysis/investigation, etc.) | D |

However, since there are many cases where the workflow cannot be uniquely determined from the user's question alone, always confirm interactively with the user "which of the following directions to proceed with" before moving to the appropriate workflow. Specifically, present a confirmation message such as the following. This confirmation message MUST always begin with a statement that this skill covers only Detect among the five areas (see DT-C13). As shown in the example below, output the grouping headings in bold and choices A–D as a Markdown list, preserving this structure; do not collapse it into a single plain-text paragraph (see DT-C14).

> This skill covers "Detect" among the five areas of ransomware countermeasures (Protect, Detect, Respond, Recover, Organization), supporting the design and evaluation of detecting damage/threats and analyzing detected events. If you have questions about other areas, please request the corresponding skill.
>
> Before answering your question, let me confirm which direction to proceed in. In addition to "detecting" ransomware damage/threats, this skill covers the "analysis" of detected events (executing evidence preservation, full-scale forensic analysis, log collection design, and on-premises detection are out of scope for this skill).
>
> **[Generates a design/assessment report]**
> - A. Build the overall design of a detection/analysis posture from scratch
> - B. Assess the sufficiency of an existing detection/analysis posture as a ransomware countermeasure (assess/improve the existing posture)
>
> **[Interactive guidance]**
> - C. First get an overview-level understanding of detection/analysis best practices (drilling down interactively, and guiding to workflows A/B/D as needed)
> - D. Want pinpoint knowledge of a specific topic (service monitoring, attack detection, GuardDuty, log-based analysis, etc.)
>
> Which direction does it mainly correspond to? Please also let me know if multiple apply.

Based on the user's response, proceed to the appropriate workflow.

### 1. Common hearing items

Used in common across workflows A, B, C, and D. These are items for grasping the "requirements, landscape, and policy" that serve as the premise for designing and assessing the detection/analysis posture; they are not items for assessing the current state of detection/analysis maturity itself (the current maturity is handled by the Workflow B-specific current-state hearing items DT-HB1–DT-HB5). The required/recommended classification differs per workflow. Because the design of log collection/protection and account structure design themselves are within the scope of the Protect phase, this skill's hearing is limited to the scope necessary for detection/analysis design.

| # | Hearing item |
|---|---|
| DT-H1 | The in-use resources that are the main targets of infection detection. The focus points of detection design are the resources where the customer's workloads (applications) or data directly run/are stored and which are subject to checks for malware infection or ransomware damage (e.g., Amazon EC2 / Amazon ECS / Amazon EKS / AWS Fargate / Amazon S3 / others). This is the premise for considering the coverage of attack detection and the selection of protection plans |
| DT-H2 | Multi-account structure / organizational structure (whether AWS Organizations / Control Tower is used, the scale in number of accounts, the presence of a security account. This is the premise for designing aggregation/delegated administration of detection/analysis). Account structure design itself is within the scope of the Protect phase |
| DT-H3 | Existing monitoring/security infrastructure and continuation policy (the presence and continued-use policy of existing monitoring infrastructure (centered on Amazon CloudWatch or a third-party monitoring product), EDR / AV, SIEM, etc. This is the premise for a detection/analysis design that leverages existing assets. Here, rather than assessing the sufficiency of maturity, grasp the presence/policy as a premise to incorporate into the design). Log collection/protection itself is within the scope of the Protect phase |
| DT-H4 | Forensic analysis implementation policy (whether the analysis/investigation of detected events will be (a) performed in-house, (b) with the outlook of cultivating analysis skills within the organization, or (c) delegated to external forensic vendors with specialist skills. Combinations are possible. Depending on the policy, whether to place the design's center of gravity on developing an analysis platform or on advance preparation for vendor engagement changes) |

When confirming target resources in DT-H1, the handling of detection differs depending on the nature of the resource. (1) Compute (Amazon EC2, Amazon ECS, Amazon EKS, AWS Fargate, etc.) is an execution environment where malware execution/infection can occur, and is the main target of runtime threat detection and malware scanning (for AWS Fargate as well, the in-container execution environment and data are the customer's workloads, so it is treated the same as other compute as a target of infection checks). (2) Storage (Amazon S3, Amazon EFS, Amazon FSx, etc.) is a target of data encryption/destruction/exfiltration; Amazon S3 is a direct target of detection, while Amazon EFS / FSx, etc., are covered by detection on the mounting compute and by log-based analysis/investigation. (3) Managed services (Amazon RDS, Amazon Aurora, Amazon DynamoDB, AWS Lambda, etc.) are not environments where the user manages the OS/runtime and where virus files are executed, so runtime malware detection (infection checks) is out of scope for this skill; data and suspicious access are caught by log-based analysis/investigation and by the Protect phase (some services provide mechanisms to detect suspicious access; see references/01-detection-strategy.md for details). The direct targets of malware scanning are, as of this writing, Amazon EC2 (EBS) and Amazon S3, but because the supported scope changes with feature enhancements, confirm against the latest version of the official Amazon GuardDuty documentation when making design proposals/assessments.

### 2. Workflow A: Overall design of the detection/analysis posture

#### Trigger conditions

Handles questions such as "I want to newly design a detection/analysis posture for ransomware damage in an AWS environment," "I want to build the detection mechanism from now on," and "I want to consult on where to start." If the purpose is to assess/improve an existing posture, select Workflow B.

#### Goal

Upon completing Workflow A, the user has obtained the following:

1. A design proposal for a posture combining detection through continuous monitoring (service impact / security attacks) and the analysis/investigation of detected events

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

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