The AWS Firewall features list is impressive to say the least. What I really appreciate is it’s not just features rich, it’s features right. It has the features you really need and are most likely to use in a cloud native deployment, plus it adds few stealth sparklers under the hood.
Note: Enterprise Features to be released at GA include (HA, Autoscaling, Rule Limits)
Other noteworthy highlights of interest
|
Horizontally Scalable
|
Session State Stickiness
|
Single Target Route Tables Entries.
|
IGW and VGW – Ingress / Egress
|
NAT Gateway – Ingress / Egress
|
VPC Peering – TBA
|
| Hub and Spoke Architecture Support |
Although it’s not listed as a “feature”, the “Custom Actions” capability is very interesting. These are conditional actions that can be invoked by events in the Firewall itself. I touch on this more in the content below.
Perimeter Firewall and NAT (Source AWS)
So why is this so interesting?
Speed, Value, Cloud Native, Policy as Code, it’s not just buzzword bingo, this is next wave of Cloud Security. Anything that provides the ability to add a Firewall on demand, at scale, and lowers the barrier to entry, while reducing friction of Security Deployments is helpful. In addition, simplifying the overall security experience for Network Security Engineers, DevSecOps Teams, SRE’s, Developer’s or a CISO is the icing on the cake.
To provide context here, we need to go back in history a bit and look at the overhead and complexity of a traditional Firewall. This in itself warrants its own blog for another day. “Insert: Future Blog Post here.” I will attempt to summarize this with a few key challenges for traditional Firewalls.
- Cost of Licenses can be expensive and tedious.
- Contracts for Enterprise accounts can take weeks to month to negotiate.
- MSSP onboarding Time can be difficult to inventory and hand off.
- Integration burden, integrations are difficult to nonexistent.
- Logging and Alerting overhead, getting logs and alerts integrated can be expensive and complex.
- Product SME’s, each Firewall Product requires an SME to configure and manage it.
- Capex
- Patching
- Additional 3rd party Vendors to manage
- Multiple Compliance Reviews Security and Assessments
Game Changer in Cloud Native Security?
I think so, though it’s less about the Firewall Tech itself, it’s all about the programmability. IBM’s Cloud Native Security Services leverages this API driven AWS Firewall and uses open source cloud native technology to manage cloud native technology. IBM uses Operator Frameworks to provide instant roll back and remediations through complex reconciliation methods. This means your MSSP is doing more for you day to day.
What is so interesting about this advancement is less about the tech and more so about Day 2 Operations. The fact you can manage your entire fleet of AWS Firewalls as part a GitOps Flow or SDLC Pipeline and do so at Scale, with Secure by Design, and Zero Trust Principles applied, from Gradle to Grave, all in Git. It’s an amazing feat, and it brings me back to the NSX and ACI days of 2014.
Re: Imagine Network Security, Firewall 2.0
In recent months, Policy as Code (PAC) has been a big buzzword. AWS Firewall's management capabilities in JSON embodies this seismic shift to fully programmatic security. The ability to prevent, detect, respond and assurance of everything as code. This Cloud Native approach to security is gaining in popularity, primarily as we shift to GitOps and SDLC based deployment, security and management of infrastructure. IBM is at the edge of this movement and is enabling on scale security by design at cloud speed.
Leading the market IBM Security Services is currently piloting advanced cloud native security management with its Unified Cloud Native Security Management (UCM) offering. This brings full stack managed cloud native security to the MSSP Market filling a large and growing gap. UCM will allow for near real time remediation of unauthorized changes to cloud environments, holistically. Bringing Deployment, Management, Policy, Compliance and Assurance into the entire SDLC Process. Thus, providing Security and Privacy by Design and enabling Zero Trust Adoption.
AWS Firewall? Is it ready for Prime Time?
Well, this all depends on your needs of course. If you need a special feature or protocol that only your traditional Firewall provides then you’re obviously going to need to stick with what you have. On the other hand, if for a new Microservices Deployment in Cloud you only need a core set of features, like DNS Filtering or Packet Inspection and 5 Tuple Support, you may have all you need.
At first glance AWS Firewall appears to be ready for mainstream operations. The Firewall Performance Capabilities in Preview are indicative of the performance characteristics to come. I would expect these number to grow exponentially at GA in the near term.
- Rules – 10,000 per rule group, 20,000 total per firewall
- Bandwidth – 5Gbps
- Firewalls – 1 per account
Is AWS Firewall Enterprise Ready?
In short, it all comes down to balance of features, functionality, performance, security and of course compliance requirements.
This all depends on your requirements as of GA. For most use cases, the AWS Firewall is certainly a fit and for others, if not at GA, it certainly won’t take long for AWS to hone its mastery of at Scale Firewall Services.
One thing to consider when evaluating a Cloud Native Firewall is to rethink what that firewall needs to do, as opposed to just meeting your existing standards. It may very well be your standards were created at a time when cloud native was not a design pattern to consider at all. Rethinking your use cases in a green field, cloud native mindset will unleash the innovation held back by older models and patterns that simple don’t apply anymore.
At IBM we employ Security Design Thinking Workshops with our Clients to harness this innovation and apply it in practice to your Journey to Cloud.
Many of IBM’s client’s partner with IBM on their Cloud Journey to leverage IBM’s vast experience in Cloud adoption and transformation. Far too often, we IBMer’s are brought in late to the game, to evaluate the damage of lift and shift’s gone bad. It’s best and far less expensive I might add, to engage with an MSSP as early in the cloud journey as possible.
Moving to Cloud requires a re-thinking of security, moving to Cloud Native requires a complete reboot all together. The people, process, technology, requirements, compliance, assurance, etc. Cloud Native is a different beast and needs to be viewed through a new lens to fully appreciate the tradeoffs and gain the most value from your cloud native use cases.
Cloud Native Antipattern #1:
Simply Forklifting the old infrastructure into the new shiny cloud looks good on paper though far too often it’s not so good in practice. It can be done with the right guidance, though it will not be cloud native unless most if not all of those 12 factor principles are achieved.
It’s important to focus on the needs of the business first and how to secure it second. This is where an MSSP’s experience adds value and can actually save you money in the near term. Getting things right the first time is always best and IBM guides clients through this with its IBM Garage Dojo’s every day.
For those looking to use Cloud Native Firewalls to Secure Lift and Shift migrations, the AWS Firewall is a great addition to your security arsenal and with its feature rich capabilities it will certainly address most if not all of your Firewall needs and possibly shore up some of other shortcomings of Older Firewall Appliances not designed for Cloud.
Feature Highlights:
As mentioned above the AWS Firewall has great set of features, I can’t wait to battle test them after launch, I encourage you to stay tuned as these are tested at Scale in the coming weeks, I’m highly optimistic.
| Feature |
| Domain Filtering |
| IP/Port/Protocol Based Filtering |
| Per-AZ Rate Limiting |
| Deep packet inspection (native decryption not supported) |
| Automatic protocol detection |
| Ability to import domain name lists or Suricata and Snort compatible rules |
| Logging to S3, Cloudwatch or Kinesis Firehose |
Note: Enterprise Features to be released at GA include (HA, Autoscaling, Rule Limits)
Although it’s not a “feature”, the “Custom Actions” capability is very interesting. These are conditional actions that can be invoked by events in the Firewall itself.
Currently pre-GA the only supported Custom Action is Rate limiting, that said, event based conditional actions is a very powerful feature. One that shows AWS’s Cloud Native thinking. I foresee this being extended to support event driven design primitives. Thus, providing engineers a way to create SOAR like actions in line with Firewall rules.
Consider a simple example of Rate limiting based on a target port or IP. This can implement by any engineer with basic JSON and Firewall knowledge. Normally many companies would need a Firewall Engineer, an API gateway Engineer and or a Load Balancer Engineer to enable this type of rule. AWS again, lowering the friction of Security.
"Input": {
"RuleGroupName": "StatelessRGExample4",
"RuleGroup": "RulesSource": {
"StatelessRulesAndCustomActions": {
"StatelessRules": [ {
"RuleDefinition": {
"MatchAttributes": {
"Sources": [ {
"AddressDefinition": "1.2.3.4/32"}],
"Destinations": [ {
"AddressDefinition": "124.1.1.24/32"}],
"SourcePorts": [ {
"FromPort": 53,
"ToPort": 53},{
"DestinationPorts": [ {
"FromPort": 53,
"ToPort": 53}
"Protocols": [ 6 ],
"TCPFlags": [ {
"Flags": [ "SYN"
],
"Masks": [ "SYN","ACK" ]
"Actions": [ "CustomAction" ]},
"Priority": 19}],
"CustomActions": [ {
"ActionName": "CustomAction",
"CustomAction": {
"RateLimit": {} }
"Type": "STATELESS",
} }, ] } } ] },
"PacketsPerSecond": 1000}
"Description": "Stateless Rule with Custom Action",
"Capacity": 199}
If we double click on this, we see with Firewall Rules all in JSON it makes it much simpler to use GitHub and SDLC to evaluate these rules for compliance and auditability. IBM Cloud Native Security Services is leveraging these SDLC approaches to further enhance Cloud Security at Cloud Speed.
GitOps Combined with API driven AWS Firewall, we see the access and authorization burden has been diminished significantly. Though this is unlikely to be the end of a VPN or SSH Bastion Host for an operator, it’s a step in the Zero Trust direction for Firewall Operators and DevSecOps teams. If you already using GitOps methods, you’ll appreciate the service-based API interoperability out of the box. For existing AWS Cloud Native engineers, AWS Config and Control Tower Integration is unknown at this time, though I would expect to see it supported in one of these soon.
Applications Security?
AWS Firewall, is part of the AWS Firewall Manager Suite of services in AWS. With this AWS Firewall Manager services like AWS WAF rules for your Applications, Load Balancers, API Gateways, and Security Groups on your ENI resources are all integrated under one umbrella. This addition of the AWS Firewall will continue to round out the security capabilities and continue to enable Cloud Native Security for Complex Cloud Native Applications, Microservices and Event Driven Ecosystems.
Understanding how applications intersect with preventative controls is critical to provide the telemetry required for comprehensive detection of Indicators of compromise (IOC’s).
In complex microservices deployments that have a constantly changing attack surface, it’s paramount to consider how to take advantage of event driven design architectures. The AWS Firewall creates an opportunity to blend, preventative controls for applications, telemetry required for Indicators of compromise (IOC) detection, and actions for remediations all in one place. AWS has obviously thought this through with their design. I can’t wait to see where they take this next.
AWS Firewall vs Traditional Firewalls:
Aside from the obvious advantages of Cloud Native, Capex vs Opex, cost, time, complexity and pay as you go value propositions. It all comes down to opportunity cost, and time to value.
As a product architect I can appreciate the value AWS Firewall brings to Enterprise Development Team. Time to market (TTM) is king in the world of tech. Blink and your market opportunity is gone. AWS Firewall enables developers to utilize pre-built policies, GitOps workflows, SDLC pipelines for day 2 operations and fits nicely in a DevSecOps organization. It allows Security Engineers to focus on more value added and quite frankly more interesting work; such as complex changes, threat hunting, and investigations. All developers need to know is which policy to apply or which AWS Firewall to use. More advanced organization may use GitOps pipelines the create new firewalls with each deployment for one to one deployment. Thus, opting to replace their sidecars and envoy deployments. On the other hand, high security organization may choose a more layered approach and simply add the AWS Firewall to the existing service chain to complement their defense in depth approach.
For our Security Engineers, it means using GitOps for Compliance and Assurance as well as automated rollout and roll back in addition to decommissioning. Dare we say Blue Green deployments for Firewalls? This fits nicely in the 3R’s approach to enterprise security. Thus, no more rule sprawl of unknown rules, or fat finger mistakes on the CLI.
For Compliance teams, this enables the opportunity for Policy as Code (PAC) for Firewalls and Applications in Cloud. Historically Firewalls have been a difficult area to automate and ensure compliance, due to the fact they have used proprietary CLI’s and have limited API’s. The AWS Firewall is another step towards continuous compliance, enabling compliance teams to extend their compliance as code to yet another area in the SDLC pipeline.
For a CISO, all the above is great news. The real value comes from the lower cost and lower friction of security. The AWS Firewall is enabling CISO’s to add security controls faster and more consistently across rapidly evolving CTO Projects. Allowing CISO’s to keep pace with the high-speed development of Cloud Native Application and Infrastructure changes. Even with all these advantages I would still recommend to any CISO to partner with your MSSP on this new Firewall Adoption.
The overall value here is time. Time to Market, Time to Security Hardening, Time to Deployment, etc. A combination of costs in Time, Labor, Scaling, Contracts, all of these have an impact on development and time to market overall. All in all, the AWS Firewall boils down to a value in Time, the fuel in which we all burn and never have enough of.
What about all my existing Firewall Features?
This is a great opportunity to assess the Firewalls you currently use and assess if you still need all these old features. Let alone if they are adding value to your Cloud Adoption. Again, another shameless plug for your local MSSP here, IBM does of these assessment for clients on a continual basis. With IBM Security Services you wouldn’t need to ask about Fit for purpose, we would preemptively advise you this as we do for our clients every day.
Traditional firewalls come with their plethora of features and functions, most of which go unused. With all those features comes complexity and cost, which leads to the need for SME’s with deep expertise in one Firewall. This is expensive to say to say the least. Traditional Firewalls have many options for centralized management to ease the burden of on scale deployments a bit. These Firewalls are very good at what they were designed to do, on Prem. They have a place in the Cybersecurity arsenal and for clients that need to those traditional appliances the option is there to dynamically add them. Just as soon as they get those new licenses approved from procurement. The VPC ingress routing provides a simplified way to add your firewall appliance of choice. So, while you’re waiting for that new license or if your need Firewall SME is on vacation, you could look as using the AWS Firewall as a temporary solution or the new standard in low cost or cost recovery solutions. Again, this where an MSSP can help you decide.
AWS and IBM Security Services better together:
As simple and amazing as it is, the AWS Firewall still needs Security Expertise to oversee it and the rest of your overall Cybersecurity. It is after all protecting your most valuable assets. So, how will you know if your secure? Do you have a MSSP looking over your shoulder? If not, you may need to consider the risk of not doing so, the Ponemon Institute cost of breach research revealed the average cost of a breach in 2019 was 3.9 Million. This number was even higher for Healthcare companies. What’s most interesting to me is the average time it takes for a company to realize it’s been breached. The average time to discovery of a breach is (206 days). There’s an old saying in the Cybersecurity world “there’s two types of companies, those that know they’ve been breached and those that don’t know they’ve been breached. Knowing is half the battle, which one is yours?
Deploying the AWS Firewall is one way of buying down this risk, another is Partnering with an MSSP. Seeing this AWS Firewall is so inexpensive maybe there’s still room in the budget for a consultation.
Please feel free to leave your thoughts and feedback before this blog. You're also welcome to connect with me on LinkedIn at https://www.linkedin.com/in/chrisdidato/
Links
2020 Cost of a Breach Report
https://www.varonis.com/blog/data-breach-statistics/#:~:text=The%20average%20time%20to%20identify,2017%20and%202018%20(Statista).
https://securityintelligence.com/posts/whats-new-in-the-2019-cost-of-a-data-breach-report/
https://www.thoughtworks.com/radar/techniques/the-three-rs-of-security
https://aws.amazon.com/firewall-manager
Using Cloud-Native ‘Policy as Code’ to Secure Deployments at Scale
Published 22 October 2020 - ID G00733174