Need cleanup of 4.3.1 - suggest simplifying

[jmanico]

We already cover MFA elsewhere, this should really be about isolation admin interfaces or other topics.

4.3.1	Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.

[cmlh]

I just did a search for "MFA" in the 4.0.2 PDF and it's not directly specified as a requirement @jmanico but is mentioned six (6) times in the 4.0.2 PDF

Should we just remove the the strikethrough text as "Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use." or something else?

[elarlang]

I just did a search for "MFA" in the 4.0.2 PDF and it's not directly specified as a requirement @jmanico but is mentioned six (6) times in the 4.0.2 PDF

In general, if you do search for improvement bleeding edge version, then it makes sense to use bleeding edge materials. v4.0.2 is released year ago and does not contain year of changes.

Should we just remove the the strikethrough text as "Verify administrative interfaces ~use appropriate multi-factor authentication to~ prevent unauthorized use." or something else?

== Verify administrative interfaces prevent unauthorized use.

What is the goal or message of this requirement? This sentence ("prevent unauthorized use") should be covered by other V4 requirements and do not give anything extra.

The goal here, like Jim mentioned, should be - administration interfaces should be isolated. Additionally to MFA, there are a lot of other options, like "it should be not available to public internet - available only from internal network or requires VPN".

[jmanico]

How about this?

4.3.1	Verify administrative interfaces are isolated from the main application by deploying administrative interfaces on a separate domain, or by only allowing intranet access, in order to prevent unauthorized use.

[cmlh]

In general, if you do search for improvement bleeding edge version, then it makes sense to use bleeding edge materials. v4.0.2 is released year ago and does not contain year of changes.

I couldn't find a daily build of the PDF or view of the Markdown in its entirety, can you send me the link @elarlang please?

[elarlang]

@cmlh - are you serious or you are just trolling here?

We work here with markdown, in github. Your build is when you open a browser and/or make git pull.

If you really like PDF, it should be possible to use new solution with makefile and generate it for yourself (I have not tried it myself).

[elarlang]

Verify administrative interfaces are isolated from the main application by deploying administrative interfaces on a separate domain, or by only allowing intranet access, in order to prevent unauthorized use.

It's complicated one, some first points:

• It does not matter where they are deployed, it matter, from where and for whom it is accessible
• separate domain does not give too much extra if it's still opened to the internet

[jmanico]

How about this? Nice and simple.

4.3.1	Verify administrative interfaces are isolated from the main application in order to prevent unauthorized use.

[cmlh]

We work here with markdown, in github. Your build is when you open a browser and/or make git pull.

https://github.com/search?q=MFA+in%3Afile+repo%3AOWASP%2FASVS&type=Code searches for MFA in the default branch @elarlang

[jmanico]

How about this? Nice and simple.

4.3.1 Verify administrative interfaces are isolated from the main application in order to prevent unauthorized use.

Can I get comments on this? If not, I'm going to go for this and PR my suggestion.

[jmanico]

In general, if you do search for improvement bleeding edge version, then it makes sense to use bleeding edge materials. v4.0.2 is released year ago and does not contain year of changes.

I couldn't find a daily build of the PDF or view of the Markdown in its entirety, can you send me the link @elarlang, please?

@cmlh I tend to just work with the markdown and use sublime text's multi-file search or similar.

[cmlh]

Can I get comments on this? If not, I'm going to go for this and PR my suggestion.

If you don't have the time I can submit the PR on your behalf @jmanico ?

[jmanico]

Give me just a little more time to get feedback. I also want to give @elarlang a chance to get 4.0.3 out the door so there is no hurry on this one. Thank you thou!

[elarlang]

Verify administrative interfaces are isolated from the main application in order to prevent unauthorized use.

Not ready for PR, but I don't know at the moment, how to improve it.

We need to declare, what this "isolated" is - otherwise it is not possible to take any clear action to verify that. Some may say, that authentication for admin interface is isolation, or extra basic auth is isolation etc.

The goal at the moment should not to simplifying it, it is simple enough. At the moment the problem is, it gives only one allowed way (MFA) for isolation. In my opinion we need to give other "accepted" solutions as well.

[starbuck3000]

Hello, just noticed you posted this link in Twitter. Much better to discuss here indeed.

I see two issues in the proposition "Verify administrative interfaces are isolated from the main application in order to prevent unauthorized use.":

1. The term "isolated" scores very high in my "list of highly ambiguous terms" :). It could lead teams weakening their deliverables just to be compatible with this control. A good example is the case where a team creates separate URLs/entry-points for the higher-administrative interfaces but neglects to maintain the same level of security to both interfaces. I would suggest clarifying the term "isolation" in a way that whoever reads this control concludes on the same action (i.e. repeatability criterion). For example, do we want network isolation? Memory space isolation? Code isolation? At what point should the auditor accept the control as implemented?
2. The second issue is that the control seems to invoke some causality that is yet to demonstrate ("in order to prevent unauthorized use"). Isolating the admin interface from the production interface does not prevent unauthorized access (as I understand it). It could obviously help mitigate some threats, definitely, but it does not result in "preventing unauthorized use". Generally, I would always suggest removing anything that looks like "in order to prevent" when writing controls.

