History of Security Standards

1. History of Security Standards University of Sunderland CSEM02 Harry R Erwin, PhD

2. Roadmap • History • Multics • The Bell/LaPadula Model • The TCSEC (Orange Book) standards • The TNI (Red Book) standards • Recent Practice • Common Criteria • Protection Profiles • Assessment

3. Resources • Karger, P.A. and R.R. Schell, Thirty Years Later: Lessons from the Multics Security Evaluation. RC 22534 (W0207-134), July 31, 2002, IBM Research Division: Yorktown Heights, NY. • Bell, D.E. and L.J. LaPadula, Secure Computer Systems: Unified Exposition and Multics Interpretation. MTR 2997, April 1974, The MITRE Corporation: Washington DC. • Department of Defense Trusted Computer System Evaluation Criteria. DoD 5200.28-STD, December 26, 1985, Department of Defense: Washington DC. • Trusted Network Interpretation. NCSC-TG-005, July 31 1987, National Computer Security Center: Washington DC.

4. More Recent Resources • Stoneburner, G., CSPP - Guidance for COTS Security Protection Profiles. NISTIR 6462, December 1999, NIST: Gaithersburg, MD. • Information technology - Security techniques —Evaluation criteria for IT security —Part 1: Introduction and general model. ISO/IEC 15408-1: 1999 (E), December 18, 1998, ISO/IEC. • Information technology - Security techniques —Evaluation criteria for IT security —Part 2: Security functional requirements. ISO/IEC 15408-2: 1999 (E), December 18,1998, ISO/IEC. • Information technology - Security techniques —Evaluation criteria for IT security —Part 3: Security assurance requirements. ISO/IEC 15408-3: 1999 (E), December 18, 1998, ISO/IEC.

5. Other Papers • Thompson, K., Reflections on Trusting Trust. Communications of the ACM, 1984. 27(8): p. 761-763. • Thompson, K., On Trusting Trust. Unix Review, 1989. 7(11): p. 70-74. • Karger, P.A., M.E. Zurko, et al, A Retrospective on the VAX VMM Security Kernel. IEEE Transactions on Software Engineering, 1991. 17(11): p. 1147-1165. • Biba, K.J., Integrity Consideration for Secure Computer Systems. ESD-TR-76-372, MTR-3153, April 1977, The MITRE Corporation: Bedford, MA.

6. History • Multics • Unix • TCSEC • Common Criteria • Current Practice

7. Security • ‘Freedom from undesirable events’—hence much broader than the usual concept. • In the UK, there are three elements to security (in a narrow sense) often listed: • Confidentiality—‘protection of data from unauthorized access.’ • Integrity—‘protection of data from unauthorized modification.’ More generally, certain desirable conditions are maintained over time • Availability—‘the system is usable by authorized users.’ • Trust is also becoming important—various relationships between a trustor and a trusted entity.

8. Multics • A USAF operating system, 1965-1976, designed to provide multi-level security (MAC) for a command and control system. Conceptually based on CTSS, the first time-sharing system at MIT. • Security was designed into the system. Smaller security kernel than SELinux (2.5 times). • Remains considerably more secure than Windows XP and UNIX/MacOS X • Primary worked example of class B2 security (cf). • ‘no buffer overflows’, but still vulnerable to malicious software.

9. Areas of Concern • Malicious developers • Trapdoors during distribution • Boot-sector viruses • Compiler trapdoors (see the papers by Ken Thompson)

10. Auditing and Intrusion Detection • Discovered it could be bypassed during the installation of malicious software, either by modification/deletion of the audit records or by experimenting with a duplicate machine to see what would be detected.

11. Multics Report Conclusions • Classes C2 and B1 only suitable for benign, closed environments. • Class A1 required for open, hostile environments. Class A1 requires proving the system is secure. This leads to the topic of models.

12. Security Models • A security model is a set of rules that can be formally proven to enforce a security policy. • There are models for confidentiality, integrity, and availability. These models conflict, and there is no model for trust. • The oldest of these models is the Bell/LaPadula model. • A good integrity model of the time is Biba.

13. The Bell/LaPadula Model • Abstract representation of computer security as it applies to classified information. The goal is to control the access of active subjects to passive objects according to a defined policy. • Modes of access: read and write in various combinations. • Access permission is stored in a matrix. • Security classifications are defined as level and compartment (e.g., TOP SECRET ULTRA).

