Mitigate Risk of Fraudulent Activities by Implementing Dual Authorization [Business Logic Issue]

[ImanSharaf]

One of the most critical security issues that can exist in high-value sensitive systems (for example, banking systems) is the lack of dual authorization for sensitive operations or transactions. This issue occurs when the application allows a single user to perform a sensitive action or transaction or action without requiring approval from another authorized user.

For example, suppose a bank's online banking application allows a single bank clerk to transfer a large amount of money to another account without requiring approval from another authorized user. In that case, this creates a significant risk of fraudulent activity. We can have a malicious insider that can perform the transaction without the need for a second person to approve it, potentially resulting in a significant loss of funds for the bank and its customers.

To prevent such scenarios, it is essential to implement dual authorization for sensitive transactions or operations in high-value sensitive systems. This means that the application should require approval from at least two authorized users before processing the transaction.

I would suggest this check:

• Verify that the application implements dual authorization for sensitive operations or transactions, requiring independent approval from multiple authorized users before processing.

[elarlang]

I'm not sure about this one.

If there is business risk, which requires approval from more than one person, then it suits.

But if there is no such business logical situation, we can not force technical solution to be used when it's not suitable.

[ImanSharaf]

I understand your concern. The proposed check is intended for situations where the application deals with sensitive operations or transactions that carry significant business risk (some L3s). It is not a requirement for all applications, but rather a recommendation for those where dual authorization would be a suitable and necessary security control.

The purpose of this check is to provide guidance for organizations that need to mitigate the risk of fraudulent activities in high-value sensitive systems. By implementing dual authorization in relevant scenarios, these organizations can ensure that sensitive operations are carried out with the necessary oversight and approval from multiple authorized users.

Here are some examples of scenarios in sensitive industries where dual authorization would be well-suited:

• Financial institutions: In banking systems, dual authorization can be used for approving high-value transactions, such as large money transfers, changes to customer account details, or adjustments to credit limits. This can help prevent fraud and unauthorized access to customer funds.

• Nuclear facilities: In the management of nuclear power plants or research facilities, dual authorization can be required for actions like the release of radioactive materials, changes to safety protocols, or the approval of maintenance operations. This can ensure that critical decisions are made with a higher level of scrutiny and oversight.

• Healthcare systems: Dual authorization can be implemented in hospital or medical record management systems for approving access to sensitive patient data or making significant changes to treatment plans. This can help safeguard patient privacy and ensure the accuracy of medical records.

• Government agencies: For sensitive operations in government systems, such as the approval of intelligence operations, access to classified information, or changes to critical infrastructure systems, dual authorization can provide an additional layer of security and oversight.

• Industrial control systems: In industries like oil and gas, power generation, or manufacturing, dual authorization can be used for approving changes to critical system configurations or initiating potentially hazardous processes. This can help prevent accidents and protect worker safety.

[elarlang]

It is not a requirement for all applications, but rather a recommendation for those where dual authorization would be a suitable and necessary security control.

This is the actual reason we should not have the requirement. We don't have recommendations, only requirements. And for that exact reasons we removed some authentication/password rules requirements as those were more recommendations and can not be fail-or-pass requirements.

As a requirement I think we over-manage it. For those rare application where it is actually needed I bet they have their own standards. In case they use ASVS as a base, they (can) fork it and add own standards. This is the valid use-case in my opinion for the recommendation and can be used as requirement for them, but not for everyone else by default.

[ImanSharaf]

I understand your point regarding the distinction between recommendations and requirements. However, I would like to draw your attention to some existing items in the ASVS that are not applicable to all applications, yet still exist as requirements. For example, items 6.1.1, 6.1.2, and 6.1.3 pertain to specific types of regulated data and may not be relevant for all applications.

In a similar manner, the proposed dual authorization check could be introduced as a requirement, with the understanding that it would only be applicable to certain types of applications dealing with high-value sensitive operations or transactions. To ensure clarity, we could explicitly mention in the requirement that it is only applicable to certain situations or industries where dual authorization is necessary.

This approach would allow organizations to determine whether the requirement is relevant to their specific application, and assess compliance accordingly. By including this requirement in the ASVS, we provide guidance for organizations that need to mitigate the risk of fraudulent activities in high-value sensitive systems, while still allowing flexibility for those applications where dual authorization is not needed.

[elarlang]

To validate that, it makes sense to get feedback from the potential users for the requirement. We can assume here together however many hours, it's still assumption without reality check.

So, for reality check, ping @danielcuthbert - maybe you have some experience and insights?

[ImanSharaf]

