5 ms·

The OWASP Top 10 is intended as an awareness tool to help raise visibility of web app. security issues. I'd agree with the article that it gets misused (a lot)

The OWASP Top 10 is intended as an awareness tool to help raise visibility of web app. security issues. 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_Security_Verification_Standard_Project https://www.owasp.org/index.php/Category:OWASP_Application_S... and at a more organizational level, OWASP SAMM https://owaspsamm.org/ 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.

deleted 7y ago
[deleted]
joeyrideout 7y ago
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 :)
- tptacek 7y ago
  CVSS is worthless; the only way to misuse it is to use it at all.
  - carty76ers 7y ago
    I’ve never used it, but could you elaborate on why it’s worthless? And what alternatives do you use?
    - wglb 7y ago
      It is an answer to the wrong question.
      - dspillett 7y ago
        That is no more helpful in terms of the extra explanation requested than the original response... Kind of "is it possible to be more vague here?" "yes, yes it is'.
    - deleted 7y ago
      [deleted]
    - kerng 7y ago
      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
  - TeMPOraL 7y ago
    Seconding others; could you elaborate? 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?
    - tptacek 7y ago
t34543 7y ago
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.
- javagram 7y ago
  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.
- throwaway_bad 7y ago
  Eh, can't only blame product managers for this. 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.
  - dspillett 7y ago
    > 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.
- dspillett 7y ago
  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.

deleted 7y ago

[deleted]

joeyrideout 7y ago

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 :)

tptacek 7y ago
CVSS is worthless; the only way to misuse it is to use it at all.
- carty76ers 7y ago
  I’ve never used it, but could you elaborate on why it’s worthless? And what alternatives do you use?
  - wglb 7y ago
    It is an answer to the wrong question.
    - dspillett 7y ago
      That is no more helpful in terms of the extra explanation requested than the original response... Kind of "is it possible to be more vague here?" "yes, yes it is'.
  - deleted 7y ago
    [deleted]
  - kerng 7y ago
    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
- TeMPOraL 7y ago
  Seconding others; could you elaborate? 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?
  - tptacek 7y ago

t34543 7y ago

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.

javagram 7y ago
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.
throwaway_bad 7y ago
Eh, can't only blame product managers for this. 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.
- dspillett 7y ago
  > 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.
dspillett 7y ago
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.