I think most should be actually checking the "OWASP Application Security Verification Standard Project" [1] instead of just the Top 10 list.
The application security verification standard has quite clear requirements that you can just feed into your software development process. The requirements are split to three different levels, L1, L2 and L3. L1 requirements are more or less straightforward, standard application development stuff. L2 and L3 go more into processes. The idea is also that the L1 requirements can be verified by external penetration testing, without access to source code.
I would say the L1 requirements are something everybody involved in creating web apps professionally should check. Maybe some the requirements don't make sense for your particular application, but for those cases it is a good exercise to write down why not.
ASVS is a good idea, but it has forever lost its credibility for me after the following recommendation appeared in one of its published documents (2.13 I believe, level 1 ASVSv3):
>Verify that account passwords make use of a sufficient strength encryption routine and that it withstands brute force attack against the encryption routine
I think this has been fixed, but I don't understand why encryption (which implies reversibility) was ever advocated over a proper password hashing method such as BCrypt or PBKDF2. And no, using terms like "one way encryption" would not be any better - it shows a general lack of understanding.
There is a general lack of understanding. OWASP is a shambolic volunteer project and its outputs are uneven at best. I would be particularly wary of OWASP when it comes to specialist topics, and cryptography is a great example of that.
That’s a bit disheartening. OWASP isn’t perfect, but it’s definitely a step up the ladder for the kind of teams that aren’t using HTTPS, and storing passwords in plain text. Having an official set of fairly specific instructions helps move the discussion away from the subjective “single quotes are more secure than double quotes” type discussions.
At least for software security, this is probably the best single reference you'll find to get from level 1 to 2 (assuming zero is your origin), regardless of ptacek's largely unfalsifiable objections. Absent from these comments are any other software-security-specific recommendations -- though if you're looking for something more holistic rather than just being siloed to software security specifically, you may consider following NIST CSF to start and then exploring mitigating common patterns exposed in the ATT&CK framework.
If you're looking more for guidance on what other companies are doing for securing development pipelines, probably BSIMM. Bear in mind it's the product of a consulting firm, and all it does is tell you the things others do, not necessarily what's actually effective (descriptive v. prescriptive). The result is that it may be tuned to steer consulting traffic their way. Full disclosure: I've consumed that consulting service at two firms thus far.
Look at ASVS v4 in the context of this subthread about password storage. ASVS provides a list of approved password hashes (or rather, borrows one from an external source), then makes a recommendation about salt size (?!), and concludes by saying applications should run the password hash twice, once with a salt that is a secret key, which (1) is a silly, broken recommendation and (2) isn't a norm in application security at all, but rather is fan service for some random contributor who believes this is a good idea. Why would you trust ASVS?
That entire section was lifted wholesale (32 bits and all) from NIST 800-63b 5.1.1.2 and as a result is specific to contexts where these requirements provide added security guarantees when processing constraints are expected (re: 32 bit salt minimums as well as secret salts / "pepper" in discrete HSMs). This probably isn't right for a number of organizations, but the standards are researched with rehabilitating the most security-impaired organizations/agencies in mind — using prescriptions derived from data. While the ASVS targets a slightly different audience, it's striving to prescribe easily accessible instructions rather than the state of the art (though the two make a pretty tight Venn diagram).
I understand and largely agree with your technical gripes though I regret to say I'm not really convinced by your position. That said, I agree with an unstated corollary to your point: 2.4.5's listing as a L2 control is not appropriate (L3 would be better where this requirement even makes sense), and this specific recommendation should be traded for an alternate prescription in favor of credential-specific hard-i.e.-long salts, because most environments outside the ones NIST cares about actually have the capability to follow the state of the art rather than hack together a solution to fit processing constraints.
---
To your point about mature security programs: you're entirely right. Without those resource constraints, I'd build a program modeled off of real world threats and attack surface as well as actual usage and abuse. No need for a general prescription when I can diagnose my specific shortcomings. You and I are in agreement there. (Talks like "using vulnerability trend analysis to guide holistic security uplift" by salesforce come to mind)
---
Responding from mobile. Please pardon any typing defects. And if you're at Security@ today, I'm up to chat more over foods.
An unfortunate part is that 2.1.2, 2.1.3, 2.1.4, 2.1.7 and 2.1.11 are all issues I've fought of favor of previously (many.. many times), and one of my best assets in that fight an "appeal to authority" by positioning documents like this.
So, as a full-time practitioner in the space with multiple decades of experience, one among many that read and comment on HN, I'm just going to say that ASVS has essentially no currency whatsoever in serious application security practices (like, the practices run by clueful tech companies with large security teams, or NCC Group and any of its constituent companies, or, as far as I know, other large-ish consulting practices like Bishop Fox or Gotham).
I appreciate that the documents are helpful as appeals to authority to win dumb arguments and am not saying you shouldn't do that! But it is weird for me to hear that people outside my field take ASVS especially seriously.
That's a big question, and I don't want to crud the thread up. My point was just, if you're at the point where you're arguing about single quotes versus double quotes, OWASP is just fine as a starting point.
Well I find it interesting :) A huge quantity of value flows through web applications, they're used by pretty much every business sector in the world for a wide range of purposes.
Security vulnerabilities in Web applications have been a major cause of big losses at a large number of these companies.
Despite that, the most authoritative, best funded, Web application security group is OWASP. A group with a full-time staff of < 10, and an annual budget of well under $10M.
It's interesting to me anyway, that the wider IT industry doesn't see value in trying to establish security practices and tooling which could be used to reduce some of these losses. Even if they don't like OWASP itself for any reason, that they don't look to establish something else to achieve the same goal.
Where I do feel some frustration with this article is where , to me, it feels like it's suggesting that "shift left security" (the idea that security activities should take place earlier in the development lifecycle) is any any way a new concept.
The idea of doing more application security work early in the development process has been around at least 20 years and probably more.
Instead of having new buzzwords for it, to try and make it more attractive, I'd be much more interested in a study of why after all this time it's still not uncommon to see a first security touchpoint for a project be a penetration test done 2 weeks before go-live.
I agree. Unfortunately, a lot of security tools get misused in general. (Don't get me started on CVSS!)
I like ASVS and hope that it becomes more popular. Other control standards like CAIQ/CCM are also useful depending on the application.
OWASP SAMM I haven't used yet but I want to have a look! My org uses BSIMM currently. Happy to see an open alternative.
Edit: To be fair, I've noticed "shift left" emerge as a buzzword alongside the popularity of DevOps and DevSecOps. There has been a meaningful improvement in tooling that allows for earlier testing, so I'll concede the new buzzword :)
I've been involved in some work tangential to the security space, and keep encountering some of those "enterprise security for management framework" buzzwords, things like Lockheed KillChain, VERIS framework and similar. I keep wondering if there's any actual value coming from that direction?
Vulnerability severity is complicated and situational. CVSS is fiddly, but still radically oversimplified. As a result, it's a ouji board metric; it says whatever the rater wants it to say. In standard vulnerability research and assessment practice, XSS is the archetypical sev:medium bug, and SQLI the archetypical sev:hi. Under CVSS, you'll see 8.0+ XSS's and 2.0- SQLIs.
There are sev:crit XSS's! A propagating XSS that can chain to ATO of important accounts would qualify. And there are, once in a blue moon, sev:low SQLIs; for instance, on queries that are already constrained by database permissions. But CVSS doesn't capture these details, and the variance in scores both reflects operator bias (and incompetence) while at the same time failing to describe what those biases are.
I do agree CVSS is abused -- especially on NVD -- where they always compute it with "worst case scenario", lacking context and completely messing it up. However, I think CVSS does bring some merit, notably,
1. Forces one to think while assigning values, which means it is more likely that the score will reflect actual severity in most cases.
2. Sets a common tone -- language -- to understanding vulnerability severity, instead of low, medium, high, critical, super critical, which is even worse.
I don't see any scoring system to incorporate the actual operational context, since that is crucial to understanding the real impact of a security issue. CVSS is an attempt, nevertheless, and if you are careful while calculating it, it does add value.
In our organization, we always re-base a vulnerability to an operational context, which makes the score more meaningful.
CVSS has the opposite of merit; it actively confuses people. The same vulnerability found by 3 different teams will have 3 wildly different CVSS scores.
Low, medium, high, critical is actually the interpretive scale provided with CVSS! CVSS isn't getting you away from that; it's just giving you micro-gradations of "medium" or "high". But CVSS isn't even reliable to its first significant figure, let alone into the decimals.
Doesnt that highlight that the problems is not CVSS, but a better quantitative measurement is needed? What other system is there that would let the 3 people agree on something? Security people seem to be the only once that use qualitative measurements and get away with it... because experts.
It is a tool to have a discussion, not a solution to risk management. Security is one of the few fields that uses qualitative measurements, and any attempt of applying more quantitative techniques faces a lot of resistance.
CVSS in isolation is pretty good, but for risk management it lacks "context". A higher level framework would be needed for that.
A bug can have a CVSS score of 10 (critical), and still have little to no impact to the business. It's all about context.
I don't think it even ever intended to be more then a data point to consider for risk management but dev
I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes for far too long.
Developers don't like security features that make development slower either.
I made the mistake of adding Content Security Policy to an app that was still in the prototype stage and it caused endless headaches whenever I needed to add new dependencies.
Your app shouldn't be outright insecure, but defense in depth (e.g., security features that are only useful contingent on the presence of another security vulnerability) can be safely deprioritized until your app gets complex enough to need it.
> can be safely deprioritized until your app gets complex enough to need it
I'd accept "until your app looks like it might leave proof-of-concept classification".
And always be mindful of how quickly PoC code can magically end up needing to be production ready overnight or worse being in production before it is... Retrofitting security can be a nightmare, one that can be so easily avoided.
Sometimes it’s the other way though, e.g. enabling a framework level XSRF protection mechanism is usually very easy for a greenfield project but it’s ignored by many developers in my experience until a security audit comes through and finds the problem - now every form in the app has to be re-tested to verify the mitigation was applied.
And in a situation where there are multiple products the matter gets more complex and competing priorities mean the wrong vice is made more often.
I once nearly left a company because of being ordered to ignore a massive security problem in a legacy application that was actively used by many people to instead concentrate on tweaking bells & whistles on the shiny new thing that hadn't left prototype yet. That would have been fine if other resource was assigned to the security issues, but it wasn't. They did eventually see sence, but I didn't exactly make myself popular with the powers that be at the time.
OWASP is a not-for-profit industry group not a governmental initiative.
However it's generally the most used "standard" for web application security and some regulations will use OWASP projects as references for what things should be considered for security
GDRP results in major fines thus has major funding. OWASP is something someone might tack on, but most of the people involved have little to no ability to check.
No. There is no such thing as OWASP certification. The only teeth OWASP "compliance" might have is a contractually agreed MUSTFIX disposition for vulnerabilities that are on the OWASP Top 10 (which would be pretty silly and is not something I've ever seen done).
The application security verification standard has quite clear requirements that you can just feed into your software development process. The requirements are split to three different levels, L1, L2 and L3. L1 requirements are more or less straightforward, standard application development stuff. L2 and L3 go more into processes. The idea is also that the L1 requirements can be verified by external penetration testing, without access to source code.
I would say the L1 requirements are something everybody involved in creating web apps professionally should check. Maybe some the requirements don't make sense for your particular application, but for those cases it is a good exercise to write down why not.
[1] https://www.owasp.org/index.php/Category:OWASP_Application_S... (the document can be downloaded from the links on the right side)