No more Department of No

As organisations come to terms with the impact of digital transformation, there have been louder calls for security teams to stop being the Department of No. In general terms, this is a positive trend but there is a danger for security teams as the ‘shift left’  of digital transformation exposes more and more that security teams haven’t been living the much-espoused business enablement or business partnership calls that we’ve heard so often in the past. 

Security teams need to take this as a wake-up call for to rethink what actual value they are delivering and how a change in their approach could increase the value they provide.

I believe that security teams are protecting existing business value as well as protecting the creation of future business value by the rest of the business, building Protect/Comply AND Grow into the core of the security strategy is key.

As security teams are trying to use pro-active measures such as threat intelligence and threat hunting to shift security risk management ‘left of boom’ there are many complementary opportunities with technology teams that are trying to shift left the delivery of projects and ultimately business value.

Organisations undergoing digital transformation must consider the cultural change required in back-office functions such as security or compliance if they are going to support the organisation in achieving its goals rather than restrict it. The apocryphal four horsemen of digital transformation failure are; lack of existing capability, legacy technology, procurement, and security. It’s easy to blame security for lack of digital success.

Security teams can often exhibit Department of No behaviour, acting as blockers on rapid change when they are operating under uncertainty. Department of No behaviour includes: refusing to engage in a timely fashion; refusing to provide risk commentary unless the digital team acquires indemnification from risk owners; preventing or delaying change requests and establishing strict bureaucracy around policies, standards and processes that do not accommodate digital methods of working.  When digital transformations do not include security teams on the journey, those teams are much more likely to revert to more extreme Department of No behaviours as they lose all trust in the digital groups.

Whether a security team has become a Dept of No or not. Security teams are often accused of this even if their only real crime is not adapting to new approaches as fast as the technology teams.  It’s hard to change perceptions after an accusation of saying no even if you never actually said it.

Here are some improvements that security teams in traditional organisations need to drive for themselves if they have any hope of escaping the label the Department of No in a digital transformation.

Risk Ownership
The ‘shift left’ movement behind digital delivery for many firms requires a change to the ownership of security risk management. No longer should security teams manage the risk for business functions that won’t handle it for themselves. If we want to enable faster and more agile delivery closer to the customer, we need those staff that are delivering services and products to own and manage the risk themselves. There has always been a temptation to do security risk management for functions that we found it difficult to get traction with, and this often resulted in the security teams ‘owning’ business risks. These risks have then been managed out of security resources and budgets, leading to contention and back to Dept. of No.

It is now necessary for security leaders to re-engineer the culture and governance of risk within the businesses they serve; this is one of the most critical tasks facing a security leader and underpins the success of a secure digital transformation. Shifting left requires greater trust in business delivery teams to step up and manage security risks themselves for the organisation as a whole. Greater faith demands greater responsibility and greater accountability from these teams in return.

Self-Service
Not only should security teams move the ownership back to the business functions but they should also provide those functions with self-service capabilities to identify, manage and accept risks and automatically and efficiently provide visibility of those decisions to all stakeholders affected. These self-service capabilities should enable product or service focused delivery teams to deliver against the responsibility and accountability required of them in the new digital world, removing security bottlenecks that hold back delivery.

To provide these benefits, self-service capabilities need to be non-specialist in presentation and as close to frictionless as possible. For example, proving dynamic questionnaires that only ask necessary questions to assess the specific risks of the activity driven from context rather than huge static spreadsheets of liability transferring questions.

Make it simple, make it online, make it single sign-on, make it remember sessions, make it prepopulate things the security team (or it’s tools) already know, make it easy to complete and easy to ask for help.

An added benefit of business function-focused self-service tools and processes is that a large proportion of the work currently conducted by security teams is then triaged out in favour of high-value projects and systems that need real attention. Doing this means delivering more with fewer security resources, increasing the efficiency and value of the security function as a whole.

Distributed Security Teams
Little security empires guarding staff headcount and budgets, often due to the scarcity of both, doesn’t work anymore. We will never be able to hire enough skilled security engineers and architects to support all projects or sprints centrally, and we are unlikely to get the budget to do so even if we could find them.  

Embedding security resources in delivery teams rather than keeping them centralised allows them to give the right advice at the right time. We should also be developing development and engineering resources to learn security skills and supporting them through communities of interest. Security leaders and CISOs should release direct control of security people to the product and service delivery teams, to support local pockets of capability and invest in training content,  domain-specific tools, extensive instrumentation and collaboration capabilities to give those local resources what they need to deliver security. There’s a lot to be learnt from McChrystals Team of Teams for the future of distributed security teams.

