Noting Paper 258 - Independent Information Security Review

[CDR-API-Stream]

Update 16/12/2022:

Decision Record

The Data Standards Chair approved this decision on 16th December 2022. The decision record is attached: Decision 258 - Response to Independent Security Health Check - final.pdf

---

Update 01/12/2022: This noting paper has been closed with a decision by the Chair in response to the community feedback and the report's recommendations to be published in the near future.

07/07/2022: The DSB, as an arm of Treasury, has engaged an external specialist assurer to provide an independent assessment of how the Information Security Profile (Profile) of the Data Standards for the Consumer Data Right (CDR) is tracking against relevant security benchmarks. Similar assessments have been completed in the past (the last one is here) and more will be undertaken in the future to help ensure the CDS remain fit for purpose. As some time has passed since the last assessment the current work has been approached in a staged manner and the attached report should be read as a first pass intended, in part, to identify areas that will require further and more detailed attention.

The DSB considers it timely to undertake this assessment now as we look ahead to an expanded CDR in line with the Government Response to the Final Report of the Inquiry into Future Directions for the Consumer Data Right, particularly with regard to action and payment initiation. Given the already substantial installed base of CDR implementations we are interested in finding ways to stage necessary changes to avoid the risks inherent in attempting wholesale change all at once.

The attached report is as provided by the external specialist assurer and should not be read as representing the views of the DSB or the Data Standards Chair. We will consider appropriate responses to the recommendations contained in the report over coming weeks. In the meantime we invite and welcome feedback on this report from the wider CDR community, ideally publicly on this thread but also privately via contact@consumerdatastandards.gov.au.

The report is attached below: Independent Health Check Final Report.pdf

[RobHale-Truelayer]

It is great that this document has been created and shared for public comment. As called out in Section 9.1, this open process continues to add value. Consideration should be given to mirroring this approach by other agencies. While it is a technical document, the comments in Section 8 are insightful. They would be readily understood by a broader audience and should probably be shared more widely.

High level thoughts and comments

1. Overall, CDR is incredibly complex. Wherever possible, an umbrella principle such as “keep things simple, easy to communicate and easy to understand” might be worth considering. This could also apply to regime security. For example, while further OTP/2FA optionality may well offer flexibility and enhanced security for some, we find ourselves in trade-off territory with an elevated burden of comprehension for rule makers, enforcement teams, participants and consumers.
2. The thinking behind getting consumers to check URLs, imposing lengthy OTPs and providing a Data Holder “kill switch” is understood, yet it feels like we are patching rather than addressing a fundamental flaw. Consumers already face significant cognitive load in unfamiliar territory with CDR, so the intended value of offering additional or extended security features may not be realised. We saw an example of this with the well-intentioned original joint account consent flows. They were just impractical. The consumers of CDR are people who are primarily motivated by an outcome - a product or service - not the process through which it is delivered. By the same token it seems CDR will be safer and better for everyone if we are able to productise security, baking it in and not relying on consumers to be aware of risks and to take action to protect themselves.
3. In order to become dominant and to unseat screen scraping as the de facto method of data sharing, CDR needs to be superior from the consumer’s perspective. There is no competitive benefit in a slower, more cumbersome process. Despite us all recognising the security benefits, we’ve seen this play out in the market. Pure play CDR providers are currently few and far between. A streamlined consent process would be a powerful step in the right direction. The report identifies that the current redirect-with-OTP arrangement is lacking in security. Given that this is also a high point of friction for consumers, it would appear to have little going for it. Rather than spending effort reinforcing and shoring up the current model, would it be better to expedite a more contemporary (and more secure) replacement that also supports higher data sharing conversion? The UK flows outlined in 4.3 could be a good starting point here.
4. The report rightly notes significant variability in data holder authentication implementations. This situation is unhelpful if we value a consistent UX as a contributor to overall regime trust. Perhaps some form of DH rating could be displayed for consumers to see. Similar to browser trust symbols used to highlight insecure websites, this might incentivise DHs (and ADRs) to comply with more secure data sharing practices.
5. Finally, a thought on the network of participants and the collective contribution this network could make to an enhanced overall security posture. As a means with which to combat larger-scale fraud and attacks, could CDR include inbuilt notification features? Could other participants be made aware of repeated failed authentication attempts at a DH, high numbers of sessions from a single source, enumeration attacks, or other behaviours considered outside of ‘normal’ bounds?

