P. 1
Computer Security 1

Computer Security 1

4.5

|Views: 1,413|Likes:
Published by ranjithmahesh8417

More info:

Published by: ranjithmahesh8417 on Feb 17, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF or read online from Scribd
See more
See less

05/01/2013

REQUIREMENT FIVE
CLASS THREE

ASSURANCE

The computer system must contain hardware and
software mechanisms that can be independently
evaluated to provide sufficient assurance that the
system enforces requirements one through four
above.

Assurance usually gets confused with guarantee. An assurance is a
believable assertion that things should not go wrong and a commitment to
fix the system if they do go wrong. A guarantee is a useless protection
against unauthorised observation. That which has been seen, particularly
when it is unauthorised, is unlikely to be ignored or forgotten.
Documented guarantees are accompanied by emphatic assertions about
the good intentions and the resolve of the guarantor. An assurance is a
demonstration that some level of confidence can safely be placed in the
guarantee. The distinction is important and the assurance is the
important thing, because the security policy establishes the required
guarantee.

All the Generally Accepted Standards of Good Practice (GASGPS)
that have been developed in general engineering practice and in software
engineering must be deployed to develop a high level of confidence that
the system meets the policy. Without going into much detail, a system
that could be considered to have high assurance of enforcing the policy is
one that

has been specified to meet some particular requirement and that

has been designed to meet the specification and that

has the right hardware configuration and that

has been documented thoroughly before it is built, including testing
and that

27

has been written by disciplined programmers according to the
specification and that

passes all tests and that

is highly resistant to penetration by a team of experienced security
personnel (often called a tiger team, for unknown reasons ) even
when they are provided with the entire specification, the
documentation and the source code.

All this, regrettably, is not enough in the most sensitive case. The
assurance developed by the method described above finally boils down to
proof by emphatic assertion. No absolutely convincing proof, in the
meaning of the word in logic, will have been developed. As will be shown
later, in the most demanding cases it is necessary to construct an abstract
mathematical model of the system and to show that

once the abstract model of the system gets into a secure state it can
not be driven into a state where insecurity is possible and that

the actual system is an instance of the abstract model and conversely
and that

the many details that erupt when the abstraction is solidified are not
in themselves a problem and can be proven to be consistent with the
abstraction and that

the system can fail and recover from failure securely.

We will look into abstract models in a later essay.

REQUIREMENT SIX
CLASS THREE

CONTINUOUS PROTECTION

The trusted mechanisms that enforce these
basic requirements must be continuously
protected against tampering or unauthorised
changes.

This merely states the obvious. The system must protect itself
against meddlers. Much of the material discussed above in requirement
five applies directly to this case. Requirement six applies to the entire
development cycle and can at the higher levels of assurance involve
detailed methodologies to be used at the time software is written to guard
against the inclusion of Trojan horses or other unwanted excrescences.

28

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->