While cybersecurity is front of mind for every Australian organisation at the moment, energy companies have even more reason than most to be looking closely at implications of the Consumer Data Right (CDR), writes Reinhart Hansen, Director of Technology, Office of the CTO, Imperva.
This is because of new reform coming into the energy sector—known as the Consumer Data Right. This data portability reform starts its rollout to the energy sector in November, starting with AEMO, AGL Energy, Origin Energy, and EnergyAustralia.
While the CDR will be good for the energy sector in the long-term, it will create some challenges for energy retailers in the short-term. Here, we outline exactly what the CDR is and the potential ramifications in regards to competition, regulatory burden, development pressure, and cybersecurity risks.
Related article: Customer details exposed in EnergyAustralia cyberattack
What is the CDR, and what does it mean for energy companies?
The Australian government introduced the CDR in 2017 to enable consumers to efficiently and conveniently access their personal data held by businesses (data holders) and to authorise the secure sharing of that data to trusted and accredited third parties (accredited data recipients).
The CDR is being applied sector by sector across the whole economy. It started with the banking sector and is now extending to the energy sector. The initial roll-out is limited to four key players in the National Electricity Market (NEM) but will be applied to other retailers in the NEM within 12 months.
The rollout comes at a critical time for the energy sector where costs are rising and consumers are keenly focused on their spending. The CDR is expected to increase competition, because it will be easier for consumers to compare and switch providers.
At the same time, it will place more regulatory burden on large energy retailers, who will be required to set up and register as data holders. Under CDR, data holders are required to do two things:
• transfer a consumer’s data in a machine-readable format when they receive a request via the secure Consumer Data Right system,
• publicly release general product data about products they offer, covering interest rates, fees and charges, discounts, and other features.
A large part of this regulatory burden rests with an organisation’s development team. Sending and receiving customer data relies on the development of specific Application Programming Interfaces (APIs), as defined by the Data Standards Body (DSB). Beyond that, security and privacy teams will need to ensure their organisation collects, uses, shares, and protects all customer data in line with the requirements outlined by the regulators.
What cybersecurity risks does CDR introduce?
The sharing of customer data via APIs, as required by the CDR, presents a significant security risk for energy retailers, as APIs connect applications together, system to system and app to app. They also connect to data stores to enable the extraction and sharing of data in an accessible manner.
A recent report by Marsh McLennan found in Australia API insecurity is responsible for between 12% and 16% of cyber events and losses. This is why hackers are targeting APIs:
1. Value: APIs connect internal data stores and applications to external and internal services, providing a pathway for cybercriminals to access vast amounts of sensitive data such as customer information or business critical data. Further, APIs serve as a blueprint for cybercriminals. They can act as a map to internal objects and even internal database structures that bad actors can exploit.
2. Proliferation: With the rising volume of APIs, bad actors now have more gateways to access sensitive data. According to Forrester, half (49%) of organisations have between 25 and 250 internally published APIs, and 60% have the same number of public APIs. The majority of organisations expect that number to increase over the next year.
3. Growth in Vulnerabilities: The vulnerabilities hackers can use to exploit APIs is also on the rise.
As APIs connect to data stores, one of the biggest risks that API insecurity poses is data exfiltration. In recent months, dozens of high-profile data breaches originated from API security-related incidents. Other API threats include data scraping, access exposure, end-user tracking, account takeover and more. This highlights the importance of having a positive security model to protect the organisation from API-based threats.
However, the biggest challenge security teams face in implementing such a model is the development team. With development teams under pressure to build apps and APIs quickly, security becomes an afterthought. Too often, APIs are released into production faster than a security team can review and catalogue them. In some cases, the security team doesn’t even have full visibility of all the APIs being developed and released, making it impossible to secure them.
Here are a couple of examples of how poor API development practices create cybersecurity risk:
1. APIs are published without security review or controls. This can create shadow APIs that are invisible to the security team and API gateway. The issue with shadow APIs is that they have access to the same sensitive information that published, secured APIs do, but no one knows where they exist or what they’re connected to.
2. APIs are not properly disabled. Deprecated or zombie APIs become a dormant breeding ground for cybercriminal activity—usually outside of the purview of developer and security operations. These unmonitored APIs are analogous to an unlocked window. Motivated criminals can sneak in to access data or execute more sophisticated attacks—often without the developer or security team ever knowing. This is the underlying risk factor that becomes a software supply chain attack.
How can organisations mitigate these security risks while still meeting CDR requirements?
To help mitigate the cybersecurity risks related to API development, security teams need to undertake the following activities:
• Gain real-time visibility of your API catalogue. Addressing API security risks requires full visibility of all APIs and their data exchange patterns. If you don’t have visibility into the full API schema or the changes being made to it, you’ll be unaware if the API is compromised or what data is accessed by an API.
• Identify and classify data flowing through every API. Get visibility beyond the API endpoint into each API’s underlying payload to identify sensitive data that could be subject to regulations and a target for cybercriminals.
• Identify end-users to authenticate and authorise. Determining the identity of end-users and what they need access to is key to securing APIs and implementing authentication. APIs should be built and tested to prevent users from accessing API functions or operations outside their predefined role.
• Understand API behaviour. Just as there needs to be controls in place on what users do, businesses need to understand APIs and how they behave, identifying unusual behaviour that could be a sign of malicious activity.
Related article: Australian boards urged to boost cybersecurity skills
• Don’t just rely on an API Gateway. Any security-related features associated with API gateways are usually related to access authentication or endpoint-level authorisation, they cannot detect sophisticated attacks targeting vulnerabilities in the application business logic and data layer and cannot discover each API’s full schema.
• Adopt for DevSecOps. SecOps teams must make DevOps teams partners in the creation and execution of their security strategy. To start, create an effective feedback loop between DevOps and SecOps teams—a development security operations (DevSecOps) approach—designed to help DevOps and SecOps work in concert to get API security risks under control.
The Consumer Data Right adds another layer of regulatory burden and complexity for the energy sector, especially in regards to data protection and cybersecurity. As energy retailers develop at speed, to both meet digital transformation goals and CDR requirements, it is critical that security teams keep pace. If they don’t, they run the risk of a security incident that could have wide-ranging consequences, including regulatory action.
