Adapting InfoSec for Container Security
Containerization has effectively become the new normal for expediting app delivery and improvements; security concerns surrounding containers don’t seem to be holding back the tide. And rightly so, because the security of any technology really depends on how it’s used.
Containers are not inherently insecure. What ultimately determines how vulnerable they can be is how developers implement the technology. When development and operations teams focus entirely on accelerating application delivery, they create security holes that can, to put it mildly, keep information security teams on their toes.
So, should you reconsider containerizing your applications? Not necessarily; instead, consider adapting your information security approach to keep pace with containers.
Understanding the Challenges
The latest briefing by the Information Security Forum (ISF) highlights that conventional technical controls like legacy firewalls and antivirus programs with pre-configured rules cannot keep pace with the ephemeral, temporary nature of containers. Since containers often need to communicate with each other as well as with back-end services, especially in a microservices architecture, small mistakes on the developers’ part could allow malicious attackers to manipulate these intricately connected components to expose sensitive data and credentials with admin privileges.
Another factor exacerbating the problem is the use of open source code by developers who are not fully aware of the code dependencies and vulnerabilities. Even if they know about existing vulnerabilities, they may not be keeping track of newly discovered ones. But developing everything from scratch is also impossible in an agile environment.
The Solution: Information Security Should Evolve
The prevalence of containerized applications suggests that the benefits of containers outweigh the risks. But this is just the beginning. As cybersecurity threats become increasingly complex and sophisticated, security strategies must also keep up. And the only way to do that is to embed security throughout the DevOps workflows, from design through production deployment, and facilitate a culture of shared responsibility across the board.
Because DevOps teams work directly with containers and understand the subtle intricacies that information security teams often overlook, it makes sense for them to actively take part in making containers secure by design. As for information security teams, they also need to stay up to speed with how containers work and create security policies and processes accordingly.
Embedding Security in People, Processes and Technology
Container security is a multidimensional undertaking. It shouldn’t be exclusive to the information security team and left to be addressed at the end of the development life cycle. The ISF briefing emphasizes the importance of embedding security in all three aspects of the PPT model (people, processes and technology). Container security best practices should be ingrained in the DevOps teams, and information security teams should provide the guidance and resources needed to implement these security ideals.
In practice, this could look like security teams defining protocols, policies and guidelines for specific security processes like container hardening, building gold container images and performing internal and external code reviews. They can also create security patterns to ensure consistency in these security tasks. For instance, a security pattern may determine all the steps that must always be followed after updating gold images—hardening, scanning and testing. But ultimately, DevOps will be following the established processes while the security team monitors.
Security teams will also need to familiarize themselves with containers to effectively leverage the right technologies where typical technical controls won’t work. Specifically, they may need to work hand-in-hand with the development team for tasks such as creating and incorporating code snippets into the container images for security tasks such as sending logs to SIEM tools and patch management or using infrastructure-as-code (IaC) to create security tools like web application firewalls and network and proxy settings for containers.
In addition to getting everybody on board and defining relevant processes, organizations should use a container orchestration tool to dramatically simplify the management of complex container environments. This brings added security benefits, like:
· Container segmentation to limit excessive data sharing and mitigate potential attacks.
· Encrypted and authenticated communication to prevent accidental data leaks.
· Logging and monitoring capabilities for containers to detect anomalies.
· Deploying passwords into the containers instead of inserting them in the code to protect them from malicious insiders.
Container Security is a Shared Responsibility
Once again, containers are not inherently insecure. It is the lack of security awareness, proper processes and the right technologies that makes them vulnerable. The only way to address container security holistically is to make security a priority for everyone instead of treating it as an afterthought. Companies need to move away from a culture where DevOps teams entirely overlook security and security teams are left chasing after vulnerabilities when an application is ready for production.
Instead, organizations need to embrace a culture of collaboration and shared responsibility. And that means more than just shifting security to the left; it means adopting a ‘security everywhere’ approach. This will also enable them to implement true DevSecOps—the future of information security—where security is everyone’s priority and an integral part of each stage of the container life cycle.