Tag Archives: AWS

Will Regulators Mandate Multi-Region over Multi-AZ in Cloud ?

Multi AZ datacenters

There was a time when one could simply point to the a,b,c of the three data centres in a Multi-AZ (Availability Zone) configuration as a satisfactory replacement of traditional Data Center–Disaster Recovery (DC-DR) requirements even for the regulated sectors. However, as cloud providers face more frequent outages, it’s becoming harder to consider this setup a reliable solution.

Just recently, Google Cloud (GCP) experienced a significant outage lasting about 12 hours, which took down the entire europe-west3 region in Frankfurt, Germany. The root cause was traced to a power and cooling failure, which forced a portion of a zone offline, affecting a wide range of services from Compute to Storage.

Traditionally, disaster recovery setups have involved multiple data centers designated as Primary and Secondary (or DR centers) with data replication. Often, these DC and DR are in separate cities. In the companies that I worked, these were atleast 300 kms apart. While effective, this approach is costly and challenging to maintain, with lot of administrative overhead.

This raises questions about how fintechs and other regulated sectors meet Business Continuity and Disaster Recovery (BCPDR) requirements in the cloud.

In cloud environments, redundancy can be implemented in several ways, with Multi-AZ setups being one of the simplest. Multi-AZ configurations typically involve three data centers within a city, usually spread 30-100 kilometers apart and identified as zones “a,” “b,” and “c.” Data is replicated in real-time across these zones, allowing this setup to be marketed as an alternative to traditional DC/DR arrangements. However, Multi-AZ is not a default feature; it requires opting in and incurs extra costs.

Another approach is Multi-Region, where data is replicated across geographically distinct zones, often in different seismic areas. This setup helps mitigate the risk of a single region being impacted by events such as severe flooding, prolonged power outages, political unrest, and similar disruptions.

Interestingly, some financial institutions, especially Banks are not entirely sold on Multi-AZ setups, pushing their technology partners to adopt multi-region architectures across separate seismic zones. While no regulatory body in India has mandated multi-region setups yet, it’s worth considering the distance between zones within each cloud provider:

  • Amazon AWS states that its Availability Zones are up to 60 miles (~100 kilometers) apart. Interestingly, AWS keeps the exact locations confidential, even from most employees. Source: https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html#:~:text=Availability%20Zones%20in%20a%20Region,with%20single%2Ddigit%20millisecond%20latency
  • Microsoft Azure mentions a minimum of ~400 kilometers between its AZs, which is the greatest distance among major cloud providers. Source:https://learn.microsoft.com/en-us/azure/reliability/cross-region-replication-azure#what-are-paired-regions)).
  • Google Cloud (GCP) does not publicly disclose the distances between its AZs, keeping this detail confidential. surprising!

Given these developments, regulators may eventually require multi-region setups for regulated entities and fintechs using cloud services instead of relying solely on Multi-AZ. So far, Multi-AZ has offered a relatively straightforward solution to meet compliance and audit requirements for BCPDR. However, it might be time to reconsider RTO (Recovery Time Objective) and RPO (Recovery Point Objective) expectations in cloud environments.

Any thoughts on these developments?

  • Link to the RCA: GCP Outage Incident Report https://status.cloud.google.com/incidents/e3yQSE1ysCGjCVEn2q1h)
  • Article on 12 hour outage: https://www.theregister.com/2024/10/25/google_cloud_frankfurt_outage/

 

Amazon AWS Inspector Review

I was quite excited by the prospect of using AWS Inspector as it is supposed to replaced some of the expensive tools like Nessus, Expose, Qualys etc for getting a holistic view of your infrastructure from a security perspective. Usually, it is a challenge to scan the servers /assets in the cloud. The complexities of Instant provisioning, Virtual Private Circuits (VPCs), multiple regions, different availability zones add to the license restrictions of the tools. If you are using any of the tools listed above, you could use only one scanning engine and pay up for the additional scanners. There are certain workarounds to these situations, but the results are not optimum.

Using a native tool like AWS Inspector would not only help in overcoming the technical challenges but also sensible from a commercial standpoint. Although AWS Inspector does not advertise itself to be a full-fledged Vulnerability Assessment Scanner, it does claim to help one understand the risk posture of their servers, be it public facing or privately hosted.

In their own words:

