Bolting on security after the fact. It’s been a common approach to software security for decades.
We architect, build code, deploy it and then figure out how to secure it. From the parade of application-related breaches and data thefts over the last few years, we pretty much know this approach does not work.
Fortunately, the evolution of continuous deployment and
DevOps, when coupled with the use of containers, offers great potential to improve application security.
Automated build pipelines provide the opportunity to include security checks into the build process, applying a range of tests to ensure every time we check in code that there is a single process to validate the application for functionality and security.
Static analysis, composition analysis, dynamic analysis, custom tests for keys and credentials and other simple solutions are available commercially and in open-source. This helps us make the code secure and obviates the need for some external security controls. These tools help you ‘look inside’ containers during the build process and validate content and function so the container has security built in regardless of where it is run.
Automation ensures these tests occur quickly and results are integrated into trouble-ticketing systems and source code control. Once validated, code is placed into secure registries. As a result, only trusted code makes it into production, thereby helping to avoid ‘pre-owned’ images from the Internet.
Containers are not commonly considered an advancement for security. With the move to micro-services, we are breaking down monolithic applications into simpler, easier to manage, and easier to scale components. An application essentially becomes a collection of loosely coupled services.
Containers are an ideal medium for this conversion, as they let us wrap a simple service into a consistent unit of delivery. If you think about it, this helps with security, as the encapsulation of one aspect of an application keeps the code – and the dependencies – simple. It makes security testing and manual scans easier and faster. And at runtime, it helps us isolate containers by function so that any given host is shared only by instances of the same container, offering segregation of data and resources from attack.
Despite that, we are witnessing this trend: with the rise in popularity of orchestration managers like
Kubernetes, cloud ‘containers-as-a-service’ offerings, and some of the practical considerations with micro-services, we again see the focused move toward infrastructure-oriented security. Many of these tools limit – or outright break – old-school firewall and monitoring because the framework itself does not promote those security models. For example, cloud service vendors won’t let you bolt security products onto their offerings.
As many developers have discovered, the micro-services
ideal is not always practical, so something called ‘Sidecars’ – essentially other containers with additional functionality -- are introduced.
These might help proxy communication with other services or perform monitoring functions. Not ideal, but one potential approach to address shortcomings with micro-services if you cannot fix the issue with application architectures. But in an effort to re-introduce traditional monitoring, assessment and firewalls into these new deployment models, we see yet again that security vendors are packaging their technology into Sidecar containers to run in the same Pod or namespace as application components.
In general, security services delivered via Sidecars are neither good nor bad; they capitalize on a design pattern to deliver traditional technologies. But these approaches are secondary to the real advancement that containers and DevOps practices provide by building security in from the start.
Your biggest gains in
application security will come from securing your application code during the design, development and testing phases. Securing your application should be your first line of defense. Use of old models of bolt-on proxy services can offer added security, but real gains come from building secure applications.
Join us for a live webinar on September 27, where we will walk you through essential tips on container assessments and streamlined DevOps security. You’ll also get a quick introduction to Tripwire for DevOps, the SaaS tool that automates DevOps security with dynamic container analysis right inside your Jenkins dashboard.
Attendees will hear expert advice on:
- DevOps best practices for quickly resolving security issues
- Security analysis for source code and web application tools
- Avoiding misconfigurations without stalling the CI/CD pipeline
They’ll also be able to earn a CPE credit for attending.
Register here.
About the Author: Adrian Lane is a Security Strategist and brings over 25 years of security and application development experience to the Securosis team. Adrian specializes in data security, database security, cloud security, and secure software development. He has experience at Ingres, Oracle, and Unisys, he has extensive experience in the vendor community,
but brings a pragmatic perspective to selecting and deploying technologies having worked on "the other side" as CIO in the finance vertical. Prior to joining Securosis, Adrian served as the CTO/VP at companies such as IPLocks, Touchpoint, CPMi and Transactor/Brodia
. He has been invited to present at dozens of security conferences, contributed articles to many major publications, and is easily recognizable by his "network hair" and propensity to wear loud colors. Adrian is not ‘The real Randall Waterhouse’, but he is a Computer Science graduate of the University of California at Berkeley with post-graduate work in operating systems at Stanford University.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
