Previous  Next  Top  Detailed TOC    Last Update: 20 Jun 2000

15. Operating Systems (OS) Overview

• Assurance
  • Conformance with the TCSEC (Orange Book) requirements
  • Conformance with the ITSEC requirements
• Recommendations

Assurance

It is useful to refer to established standards to be assured that a system offers a certain level of security and can be relied upon to guarantee this level of security. The current standards TCSEC [tcsec] and ITSEC [itsec] are basically military standards, increasingly being adopted in the commercial world (see Appendix C for details on these and other emerging standards such as TTAP and Common Criteria).   Another useful reference is the IT Baseline protection manual from the German equivalent of the NSA,  the BSI (Bundesamt fuer Sicherheit in der Informatik). It can be accessed online, or a CD can be had for free.

Even if a system is evaluated to a certain level (e.g. TCSEC C2), it still requires careful configuration, monitoring and organisation processes for it to be considered "secure" in a real production environment. Don't attach too much importance to the "label" C2 for it's own sake. It is often used as a sales pitch without real substance. E.g. a system may offer "C2 auditing", but that doesn't mean that the audit logs are useful, or that tools for high level analysis of these logs are included in the system, or that anyone actually reads the logs!

The NSA have produced an interesting paper (Nov.'98) which argues that the threats posed by the modern computing environment cannot be addressed without secure operating systems. See csrc.nist.gov/nissc/1998/proceedings/paperF1.pdf .

Conformance with the TCSEC (Orange Book) requirements

See Appendix C  or Trusted Product Evaluation Program for a more detailed discussion of TCSEC. C2 is the TCSEC level aimed for by most commercial operating systems.

A key notion in the TCSEC is the idea of a TCB (Trusted Computing Base). A TCB must provide: protection from interference with the TCB, address space separation, trusted path, least-privilege principle, continuity of operations.

• Some UNIX's are very insecure in their default configuration (e.g. BSD variants such as SunOS 4.1.3, Ultrix..). UNIX systems without password shadowing do not even conform to C1. However most vendors now have shadowing as standard (Solaris, OSF, AIX), or offer it as an option (HP-UX).
• Conceptually, modern UNIX systems fulfil C2 requirements, except for auditing. For this reason, many vendors include or offer a C2 package, which enhances the auditing capabilities.
• UNIX can achieve B1 with changes in functionality. For B2, core structures and mechanisms need to be changed. B3 requires conceptional and structural changes to UNIX.
• DOS/Windows/Windows9x systems cannot be evaluated, since there is no TCB. The OS cannot conform to the TCB requirements listed above. The user cannot be prevented from having full control of the system
• Windows NT 3.5 (service pack 3) has achieved C2 evaluation (Aug.95), but only in a non-networked configuration and without the WOW (Windows on Windows) subsystem. These restrictions were apparently to speed up evaluation time! So the C2 classification is not what one might expect. However, NT also satisfies the B2 Trusted Path and Trusted Facility Management requirements.
• NT 4.0 SP3 was ITSEC E3/F-C2 evaluated (see ITSEC below). Contrary to the C2 evaluation of NT 3.5 (see above), this one is for both Server and Workstation, in a networked configuration, and with more realistic peripherals. For TCSEC submission, see  www.radium.ncsc.mil/tpep/epl/bulletin/entries/NCSC-PB-98-003.html .

The following shows a selected list of commercial, well known OS's evaluated by the NSA under TCSEC (see [nsa1]) in Spring 1996 (sorry, I don't have a newer list..).

Conformance with the ITSEC requirements (Sept.99)

The ITSEC (see [itsec] and [itsem]) is described in detail in Appendix C. It is a European alternative to TCSEC and more complete.

ITSEC separates functionality and assurance. There are assurance levels E1 through E6. It defines example functionality classes F-C1, C2, B1, B2, B3 which correspond to the TCSEC classes and the new classes IN, AV, DI, DC and DX which are interesting because they include networking (which is missing from TCSEC). The ITSEC and TCSEC correspond as follows:

ITSEC TCSEC
E1, F-C1 == C1
E2, F-C2 == C2
E3, F-B1 == B1
E4, F-B2 == B2
E5, F-B3 == B3
E6, F-B3 == A1

ITSEC defines the following functionality classes in addition to TCSEC:

IN This class is for systems with high integrity requirements for data & programs.
AV This class is for systems with high availability functions.
DI This class is for systems with high integrity requirements for data transmission.
DC This class is for systems with high confidentiality requirements for data transmission.
DX This class is for systems with high integrity & confidentilaity requirements for data
transmission.

ITSEC suggest that requirements be analysed under the headings: Accountability, Identification & Authentication, Audit, Object Reuse, Access Control, Accuracy, Data Exchange and Reliability of Service. Mechanism or countermeasure strength is defined as being basic, medium or high.

Recommendations

• It is recommended to use an Operating System which includes standard security precautions such as newer UNIX's (e.g. SVR4, Solaris 2, AIX 4.1, OpenBSD, Suse 6.x) or NT. It is also preferable to minimise the number of different OSs installed. e.g. all UNIX variants differ, meaning security administration is more complex and error prone. If possible use just SVR4 compatible UNIX's (e.g. Solaris 2.x), or well supported (on the Internet) versions with source code (e.g. OpenBSD, Linux) for reasonable security in the default configuration, better application packaging, patch management and easier administration.
• Use ITSEC and ITSEM (or alternatively the Common Criteria or TCSEC) when writing security requirements or evaluating systems and consider buying approved/certified systems.
• See also the

The following is based on the author's experience, it is by no means an absolute reference:

Naming systems: NIS+ or DCE are much more secure than NIS, but also more complex. See the UNIX chapter and the Firewalls chapter.

SVR4.1 ES (Enhanced Security): Multi level Security (MLS) MLS is an (AT&T) add on to an underlying SVR4 UNIX system. Some kernel modules and utilities are replaced, but kernel data structure changes are minimal. Mandatory access control (MAC) is implemented (using UID, GID). Auditing tools are also included.

NT still is relatively young, but Microsoft seem to be moving away from their traditional stance of Security through Obscurity - they now publish regular security advisories. They still insist on not following crypto standards where possible (e.g. PKCS#11, IPsec) and don't submit code for peer review, so NT is not (yet) recommended for class or above. However NT is advancing faster than UNIX and it's security architecture is good. It may become the OS to beat in the coming years...... if Microsoft can resit the temptation of messing up the OS by integrating Internet Explorer.. 

On the other hand Linux has become stable, fast and feature rich and Sun are offering Solaris 8 free (with a bundles Firewall), so the future will be interesting.

I suppose you've guessed that my favourites are Solaris, Linux & NT. In fact, the best thing about Solaris is the solid SPARC hardware with it's intelligent boot prom.

For a comparison on NT and UNIX from the developers perspecitive see AdNovum's article, which summarises:
NT is certainly not a "toy operating system" (anymore). Although it does not scale very well ... (Performance decreases with more than 4 processors/server) it should yield satisfactory performance for small businesses with fewer than 250 user accounts that do not run mission critical processes. Beside fundamental scalability issues, manageability and availability remain the critical issues.

            Previous   Next  Top  Detailed TOC    IT Security Cookbook, 20 June, 2000