“Amazon Inspector is an automated security assessment service that helps improve the security and compliance of applications deployed on AWS. Amazon Inspector automatically assesses applications for vulnerabilities or deviations from best practices. After performing an assessment, Amazon Inspector produces a detailed list of security findings prioritized by level of severity.”

Setting up AWS Inspector needed reasonable effort as it required agent installation, asset tagging and defining of roles. The instructions provided by AWS was easy to follow.

However, I felt the reporting was below average and needed considerable improvement.

Installation & Running the Assessments:

To get started one needs to install the software agent on all the servers (ec2- instances) and initiate the scan from the AWS Web Console. The agent can be installed via command line and it is available for Linux as well as Windows flavors. Amazon Inspector requires read-only access to resources in the account

Following are the supported Operating Systems:

Linux OS:

  • Amazon Linux (2015.03, 2016.03, 2016.09)
  • Ubuntu (14.04 LTS, 16.04 LTS)
  • Red Hat Enterprise Linux (7.2)
  • CentOS (7.2)

Windows OS:

  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2

Supported AWS regions:

  • US West (Oregon)
  • US East (N. Virginia)
  • EU (Ireland)
  • Asia Pacific (Incheon)
  • Asia Pacific (Mumbai)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Sydney)

Scanning features

The assets can be scanned, based on what are called as Rules package. It is basically set of rules based on templates, similar to PCI, CIS benchmark etc . Following are the available ones at AWS currently:

· Common Vulnerabilities and Exposures

· Center for Internet Security (CIS) Benchmarks

· Security Best Practices

· Runtime Behavior Analysis

While the first two in the list are pretty much straight-forward, Security Best Practices lists out deficiencies based on the following categories:

Runtime Behavior Analysis provides insight on the following parameters:

NOTE: Currently, AWS does not allow custom or self-configured rules package.

Depth of scan:

Unlike the different scan templates available in the Vulnerability Assessment tools like Advanced Network Scan, Configuration Audits, PCI Scans and etc, AWS classifies its scanning depth based on the time! A point to note is that more the duration, the comprehensive will be its scan and consequently the outcome too.

You can set your duration to any of the following available values:

  • 15 minutes
  • 1 hour (recommended)
  • 8 hours
  • 12 hours
  • 24 hours

Scoring

Vulnerabilities determined from the scans are classified as following:

· HIGH

· MEDIUM

· LOW

· INFORMATIONAL

Pricing

Amazon Inspector is free for upto 250 agents for the first 90 days. The pricing differs post 90 days, more information on pricing here

Here is my analysis:

Limitations:

Maximum number of hosts that could be scanned in a single run is 50, however you can install Inspector on upto 500 instances. AWS calls this as running agents and it has a hard limit without any provisions to request the raise in this limit. If you compare this with tools like Nessus or Nexpose, then it is a big limitation as these tools allow upto 1024 IP addresses depending on the licenses

Report formats:

This is where I felt a big let down by AWS. The reports are neither readily consumable nor readily actionable. With AWS Inspector:

You can either view the results online or download it in CSV format. Only in the web console can you sort around based on parameters like HIGH, MEDIUM, LOW, INFORMATIONAL etc and you cannot use these to present an executive summary like in other tools.

The exported CSV file does not include the host name or the IP Addresses. Instead you will have to figure out the host based on the agent ID. Also, you will need to save it as spreadsheet (.xls, .ods etc ) to preserve the custom changes.

I had to play around with the pivot functionality to identify the host with maximum vulnerabilities or identify CVE which is prevalent across all the hosts.

Report includes the following information:

  • Severity
  • Date
  • Finding
  • Target
  • Template
  • Rules Package
  • ARN
  • Rule
  • AWS agent ID

AWS already provides many features and tools centered around various aspects of securely managing AWS instances and services like AWS Config, EC2 Systems manager, Cloudwatch, Cloudtrail, Trusted Advisor etc

I think AWS should consider improving the reporting functionality (executive summary, detailed summary, host IPs/names, top 10 machines with vulnerabilities, options to export report to PDF, xls, ods etc) if the AWS inspector is to provide meaningful and impactful inputs to the people using it. It has good potential to eat into the markets currently controlled by the likes of Nessus, Nexpose, Qualys and etc

#aws #awsinspector #vulnerabilityassessment #infosec #security