[jogu]

In section 7.2 ([Refresh] 'Token Rotation'), the report says:

This view is reflected in the draft OAuth 2.0 security recommendations, which makes explicit the requirement to sender constrain both access and refresh tokens [8, 4.13.2].

However the only relevant clause I can see in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.13.2 only applies to public clients, so is not applicable to CDR (where only confidential clients are permitted):

[ghost]

3. In order to become dominant and to unseat screen scraping as the de facto method of data sharing, CDR needs to be superior from the consumer’s perspective. There is no competitive benefit in a slower, more cumbersome process. Despite us all recognising the security benefits, we’ve seen this play out in the market. Pure play CDR providers are currently few and far between. A streamlined consent process would be a powerful step in the right direction. The report identifies that the current redirect-with-OTP arrangement is lacking in security. Given that this is also a high point of friction for consumers, it would appear to have little going for it. Rather than spending effort reinforcing and shoring up the current model, would it be better to expedite a more contemporary (and more secure) replacement that also supports higher data sharing conversion? The UK flows outlined in 4.3 could be a good starting point here.

I think this is a great point. I know a lot of effort was put towards this model in 2019 with a big push by some stakeholders away from utilising existing authentication of DHs. I think it is good to challenge the model again now with the benefit of real-world experience. Let's not fall victim to the sunk-cost fallacy cognitive bias, and make sure we look at it objectively.

4. The report rightly notes significant variability in data holder authentication implementations. This situation is unhelpful if we value a consistent UX as a contributor to overall regime trust. Perhaps some form of DH rating could be displayed for consumers to see. Similar to browser trust symbols used to highlight insecure websites, this might incentivise DHs (and ADRs) to comply with more secure data sharing practices.

I like the concept of a trust rating per DH. And per ADR. This would provide a win-win for consumers and the ecosystem.

[DSB-RT]

They would be readily understood by a broader audience and should probably be shared more widely.

Thanks @RobHale-Truelayer.

Would you care to elaborate on which audiences, and what channels?

Best, RT

[RobHale-Truelayer]

Hi @DSB-Rob - I was really just flagging a general observation...

I love the fact that the DSB is transparent and open using GitHub to engage on CDR issues and standards - this noting paper is a great example of that 👏

Yet, in my view, GitHub can be intimidating to many CDR participants due to the largely technical content that appears here and the highly specialised nature of related dialogue. I suspect that many non-technical people would find the content in section 8 and 9 useful, however they may never stumble across it because it appears here, buried deeply within an intimidatingly titled report. We may therefore miss out on receiving their input and understanding their views.

I'm clearly generalising in my simplistic categorisation of tech / non-tech people but I did mentioned this same matter on a FDATA call today and others seemed to subscribe to the same view so I don't think I'm completely bonkers 🤪

The solution? Tricky in this instance but potentially just adding it as an agenda item on the Thursday Implementation Call might suffice. Point people to pages 39+ and suggest a read. I'm happy to say something if JJ wants to throw to me for comment!

[chrisculnane]

In section 7.2 ([Refresh] 'Token Rotation'), the report says:

This view is reflected in the draft OAuth 2.0 security recommendations, which makes explicit the requirement to sender constrain both access and refresh tokens [8, 4.13.2].

However the only relevant clause I can see in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.13.2 only applies to public clients, so is not applicable to CDR (where only confidential clients are permitted):

@jogu just to clarify that reference is in 7.1 Sender Constrained Tokens and is provided as an example of how other standards handle sender constraints consistently between access and refresh tokens. The issue at hand is that FAPI Security Profile 1.0 - Part 2: Advanced changed to remove the explicit sender constraint requirement on refresh tokens. The argument appears to be that since OAuth requires client authentication for confidential clients, as well as a check that a refresh token was issued to that client, that it is equivalent.

However, that is not strictly equivalent to sender constraining via MTLS. As a result, the security of the access token reduces to that of the refresh token client check, since the refresh token can be used to generate a new access token. It is more desirable to have consistency between access and refresh token constraints.

