Re: Secured Coding

[Dana Epp <dana () vulscan com>]

George,

I truly believe this as no matter how secured we make our programs there 
will always be someone to figure how to break it.


Like most things in information security its about risk mitigation, NOT risk avoidance. We can sit and profile the 
adversary till we are blue in the face and assume we know how he will think; the landscape always changes and we will 
at times miss something. 

But that doesn't mean we stop trying. Secure software engineering is still in its infancy. We will continue to have 
failures. What will make the difference is how we learn from it, adapt and move forward. Having a poor track record to 
this point doesn't help. Things like buffer overflows have been around for over 20 years and many developers still 
haven't figured it out. 

But that doesn't mean we stop trying. We need to approach it with a higher mindset. Instead of worrying about the next 
great technical safeguard or uber coding technique we have to really understand how software works. How it is exploited 
and how we can mitigate the risks associated with various attack pattern TYPES. 

I say TYPES as I think it goes beyond what people like Gary McGraw outline. Commonalities in the patterns continue to 
be ignored as systems get more obscured with higher level language that hide what is going on. New developers are 
emerging without having a REAL understanding of what is going on under the hood, having a false sense of security 
because they have been told that <your favorite language here> is safer to code in. 


Sometimes we need to reflect on history and try to learn from it. We like to tout that defense in depth in any 
environment is a good idea. Yet do we actually use that thinking in software? Do we actually understand what that 
means? To me I would rather have three smaller walls than one BIG one. Why? Because I will typically know when the 
first wall is breached, giving me time to REACT. How much software today simply implements a single safeguard and think 
its safe? Its not acceptable, and thats not a failing of the discipline. Its the failing of people who don't know any 
better. They read "Writing Secure Code" or "Building Secure Software" and think they have all the answers, when there 
is much, much more. And whats sad, is most developers don't even go that far.

We need to reduce, redirect or eliminate the impacts of attacks, and that goes beyond simply writing "secure" code. We 
need to apply the thinking to configuration, to deployment AND to design. Microsoft calls it SD3+C. Its one of the 
concepts I LIKE coming out of there. Secure by design, secure by default and secure in deployment. (I won't get into 
the +C here). Yet I know MANY people don't even think about that when writing software. Heck, many still WRITE code as 
an Administrator on a Windows system for gods sake. And deploy software requiring similar rights when its not needed. 
*sigh*

Now I know I am preaching to the choir. You guys know all this stuff. But the people out there DON'T. And now we are 
full circle in the discussion of education.

George, you are right that there will always be an adversary that will be able to break our safeguards. The trick is to 
apply the appropriate safeguards in the right places to make it much more difficult for the attacker, so that they will 
move on to easier targets. Its not about have the BEST security in the world, its about having "just enough" security 
to mitigate the risks you wish to protect against. Does it make sense to spend $500,000k on developing a crypto schema 
for a P2P file sharing app? Probably not. Would you want to apply that to something protecting critical infrastructure. 
Probably. 

Think of it as a chess game with a twist. We always have to think ahead of the adversary, thinking moves ahead of what 
they are going to do. Unfortunately they can move their pawns backwards, giving them an unfair advantage. And at times, 
get ahead of us. But that doesn't mean we stop trying. 


--
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]