Hope it helps, cheers.

[ike]

This might be too spicy, but I think this should just be removed. I do think separation of administration is super important, but there should be more specific guidance at each particular layer.

For example (and some already exist): separation of admin interface URLs, separation of privileged API URIs; separation of public-facing endpoints from infrastructure administration endpoints; and separating development, staging, and production environments.

I am not sure that genericising this requirement actually conveys the intent properly.

[elarlang]

This is one requirement which I have used in pen-tests and I can see value here.

It sends clear message, that admin interfaces should not be opened to everyone with just username-password authentication.

This is really how to take down the risk - impact * likelihood:

• Vulnerability in admin interfaces gives huge impact
• Isolating / taking it away from public internet / adding extra layer of authentication takes down the likelihood

I think ASVS should send the message and verification point - is this likelihood decreased?

If we fail to improve requirement with more clear intent and goal, we should not delete it because we failed (to do it fast). I'm more happier this requirement stays like it is than it does not exist.

[jmanico]

Thank you, Elar.

"Isolation" options I've seen discussed so far:

1) MFA forced on Admins. Already covered in 2.2.9 2) Do not mix admin functionality with other functionality, ensure they are different features even if they have the same functionality at different role levels 3) Force intranet access on admin access, do not allow internet access to admin functionality 4) Isolate admin apps to different subdomains or domains and/or ports 5) Ensure admin user authentication database is isolated from other user authentication databases for password verification and similar

[coderpatros]

I think it does need to be more prescriptive than just "Verify administrative interfaces are isolated from the main application in order to prevent unauthorized use."

Unfortunately I can't think of a succinct way to represent it though.

[starbuck3000]

Thank you for clarifying "isolation", it shows that it may include many scenarios, some of which are already addressed through other controls.

What do you think of this one? 4.3.1 - Verify administrative interfaces only accept connections from trusted endpoints (e.g., admin workstation, bastion/jumphost, etc.).

• It is not vulnerable to the "isolation" ambiguity,
• It solves one big problem we are trying to address: access to admin interfaces from anywhere / untrusted systems,
• It is acceptable / feasible / verifiable,
• It is a generally approved practice by the community.

[elarlang]

Nice brainstorm and interesting proposal @starbuck3000 . But for me we change definition of "isolation" to definition "trusted endpoint".

I also would like to just put Jim's definitions of isolation as a list of examples to the requirement.

Both cases, we need list of expected solutions. It may make verification requirement long(er) and I'm completely ok (if to not say happy) with that - at least it's clear and understandable, what it means, without some extra guess-work for everyone.

Actually, this term "administrative interfaces" itself is also not always that clear :)

[jmanico]

administrative interfaces = a series of user interface screens and server-side functionality that supports traditional administration level features such as creating new users, assigning users to access control levels, editing live content on a site, and similar privileged actions.

Admin isolation is when the UI and back end Admin level features are somehow separate from other non admin functionality.

[jmanico]

After considering @starbuck3000 how about:

4.3.1 - Verify administrative interfaces only accept connections from trusted endpoints (e.g., admin workstation, bastion/jumphost, separate domain, intranet access only, etc).

[starbuck3000]

@jmanico : yes, looks all good to me.

p.s. Just a little period (.) missing after the 'etc' :)

[jmanico]

Hey @elarlang is this ok with you?

4.3.1 - Verify administrative interfaces only accept connections from trusted endpoints (e.g., admin workstation, bastion/jumphost, separate domain, intranet access only, etc.).

[mgargiullo]

@jmanico I liked your list of possible solutions with "accept connections from trusted endpoints" as one of the options.

[jmanico]

How about this one?

4.3.1 - Verify administrative interfaces only accept connections from trusted endpoints. Examples include using a bastion or jump host, limiting access to only admin workstations, providing admin functionality on a separate domain from other users, or only allowing admin access via an intranet.

[tghosth]

