No one wants to see their Robotic Process Automation project fail. Check out when and where RPA can go wrong – and learn from common mistakes.
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
4. Skip one-size-fits-all user education and training
Raise your hand if you’ve ever sat through a mind-numbing corporate security training video or webinar.
These education programs are completely necessary given that human error remains the ultimate security vulnerability. They’re also often ineffective snoozefests because they’re rarely designed with a particular audience or user group in mind. The folks in finance get the same training as the folks on the warehouse floor. That’s a mistake, according to Destiny Bertucci, head geek at SolarWinds.
“IT pros need to address security based on the department’s level of understanding as well as their usage of technology,” she says. “This is vital to a successful security policy and team.”
In a similar category, Bertucci says strong security shops tend to treat user acceptance (or acceptable use) policies as fluid, living documents that get updated periodically to reflect evolving security, privacy, and compliance landscapes.
Finally, Bertucci sees security-minded IT teams running internal communications programs as a piece of an ongoing awareness and education strategy, not unlike how sales and marketing teams run lead generation and nurturing campaigns.
5. Develop and track useful metrics
Strategic IT leaders already know that getting real buy-in and collaboration on new initiatives from throughout the business is a huge success factor. They also know that doing so often requires being able to show how a particular project or technology drives a particular business goal; bonus points if you can quantify the impacts in a manner that non-technical people can understand, or that the CEO can digest in a PowerPoint slide.
Security shouldn’t be any different: Valani of Security Compass notes that DevSecOps shops are increasingly developing and tracking metrics that can both measure the team’s progress and speak to the importance of a strong security culture to the business as a whole.
“We need to develop the right metrics,” Valani says. “I’m not talking about project-based metrics – deployment frequency, security issues found in production, et cetera – but more fundamental business KPIs like how DevSecOps is supporting key priorities for the business around quality, resiliency, and so on.”
6. Use guardrails, not blockers
In our recent post on getting your team to buy in to DevSecOps, Threat Stack CSO Sam Bisbee noted that security professionals must come to terms with something of a reputation problem: “You must realize that most non-security professionals have either had no experience or generally negative experiences with security teams. You will have to start building the bridges yourself.”
Indeed, security pros have often been tasked with saying “no” – which brings us back to that conflict borne out of treating security as a step in a process. Strategic IT shops are getting rid of bottlenecks and silos, not incorporating them anew into their daily operations. Strong security teams recognize that a “just say no” approach isn’t going to fly.
“Security has to provide guardrails instead of blockers to the systems development lifecycle and the CI/CD pipeline,” says Gerchow, the Sumo Logic CSO. “It is a must, in order to maintain speed, agility, and innovation while simultaneously meeting regulations and staying alert for malicious cyber threats.”
The guardrail mentality underpins all of the above traits of robust security organizations; you don’t shift left to slow down developer velocity, for example, but to bake security into that increasing velocity as a means of supporting its long-term sustainability and success.
How you define and implement "guardrails instead of blockers" is ultimately your call; for Gerchow, it’s all about embracing DevSecOps.
“Ultimately, the challenge is to deal with imminent cloud-based attacks without losing visibility into processes to assure users that their information is adequately secured,” Gerchow says. “This is easiest, and most scalable, under the mantra of DevSecOps. Do it from day one, and you won’t regret it on day 1,000.”
7. Don’t expect everybody to be a security expert
One of the promises of DevSecOps is that “security is everybody’s responsibility.” This may sound like paradise to security professionals, but for almost everybody else on the team, it’s a daunting prospect. You can’t expect everybody to learn all the aspects of security that may occur throughout the DevOps cycle – even if they are security pros.
Instead, think about how to derive and define security policies from your governance model, and then choose security experts with the relevant expertise to take responsibility for baking those policies into the various processes in the project or product lifecycle.
“It’s all about automation,” says Mike Bursell, chief security architect at Red Hat. “The developer, the tester, the designer, the operations person – [all] need to be able to have responsibility for following security-relevant processes, not defining them. Once you have the processes in place, you can manage by exception: Instead of trying to check that people do the right thing all of the time, spot when they do the wrong thing and sort it out from there.”
The process shouldn’t finish at the deployment stage. “During your operations phase, and even once the application has been closed down, you should be collecting monitoring behavior,” says Bursell. “And you can use that data alongside the development and test data to create information that you can provide for your auditors – and feed it all back into the next phase of design. There’s valuable data at every stage in the process.” (See Bursell's related article: Talking to normal people about security. )
Want more wisdom like this, IT leaders? Sign up for our weekly email newsletter.