What's in the Box?

The graphical Console can be accessed by way of a sophisticated API on the same network port on which you install it. To get a Console up and running, I'll follow the instructions for a basic "Onebox" installation, because both a Container Defender and a Console are installed on a single machine. Remember, no Host Defender is needed on this occasion.

Once I have a working Console, run through some of the data the Container Defender is picking up, and feed back to the Console, I'll look at integrating an AWS Lambda function.

To get started, I'll fire up an EC2 instance in AWS to install the Console. I'll assume you have working AWS credentials. Of course, it's up to you whether you're using Terraform or some other programmatic method or doing this manually. I opted to use the latest Ubuntu LTS (18.04, Bionic) OS; you'll probably want to make the Console instance quite beefy, with a good bit of RAM, and provide it with decent disk I/O. Detailed system requirements are available if needed in the docs. I ran the commands apt update; apt upgrade -y to keep up with the latest patches and packages; and then, I performed a reboot.

The next task is to download the latest version of Prisma Cloud Compute to your instance by visiting the release links [2] within the docs. From there, you can find a PDF (boasting a staggering 754 pages of about 63MB) with details on where to find the latest release. In my case, this was version 19.11.480. The docs are also now public, which is more convenient (an access token attached to the license was always required before the acquisition and is still needed for the tarball download). In this case, however, you have a URL to use for downloading a tarball with wget.

The new Prisma Cloud Compute docs have a nicely compiled list of possible routes to take at this point. I can't help but be impressed with how broad a reach the product now has, especially having embraced non-containerized hosts and serverless functions alike. Installation options include Kubernetes (Elastic Kubernetes Service/Azure Kubernetes Service), OpenShift, Docker Swarm, Pivotal Container Service, Amazon Elastic Container Service, DC/OS (the Distributed Cloud Operating System), and Windows. I chose the simplest Onebox option, which the docs remind you will scale with additional Defenders (on other host machines), if you like.

You need to be root to perform the installation. As mentioned, the Onebox installation installs a Console container and a Defender container onto your machine. First makes sure you have Docker installed: docker-ce is the latest version [5] (the older versions are called docker , docker.io , or docker-engine ). On Debian derivatives, you can install the older version with:

$ apt install docker.io

Now simply extract the files from the tarball, which still sits at about 687MB:

$ mkdir twistlock
$ tar -xzf prisma_cloud_compute_edition_19_11_480.tar.gz -C twistlock/

If you cd into that newly created directory and look for the twistlock.cfg file, the options you might tweak are critical to an enterprise installation and include, for example, which network ports your Console and Defenders communicate over and where backups are saved. You can also tweak read-only and root user security settings for the Console and set up high availability. For the Onebox installation, however, the defaults will suffice.

As part of the next command, you automatically agree to the end-user license agreement with the -s option and opt for the Onebox install route:

$ ./twistlock.sh -s onebox

If you didn't want a Defender on this same instance, then replacing onebox with console would achieve just that. If you see a disk space warning here, then it's possible to append a y to the switch (i.e., -sy) to ignore the warning and proceed.

After a little patience and familiar Dockeresque output, you should see some notices in green text denoting success.

Batteries Definitely Included

The next step is accessing the Console over TCP port 8083. In the AWS Management Console, open this port to your local IP address within the instance's security group to make it possible to navigate directly to the public URL over HTTPS: https://34.XXX.XXX.XXX:8083 . After entering that URL, you're immediately asked about creating your initial admin account (Figure 1), which needs to be completed to log in.

Figure 1: The Console is up, so now you need to create an admin account.

The next screen asks for a license key, and once that's pasted in, you are presented with the main Console screen (Figure 2). The default view is a zoomed-in Radar view displaying your Console and Defender containers and their relationship in terms of network ports. Additionally, the Defender container is selected and shows any issues in the black box at the foot of the display. Usually this screen is extremely busy with resources, as opposed to just the two containers seen here. At its busiest, the ability to be able to zoom in and out of the topology on the display is invaluable. In addition to the container view, you have host and serverless views, too.

