This is an expanded, modified version of an 'educational chart' that may be familiar to you.

Hope that you enjoy it!

[Note - the chart is 5 pictures wide by 2 high, for some reason the web display sometimes only shows 4 wide.  You can download the .jpg file from the link]

Cheers

Ron

Ron Segal

ron@etrustd.com

The National Security Agency (NSA) defines a trusted computer system or component as one "whose failure can break the security policy", and a trustworthy system or component as one "that will not fail". A trusted system therefore is one where 'trust' is used to describe a role, irrespective of whether a system is able to perform adequately in that role, whereas 'trustworthy' is used to describe the adequacy of a system to perform as expected. In both cases 'trust' is effectively used as an acronym for security, although 'trustworthy Computing' according to Microsoft's Bill Gates is broader - 'What I mean by this is that customers will always be able to rely on these systems to be available and to secure their information.'

We all have to start somewhere. So, if you are interesting in 'having a go' at computer forensics, here's a quick, practical introduction to the mechanics:

http://www.shortinfosec.net/2008/07/tutorial-computer-forensics-process-...

The August, 2008 volume of Control Journal (vol 4) contains an article 'Secure Software Development - The Role of IT Audit' (B L Ciaramitaro and J Livermore).  Essentially this article complains about:

• the lack of software construction security standards,
• the disconnect between software developers and security specialists,
• the failure of tertiary education to teach computer science students how to write secure software,
• and the fact that IT audit is failing to address security controls in software development.

All of this seems to be true and as a consequence businesses are spending billions of dollars each year recovering from security breaches due to insecure software.

A challenge to those developing IT audit programmes anywhere where software is being developed, is to proactively address this shortfall by introducing sofware programming security audits. The 'Secure Programming Standards Methodology Manual' (SPSMM at http://www.isecom.info/mirror/spsmm.0.5.1.en.pdf) provides a good insight into the kind of software vulnerabilities that exist and the kind of security techniques needed to deal with them.

As with most IT auditing, which can be conducted at several levels, the key here is to ensure that:

• there are security policies that address software construction,
• the contents effectively refer to techniques such as those described in the SPSMM,
• there are management and construction processes applying those policies (such as peer reviews and testing),
• and that there is good evidence that these processes are working.