On April 29 of this year, the Department of Homeland Security issued Binding Operational Directive (BOD) 19-02, Vulnerability Remediation Requirements for Internet-Accessible Systems. According to the DHS website “a binding operational directive is a compulsory direction to federal, executive branch, departments and agencies for purposes of safeguarding federal information and information systems.”

BOD 19-02 states the case for early, quick vulnerability remediation:

“…it is more critical than ever for federal agencies to rapidly remediate vulnerabilities that otherwise could allow malicious actors to compromise federal networks through exploitable, externally-facing systems. Recent reports from government and industry partners indicate that the average time between discovery and exploitation of a vulnerability is decreasing as today’s adversaries are more skilled, persistent, and able to exploit known vulnerabilities. The federal government must continue to take deliberate steps to reduce the overall attack surface and minimize the risk of unauthorized access to federal information systems as soon as possible.”

BOD 19-02: What to know

Before BOD 19-02, DHS released BOD 15-01 which also focused on critical vulnerability remediation. The latest binding operational directive builds on 15-01’s use of the DHS Cyber Hygiene scanner.

In summary, the DHS Cyber Hygiene scanner inspects all U.S. Government agencies’ Internet facing services for vulnerabilities. The agencies will be provided with a Cyber Hygiene report of the scan’s findings and will be responsible for remediating the critical and high vulnerabilities detected on the agency’s Internet-accessible systems as follows:

  • Critical vulnerabilities: Remediated within 15 calendar days of initial detection
  • High vulnerabilities: Remediated within 30 calendar days of initial detection

How Twistlock can help

Twistlock empowers organizations to secure their cloud native applications across the application lifecycle by scanning your hosts, images, and functions for vulnerability and compliance issues as part of the CI process, continuously monitoring your registries for new vulnerabilities and compliance issues, and protecting your applications at runtime along with global risk prioritization.

What is a vulnerability

Twistlock uses the Common Vulnerability Scoring System (CVSS) for all vulnerabilities the same “high” and “critical” scoring range used by the Cyber Hygiene scanner report. Twistlock CVSS scoring is based upon the National Vulnerability Database’s Base Score.

Identifying vulnerabilities

Twistlock identifies vulnerabilities throughout the life of your applications by scanning for vulnerabilities during the build, ship, and run phases. Let’s take an example of building an Internet facing web application that uses the Apache Struts 2.3.x plugin. Here is how Twistlock can help identify, alert, and prevent this critical vulnerability.

Build Phase

Here is a Dockerfile in which I am using the tomcat:7 image and Apache Struts v2.3.12:

FROM tomcat:7

ARG struts2_version=2.3.12

RUN apt-get update
RUN apt-get -y install curl git nmap dnsutils 
RUN set -ex \
  && rm -rf /usr/local/tomcat/webapps/* \
  && chmod a+x /usr/local/tomcat/bin/*.sh
RUN curl -o /usr/local/tomcat/webapps/ROOT.war http://central.maven.org/maven2/org/apache/struts/struts2-showcase/${struts2_version}/struts2-showcase-${struts2_version}.war
EXPOSE 8080

Using the Twistlock Continuous Integration (CI) scanning tools you can identify the critical Apache Struts vulnerability, stop the build process since the image contains a vulnerability that exceeds my vulnerability thresholds, and notify the developer. For example, a Jenkins Pipeline build using the Twistlock Jenkins Plugin to scan the image will stop the build process and inform the developer that the image contains known critical vulnerabilities, as shown in the screenshot below:

Twistlock is informing the developer that the vulnerability has been fixed in v2.3.33 and allowing the organization to shift security to the left.

Ship Phase

Twistlock will scan your images local to the hosts and within your registries, with the ability to show just the high and critical vulnerabilities that have available fixes. This capability allows you to quickly and easily address the high and critical vulnerabilities that can be fixed immediately.

In the screenshot above, you can see my vulnerability policy window set to Alert on High and Critical vulnerabilities. Then, you can see the images in my registries that meet those requirements.

The vulnerability column is only showing high and critical vulnerabilities with known software publishers’ fixes.

Run Phase

Twistlock provides the ability to block known high and critical vulnerability images from running as containers. For example, I can edit the my vulnerability policy to block the starting of images with high and critical vulnerabilities that have associated software publishers’ fixes as shown in the screenshot below. I can also include a grace period before the rule takes effect to ensure the dev/test process has time to complete.

My rule is in effect. When I try to start the container the process is stopped, and my terminal returns access denied:

$ docker run -it registry.infra.svc.cluster.local:5000/tl_demo/struts2_
demo:1
docker: Error response from daemon: OCI runtime create failed: [Twistlock] Image operation blocked by policy: Block
high and critical vulnerabilities, has 29 vulnerabilities, [high:18 critical:11]This image is being blocked due to
high and critical vulnerabilities - DHS BOD 19-02

Additionally, the corresponding alert appears in Twistlock Console:

But what about vulnerabilities that emerge after the now vulnerable image is running as a container? Twistlock Vulnerability Explorer correlates all this information for you.

Let’s say you built this image two weeks ago and a new critical vulnerability is identified. Console will update its vulnerability threat information from the Twistlock Intelligence Stream. Twistlock Vulnerability Explorer will identify:

  • The package (org.apache.struts_struts2-core:2.3.12) associated with the vulnerability,
  • Which image (tl_demo/struts2_demo:2.3.12_build) that package is in
  • Which node (master-1903311-paul-lab-twistlock-com) within your environment that image is running as a container

Don’t stop at just your publicly facing vulnerabilities, use Twistlock to identify all vulnerabilities, and compliance issues while protecting your applications at runtime.

As I mentioned earlier, Twistlock scans for host-based vulnerabilities as well.

Conclusion

Twistlock has long supported U.S. Government Agencies and their laws, regulations, and guidances. Twistlock is one of the authors of NIST SP 800-190, the Application Container Security Guide, we are proud to continually provide security guidance for both federal customers and enterprises.

I hope this blog post helps provide insights into the latest binding operational directive and how Twistlock can help you scale your cloud native applications securely.

← Back to All Posts Next Post →