search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.67k stars 648 forks source link

Scope for 5.0 and beyond #1127

Closed jmanico closed 1 year ago

jmanico commented 2 years ago

We know that ASVS is for Web Apps, but how far do we go? Do we include DevOps principles? infrastructure management? Laptop security?

jmanico commented 2 years ago

I think once we start talking about to how to setup dev's laptops we have gone too far.

elarlang commented 2 years ago

More fuel to the topic - re-define levels

jmanico commented 2 years ago

I think the levels should be RISK-BASED and absolutely not TESTABILITY BASED

mgargiullo commented 2 years ago

@jmanico I completely agree. That's how I explain it to our clients and how we test against it. Even with the current 4.0.x Level 1 assessment, there are items that are better understood via discussion and review of artifacts than test results.

Quick example: 2.1.7 (passwords checked against breach list, etc...) testing isn't 100% accurate here. I'd rather have a quick conversation with the client/dev and know for sure how it's handled.

cmlh commented 2 years ago

I think the levels should be RISK-BASED and absolutely not TESTABILITY BASED

I'd like to revert to the level of effort of ASVS v1/2009 to align with Common Criteria

I think once we start talking about to how to setup dev's laptops we have gone too far.

Also align to the following where applicable.

elarlang commented 2 years ago

@cmlh - instead of putting quite often "align this and that" comments, can you work them through, analyze them and provide arguments, WHY we should align with them? What something gives or give not?

Clear proposals please, not "align with the internet" from issue to issue.

danielcuthbert commented 2 years ago

One of the major things for me at least with 5.0 is that of usability. A standard, or indeed anything really, is only good when people can use it easily without needing manuals to grok how it all works and I feel that after 14 years and 4 main releases, we need to put ease of use at the front as much as we do the approach, be it risk or testability, format, etc.

I'm a fan of https://mvsp.dev/ in that it is simple to understand and therefore use but as @jmanico said at the start, the world we live in has changed drastically compared to when V1 of the ASVS came out and indeed V2 and 3. The Internet today isn't as simple anymore, we aren't Apache/NGINX --> MySQL and a handful of web languages anymore and this is where I see efforts like https://github.com/OWASP/owasp-masvs & https://owasp.org/www-project-samm/, https://owasp.org/www-project-cyclonedx/, and many others now as vital as the ASVS and the need for collaboration more important than ever before.

It's easy to say 'align to X' but in reality, there are so many X's that this could very quickly turn into an unmanageable mess. I think what we need to do is find out from the community at large as to what they would find useful.

mjang-cobalt commented 2 years ago

From the perspective of a Technical Writer, usability is closely related to readability. Security docs are notoriously dense. I think we can include tools like Vale to incorporate standards like:

moshe-apiiro commented 2 years ago

makes sense @danielcuthbert - maybe the question is what is the equilibrium point between usability and too-complex/rigorous guidance that will make the practitioner to come back to the rulebook like it's a rolemaster companion. I am assuming here that "easy to understand" is prone to more open interpretation.

Coming back to the topic of scope, personally, I would love to see ASVS scope:

jmanico commented 2 years ago

I read the MASVS very carefully - and it's amazing and much much better to understand than ASVS.

I really think we want to make 5.0 more like MASVS in its clarity and push the complexity of ASVS to the appendix.

jmanico commented 2 years ago

Section V4: Authentication and Session Management Requirements of MASVS is much much more sensible and usable than what we currently have in ASVS.

4.1 | MSTG-AUTH-1 | If the app provides users access to a remote service, some form of authentication, such as username/password authentication, is performed at the remote endpoint. | x | x 4.2 | MSTG-AUTH-2 | If stateful session management is used, the remote endpoint uses randomly generated session identifiers to authenticate client requests without sending the user's credentials. | x | x 4.3 | MSTG-AUTH-3 | If stateless token-based authentication is used, the server provides a token that has been signed using a secure algorithm. | x | x 4.4 | MSTG-AUTH-4 | The remote endpoint terminates the existing session when the user logs out. | x | x 4.5 | MSTG-AUTH-5 | A password policy exists and is enforced at the remote endpoint. | x | x 4.6 | MSTG-AUTH-6 | The remote endpoint implements a mechanism to protect against the submission of credentials an excessive number of times. | x | x 4.7 | MSTG-AUTH-7 | Sessions are invalidated at the remote endpoint after a predefined period of inactivity and access tokens expire. | x | x 4.8 | MSTG-AUTH-8 | Biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore. |   | x 4.9 | MSTG-AUTH-9 | A second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. |   | x 4.10 | MSTG-AUTH-10 | Sensitive transactions require step-up authentication. |   | x 4.11 | MSTG-AUTH-11 | The app informs the user of all sensitive activities with their account. Users are able to view a list of devices, view contextual information (IP address, location, etc.), and to block specific devices. |   | x 4.12 | MSTG-AUTH-12 | Authorization models should be defined and enforced at the remote endpoint. | x | x

tghosth commented 2 years ago

My feeling is that ASVS has historically been primarily about designing and writing applications. There is also OpenSAMM which comes to provide guidance on the processes around developing software.

However, in the last few years there has been a significant rise in what I tend to call "application infrastructure". I think that sort of falls in between those two areas and covers aspects of development environment security and DevOps process and CI/CD security. My inclination is not to include those in the scope of ASVS.

Having said that, I think things like compilation settings and dependency security are close enough to the "designing and writing applications" that they are and should continue to be included although I am open to feedback on that.

At this point, I think our main priority needs to be to get an effective ASVS 5.0 out which aligns with the original ASVS scope but in a far more usable way.

tghosth commented 2 years ago

This issue has been open for a while and kinda of went off track.

I think my summary would be that we should be prepared to include new requirements which closely match ones we already have but we should be wary of large, brand new areas.

Unless anyone disagrees, I will mark this as closed in mid-August and maybe make a note somewhere in the contribution guidance.

kwwall commented 1 year ago

@jmanico wrote:

I think the levels should be RISK-BASED and absolutely not TESTABILITY BASED

I absolutely agree, but at the same time, let's be transparent about testability. After all, that's a huge issue with a lot of high-level (but IMO, often worthless) company GRC related policies and standards. They are too damn vague to be testable. So having testable security requirements is a big draw.

This lack of transparency is part of the reason that I posted the discussion https://github.com/OWASP/ASVS/discussions/1651. Have the testability aspect to ASVS, especially without access to source code as the Level 1 requirements more or less promise, was a big selling point to upper management. But on closer inspection, I've discovered there's very little there. It's mostly am empty promise. We need to do better.