Frequently Asked Questions

Product Information & Case Study Details

What was the objective of the DDoS testing for the Central American bank on AWS?

The main objective was to validate the bank's DDoS protection status for its IT infrastructure hosted on Amazon Web Services (AWS). The bank specifically wanted to test the effectiveness of AWS Shield Advanced and its ability to mitigate application-level DDoS attacks targeting a mobile application published via AWS API Gateway. The test aimed to ensure that configurations were correct and that the system could withstand real-world attack scenarios. Note: The test focused on application-level (Layer 7) attacks and did not cover all possible DDoS vectors.

Which AWS services and configurations were involved in the DDoS testing?

The bank's environment included AWS Shield Advanced with Layer 7 automatic mitigation enabled, integrated with several application load balancers, Route 53, CloudFront distributions, and Elastic IP addresses. The API Gateway was responsible for publishing the mobile application API and handling TLS termination. Note: The Web Application Firewall (WAF) was present but not configured with relevant rules for the test.

What types of DDoS attacks were simulated during the test?

Red Button simulated six application-level (Layer 7) attack vectors, focusing on different types of HTTPS floods. The goal was to test how these attacks would be detected and mitigated by the bank's AWS-based defenses. Note: The test did not include volumetric or protocol-level attacks outside of Layer 7.

What were the main findings from the DDoS simulation on AWS?

The test revealed that all simulated attacks succeeded in bypassing AWS Shield Advanced due to an improper configuration of the API Gateway (using Regional API Gateway without CloudFront). Most attacks were absorbed by the API Gateway only because of the low attack rates used; higher rates would have reached the origin servers. A simulated GET flood attack, using valid API requests, bypassed all protection layers and caused service downtime. Note: These results highlight the importance of correct configuration and layered defense.

What is the DDoS Resiliency Score (DRS) and what score did the bank receive?

The DDoS Resiliency Score (DRS) is a numeric value provided by Red Button after testing, indicating the types of attacks a system can withstand and those it cannot. In this case, the Central American Bank received a DRS of 4.0, compared to a recommended score of 6.5 for the banking industry. Note: The DRS is specific to the tested environment and attack scenarios.

What recommendations did Red Button provide to strengthen the bank's AWS DDoS protection?

Red Button recommended deploying CloudFront in front of the API Gateway to enable Shield Advanced automatic mitigation for application-layer attacks, creating a rate-limit-based rule in the Web Application Firewall (WAF), and implementing a Scanners and Probes protection component to automatically detect and block suspicious traffic. Note: Effectiveness depends on proper implementation and ongoing review of configurations.

Features & Capabilities

What types of DDoS testing and simulation does Red Button offer?

Red Button offers realistic DDoS simulations tailored to specific environments, including AWS, Azure, on-premise, hybrid infrastructure, and industry-specific needs such as financial services, gaming, and telecom. Simulations can include over 100 attack vectors and test both application-layer and network-layer defenses. Note: The scope of each test is defined with the customer and may not cover all possible attack types.

What is included in Red Button's DDoS testing service report?

After testing, Red Button provides a detailed report that includes a DDoS Resiliency Score (DRS), analysis of which attacks were mitigated or bypassed, and prioritized recommendations for improving defenses. Reports are designed to support compliance and audit requirements. Note: The depth of reporting depends on the scope of the engagement and the data collected during testing.

Use Cases & Benefits

Who can benefit from Red Button's DDoS testing services?

Organizations operating critical infrastructure on cloud platforms (such as AWS or Azure), especially in regulated industries like financial services, government, gaming, and telecom, can benefit from Red Button's DDoS testing. The service is designed for cybersecurity managers, CISOs, IT managers, and cloud architects who need to validate and improve their DDoS defenses. Note: Organizations with unique or highly customized environments should confirm test compatibility during scoping.

What business impact can be expected from using Red Button's DDoS testing?

Customers can expect improved operational resilience, reduced risk of downtime, and actionable insights for strengthening defenses. The service also supports regulatory compliance by providing audit-ready reports. Note: The actual impact depends on the organization's ability to implement recommended changes and maintain ongoing vigilance.

Implementation & Process

How long does it take to implement a DDoS test with Red Button?

