Decision Proposal 191 - Retailer to AEMO InfoSec Profile

[CDR-API-Stream]

The attached decision proposal outlines options and recommendations for the information security profile for communication between Retailers and AEMO under the peer to peer model for energy.

The decision proposal is attached below: Decision Proposal 191 - Retailer to AEMO InfoSec Profile.pdf

Feedback is welcome on this proposal. Consultation on this proposal will close on 9th August 2021.

Apologies for the relatively short consultation period. We are seeking initial feedback on direction with this proposal and still leave time for subsequent, more detailed consultations if they are required. Please indicate if more time for consultation is required.

[SelenaLiuEA]

Good afternoon,

Would it be possible to have an extension to this Issues Proposal, in line with the end point issues paper to 9 August?

Thank you

[gurchan-AGL]

Thanks for the opportunity to contribute.

In principle AGL agrees DSB’s recommendation to adopt “Option 1 – AEMO e-Hub Security Profile, and Option A – Delegated Documentation” is compelling for the factors outlined in the decision proposal. However, AGL does believe there may be a decoupling advantage of a separate CDR Specific Security Profile from that of existing AEMO e-Hub Security especially if the underlying mechanisms in place in the e-Hub can be mostly leveraged.

A CDR specific security profile can evolve independently and be protected from any future energy industry associated info-security changes such as those being considered as part of Australian Energy Sector Cyber Security Framework (AESCSF). AGL suggest further consultation to confirm whether decoupled CDR Specific Security Profile would be compelling enough to support Option 2 or variant that incorporated most of the advantages of Option 1 such as reduced cost of implementation.

Further consultation would also allow consideration of the “end point issues paper” as mentioned by @SelenaLiuEA

[biza-io]

Biza.io believes that this discussion is intrinsically linked to the discussions contained within DP182, NP200 and DP183 as well as more broadly related to the current Treasury Consultations on Rules V3. On this basis we intend to respond to all of these items with linked papers.

As a consequence of the volume of considerations between these items we request the closure time for submissions be extended to 30 July 2021.

[CDR-API-Stream]

By request this consultation is being extended until the 9th August.

As stated in the proposal, early indication of feedback would be helpful due to timeframes. Late feedback that is significantly divergent to the proposal will be harder to accommodate.

Note that to hit the October/November date for candidate level standards for the energy sector there will be less scope for long extensions. For the data clusters we have already been consulting on for over a year will be trying to hold to scheduled dates.

[PratibhaOrigin]

Thanks for the opportunity to provide feedback on the topic - Retailer to AEMO InfoSec.

Based on the consultation paper , the summary of DSB recommendations – The recommendation of the DSB, is to adopt: • Option 1 – AEMO e-Hub Security Profile, and • Option A – Delegated Documentation

This involves utilising the existing AEMO e-hub security profile. The CDR standards would require the use of the e-Hub platform and associated mechanisms for the requesting of data from AEMO by retailers. This would effectively delegate the ongoing management of this security profile to the existing AEMO mechanisms. The CDR standards would refer to this standard as a normative standard and delegate maintenance and clarification of implementation questions to AEMO.

Origin’s feedback – • From a policy point of view – this seems reasonable and we would support the use of existing platforms for the exchange of any data between retailers and AEMO. Assists with minimising costs and already existing processes and systems. • From an energy industry perspective, there isn’t any change to the value to data flowing between AEMO and a Data Holder that would warrant us building a different security profile. • As explained in the document , it also seems reasonable to rely on AEMO to maintain the documentation and include the documented profile as a normative standard within the CDR. • We therefore concur with the recommendations made by DSB in the paper.

Also, we are currently doing the review of the Decision Proposal 192 - AEMO Exposed End Points and if any impacts identified based on that, we will include it in our feedback for DP-192.

[biza-io]

Please find attached the Biza.io Response to Decision Proposal 191: Retailer to AEMO InfoSec Profile: DP191 - Retailer to AEMO InfoSec Profile.pdf

In summary Biza.io does not support the adoption of the AEMO e-hub Security Profile unless the following recommendations are actioned:

• Utilise a trust chain incorporating the ACCC Certificate Authority. This can be done via a tertiary level intermediary or a new intermediary within the same ACCC Root Certificate authority
• Formally adopt the existing or develop an equivalent certificate policy that is aligned with the currently mandated ACCC Certificate Policy
• Adopt a token based authentication method for e-hub Profile API access which utilises Data Standards & Register Standards aligned OAuth2 JWT client assertions (ie. private_key_jwt) coupled with OAuth2 scopes. This will allow alignment to existing key management practices already present in CDR solutions.
• Remove Source IP whitelisting as it is a potential limiter to cloud based deployments and is a questionable information security control
• Uplift existing documentation to incorporate unambiguous technical detail so that implementers are able to interpret more effectively.
• Update the intellectual property guidelines of the e-hub Profile to be clear and unambiguous to facilitate active market participation of CDR solution providers without restriction or risk of AEMO or AEMO Contracted parties to restrict development of CDR solutions such as Development Sandboxes, As-a-Service products etc.

[EnergyAustraliaBA]