Clearly, while security teams need to trust the delivery teams to do the right thing, that doesn’t mean security shouldn’t verify! The extensive instrumentation and centrally-provided tooling should give security teams visibility into the effectiveness of these distributed security people and teams and the value of red teaming from the centre shouldn’t be underestimated.

Process Maturity & Automation
One of the challenges that security teams face is finding the time to really engage the business and learn what drives them, what the broader goals are and how to support the rather than limit them in an attempt to assert control through Department of No behaviours.

Many security teams are time-bound and resource-bound. Much of what traditional security teams do involves moving data from technical security control interfaces to spreadsheets and presentations and then trading these documents or their outputs with other security or technology people. Every time we add a control we increase the manual drudgery of context switching between interfaces to input configuration changes or extract data reports on performance or configuration.

These processes meet the needs of regulators, auditors and executives but don’t increase security beyond providing some minimal assurance that the risk profile has not gotten worse. Even when we get to processes that impact on security risk management such as SOC playbooks we often find these are mostly manual processes, open to errors with little opportunity to gain visibility whether they are useful or not.

It is this latter example which provides security teams with a view on how to improve. The development of SOAR (Security Orchestration, Automation and Response) tools is an example of taking complex manual workflows and processes and seeking to automate the drudge work and the context shifting providing the skilled security team with enriched data to make decisions and act on them. As with so many things security operations is the pressure point that forces innovation.

The same approach taken for security operations automation in SOAR applies to all security processes from risk assessments to metrics collection to configuration auditing and third-party assurance. Using workflow automation tools used elsewhere in the business, API integration and where necessary (here be dragons) robotic process automation we can reduce drudge work, reduce manual data extraction and munging, increase visibility and increase the capacity of skilled security teams to make decisions that affect the security risk profile. These will also provide the time for reflection and engagement that build trust with the delivery teams and help extinguish Department of No responses.

Learning Culture
One of the common threads of digital culture is agile delivery. This can be a bugbear for security teams as they see the increased delivery velocity and experimentation as real sources of uncertainty and potential failure. Failure in security is wrapped up in the desire of many security teams to eliminate all possible security risks which when uncertainty is discovered can lead to a knee-jerk classic Department of No response.

There are many definitions of what this means but the agile manifesto is as good a place as any to start. From the manifesto the value as follows reflects an important part of how security should be operating:

“Responding to change over following a plan”

Putting some more context here the following from the twelve principles behind the manifesto the following is instructive:

“At regular intervals, the team reflects on how to become more effective, then tune and adjusts its behavior accordingly.”

There is a lot of wisdom baked into these statements. Security teams build programmes to address the security risk environment they operate within These environments are constantly changing both internally and externally. Security teams’ knowledge about the threats they face improve over time and every event or breach should be generating knowledge about how to avoid that risk in the future.

Ironically, continuous improvement of security is often a central theme of security maturity models adopted by security teams to define their security programmes. Unfortunately, security teams often declare continuous improvement as a high level of maturity and delivery is postponed to the end of any improvement programme, sometimes with the hope that no-one will check if it is active or not.
 
The problem is that security teams and delivery teams both resist continuous improvement. Underpinning continuous improvement is a learning culture where feedback from operational events is considered and improvements implemented.  A learning culture requires radical transparency of failures and a no-blame culture.

Security teams worry that failures of process and security breaches are seen as their fault so often resist calls for transparency. Delivery teams oppose the same calls for transparency as they don’t want to lose control of their delivery agenda because of executive panic over exposed risks.

The most basic security maturity improvements are undercut over time by a failure to learn from operational events as control configurations and process definitions diverge from the changing requirements of the operational environment. The reason that occasional acts of transparency derail executive peace of mind is that their expectations and reality have diverged so much. More regular feedback within processes with verifiable and auditable improvements makes such divergence much less likely.

A learning culture is key in operational security risk management both because of the changing threats we face and the changing environments we operate, and without it, we are dooming ourselves to predictable and regular notable failures.

Summary
The first step in not being the Department of No is a shared desire across the security team to truly engage business colleagues and help them manage security risks.  If you then move risk ownership back to the business leadership; give delivery teams and risk owners the ability to self-serve; distribute security people from the centre to the delivery teams; automate processes and workflows and build a focused learning culture; then you will have the opportunity to turn the expectations of the Department of No on its head. You will then have the chance to deliver real security impact in new digital organisations.