I appreciate the need for a reality check, and I can provide some context from my experience working with Canadian banks that the requirement for dual authorization is a necessary security control to mitigate the risk of fraudulent activities.

[tghosth]

So I think the 6.1.x requirements are relatively specific.

Even 3.7.1 (permalink) is relatively specific about when it is relevant.

I understand why you want to add a requirement like this. However, I think the sort of requirement you propose here would be highly subjective and hard to enforce or use as an easy to understand recommendation. I will leave this open for further comments but I am not sure I would support adding a requirement like this.

[tghosth]

Punting this to the business logic rework stage

[EnigmaRosa]

Could this be addressed under separation of duties?

[tghosth]

I'm glad that this popped up now as this also got sort of discussed here: https://github.com/OWASP/ASVS/issues/1437#issuecomment-1910451384

I know we talk about business logic vulnerabilities but my current thinking is that trying to require dual-authorization/separation of duties is problematic because when to do that is more of a business decision so I don't think we should be specifically mandating it. I also don't the ASVS can effectively mandate any specific "anti-fraud" controls because that will also depend on business context.

Any other thoughts?

[EnigmaRosa]

I agree with the language introduced by #1437 (comment), as it clearly specifies that this only applies where the functionality is supported. If you wanted to do something broader for sensitive functionality that isn't covered in 4.3.3, perhaps make a new requirement that is an L3 and something along the lines of

Verify that, if the application supports functionality that has been determined as sensitive by the business, such functions are protected by extra controls such as multi-user approval.

From experience, and in agreement with @ImanSharaf , I have seen applications where multi-user approval is needed for functionality central to the application, not related to configuration.

[tghosth]

I agree with the language introduced by #1437 (comment), as it clearly specifies that this only applies where the functionality is supported.

Ok so that language got integrated.

Verify that, if the application supports functionality that has been determined as sensitive by the business, such functions are protected by extra controls such as multi-user approval.

So once we start getting into application functionality, it raises a few questions for me:

• How easy to verify is this requirement?
• Who decides what is sensitive enough to require extra controls?
• Who decides what extra controls are appropriate (aside from multi-user approval).

Any thoughts @EnigmaRosa @ImanSharaf ?

[elarlang]

Just a note to:

Who decides what is sensitive enough to require extra controls? Who decides what extra controls are appropriate (aside from multi-user approval).

It does not matter who and when is doing it, but it must be analyzed and documented as a pre-condition and we have covered by requirements on (current) V1.8

V1.8 Data Protection and Privacy Architecture

#	Description	L1	L2	L3	CWE
1.8.1	[MODIFIED, MERGED FROM 8.3.4, LEVEL L2 > L1] Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data.	✓	✓	✓	213
1.8.2	[MODIFIED] Verify that all protection levels have an associated set of protection requirements and that these are applied in the architecture. This should include (but not be limited to) requirements related to encryption, integrity verification, retention, privacy and privacy-enhancing technologies to be used, and other confidentiality requirements.		✓	✓

[ImanSharaf]

I agree with the language introduced by #1437 (comment), as it clearly specifies that this only applies where the functionality is supported.

Ok so that language got integrated.

Verify that, if the application supports functionality that has been determined as sensitive by the business, such functions are protected by extra controls such as multi-user approval.

So once we start getting into application functionality, it raises a few questions for me:

• How easy to verify is this requirement?
• Who decides what is sensitive enough to require extra controls?
• Who decides what extra controls are appropriate (aside from multi-user approval).

Any thoughts @EnigmaRosa @ImanSharaf ?

It works for me.

[jmanico]

I'm not entirely sure if we should include this in, although I'm inclined to enhance the business logic section as suggested. Elar's observation that we only have requirements, not recommendations, is valid and adds to my uncertainty. However, I'm somewhat leaning towards incorporating it anyways.

[elarlang]

Just note we also have requirement:

#	Description	L1	L2	L3	CWE
4.3.3	[MODIFIED] Verify that, if the application allows changing highly sensitive configurations around passwords or connection parameters for integrations with databases and third-party systems, they are protected by extra controls such as re-authentication or multi-user approval.		✓	✓	732

[jmanico]

Good point Elar. I think this mention of multi user approval is enough for ASVS and we can drop it for the business logic section.

[tghosth]

I think this becomes a little too prescriptive and specific as I have said above.

@EnigmaRosa previously suggested:

Verify that, if the application supports functionality that has been determined as sensitive by the business, such functions are protected by extra controls such as multi-user approval.

I just wanted to reiterate my concern from above which was that once we start getting into application functionality, it raises a few questions for me:

• How easy to verify is this requirement?
• Who decides what is sensitive enough to require extra controls?
• Who decides what extra controls are appropriate (aside from multi-user approval).