Thank you for the opportunity to provide feedback. Energy Australia agrees with the recommendation provided in the consultation paper on AEMO InfoSec Profile which is to apply, specifically

• Option 1 – AEMO e-Hub Security Profile and
• Option A: Delegated Documentation.

This is based on the premise that there won’t be any changes to the security profile by AEMO and that documentation will be maintained by AEMO.

[commbankoss]

For ‘options for retailer to AEMO information security profile’, Commonwealth Bank is supportive of 'Option 2 – CDR Specific Security Profile'. We would only support 'Option 1 - AEMO e-Hub Security Profile' if the security profile is uplifted. Specifically, the security profile for interactions between retailers and AEMO should be uplifted to the same security level as the rest of the CDR ecosystem. For example, changes to the security profile may include:

• Replacing “basic auth” with private_key_jwt to make sure there is no reliance on shared secrets;
• Replacing Resource Server authentication (anti-pattern) with Authorisation Server token based authentication to align with the standard OAuth-based model; and
• Utilising sender constrained access tokens to prevent token leakage.

Broadly, we recommend aligning to FAPI as much as possible. While adoption of the entire profile may be impractical, the threat model used in FAPI should be addressed by the components of the FAPI profile where possible.

For ‘options for level of specificity in Consumer Data Standards’, Commonwealth Bank recommends Option B – Light Documentation. The documentation should refer to the underlying standards (e.g. FAPI and OAuth) as much as possible, and aim to reduce any customization.

[CDR-API-Stream]

In response to the feedback from Biza:

• Utilise a trust chain incorporating the ACCC Certificate Authority. This can be done via a tertiary level intermediary or a new intermediary within the same ACCC Root Certificate authority
• Formally adopt the existing or develop an equivalent certificate policy that is aligned with the currently mandated ACCC Certificate Policy

It is unclear why this would be of value considering the implementation costs for all retailers, for AEMO and for the CDR Register and the feedback does not appear to make a justifiable case. In addition, the concept of a trust chain for a certificate is important in the context of a transaction between two parties but the attempt to apply this across two independent transactions between different parties is not an industry standard approach and appears to be a misapplication of the concept.

• Adopt a token based authentication method for e-hub Profile API access which utilises Data Standards & Register Standards aligned OAuth2 JWT client assertions (ie. private_key_jwt) coupled with OAuth2 scopes. This will allow alignment to existing key management practices already present in CDR solutions.
• Remove Source IP whitelisting as it is a potential limiter to cloud based deployments and is a questionable information security control

If we were to adopt a CDR specific profile this would proposal would be a candidate approach to simplify implementation. In this situation, however, the existing participants (AEMO and the energy retailers) have already implemented an existing set of protocols and requiring them to align with the CDR adopted processes would actually make things more complex.

• Uplift existing documentation to incorporate unambiguous technical detail so that implementers are able to interpret more effectively.
• Update the intellectual property guidelines of the e-hub Profile to be clear and unambiguous to facilitate active market participation of CDR solution providers without restriction or risk of AEMO or AEMO Contracted parties to restrict development of CDR solutions such as Development Sandboxes, As-a-Service products etc.

These items are outside of the control of the DSB.

Overall this feedback indicates that Biza recommends defining a new, CDR specific, information security protocol for these transactions with specific requirements being applied. This would appear to align with Option 2 and Option C in the proposal.

[CDR-API-Stream]

In response to the feedback from CBA

Broadly, we recommend aligning to FAPI as much as possible. While adoption of the entire profile may be impractical, the threat model used in FAPI should be addressed by the components of the FAPI profile where possible.

For ‘options for level of specificity in Consumer Data Standards’, Commonwealth Bank recommends Option B – Light Documentation. The documentation should refer to the underlying standards (e.g. FAPI and OAuth) as much as possible, and aim to reduce any customization.

Similar to the response to the feedback from Biza, this would essentially mean defining a new profile for retailer to AEMO communication that does not take into account pre-existing relationships and implementations.

Aligning with a specific international standard is not a rationale by itself and the feedback does not provide a justification as to why this approach should be preferred in the face of the additional complexity and cost for the implementing entities.

Also, this does not misalign with the adoption of the recommended approach. If AEMO, through consultation with their client community, concurs that the adoption of OIDF related standards would be an appropriate roadmap then this could be achieved via their existing community consultation processes.

[CDR-API-Stream]

In response to feedback from @gurchan-AGL

The need for further consultation is understood. One possibility in this space is that we adopt a minimal approach initially but, in response to evolving need, we move to a more specific requirement. An adoption of option 1 at this point in time does not preclude that position changing in response to further consultation and experience as the standards progress as we approach November and also beyond that.

[CDR-API-Stream]

After reviewing the feedback provided it would appear that there is strong support for the recommendation in the decision proposal, acknowledging that this position may need to change in the future as further consultation progresses.

The DSB will prepare a decision document in alignment with the existing recommendation for consideration by the Data Standards Chair.

[CDR-API-Stream]

Please find attached the final decision of the Chair: Decision 191 - Retailer to AEMO InfoSec Profile.pdf