14. Security Access Rules • Simple security property: for a subject to access an object, the level and compartments of the subject must dominate those of the object. (Dominant levels are higher and dominant compartments are supersets.) • The *-property prevents a malicious subject from ‘leaking’ information: if a subject has read access to document A and write access to document B, then the level and compartments of document B must dominate those of document A. • Finally, anything not prohibited is allowed. This is known as the discretionary property.

15. BP and Security • The Bell/LaPadula model can be implemented in a security kernel and will work correctly. • The kernel has to be monolithic—that is a single thread mediates all access and that thread handles all accesses atomically. • Implication: distributed security cannot enforce the BP model. It can only detect after the fact that a violation has occurred (Abrams, personal communication). This resulted in the withdrawal of the Trusted Network Interpretation (q.v.). • An utter pain operationally as objects emerging from the process are highly classified.

16. The Covert Channel Problem • Early in the development of computer security, covert channels were discovered. • A covert channel is a communication channel that can be exploited to transfer information in a manner that violates the system's security policy. • Two types of covert channels: • storage channels and • timing channels. • 100 bits per second very bad and 1 bit per second tolerable and common. Remains a problem today.

17. UNIX • UNIX security was designed in direct opposition to Multics. • It enforces discretionary rather than mandatory access, relying on the owners of the objects to judge who may have access. • Intended for a benign environment where users are trusted. “System high” security. • Covert channels not an issue. • Basis (with development) for class C2.

18. The TCSEC (Orange Book) Standards • Descriptions from the standard • Class D • Class C1 • Class C2 • Class B1 • Class B2 • Class B3 • Class A1

19. Class D • This class is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class. • Older operating systems.

20. Class C1, Discretionary Security Protection The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class (C1) environment is expected to be one of cooperating users processing data at the same level(s) of sensitivity.

21. Class C2, Controlled Access Protection • Systems in this class enforce a more finely grained discretionary access control than (C1) systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation. • Current commercial operating systems.

22. Class B1, Labelled Security Protection Class (B1) systems require all the features required for class (C2). In addition, an informal statement of the security policy model, data labelling, and mandatory access control over named subjects and objects must be present. The capability must exist for accurately labelling exported information. Any flaws identified by testing must be removed.

23. Class B2, Structured Protection In class (B2) systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found in class (B1) systems be extended to all subjects and objects in the ADP system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and non- protection-critical elements. The TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration management controls are imposed. The system is relatively resistant to penetration.

24. Class B3, Security Domains The class (B3) TCB must satisfy the reference monitor requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security-relevant events, and system recovery procedures are required. The system is highly resistant to penetration.

25. Class A1, Verified Design Systems in class (A1) are functionally equivalent to those in class (B3) in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping with the extensive design and development analysis of the TCB required of systems in class (A1), more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported.

26. Fundamental TCSEC Requirements • Security Policy • Marking • Identification • Accountability • Assurance • Continuous Protection

27. Security Policy There must be an explicit and well-defined security policy enforced by the system. Given identified subjects and objects, there must be a set of rules that are used by the system to determine whether a given subject can be permitted to gain access to a specific object. Computer systems of interest must enforce a mandatory security policy that can effectively implement access rules for handling sensitive (e.g., classified) information. These rules include requirements such as: No person lacking proper personnel security clearance shall obtain access to classified information. In addition, discretionary security controls are required to ensure that only selected users or groups of users may obtain access to data (e.g., based on a need-to-know).

28. Marking Access control labels must be associated with objects. In order to control access to information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object's sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object.

29. Identification Individual subjects must be identified. Each access to information must be mediated based on who is accessing the information and what classes of information they are authorized to deal with. This identification and authorization information must be securely maintained by the computer system and be associated with every active element that performs some security-relevant action in the system.

30. Accountability Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party. A trusted system must be able to record the occurrences of security-relevant events in an audit log. The capability to select the audit events to be recorded is necessary to minimize the expense of auditing and to allow efficient analysis. Audit data must be protected from modification and unauthorized destruction to permit detection and after-the-fact investigations of security violations.

