Re: Application Insecurity --- Who is at Fault?

[Michael Silk <michaelslists () gmail com>]

Inline

On Apr 7, 2005 1:06 AM, Dave Paris <[EMAIL PROTECTED]> wrote:
> And I couldn't disagree more with your perspective, except for your
> inclusion of managers in parenthesis.
>
> Developers take direction and instruction from management, they are not
> autonomous entities.  If management doesn't make security a priority,

See, you are considering 'security' as something extra again. This is
not right.

My point is that management shouldn't be saying 'Oh, and don't forget
to add _Security_ to that!' The developers should be doing it by
default.


> then only so much secure/defensive code can be written before the
> developer is admonished for being slow/late/etc.

Then defend yourself ... ! Just as you would if the project was too
large due to other reasons. Don't allow security to be 'cut off'.
Don't walk in and say 'Oh, I was just adding "security" to it,'. A
manager will immediately reply: "Oh, we don't care about that...".
Instead say: "Still finishing it off..". (This _has_ worked for me in
the past, by the way...)

 
> While sloppy habits are one thing, it's entirely another to have
> management breathing down your neck, threatening to ship your job
> overseas, unless you get code out the door yesterday.

Agreed. (Can't blame consumers for this issue, however..)

 
> I'm talking
> about validation of user input, 

This is something that all programmer should be doing in _ANY_ type of
program. You need to handle input correctly for your app to function
correctly, otherwise it will crash with a dopey user.


> ensuring a secure architecture to begin
> with, and the like.  

'Sensible' architecture too, though. I mean, that's the whole point of
a design - it makes sense. For example, an app may let a user update
accounts based on ID's, but it doesn't check if the user actually owns
the ID of the account they are updating. They assume it's true because
they only _showed_ them ID's they own.

You'd hope that your 'sensible' programmer would note that and confirm
that they did, indeed, update the right account. Not only for security
purposes, but for consistency of the _system_. The app just isn't
doing what it was 'specified' to do if the user can update any
account. It's _wrong_ - from a specification point of view - not just
'insecure'.

You would, I guess, classify this as something the managers/consumers
need to explicitly ask for. To me, it seems none of their business. As
a manager, you don't want to be micromanaging all these concepts (but
we are - CIO's...) they should be the sole responsibility of the
programmer to get right.


> The later takes far more time to impliment than is
> given in many environments.  The former requires sufficient
> specifications be given upfront 

Agreed.

-- Michael


> Michael Silk wrote:
> > Quoting from the article:
> > ''You can't really blame the developers,''
> >
> > I couldn't disagree more with that ...
> >
> > It's completely the developers fault (and managers). 'Security' isn't
> > something that should be thought of as an 'extra' or an 'added bonus'
> > in an application. Typically it's just about programming _correctly_!
> >
> > The article says it's a 'communal' problem (i.e: consumers should
> > _ask_ for secure software!). This isn't exactly true, and not really
> > fair. Insecure software or secure software can exist without
> > consumers. They don't matter. It's all about the programmers. The
> > problem is they are allowed to get away with their crappy programming
> > habits - and that is the fault of management, not consumers, for
> > allowing 'security' to be thought of as something seperate from
> > 'programming'.
> >
> > Consumers can't be punished and blamed, they are just trying to get
> > something done - word processing, emailing, whatever. They don't need
> > to - nor should. really. - care about lower-level security in the
> > applications they buy. The programmers should just get it right, and
> > managers need to get a clue about what is acceptable 'programming' and
> > what isn't.
> >
> > Just my opinion, anyway.
> >
> > -- Michael
> [...]