Mature agile practices lead to better team work. Product managers, designers, developers and testers all plan and execute work packets or product backlog items (PBIs) as part of a squad.
Completion of the PBIs continuously improves a product or products. I’ve often wondered throughout my career why the cyber experts aren’t always part of this.
The product feature set benefits from iterative change and customer feedback but so often this doesn’t extend to operational risks like cyber. Instead, once planning, design and sometimes even development are done, it is passed to the cyber team to detail all they find wrong with it.
The result is a go-live meeting where a senior manager is often asked to accept risk. They are told there isn’t time to address them. Given the orchestration required to co-ordinate a go-live event, the decision is typically a forgone conclusion.
A squad is cross functional and should include cyber. Cyber should be there from the planning phase and they should be creating work packets on the product backlog.
To be effective, all practices for managing operational risk need to be well understood. Cyber is no different.
Cyber should be included in the “definition of done” and should be supporting the product manager to complete iterative improvements in the operational risk profile. This should escalate through so that the organisational risk profile is iterated in step with delivery. Ultimately line three risk should have a view of current risk that is traceable to real data. It should be easy but there are some challenges.
Cybersecurity is like the stitching in your trousers. When you get dressed you note the colour of your outfit but not what stitches it together. Looking good is important but ignoring the stitching may find your rear end hanging in the breeze.
Stitching, like cyber, needs to be part of the delivery process. The belief that a security control can be easily bolted on after the fact is a common misconception. It is often used to justify deferring the implementation of a control to when it “really matters”.
Unfortunately, the risk of downtime and the cost of complex integration means a control may not be viable if it is put off. The cyber expert champions the implementation of controls at planning; supports delivery and testing; and works with line two risk (depending on the model) to ensure their absence is appropriately managed.
I once heard a presenter state that, “You risk people need to adapt your practices to deal with security."
I considered the statement for some time before arriving at an opposing view. Cyber security professionals need to learn the language of operational risk. It is a common language used across the industry. Changing that language to suit one team does not make good business sense but supporting the cyber team to speak the language of the business does. Cyber is just another cause of operational risk and that is how it needs to be managed. There are, of course, pitfalls.
Pitfall number one is that cyber risks are often focused on a technical vulnerability rather than a business impact. This typically results in all cyber risks ranking the same.
Read more: The top 10 security essentials for the networked enterprise
The likelihood of most technical vulnerabilities being exploited is very low but the worst-case scenario has a very high impact. It becomes difficult to prioritise cyber issues when their risk profile is always the same.
This is easily addressed by managing cyber vulnerabilities as product vulnerabilities – escalating the risk only for outliers. The business risk becomes the aggregate of product vulnerabilities and the rate at which they are addressed. Agile tools such as Jira enable this by allowing the business to easily report on run rate. Is the product becoming more or less secure? Is it introducing operational risk or reducing it?
Pitfall number two is populating the enterprise register directly with technical issues.
The audience for the enterprise register typically isn’t furnished with adequate time to research technical detail.
Risk frameworks don’t allow the comparison of detailed operational risk and (for example) financial risk. The purpose of risk is to inform decisions. If risk statements create confusion, the risk management practice becomes counterproductive.
Fortunately, this again simply requires the technical detail to remain with the squad.
Instead of cyber issues leading to enterprise register entries, they should inform updates to standing cyber risks.
The standing cyber risks should provide a holistic view of the operational risks resulting from cyber issues.
An example of three standing risks could be describing the potential to compromise information integrity, confidentiality or availability. Each can focus on the business impact of information being compromised rather than the specific method that may lead to it. Specific product vulnerabilities and the rate at which they are addressed then inform updates to the standing cyber risks on the enterprise register.
Pitfall number three is only discussing the risks individually. Certainly, vulnerabilities may need to be resolved individually but the risk profile comes from the sum of vulnerabilities, not each individual item.
Take the example of a product that has 50 vulnerabilities introduced in a week. Assessing the operational risk associated with each vulnerability individually is not only time consuming, it waters down the business issue.
The issue is that there are 50 vulnerabilities being introduced per week. The business needs to take action if the number of vulnerabilities being addressed is significant lower than those being treated. Reporting on the total number of issues and the rate at which they are being treated should inform stakeholders rather than confusing them.
Using aggregates to report operational risk creates useful business information but doesn’t help the squad to manage individual items. This is where line one or two risk can help.
Hosting risk bowtie sessions with the squad can help to determine if remediating a vulnerability or delivering a new control provides the most benefit. Risk not only adds value by reporting on enterprise risk, they can share their expertise with squads. This helps the squads prioritising the PBIs that address operational risk like cyber. If cyber is part of the squad, this exercise also serves to educate line two risk about cyber.
To be effective, all practices for managing operational risk need to be well understood. Cyber is no different. Creating awareness at all levels of the organisation is critical and it needs to be tailored to that level.
The days of posters on the back of toilet doors are long gone, you need to grab people’s attention and focus. I once called a chief financial officer ‘a whale’ in a risk meeting. That got their attention. A colleague suggested we “defuse a bomb” as part of incident response training. That drove engagement between teams. Having developers compete with security testers to see who can beat the other makes their job more interesting and gets more value for the company dollar. Subject awareness is critical to managing operational risks like cyber and thinking outside the box makes it a joy rather than a burden.
I wish I had a flux capacitor like Marty McFly. I wish I could tell you which cyber threat was going to strike next. I wish when I was right it that was acceptable to do the “I told you so” dance. But we can’t have everything we want.
Cyber risk is just operational risk. It is an educated guess of what might happen. Its job is to inform business decisions.
It needs to be captured in business terms and be communicated in familiar language. It should engage and not isolate its audience and the message needs to be traceable from line one through to line three risk.
Managing this in a constantly changing world needs strong relationships to succeed. I am pleased to say that the chief financial officer and I are still on good terms.
Simon Burson ( taz@mania.net.nz ) is national manager cybersecurity at IAG. The views in this article do not reflect the official position of his employer.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.