Any thoughts @EnigmaRosa?

[EnigmaRosa]

I believe that the extra controls and what necessitates them would be included in the application documentation (perhaps within nonfunctional security requirements, for example). Of course, this requires us to assume that the developers have put sufficient consideration to the sensitivity of application functions and the appropriate controls.

Addressing @tghosth's concerns one by one (but not in order)

Who decides what is sensitive enough to require extra controls?

I'm inclined to include some sort of definition/guidance/list of sensitive functionality + "and other functions deemed sensitive by the business". Otherwise, we either have to say it is entirely up to the devs or to the verifier - but this is entirely subjective IMO, and shouldn't be done.

Who decides what extra controls are appropriate (aside from multi-user approval).

We could perhaps provide a list of controls to match the provided sensitive functionality list, but, again, this gets really subjective really quickly.

How easy to verify is this requirement?

You'd need documentation review + penetration testing for this, so not super difficult. Unless you're verifying that they chose the right control, in which case...see my subjective comments.

[ImanSharaf]

• Who decides what is sensitive enough to require extra controls?

My concern was around fintech related apps, specially banks, to avoid frauds.

[elarlang]

I believe that the extra controls and what necessitates them would be included in the application documentation (perhaps within nonfunctional security requirements, for example). Of course, this requires us to assume that the developers have put sufficient consideration to the sensitivity of application functions and the appropriate controls.

I'm inclined to include some sort of definition/guidance/list of sensitive functionality + "and other functions deemed sensitive by the business". Otherwise, we either have to say it is entirely up to the devs or to the verifier - but this is entirely subjective IMO, and shouldn't be done.

We could perhaps provide a list of controls to match the provided sensitive functionality list, but, again, this gets really subjective really quickly.

Maybe it is just a question of terminology, but developers are just implementing it. It must be done during the analysis step and we have requirements for that. I already pointed it out here: https://github.com/OWASP/ASVS/issues/1576#issuecomment-1927008339

[tghosth]

Thanks for the responses @EnigmaRosa :)

I believe that the extra controls and what necessitates them would be included in the application documentation (perhaps within nonfunctional security requirements, for example). Of course, this requires us to assume that the developers have put sufficient consideration to the sensitivity of application functions and the appropriate controls.

So maybe a pair of a documentation requirement in V1 and a specific requirement somewhere else...?

I'm inclined to include some sort of definition/guidance/list of sensitive functionality ... We could perhaps provide a list of controls to match the provided sensitive functionality list.

So it feels like your answer to my original questions of "Who decides what is sensitive enough to require extra controls?" and "Who decides what extra controls are appropriate (aside from multi-user approval)" would be us as the ASVS authors, have I understood correctly?

Do you think it is practical to come up with a sufficiently comprehensive list of specific examples of functionalities and controls that would allow us to be prescriptive?.

The alternative is to leave it as a requirement that they had to have thought about this, documented their decisions and then implemented what they said they should do without being opinionated about the outcome. Although, at that point, it feels like maybe we are just providing a recommending something rather than mandating a particular outcome.

What do you think?

Maybe it is just a question of terminology, but developers are just implementing it. It must be done during the analysis step and we have requirements for that. I already pointed it out here: https://github.com/OWASP/ASVS/issues/1576#issuecomment-1927008339

@elarlang I think the gap here is that those requirements talk about sensitive data but not explicitly sensitive funcitonality.

[elarlang]

For sensitive functionality, we have 4.3.3, see https://github.com/OWASP/ASVS/issues/1576#issuecomment-2097681392. It can be fine-tuned if needed, or what is the not-covered aspect at the moment?

[tghosth]

For sensitive functionality, we have 4.3.3, see https://github.com/OWASP/ASVS/issues/1576#issuecomment-2097681392. It can be fine-tuned if needed, or what is the not-covered aspect at the moment?

We deliberately made that requirement focus on things that sensitive from a technical perspective (and therefore easier to mandate centrally) rather than a from business perspective (which will vary per application).

[tghosth]

I am going to leave this open for now whilst also merging the V11 rework PR as it has been open for a long time

[EnigmaRosa]

I definitely saw additional documentation being part of this, like @tghosth mentioned

The alternative is to leave it as a requirement that they had to have thought about this, documented their decisions and then implemented what they said they should do without being opinionated about the outcome.

But then you get the issue of verifying that they thought "correctly" about it (i.e. did they consider the expected/appropriate controls?), which brings it back to the "who makes the decision?" question.

Ultimately, I feel like there should be some sort of appendix involved so we can go into more detail that what could be contained in a normal requirement.