Disaster Recovery

5 automated security scanners

DR Plan Assessment

Purpose: The DR Plan Assessment Scanner is designed to evaluate the security posture of disaster recovery (DR) plans by analyzing their accessibility and documentation. It aims to identify public documents that reveal critical system dependencies, operational procedures, and performance metrics, thereby exposing potential vulnerabilities to adversaries.

What It Detects:

DR Documentation Detection: Identifies publicly accessible DR plan documents, including business continuity plans and recovery policies.
Recovery Procedure Exposure: Uncovers publicly available runbooks, step-by-step guides, and checklists that outline recovery procedures.
DR Commitment Disclosure: Reveals Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), which can set attacker timelines if disclosed.
DR Infrastructure Details: Exposes information about recovery sites, failover destinations, system architecture, and technology stacks used in the DR plan.
DR Testing Documentation: Identifies publicly accessible schedules for DR testing, drill documentation, test results, and audit reports.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) that represents the target organization’s website or network.

Business Impact: Publicly accessible DR plans can lead to unauthorized access to critical system information, aiding targeted attacks and potential data breaches. Disclosure of recovery times and points can also influence attacker strategies by setting their timelines for disruption efforts.

Risk Levels:

Critical: If public documents reveal detailed operational procedures or infrastructure details that could be exploited by adversaries, this poses a significant risk to the organization’s security posture.
High: The exposure of recovery times, points, and other critical information can set attacker timelines, making it difficult for organizations to defend against targeted attacks.
Medium: While less severe than critical or high risks, medium severity findings indicate potential vulnerabilities that should be addressed to improve the overall security of the DR plan.
Low: Informative findings suggest minimal risk unless coupled with other indicators of compromise.
Info: These are generally non-critical findings and do not pose immediate threats but can provide valuable insights for ongoing security monitoring and improvement.

Example Findings:

A publicly accessible DR plan document reveals detailed steps for a specific recovery procedure, potentially aiding an attacker in planning targeted attacks.
An organization’s RTO and RPO commitments are disclosed on a public website, setting clear timelines that adversaries can exploit during disruptions.

This documentation provides a comprehensive overview of the DR Plan Assessment Scanner’s purpose, detection capabilities, required inputs, business impact, risk levels, and potential findings based on typical scenarios it might identify in practice.

DR Orchestration

Purpose: The DR Orchestration Scanner is designed to evaluate and analyze the disaster recovery (DR) orchestration capabilities of a given domain. It aims to identify automated recovery systems, test failover orchestration endpoints, check for recovery automation tools, determine the exposure of the orchestration platform, and detect weaknesses in automated recovery processes that could affect the speed of failover.

What It Detects:

Orchestration Platform Detection: The scanner identifies various disaster recovery tools such as Ansible, Terraform, Puppet, Chef, SaltStack, Zerto, Site Recovery Manager, AWS Orchestration, and Azure Orchestration. It also detects failover automation systems and checks for orchestration APIs to assess the exposure of the platform.
Automated Failover Systems: The scanner checks for automated failover endpoints, identifies trigger mechanisms for failovers, verifies status dashboards related to health checks, and explores dependencies in the failover process.
Recovery Workflow Automation: It identifies tools used for automating recovery workflows, detects playbook automation, examines sequence orchestration, manages dependencies, and coordinates multi-system recoveries.
Orchestration Technology Stack: The scanner identifies vendors of orchestration tools, detects cloud orchestration services like AWS CloudFormation and Azure Systems Manager, checks for Kubernetes/container orchestration, and explores the use of infrastructure-as-code tools.
Recovery Coordination: It tests endpoints for coordinating recovery efforts across multiple systems, tracks statuses during the recovery process, and identifies handoff processes between different systems.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) that represents the target system to be analyzed.

Business Impact: Poor disaster recovery orchestration can significantly delay response times during a failover scenario, increase the risk of data loss due to uncoordinated actions, and extend downtime periods. This directly impacts business continuity and can lead to substantial financial losses or reputational damage. Effective DR orchestration is crucial for ensuring that systems can be quickly recovered in case of an outage, thereby minimizing operational disruptions.

