What CISOs need to know about Australia’s consumer data right

The consumer data right (CDR), first mooted by the Australian federal government in 2017, lets consumers compare and switch providers more easily by giving them more control of their personal data. Banking is the first sector to roll out the CDR, with energy and telecommunications to follow.

The early experiences are revealing how CSOs may need to adapt security protocols to each sector to secure the flow of data.

For providers like banks and telcos, the CDR means a new personal data sharing regime, becoming accredited as a data recipient, and being subject to compliance checks—and potential enforcement actions for compliance failures. There are now 12 accredited data recipients, with Finder and SISS Data Services recently joining the list. In the case of banking, the four major banks are the first required to share data, to be followed by most authorised deposit-taking institutions (ADIs).

By accrediting providers, the CDR framework is designed to ensure secure data sharing between designated data holders and accredited data recipients. “The accreditation requirements ensure data recipients have appropriate controls in place to keep data secure,” an Australian Competition and Consumer Commission (ACCC) spokesperson told CSO Australia.

Security-driven CDR compliance

Each sector—banking, energy, and telecommunications—will have its own CDR implementation, including the application programming interfaces (APIs), which are to be agreed by the stakeholders in the sector and coordinated by the relevant agency—the ACCC or the Commonwealth Treasury.

Under the CDR scheme, there are data holders and data recipients, and to be CDR-compliant, providers must use the APIs developed for the sector. In the system design, security considerations have been paramount from the outset. “The design process was driven by cybersecurity concerns,” said Rob Nicholls, an associate professor of regulation and governance at the University of New South Wales’s Institute for Cyber Security.

Each data recipient and data holder is expected to have a sector-specific endpoint security system. Banking, which deals with more sensitive information, may require endpoint security that is greater than in the energy sector, Nicholls said.

The endpoint API security is defined in the standards. So with banking, for example, it uses either OAuth 2.0 access tokens or ID tokens. “Compliance with the validation rules in RFC 6749 is also required. That is, well-established standards are incorporated by reference into the CDR standards and these are all provided on a GitHub,” Nicholls said.

Having these industry-specific requirements has actually meant that the changes have improved consumer data security. Nicholls noted the original model using the Australian Energy Market Operator (AEMO) gateway did not adequately protect consumer data, so has since been strengthened. “Now, the industry is moving to a more secure peer-to-peer solution. The way these will be secured has not yet been finalised; however, all stakeholders will be involved,” he said.

The ACCC is the lead regular for the CDR and, together with the Office of the Australian Information Commissioner (OAIC) and the Data Standards Body (DSB), has been developing and implementing the CDR.

The DSB has created the technical standards for the processes of sharing consumer data, while the OAIC is responsible for investigating and enforcing any privacy complaints and managing any privacy-related regulatory activities. Both the ACCC and OAIC will “monitor and enforce CDR participants’ compliance with the relevant laws, rules, and data standards,” Nicholls said.

What security accreditation is required

There are high minimum security requirements to comply and be admitted into the CDR system. These include the use of encryption, firewalls, and server hardening for network security, along with multifactor authentication, audit logging, and monitoring, as well as role-based access, unique IDs, and password authentication to protect access to consumer data.

Providers must also securely manage data across its life cycle, including data loss prevention, and hold CDR data in nonproduction environments. Vulnerability management needs to include security patching and secure coding. Malware protection, at a minimum, will have antimalware, antivirus, web and email content filtering, and application whitelisting. And not overlooking the human element, providers must offer security training and awareness, including the acceptable use of technology and human resource security.

To begin accreditation, organisations need to provide evidence they have a secure IT environment. “Once accredited, data recipients are required to pass a range of tests using a conformance test suite (CTS) to demonstrate their technology solution works correctly in the CDR ecosystem,” the ACCC told CSO Australia.

