Practical IT Security: Summary of Chapters 1-8
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.
The following based on the authors experience and a checklist for system security,
published by the UK ITSEC scheme [uk1] 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
- 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
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.
Class : Public / non classified data
Class : Internal data
Class : Confidential data
Class : Top Secret data
|Maximum allowed Server downtime, per event
|Available on which Days?
|During what hours?
|Expected availability percentage
||= 1 day/week
||= 2 hours/week
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.
- Data shall be accurate & complete:- Systems integrity (e.g. database, filesystem,
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
- 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
- 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
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
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.