Security as a part of code quality (Was: Re: Where Does Secure Coding Belong In the Curriculum?)

[gem at cigital.com (Gary McGraw)]

Actually CJC, it's often even worse than that.  In many cases, the customer or consumer has an implicit requirement for 
security that remains unstated.  Only when the system fails and is successfully attacked does that requirement shift 
from implicit to explicit.  "You mean it wasn't secure??  You've got to be kidding..."

In some sense that's what happened to Microsoft way back in the virus-bag days.  History shows that it is best to 
anticipate implicit requirements and address them as possible.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com


On 8/21/09 8:40 AM, "Cassidy, Colin (GE Infra, Energy)" <colin.cassidy at ge.com> wrote:

Martin Gilje Jaatun wrote:

> Karen, Matt & all,
>
> Goertzel, Karen [USA] wrote:
> > I'm more devious. I think what needs to happen is that we
> need to redefine what we mean by "functionally correct" or
> "quality" code. If determination of functional correctness
> were extended from "must operate as specified under expected
> conditions" to "must operate as specified under all
> conditions", functional correctness would necessarily require
> security, safety, fault tolerance, and all those other good
> things that make software dependable instead of just correct.
> >
> I couldn't agree more!
>
> However, I have had several discussions with a colleague who is fairly
> well known in the"Software Process Improvement Mafia" on the topic of
> how to ensure that security requirements are considered for
> _all_ kinds
> of code, not just "security software". Particularily in the context of
> agile development techniques, security keeps getting the short end of
> the stick, losing every time to "working features". His stance on this
> is that "if security were important to the customer, the
> customer would
> provide and prioritize security requirements". To me, this is
> a bit like
> saying "If the customer doesn't explicitly state that the software
> should be Y2k-proof, he/she is not really bothered about it".

The problem (certainly as I see it) is that the customer is likely to say
"Make it secure" without really understanding what that means.  Secure
against what exactly?

Or you'll get a list of security features that the customer wants, but as we
all know security features != secure product.

Instead we've taken a combined approach of including customer requirements
and adding specific requirements of our own focusing a good Secure
development practices.

> If we can "brainwash" the coming generations of programmers into
> accepting Karen's definition of "quality code", we might finally be
> getting somewhere.

And that's the trick we've been attempting here.  Secure software is nothing
more than really good quality code.  We already use coding guidelines and
have a strong(ish) process of code reviews.  So we have augmented our coding
and review guidelines to include secure coding aspect such as input/output
validation, good memory management etc.

That said there is still a lot of scope for improvement in the rest of the
software development process (testing and design in particular).

CJC