Has WHS jumped the shark?

Does the "WhiteHat Website Security Certification Program" demonstrate that WHS has jumped the proverbial shark?

25% or more of WHS's customers demanded a logo program of this nature, says Jeremiah Grossman, CTO of WHS. Customer demand is not something to ignore lightly.

By the same token, website logo programs of this nature have a dubious past, at best.

Take McAfee's "Hack Safe" program as an obvious example. The level of negative press that the "Hacker Safe" program has generated to date is outstanding.

McAfee 'Hacker Safe' cert sheds more cred. Rubber stamp factory exposed
http://www.theregister.co.uk/2008/04/29/mcafee_hacker_safe_sites_vulnerable/

More bad news for McAfee, HackerSafe certification
http://blogs.zdnet.com/security/?p=1068

Hackersafe? Not so much.
http://holisticinfosec.org/video/HS_ISSA/ISSA_Regional_HackerSafe.html

Russ McGee had a very interesting blog post that was favorable to WHS's new website cert program.

http://holisticinfosec.blogspot.com/2009/05/whitehats-trustmark-program-as-game.html. In the comment section, Jeremiah states:

I think it's also fair to say that what we're offering is more of a "Trust mark" than "Security mark." We do not want lay claim as to the implied security of a website, or the lack thereof. Doing so is a very slippery slope. If our mark does that it is not our intent and we are open to ideas on how best to clarify its true meaning.

To answer your question, only Sentinel customers may display our mark -- which does not come cheaply as compared to others. Organizations who use the Sentinel Service are those who really care about security and the mark should represent that.

and http://www.whitehatsec.com/home/services/certified.html states:

The “website security by WhiteHat Security” mark allows Sentinel subscribers to assure their site visitors that the WhiteHat Sentinel Services is being actively deployed to safeguard confidential data from security breaches and hacker attacks

Jeremiah was faced with a rather difficult choice : upset his customer, or upset some in the security community.

But I must call this a "security fail" for for time being.

a) This cert is not claiming that the website is secure
b) This cert claims that Whitehat Security is the web security service provider, only
c) This cert is consumer based; it's meant for the consumer not the security pro
d) A security-ignorant consumer (the masses) will incorrectly conclude that the website IS secure based on seeing the WHS certification logo, even thou WHS is not making that claim

We need more in-depth verification and more process, not less. Projects like the OWASP Application Security Verification Standard meets that challenge head-on.

http://manicode.blogspot.com/2009/06/owasp-asvs-release-version-published.html

PS: So in a few years, when we have a "Aspect Assured" logo, please give me a hard time. :)

OWASP ASVS Release Version published

Release quality OWASP projects are the level of quality of professional tools and documents.

