In a recent article on the GovDevSecOpsHub, we featured the first of a three-part interview series with Michael Epley, the Chief Architect and Security Strategist for Public Sector at Red Hat. We sat down with Michael following the company’s announcement in January of this year that it was acquiring StackRox, a leading provider of container and Kubernetes security software solutions.
In the first part of our discussion, we asked Michael to explain the unique security challenges that containers and Kubernetes create for development teams, and why adding the capabilities and solutions from StackRox to the Red Hat portfolio will help application developers overcome these challenges.
In the second part of our far-reaching discussion about container and Kubernetes security, we asked Michael about the current threat landscape facing government agencies, the impact of complex application development lifecycles on compliance and security, and what it means to say that an application is “Kubernetes native.”
Here is what Michael had to say:
GovDevSecOpsHub (GDSOH): Today’s government agencies are at high risk of cyberattacks from a large number of incredibly sophisticated cyber threats – all just searching for vulnerabilities in their applications and networks to exploit. What is this threat landscape currently like and how are government agencies working to keep pace?
Michael Epley: This is absolutely correct. Cyberattacks are on the rise and attackers are getting more capable. These cybercriminals are powered by increased levels of organization and funding – either as a result of state-sponsorship, adjacent criminal enterprises, compounding gains from their own exploits, or maturing black market for cyber vulnerabilities and exploits. Simultaneously, rapidly growing complexity in networks, systems, applications is making risks and vulnerabilities harder to manage.
None of this is a reason to fear, however. Our powers to counter these threats, minimize risks, and respond to failures are also increasing exponentially.
Governments are targeted for the real – and often very large – impact that successful attacks can have, as illustrated by recent attacks like Solarwinds and MS Exchange. Adopting a cloud native strategy is an important tool to protect ourselves.
The separation of concerns between IaaS, PaaS, and SaaS allows users to focus their risk management efforts where their needs and capabilities lie and allows] the cloud service providers to leverage their expertise to maximum effect. This separation of responsibilities mirrors the benefits of containers for DevOps. Security practitioners can focus on the aspects of their application layer they can control while inheriting the security of the stack below.
GDSOH: How can a platform like StackRox help government users meet these security and compliance challenges?
Michael Epley: Regulations and compliance regimes are necessary to allow providers to prove the underlying and real security or risk afforded to their tenants. The standards and compliance regimes are labyrinthine puzzles to the uninitiated and are often derided as providing only a veneer of actual security. The causes for skepticism vary but are driven by ignored policies, gaps in compliance, ineffective security controls, human error, and untrained or inexperienced implementers.
Kubernetes and container ecosystems epitomize this challenge from its novelty alone and merely by its own complexity. Technical layers in a typical Kubernetes distribution include paired software-defined networking, or service meshes, externalized deployment, and lifecycle management. Stackrox converts security baselines common for our government users — NIST SP 800-53 and SP 800-190 — into actionable and enforceable policies. NIST provides only generalized implementation guidance for government users but StackRox provides the practical, concrete, and consistent application of these rules.
“Governments are targeted for the real – and often very large – impact that successful attacks can have, as illustrated by recent attacks like Solarwinds and MS Exchange. Adopting a cloud native strategy is an important tool to protect ourselves.” – Michael Epley
By helping automate the otherwise time-consuming and laborious assessment of Kubernetes-based infrastructure, StackRox allows frequent and reliable assessments and continuous monitoring and diagnostics without needing to become experts in these technologies. System owners need to provide the necessary body of evidence for the accreditation process to Accrediting officials (AOs) and Stackrox’s inventory and compliance dashboards allow confidence for both sides of this transaction and enable rapid ATOs. StackRox’s Integration of threat and risk data – including Kubernetes and container relevant CVEs – into this assessment process also positions agency CISOs to move towards continuous ATO processes.
GDSOH: How widely adopted is Kubernetes in today’s application development teams?
Michael Epley: The adoption of Kubernetes today is wide and growing fast, but it’s heavily focused on the operations side of most enterprises at the moment. But Kubernetes has also been described as a DevSecOps platform and offers tremendous benefits for developers and DevOps minded teams. In fact, Red Hat’s own Kubernetes-based platform, Openshift, was built to be used by developers from the outset, in part because containers are such great tools for enabling developers using agile and DevOps processes to work better, faster, and cheaper.
Openshift leverages the properties of containers and Kubernetes to automate a DevOps pipeline, extending Kubernetes’ API to include constructs useful to developers – such as Builds, Pipelines, or DeploymentConfigs, to name a few – that allow declarative expressions of developer’s intent, enforceable patterns so alpha developers and DevOps engineers can provide guardrails, and automated or default implementations to minimize friction in the processes.
“The standards and compliance regimes are labyrinthine puzzles to the uninitiated and are often derided as providing only a veneer of actual security. The causes for skepticism vary but are driven by ignored policies, gaps in compliance, ineffective security controls, human error, and untrained or inexperienced implementers.” – Michael Epley
By definition, Kubernetes ties together some of the most difficult problems in computer science — process and resource isolation, distributed systems engineering, reliability engineering — and we can’t also expect developers to be security experts in these fields as well. Developers aren’t generally going to be well versed in the underlying platform technologies that make Kubernetes and the infrastructure it relies on work — nor should we expect them to be so.
Similarly, the shift from DevOps to DevSecOps is asking developers to again become experts in and take responsibility for security throughout their application lifecycles. If our goal is for application development teams to be successful in adopting cloud native application paradigms, we need to make it easier.
GDSOH: Why is it important that StackRox is Kubernetes-native – and what does that really mean?
Michael Epley: We ask a lot from developers to deliver solutions – meeting customer and business requirements on time and under budget. Making it easier for developers requires us to automate as much as possible, hiding the implementation details from the developers while converting and exposing feedback in ways that will be relevant to developers.
Security must also either be an inherent property of the tools and platform they use and thus ubiquitous and unavoidable, or developers will be forced to work around or bypass controls. By using hooks into existing CI/CD tools, container and Kubernetes native APIs that can’t be bypassed, and system-level events, StackRox provides the ubiquitous presences within the cloud native application development platform to force developers to adhere to StackRox’s features. It prevents developers from making errors or misconfigurations that might reduce their overall security by automating security checks for privileges and Kubernetes RBAC controls, or network configurations to eliminate unnecessary network accesses.
KubeLinter is a new open source project from StackRox that exemplifies the efforts to minimize developer error and misconfiguration when using Kubernetes and automates the process of validating Kubernetes objects and application definitions in Helm charts for best practices.
“Developers aren’t generally going to be well versed in the underlying platform technologies that make Kubernetes and the infrastructure it relies on work — nor should we expect them to be so.” – Michael Epley
StackRox also converts the Kubernetes and container security controls and compliance into the same frameworks and reporting mechanisms in use already, making it easy to use. As developers learn how to execute DevOps using the features and capabilities of these tools through declarative and data-driven processes, CI/CD and automated build and test tools, and continuous monitoring and diagnostics, StackRox fits right into these workflows.
Introducing security into the mix with StackRox is not disruptive to DevOps adoption and reinforces the role that developers play in security and compliance. A clean developer and operations experience via built-in dashboards lets developers and operators, alike, quickly see what security impacts their code may make against compliance and security controls. By pinpointing issues to the relevant Kubernetes and container components, StackRox allows developers to react quickly and early in hardening processes to lower compliance costs and overall risk.
Getting developers to use Kubernetes and containers presents challenges and risks, as well as opportunities. All security investments should be driven by risk, a calculation that accounts for the potential threats as well as impacts. The StackRox platform is Kubernetes native because the threats and impacts to Kubernetes and containers are unique to these technologies and – as noted – we can’t expect developers also to become experts in understanding the relevant threats and impacts.
With Stackrox, the risk calculation is now automated and informed by Kubernetes and container-specific threat analysis and responses and mitigations tailored to these technologies for maximum effectiveness. Developers can put their attention to securing their code, dependencies, and supply chain where their skills offer the most benefit.
To learn more about Red Hat’s acquisition of StackRox, click HERE.
