StackRox this week announced it has added support for additional privacy and security controls defined by the National Institute of Standards and Technology (NIST) to the StackRox Kubernetes Security Platform.
Branden Wood, director for U.S. Federal Government at StackRox, says support for the relevant NIST 800-53 privacy and security controls will make it easier for federal agencies and organizations that do business with those agencies to employ Kubernetes. Organizations that adopt the StackRox Kubernetes Security Platform can at anytime create an instant snapshot of compliance status to identify compliance gaps and vulnerabilities, he says.
The StackRox Kubernetes Security Platform already supports CIS Benchmarks for Docker and Kubernetes, PCI DSS, HIPAA and NIST 800-190, a specification that addresses application container security.
Wood says rather than reinventing the wheel, many organizations are now standardizing on NIST specifications to define their security and privacy controls regardless of whether they do business with the government. Those controls can also be applied to address other data privacy requirements as well as comply with the Federal Risk and Authorization Management Program (FedRAMP) mandate via the StackRox Kubernetes Security Platform.
In general, Wood says many organizations are now quickly moving toward a least privilege approach to cybersecurity that also addresses compliance requirements. As part of that transition, the NIST specifications make it easier for those organizations to address potential blind spots such as segmentation when it comes to container compliance and security, he notes.
Those requirements are then usually addressed as part of the DevOps process that treats compliance as code, Woods adds.
Of course, the rate at which responsibility for compliance is shifting left toward developers varies widely between organizations. In an ideal world, developers would programmatically implement compliance controls as an extension of any workflow defined within the context of a continuous integration/continuous deployment (CI/CD) environment. The implementation of those controls would then be verified by a compliance team. Today most compliance teams identify issues after an application is already deployed and then hope developers have time to address those issues during the next round of bug fixes. Most organizations, however, are still in the early stages of embracing DevSecOps, so it may be a while before they move on to embracing compliance as code.
In the meantime, StackRox is making a case for implementing compliance as code on Kubernetes clusters rather than trying to address each container in isolation. Theoretically, the more Kubernetes clusters that are adopted, the easier it should be to programmatically bake compliance into the application development and deployment process.
Whatever the approach, it is now only a matter of time before auditors turn their focus to Kubernetes deployments. Containers themselves may be a little too ephemeral for the average auditor to track. Kubernetes clusters, on the other hand, provide a constant that inevitably will draw the attention of auditors asking some very pointed questions about the chain of custody within containerized application environments that many DevOps teams currently might not be able to answer.