Technical Recovery Plan (TRP) Exercise in a Cloud-Native Environment: Practical Lessons ...
Masanori Morino (KINTO Technologies Corporation)
Overview
In an era where ransomware attacks are increasingly sophisticated and impactful, organizations are compelled to rigorously test their recovery capabilities. Masanori Morino from KINTO Technologies Corporation presented a compelling case study at FIRSTCON, detailing a Technical Recovery Plan (TRP) exercise conducted in a purely cloud-native environment. This talk, titled "Technical Recovery Plan (TRP) Exercise in a Cloud-Native Environment: Practical Lessons...", provided invaluable insights into KINTO Technologies' proactive efforts to bolster their resilience against cyber threats, specifically ransomware.

Key moments
- 3:00 Motivation: Toyota Financial Services ransomware attack
- 5:30 Crucial precondition: ransomware undetected for days
- 8:00 Analyzing ransomware risks to Amazon RDS database
- 13:30 Choosing Point-In-Time Recovery for database restoration
- 16:00 Key finding: Cloud backup alone is insufficient
- 18:00 Critical lessons: privileged access, recovery SLA
- 19:30 DR exercises reveal plan gaps, not just test them
Technical Recovery Plan (TRP) Exercise in a Cloud-Native Environment: Practical Lessons from a Ransomware Recovery Drill
Speakers: Masanori Morino, Product Security & Governance, KINTO Technologies Corporation / Toyota Financial Services
Conference: FIRSTCON
YouTube: https://www.youtube.com/watch?v=Ades1PlinhU
Overview
In an era where ransomware attacks are increasingly sophisticated and impactful, organizations are compelled to rigorously test their recovery capabilities. Masanori Morino from KINTO Technologies Corporation presented a compelling case study at FIRSTCON, detailing a Technical Recovery Plan (TRP) exercise conducted in a purely cloud-native environment. This talk, titled "Technical Recovery Plan (TRP) Exercise in a Cloud-Native Environment: Practical Lessons...", provided invaluable insights into KINTO Technologies' proactive efforts to bolster their resilience against cyber threats, specifically ransomware.
The impetus for this exercise was a real-world ransomware incident that affected a European subsidiary of Toyota Financial Services in 2023. This direct experience underscored the critical need for KINTO Technologies, a second-tier subsidiary of Toyota, to validate their own recovery strategies. While cloud environments are often perceived as inherently more resilient and easier to restore from, the talk highlighted the crucial distinction between theoretical capability and proven operational readiness, especially when faced with complex scenarios like delayed detection of an intrusion.
Morino's presentation delved into the meticulous preparation, execution, and subsequent lessons learned from their ransomware recovery drill. It offered a candid look at the challenges of orchestrating a large-scale recovery effort involving multiple teams (security, DBA, cloud infrastructure, DevOps) and the discovery of critical gaps in their existing plans, emphasizing that such exercises serve not just to test a plan, but to reveal its deficiencies. This article will provide a detailed technical analysis of KINTO Technologies' TRP exercise, its findings, and the broader implications for cybersecurity defenders.
Background
▶ Watch: Motivation: Toyota Financial Services ransomware attack (3:00)
The cybersecurity landscape has seen a relentless increase in the frequency and sophistication of ransomware attacks. For large, interconnected organizations like the Toyota Group, such incidents can have far-reaching consequences, impacting operations, reputation, and financial stability. The critical event that catalyzed KINTO Technologies' initiative was the 2023 ransomware attack on a European subsidiary of Toyota Financial Services. This incident served as a stark reminder that even well-established enterprises are vulnerable, prompting a group-wide directive to strengthen security postures, including rigorous patch management and robust backup strategies.
KINTO Technologies operates exclusively in a cloud-native environment, without any on-premise infrastructure. This operational model often leads to a perception that recovery from incidents, particularly data loss or corruption, is straightforward due to the inherent resilience and backup capabilities offered by cloud providers. However, Morino articulated a crucial gap: despite having backup mechanisms in place, KINTO Technologies had never actually tested their full recovery plan in a realistic, emergency scenario. There was no empirical proof that their theoretical recovery capabilities would translate into effective action when it mattered most.
The core problem addressed by this exercise was the lack of validation for their Disaster Recovery (DR) and Technical Recovery Plan (TRP) in a cloud context. Specifically, the team wanted to understand if they could recover effectively when a significant period (several days) elapsed between the initial ransomware infection and its detection. This "time gap" is a common and challenging aspect of real-world ransomware incidents, as it complicates simple backup restoration and often necessitates more complex data recovery strategies. The exercise was designed to bridge this knowledge gap, moving from an assumed state of readiness to a validated, battle-tested recovery posture.
Key Findings
▶ Watch: Analyzing ransomware risks to Amazon RDS database (8:00)
The TRP exercise yielded critical insights into KINTO Technologies' recovery capabilities and highlighted areas for significant improvement. The speaker structured the findings around three key tests and four important lessons learned.
Exercise Test Results:
- TRP Procedure Correctness: The primary objective was to validate the technical recovery procedures. The outcome was positive: all four participating teams—Security, DBA, Cloud Infrastructure, and DevOps—successfully executed their respective TRP playbooks without errors. This indicated that the documented procedures were technically sound and understandable by the relevant teams.
- Encrypted Data Recovery: This was a partial success. The database was successfully restored to a pre-encryption state using Point-in-Time Recovery (PITR). However, any data that had been updated after the PITR point but before the detection of the ransomware could not be automatically recovered via cloud backups. This updated data required a separate, manual recovery process performed by the product team using their own specific TRP. This finding underscored a critical limitation: cloud-level backup alone is insufficient for comprehensive recovery in complex ransomware scenarios, necessitating additional product-level recovery mechanisms.
- Incident Response Manual Effectiveness: The existing incident response manual was found to be partially effective. While the overall framework worked, specific procedures within the manual were identified as outdated. This highlighted the continuous need for maintenance and regular updates to incident response documentation to ensure its relevance and accuracy.
Lessons Learned:
Beyond the direct test results, the exercise revealed four crucial lessons that extend beyond the technical execution:
- Improve Communication: During the exercise, communication primarily relied on text-based chat platforms like Slack. This proved inefficient for a large, multi-team effort, making it difficult to maintain synchronized understanding across 70 participants. The lesson was to integrate video conferencing tools (e.g., Teams, Zoom) for better real-time interaction and clarity during critical incident response activities.
- Streamline Information Sharing: Related to communication, the chat-only approach led to information fragmentation, making it challenging for late joiners or those needing a quick overview to grasp the current situation. The team identified the need for a shared, centralized document to provide real-time updates and a single source of truth for incident status and actions taken.
- Protect Privileged Accounts: The exercise scenario involved the compromise of a normal user account. While this led to significant damage, the team recognized that if a privileged account (e.g., an administrator account) had been compromised, the potential for harm would have been far greater and recovery significantly more complex. This reinforced the critical importance of robust Privileged Access Management (PAM) strategies.
- Define Recovery SLA with Stakeholders: The scenario forced a critical business decision: accept some data loss from the period between the PITR point and detection, or invest significant manual effort to recover it from logs. This is not solely a technical decision but a business one. The lesson was to proactively define Service Level Agreements (SLAs) for recovery, including Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), in consultation with business stakeholders before an incident occurs. This ensures that technical teams understand the business's acceptable level of data loss and downtime.
Masanori Morino concluded this section by emphasizing a profound personal realization: a DR exercise is not merely about testing a plan, but about discovering what your plan is missing. The exercise uncovered unexpected gaps, such as the extended time required for data recovery, reinforcing the absolute necessity of conducting such drills regularly, even in seemingly secure cloud environments.
Technical Deep Dive
▶ Watch: Choosing Point-In-Time Recovery for database restoration (13:30)
The core of KINTO Technologies' TRP exercise involved a meticulous preparation phase and a detailed technical execution, focusing on a realistic ransomware scenario in their cloud-native environment.
The preparation phase, spanning from January to April 2024, involved five key steps:
- Defining Preconditions: The most critical precondition established was a multi-day delay between ransomware infection and detection. This was paramount because it immediately invalidated simple "restore from latest backup" strategies, forcing the team to confront data loss and recovery challenges over a prolonged period. This made the exercise significantly more challenging and realistic.
- Selecting the Target Product: For their inaugural exercise, KINTO Technologies chose a system with a relatively simple architecture and minimal external dependencies. The chosen target was a monthly billing calculator for their car subscription services, comprising a basic web application and a database backend. This allowed the team to focus intensely on database recovery, which was identified as a primary concern.
- Creating the Exercise Scenario: The scenario was carefully crafted to simulate a plausible ransomware attack:
- An employee's device is infected with ransomware.
- Over several days, the attacker leverages the infected device to compromise a maintenance EC2 server, which functions as a jump server for accessing the database.
- Through this jump server, the attacker encrypts data within the Amazon RDS MySQL database.
- Crucially, due to the delayed detection, a simple restoration from the most recent clean backup would result in the loss of legitimate data modified after the last clean backup point. The TRP needed to address this data gap.
- Writing the Technical Recovery Plan (TRP): The product team developed a specific TRP to address the unique challenges posed by the delayed detection and encrypted database. This plan focused on how to recover data that could not be restored via standard backups.
- Preparing the Test Environment: A dedicated internal shared test environment was reserved to ensure the exercise could proceed without impacting production systems.
Ransomware Risks to Amazon RDS MySQL
A key technical consideration was understanding how ransomware could impact an Amazon RDS MySQL database. The team analyzed three specific risks:
- Data Destruction: RDS instances do not allow direct file-level access to the underlying storage. Even with elevated database privileges, an attacker cannot directly delete or corrupt the physical database files. Therefore, this risk was deemed not possible.
- Data Compromise: If an attacker gains control of a database user account, they can execute standard SQL commands such as
UPDATE,DELETE,DROP TABLE, orTRUNCATE TABLE. This can lead to data modification, deletion, or schema destruction. This risk was deemed possible. - Data Encryption via SQL Functions: An attacker could use SQL functions like
AES_ENCRYPT()or custom encryption logic to encrypt data values within columns, one by one. This is essentially a form of data compromise where the data remains, but becomes unreadable without the decryption key. This risk was also deemed possible.
Given these analyses, the TRP specifically focused on mitigating data compromise and data encryption risks within the RDS database.
TRP for the Compromised Jump Server (EC2)
The scenario included a compromised EC2 jump server. The TRP for this server outlined a three-step process:
- Isolate: Immediately disconnect the compromised EC2 instance from the network, blocking all inbound and outbound traffic. This prevents further lateral movement or data exfiltration.
- Preserve for Forensics: Before any other action, take a snapshot of the EC2 instance. This preserves the compromised state for detailed forensic analysis, which is crucial for understanding the attack vector and scope.
- Provision New Server: Create a clean, new EC2 instance from a trusted, clean machine image. Apply appropriate security groups and configure it according to the TRP, ensuring it is secure before re-establishing access to the database.
Database Recovery Strategies: Backtrack vs. PITR
For database recovery, two primary Amazon RDS strategies were considered:
- Backtrack: This feature allows an Amazon Aurora database to "rewind" to a previous point in time, essentially undoing unwanted changes. However, Backtrack has a significant limitation: it can only revert changes up to a maximum of six hours. In KINTO Technologies' scenario, where "several days" had passed between infection and detection, Backtrack was not a viable option. Furthermore, Backtrack modifies the existing database cluster.
- Point-in-Time Recovery (PITR): This feature allows restoring an RDS database to any specific second within a defined retention period (up to 35 days). Crucially, PITR works by creating a completely new database cluster from a backup and applying transaction logs up to the specified point. This was the ideal tool for the exercise's scenario, as it could restore to a point before the attacker's actions, even days prior. A significant advantage of PITR is that the original, potentially compromised database cluster remains intact, which is invaluable for forensic investigations.
Based on these comparisons, PITR was selected as the primary database recovery mechanism for the exercise.
Exercise Execution
The exercise itself took place on April 10, 2024, from 1:00 PM to 6:00 PM JST. It was conducted entirely online via Slack, involving 70 participants across four distinct teams: Security, DBA, Cloud Infrastructure, and DevOps. This collaborative, multi-team approach was essential for simulating a realistic incident response, requiring coordinated efforts to isolate, analyze, and recover compromised systems and data.
Demo / Proof of Concept
▶ Watch: Critical lessons: privileged access, recovery SLA (18:00)
While the talk did not feature a live technical demonstration in the traditional sense, the entire Technical Recovery Plan (TRP) exercise served as a comprehensive proof of concept for KINTO Technologies' ransomware recovery capabilities in a cloud-native environment. The exercise effectively "demonstrated" the practical application of their TRP and the chosen recovery strategies under simulated attack conditions.
Specifically, the exercise demonstrated:
- TRP Execution: The successful execution of playbooks by all four participating teams (Security, DBA, Cloud Infrastructure, and DevOps) validated the clarity and effectiveness of their documented procedures. This real-world "walkthrough" proved that the written plan could be translated into coordinated action.
- Cloud Recovery Mechanism Efficacy: The use of Amazon RDS Point-in-Time Recovery (PITR) was demonstrated to be an effective technical mechanism for restoring the database to a state prior to encryption, even with a multi-day delay. This confirmed the utility of cloud-native recovery features.
- Identification of Recovery Gaps: The exercise highlighted the need for manual, product-level data recovery for data updated between the PITR point and detection. This implicitly demonstrated that while cloud services provide robust foundational recovery, application-specific data integrity and recovery often require additional, tailored processes.
- Operational Challenges: The exercise exposed challenges related to communication (Slack-only) and information sharing (lack of a centralized status document), thereby demonstrating the operational complexities inherent in large-scale incident response.
In essence, the exercise itself was the "demo," providing tangible evidence of what worked, what didn't, and what needed improvement in KINTO Technologies' ransomware recovery posture.
Defensive Implications
▶ Watch: DR exercises reveal plan gaps, not just test them (19:30)
The insights gleaned from KINTO Technologies' TRP exercise offer crucial defensive implications for any organization operating in a cloud-native environment, particularly concerning ransomware preparedness.
- Beyond Cloud Backups: Embrace Product-Level Recovery: The most significant takeaway is that relying solely on cloud provider backups (like RDS snapshots or PITR) is often insufficient for comprehensive recovery in complex scenarios, especially with delayed detection. Organizations must develop and test product-level recovery plans that account for data modified between the last clean backup and the incident detection. This might involve recovering data from application logs, transaction journals, or other specific data sources not covered by standard infrastructure backups.
- Continuous Validation Through Realistic Exercises: Regular, full-scale DR exercises are not optional; they are essential. The exercise's focus on a "multi-day delay" between infection and detection is a critical element of realism that should be incorporated into all drills. These exercises must be designed not just to confirm existing plans, but to actively uncover gaps and unforeseen challenges.
- Prioritize Privileged Access Management (PAM): The scenario highlighted the potential for devastating impact if a privileged account were compromised. Organizations must implement robust PAM solutions to minimize the attack surface for high-privilege credentials, enforce least privilege, and incorporate multi-factor authentication (MFA) everywhere possible. This includes granular controls over jump servers and direct database access.
- Establish Clear Recovery SLAs with Business Stakeholders: Technical teams often face difficult decisions during recovery, particularly regarding potential data loss versus recovery effort. It is imperative to define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) with clear business input before an incident. This allows technical teams to make informed decisions that align with business continuity requirements and acceptable risk levels.
- Strengthen Incident Communication and Information Sharing: Effective incident response is as much about communication as it is about technical execution. Organizations should establish clear protocols for real-time communication (e.g., dedicated video conference channels) and centralized information sharing (e.g., shared incident war room documents) to ensure all stakeholders are synchronized and informed.
- Maintain and Update Incident Response Documentation: The finding that some procedures in the incident response manual were outdated underscores the need for continuous review and updating of all incident response and recovery documentation. This should be an iterative process, ideally informed by post-mortem analyses of exercises and real-world incidents.
- Forensic Readiness and Preservation: The TRP's emphasis on isolating compromised servers and taking snapshots, as well as the PITR's ability to leave the original database cluster intact, highlights the importance of forensic readiness. Preserving the compromised environment is crucial for root cause analysis, understanding attacker tactics, and preventing future incidents.
- Understand Cloud Service Nuances: A deep understanding of cloud provider features and their limitations (e.g., the 6-hour limit of RDS Backtrack vs. the 35-day capability of PITR) is vital for selecting appropriate recovery strategies. Cloud architects and security teams must be intimately familiar with these specifics to design resilient systems.
By integrating these defensive implications into their security strategies, organizations can significantly enhance their resilience against ransomware and other destructive cyber attacks, moving beyond theoretical preparedness to validated operational readiness.
Key Takeaways
- Cloud backups alone are insufficient: While cloud services offer robust backup capabilities like Amazon RDS PITR, they often don't cover all data integrity and recovery needs in complex ransomware scenarios, especially with delayed detection. Product-level, application-specific recovery plans are essential.
- Realistic exercises are critical for discovering gaps: DR exercises should simulate challenging, real-world conditions (e.g., multi-day detection delays) to expose weaknesses in plans and processes that might otherwise remain hidden.
- Effective communication and information sharing are paramount: During an incident, clear, real-time communication via video calls and centralized, shared documentation is crucial for coordinating diverse teams and maintaining situational awareness.
- Privileged Access Management (PAM) is a foundational defense: Protecting privileged accounts is vital to limit the extent of damage an attacker can inflict, as compromise of such accounts can severely complicate recovery efforts.
- Define Recovery SLAs with business stakeholders proactively: Business decisions regarding acceptable data loss (RPO) and downtime (RTO) must be made before an incident, guiding technical teams on the appropriate level of recovery effort.
- Incident response documentation requires continuous updates: DR plans and incident response manuals are living documents that must be regularly reviewed and updated to remain relevant and effective.
About the Speaker(s)
Masanori Morino is a seasoned professional with a rich background in technology and cybersecurity. He began his career as a web application engineer, spending many years working on systems such as web analytics and e-commerce front-end development. Over the past decade, his focus has shifted to cybersecurity and security governance.
Currently, Masanori holds roles at both KINTO Technologies Corporation and Toyota Financial Services, where his expertise is concentrated on product security and security governance. His experience spans both the practical implementation of secure systems and the strategic oversight of security practices within large corporate structures. His presentation at FIRSTCON reflects his deep understanding of real-world security challenges and the practical measures required to address them.
Reviews
Dr. Zero (Offensive Security Researcher) — SOLID
Honest, well-structured case study of a ransomware recovery drill in AWS. The value is in the candid 'here's what we thought would work and didn't' moments, not in any novel technique. Fills a slot for defenders who've never run a real tabletop, but offers little to teams who have.
Heather Calloway (CISO) — STRONG ACCEPT
This is exactly the kind of exercise every security program claims to run but rarely does with this level of rigor. The candor about what broke—communication, data gaps, outdated playbooks—is more valuable than the confirmation that PITR works. I'd point my IR and resilience leads at this.
→ Top-rated talks at FIRSTCON26 — 38th Annual FIRST Conference