IBM Security Global Forum

 View Only

AWS Cloud Native Firewall Brings Modern Enterprise Firewall Features to Cloud Native and Eases the Burden of Bring-Your-Own-Firewall

By Christopher Di Dato posted Tue November 17, 2020 07:00 PM

  

AWS recently announced a new service, AWS Network Firewall, which provides network security controls across Amazon Virtual Private Cloud (VPCs). The easy to deploy service enables users to launch a managed cloud native firewall to complement the rest of the AWS Security Platform. This potentially enables faster, simpler, deployment of firewalls, policies and advanced rulesets for complex networking deployments.

As part of the announcement, IBM Security was named an AWS launch AWS Network Firewall partner across both Independent Software Vendors (ISV) and Managed Security Solutions Providers (MSSP)capabilities. This builds off the broad IBM Security support for cloud native services in AWS covering both Security Information and Event Management (SIEM) and managed security services offerings as well as demand for deep partner integrations across AWS technologies.

During a meeting with the IBM Security QRadar Team, where teams integrated QRadar with the new AWS Service, I had the opportunity to play with AWS’s new Cloud Native Firewall, Code Name “Vanta,” I must say I am very impressed with this Firewall. What is Vanta? Vanta or AWS Network Firewall as its newly branded name, is a Managed (FWaaS) Firewall as Service offering for AWS Cloud Services. It’s a stateful, cloud-based network security firewall as a service with cloud scalability and high availability on the way.

Or as AWS describes it, “a network firewall service for Amazon Virtual Private Cloud (VPC).

AWS Firewall provides enterprise firewall features that allows customers to secure their cloud environments without the need to purchase a traditional firewall appliance. AWS Firewall’s has a powerful feature set to list a few: Stateful FW, Packet Inspection, Filtering. It also has the ability to import rules from Snort or Suricata IPS (Intrusion Prevention System) that allows for Snort and Suricata rule portability. That’s right, you can port your existing Snort and Suricata rules to the AWS Firewall. This means all open source rule sets you have curated can be rolled in, while leveraging the rules curated in the open source community as well. This could potentially save months of engineering time in itself. Due to time constraints this feature will be tested after GA.

As with anything with great power comes great responsibility, and the AWS Firewall is no exception. IBM Security Services is partnering with AWS to help its clients take advantage of this cost effective opportunity without compromising a client’s security requirements. Leveraging IBM Security X-Force Threat Management, IBM Security X-Force Red and IBM Security QRadar to bring the best of breed security services to AWS.

AWS Firewall Summary:

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.

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)


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.

AWS Firewall Reference Architecture:

The AWS Firewall utilizes the VPC Ingress Routing Enhancements released last year to steer traffic to it. It logically sits inline just like your existing appliances do today.

In the picture below the AWS Firewall Appliance sits behind the Internet Gateway in your VPC. Depicted in the Middle Box on the route named eni0.

This design decision provides the flexibility of replacing your Appliances at any time, thus reducing lock in.

Image Source: AWS

Currently in Preview the management is done via the AWS CLI or the AWS VPC API. I would expect to see a nice UI in the future although, it may be unnecessary if you’re using GitOps. Policy’s and all configurations are created from the very readable JSON, YAML is also supported for those who love YAML.

Deployment Architectures:

The AWS Firewall supports many standard deployment architectures with more complex ones in the near term. It’s important to take a moment and consider the capabilities of AWS’s Networking. It’s easy to see how a simple design can evolve into complex network overnight. I won’t bore you with all of the supported designs, though these two are a representative of its impressive capabilities.

Perimeter Firewall and NAT (Source AWS)


Egress to Internet and On-Prem (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.

  1. Cost of Licenses can be expensive and tedious.
  2. Contracts for Enterprise accounts can take weeks to month to negotiate.
  3. MSSP onboarding Time can be difficult to inventory and hand off.
  4. Integration burden, integrations are difficult to nonexistent.
  5. Logging and Alerting overhead, getting logs and alerts integrated can be expensive and complex.
  6. Product SME’s, each Firewall Product requires an SME to configure and manage it.
  7. Capex
  8. Patching
  9. Additional 3rd party Vendors to manage
  10. 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





#Spotlight
#Highlights-home
#Highlights
2 comments
1173 views

Permalink

Comments

Tue November 17, 2020 07:50 PM

https://aws.amazon.com/blogs/aws/aws-network-firewall-new-managed-firewall-service-in-vpc/

Tue November 17, 2020 07:50 PM

AWS Native Firewall is released. https://www.linkedin.com/posts/chrisdidato_aws-network-firewall-new-managed-firewall-activity-6734621456526917632-Tu4G