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:

• A system may not contain confidential data, but it must be available 24 hrs a day - so it has low data sensitivity, but high availability requirements. High availability systems always require better confidentiality to prevent "denial of service" attacks.
• For other systems confidentiality (i.e. non disclosure of information) is more important than integrity (modification of information), for others the reverse is true.

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.

• The Orange Book specifications for Classes C1 and C2 is included in appendix E. A brief summary of the relevant Orange Books classes is included below.
• The Orange Book classes use the notion of a Trusted Computing Base (or TCB) extensively. This is the central part of the system (e.g. the kernel) which is trusted to carry out security functions.

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.

• Network sniffing software should not be installed.
• A virus scanner should be installed (DOS/Windows).
• Accounts should only exist for authorised persons and must always have a password.
• Screen locking with password protection should be activated automatically after 15 minutes idle time.
• Write access to network filesystems should be restricted to groups of users or machines.
• Communications software (NFS, LanManager, RAS, PPP, UUCP, Workgroups..) should be correctly installed with security options enabled.

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.

• Documentation: test, security design philosophy, security features user guide (description of security mechanisms from users point of view), trusted facility manual (i.e. security administration guide).
• Assurance: System Architecture: does the TCB run in protected mode?. Functions should exist for checking hardware & firmware integrity. Have the security mechanisms been successfully tested?
• User identification and authorisation is required, along with protection of authorisation data[2].
• Discretionary access control: access is controlled between named users (or user groups) and named objects.

5.3.3 Class Requirements: Confidential data

Summary: Orange book C2 + secure data transmission.

• C2 (Controlled Access Protection):
  • As C1 plus additional requirements for: trusted facility manual (describe C2 mechanisms), identification & authorisation (no group accounts may exist), discretionary access control (control assignment of privileges) and security testing (test C2 mechanisms).
  • User accountability: Users are accountable for their actions. Audit trails should be available with monitoring and alert functions. Audit logs should be protected.
  • Object Re-use: Objects used by a subject should be reinitialised before use by an other subject. i.e. should not be possible to compromise security by reuse of objects.
• Secure data transmission : When sending messages or when programs communicate with each other, privacy and completeness (i.e. confidentiality and integrity) must be maintained.
  For certain applications it may also be necessary that the receiver be absolutely sure that the information comes from the sender and not someone else. This is called non repudiation of origin. It may also be required that the sender must be sure that the message was received by the intended receiver - non repudiation of receipt.

5.3.4 Class Requirements: Top Secret data

Summary: Orange book B1 + secure data transmission.

• B1 (Labelled Security Protection):
  • As in C2 plus additional requirements for identification & authentication (maintain security compartment information), trusted facility manual (B1 mechanisms & how to change security compartment), design manual (description of the security model & mechanisms), assurance (system architecture: process isolation, integrity checking, security testing: try penetration attacks & remove flaws) and auditing (log security levels of objects).
  • Labels : Maintain sensitivity labels under control of the TCB, Input/output of labelled information, label integrity (linked to objects), label human readable output, single & multi-level I/O.
  • Verification of specification & design: Does the system behave according to the Design Manual?
  • Exporting of labelled information, exporting to multilevel and single level devices.
  • Mandatory access control: access control for objects & subjects is specified by the TCB (i.e. not the user).
• Not part of B1 is Covert channels and trusted path analysis. They may be necessary for some systems. Class B2 includes these an other further requirements.
• Secure data transmission: as .

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.

• Identification / authentication: Users must be uniquely identified (e.g. usernames + login) and be authenticated (e.g. via passwords). Authentication data must be protected.
• Audit Trail :
  • A record of who did what, from which terminal, on what machine, when, with what object and whether successful or not should be maintained.
  • Events for logging: Identification/Authorisation, Access rights administration, creation/deletion of sensitive objects, actions affecting security of the system.
  • Logs must be protected (confidentiality, integrity e.g. file permissions) and should be regularly monitored and when necessary (automatically) security alerts raised.
  • Tools should exist for manipulating audit trails and should allow actions of a particular user to be identified (in an understandable fashion).

IV. Access Control :

• Discretionary access control: The system shall distinguish and administer access rights between users, groups of users, objects (e.g. permissions on filesystem, shared memory, floppy drives, printers, devices, network services, menu options, application options).
• Mandatory access control : access control for objects & subjects is specified by the TCB (i.e. not the user).
• Secure system startup - components should startup securely.
• Object reuse : Objects used by a subject must be reinitialised before being used by another subject.

V. Secure data exchange / network communications

• Network Peer entity authentication: Both sides (users & processes) must identify & authenticate themselves (have their identity verified), prior to the exchange of data.
• Network Data integrity: Data must remain complete during transmission. Unauthorised manipulation of user data, audit trail data and replay of transmissions should be reliably identified as errors.
• Network Data confidentiality: Only authorised persons should be able to access the data. (e.g. end-to-end data encryption)
• Data origin authentication : Does the receiving process know who the data is coming from? For class systems, non repudiation of origin may be required: On receipt of data, it should be possible to uniquely identify and authenticate the sender of the data. Has the receiver proof of where information came from? This can be achieved by the use of digital signatures.
• Non repudiation of receipt : Has the sender proof that the information sent was received by the intended receiver?
• Access control : All information previously transmitted which could be used for unauthorised decryption should only be accessible to authorised persons.

VI. Availability

• Backup: Backup and restore policies shall exist and be tested regularly.
• Prevention of resource abuse : e.g. Quotas, CPU, memory, process limits per user.
• Patches/change management : careful, precise procedures are required for updates, or configuration changes to production systems. A "change log" should be kept up to date.
• Environment : air conditioning, cabling, norms.
• Disaster Recovery : Plan for Power failures (UPS), fire and flooding, security breach.
• Organisation : Defined support procedures, roles and responsibilities with service level agreements, documentation of procedures, service slots, 7x24H ().
  Disposal of equipment.
• Redundancy : Redundancy is possible on many levels. CPU, disks, disk drivers, network, transport (e.g. OLTP), application (e.g. NIS+, Lan Manager, DNS) and complete system (e.g. HACMP). Redundancy should be regularly tested.

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

         IT Security Cookbook, 21 July, 2000