Risk Levels:

Critical: The scanner identifies critical vulnerabilities in the automated recovery process that could halt failover operations entirely. This includes missing automation, lack of testing, and significant gaps in orchestration capabilities.
High: High-risk findings involve slow or inefficient failover processes due to manual intervention, inadequate coordination between systems, and exposure of orchestration platforms without proper security measures.
Medium: Medium-severity issues pertain to potential delays in recovery workflows caused by missing automation tools or incomplete testing. There is a moderate risk of data loss or extended downtime if not addressed promptly.
Low: Low-risk findings are generally informational, such as the detection of legacy systems using outdated orchestration tools that do not pose immediate threats but should be considered for future upgrade paths to enhance security and performance.
Info: These are primarily informative about the presence of certain technologies or endpoints without significant impact on DR operations.

Example Findings:

The domain lacks any automated recovery processes, requiring manual intervention for every failover scenario, which significantly increases recovery time and introduces human error risks.
There is no documented test plan for existing automation tools, leading to uncertainty in the effectiveness of the failover mechanism during a disaster event.

Data Recovery Testing

Purpose: The Data Recovery Testing Scanner is designed to assess the readiness of an organization in terms of data recovery processes by evaluating various aspects such as backup system detection, recovery documentation accessibility, evidence of recovery testing, and identifying weaknesses that could hinder effective restoration during incidents.

What It Detects:

Backup service endpoints and verification portals are identified to ensure they are accessible and functioning correctly.
Recovery documentation, including runbooks and procedures, is checked for completeness and accessibility.
The scanner detects the presence of recovery testing schedules, drill announcements, and metrics related to Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Backup technology stack analysis includes identification of vendors, cloud services used, encryption status, replication mechanisms, and any exposure vulnerabilities in these systems.
Indicators of automation and orchestration processes for data recovery are tested to ensure they are functional and efficient.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) which serves as the primary target for the scanner’s analysis.

Business Impact: Poor data recovery testing can lead to significant risks including untested backup failures during actual recovery, delayed restoration due to missing documentation, inadequate system configuration preventing effective recovery, and increased downtime resulting from lack of validation processes. These issues directly impact business continuity planning and execution.

Risk Levels:

Critical: The scanner identifies critical gaps in data recovery testing that could lead to significant risks such as untested backup systems failing during actual recovery or delayed restoration due to missing documentation.
High: High risk is associated with inadequate system configuration preventing effective recovery, which can result in substantial downtime and impact business operations significantly.
Medium: Medium risk findings involve weaknesses in automation and orchestration processes that might delay the recovery process but do not pose immediate critical threats.
Low: Low risk findings are informational in nature and indicate minor issues such as outdated documentation or non-critical system configurations, which generally have minimal impact on business operations.

Example Findings:

The scanner identifies a backup service endpoint that is incorrectly configured and does not support the required authentication mechanisms for recovery processes.
A critical recovery procedure document is found to be inaccessible due to permissions issues, potentially delaying disaster recovery efforts significantly.

DR Testing Regime

Purpose: The DR Testing Regime Scanner is designed to assess the effectiveness of disaster recovery testing practices by analyzing various aspects such as test schedules, evidence of testing completion, and scope coverage. Its primary objective is to identify potential gaps in testing that could lead to inadequate preparedness during real-life disasters.

What It Detects:

Testing Schedule Detection: Identifies the presence of disaster recovery testing schedules and drill calendars within a domain’s documentation or metadata.
Testing Evidence: Checks for reports or evidence indicating completed tests, which is crucial for understanding the effectiveness of the recovery processes.
Testing Scope Assessment: Evaluates whether the tested systems cover both full end-to-end scenarios and component-level details to ensure comprehensive coverage.
Testing Frequency Analysis: Analyzes the frequency with which testing is conducted, including annual, quarterly, monthly, and continuous testing patterns.
Testing Quality Indicators: Assesses the presence of documentation around lessons learned, remediation plans, and improvements in future testing strategies.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) that serves as the primary target for scanning.