Application Security Verification Standards are specifications produced by OWASP in cooperation with secure applications developers and verifiers worldwide for the purpose of accelerating the deployment of secure Web applications. First published in 2008 as a result of an OWASP Summer of Code grant and meetings with a small group of early adopters, the ASVS documents have become widely referenced and implemented. Further development of ASVS occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. You can download it here (http://www.owasp.org/index.php/ASVS).

For more information, please contact us. Mike Boberski, Jeff Williams, and Dave Wichers are the primary authors.

OWASP Podcast #23 - Dr. Boaz Gelbord

OWASP Podcast #23, an interview with Dr. Boaz Gelbord - is now live! http://www.owasp.org/download/jmanico/owasp_podcast_23.mp3

Boaz is the co-author of the OWASP Security Spending Benchmarks Project.

RSS: http://www.owasp.org/download/jmanico/podcast.xml
iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012

'Sound' Analysis by Dave Wichers

( This blog post was authored by dave.wichers@aspectsecurity.com )

I recently attended the NSA High Confidence Software & Systems (HCSS) Conference and noticed that many tool vendors and researchers working on static and dynamic analysis were using a new term called sound analysis, which means, ‘no false negatives’. In other words, a ‘sound’ analysis won’t miss any of the types of flaws it is looking for. It might have some false positives.

Bill Scherlis, one of the speakers, defined this as: “In a sound analysis, as distinct from heuristic analysis, we do not produce false negatives. If there is a defect of a particular variety, our sound analysis will find it. I’ll note that a sound analysis may have false positives. The mathematics generally preclude the possibility of having it both ways. But in practice we don’t get many false positives. But the main point is to avoid false negatives, to not miss a diagnosis. We may occasionally over-diagnose but we will never miss a diagnosis.”

I like the idea of this, but I have never heard any of the vendors in our space claim sound analysis for anything they look for. I did see one vendor there that claimed they could provide sound analysis for buffer overflows. The company was Kestrel Technology. They define soundness as: http://www.kestreltechnology.com/about/sound.php

So, if you hear of any code scanning vendor claim they provide ‘sound’ analysis, I’d be interested in hearing about it. dave.wichers@aspectsecurity.com

- Dave Wichers

PS: Because Kestrel does ‘sound’ analysis, they are able to report the kinds of positive information I would love to see from a tool. In my presentation, I had the following security facts label (updated based on Jeff’s original idea 5+ years ago). Imagine tools in our space reporting what I have listed in gray … Wouldn’t that be nice :-)

PPS: I don’t think this is an attack ‘against’ the tools. I think there are two points here:
1) Sound analysis vs. best we can do with current state of the art (and even sound analysis can improve with less false positives).
2) And separately, tools reporting what they have found that’s good, rather just what is bad. However, if tools aren’t doing ‘sound’ analysis, they will be reluctant to report goodness, since they can’t find/report everything that’s relevant (and are thus unsound) :)

OWASP Top 6 2009

6. OWASP Legal Project (Secure Software Contracts for Developers and their Clients) http://www.owasp.org/index.php/Category:OWASP_Legal_Project

5. OWASP Live CD! FREE TOOLS! http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project

4. OWASP Application Security Verification Standard http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

3. OWASP Code Review Guide http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

2. OWASP Developers Guide http://www.owasp.org/index.php/Category:OWASP_Guide_Project

1. OWASP Coders Security Library for Java, PHP, .NET, ASP and Haskel (ESAPI - FOSS
Enterprise Security API) http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Please do not log session ids

I'm very disappointed to see Johannes Ullrich @ the Internet Storm Center lead off the SANS Software Security Institute blogging effort at appsecstreetfighter.com by providing a software security recommendation that will significantly increase application risk!!

http://appsecstreetfighter.com/2009/05/24/logging-cookies-in-apache/

This is absolutely positively bad application security advice. Logging a session id will actually increase application risk! Never log session ids!

To quote Johannes, "The cookie typically includes the session ID, which then links to a particular user. So this way, you can figure out which user caused a particular action."

An insider could hijack all active sessions by simply having access to a live application log file.

Never log session ids. If you need to uniquely identify each session in your log files for debugging or other purposes, then hash your session id's before logging them. Only transmit session ids over well configured https. Keep session ids out of urls. Make sure session ids are cryptographically random and long. Reduce idle timeout. Enforce absolute timeout. Invalidate session ids at logout.

But really, if you think you need to log a session id or ANY credentials, think again.

Make sure your Web Application Security educator utilizes OWASP principles!

PS: appsecstreetfighter.com is a great blog name.

OWASP Podcast #22 - Dan Cornell

OWASP Podcast #22, an interview with Dan Cornell, CTO of the Denim Group - is now live! http://www.owasp.org/index.php/Podcast_22

Dan is a smart cookie who puts in incredible amount of time volunteering for OWASP. He's a great guy with a very pragmatic perspective on Application Security. I hope you enjoy!

OWASP Podcast Series RSS: http://www.owasp.org/download/jmanico/podcast.xml
OWASP Podcast Series iTunes: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012