Re: Secure Coding? Bah!

[Mike Hoskins <mike () adept org>]

ONEILL David J wrote:
> GREAT! More Architect/Developer bashing.

i agree, it's not the attitude we need to promote.  everyone is 
overworked already, we need to suck it up and talk about solutions not 
point out obvious pitfalls we're all aware of and many have been trying 
to "solve" for the past decade.  OTOH, i agree with a few others that 
the article purposely took a fair amount of editorial privilege.

> security woes of the planet.  Although I have never spent a day in a classroom
> studying methods to make applications more secure, I do have a Computer
> Science degree and around thirty six years of experience building applications

i respect your knowledge, but i also feel you should either obtain 
relevant security training or trust a peer to evaluate your work for 
you.  generic "peer review" is a good thing, but having a brain around 
that makes security their #1 priority is immensely helpful. 
particularly if you're developing "trusted" applicaitons.

the sad thing is, with the economy the way it has been, many companies 
could only afford to keep "core" development staff -- of which security 
types are rarely considered a part.

> And from what I've experienced the majority of
> breaches come from networks and network devices being hacked.

www.microsoft.com.

also, ask yourself the difference between software and hardware.  if we 
in turn say that many of the network "hardware" devices in your 
experience were hacked due to "software" coding practices...  i think we 
can agree the point of entry doesn't really matter much, code is still 
often at the core of the compromise.  (second probably only to laziness.)

> I have met numerous people in my field that were security conscious.  And I
> have never met anyone who said that they did not have the time or aspiration
> to make their code more secure.  And in this context, the only bad code that I
> have had to work with, is code that was developed overseas. My opinion,
> outsourcing companies really don't care what the code works like as long as
> they get paid.

i agree.  it won't always be this way, but i feel it is currently.  for 
now, many of the over-seas places offering "discount labor" are offering 
it because the skillsets they're marketing are 1984, or at least 1994. 
;)  no offense, but i've worked with a few of these folks (who were very 
nice individuals), and they were anything but experts in their field.

> Our problem is that we do care, so we fix the problems we find
> before they cause any issues that management would here about.  And this is
> how we shot ourselves in the foot, we tell management what we found but it
> never sinks in because they did not see any cost penalty.

i thought this kind of security-conscious "refactoring" would have more 
recognition than ever before given all the recent "ED" buzz.  if you 
have a security-architect-type-person who evangelizes security to TPTB 
while being technical enough to conduct code review, management would be 
in the know and you would have more recognition (and development time).

of course most companies never hire that person...  but maybe you or a 
coworker could wear another hat?  i've found just sumarizing 
security-related improvements in development/engineering meetings and 
making the slightest effort to view security as an item worthy of time 
on your PM's gant chart goes a long way...

granted, this rant started with "we're all overworked already" -- 
reminding me what an old co-worker once said, "if i have any more 
slashes in my title, i'm going to slash someone's throat."