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]
