Understanding the OWASP list
whitessource.com
whitessource.com
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)
>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.
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.
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.
It is frustrating working in an environment where the ASVS is held up as infallible...
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.
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.
Have you considered contributing recently?
One of the benefits is that it's open source, so you're free to contribute to improve it.
I'd agree with the article that it gets misused (a lot) as some kind of checklist that, if you apply, you can have a "secure" application.
Ironically OWASP has several other great projects that are designed to provide methodologies to improve application security like ASVS https://www.owasp.org/index.php/Category:OWASP_Application_S... and at a more organizational level, OWASP SAMM https://owaspsamm.org/ .
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 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 :)
Kind of "is it possible to be more vague here?" "yes, yes it is'.
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'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?
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.
It simply doesn't say anything at all.
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.
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.
I have faithfully filled out a CVSS calculator form for small bugs that I'd consider sev:med and it happily declared them as sev:crit.
It's stupid. CVSS just muddies the water and creates the illusion of a measuring stick where there is none.
I don't bother with CVSS, and none of my clients even notice.
Just treat severity as an enum and explain your decision:
typedef enum sev { info, low, med, high, crit } sev;
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.
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.
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.
https://www.owasp.org/index.php/OWASP_Cloud-Native_Applicati...
https://seventhings.liftweb.net/security
Can this be improved to include support for all the OWASP ?if not, why ?
Do programmers really follow it? Is it a status quo for companies to make sure their software follow OWASP top 10 like a checklist?
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.
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