As automation touches more of your organization, security will be far from automatic. Bots’ privileges need close scrutiny, for example.
DevSecOps: 7 habits of strong security organizations
What behaviors do today's strongest security organizations share – and what can you learn from them? For starters, treat security as much more than a step
A burglar sizes up two houses. The first has a security system and a vicious guard dog; the second is unlocked and no one’s around.
Guess which house the burglar is going to try first? He’ll take down the easier mark.
There’s corollary in IT: Some companies are simply less secure than others. While there’s no such thing as “100% secure” – everyone is susceptible to a breach – that doesn’t mean you need to invite potential threats in through an unlocked back door. These days, it’s probably not just a back door, either, but a whole host of entry points, physical and virtual.
[ Are you a DevOps job seeker or a hiring manager? Get our free resource: The Ultimate DevOps Hiring Guide. ]
So we asked a group of IT leaders and security experts: What characteristics do strong security organizations have in common? What do they do that the rest of us can learn from to improve our own security posture?
“Strong IT security organizations really are baking DevSecOps into their technology DNA from Day 1,” says George Gerchow, CSO at Sumo Logic.
Indeed, DevSecOps culture has become an increasingly popular way of reconciling the goals and demands of the digital age with an incredibly complex security landscape.
[ Does your boss thwart your efforts? See our related story: Bad DevOps bosses: How to deal with them. ]
Whether you call it DevSecOps or not, the principles and practices have plenty in common with the characteristics of strong security shops at large. Read on to learn what strong DevSecOps organizations do to foster security while still driving their most pressing business and technology priorities.
1. Treat security as a culture, not a step
In the monolithic age of IT, security was often treated as a step – often just before a production release – in the software development lifecycle. That puts security pros in perpetual conflict with the rest of the team. Discovering vulnerabilities at that late stage becomes a matter of choosing the lesser of two evils: Delay the release, or release vulnerable code.
Security bolted on at the end of a delivery pipeline also tends to mean security is largely in the business of fighting fires – usually big ones in production – rather than preventing them. That’s a treacherous business in the age of hybrid cloud architectures, multi-cloud strategies, and other facets of modern IT.
IT shops with strong security postures tend to treat security as a matter of culture rather than a step in a process.
Indeed, “long-term” is an operative phrase. There’s no point at which you declare “we’re secure” and cross security off the to-do list.
“Any short-term initiative might appear to hit the mark, but in reality is merely a façade,” Valani says. “Building that culture implies changing the mindset of individuals and teams.”
2. Fully embrace the “shift security left” mindset
The term “DevSecOps” itself represents the evolution from the “step in a process” mindset to a robust culture of security – one that moves security as far to the “left” in the SDLC as possible (“left” referring to earlier phases of the traditional SDLC, which is often represented as a left-to-right timeline or process.)
“Organizations that lead a successful approach to IT security embrace a ‘shift left’ mindset – meaning they bake security measures into the very foundation of their IT,” says Robert Hawk, privacy and security lead at xMatters. “This entails not only addressing security concerns at the code level, but making the code itself more robust, modular, and mature.”
Robert Reeves, CTO and cofounder at Datical, notes that DevSecOps shops commonly incorporate security reviews into the development and testing stages of their pipeline. And they don’t stop there.
“The highest performers go a step further and codify security policies into Dev and Test environments,” Reeves explains. “For example, if it’s a good idea to segment application database users from database objects they don’t need to access, we should do that across all our environments. If a developer writes code that accesses a table her application does not have access to, she will find out immediately in Dev when it fails.”
Even better, the developer will discover the issue without even engaging the security or database teams.
3. Use risk-based, situational strategies
In an increasingly hybrid IT universe, IT leaders are tasked with managing and securing a wider range of environments. Strong security shops recognize that a single uniform security strategy isn’t going to work; that’s almost certain to keep your team in the firefighting business.
“[Strong security] organizations use a risk-based approach that includes situational awareness and awareness of the emerging threats to security,” says Hawk of xMatters. “This empowers them to be proactive rather than reactive so that they can predict and avoid major incidents instead of simply responding and sinking countless hours and dollars into them.”