Much has been said recently about boards becoming more aware of their organisation’s cyber risks, and what is being done to mitigate them. APRA’s CPS 234 Information Security regulation, which became enforceable on July 1st 2019, goes as far as to place responsibility for the oversight of an organisation’s information security directly in the hands of the board:

“The Board of an APRA-regulated entity is ultimately responsible for ensuring that the entity maintains its information security.”

There is no question that boards, and executives outside of IT, are demanding accurate and relevant facts on their organisation’s information security and cyber-related risks. Cyber risk management strategies and issues must be reported to boards without obfuscation or the far-too-common “papering over the cracks.” Too many times I have seen the most important information, both good and bad, hidden in a swathe of unnecessarily technical gobbledygook.

Unfortunately, the hiding, intentional or otherwise, of important information in swathes of unnecessary information is not just limited to cyber risk. Directors are frequently overwhelmed with the amount of information provided to them in board papers, in some examples several hundreds of pages.

After many years working in various aspects of cyber risk, there is one consistent issue that I have rarely seen adequately resolved: Lack of effective communication of cyber risk issues and mitigation strategies from the IT security management “coalface” to senior management and the board.

One reason that many of my peers and I find this so frustrating is because it doesn’t help anyone. IT teams are better served when both executive leadership and the board understand the magnitude, and potentially devastating impact, of the cyber risks their organisation faces. Visibility into control capability gaps and the remediation strategies for cyber risks helps drive the prioritisation of the IT security budget.

Leaders demand to know more about their cyber risks, APRA has regulated board responsibility, and this is maybe a sign of things to come for unregulated organisations also. Under CPS 234, responsibility for ensuring that unregulated 3rd party service providers are prepared for cyber incidents lies with the regulated entity. The CPS 234 “tendrils” extending outside of regulated entities.

In their CPS 234 Practice Guide (CPG 234), APRA have helpfully provided some “examples of information that could be provided to the Board and management as part of their oversight of information security…” I have analysed the value of these examples with colleagues in cyber risk and information security as well as board directors, each with their own unique perspective of what is interesting, important, and obligatory information for management and boards to be familiar with. We believe that with some adjustments and a data collection, analysis and reporting framework, the APRA examples can provide a solid basis for concise and effective management and board cyber risk reports.

Taken at face value, the categories are straightforward: “Capabilities; Incidents; Controls and Education.” Once broken down to the source documents that are required as input to these categories, there could be a requirement to review and report on at least 40 different sets of information for a single entity. Also, as part of good governance, this information needs to be assessed as to currency and quality. Executives and boards need to know that they are reading from the most current and accurate playbook. It is easy to see how the board reports can become so large and unwieldy.

There are areas of cyber risk management that are missing from the APRA examples and should be built into the reporting framework. One example is regulatory compliance outside of APRA, which is especially important for organisations that do business in other jurisdictions with concerning privacy regulations like the EU, and more recently, California. Another example is insurance. Whilst CPS 234 is strong on incident response planning and testing, nothing is mentioned regarding the role of cyber insurance in incident response and financial resilience. Directors and officers of companies should also be aware of their potential liabilities from cyber incidents and how insurance may respond in various scenarios.

With a process of distillation and information gathering governance, it is possible to refine and expand on the examples given by APRA to provide succinct cyber and information security risk reports for management and the board when required. A customised and accessible cyber risk board reporting framework. When built on APRA’s own examples, the reporting framework is designed to withstand regulator scrutiny. An effective framework will lead to better communication of cyber risk and mitigation strategies and streamlining of the report process. This leads to better understanding of an organisation’s past, current and planned cyber risk management issues and strategies.

It is not possible to guarantee that an organisation is immune from a damaging cyber incident. Effective dissemination of information around cyber risk management brings any resilience issues to light for management and the board. Increased understanding of cyber risk management will also improve the organisation’s cyber risk culture and assist in reducing the scale of post-incident impacts, for example damage to brand and reputation.

For years now It has been hard to find an article on cyber risk that doesn’t say somewhere that IT security and resiliency are “…a business risk, not just an IT problem.” By this rationale all business leaders should have access to, and the opportunity to question, effective cyber risk management reports.

Please contact us if you would like to discuss cyber risk board reporting.

Have you heard this before:

“Our data is all stored in the cloud so it’s totally secure” or “we have guaranteed 99.9999% uptime as we use the cloud?” I have heard this from IT teams, executives and board members alike. These misconceptions can lull entire leadership teams into a false sense of security, thereby reducing the amount of effort on building and testing incident response plans and leaving organisations exposed to massive risks.

Before I launch into the risks and how to check exposure, just a few comments on using large cloud service providers. They spend heavily on:

