A deeper dive into APRA’s cybersecurity stocktake: improving supply chain security, control testing programs, and managing incident response

In our initial post on APRA’s cybersecurity stocktake, we provided an overview of the essential findings and some initial areas that all organizations need to consider to improve the security of both their own and their customers’ data.  

In this post, we’ll focus on what we have learned working with customers and as part of our own cybersecurity journey to address APRA’s findings, specifically:

• Third-party information security capability;
• Poorly defined and executed control testing programs; and
• Incident Response processes that are neither reviewed nor tested

Although APRA’s stocktake focused on the financial services sector, we believe the takeaways are relevant to every business that manages information they want to secure and protect.

Securing your supply chain and third parties

No matter how well you secure your infrastructure and the controls that you place on data within your network, the blurring of the boundary of ‘the network’ and the inevitable flow of data and information outside of traditional boundaries to cloud and other external services means that conventional approaches to ‘securing the network perimeter’ can take us only so far.    

Data and information more commonly reside and are managed in cloud services with less reliance on internal infrastructure and systems. As APRA’s report shows, we need to broaden our view on our organization’s' ‘security boundary’ to include these external cloud services and ensure we take a more data or information-centric approach to security. Where is the data stored? Where does it flow? Who has access to it, and in what context?  

Some saw the arrival of Cloud services in all its forms as reducing risk for companies – security became the cloud provider’s problem. While there is undoubtedly an element of truth to this, recent examples, such as the MOVEit breach or last year’s SolarWinds infiltration, show that, ultimately, the consequences of a breach belong to the cloud service’s customers.

The report highlights the issues of a lack of assessment of third parties, including testing and independent verification, aligned with the sensitivity and nature of the information stored by those third parties. Simple steps such as regularly requesting independent verification of security credentials such as SOC 2 Type 2 and independent penetration tests of services you propose to use can all help reduce the risk. Many of our customers also require us to undergo penetration tests conducted by them as well as answering security questionnaires that specifically focus on the sensitivity of the information assets we are storing.  

Apart from holding your supplier to account, it is also critical to recognize that they cannot be held accountable for everything. Some aspects of security will remain your responsibility. Make sure you understand what these are. Usually, your supplier will be able to provide you with a list. In RecordPoint’s case, our customers control who has access to their service in their Azure Active Directory and what content/data they store in the service. Without proper control of these by our customers, then there is the potential for data to be compromised, regardless of what we do as the service provider.

In addition, it is critical that you understand what data you are storing in third-party cloud services and ensure that the third party is not managing data that does not align with your organization's security profile. Many RecordPoint customers use our platform to identify what data they are storing in external, third-party services so that remediation action can be taken when information is stored in the wrong place, e.g., customer data or files in a low-security file share.  

Poorly designed or executed control programs

Unfortunately, many organizations fail to live up to the intentions of their security controls program. While ticking off a compliance audit (whether external or internally audited) is important, the point of the checklist and the audit is not to ‘get through it’ but to use the exercise to really understand your security posture with an emphasis on real risk management rather than just ‘compliance for its own sake.’ Do not set controls based on what you can achieve but on the nature of the information and data you protect.  

A completely clean audit is excellent, but it may just be the starting point.  

Compliance standards such as SOC 2, ISO27001, C-Star, Australia’s Information Security Registered Assessor Program (IRAP) standard, and National Institute of Standards and Technology (NIST) standards are all great tools to help assess your posture. But stepping back and undertaking an assessment that considers these standards in the context of your business's specific risks will yield better outcomes. Do not have sterile debates about controls that don’t realistically add to your posture but equally, don’t ignore critical controls. Focus on what matters to your business and your customers.

Finally, ensure you don’t wait a year or two to run an externally audited assessment. Schedule your internal audits and align the frequency with the risk profile associated with the specific control. For example, privileged access audits are critical to RecordPoint, so we conduct these frequently. Physical office audits are less important as we are a cloud-based company with no internal infrastructure.

Incident response plans that are not fit for purpose

The APRA report highlighted the surprising number of organizations that have no security incident response plans in place, or if they do, they are not tested or fit for purpose.  

The primary problem we have seen is that IT teams see ‘incidents’ as focused on technical outages or service failures rather than the more specific domain of security events which can have much graver consequences.  

A good exercise goes back to auditing the data to be managed and where it is held and walking through the possible consequences of data exposure (through both attacks by bad actors and ‘data spills’ where information is inadvertently exposed).  Once this is understood, map out what a response would look like across several critical areas:

• Alerting – How are you going to know that an incident has occurred? What are the likely reporting vectors – customer notification, alert from your SIEM, etc
• Containment - How do you ‘stem the bleeding’ and stop further data loss? Has the attacker been expelled? Can you isolate the affected environment and prevent an attacker from ‘pivoting’? Have you suspended suspect credentials or other attack vectors?
• Reporting – What are your obligations to customers, law enforcement, or regulatory bodies? Who will coordinate communication, and within what timeframe?
• Removal – How do you remove the threat from the environment? What is your strategy for preserving evidence for later forensic analysis?
• Restoration – What is the plan for service restoration from backup or other source? What service levels do you aim to meet around the restoration and preservation of data?

• Review – What have you learned from the exercise? What went well and poorly? Where did we ‘get lucky’?  

Any exercise should cover all of the above areas. It doesn’t need to be ‘too real’; a paper prototype exercise is usually fine for testing. At RecordPoint, we like to make it a little more ‘real’ and not tell our incident response team before we run a test!  

Focusing on the actual risk

The best advice we can provide is to not rely too much on simply meeting the letter of the compliance requirement, whether from APRA or other requirements. This is just a baseline. Focus on understanding the risks implicit in your data and build a security posture around that analysis. Thinking more broadly than the  compliance requirement ensures you do more than tick a box and actually take concrete steps to manage your business's ‘real risk.

‍