As I start a new job in a few days, I’m revisiting a classic in management and leadership transition that I’d recommend all my readers to get as well. “The first 90 days” by Richard Watkins.

Something that in my consulting experience I’ve came across quite often and helped clients navigate through is governance and structure misalignments not only within Infosec teams, but also relating to the Infosec function itself to the wider organisation we’re supporting.

I referenced the book as there’s a chapter in it that is quite informative and a good model to have a discussion about what these misalignments tend to be, particularly when trying to change the paradigms of the security function from the “old school” command and control type approaches to a more modern way to integrate security into the workings of the organisation itself.

Infosec functions, even when wanting to modernise and integrate attainment of security objectives as an integral part of achieving operational objectives, often dismiss or disregard part or all of the 4 different pillars of organisational architecture which tends to manifest itself in not achieving all of the benefits they wanted to pursue to begin with. For those who haven’t even started, this is a good model to start planning for it. So the 4 pillars we’ll discuss are:
  • Core processes
  • Strategic direction
  • Structure
  • Skill bases

If you have these types of misalignments, it’s good to have an approach to help highlight what those misalignments are, and I’ll share my thoughts on the subject in this blog post.

Here are a few flavours of these misaligments and how they may manifest themselves:

Misalignments between strategic direction and skill bases

Often a (generally newly appointed) leader comes to appreciate that what and how they’ve been “doing security” isn’t appropriate anymore. That the way they may have approached in the past no longer aligns with the business value creation structures and that security is being perceived as an impediment to the creation of value. This realisation often leads to a change in strategy, usually one where the security team plans to make the strategic shift from being “requirement setters” to being “capability providers” and all else that goes with it. But more often than not, the current team isn’t really equipped (often not even willing) to start approaching our craft in fundamentally different ways.

If, as a leader, you’re making this shift then you need to consider the new skill bases required to succeed in implementing such a strategy. These typically include the following:

  • Deep understanding of modern software development practices
    • Your team is unlikely to have this skillset. Either providing training in software development, promoting shadowing of development work, or hiring a Developer or QA engineer into the team whose component of the role is to promote continuous training and mentorship on development are all ways you can potentially tackle that
  • Coaching in facilitation skills
    • Historically, security teams have managed with the organisational benefit of role authority. As the pressures of time to market increase, the organisational ability to stop and have handoffs on their processes (security or otherwise) become less palatable to the organisation and may lead to the emergence of covert work systems, where security stops being a consideration altogether. Sending around emails with spreadsheets, or assuming your Development teams even know where your policies are is no longer a valid strategy. Not when our ITIL based processes or the 90s and 00s are, for many, a thing of the past and those “gates” don’t really exist anymore. Teaching our security teams true facilitation skills, how to run a workshop, feel the pulse and energy of the room, not coming with the answers but knowing how to ask good questions and probe for teams to develop their own understanding and coming up with their own answers, are skills sorely missing from most security professionals.
  • Ability to look in a software code repository
    • Not being full developers, but having the ability to login to a code repository and read a CI/CD pipeline definition file, or understanding what a Docker image is doing, and what tests are running helps both build empathy and have a basic level of common language which will yield results in building relationships

Misalignments between strategic direction and core processes

Having all the “right” strategic intent in the world, but then being supported by old fashioned processes, will make it impossible to achieve and deploy such strategy. When embarking in this type of change, you really need to look into the core processes by which “security becomes a thing” in your organisation.

When people in your organisation, not just development but across all areas, what does security “look like” in the context of their roles ?

Some of these core processes from “old school” approaches tend to be in the form of “enterprise review boards”, “security clinics” where Developers may need to wait 2/3 weeks until it happens and they can get feedback on something they want to work on. It may be in the form of Publishing policies in a Sharepoint site that no one knows where they or even that they exist, and written in a language so detached from what they are familiar with that even if they read them, they’d have no chance in connecting to anything they actually do.

Core processes, such as requirements and policies, need to be aligned to the processes which are expected to consume them. This is effectively a call to codify our policies as code, so they can be directly used in the development process, but also to make consumption of security capabilities such as “software code analysis”, vulnerability scanning, secrets scanning as simple as integrating another library, running a docker command, etc. If we make our engineering have to change context to get their security results and visibility, we’ve already lost half the battle before it even started. I will also extend this to include things such as whitelisting false positives, requesting security exceptions etc. The “experience” of security, the “developer experience of security” needs to be the main consideration for our core security processes

Misalignments between structure and processes

If your structure, and the services you provide to the organisation, are misaligned with the core processes, then you’re in trouble too. Having a structure that is largely aligned to produce word documents and spreadsheets and having “modern core security processes” where things are “managed as code”, will imply you’ll have no one that fully understands what’s happening and will likely have a hard time providing any real assurance that security objectives and requirements are being met.

Finding ways to align incentives, communication between stakeholders working to similar timespans and measured on similar timescales (eg separating compliance / risk which tend to work in at least quarterly, usually yearly or multi-year cycles, and security engineering / product security functions which will tend to deliver in sprints or more aligned to the tempo of typical development timescales is what I’m referring to here). You certainly need both types of capabilities, but create the structure and communication networks and governance artefacts themselves so they’re better aligned between these stakeholder groups. My rule of thumb is that when creating governance structures that one needs to SUBORDINATE security to the value creation structure, and not force value creation activities to a tempo dictated by the governance function. You don’t want to be the bottleneck, right ? right ?

Misalignments between structure and skills

Having the best thought out structure in the world, but then not resourcing with the right skill set is again a recipe for disaster. Yes, let’s create a better structure but not forget we need the right skills working on the right artefacts so our strategy can succeed. This tends to be the easier to solve (though everyone complains about the skills gaps). Recruit internally. Get Developers, Platform Engineeers, QA engineers with an interest, the money you’d spend on overpriced agencies and interviewing 20 candidates, use it instead to provide paid training to those engineers that NOT ONLY will have the technical know how, but both have effective social networks already in your organisation AND be very familiar with development processes and incentives in your particular context. Just 2 hours ago, came from having lunch with a Security Executive who did just this after I recommended, and within 2 weeks he had 4 QA engineers super excited to start their Infosec careers, and with a good part of the skill set to make this new type of structure a success, provided they’re now well supported in becoming security experts as well.

As with all of these things, we do need to start with a strategic direction, but doing so separated from core processes, structure and skill bases required to make the strategy a success, you’re certainly be hitting roadblocks in promoting effective change and being successful in the delivery of such strategies.