Clarification: 2.4.2 "realistic human timing"

[ajayojha]

Verify that business logic flows require realistic human timing, preventing
excessively rapid transaction submissions.

I have few questions:

1. Is realistic human timing is defined anywhere?
2. How this is testable?
3. How application react when the tests(E2E, etc) are runs through CI/CD automation?

[elarlang]

Please (re)read the concept of documented security decisions: https://asvs.dev/v5.0.0/What-is-the-ASVS/#documented-security-decisions

1. Is realistic human timing is defined anywhere?

It is expected that the required values (realistic human time per flow) are analyzed and documented via the requirement:

#	Description	Level
2.1.3	Verify that expectations for business logic limits and validations are documented, including both per-user and globally across the application.	2

2. How this is testable?

How it is not?

3. How application react when the tests(E2E, etc) are runs through CI/CD automation?

This is up to the implementation of how to solve that. Anti-automation defence can not be ignored because "otherwise my CI/CD does not work".

[ajayojha]

Please (re)read the concept of documented security decisions: https://asvs.dev/v5.0.0/What-is-the-ASVS/#documented-security-decisions

Thanks for sharing this link, In the document the 'session timeout' example is bit different than the reported concern.

It is expected that the required values (realistic human time per flow) are analyzed and documented via the requirement:

The "business logic limits" and "business logic flows require realistic human timing" both are different, As far as I know the business logic limits can be controlled but business logic flows require realistic human timing is difficult to address.

How it is not?

Without a defined baseline, it isn’t possible to test. If you can share references where top organizations require “realistic human timing” for business-logic flows in their security practices, that would help to correct my understanding.

This is up to the implementation of how to solve that.

I may find the solution once you share the relevant reference links which i have asked in my previous paragraph.

What is the security objective of V2.4.2 beyond what V2.1.3 already covers?

[elarlang]

I described the concept, how the requirements are organized - there is a documented security decision that defines realistic human time for certain UI flow, and then you can test against it.

That is the "baseline definition". I don't think there is a need to search for how someone has implemented it.

What is the security objective of V2.4.2 beyond what V2.1.3 already covers?

Again, the concept of documented security decisions I referred to and recommended reading. There are "documented security decision" + "verification from implementation" combinations.

2.1.3 is a security decision requirement - you need to have the analysis and decision made; without that, you can not implement or test related requirements.

2.4.2 is a requirement to verify limits from the implementation, based on 2.1.3 documented security decisions.

[ajayojha]

"certain UI flow"

Why only certain UI flows? The way the requirement is written, it appears to apply to the whole application, so I’m assuming its scope is broader than just a few specific flows.

That is the "baseline definition". I don't think there is a need to search for how someone has implemented it.

I am not asking you to provide an implementation or solution. I am trying to understand whether this is actually recognised as a security practice in the industry:

1. How many major organizations are using “realistic human timing” as a security control ?
2. Which external references, or guidance, did the ASVS team rely on when drafting this requirement?

Without that context, it is hard to understand the importance of this requirement

based on 2.1.3 documented security decisions.

The problem I have is that there is no information or guidance on how those security decisions should be made in this specific area.

Here are few points which I need inputs:

1. Documented decisions are good, but it's doesn't solve the ambiguity in the requirement wording.
2. My CI/CD scenario seems to have been misunderstood. Every modern application has E2E tests/specs running in pipelines, and these flows are inherently non-human in timing. We cannot compare “human vs machine” execution for test pipelines, so it’s not clear how this requirement should be interpreted for those cases.
3. There are many real-world variations in user behaviour and environment. For example:
   a. User A on high-speed fibre.
   b. User B on a slow 3G connection.
   c. User C on a mobile device with average network conditions.
   All three are exhibiting “realistic human timing” from their own context. It’s not feasible to define a single universal numeric threshold that works across all of these edge cases and still claim it is “realistic” for everyone.

For clarity, it would be very helpful if you could share any reference material that the ASVS team used when documenting this requirement.

[elarlang]

Whatever is done outside of ASVS is out of scope for me here. The requirement originates from a previous version, and I don't know what the background was for it back then. For me it makes sense without the need to investigate how "the industry" has implemented it.

It is an L3 requirement and therefore it is a defense-in-depth requirement.

[ajayojha]

The security objective of this requirement is still not clear

For me it makes sense

