In September 2017, the National Institute of Standards and Technology (NIST) released Special Publication (SP) 800-190, Application Container Security Guide. NIST SP 800-190 explains the security concerns associated with container technologies and recommendations for the image details and container runtime security. It provides prescriptive details for various sections including image, registry, orchestrator, container and host OS countermeasures. Given the popularity of Kubernetes, our mission at Sysdig has been to help organizations mitigate security and compliance risks that inhibit their ability to drive Kubernetes and container deployments. Sysdig Secure provides container security and allows your images to adhere to the NIST 800-190 controls.
I. Container image scanning policies for NIST 800-190The integration of security into Devops is new to many enterprises but is imperative because the development agility Devops practices provides can make applications vulnerable to compliance violations. The out-of-the-box framework for NIST 800-190 in Sysdig Secure allows customers to enforce Kubernetes and container compliance in their container deployment lifecycle and provides additional checks for container images running in Kubernetes and OpenShift environments. These policies can also be customized to create either “Warn” or “Stop” actions.
II. NIST SP 800-190 compliance in CI/CD pipelineYou can ensure compliance to NIST 800-190 by defining image security scanning policy checks prior to deployment. To help you achieve this, Sysdig Secure integrates with CI/CD pipeline tools like Jenkins, Bamboo and many others to scan images prior to being pushed to production or to the container registry.
III. NIST 800-190 compliance reportsIn an audit, organizations are asked to prove compliance over a specific time frame. This poses significant challenges in Kubernetes and containerized environments where developers and application owners are constantly deploying new container images, often without a security review. Sysdig Secure enables you to report on your current compliance posture, and also maintains historical snapshots of policy assessments, enabling you to prove compliance assurance for any past time periods as well. Below you can see a NIST 800-190 compliance assurance report being generated: The compliance report provides:
- Visibility into the resources scanned within repositories and registries that you had specified.
- A high-level view of how many images passed and failed the NIST checks based on your user customized NIST scanning policy. This policy can also be leveraged natively in your CICD pipeline such as Jenkins, CircleCI, Bamboo, and others to prevent vulnerable images from ever entering production.
- The specific compliance controls that were violated. You can click on any of the violations to get more information about the vulnerabilities, packages, known CVEs, etc.
IV. Alert on NIST SP 800-190 policy violationsWith Sysdig Secure you can configure flexible alerts to trigger when a NIST 800-190 compliance policy violation is detected. You can set up different notifications by application (scoped down to Kubernetes resources like clusters or namespaces) or by team, so the owner can quickly respond and address it.
Implementing NIST 800-190 application container security guide with Sysdig SecureSysdig Secure ensures continuous container compliance automation of the NIST 800-190 standard for images running in your Kubernetes and OpenShift environments across the container lifecycle. As a result, Sysdig Secure users can ensure compliance in their image scanning, Kubernetes and Docker containers, at runtime and during audit.
|NIST 800-190 Section 4 Controls
|Sysdig Secure Support
|4.1 Image Countermeasures
|4.1.1 Image Vulnerabilities 4.1.2 Image configuration defects 4.1.3 Embedded malware 4.1.4 Embedded clear text secrets 4.1.5 Use of untrusted images
|4.2 Registry Countermeasures
|4.2.1 Insecure connections to registries 4.2.2 Stale images in registries 4.2.3 Insufficient authentication and authorization restrictions
|4.3 Orchestrator Countermeasures
|4.3.1 Unbounded administrative access 4.3.2 Unauthorized access 4.3.3 Poorly separated inter-container network traffic 4.3.4 Mixing of workload sensitivity levels 4.3.5 Orchestrator node trust
|4.4 Container Countermeasures
|4.4.1 Vulnerabilities within the runtime software 4.4.2 Unbounded network access from containers 4.4.3 Insecure container runtime configurations 4.4.4 App vulnerabilities 4.4.5 Rogue containers
|4.5 Host OS Countermeasures
|4.5.1 Large attack surface 4.5.2 Shared kernel 4.5.3 Host OS component vulnerabilities 4.5.4 Improper user access rights 4.5.5 Host file system tampering
|4.6 Hardware Countermeasures