hi @jmanico, the suggestions says "providing admin functionality on a separate domain from other users" (assuming we are talking about a web domain like https://admin.example.com). Do you think that is an example of "only accept connections from trusted endpoints."? It feels like there is a mis-match between those two things...

[jmanico]

How about...

4.3.1 - Verify administrative interfaces are isolated from the main application and only accept connections from trusted endpoints. Examples include using a bastion or jump host, limiting access to only admin workstations, providing admin functionality on a separate domain from other users, or only allowing admin access via an intranet.

[cmlh]

Can insert a clarification where 4.3.1 excludes management of a team account i.e. multiple user accounts as I'd assume this is the management of the SaaS application itself, including hosted cloud infrastructure?

[tghosth]

@jmanico

Minor modification to change "and" to "or":

4.3.1 Verify administrative interfaces are isolated from the main application or only accept connections from trusted endpoints. Examples include using a bastion or jump host, limiting access to only admin workstations, providing admin functionality on a separate domain from other users, or only allowing admin access via an intranet.

@cmlh:

Can insert a clarification where 4.3.1 excludes management of a team account i.e. multiple user accounts as I'd assume this is the management of the SaaS application itself, including hosted cloud infrastructure?

I am not sure I understand what you mean.

[cmlh]

Might be hard to explain if we don't have defined DevOps roles for ASVS so I'll drop this suggestion for the moment @tghosth

[tghosth]

@jmanico do you agree with my minor change here: https://github.com/OWASP/ASVS/issues/1086#issuecomment-1195694482

[elarlang]

Reason for "keep the and" and do not use or. Even if you accept connections only from trusted endpoints then:

• in "XSS" situation those are on the same Origin and vulnerability most likely gives options to escalate to higher privileges functionality
• for accessing resources via API/DB/etc accounts it gives danger that "public web site" uses same level permissions as administrative part of the site. It is more secure to keep them separately with separate accounts and permissions for internal/external resources

"or only allowing admin access via an intranet" - limiting access only to intranet is takes down some likelihood, but on the other hand it is a bit in conflict with Zero Trust philosophy (NIST Special Publication (SP) 800-207, Zero Trust Architecture). ZTA does not say "do not use intranet", but just "don't relay on it"

[jmanico]

@jmanico do you agree with my minor change here: #1086 (comment)

This change looks good to me.

[jmanico]

Reason for "keep the and" and do not use or. Even if you accept connections only from trusted endpoints then:

• in "XSS" situation those are on the same Origin and vulnerability most likely gives options to escalate to higher privileges functionality
• for accessing resources via API/DB/etc accounts it gives danger that "public web site" uses same level permissions as administrative part of the site. It is more secure to keep them separately with separate accounts and permissions for internal/external resources

"or only allowing admin access via an intranet" - limiting access only to intranet is takes down some likelihood, but on the other hand it is a bit in conflict with Zero Trust philosophy (NIST Special Publication (SP) 800-207, Zero Trust Architecture). ZTA does not say "do not use intranet", but just "don't relay on it"

This is a good argument, Elar. I'm personally ok with "and" or "or". I prefer and. Or what you prefer. Either-or works for me.

[tghosth]

Ok I opened a PR with "and"

[elarlang]

I approved/merged PR, but ...

"Verify administrative interfaces are isolated from the main application ..."

I wonder is clear and actionable - like what mean "isolated from the main application"?

[tghosth]

Would you prefer something like:

Verify that administrative interfaces are logically separated from the main application

That is still vague but it gives slightly more direction whilst still allowing flexibility.

[starbuck3000]

Reading this one year after my previous comment, I still suggest removing the isolation/separation part.

Isolation (whatever it means) is an architecture/design pattern that can be implemented in response to a security requirement, it is not a security requirement by itself, unless we start telling the world how applications should be designed.

It seems to me that this discussion arises from the ambiguity I often observe in security specifications on what constitutes unauthorized access to an administrative interface. If we compare this with a door lock: I cannot tell from our discussion whether we are trying make sure that a door lock cannot be bypassed/breached by intruders, or whether we are trying to prevent intruders from reaching the lock that holds access to the asset.

In the first case, there is no causation at all for isolation: a security control focused on ensuring that any interaction to an administrative interface undergoes proper access control (triple A, or authenticate / authorize / audit) is sufficient, isolation doesn't bring anything more.

If the second scenario is our concern, there is some causation for isolation. But "isolation" is only one of many possible design options: an architect could also choose to require a trusted IP origin, or to extend authentication to the client endpoint/device itself, to enforce hardware security key authentication, etc. "Isolation" is only one possible response to the threat we are trying to address. As such, I think it should not be part of the requirement but part of the possible answers to the requirement, i.e., listed as one of many possible answers.

I strongly believe that one of main ASVS's strengths resides in its agnostic approach to application design. It is rather through the evaluation of a design proposal that one should assert whether or not the proposal satisfies the ASVS requirement, whatever it looks like.

Consequently, my proposition: 4.3.1 - Verify administrative interfaces can only be logically reached from trusted endpoints or locations. Examples include restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc..

First, this proposition acknowledges a design based on isolation, but also acknowledges other design proposals, which may satisfy the base requirement. Second, this proposition gets rid of the ambiguity behind "unauthorized access" (which is typically addressed through proper access control) by using the concept of "trusted" endpoints and networks.

[tghosth]

So I like your proposal @starbuck3000. I agree that it is better focused on the actual issue here. I would just make very minor alterations:

4.3.1 - Verify administrative interfaces can only be logically accessed from trusted endpoints or locations. For example, restricting access to bastion or jump hosts, trusted admin workstations or endpoints (e.g., device authentication), administrative LANs, etc..

@starbuck3000 any other comments

@elarlang do you agree with the change? I think it is also less ambiguous

[starbuck3000]

Thank you @tghosth for your review and improved version, all good for me!

[tghosth]

Opened #1407, @elarlang please review :)