CDR Data Holders outbound connection whitelisting

[AusBanking2]

The attached paper presents the ABA's concerns regarding outbound connection whitelisting and the proposed solutions. We request this matter be considered by the DSB and the CDR community.

211101 - CDR DCR paper - FINAL v.0.7.pdf

[nils-work]

I believe the paper attached above relates to issues outlined in this support ticket and issue #416.
and -
#409
#451

and now covered in ConsumerDataStandardsAustralia/standards#245

[ShaneDoolanFZ]

We are glad to see this is now being discussed as opposed to banks quietly taking unilateral and non-compliant action to impose Option One on ADRs, which is the current state of play with some Data Holders.

If the DSB wishes to introduce any automated solution to allow ADR domain allowed-listing to occur then Adatree is not at all opposed to it. Adatree also intends to implement automated outbound domain allow-lists in much the same way as Option Two is described because the Data Holder Brands endpoint makes Data Holder domains available to us.

Adatree is strongly opposed to Option One proposed. We understand that this is a typical process for APRA regulated institutions, but there are 83 (and counting) other APRA regulated institutions that are live and have managed to safely navigate not having this practice in place for the client registration endpoint. We are against the ecosystem slowing to accomodate a small minority who have not managed to navigate this requirement.

For ADRs, individual Data Holders are an implementation detail in a long list of automated CDR integrations. By allowing Data Holders to introduce a manual process where ADRs are expected to notify each one ahead of time that a POST or PUT DCR attempt is coming is an enormous overhead and will further slow down an ecosystem struggling for traction. If this were the case and each Data Holder that is currently active took the allowed-listing option proposed, and with the temporary Option One imposed, then ADRs would have to notify and track the progress of no less than 87 Data Holders (and counting). This will be further compounded when other sectors go live. The Data Holders I alluded to in issue #416 took up to a week to add our domains to their list. This is not an acceptable amount of time and effort for ADRs to spend accomodating either questionable Data Holder network implementations that have an inability to isolate a public interface, or the simple refusal by some institutions to add an exception to their infosec policy to accomodate CDR requirements.

This is a standard adopted by organizations (including many data holders) with mature security posture and it acts as an effective security control by mitigating against data exfiltration risk from Data Holder environment

If it is a case that there is sufficient isolation of the client registration endpoint from data exfiltration endpoints then Data Holders must feel dynamic client registration itself is inherently non-secure as a process and should outline in detail what aspects of it they are concerned with.

[dsbivan]

Thank you all for your input.

This topic will be added to the agenda of maintenance iteration 9 and we will discuss the following questions:

1. Why can’t the jwks_uri and sector_identifier_uri values published in the SSA be trusted without additional vetting?
2. What checks are performed against the jwks_uri and sector_identifier_uri to evaluate it meets a sufficient security score to be whitelisted?
3. Does this task require manual intervention or is performed on the fly?
4. If ADR hosted endpoint domains were exposed ahead of time prior to the registration process, what minimum timeframes are required to perform these checks / whitelisting?
5. How will the operational processes / CDR Register provide a transition process so as not to hinder accredited data recipients?
6. The jwks_uri and sector_identifier_uri have been identified during the registration process. What about other endpoints hosted by data recipients, e.g redirect_uris, recipient_base_uri? Are there any similar requirements for these front-channel endpoints?

This analysis should then seek to describe the following:

1. If identified, any changes to the registration process, either technical, operational or both
2. SLA for a proposed whitelisting process to minimise impact to registration
3. Validate that data recipients shouldn’t be unreasonably impacted by proposed approach
4. Validate that the identified approach addresses the highlighted security concern

[AusBanking]

Hi @ShaneDoolanAdatree and all others interested in this:

ABA would like to clarify couple of points on behalf of its members.

Option One is only suggested as an immediate and temporary solution which doesn’t require any additional effort from Data Recipients and Data Holders. The register would be notifying Data Holders as a part of onboarding process. This will solve the problem immediately for Data Recipients.

Option Two is the recommended option medium term and it does require register API changes. Hence we allow for some time for this to be designed and deployed.

All options are optional for Data Holders that don’t require network endpoint whitelisting.

All options decouple network endpoint whitelisting from dynamic client registration process and don’t impose any additional effort on Data Recipient side.

[CDR-API-Stream]

After some internal discussions within the DSB and with various stakeholders in the ACCC the proposed solution for this issue, for feedback and discussion in the call tomorrow, is as follows:

• In the short term we would add a note to the standards indicating that outbound whitelisting is an implementation choice for Data Holders to make but that all NFRs need to be adhered to with whatever solution is implemented. This effectively clarifies that manual whitelisting (or even slow automated whitelisting) is explicitly non-compliant with the standards
• We will initiate a Decision Proposal to continue consultation on this, as well as other issues related to DCR and the use of the Register APIs in general

This will clarify the position of the standards. For data holders that have an implementation that does not align with this position a conversation with the regulator would be needed. That would be the appropriate avenue to discuss option 1, as suggest in the ABA submission, as an interim solution until compliance is able to be achieved.

Note that the rationale for this is as follows:

• DCR is a critical enabler for ADR success and there should be no barriers or friction in this process as this could undermine the success of the CDR regime
• This minimises the obligations on the data holders and leaves them free to make contextual implementation decisions as long as they align with the NFR requirements of the standards (rather than mandating a specific implementation pattern)
• Discussion of this issue in general warrants a more visible consultation hence a Decision Proposal would be the appropriate path to find a long term resolution for the issue

[AusBanking]

Hi @CDR-API-Stream, As mentioned above, we are happy to comply with the NFR’s defined in the data standards (ie. for DCR 1000ms) however we request clarification as per Github 409 Dynamic Client Registration Response Time NFR how will external dependencies outside of the Data Holders sphere of control (eg. time spent calling Registry API) will be factored for the DCR NFR?

[CDR-API-Stream]

The standards have been updated to incorporate the following task:

In the short term we would add a note to the standards indicating that outbound whitelisting is an implementation choice for Data Holders to make but that all NFRs need to be adhered to with whatever solution is implemented. This effectively clarifies that manual whitelisting (or even slow automated whitelisting) is explicitly non-compliant with the standards

This change was incorporated into release v1.15.0. Refer to Decision 212 for further details.

[AusBanking]

In light of the recent security vulnerability known as log4Shell with a CVSS score of 10 (the highest-level severity score)
that drew global attention and remediation work, our members reported that the Outbound whitelisting is proven to be an effective control in limiting the impact initially as it will disrupt the remote code execution (RCE) flows involved in exploiting the vulnerability. Outbound connection whitelisting security control reduces the impact of vulnerabilities similar to log4Shell and minimise the risk of data ex-filtration by restricting outbound connections from internal servers to attackers command and control servers.

We would like to emphasize again that having unrestricted outbound internet access from the internal networks of the organisation poses serious security risks and we request the DSB to expedite the resolution of this issue.

[CDR-API-Stream]

Thank you all for your input on this topic.

DP 245 explores how Data Recipient information should propagate between Data Recipient Software Products, Data Holder Brands, and the CDR Register. One use case which has been explicitly called out is Whitelisting of Data Recipient
Software Product domains.

I'd encourage all participants to contribute to the conversation in DP 245 which will help define this future state.

This piece of work will be progressed through the decision proposal and not considered for Maintenance Iteration 11.

[nils-work]

As part of a backlog review in Maintenance Iteration 21, it was suggested that this issue could be closed.
If there are no further comments, this issue will be closed on 25 October 2024.