[SC-L] more relevant certifications
Paco Hope p...@cigital.com wrote: just as overly-simplistic as someone who disparages all credentials equally. On that note... my company (BAE Systems) has been pushing for people to become CISSPs, because in turn the main client (US gov) has been pushing for contractors to have a bunch of CISSPs on the projects. But, it seems as though that cert is very heavily loaded down with things that front-line grunts like me will NEVER use. I doubt I'll ever get to decide where a data center is located, let alone the entire building, nor what kind of fire detection/suppression or physical security systems it has, and I can probably forget about dictating HR policy as well. So, I was considering other certs, that seem much more relevant. The main relevant one I've heard of is the GSSP (GIAC Secure Software Programmer). 1) What do y'all think of that one? 2) It looked to me as though, other than perhaps from buying books, there is one and only one GSSP practice exam, and it can be taken only once. Am I wrong? Do you know of any others available for free, preferably to be taken online? 3) Have you heard of any other certs relevant for those of us who mainly design and implement computer-based systems, which will usually undergo security scrutiny, and usually have little to no say about all the other stuff around it? (Preferably not technology-specific, as opposed to for example a Secure Java or Secure Web-Apps cert.) Compare and contrast, as the teachers would say Thanks, Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII | Play: davearonson.net | \/ Ribbon Specialization is for insects.| Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net| EmailWeb ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT)
I would argue that the security 'bugs' you've described are in fact functional deficiencies in the implemented design. That is, the exploit of them has a direct impact on functional performance of the application, even if it's just a problem with error handling (input validation). I would further argue that treating security as a special case ends up doing us more harm than good. Doing so allows developers, designers, and the business to shrug it off as Somebody Else's Problem (SEP), instead of owning it themselves. The same goes for the requirements, design, etc. As an industry, we've developed segments of specialized knowledge, and then have the audacity to complain about it not being mainstream. It's time we picked one, and I would argue that mainstreaming these concepts will be far more effective than continuing as a specialized bolt-on discipline (which is not to say that specialized research should not occur, just that in real life the application of this knowledge should not be specialized, per se). *shrug* The only way I see to win the game is to change the rules and/or the game play itself. We must never forget that the security industry still relies (heavily) on many of the same concepts that protected us 15 years ago (i.e. signature-based scans and ACLs - AV+firewall). -ben Goertzel, Karen [USA] wrote: No - that isn't really what I meant. There CAN be security bugs - i.e., implementation errors with direct security implications, such as a divide-by-zero error that allows a denial of service in a security-critical component, thus exposing what is supposed to be protected data. But there are also bad security decisions - these can be at the requirements spec or design spec level. If they're at the requirements spec level, they aren't bugs - they are either omissions of good security or commissions of bad security. An omission of good security is not encrypting a password. That isn't a bug per se - unless it's a violation of policy. But if there's no password encryption policy, then the failure to include a requirement to encrypt passwords would not be a bug or a violation of any sort (except a violation of common sense). It would still, however, result in poor security. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: Benjamin Tomhave [mailto:list-s...@secureconsulting.net] Sent: Fri 20-Mar-09 11:04 To: Goertzel, Karen [USA] Cc: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) So, what you're saying is that security bugs are really design flaws, assuming a perfect implementation of the design. Ergo, security bug is at best a misnomer, and at worst a fatal deficiency in design acumen. :) -ben Goertzel, Karen [USA] wrote: Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between software and security bugs? It seems to me that all bugs are software bugs, ... -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Hofstadter's Law: A task always takes longer than you expect, even when you take into account Hofstadter's Law. http://globalnerdy.com/2007/07/18/laws-of-software-development/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT)
I have to post this blog in response. http://labs.mudynamics.com/2008/07/14/zen-and-the-art-of-fixing-p1-bugs Love the security testing IS functional testing, BTW. K. --- http://www.pcapr.net On Thu, Mar 19, 2009 at 4:28 PM, Benjamin Tomhave list-s...@secureconsulting.net wrote: Why are we differentiating between software and security bugs? It seems to me that all bugs are software bugs, and how quickly they're tackled is a matter of prioritizing the work based on severity, impact, and ease of resolution. It seems to me that, while it is problematic that security testing has been excluded historically, our goal should not be to establish yet another security-as-bolt-on state, but rather leapfrog to the desired end-state where QA testing includes security testing as well as functional testing. In fact, one could even argue that security testing IS functional testing, but anyway... If you're going to innovate, you must as well jump the curve*. -ben * see Kawasaki Art of Innovation http://blog.guykawasaki.com/2007/06/art_of_innovati.html Gary McGraw wrote: Aloha Jim, I agree that security bugs should not necessarily take precedence over other bugs. Most of the initiatives that we observed cycled ALL security bugs into the standard bug tracking system (most of which rank bugs by some kind of severity rating). Many initiatives put more weight on security bugs...note the term weight not drop everything and run around only working on security. See the CMVM practice activities for more. The BSIMM helps to measure and then evolve a software security initiative. The top N security bugs activity is one of an arsenal of tools built and used by the SSG to strategically guide the rest of their software security initiative. Making this a top N bugs of any kind list might make sense for some organizations, but is not something we would likely observe by studying the SSG and the software security initiative. Perhaps we suffer from the looking for the keys under the streetlight problem. gem On 3/19/09 2:31 PM, Jim Manico j...@manico.net wrote: The top N lists we observed among the 9 were BUG lists only. So that means that in general at least half of the defects were not being identified on the most wanted list using that BSIMM set of activities. This sounds very problematic to me. There are many standard software bugs that are much more critical to the enterprise than just security bugs. It seems foolhardy to do risk assessment on security bugs only - I think we need to bring the worlds of software development and security analysis together more. Divided we (continue to) fail. And Gary, this is not a critique of just your comment, but of WebAppSec at large. - Jim - Original Message - From: Gary McGraw g...@cigital.com To: Steven M. Christey co...@linus.mitre.org Cc: Sammy Migues smig...@cigital.com; Michael Cohen mco...@cigital.com; Dustin Sullivan dustin.sulli...@informit.com; Secure Code Mailing List SC-L@securecoding.org Sent: Thursday, March 19, 2009 2:50 AM Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT) Hi Steve, Sorry for falling off the thread last night. Waiting for the posts to clear was not a great idea. The top N lists we observed among the 9 were BUG lists only. So that means that in general at least half of the defects were not being identified on the most wanted list using that BSIMM set of activities. You are correct to point out that the Architecture Analysis practice has other activities meant to ferret out those sorts of flaws. I asked my guys to work on a flaws collection a while ago, but I have not seen anything yet. Canuck? There is an important difference between your CVE data which is based on externally observed bugs (imposed on vendors by security types mostly) and internal bug data determined using static analysis or internal testing. I would be very interested to know whether Microsoft and the CVE consider the same bug #1 on internal versus external rating systems. The difference is in the term reported for versus discovered internally during SDL activity. gem http://www.cigital.com/~gem On 3/18/09 6:14 PM, Steven M. Christey co...@linus.mitre.org wrote: On Wed, 18 Mar 2009, Gary McGraw wrote: Many of the top N lists we encountered were developed through the consistent use of static analysis tools. Interesting. Does this mean that their top N lists are less likely to include design flaws? (though they would be covered under various other BSIMM activities). After looking at millions of lines of code (sometimes constantly), a ***real*** top N list of bugs emerges for an organization. Eradicating number one is an obvious priority. Training can help. New number one...lather, rinse, repeat. I believe this is reflected in public CVE data. Take a look at the bugs that are being reported for, say, Microsoft or major Linux
Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT)
So, what you're saying is that security bugs are really design flaws, assuming a perfect implementation of the design. Ergo, security bug is at best a misnomer, and at worst a fatal deficiency in design acumen. :) -ben Goertzel, Karen [USA] wrote: Except when they're hardware bugs. :) I think the differentiation is also meaningful in this regard: I can specify software that does non-secure things. I can implement that software 100% correctly. Ipso facto - no software bugs. But the fact remains that the software doesn't validate input because I didn't specify it to validate input, or it doesn't encrypt passwords because I didn't specify it to do so. I built to spec; it just happened to be a stupid spec. So the spec is flawed - but the implemented software conforms to that stupid spec 100%, so by definition it not flawed. It is, however, non-secure. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave Sent: Thu 19-Mar-09 19:28 To: Secure Code Mailing List Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) Why are we differentiating between software and security bugs? It seems to me that all bugs are software bugs, ... -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ [ Random Quote: ] Hartree's Law: Whatever the state of a project, the time a project-leader will estimate for completion is constant. http://globalnerdy.com/2007/07/18/laws-of-software-development/ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)
Well, it seems that there's an interesting nuance here. We don't really have a concrete definition for what software is (code, design, compiled bins, etc.). All of these things plus the subjective expectations from designers, users, and security folks tend to be the domain for how the term is used. Now on to 'bug'... Same thing applies. A missing feature can be called a bug just as well as a flawed line of code (or even a specified feature that does something undesirable). But, I'm of the mind that avoiding security problems in software comes down to specification and design. I know Gary likes to talk about security problems as bugs (code-level) vs flaws (design-level), but this abstraction isn't helpful when trying to build secure software in general (however, it is helpful in convincing people that are bug-chasing to look elsewhere too). In fact, I'd be willing to be that for just about every software security problem we've dealt, I could give you a design/spec level solution that would prevent it in general (and make auditing and so forth incredibly streamlined). p. ~ ~ ~ ~~~ ~~ ~ Pravir Chandra chandraatlistdotorg PGP:CE60 0E10 9207 7290 06EB 5107 4032 63FC 338E 16E4 ~ ~~ ~~~ ~ ~ ~ -Original Message- From: Goertzel, Karen [USA] goertzel_ka...@bah.com Date: Fri, 20 Mar 2009 10:06:46 To: Benjamin Tomhavelist-s...@secureconsulting.net; Secure Code Mailing ListSC-L@securecoding.org Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT) ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] more relevant certifications
I would refer you to Section 7.2.2.2, Professional Certifications, starting on page 272 of Software Security Assurance: A State-of-the-Art Report which can be downloaded from: http://iac.dtic.mil/iatac/download/security.pdf The report was published in July 2007; there may be additional certifications that have become available since then. -- Karen Mercedes Goertzel, CISSP Booz Allen Hamilton 703.698.7454 goertzel_ka...@bah.com -Original Message- From: sc-l-boun...@securecoding.org on behalf of SC-L Reader Dave Aronson Sent: Fri 20-Mar-09 09:59 To: Secure Coding Subject: [SC-L] more relevant certifications Paco Hope p...@cigital.com wrote: just as overly-simplistic as someone who disparages all credentials equally. On that note... my company (BAE Systems) has been pushing for people to become CISSPs, because in turn the main client (US gov) has been pushing for contractors to have a bunch of CISSPs on the projects. But, it seems as though that cert is very heavily loaded down with things that front-line grunts like me will NEVER use. I doubt I'll ever get to decide where a data center is located, let alone the entire building, nor what kind of fire detection/suppression or physical security systems it has, and I can probably forget about dictating HR policy as well. So, I was considering other certs, that seem much more relevant. The main relevant one I've heard of is the GSSP (GIAC Secure Software Programmer). 1) What do y'all think of that one? 2) It looked to me as though, other than perhaps from buying books, there is one and only one GSSP practice exam, and it can be taken only once. Am I wrong? Do you know of any others available for free, preferably to be taken online? 3) Have you heard of any other certs relevant for those of us who mainly design and implement computer-based systems, which will usually undergo security scrutiny, and usually have little to no say about all the other stuff around it? (Preferably not technology-specific, as opposed to for example a Secure Java or Secure Web-Apps cert.) Compare and contrast, as the teachers would say Thanks, Dave -- Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII | Play: davearonson.net | \/ Ribbon Specialization is for insects.| Life: dare2xl.com | /\ Campaign -Robert A. Heinlein | Wife: nasjleti.net| EmailWeb ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
