Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Michael Silk
On Apr 7, 2005 12:43 PM, Blue Boar [EMAIL PROTECTED] wrote:
 Michael Silk wrote:
  See, you are considering 'security' as something extra again. This is
  not right.
 
 It is extra.  It's extra time and effort.  And extra testing.  And extra
 backtracking and schedule slipping when you realize you blew something.
 All before it hits beta.

All of this is part of _programming_ though.  To me it should be on
the same level as, say, using an 'Array' at an appropriate point in a
program. You won't say to management: Oh, I didn't use an array there
because you didn't ask me to.. It's ridiculous to even consider. And
so it should be with so-called 'Security' that is added to
applications.

Consider the bridge example brought up earlier. If your bridge builder
finished the job but said: ohh, the bridge isn't secure though. If
someone tries to push it at a certain angle, it will fall. You would
be panic stricken. Fear would overcome you, and you might either run
for the hills, or attempt to strangle the builder... either way, you
have a right to be incredibly upset by the lack of 'security' in your
bridge. You WONT (as is the case now) sit back and go: Oh well, fair
enough. I didn't ask you to implement that, I just said 'build a
bridge'. Next time i'll ask. Or make sure the public specifically
requests resistence to that angle of pushing.

Hopefully my point is obvious...

-- Michael

 Any solution that ends up with us having secure software will
 neccessarily need to address this step as well as all others.  The
 right answer just might end up being suck it up, and take the
 resource hit.  It might be switch to the language that lends itself to
 you coding securly at 75% the productivity rate of sloppy coding.  I
 don't know enough about the languages involved to participate in that
 debate.
 
 Strangely enough, for the last year and a half or so, I've been sitting
 here being QA at a security product company.  Doing software right takes
 extra resources.  I are one.
 
Ryan





Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Blue Boar
Michael Silk wrote:
 See, you are considering 'security' as something extra again. This is
 not right.

It is extra.  It's extra time and effort.  And extra testing.  And extra
backtracking and schedule slipping when you realize you blew something.
 All before it hits beta.

Any solution that ends up with us having secure software will
neccessarily need to address this step as well as all others.  The
right answer just might end up being suck it up, and take the
resource hit.  It might be switch to the language that lends itself to
you coding securly at 75% the productivity rate of sloppy coding.  I
don't know enough about the languages involved to participate in that
debate.

Strangely enough, for the last year and a half or so, I've been sitting
here being QA at a security product company.  Doing software right takes
extra resources.  I are one.

 Ryan




Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Margus Freudenthal
Michael Silk wrote:
Consider the bridge example brought up earlier. If your bridge builder
finished the job but said: ohh, the bridge isn't secure though. If
someone tries to push it at a certain angle, it will fall.
All bridges have certain limits. There is difference between a 
footbridge and bridge that can be driven over with a tank. The 
difference is also reflected in cost. You are advocating always building 
tank bridge. Which is understandable attitude - this way you are 
mostly safe. However, in some cases it is *economically feasible* to 
just build a simpler bridge and accept the fact that it will break under 
some conditions.

Ultimately it is a matter of economics. Sometimes releasing something 
earlier is worth more than the cost of later patches. And 
managers/customers are aware of it.

--
Margus



Re: [SC-L] Application Insecurity --- Who is at Fault?

2005-04-07 Thread Michael Silk
Dave,

 What you're proposing is that the ironworker should reengineer the
 bridge in-situ (as if he even has the authority!), causing weeks of
 delay, cost overruns, and possibly lead to his employer never getting a
 bridge contract again.

That's not at all what I'm suggesting... guess my point wasn't so obvious :)

I'm not saying the programmer should totally redesign the application
if it's not secure.

I am saying that they _SHOULD_ do the simple, 'trivial' things within
the context of their current job. Validating input, handling errors
properly, ensuring ownership of various id's, etc. All of these things
fall in this category.

Yet these days, when programmers actually _DO_ do these things, they
call these things 'security features' and themselves 'secure
programmers' (or whatever). And that's what I think is ridiculous.

Other things, like designing a secure protocol/management of your
encryption system can be though of as 'something extra' but these
types of problems aren't the _MAJOR_ problems (they are big problems,
however) that we deal with.

There are, of course, design concepts that shouldn't really be billed
as 'extra' either [like appropriate user management/access systems,
etc].

And back to the main point of this discussion, is that lack of these
things in application shouldn't be blamed on consumers (or even
management) for not asking. These things should be assumed...

-- Michael

 
 Somehow, that just doesn't hold water.
 Kind Regards,
 -dsp