31. Assurance The computer system must contain hardware/software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces requirements 1 through 4 above. In order to assure that the four requirements of Security Policy, Marking, Identification, and Accountability are enforced by a computer system, there must be some identified and unified collection of hardware and software controls that perform those functions. These mechanisms are typically embedded in the operating system and are designed to carry out the assigned tasks in a secure manner. The basis for trusting such system mechanisms in their operational setting must be clearly documented such that it is possible to independently examine the evidence to evaluate their sufficiency.

32. Continuous Protection The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or unauthorized changes. No computer system can be considered truly secure if the basic hardware and software mechanisms that enforce the security policy are themselves subject to unauthorized modification or subversion. The continuous protection requirement has direct implications throughout the computer system's life-cycle.

33. Class C2 Requirements • Discretionary Access Control • Object Reuse • Identification and Authentication • Audit • System Architecture • System Integrity • Security Testing • Documentation (TCB = Trusted Computing Base)

34. Discretionary Access Control The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users.

35. Object Reuse All authorizations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system.

36. Identification and Authentication The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual.

37. Audit The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction or objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers, and other security relevant events. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity.

38. System Architecture The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements.

39. System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.

40. Security Testing The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. Testing shall also include a search for obvious flaws that would allow violation of resource isolation, or that would permit unauthorized access to the audit or authentication data. (See the Security Testing guidelines.)

41. Documentation • You must provide: • Security Features User's Guide • Trusted Facility Manual • Test Documentation • Design Documentation

42. TNI (Red Book) • Trusted Network Interpretation • Interpretations of the TCSEC for networks • Added security services • Did not include • COMSEC • Emanations security • Physical security • NTCB means the Network Trusted Computing Base.

43. Some Important Network Interpretations for C2 Systems • Note that “users” do not include “operators,” “system programmers,” “technical control officers,” “system security officers,” and other system support personnel. They are distinct from users and are subject to the Trusted Facility Manual and the System Architecture requirements. Such individuals may change the system parameters of the network system, for example, by defining membership of a group. These individuals may also have the separate role of users.

44. Some Important Network Interpretations for C2 Systems • Policies: • SECRECY POLICY: The network sponsor shall define the form of the discretionary secrecy policy that is enforced in the network to prevent unauthorized users from reading the sensitive information entrusted to the network. • DATA INTEGRITY POLICY: The network sponsor shall define the discretionary integrity policy to prevent unauthorized users from modifying, viz., writing, sensitive information. The definition of data integrity presented by the network sponsor refers to the requirement that the information has not been subjected to unauthorized modification in the network.

45. Some Important Network Interpretations for C2 Systems • When group identifiers are acceptable for access control, the identifier of some other host may be employed, to eliminate the maintenance that would be required if individual identification of remote users was employed. However, it must be possible from that audit record to identify (immediately or at some later time) exactly the individuals represented by a group identifier at the time of the use of that identifier.

46. Some Important Network Interpretations for C2 Systems • The NTCB shall ensure that any storage objects that it controls (e.g., Message buffers under the control of a NTCB partition in a component) contain no information for which a subject in that component is not authorized before granting access. This requirement must be enforced by each of the NTCB partitions.

47. Some Important Network Interpretations for C2 Systems • In cases where the NTCB is expected to mediate actions of a host (or other network component) that is acting on behalf of a user or group of users, the NTCB may employ identification and authentication of the host (or other component) in lieu of identification and authentication of an individual user, so long as the component identifier implies a list of specific users uniquely associated with the identifier at the time of its use for authentication. This requirement does not apply to internal subjects.

48. Some Important Network Interpretations for C2 Systems • The sponsor must select which events are auditable. If any such events are not distinguishable by the NTCB alone, the audit mechanism shall provide an interface, which an authorized subject can invoke with parameters sufficient to produce an audit record. These audit records shall be distinguishable from those provided by the NTCB.

49. Some Important Network Interpretations for C2 Systems • In the context of a network system, “other security relevant events” might require: • Identification of each access event • Identification of the starting and ending times of each access event • Identification of security-relevant exceptional conditions • Utilization of cryptographic variables • Changing the configuration of the network

50. Some Important Network Interpretations for C2 Systems • Testing of a component will require a testbed that exercises the interfaces and protocols of the Component including tests under exceptional conditions. The testing of a security mechanism of the network system for meeting this criterion shall be an integrated testing procedure involving all components containing an NTCB partition that implement the given mechanism. This integrated testing is additional to any individual component tests involved in the evaluation of the network system.