[jogu]

just to clarify that reference is in 7.1 Sender Constrained Tokens and is provided as an example of how other standards handle sender constraints consistently between access and refresh tokens.

Yes, apologies, I did quote the incorrect session number / heading.

I would still say it's somewhat misleading to quote text that talks about requirements for public clients, and to say It reflects the view that confidential clients should use sender constrained access tokens using a mechanism other than client authentication.

The issue at hand is that FAPI Security Profile 1.0 - Part 2: Advanced changed to remove the explicit sender constraint requirement on refresh tokens.

This is not really true, albeit the situation is complicated - as per https://bitbucket.org/openid/fapi/issues/202/authorization-code-and-refresh-token-must :

<...> I suggest we remove the requirement that the refresh token and authorization code are holder of key bound.

The requirement that the client has to use asymmetric crypto to authenticate at the token endpoint has the same effect - and in practice is what I believe that people have interpreted the spec to mean.

Most people consider that requiring OAuth client authentication, with the additional constraint as per FAPI of private_key_jwt or MTLS client authentication, requires that the client proves possession of the key at the token endpoint when using a refresh token - meeting the requirements of sender constraining. It is, for example, as strong as the default mode defined in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop for sender constraining access tokens. So removing the text saying that refresh tokens had to be sender constrained had no practical effect, no implementations nor conformance tests were changed as a result of that change. The conformance tests continue to check that refresh tokens are bound to the client as required by RFC6749.

For confidential clients, there's not actually a standards defined method for sender constraining a refresh token for a confidential client, other than (as FAPI1 part 2 does) using OAuth client authentication. The 'simple' approach of binding it as is done for public clients, using the method in https://datatracker.ietf.org/doc/html/rfc8705#section-7.2 results in the client losing all consents if it rotates it's keys, as it is no longer able to use the refresh tokens that were bound to the old key. (So for confidential clients, FAPI1 has never defined any interoperable way to practically sender constrain refresh tokens, other than OAuth client authentication.)

[DSB-RT]

Hi @DSB-Rob - I was really just flagging a general observation...

I love the fact that the DSB is transparent and open using GitHub to engage on CDR issues and standards - this noting paper is a great example of that 👏

Yet, in my view, GitHub can be intimidating to many CDR participants due to the largely technical content that appears here and the highly specialised nature of related dialogue. I suspect that many non-technical people would find the content in section 8 and 9 useful, however they may never stumble across it because it appears here, buried deeply within an intimidatingly titled report. We may therefore miss out on receiving their input and understanding their views.

I'm clearly generalising in my simplistic categorisation of tech / non-tech people but I did mentioned this same matter on a FDATA call today and others seemed to subscribe to the same view so I don't think I'm completely bonkers 🤪

The solution? Tricky in this instance but potentially just adding it as an agenda item on the Thursday Implementation Call might suffice. Point people to pages 39+ and suggest a read. I'm happy to say something if JJ wants to throw to me for comment!

Thank you Rob.

There were security items on the agenda for last week's imp call, but I was unable to attend. Did this meeting address your needs? Or would you like to suggest we post this report to our website as well?

Best, RT

[DSB-RT]

just to clarify that reference is in 7.1 Sender Constrained Tokens and is provided as an example of how other standards handle sender constraints consistently between access and refresh tokens.

Yes, apologies, I did quote the incorrect session number / heading.

I would still say it's somewhat misleading to quote text that talks about requirements for public clients, and to say It reflects the view that confidential clients should use sender constrained access tokens using a mechanism other than client authentication.

The issue at hand is that FAPI Security Profile 1.0 - Part 2: Advanced changed to remove the explicit sender constraint requirement on refresh tokens.

This is not really true, albeit the situation is complicated - as per https://bitbucket.org/openid/fapi/issues/202/authorization-code-and-refresh-token-must :

<...> I suggest we remove the requirement that the refresh token and authorization code are holder of key bound. The requirement that the client has to use asymmetric crypto to authenticate at the token endpoint has the same effect - and in practice is what I believe that people have interpreted the spec to mean.

