Global cybersecurity attacks made headlines the past year, which range from Uber, MBDA Missile Systems, a Victorian University, and who will ever forget the double ransomware attack faced by Toll Group in 2020. It is evident that Australia is not immune to this increased global threat and according to recent data, ransomware is 57-times more destructive in 2021 than it was in 2015.
As a result of the global cybersecurity threats, the Australian Cyber Security Centre (ACSC) issued a notice in February 2020 to Australian organisations to adopt an enhanced cyber security posture.
We highlighted in a previous post that enhancing your organisations security posture starts with a practical plan and an efficient mechanism to establish visibility. A short summary of the approach and some focus areas are:
- Define a phased approach, starting at a “stage 1” and set a period of approximately 60-days to deliver priority improvements. This approach keeps the outcomes real and delivers thread prevention results with business value.
- Establish visibility across your AWS ecosystem
- Focus on improving perimeter and edge security as a priority
- Host (EC2) security – patch management is not to be forgotten
- Infrastructure as Code (or automation) bring major benefits to the table, however, do not fall in the trap of delaying for months to improve security due to a lack of automation resources, or a lack of skills
In this post, we will focus on establishing practical edge/perimeter security in our cybersecurity posture enhancement journey. Let us first establish a baseline definition of the perimeter. Perimeter security in cybersecurity refers to the process of defending a company’s network boundaries from hackers, intruders, and other unwelcome individuals. In contrast, edge security extends to decentralised devices, including mobile phones, secondary cloud environments, and smaller data centres, each requiring its own digital defences.
Secure the perimeter
Securing the permitter within the context of an Amazon Web Services network may include, but are not limited to:
- Improving defences against Denial-of-Service attacks (DOS) or Distributed Denial-of-Service attack
- Improving Security Group posture (virtual firewalls)
- Decreasing the attack surface, by removing insecure network devices from the perimeter – most commonly,
- Protecting compute resources against common web exploits and bots that may affect availability or compromise security.
A common tool in the security toolbox used to improve perimeter security is deploying a firewall. With most public facing services operating on layer-7 HTTP/S protocols (i.e., Websites and APIs), deploying a Web Application Firewall (or WAF) is a very effective strategy. There are many vendor and firewall options to choose from when window-shopping the WAF isles and shelves, however keeping to our practical security posture improvement plan our approach should be:
- Quick and simple to implement
- Do not require specialist knowledge to implement and operate
- Cost effective, yet deliver true security benefits to our workloads
AWS Web Application Firewall (AWS WAF) supports our practical approach and ticks all the boxes. A key benefit of AWS WAF is that is offers protection for most AWS services commonly deployed to serve public facing workloads, websites, and APIs. As depicted in the diagram below, AWS WAF supports our practical approach by providing protection for:
- AWS Application Load Balancer
- Amazon CloudFront
- Amazon API Gateway
- AWS AppSync
A major benefit of AWS Web Application Firewall is the simplicity of the provisioning and configuration thereof. Commonly, firewall deployments are coupled with network routing changes, DNS configuration changes, and a handful of other carefully considered adjustments. AWS Web Application Firewall can be configured and integrated with common workload components using the AWS Console in a couple of minutes – and keeping with our practical plan, suits us perfectly. Full CloudFormation support is also available should your organisation be making use of Infrastructure as Code.
AWS Web Application Firewall
AWS WAF is configured and deployed to AWS resources through a mechanism called Web ACLs – or Access Control Lists. A web ACL is a collection of rules that determine if request traffic is allowed or denied. A major benefit of AWS WAF is that it comes pre-packed with a large collection of tried and tested rulesets to choose from, that should cater for most workloads ranging from a simple WordPress site to more advanced SQL-backed APIs and more.
Let us explore the mechanisms to deploy and configure an AWS Web Application Firewall using the AWS Console.
A simple search in the AWS Console for “WAF” will result in the “WAF & Shied” menu option popping up. The same area is also used to manage AWS Shield-Advanced subscriptions. AWS Shield (standard and advanced) is another service to help protect your workloads against DOS and DDoS attacks, although we will not be exploring AWS Shield-Advanced in this post, you should be aware that AWS Shield-standard is enabled for free across any AWS component you deploy and offers free protection against large scale DOS/DDoS attacks. For more information on AWS Shield, please refer to the service description page here.
Creating a new Web ACL is a simple process, requiring only a few details and when using the AWS Console, the creation process is done through an easy for follow guided process. As depicted in the image below, we specify a name and the AWS Region we want the Web ACL to be operational in. This is important, as there are two different types of Web ACLs at play – Global and Regional. The difference is that a Global ACL is used to protect Amazon CloudFront distributions, whereas Regional Web ACLs are used to protect regional resources, such as an Application Load Balancer.
Our practical example will be deploying a Regional Web ACL, to protect a workload running on several EC2-nodes behind an Application Load Balancer. An important aspect to remember is that one WAF Web ACL can protect multiple resources in the same AWS Region, and the base cost of an AWS WAF Web ACL is minimal (~$7.00 per month – with 2 x rules) and the rest of the costs are consumption based at $0.60 per 1 million requests. This meets out practical and cost effective perimeter protection requirement.
During the second step of the Web ACL configuration, select the RULES that will protect the workload(s). Here you will need to dive into the various options available and the specific requirements of the workload in question, however, remain practical and start somewhere. Remember that the practical plan is to offer a good level of protection during the first 60-days, and then enhance the security posture over time.
A good starting point is to select the “Amazon IP reputation list” and the “Core rule set”. These two rulesets offer a balanced level of protection and is unlikely to impact on real-world business-as-usual workload traffic patterns.
Selecting the correct rules and configuring it appropriately is important, as some workloads or web-applications may by design use some traffic or data-elements which may be interpreted as malicious requests. For this reason, it is important for the rules to be configured as a counter only when enabling AWS WAF on a production workload. This instructs AWS WAF to allow all traffic, but only COUNT the traffic that would have been denied should the rule(s) have been fully active. Monitoring these denied requests for a few days or weeks prior to disabling the COUNT is highly recommended.
Architectural considerations may need to be assessed when re-using Load Balancers or Amazon CloudFront distributions for different workload types, since a Web ACL applied to a Load Balancer will inspect all traffic destined for different workloads. AWS WAF allows for some advanced configuration, referred to as “scope-down statements”, which scope the effect of a rule to a specific URI-path, cookie-values, country, and a few more options. This could become complex to manage for various types of workloads operating behind one load balancer, with each requiring unique rules and competing rulesets to be fully protected.
The image below highlights the various request-elements that can be used to define a scope-down statement.
As highlighted above, it is highly recommended to deploy and enable AWS Web Application Firewall with the COUNT option enabled and monitor it for a few days or weeks to assess the impact it may have once fully enabled. Once you are confident that all business-as-usual web requests pass successfully through the WAF, you can enable some or all the WEB ACL rules to fully protect the workload(s) in question.
As indicated in the image below, there are three suspicious request patterns coming from unknown origins in China and Antigua accessing our sample workload and attempting to access common database or website configuration scripts. The most interesting fact is that these malicious activities started to occur 30-minutes after deploying a test workload and opening port-80 traffic to the world.
In addition to these three common PHP web CMS pages, our seamingly safe website had several more interesting attempts to try exploit the site.
AWS WAF further provides a high-level overview of the allowed and blocked traffic. This view offers the security team and application teams an easy mechanism to assess allowed and denied traffic patterns.
AWS Web Application Firewall and Amazon CloudFront
The example focused on in this post highlights the deployment and configuration of AWS WAF and a core set of Web ACLs for an Application Load Balancer. The most convenient feature of the AWS WAF is that it did not require any changes to DNS or Network traffic routing. It truly is a “plug-and-play” feature to enhance your cybersecurity posture in a practical way.
These same features and easy to configure benefits apply when deploying and configuring AWS WAF to protect Amazon CloudFront distributions.
AWS WAF and a multi-account ecosystem
You may be operating a larger ecosystem of AWS accounts with many web facing resources, with a preference or mandate for only a central team of security experts to operate and configure firewalls.
AWS Firewall Manager is purpose built for such a larger scale operating environment, which allows you to centrally configure and manage firewall rules across your accounts and applications in AWS Organizations.
In conclusion, AWS WAF offers a simple, yet very effective mechanism to enhance your perimeter security, however it is important to note that the biggest threat to malware attacks remain internal staff with elevated network or system access. Issuing users with a secondary system identity/account for administrative purposes offer extra protection on the internal network. In addition, establishing a continuous security awareness program for all staff offer the best protection against malware attacks. Prevention is better than paying an expensive cybersecurity attack ransom.
For reference, additional statistics on cybercrime can be explored here. A bit of trivia and latest news on global and local cybersecurity attacks can be found on the BBC website and here.