Secure Coding mailing list archives

RE: ACM Queue article and security education


From: "Michael S Hines" <mshines () purdue edu>
Date: Wed, 30 Jun 2004 20:29:17 +0100

If the state of the art in automobile design had progressed as fast as the
state of the art of secure programming - we'd all still be driving Model
T's.  

Consider-
  - System Development Methods have not solved the (security) problem -
though we've certainly gone through lots of them.
  - Languages have not solved the (security) problem - though we've
certainly gone through (and continue to go through) lots of them.
  - Module/Program/System testing has not solved the (security) problem -
though there has been a plethorea written about system testing (both white
box and black box).

And a question/comment/observation.
First the comment - As an IT Auditor we approach auditing in two stages -
first we look at general controls, and then application controls (won't go
into details here - there's information on this available elsewhere).  If
general controls are not in place, application controls are not relevant
(that is any application control can be circumvented due to weak general
controls). 
Then the question - Why do we not subject computer operating systems (which
are a general control) to the same level of testing that we subject
applications?   
And the observation - weaknesses in operting systems have been documented
(but not widely circulated) - yet we (as Sysadmins/users/auditors/security
experts - you pick) do not have a problem using faulty system software and
laying applications on top of them.  Why is that?     

And then a thought question - in message passing operating systems (those
that respond to external stimuli, or internal message queues) - if one can
inject messages into the processing queue, can't one in essence 'capture the
flag'?  Yet we see message passing systems as middleware (and OS core
technology in some cases) to facilitate cross platform interfaces.  Aren't
we introducing inherient security flaws in the process?     

Mike Hines
-----------------------------------
Michael S Hines
[EMAIL PROTECTED] 






Current thread: