Inherently Secure Code?

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

To be sure, "inherently secure code" is a misnomer. However, that being
said, my original contention was that certain common vulnerabilities
should be automatically managed these days rather than relying on
explicit code to catch them. Should any sort of overflow really be
allowed? I have to believe there are ways to safely trap those - perhaps
they result in an abend, but at least not in a manner that achieves the
goals of a compromise attempt. Similarly, it seems that there should be
ways to force the deserialization and parsing of data that could be
safer than allowing raw, unvalidated input to be acted upon.

I wonder, too, if part of the error in the curriculum thread is focusing
too low-level - that is, instead of focusing just on coding skills,
maybe there should also be a larger discussion of publishing frameworks,
development environments, etc., that introduce a lot of these security
capabilities as inherited properties/functions? Done properly, it would
lead to inherently better properties. fwiw.

-ben

Peter G. Neumann wrote:
> I don't much like INHERENTLY SECURE CODE.
> Software components by themselves are not secure.
> Security (and trustworthiness that encompasses security, reliability,
>   survivability, etc.) is an emergent property of the entire system
>   or enterprise.  To say that a component is secure is rather fatuous.
>
> See my DARPA report on composable trustworthy architectures for
> starters.
>   http://www.csl.sri.com/neumann/chats4.pdf or .html
>
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at 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.
> _______________________________________________

-- 
Benjamin Tomhave, MS, CISSP
falcon at secureconsulting.net
Blog: http://www.secureconsulting.net/
Twitter: http://twitter.com/falconsview
Photos: http://photos.secureconsulting.net/
Web: http://falcon.secureconsulting.net/
LI: http://www.linkedin.com/in/btomhave

[ Random Quote: ]
"We can't solve problems by using the same kind of thinking we used when
we created them."
Albert Einstein