Many enterprises today are implementing security solutions that can be deployed and maintained more quickly and easily, and at lower cost, using a DevOps methodology.
Organizations applying DevOps to security are not looking at IT groups separately as the database team and the application team; rather they see everything as the delivery team. It’s also a team that works together that deliver security services for customers.
Application, database, network and endpoint security have traditionally been segregated, and you can see how that is built into the tools. DevOps is about bringing these pieces together and integrating operations because it’s about implementing security starting at the top of the value chain—the customers. Ultimately, we look at the value we’re delivering for the customers with security and really making sure we are inserting it into the front of the pipeline. Leading DevOps shops integrate security upfront when building the next big product, feature or service for external or internal users.
Related Content:
DevSecOps: Putting Database Sec In DevOps
DevOps Introduces Complexity. Really
There are several different models of organizational structure used to insert security into the software development life cycle. Most make sure it is an integral part of everything that gets released. But the point is that it needs to be integrated. It needs to be a living part of everything an organization is doing.
One effective choice is make sure DevOps engineers are focused on the standardization of the network and the application.
For example, look at locks. Most of the time, developers are keeping all passwords in locks. As a DevOps team, we’re sharing locks. That means that all credentials, even credit card information, can be exposed. Before we release the features, we need to think about security and remove passwords and credit card details.
[su_pullquote align=”right”]Security needs to be a living part of everything an organization is doing.[/su_pullquote]
When we look at the network and the database side, we need to disable all ports, and this is important to do before releasing things. Disable all the network ports and bring all the databases into these, and open only relevant ports.
If you are going to embed security, it’s actually cheaper, more efficient and faster to do it in the DevOps team; otherwise, you have to train engineers in application, database or network teams on security or add an expert into those teams. But, if you add the security expert into the DevOps team, you could involve fewer people or simply additional people who are cross-trained.
When we talk about cost savings and cost reduction with our clients, we focus on two things. We look at the model that shows how the cost of finding defects goes up as the product is developed. If you can include quality from the beginning, you reduce cost of maintenance and cost of quality—that’s the first thing. The same is absolutely true of security—that’s the second thing.
When you’ve got an integrated SRE full-stack engineer working hand in hand with the development team, they’re thinking security, operational agility and maintainability of the system from the get-go, and they’re inserting those non-functional requirements and making sure they’re adhered to across the stack.
This method is not at the exclusion of having the application team run code tools on security on their applications. Rather, it is someone who is looking at all these pieces and making sure they’re being done correctly.
Ultimately, we’re producing a product that is not only functional, but actually operable in an efficient and effective way. It can’t break every minute, causing us to spend millions just to keep the darn thing alive. It works the same way with security.
Even if it’s operable, if we get hacked, the company has a massive data breach liability.
By having skilled engineers on the front line—particularly skilled DevOps engineers on the front line—you’ve got folks who are thinking in that full-stack mode about the security implications of the system’s operation and any issues they may see, making them more able to identify things that are potential threats.
Like both DevOps and SEO, I think that Security should not be a role or a responsibility, but a way of thinking. The burden of responsibility around security has to be shared across the organization. The protection of PII, PCI and sensitive business data should be factored into the architecture, development and monitoring of your applications and infrastructure by Dev and SRE. The SRE team should ensure that you have systems in place for secure key management for application/api security, and that service/data access layer resources are behind a private vlan that is acl restricted to the web app layer. PII should be stripped from all query parameters. The SRE team should also ensure appropriate app logging, and central log aggregation for analysis, reporting and anomaly detection. But I think that there is still a lot of value for a modernized security role or team, from standpoint of having an advisory expert in policy, auditing and anomaly review, and both tactical and legal response in the event of an attack or breach.