AWS Firewall Managed Cloud NGFW

updated: 2022-09-07

(Under Construction)

Introduction

Palo Alto announced direct NGFW Cloud integration with AWS as well as AWS announcment back in March of 2022. This is a really new product that integrates AWS Firewall Manager with Palo Alto NGFW.

I am still reviewing it, but here are some initial docucmentations around it that I’ve been looking at and evaluting and this is a PDF with a brief overview: Palo Alto Cloud NGFW (file removed due to NDA)

Intro video

Overview

Since the product is new there are obviously going to be a learning curve and bugs that come along with it. Here we want to go over some of the hurdles that this product is going to have to overcome in order to sell me on if it really is the next generation for a proper Cloud Deployment.

Concerns & Problems

So, first I would like to say this product is promising, but I would like to get the negatives out the way first. As coming from a Network and Security background first and foremost you can definately tell that this was not initially built for the Security Network Engineer. The overall feel and marketing seems centered around DevOps. In my experience Security should be left to the Security experts or at least Developers that have a Security/Network background or are working hand and hand with a team of professionals with those skills and background.

  1. Isolated from Panorama or a standardized way of managing the NGFW clusers. This leaves you stuck with how AWS Network Firewall Manager handles firewall policies. Which I personally am not a fan of.
  2. Lack of support for tagging and AWS monitoring to be able to leverage DAGs ( Dynamic Address Groups )
  3. Reliance on native AWS tooling. This may not seem like an issue, but if you work or have a siloed strctural corporate environment this can become very challenging very quickly.
  4. Lack of customization in the IDP/IDS system. I find in production system we, as Security Engineers, have to quickly circumvent or adjust detection and blocking. I have yet to see the ability to get this type of customization into the Cloud NGFW product.
  5. Logging structure is full on geared towards a person with a Development background. Don’t get me wrong here, I do like the structure and having some programming background I can see so much advantage in this approach, but when we are talking about an operational team to support this and troubleshoot on demand you need something they are already trained in and familiar in. Not all Security Engieers are also programmers/developers.
  6. AWS Network Firewall Manager tends to lean towards a distributed system (where you also have a choice of stateless or stateful inspection). Now you can still stick with a centralized managed system within it, but underlying AWS documentation leave this up in the air for me.
  7. Timelines, timelines, timelines… I don’t trust vendors or anyone telling me “it’s coming, it’s comming” becuase we all know delays and problems happen. So, relying on a vendor on key compenents that are necessary for a fully enterprise level secure posture is key. At least for me.
  8. Decryption, decryption, decryption. I’ve never been a fan of Palo Alto and how they decrypt inline. If you follow CIS or NIST standards. See NIST SP 800-52

Seen Benifits

OK, now that the negative is out of the way. Here are some promise that I really do hope come out well in the end. Well I’m highly confident they will. It’s just if you are a true Security person you know don’t trust just verify!

  1. Encryption/Decription. I love this saying and can’t remember who said it “Dance like nobody is watching, but encrypt like everyone is”. Now I tend to not use Palo Alto for inline decryption, but there maybe some promise esp with AWS integration. And with the code updates in 10+ and cipher support it is worth another look More has to be looked at.
  2. Auto scaling is now handled by AWS. Wonderful, since that is a major hurdle in how we have to handle a VM-Series deployment. Still more on this that needs review.
  3. Centralized and decentralized plus the ability to have a hybrid deployment. This is interesting concept and looking forward to trying it out.
  4. Code developement. Cloud NGFW was really looked at from a code first perspective. And although that, to a Security first person, is tough to swallow it does allow the ability to quickly deploy and get security where it needs to be. If the product keeps at a fast enough pace to this it will be is very promising.
  5. Promise to deliver a better tagging mechanism for AWS integration. See notes in AWS Blog

Roadmap

Once I heard the roadmap and if Palo Sticks to this I think the benifits will begin to outweigh the negatives within this deployment. I hope to add more to this soon.

Deployment Process

Now the fun stuff. Deploying was relatively simple. I recommend going with your Palo Alto rep to get a POC (they typically allow a 15 day period) prior to subscribing to the service in the AWS marketplace. Otherwise you will be charged.

The process switches between AWS and Palo Alto’s webconsole like: https://web.aws.cloudngfw.paloaltonetworks.com/#/login .

Design Overview

What I like about how Palo Alto and AWS have deployed this is that they are sticking to the traditional methodology that has been developed already. Giving you the ability to manage your cloud deployment in a centralized or decentralized manor (or even hybrid depending on your business needs). This is a simple lift and shift based off AWS Design Concept Overview for more indepth view of it, but essentially this design still works here:

The issue here is that you are leveraging AWS Network Firewall Manager to handle all the endpoints being built and the firewalls themselves. What is good about this is you don’t have to do all the heavy lifting and scripting, what becomes the problem is that you are in the hands of AWS and Palo Alto. And I’ve already seen where code worked and then stopped working becuase of how AWS handles the creation of things via their new AWS Network Firewall Manager.