The onboarding and planning phase typically takes around two weeks from kickoff to the start of the DDoS test. For AWS or Azure DDoS testing, the total customer time commitment is about five hours, including a pre-test interview, live test session, and results readout. Note: Larger or more complex environments may require additional time for scoping and approvals.

What resources are required from the customer during a DDoS test?

Customers need to provide access to their infrastructure or network security team for monitoring and authorizing actions during the test. Red Button assists with planning, execution, and obtaining any required third-party approvals (such as from ISPs or cloud providers). Note: Minimal customer effort is required for standard AWS or Azure tests.

Security & Compliance

How does Red Button support compliance with security standards?

Red Button supports compliance with ISO 27001 and SOC 2 by providing detailed technical reports, a DDoS Resiliency Score, and audit-ready evidence. Reports include actionable insights and remediation steps to help organizations meet regulatory requirements such as SAMA, MAS, and HKMA. Note: Achieving compliance depends on the organization's implementation of recommendations and ongoing controls.

Customer Success & Case Studies

Where can I find more case studies about Red Button's DDoS testing?

You can find additional case studies, including those for financial services, government, gaming, technology, and more, on the Red Button case studies page. Each case study provides details on the challenges faced, solutions implemented, and results achieved. Note: Outcomes vary based on customer environment and engagement scope.

Case Study: FINANCIAL SERVICES

Strengthening a Bank’s Protection on AWS

Strengthening a Bank’s Protection on AWS

Background

The Central American bank, which operates in several countries, wanted to test the DDoS protection status of its IT infrastructure, hosted on Amazon Web Services. While the bank was using the AWS Shield Advanced service, it wanted to validate its configurations and ability to mitigate application-level DDoS attacks. Specifically, the Central American Bank was interested in testing one of its mobile applications that is published to the internet via AWS API Gateway.

AWS Shield Advanced was configured with L7 DDoS auto-mitigation enabled and was integrated with several application load balancers, Route 53, CloudFront distributions, and Elastic IP addresses.

The Solution

The Red Button team planned a DDoS attack simulation consisting of six application-level attack vectors. Our objective was to test how different types of HTTPS floods would be detected and mitigated.

Attack vector analysis plan: Indicating which component should stop each attack vector.

Our expectation was for:

  • AWS Shield Advanced Layer 7 Automatic Mitigation to detect anomalies and perform auto-mitigation, namely, to create a new rate-limit-based rule in the defined WEB ACL.
  • The API Gateway, which is responsible for publishing the mobile-application API and for the TLS termination process, to absorb attacks that utilize the TLS flood mechanism.

We did not expect the Web Application Firewall (WAF) to block any of the simulated attacks, since it was not configured with any relevant rules.

Test Results

Attack vector analysis: Actual results

Unexpectedly, all attacks succeeded in bypassing the AWS Shield Advanced protection layer. This was due to an improper configuration of the API Gateway (using Regional API Gateway without CloudFront), which completely disabled the intended protection from AWS Shield Advanced.

Most attacks were absorbed by the API Gateway. This, however, was only due to the low attack rates used. If we were to increase traffic rates, the attacks would have bypassed the Gateway and reached the origin servers.

The simulated GET flood attack, a common applicative DDoS attack, bypassed all protection layers and took down the service. This was because it used a valid API request, unlike the other attacks.

DDoS Resiliency Score

Upon completion of DDoS testing, we provide customers a detailed report that includes a DDoS Resiliency Score (DRS) – a numeric value clearly indicating the type of attacks the system can currently withstand and more severe attacks that it cannot.

The DRS score of the Central American Bank was calculated as 4.0, compared to a recommended score (based on the threat level common in the banking industry) of 6.5.

Recommendations

Following testing, we provided several recommendations to strengthen protection:

Architecture: The top recommendation was to deploy CloudFront in front of the API Gateway to protect it with the Shield Advanced automatic mitigation service for application-layer DDoS attacks.

WAF configuration: Create a rate-limit-based rule to help detect and mitigate a large number of DDoS attack scenarios.

Automation: Implement the Scanners and Probes protection component to automatically detect and block traffic from specific IPs that receive repeated error response codes and are unlikely to be legitimate human users.