• Top-of-range servers and storage
• Highly resilient data centres
• Fast and resilient networks
• Dedicated, highly qualified and experienced cybersecurity personnel
• Many other security and resiliency risk mitigation techniques

One of the largest cloud service providers suffered an incident on 23 October 2019 with some of their customers experiencing up to 12 hours of service interruption. Also, an Australian bank that has all the above technology themselves experienced a system outage down on Thursday 17th of October 2019 causing so many repercussions that they took responsibility and have already provided some financial compensation to those affected. They took responsibility but some have assumed that the root cause of the problem was a patch from their 3rd party software vendor.

This is just in the last three weeks. Countless organisations and individuals all over the world were affected by these issues caused through their service providers’ dependence on 3rd parties for delivery of technology services:

• In the example of cloud companies, they are the 3rd party platform provider – aggregators of service
• For the bank they are a 3rd party provider and aggregator of financial services

So, the rabbit hole goes very deep in terms of cause, impact and responsibility. For these few incidents alone, I read a story about an individual who was denied critical surgery overseas due to an inability to access funds. I also heard of a company that missed out on a tender due to a lack of access to critical software. What about the problems these incidents also caused for millions of people who had no part in the cause of the outages?

The larger and more regulated an entity is, the more likely that they will have one or more teams that look specifically after 3rd party service providers. They investigate important details like service level agreements (SLAs), contract small print, termination of contracts and limitations of liability. They can do this because they have lawyers who understand contracts and service delivery managers who understand SLAs etc.

But what about everybody else who wants the shiny cloud computing, and ultra-fast internet, and 6-nines of uptime billed by the nanosecond of utilization, with no lock-in clauses, right now? Unfortunately, a lot of people just click the ‘Accept” box.

Briefly on the large, regulated entities. They, like all organisations, can also be susceptible to 3rd party service provider risks from “shadow IT,” Sounds scary because it is. This is where despite (and maybe because of) the best intentions of procurement policies around the adoption of new systems, sometimes people can’t wait for the correct approvals from IT and procurement. With cloud-based software and infrastructure access only a credit card number away, there are many examples of organisations using systems for operations that the IT department, let alone procurement and legal, didn’t know they had.

I remember individuals plugging in access points all over the place when WiFi came about because their IT departments hadn’t decided the technology was safe for the organisation to adopt. One of the first WiFi security standards, WEP, was quickly and relatively easily compromised.

Now back to the subject. “…it’s not our fault!” Yes, it is, and most likely you will be held accountable. Without a diagram let’s see if this explains some of the responsibility chain: Let’s say your organisation is XYZ that holds several thousand customer records which can be considered sensitive. XYZ was an early adopter of cloud services and uses Cloudy Cloud (not a real company unsurprisingly) for compute and data storage, with no problems so far. Cloudy Cloud has built a perception that they are unbreakable/unhackable.

Cloudy Cloud has a data breach and XYZ’s customers’ personal records are available for sale on the “dark web” to the highest bidder. In October I posted a piece on what XYZ should do should there be in incident, but here is a high-level breakdown of responsibilities:

• The customers affected by the data breach are under contract with XYZ
• XYZ is contracted to Cloudy Cloud for data storage services
• There is no contractual relationship between Cloudy Cloud and XYZ’s customers and they may not be aware of where their data is physically stored
• XYZ most likely has an obligation under the Federal Privacy Act to notify the individuals affected and the Privacy Commissioner

While the breach might be Cloudy Cloud’s fault, the impacted individuals have no direct recourse to Cloudy Cloud, only to XYZ, whose rights in relation to Cloudy Cloud fall under the terms of their service agreement. In most cases there are limitations of liability in these agreements which may not cover any flow-on costs to XYXZ.

In many cases we have seen that the fault for data breaches of cloud customers has been due to incorrect or insufficient implementations of the cloud providers’ security management frameworks. There is a shared responsibility security model between the customer and the cloud provider.

Therefore, ultimate responsibility for managing the incident and any impacts to their customers lies with XYZ. In reality the circumstances are far more complex, however it is a good strategy to assume that your organisation, as a provider of services to your customers, is responsible for any incident that impacts them.

In any case 3rd party IT service providers are a part of most organisations’ IT capabilities, and adoption continues to increase rapidly. Here are a few simple recommendations on 3rd party cyber risk management:

• Build a 3rd party service provider register that includes specific sections on incident handling and liability
• Review the contracts with your legal team in the context of a major incident
• Build out risk scenarios, and formulate an incident response plan that includes the third-party service provider response capabilities, and involve them in planning and exercises
• Test one or more of the scenarios with risk simulations, these will highlight gaps before an incident happens

Should you have any questions or would like some assistance with the above recommendations, please get in touch.