Maksim Kabakou - Fotolia
A DevOps security model calls for businesses to realign teams and establish new practices, but despite an abundance of tech tools and good intentions, it's still much easier said than done.
Friction with organizational inertia isn't a new story in DevOps. But, as urgency grows around IT security while businesses undertake digital transformation, developers and IT ops pros continue to encounter thorny challenges that hamper deeper collaboration between technical and business teams.
"DevOps has been focused on CI/CD and getting code to cloud, but there hasn't been much focus on business collaboration with DevOps teams," said Carmen DeArdo, an independent DevOps consultant and a senior value stream management strategist at Tasktop, a software lifecycle management company in Vancouver, B.C. "Most IT departments still don't speak the language of business."
Agile app development, DevOps app deployment and security vulnerabilities have accelerated to a degree that necessitates a change in the way in which most organizations prevent data breaches. Companies must realign their business and IT teams into product-focused groups and move away from project management that emphasizes getting code out the door, which can de-emphasize ensuring it functions safely long term.
Companies also must break down monolithic org charts into small, loosely coupled teams, reminiscent of modern microservices application architectures. This compartmentalization will make skyrocketing technical complexity manageable and reduce the severity of security breaches.
"You'll never be completely sure you're secure, so the best route is to create a cellular structure of build-and-run teams that don't have access to the whole enterprise," said Jeremy Pullen, CEO and principal consultant at Polodis Inc., a DevSecOps -- that's DevOps with a focus on integrated security -- advisory firm in Tucker, Ga., that works with enterprise clients. "But most companies I talk to are nowhere close to shifting left on the product requirement side to build that kind of security in from the beginning."
Most enterprise IT departments still struggle to assemble multiple technical disciplines, such as application development and IT security, let alone to fold business experts into product-focused teams. In part, this is because the IT side of a company would need to initiate difficult conversations with business owners.
"It's much easier to change the technical side to work more closely together than [it is] to tell a business unit, 'Your organization isn't efficient,'" said Richard Fong, senior software engineering manager at Mitchell International, an auto insurance software company in San Diego. "And it's still not easy to work more closely between DevOps and security."
However, with high-profile security breaches in the news on a regular basis, to say nothing of the competitive pressures traditional enterprises face from disruptive tech-focused startups, there's a willingness to overcome cultural resistance. Unfortunately, that's when the realities of business practices, such as binding contracts, set in.
Companies that outsource IT management tasks to service providers, for example, can find their attempts to restructure into cross-functional teams blocked by the fact it would change the scope of work in those contracts. It will take years before these business practices change.
IT pros try to solve DevOps security tools' fragmented puzzle
Attackers won't wait patiently while enterprises struggle to reorganize with a DevOps security model. Security breaches won't stop, so the next best option for IT pros, in the absence of an organizational overhaul, is to ensure organizations can respond quickly to contain them.
Tools, particularly those focused on application container security, have begun to bake in artificial intelligence to reduce the noise of false alerts and quickly identify anomalies that could be the hallmark of a security breach. However, few IT security tools -- especially from startup providers -- offer a holistic view of the entire enterprise. The most innovative security tools primarily focus on containers, serverless functions or microservices architectures. Tried-and-true IT security monitoring tools, in many cases, have yet to catch up to new approaches to application deployment and infrastructure automation.
Jeremy PullenCEO and principal consultant, Polodis Inc.
"We're at a renaissance phase where we're creating new orchestration systems, and it's an exciting and nerve-wracking time before best practices and industry consolidation occurs," said Steve Herrod, managing director of General Catalyst Partners, a venture capital firm that invests in IT infrastructure startups, including in the security market. "Specialized tools give an already-overworked enterprise security team another set of data to manage."
Enterprises hope that widespread use and standardization on infrastructure automation frameworks, such as Kubernetes container orchestration, will help create a more holistic view of security.
"Containers clean up some of the complexity of deploying applications across multiple platforms and targets and could bring standardization to the table for companies that have to account for all the different application delivery models," said a senior architect at a large insurance company on the East Coast, who spoke on condition of anonymity because he is not authorized to represent his employer in the press. "But the security piece continues to be a big puzzle. We have security at different points in the toolchain, but the overall chain is potentially fragile."
Meanwhile, widespread use of open source software frameworks such as Kubernetes is a double-edged sword. Security problems in those frameworks can be well-understood, but the impact of vulnerabilities exposes many companies and products that use the framework to security risks.
"The positive aspect of things like Kubernetes is the microservices approach, where you can push code out without changing the entire app, which offers an increased ability to respond to security issues," Herrod said. "But there's also higher risk when a common set of code has such broad reach."