BSIMM: Confessions of a Software Security Alchemist(informIT)

[list-spam at secureconsulting.net (Benjamin Tomhave)]

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_karen at bah.com
>
>
>
>
> -----Original Message----- From: Benjamin Tomhave
> [mailto:list-spam at 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_karen at bah.com
> >
> >
> >
> >
> > -----Original Message----- From: sc-l-bounces at 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
falcon at 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/