“Security needs to be everyone’s job.”
You’ve likely heard or read something like this in community discussions, conference talks, or articles focused on awareness programs and developing a security culture. When anyone outside of a security team is involved in a security failure, it frequently leads to finger-pointing and animosity across teams, with security professionals saying things such as, “Users are the weakest link.” You’ve probably heard that one before as well.
One fundamental problem with sentiments such as this is that people who weren’t hired to be a part of the security team have their own jobs to do and were hired to provide value to the organization in their own ways. Those jobs have expectations, performance measures, bonus incentives, goals, projects, and day-to-day responsibilities, all of which likely have little to do with information security, if anything at all.
But these are all things that the security culture is rarely empathetic to, especially during a breach. Security needs to be everyone’s job for the system to work, so we can’t afford weak links in the chain, right?
But as more companies move to embrace the DevOps mindset, culture, and toolchains, empathizing with these differing responsibilities is not only a nice-to-have; it’s essential. When DevOps first burst onto the scene, it broke down the barriers between development and operations teams to increase skill and knowledge-sharing, improve tooling, and ultimately produce better systems.
There was a certain willingness to make this change on both sides, and it required that development really understand operations at the same time that operations strived to understand the development process. With security making its entrance into this shift via DevSecOps, we need to embrace the same mindset and at the same time give off those same vibes.
Here's how design thinking can deliver the goods, and five tips to get you started.
Design your thinking
Design thinking is a structured process that refers to the user-centric techniques you can use to develop creative solutions to challenging problems. In the world of DevSecOps culture building, users could be developers, SREs, IT staff, or anybody else working to build systems or, even better, produce customer value within an organization. So that’s great, but here's one more buzzword to top off the pile of acronyms that permeate the industry: what does design thinking actually mean?
Empathy is the first step in the design-thinking process. In this context it is directed at the problems users may be facing, the issues that security processes introduce, contentious interactions with past security personnel, or anything in between. The DevSecOps manifesto, as published by the DevSecOps community site, encourages security professionals to think like developers, codify their tooling, and integrate tooling wherever possible the way that developers do: Programmatically.
This has encouraged a wave of vendors to develop security tools and complementary marketing campaigns that suggest how DevSecOps should be done, what a toolchain needs to look like, what processes need to be in place. This movement is setting us back as an industry when it comes to working alongside our development and operations peers.
Isn’t more automation and tooling a good thing?
Automation isn’t the issue, and neither is having more tooling options. The issue lies in security teams dominating the narrative around how software should be built how development processes need to work, and forcing the adoption of tools that shape process and workflow instead of the reverse being true.
The entire point of DevSecOps is that barriers go down and collaboration goes up. To this end, trust and communication need to be established inwardly and outwardly. Without a firm understanding of where security causes friction, what problems development teams struggle with, and ultimately what people need, any solution is destined to struggle — or fail.
Here is where that first step of the design-thinking process, empathy, comes in.
Before looking to plug new tools into your development team’s toolchain and start changing the team’s workflow, sit down with the team to understand what’s happening. The following five tips can be helpful in this empathy-exploration process.
- Ask why things are the way they are, why certain tooling is in place, why certain requirements exist, and why a process is one way versus another. Even if you believe that you know the answers, seeking to understand the deeper context may reveal useful insights that can be useful later when designing solutions.
- Make sure that all attendees get to voice their feelings and opinions. By ensuring that no single person can dominate a discussion, you’ll both show that you care about each person in the room and uncover different aspects of the problem you’re trying to solve.
- Don’t cut people off or suggest answers to questions that others are trying to answer; such actions not only discourage openness but also reinforce what you already know.
- Lean toward open-ended questions. And when you get people talking, probe for additional details.
- Take good notes during your discussions so that you can take them back to your team and analyze them for inconsistencies or other useful information later.
By going through the process of learning through empathy alongside your development and operations teams, you'll demonstrate that security is on a level playing field. It highlights that security is willing to figure out what will work best for the organization’s context, team goals, technology stack, and existing environment. This willingness can break down barriers, which is necessary for a DevSecOps shift to succeed.
Make shift happen
The tools and techniques released at conferences may work perfectly, they may need to be adapted, or they may not work at all for your organization. The goal of any applied design thinking process is to remain focused on what users need, what will benefit them, and what will best solve their problems.
Understanding that problem, and the context from all possible perspectives, is one of your most important steps. It will help you and your security team figure out what solutions will work best. And it will help you to break down walls between teams while building up the culture necessary for a successful DevSecOps shift.
I'll be speaking in depth about design thinking at DevSecCon Tel Aviv. Are you kicking off your next project or planning session? Let me know how it goes by posting your comments below, or reach out to me @HolyCyberBatman on Twitter.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
