Hello, and welcome to this lecture where I shall give an introduction to the AWS WAF service. If you are delivering any kind of web content, either through CloudFront Distributions, Amazon API Gateway REST APIs, Application Load Balancers, or via AWS AppSync GraphQL APIs, then I would recommend you implement the AWS Web Application Firewall service as an additional layer of security.

Without using a web application firewall you could be exposing your websites and web apps to potentially harmful and malicious traffic, which could lead to security risks within your environment. This could have a significant detrimental impact on your business from both a financial and reputation perspective. The AWS Web Application Firewall is a service that helps to prevent websites or web applications from being maliciously attacked by common web attack patterns. Many of which are outlined in the OWASP top 10 list, such as SQL injection and cross-site scripting.

In addition to your own custom criteria, such as perhaps filtering request based on source IP address or country of origin. OWASP, the Open Web Application Security Project is a not-for-profit organization that is dedicated to helping others improve security and software. They provide a top 10 list of the most critical security vulnerabilities and risks surrounding application architecture. For the latest OWASP top 10 list, please visit the following link.

If you can implement a WAF within your architecture to mitigate against some of these vulnerabilities, then that's a huge asset to your web application architecture and a great relief to the security officers within your organization. If you then compare the implementation and administration time needed to deploy AWS WAF to a standard WAF solution, then it's by far quicker. Further, AWS WAF is far simpler and easy to manage as well. And there are currently two versions of AWS WAF. AWS WAF classic, and AWS WAF, sometimes referred to as new AWS WAF.

Now you should only use AWS WAF classic if you created AWS WAF resources prior to November, 2019. So in this course, I shall be focusing on new AWS WAF. The AWS WAF service interacts with Amazon API Gateway, Amazon CloudFront for its distributions, Application Load Balances, and AWS AppSync, ensuring only filtered web requests that meet specific conditions are forwarded to be processed by these services. WAF works with these other services to filter both HTTP and HTTPS requests by distinguishing between legitimate and harmful inbound requests that will then either be allowed or blocked.

Let's take a closer look at what the WAF service is composed of to allow you to understand how it works. So there are a number of essential components relating to WAF. These being Web ACLs, Rules and Rule Groups. Let me explain each of these individually to see what part they play within the service, starting with the main building block of the configuration, the Web ACL. So Web Access Control lists, or web ACL, are the main building block of the WAF service. And it's used as the component that is associated with one of the supported resources to determine which web requests are considered safe and which ones are not.

At the time of writing this course, the supported resources include Amazon CloudFront Distributions, Amazon API Gateway REST APIs, Application Load Balances, and AWS AppSync GraphQL APIs. The Web ACL contains rules, which contains specific controls and criteria checks that assess each web request to determine whether it should be allowed or blocked. Also for each Web ACL, there is a default action that traffic should take if the criteria set out in the rules are not met by the incoming request, and the options for this are either allow or block.

Rules. Each rule contains statements and actions, which focus on specific criteria that the web request will be inspected against. If the inspected request matches the criteria set out in the statement, then that is considered a match. The result of this match can then follow an action of allow, block, or count. Allow means the request is forwarded onto the resource. Block means the request is dropped and a response is sent back to the requester, informing them that the request was denied, and count simply counts the number of matching requests.

Rule Groups. A Rule Group is essentially a collection of rules that you can apply to different Web ACLs as you need to. AWS WAF also comes pre-configured with a number of AWS manageable groups that have been built and designed to protect your resources against some common attack patterns. In addition to this, you can also get access to other Rule Groups created and sold by other vendors on the AWS marketplace. So from a logical architecture perspective, let's assume that WAF has been associated with a CloudFront Distribution with its origin pointing to S3. The network diagram would look as follows at a high level.

So firstly, a user would initiate a request to the web content being served by the CloudFront Distribution. Next, although logically AWS WAF sits in front of CloudFront, the request will be received by the CloudFront Distribution first. Then it's immediately forwarded to your associated WAF Web ACL. The AWS WAF Web ACL associated with the distribution would filter the incoming web traffic using the Rules or Rule Groups. So before it's even traversed your CloudFront environment and network, you have the ability to detect, analyze, and either allow or block the incoming request.

If the criteria highlighted by the Rules deemed that the request should be blocked, then the traffic would be stopped and prevented from progressing further. The requester would then be informed the request was denied. If the traffic met the criteria, allowing the traffic to pass, then the request would be forwarded to CloudFront. CloudFront would then serve the content as required. You might already have other security detection mechanisms within your organization that operate deeper within your infrastructure, perhaps at the web server layer, to mitigate against some of the same risks that WAF does.

And so you may be thinking, why should I implement WAF if I have this existing solution, which is working okay? If you have existing detection systems within your infrastructure, then that's great. However, the closer they are logically implemented to your web application, then the greater the risk of additional vulnerabilities occurring towards the edge of your infrastructure. It's best to mitigate vulnerability risks as close to the perimeter of your network environment as possible. By doing so, reduces the chances of other infrastructure and systems being compromised.