4 ms·

As of now? ASVS v4: https://www.owasp.org/images/d/d4/OWASP_Application_Security_Verification_Standard_4.0-en.pdf https://www.owasp.org/images/d/d4/OWASP_Applic

As of now? ASVS v4: https://www.owasp.org/images/d/d4/OWASP_Application_Security_Verification_Standard_4.0-en.pdf https://www.owasp.org/images/d/d4/OWASP_Application_Security... 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.

tptacek 7y ago
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?
- time0ut 7y ago
  I've been trying to make sense of 2.4.5 for a while and have come up short. So thank you for that insight. It is frustrating working in an environment where the ASVS is held up as infallible...
  - technion 7y ago
    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.
    - tptacek 7y ago
      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.
- eganist 7y ago
  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.

tptacek 7y ago

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?

time0ut 7y ago
I've been trying to make sense of 2.4.5 for a while and have come up short. So thank you for that insight. It is frustrating working in an environment where the ASVS is held up as infallible...
- technion 7y ago
  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.
  - tptacek 7y ago
    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.
eganist 7y ago
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.