Most people consider that requiring OAuth client authentication, with the additional constraint as per FAPI of private_key_jwt or MTLS client authentication, requires that the client proves possession of the key at the token endpoint when using a refresh token - meeting the requirements of sender constraining. It is, for example, as strong as the default mode defined in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop for sender constraining access tokens. So removing the text saying that refresh tokens had to be sender constrained had no practical effect, no implementations nor conformance tests were changed as a result of that change. The conformance tests continue to check that refresh tokens are bound to the client as required by RFC6749.

For confidential clients, there's not actually a standards defined method for sender constraining a refresh token for a confidential client, other than (as FAPI1 part 2 does) using OAuth client authentication. The 'simple' approach of binding it as is done for public clients, using the method in https://datatracker.ietf.org/doc/html/rfc8705#section-7.2 results in the client losing all consents if it rotates it's keys, as it is no longer able to use the refresh tokens that were bound to the old key. (So for confidential clients, FAPI1 has never defined any interoperable way to practically sender constrain refresh tokens, other than OAuth client authentication.)

For clarity, Chris Culnane was one of the authors of this independent health check.

Best, RT

[RobHale-Truelayer]

Hi @DSB-RT

There were security items on the agenda for last week's imp call, but I was unable to attend. Did this meeting address your needs? Or would you like to suggest we post this report to our website as well?

Thanks for checking back. I only managed to attend for part of the call so am not sure if there was any engagement. However I checked the Agenda just now and see it has been flagged in the last 2 calls - so it's out there and hopefully getting some broader readership. I think that should suffice 🙏

[PratibhaOrigin]

Origin welcomes the reviews analysis of the CDR authentication flow using OTP and its shortcomings. Whilst Origin understands that this is a known issue that has been discussed during the Banking implementation, Origin hopes this paper will evoke renewed focus on this issue, with the gravitas it requires. The OTP authentication method is very vulnerable to spear phishing attacks. Scammers can obtain the OTP, under false pretences, from a sizeable number of Energy customers, particularly those that are not tech savvy or digitally enabled. This OTP may be used to go through the CDR authentication flow, resulting in access to the customers information through a legitimate ADR.

Origin Energy believes that Energy (and Utilities) industry is more susceptible to this issue, as consumers are used to switching energy retailers over the phone as compared to switching their financial institutions. Origin hopes that this issue is mitigated, including if any updates/amendments to the CDR Standards are required, to make it more difficult for the scammers to access customer accounts, if not fully deter them. This issue has been discussed with the DSB technical team and several alternatives were discussed however there is no appetite to update the standards before the 15th of November 2022 go-live despite the live risk. As such, based on our discussions, Origin would like to formally lodge it as a CDR risk so that industry can work together in remediating it.

Issue description: Historically, Origin has observed the following scam pattern: • Customers receive calls purporting to be from another major retailer promising customers cheaper rates. This occurs during rate increase periods. • The scammers let the customer know that they needed to verify the customers identity using OTP. • The scammers initiate a password reset flow, which requires email address and OTP. This sends the OTP to the customer. • Customer provides the OTP over the phone thinking they were verifying their identity. • Scammers reset customers password and take over the customer’s account, downloading bills and obtaining other PII.

Whilst Origin has put in place controls to prevent and detect such activity, the CDR authentication flow would be an easier vector for the scammers to use. Instead of attempting the scam through our systems, the scammers will move to an ADR instead, achieving the same objective.

Origin is concerned that, due to the prescribed auth standards, the CDR weakens the DHs controls against this type of attack. Overall, there seem to be incongruency with the controls placed to protect vulnerable consumer (e.g., Domestic/Family Violence) as this scam is a straightforward way for family violence victim’s information to be obtained despite any controls implemented at the data holder. There is a concern that while numbers are low, its criticality is quite high and has a potential to cause damage to CDR brand and result is grave consequences for the DH and more importantly, the customer. With the current CDR authentication flow, the DH is limited to implementing detective controls such as device fingerprinting. However, in several circumstances, these controls are ‘after the fact’. The damage is already done. Preventative controls, such as the use of magic links (that are not easily shareable), would go a long way in preventing these scams. However, the DHs are bound by the prescribed OTP flow.