Business Impact: Inadequate disaster recovery testing can lead to significant risks during real disasters, including delayed response times, data loss, and operational disruptions. This can severely impact business continuity and reputation.

Risk Levels:

Critical: If no DR tests are documented at all or if the documentation is incomplete and does not disclose any scheduled tests, this poses a critical risk as it indicates a complete lack of preparedness for potential disasters.
High: Missing test schedules or insufficient testing evidence can be considered high risks since they suggest poor preparation and inadequate awareness of potential issues that might arise during recovery operations.
Medium: Partial coverage in testing or inconsistent frequency of tests may lead to medium risk, as it implies a lack of thoroughness in the disaster recovery planning process.
Low: Continuous monitoring and detailed reporting on lessons learned can indicate low risk if there is evidence of continuous improvement and effective handling of issues post-test.
Info: Informational findings such as planned testing schedules that are not yet evidenced could be considered for informational purposes, highlighting future commitments to improving recovery practices.

Example Findings:

“No evidence of disaster recovery tests documented on the website.”
“Quarterly DR drills are mentioned in documentation but no specific dates or outcomes disclosed.”
“The site claims annual testing but lacks any historical data or reports to support this claim.”

This structured output provides a clear, user-friendly overview of what the scanner aims to detect and assess, along with its implications for security posture and potential risk levels.

Recovery Time Testing

Purpose: The Recovery Time Testing Scanner is designed to analyze and validate recovery time objectives (RTOs) and recovery point objectives (RPOs) within an organization. Its primary purpose is to ensure that there are adequate measures in place for testing and validating the recovery times of critical systems, which can help mitigate risks associated with untested RTOs, missed recovery objectives, and delayed business resumption during actual disasters.

What It Detects:

RTO/RPO Testing Evidence: The scanner identifies documentation that demonstrates tests have been conducted to measure RTOs and RPOs.
Recovery Speed Metrics: It checks for any disclosures or claims regarding the speed of recovery, including failover times and recovery durations.
Recovery Performance Testing: The scanner looks for evidence of performance testing that verifies the claimed recovery speeds and identifies weaknesses in the validation process.
Recovery Time Claims: It examines any guarantees or commitments made by the organization regarding recovery times and ensures these are supported by adequate evidence.
Recovery Validation Processes: The scanner tests for ongoing monitoring, tracking, and reporting processes related to recovery time objectives.

Inputs Required:

domain (string): A fully qualified domain name (e.g., ekkatha.com) that represents the target system or service being assessed.

Business Impact: Inadequate recovery time testing can lead to significant risks, including untested RTOs failing during actual recovery processes, gaps in recovery validation becoming apparent too late, and increased downtime due to unverified recovery speeds. These issues can directly impact business continuity and customer trust, potentially leading to substantial financial losses and reputational damage.

Risk Levels:

Critical: This severity level is reached when there are no RTO/RPO testing evidences found despite the presence of claims or disclosures regarding such tests. It indicates a critical gap in security practices that could lead to severe consequences during disaster recovery scenarios.
High: This risk level applies when there are missing endpoints for recovery time validation, which suggests inadequate infrastructure setup for continuous monitoring and assessment of recovery capabilities.
Medium: Medium severity is assigned when there are detected but unverified claims about recovery speeds or times without sufficient evidence to support these assertions. It signals a need for more thorough testing and verification.
Low: This level is used for informational findings that do not directly impact critical business functions but still highlight areas for improvement in the organization’s disaster recovery strategy.

Example Findings:

“RTO/RPO values are disclosed, but no evidence of testing was found.”
“The domain does not have any endpoints dedicated to recovery time validation; this poses a significant risk as it indicates a lack of proactive measures for assessing and improving recovery capabilities.”

This structured documentation provides a clear overview of the scanner’s purpose, what it detects, the inputs required, the business impact, and potential risk levels based on the findings. It is designed to help security teams understand the scope and implications of using this scanner in their environment.