previous  next  Title  Contents  Index   Last Update: 21 Jul 2000


5 Requirements on systems

5.1 System Model
5.2 Availability requirements
5.3 Sensitivity requirements

5.3.1 Class Requirements: Public / non classified data
5.3.2 Class Requirements: Internal data
5.3.3 Class Requirements: Confidential data
5.3.4 Class Requirements: Top Secret data
5.3.5 Requirements: Summary of relationship to Orange Book Classes

5.4 Component security checklist


The security required of a system depends on what information it processes, for what purposes. The information and information processing functions should have sensitivity and availability labels (i.e. be classified, as in the preceding chapter), so that the security needs to the system can be specified.

The security needs of the system may concentrate on availability, confidentiality or integrity, for example:

In the following sections, a set of requirements are proposed, based on the sensitivity and availability classes proposed in the previous chapter.

5.1 System Model

Systems need to be broken down into components and the security of each component analysed. When a user access data, he passes through a variety of possible security controls, or components. Some of these controls are physical, some organisational and some are computer based. The following is one way of representing the components /controls involved.

For data to be secured each of the different layers (security components) from Physical to Operating system need to be correctly configured and monitored. It is not enough to simply secure the physical access for example, because access via the network may also be possible.

In using a model of this kind, it is possible to break down the measures needed to protect a system (or data) into subsystems which correspond to real-life software/hardware/human entities.

In this chapter requirements are defined, in part II & III of the document, guidelines are proposed for securing each of the layers in the above model.

5.2 Availability requirements

The following specifies requirements on systems and organisation for each availability class.

Title Detail
Backup concept A backup and restore policy must exist. X X X X

Test restore policy regularly!

1/Year 1/Year 1/Year 1/Year

Minimum frequency of regular backups.

weekly daily daily daily

Minimum frequency of off-site backups.

  monthly weekly weekly
Environment

Air Conditioning

    X X

Electromagnetic protection (EMP hardening)

      X

UPS (220V protection)

    X X
Organisation

Clearly defined support organisation.

  X X X

Documentation of availability measures, recovery procedures, disaster plans (virus outbreak, security breach, fire, power failures etc.)

  X X X

Change management (Updates/patches/new SW)

  X X X

Effective (if possible automated) log monitoring and alerts.

  X X X

Prevention of resource abuse

  X X X

Service slots must be defined. Regular maintenance planned.

  X X X

24 Hour personnel

      X

Help Desk (reaction times, escalation procedures).

    X X
Redundancy (hw/sw)

Hardware spares or Vendor maintenance contract.

  X X X
 

Database servers: RAID, Replication, transaction monitors.

    X X

Naming servers (NT, NIS+, DNS, NIS...): backup/replica servers.

    X X

File Servers: Mirroring, RAID 5, file replication.

    X X

Complexity / ease of maintenance is also important for availability. Complex, difficult to maintain systems will have a high probability of misconfiguration (unless expert system administrators are available) and hence increase the security risk.

5.3 Sensitivity requirements

The requirements proposed here for each of the sensitivity classes to are based on the American DoD (Department of Defense) Orange Book [tcsec] (see Appendix E) classes C1,C2 & B1 and the European Orange Book (or ITSEC) [itsec] class F-DX for secure communications requirements. Basing requirements on international standards such as these is preferred, since inter-company security policy may be more easily defined and these standards have been already tried & tested by other companies.

5.3.1 Class Requirements: Public / non classified data

Class requirements are not based on any standard, but "common sense". These requirements stipulate a minimum to be achieved by all systems in a company.

Even systems non-sensitive data should have a minimum security level (especially if they are networked), otherwise they could be used as a point of entry for attacks on more confidential systems.

5.3.2 Class Requirements: Internal data

Summary: Orange book C1 (Discretionary Security Protection).
C1 is used for co-operating users working with data of the same sensitivity level.

5.3.3 Class Requirements: Confidential data

Summary: Orange book C2 + secure data transmission.

5.3.4 Class Requirements: Top Secret data

Summary: Orange book B1 + secure data transmission.

5.3.5 Requirements: Summary of relationship to Orange Book Classes

The following shows roughly how the data sensitivity classes to devised in this document relate to orange book classes D-B1.

Title Detail Orange Book Reference D C1 C2 B1
  Data Sensitivity Class
Documentation Test documentation
Design documentation,
Security features user manual,
Trusted facility manual
  + + +
Assurance System architecture verification
Hardware/firmware integrity checking
Security testing (test for loopholes)
  + + +
Accountability User identification /authorisation   + + +
  Audit Trail (Beweissicherung)     + +
Access control Discretionary access control     + +
  Object reuse :Reinitialisation of objects.     + =
Labels Labels, integrity, human readable output.       +
Verification Specification and design verification       +
Exporting of labelled information to multilevel & single level devices.       +
Requirements in addition to the Orange book:          
Secure data exchange Peer entity authentication   + + =
  Data integrity     + =
  Data confidentiality     + =
  Data origin authentication / Non repudiation of origin     + +
  Non repudiation of receipt     + +
  Access control       +

Legend:
+ means as previous class with additional requirements.
= means same requirements as previous class.

5.4 Component security checklist

It is suggested that individual components of a system and systems as a whole be analysed according to the following checklist.
I. Documentation: Are the system security features well documented? Security Features User's Guide, System Administrators Guide to Security, Test documentation, Design documentation.
II. Assurance : How can one be sure that the systems does what it should do? :- System Architecture, System Integrity, Security Testing. Has the system been certified to meet known standards?
III. Accountability : Users shall be accountable for their actions.

IV. Access Control :

V. Secure data exchange / network communications

VI. Availability


[2] On UNIX systems, this means that shadow password files are required.


previous  next  Title  Contents  Index  IT Security Cookbook, 21 July, 2000