DevSecOps is not as much about the tools as it is about the people and processes that drive it. Moving from traditional SecOps to modern DevSecOps takes a focused approach as it involves change across teams—Dev, QA, and IT—and across various processes in the organization. Let’s discuss some of the best practices and modern approaches to security that make DevSecOps practices a reality.
Security as an enabler of innovation
Security has traditionally been about gatekeeping, restrictions, and lock down. Its focus has been to build walls that restrict users and communications both internally and externally. This led to security teams and IT taking the blame for hindering progress while developers push for innovation and a more open approach to security. DevSecOps is the answer to this challenge.
DevSecOps practices follows the “shift left” approach where IT becomes a partner with development from the very start of development. Working together, developers become security conscious, and look for ways to build security into their planning from day one. This way when something does go wrong, which it eventually will, Dev and IT are more aware of who owns what, and which decision in the planning stage led to the failure. Troubleshooting is faster, and solutions are more robust as DevSecOps aligns the agenda of Dev and IT under the common goal of securing the application. As development and IT look at security from each others’ perspectives, they become champions of innovation, which they realize isn’t in opposition to security.
Security as a consumable service
IT approval ends up being the bottleneck in many projects because IT has placed a heavy burden on itself to manually monitor and approve every small feature that needs to be launched, every environment that needs to be created, and every incoming network request. The default mode of operation is mistrust and fear. However, this approach is detrimental to progress, and isn’t even effective, as eventually something will get through the cracks. On the other hand, taking an automated approach to security is what’s needed to enable the scale that modern cloud-native apps require.
This involves using templates wherever possible. It echoes what IT is used to from the infrastructure as code era with tools like Chef and Puppet. However, this approach doesn’t just apply to the configuring of hardware instances—It applies to other parts of the development process as well. Containers have especially made this a reality, as you can package code and its dependencies in a container image and make it internally available via a private container registry. By leveraging containers, IT can create default templates at the start and get out of the way, allowing internal users to quickly leverage pre-approved and secure components that are enabled by IT.
When this happens, security becomes distributed, and isn’t controlled or bottlenecked by a central approving authority. This is a natural extension of the underlying change that’s swept across software delivery where cloud-native apps use a distributed microservices architecture.
Role-based access control
RBAC is the approach of giving access to users and applications based on which group or role they fall into. It looks to abstract the job of making individual security decisions to a higher level. RBAC is not new as a concept, but it has taken on a new avatar in the era of containers. The container stack is complex with new parts such as a registry, orchestration layer, and a more complex networking model. This change has a bearing on how RBAC is handled.
RBAC policies for containers are created and controlled by a container orchestration tool like Kubernetes. They operate at the level of namespaces, and enforce limits at the API level. While admins of a Kubernetes namespace can assign roles and controls for other users, they still don’t have access to all resources within that namespace—That’s reserved for a cluster-admin. Users with the ability to create pods within a cluster have escalated privileges that enable those pods to make use of secrets, but these secrets are still hidden from the users themselves. In this way, Kubernetes has very strong defaults for RBAC, and is an essential part of the DevSecOps agenda.
Policy-based network security
The method of distributing security goes from operations into network security as well. With the network, rather than a peripheral firewall, enforcing micro-firewalls around each service is the order of the day with cloud-native applications. They provide a higher level of security and isolate services from each other during times of attack. Project Calico is breaking new ground in this respect, and is one of the network security tools at the forefront of container security.
The role of security testing is not to ensure restrictions and firewalls are configured correctly and working, but rather to look to breach these security protocols even if they’ve been configured correctly. Security testing should look to break things, and attack the system like an outsider would. Security teams are familiar with the concept of blue and red teams where red teams attack the system, and blue teams act as the internal security team protecting the system. This can be helpful, but it can be difficult to accurately reflect an outside attack in scale and complexity. It requires familiarity with commonly known vulnerabilities and external threats.
Netflix had pioneered the “chaos monkey” principle a few years ago, and it still is relevant in a container system where there’s a need to have a backup option for different components like storage volumes, network connections, and host machines. It still pays to actively take down random resources and attempt to sustain service uninterrupted or restore services back in the quickest possible time.
Threat detection at runtime
Apart from all these approaches to securing the container system from inside, a requirement for DevSecOps practices in the container age is threat detection during runtime. This involves analyzing container performance and all related components, both internally and externally.
Tools like Twistlock analyze large quantities of data generated by container systems and are adept at spotting suspicious patterns before they turn into emergencies. They leverage security data from external agencies, and even use their own customers’ anonymized security data to create a more intelligent security platform. A threat detection tool keeps you a step ahead of attackers, and is the need of the hour when managing containers in production.
DevSecOps practice is not a “set it and forget” it task. It is instead the essential fabric of an organization’s software delivery culture. Making DevSecOps a reality involves a complete overhaul of security practices that includes providing security as a consumable service, following a distributed approach to security, adopting modern approaches like RBAC for containers, policy-based network security, and most importantly, threat detection during runtime. It can seem like a lot—and it should be, considering how much is at stake.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Your Firewall’s Role in Cloud-Native Security
We live in the cloud-native era. That means the firewall strategy that...
Compliance, Microservices and Your Application
Compliance in modern applications that leverage containers, serverless...
6 Tips for Secure Data Management for Containers
One of the main reasons why containers have become so popular is that ...
OpenShift Internal Registry: Populating Registry Scans with Twistlock
Twistlock uses the Docker v2 Registry catalog API call to inventory im...
Better Together: Protecting Docker Registries with Twistlock and JFrog Artifactory
In a containerized devops lifecycle, a registry such as JFrog Artifact...