Figure 2: A zoomed-in Radar view of the Console showing a Container Defender chattering away to the Console container over TCP port 8084. This is where you will also see any issues that have been identified.

Before configuring serverless protection, I would be remiss not to cover some of the common interfaces and dashboards you will use to get the best out of the product.

The Console

On the left side of the Console you can see a number of options. The options under the Defend menu are, for all intents and purposes, the place to configure your rules. You will be most concerned with Runtime , Vulnerabilities , and Compliance . Other options in the list are Firewall and Access .

I covered firewalling a moment ago, so I'll take a quick look at Access . This area is one of the reasons I started working with what was Twistlock a few years ago. To my mind, this functionality is unquestionably exceptionally powerful. I was initially drawn to working in DevSecOps because of the minefield that was Docker security at the time (which has improved since then).

If you're interested, the open source Twistlock AuthZ Broker software is available on the Twistlock GitHub page [6]. It is described as a "basic extendable Docker authorization plugin that runs directly on the host or inside a container" and includes clear documentation.

Having discovered AuthZ – and, as a result, Twistlock as an organization – it soon became clear that container security required a great deal of consideration to get it right. Thankfully, Prisma Cloud Compute now means that all of the heavy lifting is done for you. In Figure 3 you can see the granularity of some of the container rules. Further down that list are image_delete rules and network and volume options, among many others. The blue boxes at the bottom of the figure show the Groups, Containers, Hosts, Images, and Labels to which the rules apply. This is just one of the options available from the Access menu, which has Secrets management and Kubernetes auditing, too.

Again, one of the most powerful features of Prisma Cloud Compute is its ability to use machine learning to monitor resources when they are first introduced to the security suite. After a period of an hour, a model is created. Should a resource (container, host machine, function, or otherwise) start misbehaving, the Console will flag it as an issue to be investigated. If in-house requirements mean that the models need to be tweaked, then you can alter the rules with the fine-tuned rulesets shown in Figure 3.

Figure 3: A sample of configurable actions for containers.

As you might expect, the Monitor section is where you can see the results of the rules created between you and machine learning under the Defend options. Briefly, Prisma Cloud Compute picks up the details of components (in this case, a Console and a Defender). With the Defender container selected under the Runtime option, you can see in Figure 4 that Prisma Cloud Compute's timesaving machine learning process is still checking how that container usually goes about its business. Figure 5 shows that the modeling has recorded a number of details from its day-to-day behavior. If Prisma Cloud Compute sees any deviation from these processes, it will trigger alerts, blocking actions, or both.

Figure 4: The machine learning process is still analyzing how this particular container usually behaves.

Figure 5: This container is a busy little thing and has a few processes running during the normal course of a day.

In that same model is common information relating to filesystem access, network ports, kernel capabilities, and syscalls. Tweaking all of these details manually would be nearly impossible and highly prone to errors; at the risk of repeating myself, this is where machine learning makes such a difference.

Under the Vulnerabilities option, the security suite checks include container images, hosts, serverless functions, container registries, and jobs triggered by the Jenkins plugin.

As an example, I'll just take a quick look at one particular CVE that's been flagged and how Prisma Cloud Compute deals with it. A redacted Figure 6 (because Prisma Cloud Compute is transparent about issues present within its own containers, too) shows how vulnerabilities are presented. Note that usually it's possible to see whether a vendor fix is available, in addition to being presented with clickable links to drill down into other ways to mitigate the flagged CVEs, again saving precious time in which you would normally be researching an issue.

Figure 6: A CVE warning from the Defender container, redacted to protect the innocent.

As you can imagine, when dealing with thousands of running containers on a busy estate, this level of detailed information is genuinely invaluable for remediating issues promptly.

The Prisma Cloud Compute Compliance section presents vulnerabilities analysis. Among the information is a screen detailing the layers of containers and where issues might exist in your Dockerfile, which is a very useful addition to assist in the operational side of running infrastructure. Figure 7 shows a little taster of that which hosts, container images, and functions might all be subject when it comes to compliance. In this section, you will also find AWS compliance tests that can highlight cloud platform issues.

Figure 7: Compliance is key to a robust security posture, especially for larger organizations.