If this risk is known, understood and has been accepted for CDR, a few questions would need attention.

1. What is the process to follow should a data holder observe targeted scam campaign against its customers?
2. What are ADRs obligations to mitigate this kind of attack?
3. Is the CDR lowering the security posture of Data Holders that have a more stringent authentication flow than that which is prescribed by identifier + OTP?
4. If this is accepted and understood, what is the threshold of occurrences beyond which the risk warrants a review?

[AusBanking]

The ABA welcomes the engagement of an external review of the Profile and Data Standards, and the sharing of this assessment with the community. This was a valuable exercise, and we recommend that these reviews are performed at least annually, or more frequently if major changes.

We do note that the scope of the review only addresses part of the ecosystem, we understand that a further review will be undertaken and recommend that the following topics are covered: • Data Holder: Data Recipient communications (cdr_arrangement_id) • Portal Security: for participant administration by participants, or ACCC. • Participant and software accreditation (initial and ongoing). • Complex consents scenarios (such as Nominated rep, Secondary Account Holders, Vulnerable persons)

Keeping it Simple

We agree with @RobHale-Trulayer on the need of the simplification of the scheme to gain adoption, this will reduce the analysis and risk of implementation issues given the steep learning curves of participants, in not only the upstream standards, but also the non-standard or transitional characteristics of the CDR.

We support all recommendations of the report that clarify or simplify the standards.

Consumer Authentication

The ABA supports the recommendations of the health check which release data holders from conformance with the CDR standards for OTP flows, and instead require conformance with other standards such as NIST. As reflected in the document, this approach remains consistent with the rules, but will also ensure that innovation and the adoption of more secure authentication mechanism can be adopted for the CDR.

We support the opinion of the document that the CDR OTP does not fully mitigate the risk of Phishing, and believe that in time, as organisations move to alternative mechanisms that prevent phishing such as App2App or WebAuthN, the CDR OTP flow may become the remaining target for a phishing attack on an organisation.

In the spirit of standards simplification, rather than supporting the recommendations to change standards to mitigate issues with the current OTP flow, we would instead recommend the standards require conformance with upstream standards such as NIST that would bring the same outcome.

We agree with the recommendation for the minimum credential level within the Data standards to be CL2.

Registry

While we support the papers recommendations for JWT validation, transition of authorisation states, and suggestions for some other "minor improvements", the ABA recommends a full analysis of the registry and its function; in particular an analysis of ADR lifecycle management and security as it relates to addressing issues stemming from new Rules V3, and raised in #427 (see also #480 Pairwise) and intended to be covered in future plan #68.

Scheme Authentication

While we are in general agreement with the recommendations of this section, we also support the comments above of @jogu. This section of the paper digs deep into FAPI and the subsequent discussion indicates potential for further analysis is required, and the materiality of the risk is well understood; however, at this stage we support Recommendation 27, which allows organisations to implement this controls consistent with their risk appetite.

Consent Framework

We strongly recommend further analysis into the consent framework, to take into consideration Rules Version 3, aspirations of the Future Directions report (e.g. cross border use cases) and how capabilities such as Cryptographically signed consent receipts may be realised. For example: Under the current model a cryptographically safe consent receipts issued by an ADH (pp40) would be worthless

[MattM-Cuscal]

We welcome the open and transparent consultative process thereby improving the quality of the standard and strengthening the security posture which is very crucial for the sensitive nature of the information being consumed or produced. We support all the recommendations as we believe they ensure enhancing the security of the CDR eco-system.

We strongly agree to the recommendation on leveraging the existing Data Holder authentication flow mechanism over CDR OTP authentication flow (OIDC Hybrid flow with single factor OTP). However, we believe that the standard must define/mention at least one stronger authentication flow which Data Holder or a representative of Data Holder must provide; also allow the Data Holder or a representative of Data Holder to provide alternate authentication mechanisms (of equal or higher level of authentication assurance than the mandated flow) which consumers can opt-in. We agree with recommendation to set CL2 as the default credential level in the Data Standards.

We also recommend that the CDR security requirements refer directly to the NIST standards wherever applicable and reference other standards only if NIST doesn't address them directly. This will help simplify the standard and help remove the ambiguities.

