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.cass...@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 theSoftware 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
___
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.
___