This testing takes place in a sandbox, and participants must pass the CTS before they receive ‘active’ status and are allowed to be part of the CDR. If providers, particularly smaller operators like fintech firms or online-only ‘neobanks’, need help to quality, compliance services are available from third parties to help them meet the CDR ecosystem requirements.

“Any businesses that fail [the CTS] are not identified by the ACCC, but they don’t become ‘active’” and thus are not part of the CDR ecosystem. “Even some of the major banks have had to apply more than once,” Nicholls said.

CDR compliance may create additional security requirements—and work

Local fintech Frollo helped build and test the CDR ecosystem as part of ACCC trial. Its CIO Tony Thrassis noted the security for accessing the CDR APIs is not in itself too onerous to build—but it’s a different story if things go wrong. “Once developed, it is very tight, and any issues between the data holder and data recipient become difficult to fix in production,” he said.

“We are seeing the need for a consumer to revoke their consent and re-consent to fix a problem. While maturity of IT systems will reduce this, things can go wrong and networks can have issues,” he said. That may require additional requirements to be brought to bear in existing systems.

The second element is the security objectives and controls along with data safeguards. “These are basically what an authorised ADI would need to pass Australian Prudential Regulation Authority (APRA) CPS234. Not a lot different, but in that regard, for a small fintech, these are quite onerous,” Thrassis said.

To manage the CDR security requirements, Thrassis recommends CSOs put in the required controls, safeguards, polices, and procedures. “These are also not too different to ISO 27001. For organisations not familiar with this level of security and the practices required, it will be quite daunting and not cheap to implement,” he said.

As part of the trial it undertook with the ACCC, Frollo performed more than 300 tests. When it went live with the four major banks, there were still plenty of issues. Thrassis said the CTS is at issue, and he considers the CTS not sufficiently robust to say the software developed, either by a data holder or data recipient, will itself be robust.

“CTS is not a quality tool, only a compliance tool, and that is a significant difference. We tested the big four banks and have been providing testing services to other banks. No one has got this right first go,” he said.

The CTS’s limited scope of compliance is one issue that will affect organisations seeking to be accredited for the CDR.

The University of New South Wales’s Nicholls   note that the two major cybersecurity concerns the new regime has addressed stem from two areas : systems and user data.

• The first is ensure that the underlying systems are not exposed by the CDR process. “That is, the APIs provide a mechanism by which underlying critical infrastructure is not exposed. The APIs and API security (including authentication and authorisation systems) are part of the cybersecurity design.”
• The second part is ensure that consumer data is not exposed, he said.

What first steps should CSOs take for CDR implementation?

The first steps begin with mapping out the CDR processes that will be needed against what is currently in operation within the organisation. If there isn’t in-house experience, CSOs may need to look for external support from expert security assessment teams familiar with the framework.

“In our case, because we were already working according to 27001 certification, we mapped the extra controls and procedures that were needed and updated staff with the new procedures,” Frollo’s Thrassis said.

“We had to change systems to capture what was needed and restrict access where needed. Then it was building the actual use case into our apps and back end—then lots of testing over six months. This meant understanding standards, developing our customer CDR policy and working out what de-identification meant by the rules. If it couldn’t be passed, due to too much complexity (like de-identification), it had to be avoided,” he added.

The University of New South Wales’s Nicholls suggested keeping across the regular government updates, via access to the GitHub and web resources as well as the implementer-specific support portal.

While some of the available resources can help a CSO in that CDR effort, the commitment required is major. “All of this requires significant resources to be allocated by the CSO or CIO. To get those resources, it’s critical that the consumer and security challenges are understood by the board of directors, as well as the C-suite,” Nicholls said. CDR compliance is, after all, a required cost of doing business.

And organisations can use it for broader advantage, Nicholls said: “The introduction of the CDR is being used by a number of businesses as an opportunity for significant transformation. It’s a great reason for dropping legacy and less-secure systems.” Of course, these transformations too will require significant attention from the CSO,” he said.