We welcome the other recommendations on key management, certificate management, security endpoints, & registry endpoints which add greater clarity and simplification to the Data Standards.

[amanuel13]

With reference comment by Ron Hale True Layer " It is great that this document has been created and shared for public comment. As called out in Section 9.1, this open process continues to add value. Consideration should be given to mirroring this approach by other agencies. While it is a technical document, the comments in Section 8 are insightful. They would be readily understood by a broader audience and should probably be shared more widely.

High level thoughts and comments

1. Overall, CDR is incredibly complex. Wherever possible, an umbrella principle such as “keep things simple, easy to communicate and easy to understand” might be worth considering. This could also apply to regime security. For example, while further OTP/2FA optionality may well offer flexibility and enhanced security for some, we find ourselves in trade-off territory with an elevated burden of comprehension for rule makers, enforcement teams, participants and consumers.
2. The thinking behind getting consumers to check URLs, imposing lengthy OTPs and providing a Data Holder “kill switch” is understood, yet it feels like we are patching rather than addressing a fundamental flaw. Consumers already face significant cognitive load in unfamiliar territory with CDR, so the intended value of offering additional or extended security features may not be realised. We saw an example of this with the well-intentioned original joint account consent flows. They were just impractical. The consumers of CDR are people who are primarily motivated by an outcome - a product or service - not the process through which it is delivered. By the same token it seems CDR will be safer and better for everyone if we are able to productise security, baking it in and not relying on consumers to be aware of risks and to take action to protect themselves.
3. In order to become dominant and to unseat screen scraping as the de facto method of data sharing, CDR needs to be superior from the consumer’s perspective. There is no competitive benefit in a slower, more cumbersome process. Despite us all recognising the security benefits, we’ve seen this play out in the market. Pure play CDR providers are currently few and far between. A streamlined consent process would be a powerful step in the right direction. The report identifies that the current redirect-with-OTP arrangement is lacking in security. Given that this is also a high point of friction for consumers, it would appear to have little going for it. Rather than spending effort reinforcing and shoring up the current model, would it be better to expedite a more contemporary (and more secure) replacement that also supports higher data sharing conversion? The UK flows outlined in 4.3 could be a good starting point here.
4. The report rightly notes significant variability in data holder authentication implementations. This situation is unhelpful if we value a consistent UX as a contributor to overall regime trust. Perhaps some form of DH rating could be displayed for consumers to see. Similar to browser trust symbols used to highlight insecure websites, this might incentivise DHs (and ADRs) to comply with more secure data sharing practices.
5. Finally, a thought on the network of participants and the collective contribution this network could make to an enhanced overall security posture. As a means with which to combat larger-scale fraud and attacks, could CDR include inbuilt notification features? Could other participants be made aware of repeated failed authentication attempts at a DH, high numbers of sessions from a single source, enumeration attacks, or other behaviours considered outside of ‘normal’ bounds?"

We fully support all of the above comments from Rob.

The continued tolerance/allowance for use of screen scraping in conjunction with current CDR access standards in view of current data compromise/hacking must be addressed by an easier yet still secure and safe solution to that in CDR. That a blind eye to screen scraping in trying to boost participation by Adis and other prospective/current CDR participants is in conflict with other industry standards including e-payments code through consumers sharing their internet banking passwords must be stopped if we are going to build consumer confidence and usage.

The consumer supply of their username password for use in screen scraping, regardless if deemed consented is viewed as being enforced on them by lending entities who are viewed as the major current users of CDR. to enable them to obtain a home/loan lending. The consumer's confidence in this and CDR is and will be shaken by this week's events.

The proposals in relation to key management, certificate management, security endpoints, & registry endpoints are also supported as they contribute to making it simpler while still secure for current and prospective ADRs to seek and use participation in CDR and not alternative screen scraping entity options.

[CDR-API-Stream]

Thank you to all who provided feedback. This noting paper will now be closed with a decision by the Chair in response to the community feedback and the report's recommendations to be published in the near future.

[CDR-API-Stream]

The Data Standards Chair has now approved this decision. The decision record can be found in the original post.