If you don't want to read any theory (i.e. the previous chapters), then read at least this part before going into the technical guidelines.
10.1 Brief Security Checklist
The following based on the authors experience and a checklist for system security, published by the UK ITSEC scheme [uk1] http://www.itsec.gov.uk/ .
- Is your software ITSEC or TCSEC (see appendix C) certified? Is it securely configured and installed? Are audits regularly carried out?
- Are your passwords secure (easy to guess, regularly changed, use of temporary & default passwords)? Can people see your staff entering passwords on their terminals and PCs? Are screens ever left logged on or unattended, however briefly? Are screens automatically locked after 10 minutes idle?
- Is your most valuable data encrypted?
- How accessible is your equipment; are PCs or servers anywhere near public areas?
- Do your staff wear ID badges? Are your computer areas physically secured? Do you check the credentials of external contractors?
- Do you have a machine dedicated to checking against viruses?
- Is waste paper binned or shredded? Do you have procedures for disposing of waste material?
- What do you do with old computer equipment? Are you sure old hard and floppy discs can't be read by someone else? Do you have a policy for allowing old or used computer components out of the building?
- Do you keep backup records? Do you have a system for archiving information? Are the archives kept in a secure environment? Are Restores regularly tested?
- Do you have rules about what can and cannot be sent over email and what may or may not be download from the Internet (or BBSs). What procedures do you have for remote logon or support?
Another way of looking at the problem is using the British standards institute [bsi1] list of "key controls":
- Information Security Policy Document
- Allocation of security responsibilities
- Information security education and training
- Reporting of security incidents
- Virus controls
- Business continuity planning process
- Control of proprietary copying.
- Safeguarding of Company records.
- Compliance with data protection legislation
- Compliance with security policy.
10.2 Classification Summary
Sensitivity Classes:
Class
: Public / non classified data
Class: Internal data
Class: Confidential data
Class: Top Secret data
Availability Classes
| Class |  |
|
|
|
| Maximum allowed Server downtime, per event | 1 Week | 1 Day | 1 Hour | 1 Hour |
| Available on which Days? | Mon-Fri | Mon-Fri | Mon-Fri | 7 Days |
| During what hours? | 07:00-18:00 | 24h | ||
| Expected availability percentage | 80% | 95% | 99.5% | 99.9% |
| = 1 day/week | = 2 hours/week | = 15min./week | = 10min./week |
10.3 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. Assurance: Documentation (Are the system security features well documented for Users and System Administrators Guide to Security, Test & Design documentation). Education: Are users and system administrators educated on secure system usage? Policy: Does a written Security Policy exist? System assurance :- Architecture, System Integrity, Security Testing. Has the system been certified to meet known standards?
II. Accountability/Responsibility : 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: Identificaton/Authorisation, Access rights administration, creation/deletion of sensitive objects, actions affecting security of the system.
* Logs must be protected (confidentiality, & integrity) and should be regularly monitored and when necessary security alerts raised (automatically).
* Tools should exist for manipulating audit trails and should allow actions of a particular user to be identified (in an understandable fashion).
III. 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 shall startup securely.
- Object reuse : Objects used by a subject must be reinitialised before being used by another subject.
IV. Accuracy
- Data shall be accurate & complete:- Systems integrity (e.g. database, filesystem, file) checking.
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. Reliability of Service/Availability/Contingency Planning
- 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. clusters). Redundancy should be regularly tested.
Notes: Points I-III are based on the TCSEC [tcsec] class C2 (or [itsec] E2 F-C2 - see appendix C), point IV come from ITSEC, point V is based on the ITSEC functionality class F-DX and point VI is based on experience.