One of cybersecurity leadership’s most important jobs is effective communication, but the security industry has a funny history around the way it communicates priorities, desires, and intentions. We tend to “tell and demand” instead of ask, and we also tend to use FUD (fear, uncertainty, and doubt) instead of data. A lot of people outside of the field that I’ve spoken to about this type of communication have referred to it broadly as “just because” reasoning. “Just because” reasoning doesn’t build trust.
Effective communication can create the conditions necessary for an organization to truly change. It can help to create an experimental, exploratory mindset, as well as sway prioritization decisions at both tactical and strategic levels.
This article will go into some specific ideas on how a security leader can effectively communicate the importance of a DevSecOps strategy shift inside, and then outside, their team.
Communicating Within the Security Team
The move to invest heavily in automation and to change the way that security engagement happens can be disruptive to an organization’s status quo. There are many unknowns such as new tools; whether existing tools and processes might need to go away; and so on. Fear of disruptive change and automation is present in many facets of technology, but that doesn’t mean we should avoid it.
In my leadership capacity, I have found the ambidextrous organization model quite helpful to explain and drive toward change. The basic idea is that you acknowledge the many things you do today that deliver value and name them. These activities are referred to as “extract” activities. We know that we can’t do the same thing we do today in five years and that something must change, but we might not know what that is yet. So, to find out what will work in our context, we allocate resources to “explore” new ways of working and new ways of adding and capturing value. An explore activity might move over to an extract activity as it matures and confidence in it builds, at which point the cycle continues to loop. Employed thus, the ambidextrous model minimizes the typical concerns that come with change.
The big thing for me is: Don’t leave people behind. Bring your existing team along in this change so that they learn new skills at the same time as these forward-leaning DevSecOps patterns are contextualized with all their rich background and context.
Communicating Beyond the Security Team
External teams are in some ways easier to communicate with along these lines. Engineering and product teams may be the ones pushing security to come along due to their existing preferences for building and managing software. However, other teams, such as legal and sales, may be more hesitant to get behind a significant change in operating practices. To them, this may represent unnecessary risk or distractions. While these are just examples, any external stakeholder could fall into a place of not being aligned with or supportive of this strategic shift.
To achieve alignment, focus on truly understanding the value proposition that this shift will provide and when you understand it, how you want to articulate that. This is best done in contrast to your understanding of the pain points that a particular stakeholder may experience. For example, engineering teams may face friction in their build and development process that they wish to alleviate. Legal teams may be concerned with the risk of moving too quickly without “proper security checks on each change.” Sales teams might be frustrated currently with their inability to address certain customers’ inquiries about security posture.
Whatever the pain point(s) may be, you need to understand them, empathize with them, and talk about the value proposition in contrast to that pain point. I have also found that taking an explicit step in inviting specific stakeholders into the process to provide feedback, be an advisor, or play some other part in ownership of the strategic shift can do wonders in the journey toward alignment.
Concluding Thoughts
In my experience, one of the biggest transformations that occurs within a security team here is around culture. Not tools, not process, but culture. Acting things out, modeling “the way,” and truly leaning into an agile development-oriented mindset are fantastic methods to help organic culture change take root. As that happens, less convincing is necessary and, in some ways, the hard parts take care of themselves. Communication then becomes a function of strategic direction setting and shaping as opposed to disrupting.
Want more cybersecurity insights? Visit the Cybersecurity channel:
