Most traditional security tools agencies rely on aren’t designed to effectively show what’s going on inside of a container.
Open-source container technology has already disrupted traditional software development practices. Now, containers are poised to upend the way federal IT professionals secure those practices.
Securing containers necessitates a “shift left” mentality, where security is fully integrated into the entire development process from start to finish. To make the shift, developers must move on from legacy security tools and procedures and employ a combination of cloud-native security solutions while building security into their application development pipelines.
Let’s look at why this is important and how to tackle this challenge.
Lack of Visibility into Containerized Applications
Federal agencies have long relied on traditional security tools, like host intrusion detection systems and antivirus software, for protection, but these solutions were not built for modern container deployments. Most aren’t designed to effectively show what’s going on inside of a container and are therefore ineffective at container security.
These solutions could even be harmful by creating a false sense of security. A security team that is used to using a virus scanning software, for example, could apply that tool to the applications running within their containers and check their security box for compliance. But, they may not realize that the scanning solution they’re using isn’t equipped to accurately assess the containerized application. They feel like they’re covering their bases when they’re really not.
Scanning Containers and Developing Security Policies
To help address this gap, the open-source community is developing technologies that facilitate best security practices of containerized applications.
The community has created technologies specifically designed to provide end-to-end security through the software lifecycle. These tools effectively “see” into the container and perform deep scans to detect trojans, viruses and malware contained within the images. They can also enhance runtime security by identifying possible anomalies, behavior changes and exploitations while the application is running in production. The list of capable open-source projects is very wide, but a few of the more popular ones include SonarQube (for code quality); Anchor (scanning and policy); Falco (runtime security); KubeBench (security and policy); Open Agent Policy (policy) and OpenSCAP (security and policy). Many cloud-native architectures also have adopted service mesh technologies such as Istio or Linkerd to implement dynamic security models, including zero-trust models that spun out of Google.
One of the top tools available in the cloud-native policy space is the Cloud Native Computing Foundation’s Open Policy Agent (OPA). This project outlines a consistent way to enable better security policy around the cloud-native ecosystem. OPA provides a common policy language that’s easily programmable and consistent across that ecosystem. Leveraging OPA, teams can now build policies to meet the needs of highly regulated industries that want to adopt emerging technologies. By adopting OPA, agencies can write the same security policies for their service mesh tooling as they would for Kubernetes or another container orchestration system–a great benefit for agencies used to juggling many different policy tools.
The Importance of DevSecOps
Beyond tools and policies, the general consensus among federal IT professionals has seemingly always been that security is everyone’s responsibility. That includes the developers working on the applications.
While that statement is still true, it’s important to put in well-defined APIs and boundaries between code check-in and production. This is where DevSecOps adds value. By bringing security teams into the development process, you can build automated security and compliance checks into the same deployment mechanisms that are shipping code into production. Applications can be automatically checked for the quality of their code and vulnerabilities or errors in container images.
This is not to say that developers shouldn’t still take security seriously, it’s simply recognizing that security isn’t necessarily their area of expertise. Having automated security checks in place throughout the container development process can lend an air of “trust, but verify” to that process. It’s a means of supporting development with sound security practices aimed at covering any security holes that developers may have missed.
Sorting through the Noise
Containers are very effective for accelerating application development, but effectively managing their security is critically important. However, there’s no reason organizations can’t be both agile and secure. Today, there are many options available to help agencies effectively secure containerized application development.
Indeed, some may argue that choosing the ideal cloud-native security tools might be the biggest challenge of all. For them, selecting the right partner who can sort through the noise may be the first step forward in their path toward a modern security approach for their container development methods.
John Osborne is a chief architect at Red Hat.