ASVS
ASVS copied to clipboard
OWASP
Need cleanup of 4.3.1 - suggest simplifying
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. |
|---|
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?
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".
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. |
|---|
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 - 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).
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
How about this? Nice and simple.
| 4.3.1 | Verify administrative interfaces are isolated from the main application in order to prevent unauthorized use. |
|---|
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
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.
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.
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 ?
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!
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.
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.":
- 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?
- 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.
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.
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.
Thank you, Elar.
"Isolation" options I've seen discussed so far:
- MFA forced on Admins. Already covered in 2.2.9
- Do not mix admin functionality with other functionality, ensure they are different features even if they have the same functionality at different role levels
- Force intranet access on admin access, do not allow internet access to admin functionality
- Isolate admin apps to different subdomains or domains and/or ports
- Ensure admin user authentication database is isolated from other user authentication databases for password verification and similar
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.
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.
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 :)
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.
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).
@jmanico : yes, looks all good to me.
p.s. Just a little period (.) missing after the 'etc' :)
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.).
@jmanico I liked your list of possible solutions with "accept connections from trusted endpoints" as one of the options.
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.
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...
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.
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?
@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.