AWS Step-by-Step
AWS Makes it Easier to Detect Firewall Configuration Changes
There is an old saying among IT security pros that you can't secure what you can't monitor. This saying holds true whether you are talking about on-premises infrastructure or infrastructure in the cloud. Overall, Amazon and other cloud providers have historically made it relatively easy to monitor cloud infrastructure, but there has always been room for improvement. Thankfully, Amazon has recently made it possible to use EventBridge to monitor AWS network firewall state changes.
What is Amazon EventBridge?
Amazon EventBridge is often described as an event bus service. It allows you to build event-driven workflows based on events that occur within your AWS ecosystem. As an example, you might use EventBridge to trigger an automated alert if one of your EC2 instances suddenly powered off. Like other automation tools, EventBridge ties triggers to workflows. In other words, if a specific event occurs (such as a virtual machine instance being powered off), then a predefined workflow is executed in response.
What is New for AWS Network Firewalls?
Until recently, the AWS Network Firewall did not publish firewall state changes directly into EventBridge. This meant that admins sometimes had to look for creative ways of detecting changes that might have been made to a firewall.
What Types of Events are Published to EventBridge?
According to the AWS documentation, there are currently three types of events that are published to the EventBridge default event bus.
The first of these events is a firewall configuration change. This might include a situation where a firewall rule group or policy is modified. To use an analogy from everyday life, think of the firewall as being like a security guard and think of the modification as being like you or someone else telling the guard to do something differently from the way that they have been doing things.
Keep in mind that when such an event occurs, the firewall is only reporting to EventBridge that a configuration change has taken place. The firewall does not attempt to distinguish between an intentional modification, an accidental modification, or a security breach.
The second type of event that is published is a firewall transit gateway attachment status change. An organization that wants to centralize VPC traffic inspection will typically attach a firewall to the transit gateway, thereby forcing all of the traffic passing between VPCs to traverse the firewall. The Firewall Transit Gateway Attachment Status Changed event is triggered when a new attachment to a gateway is created or an existing attachment is modified or removed.
The third type of event that may be sent to EventBridge is a firewall attachment status changed event. As the name suggests, this event occurs when the firewall endpoint attachment changes. The AWS network firewall creates endpoints inside of your VPC subnets. These endpoints are the thing that actually inspects and filters traffic. The Firewall Attachment Status Changed event is triggered when any one of those endpoints experiences a lifecycle state change. In simple terms, this means that if a firewall endpoint is created or deleted or if it fails or otherwise changes states, then the event will be triggered.
Collectively, these three events cover:
- The configuration layer, affecting the firewall's configuration and behavior
- The infrastructure layer, which reflects whether or not the endpoints are healthy
- The network connectivity layer, which determines whether traffic can even reach the firewall
Together, the three event types give you visibility into firewall policy changes, operational health, and network integration.
On the surface, these events would seem to be geared toward observability and giving security teams better insight into what is going on with the firewall. However, the real story here is not observability, but rather security automation. This is a significant distinction. I once heard someone state that observability tells you what happened in the past, while automation decides what is about to happen next.
To show why this type of automation is so significant, imagine a situation where a junior admin within your organization makes a change to a firewall policy. When the change occurs, a logging event is presumably created and then later a human may or may not actually read the log. Odds are that the log will only be reviewed if someone notices a problem later on.
Conversely, you could configure AWS so that the configuration change triggers a Lambda function that compares the new rule to the organization's security standards. Automation might then roll back the modification and flag it for review if the change is found to be a policy violation. Similarly, an organization might have been using the same firewall configuration for years and therefore any change would represent unwanted behavior. As such, EventBridge could be configured to immediately notify someone if a firewall configuration change is detected.
The point is that observability does not reduce risks by itself, but automation does. By bringing security automation to the AWS Network Firewall, AWS is allowing for the creation of an event-driven architecture that can respond to adverse conditions in real time.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.