I strongly believe that individual opinion isn’t sufficient without some concrete evidence that others can rely on.

The requirement originates from a previous version

Will wait for @jmanico comment on this, whenever he is available.

It is an L3 requirement and therefore it is a defense-in-depth requirement.

clear behaviour to verify missing even it's defense-in-depth .

[jmanico]

First of all I want to acknowledge that @elarlang is acting very professional is all of his responses to you and I support what he is saying. ASVS is meant to be high-level and not get into the deep implementation details for every requirement.

At the same time, you're request that we make some of these requirements more clear is helpful. I value the opinions of senior developers like yourself a great deal.

So let me reply to the original post:

"Verify that business logic flows require realistic human timing, preventing excessively rapid transaction submissions."

This is a perfect L3 attack to address automated bots/malware like Zeus from making forged transactions. And frankly, it's old school. This is a classic anti-automation / anti-fraud / anti-abuse control that sits in business logic layers especially at banks.

If you like, I can give you details on how to easily implement the foundations for this control.

But do support all of Elar's comments and think this is a perfect L3 requirement.

How else do you think we can make it better?

[ajayojha]

First of all I want to acknowledge that @elarlang is acting very professional is all of his responses to you

Totally agree and I really appreciate. Thanks to @elarlang and ASVS team.

ASVS is meant to be high-level and not get into the deep implementation details for every requirement.

My focus is on references which ASVS team has considered while drafting this requirement not on implementation details.

If you like, I can give you details on how to easily implement the foundations for this control.

Yes, please. I would be very happy to understand the “how” part, specially in the context of modern applications.

How else do you think we can make it better?

From my perspective, modern systems rely more on ML-based risk scoring, behavioural analytics etc., rather than on the concept of “realistic human timing.”
For example, I live in India and can transfer money to someone’s account in about 1–4 seconds via UPI apps. That makes it hard to define any universal “realistic human timing” value in code that would work across different systems and use cases. if you can share some references which corrects my understanding

This is why I am asking for references to correct my understanding.

[elarlang]

There is no "universal human timing". Timing must be analyzed for each flow that is done via UI. If machine-to-machine flow is used, there is no human involved and no need for a "realistic human timing".

[jmanico]

I once wrote a banking website for a very wealthy prince who wanted his own private bank. This guy had pet lions and insisted on on-site meetings. I was never comfortable having feature meetings with a lion or two walking around. But I digress.

In the database we had a very simple table with a "action-id", "timestamp" and "user-id".

We recorded every action. First hit to the website, hitting the login page, the login process, viewing account data, every transaction and more. So we were not measuring time for one transaction. We measured time of each step of the entire user sequence.

We could easily tell in these sequences if it was man or machine. Weak automated attacks jumped out at us. Stronger automated attacks from malware like Zeus added timing delays, but we used basic statistical analysis to see that the time delays were not random or the steps were too precise - human sequences have a lack of precision that can be hard for automation to emulate.

If I was building this today I would do the same - but also use ML to analyze the sequences.

It's late for me and I'm on my phone. But is this enough to get you started with this kind of feature?

I sincerely think it's an important and well worded L3 requirement.

[ajayojha]

Thanks Jim sharing the information.

I agree with the goal (blocking automated/malware transactions). My concern is that the current wording around “realistic human timing” is ambiguous and could push implementers toward incorrect designs. It's good to focus on flow integrity plus behavioral/risk analysis would be more verifiable across architectures.

If I had to implement this (The use-case Jim has shared) today, I would use anti-replay/sequence tokens combined with ML-based behavioral analysis, rather than custom “realistic human timing” check. Custom timing analysis is buggy. I can share failure cases and more details on the token approach if you would like.

There is no "universal human timing".

@elarlang I have used the word of "universal" and this means to minimum verification time define at global application level.

If machine-to-machine flow is used, there is no human involved and no need for a "realistic human timing".

How this is feasible in modern architecture where client-side frameworks and server-side frameworks are different. The same backend API's are accessed from the browser and from the end clients machines.

[elarlang]

Anti-replay and sequence is a completely different problem and it is addressed by v5.0.0-2.3.1.

On the topic, v5.0.0-2.4.1, there have been clear feedback from 2 leaders, that the current requirement is ok as it is and without seeing any valid and on topic opposing evidence, I close the issue.