These small issues are what can drive a developer crazy, and get a Security Engineer concerned about the underlying stability of the platform itself.

Certificate Management

Cloud NGFW offers an easy way to integrate your certifiate updates via AWS AMC using tags. This gives your Firewall the permissions it needs to retrieve certificates when necessary and apply them to your Inbound or Outbound policies making for an easy automation control of your certificates and being able to run deep level inspection without all the heavy lifting mentioned in AWS Inbound Inspection .

Yet this is not with it’s own downfalls that I still have not seen proven to work. Further can be read in a previous post as the same issue still exists. Not to mention Palo Alto’s issues with inline decryption, which is on the roadmap of getting better, but still has caused issues in versions 9.x and lower. Although signficant strides have been made starting in 10.x+. I am still working out to prove this.

See current list of supported suites: PAN-OS 10.1 Decryption Cipher Suites

Even though it says it is supported I have had run into issues on lower versions that still would not work. Palo Alto has promised in the 10 version of code that you get more logging into why and how the decryption is occurring. I cannot wait to try it out and see the strides they have made. Or what else needs to be done.

Automation/Code

I have reviewed the terraform documentations around Cloud NGFW product and I think they are overall off to a good start. Although their documenation needs some work. I think The Developer's Guide To Palo Alto Newtworks NGFW for AWS is a good start and definately review and look at and he has soe really good sample terraform samples that I can definately appreciate.

I have noticed a few issues though here that I’ve been looking into:

  • The provider configs require an arn, but I think this is how things are created within AWS that ruined how this works. So, the sample code shows:
provider "cloudngfwaws" {
  host    = "api.us-east-1.aws.cloudngfw.paloaltonetworks.com"
  region  = "us-east-1"
  arn     = "arn:aws:iam::123456789:role/CloudNGFWRole"
}

But what i would recommmend is changing that out to:

provider "cloudngfwaws" {
  host = "api.<region>.aws.cloudngfw.paloaltonetworks.com"
  region = "<region>"
  lfa_arn = "arn:aws:iam::<account_id>:role/CloudNGFWRole"
  lra_arn = "arn:aws:iam::<account_id>:role/CloudNGFWRole"
  logging = ["login", "get", "post", "put", "delete", "path", "send", "receive"]
}

If you don’t you’ll proably end up getting the following error due to unable to assume the Global Role:

Account is not successfully onboarded by FMS. Programmatic Access for CloudNGFWGlobalRulestackAdmin role is not supported

and I’m seeing that a lot blogs around on these errors. I’ve brought this to Palo Alto and hopefully they’ll either fix it or get this working. Yet, I do think this error can be put to blame on the AWS side. Which is why migrating or chosing this product in such an infancy stage is problematic if you really need to rely on your workloads to be operational.

  • Palo Alto also advises to use the version in their Terraform config like this:
terraform {
  required_providers {

      source  = "paloaltonetworks/terraform-provider-cloudngfwaws"
      version = "1.0.0"
    }
  }
}

Don’t… as version 1.0.0 is giving me errors. Check the current version they are on and what is available. As of today their release is up to 1.0.8, so therefore I use either:

terraform {
  required_providers {
    cloudngfwaws = {
      source  = "paloaltonetworks/cloudngfwaws"
      version = "1.0.8"
    }
  }
}

or just avoid the version if you don’t care (not great for production deployment)

terraform {
  required_providers {
    cloudngfwaws = {
      source  = "paloaltonetworks/cloudngfwaws"
    }
  }
}

Either one of the above should prevent errors when pulling down the terraform.

  • There is also an issue with the secret_key and access_key parameters as documented in Terraform Regestry , which I’ve complained is incorrect. If those values are supplied in the provides config porition and even though you can see it in the GoLang code that it can read in those params it doesn’t work. Don’t even bother using it. You’ll need to use os.env() import from python or just set it via a bash script in your local environment varriables for the terraform file to pick it up. I think this needs to be fixed either to be supported or not, but according to the documentation those values are supported, yet it only leads to auth errors.
  • Another issue is how to use the parent child relationship that we are so used to. If you cannot get Global ARN access to the Cloud NGFW through Terraform to create some Global entities that we all know and love to use in our standard Palo Alto Panorama Deployment; than you are stuck recreating every single shared resource in every local configuration applied to each firewall you deploy. This is unmanagable and an Auditers nightmare.
  • Speaking of auditors:
    • The login to the Cloud NGFW portal doesn’t use dual factor authentication a basic requirement for today
    • You only have 3 roles to provide a user with (and notice they are all Admins… hmmm really?):
      • Local Rulestack Admin
      • Local Firewall Admin
      • Global Rulestack Admin
    • Once again an Auditors nightmare esp if you are following basic NIST 800-53r5 compliance, but even other basic organizational cybersecurity guidence requires and looks at this in order to pass compliance.

Coding Cloud NGFW

Terraform Support for Cloud NGFW AWS

The Developer’s Guide To Palo Alto Networks Cloud NGFW for AWS

Terraform Repositories