Policy-based security in JWCC: Putting the Sec in DevSecOps

There’s a movement going on in the world of Department of Defense (DoD) applications. The momentum surrounding application modernization efforts means containerized applications show growth in the DoD. That, combined with task orders coming out using the Joint Warfighting Cloud Capability (JWCC) contract, leads to the question, “How do we increase the security of containerized applications in this new landscape?”

Traditional ACAS (Assured Compliance Assessment Solution) scans don’t really work in a containerized environment. You can certainly scan containerized applications, but in general, they come back with no findings. Because of this, many application owners and Authorizing Officials (AOs) are adopting a Kubernetes-native security approach to DevSecOps. Or, as I like to say, “Putting the sec into dev/sec/ops.”

Red Hat Advanced Cluster Security for Kubernetes (RHACS) can provide a single view of security across all JWCC providers. Your organization might have workloads in AWS, Google Cloud, Azure and Oracle Cloud, plus an on-prem solution like the Defense Information Systems Agency’s  (DISA’s) Containers as a Service offering. RHACS provides an up-to-date and easy-to-understand view of the security posture of workloads in each of these environments.

At a high level, RHACS covers six security use cases you can view from a unified dashboard across JWCC providers. The use cases are:

• Vulnerability management: Encompasses understanding what known vulnerabilities exist in container images. This employs a combination of out-of-the-box and custom policies that allow the user to see metrics like:
  • Riskiest deployments by CVE Count and CVSS Score
  • Frequently violated policies, such as flagging images that are older than 90 days
  • Most common vulnerabilities
  • Recently detected vulnerabilities
• Network segmentation: Entails understanding the networking relationship between pods. You can build network policy rules to isolate applications and data from one another using Kubernetes. RHACS identifies potential networking security issues, such as, which ports and protocols are and are not allowed or whether there are firewalls between different application components.
• Compliance: This use case examines the actual configuration of the underlying container platform. In this use case, ACS looks at the compliance of the Kubernetes API resources, the container platform, and the nodes running the cluster to check whether the platform meets various regulatory standards, like CIS, HIPAA, PCI, NIST 800-53, etc. The Compliance use case monitors for a suite of controls representing industry and regulatory benchmarks for workloads. For DoD considerations related to OpenShift infrastructure, compliance integrates with Red Hat's compliance operator to provide CIS benchmarks for the OpenShift cluster. DISA has not yet approved the OpenShift STIG, but the CIS controls are typically the source from which STIGs are derived.
• Configuration management: This use case defines a set of controls that examine how an application interacts with Kubernetes. It is not uncommon to view the container itself as the most important application security component when looking at an application in a containerized environment. However, there are many configuration considerations that go into security, including how the application interacts with Kubernetes itself. Consider information like:
  • Service account privileges
  • How the application uses the network
  • How the application interacts with storage or other services in the OpenShift environment
• Risk profiling: This use case provides information about which configurations have risks associated with them. In many cases, the application configurations can be more important than the vulnerabilities found within the applications. Risk profiling defines values for different risks. Here are a few examples:
  • Do containers have root privileges? 
  • Does an environment variable contain a Secret?
  • Does a Java application spawn a shell?
• Violations: This use case shows violations of policies detected in running applications. Aside from flagging vulnerabilities, this section highlights fixable issues with running applications. These violations might be how the application interacts with Kubernetes or a vulnerability on a container application. Some of the highlighted violations include:
  • Security findings, including CVEs
  • Violations of DevOps best practices
  • Suspicious runtime behaviors

Now that I’ve found a security issue, what do I do about it?

This is one of the great questions in DevSecOps remediation. The answer lies in the notion of shifting left in a DevSecOps world. This means planning for security in the early stages of development.

One of the main ideas behind Red Hat Advanced Cluster Security is that it helps users better understand risk so that app owners can decide what's acceptable and provide remediation.

Since containers are immutable, that typically doesn't mean directly addressing the remediation in a running environment. Instead, go back to the container image or the source code and fix the configuration or the image that brought the problem in the first place. This becomes a permanent solution. Rebuild and redeploy container images using the most current and secure container and components, taking advantage of fixes that are already out there.  

DevOps has pipelines that can manually or automatically be kicked off. These pipelines are an ideal place to inject security controls. One of the most common use cases is understanding what vulnerabilities exist in container images and/or their dependencies before building the applications.

I believe the best way to prevent a security flaw is by never allowing it to reach production. That means failing a build due to a security violation. RHACS can also be set to send a warning and not actually fail a deployment.

This approach makes the developers responsible for what they bring to the environment. It also helps them understand and fix the vulnerabilities. Typically, this means using the most recent version of a container. Vendors may have provided a fix for detected vulnerabilities. The developers must move to a version of the component that supports the fix for these noted vulnerabilities.

This sets a guardrail so that the security team can decide whether or not to accept a project advancing in the pipeline if it brings in a serious vulnerability with a known fix. Additionally, you can integrate Red Hat Advanced Cluster Security with your favorite messaging apps, like Slack, Teams or email to notify developers of the outcome of a build process.

Security is paramount in DoD IT. For many DoD entities, containerization is a brave new world where security is a different animal than it was with traditional applications. In many early deployments of containerized applications, one of the major needs was educating the AOs on how security works in a modern application. 

As mentioned above, ACAS, which has been the source of truth for application security in the DoD, is not effective in the world of modern, containerized applications. Having a Kubernetes-native security solution is key to providing secure applications for containerized workloads in general and especially those living on JWCC.