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 eventshence much
  broader than the usual concept.
• In the UK, there are three elements to security
  (in a narrow sense) often listed
• Confidentialityprotection of data from
  unauthorized access.
• Integrityprotection of data from unauthorized
  modification. More generally, certain desirable
  conditions are maintained over time
• Availabilitythe system is usable by authorized
  users.
• Trust is also becoming importantvarious
  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 monolithicthat 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.

51
Some Important Network Interpretations for C2
Systems

• User documentation should describe user visible
  protection mechanisms at the global (network
  system) level and at the user interface of each
  component, and the interaction among these.

52
Some Important Network Interpretations for C2
Systems

• The manual shall contain specifications and
  procedures for the network configuration.
• The hardware configuration of the network itself
  
• Attaching new components to the network
• The case where certain components may
  periodically leave the network and then
  rejoin
• Network configuration aspects that can impact
  the security of the network system
• Loading or modifying NTCB software or
  firmware
• Any assumptions about security of a given
  network should be clearly stated.

53
Communications Service

• The communications service itself has to be
  evaluated in terms of
• Design encapsulation
• Testing
• Design verification
• Configuration management
• Network control

54
Network Security Services

• Communications integrity
• Authentication, field integrity, and
  non-repudiation
• Denial of service (DoS)
• Continuity of operations, protocol-based
  protection from DoS, and network management
• Compromise protection
• Data confidentiality, traffic flow
  confidentiality, and selective routing

55
TCSEC and Commercial Systems

• Examples of Class D systems
• Windows 98
• MacOS 9
• Examples of Class C2
• Windows NT
• Windows XP
• Unix and Linux
• MacOS X
• Example of Class A1
• DEC built a VAX system to A1 standard The Brick

56
The TCSEC in Practice

• Experience with the TCSEC was negative. It was
  used as the basis for the evaluation of a number
  of systems, but the following issues were
  encountered
• Enormous bureaucracy and paperwork burden
• Any hardware or software change forced
  reevaluation of the entire system
• Eventually, formal evaluation was abandoned, and
  this led to the development of the Common
  Criteria.

57
Common Criteria

• A International standard extending the TCSEC
• Different approachno certification, rather the
  vendor documents the security requirements met by
  the system in a Protection Profile (PP) using a
  standard security taxonomy. The user then
  compares their security requirements (defined in
  the same taxonomy) against the PP. Evaluation
  still key.
• CCTool is an expert system to support the
  process.
• A bit behind the power curve.

58
Practical Experience

• The security problems over the last few years
  have
• Confirmed the correctness of the TCSEC/CC
  requirements.
• Provided a great deal of experience with
  practical security. The TCSEC/CC has not been
  particularly useful in dealing with the current
  threat.
• We probably know enough now to rewrite the
  TCSEC/CC in much greater detail.

59
Lessons Learnt

• The TCSEC standards were definable, but
  certification of systems with varying software
  and hardware to those standards was impossible.
• Certification of systems as meeting the Common
  Criteria is still a serious burden.
• We are beginning to understand what beyond the
  Common Criteria has to be done.

60
Assessment

• The original problem was understanding how to
  secure a system formally. That was either
  solvable (single computers) or infeasible
  (networks). Now there are two open problems
• How to make confidentiality, integrity,
  availability, and trust compatible.
• How to address the practical problems of securing
  systems on the network.
• Welcome to the future