Daattaa SSeeccuurriittyy

D C
Coonntteenntt ddeessccrriippttiioonn

Part 1
Information System Security & Security Policy
Keywords:
Security, Security Policy, Security Incident, Security Audit, Prevention, Detection, Recovery.

Summary:
Each member of the community must be responsible for the security and protection of electronic
information resources over which he or she has control.
Resources to be protected include networks, computers, software, and data. The physical and logical
integrity of these resources must be protected against threats such as unauthorized intrusions, malicious
misuse, or inadvertent compromise. Activities outsourced to off-campus entities must comply with the
same security requirements as in-house activities.
However, security policy must be fixed and maintained with the collaboration of managers,
administrative officials and users.

Objectives:
Upon completion of this part, the student will be able to understand:
• What is information security?
• The definition of information security and the factors to consider when maintaining security
• Why is security design necessary?
• The objective of security design and security requirements should be established.
• Definition of security policy and advantages/disadvantages of having a security policy.
• General outline of security policy.
• Considerations when writing security policy.
• What factors should be considered when writing a security policy.

Universal Knowledge Solutions S.A.L.

-1-
 Computer related crimes

• August 1995
o A 24 years old student accessed CitiBank's computer system and illegally transferred
2.8 million US dollars to his bank account.

• March 1999
o Mellissa, a computer virus attached to Microsoft Words, spread through the use of
emails.

• February 2000
o Denial of Service attacks caused major websites such as Yahoo.com, Microsoft.com,
ebay.com, cnn.com, amazon.com to go offline.

• March 2000
o Two 18 years olds hacked into Internet shopping websites, stole 26,000 credit card data,
and shopped up to an amount of 3 million US dollars, using the stolen credit card
information.

• January 2003
o Computer virus (or worms) Slammer (2003.1) and Blaster spread through the Internet
attacking the security holes on the servers and client PCs.

Computer related crimes

20000
18000
16000
14000
12000
10000
8000
6000
4000
2000
0
1988 1990 1992 1994 1996 1998 2000

CERT is a center of internet security expertise, located at the Software Engineering Institute, a
federally funded research and development center operated by Carnegie Mellon University.

Universal Knowledge Solutions S.A.L.

-2-
The center studies internet security vulnerabilities, research long-term changes in networked systems,
and develop information and training to help you improve security.

We in the slide the numbers of security incident in the united states reported to the CERT between
1988 and 2000.

What Does Security Means?

Security in a broad sense

Information System Security

Information System Security includes 3 Main Concepts:

• Confidentiality:
o Confidentiality is related to the READ Action
o It concerns part of the system and not necessary all the system

• Integrity:
o Integrity is related to the WRITE & MODIFY Actions
o It means that the current version is identical to a referential one

• Availability
o Availability is related to the EXECUTE Action
o It’s very difficult to implement it since DOS (Deny Of Service) attacks are easier than other
attacks.
o Actually computer systems try to reach 99.999% of availability.

Universal Knowledge Solutions S.A.L.

-3-
 Main Security Operations

• Access Control.
• Authorization
• Fault tolerance.
• Risk Management.
• Backup Policy.
• Disaster Recovery Policy.

Why is Security Design Necessary?

• Obtain the maximum effect at the minimum cost.

• Anticipate the types of threats that will occur in accordance with the characteristics:
o System Configuration:
ƒ Site distribution
ƒ Site connection to the networks
ƒ etc …
o Types of user:
ƒ How the systems are used and accessed?
ƒ Is the number of users limited or unlimited?
ƒ etc…
o Expected threats
ƒ Anti-Viruses.
ƒ Password theft.
ƒ Deny of Services.
ƒ etc ...
o Damage amount
ƒ Direct loss in materials
ƒ Indirect loss in reputation.

How to Establish Security Requirements?

For maximum effect, we must clarify the security requirements of the organization by assessing:

• Risks to the organization (By assessment of threats and vulnerabilities and by identifying all
possible risks

Universal Knowledge Solutions S.A.L.

-4-
• Examples:
o What is important and what should be protected?
o What threats exist inside and outside of your organization?
o From whom and what do you want to protect from?
o What are your weaknesses (vulnerabilities)?
o Which security measure should have higher priority?

• Legal, regulatory and contractual requirements (Requirements that an organization are

obligated to follow, such as labor standard laws, employment contracts, Encoding Lows,
Civil Lows)

Success Factors

The following factors are often critical to the successful implementation of information security within
an organization:

• Security policy that reflect the organization's objectives.

• Implement security that can be enforced
• Appropriate training and education.
• Support and commitment from management.

Guidelines for Information Security

• IS013335: Guidelines for the Management of IT Security (GMITS)

o General guide for creating security policies, risk assessment, and selection of safeguards.

• IS015408: IT Security Evaluation Criteria (CC: Common Criteria)

o Criteria to be used as basis for evaluation of security properties of IT products and systems.

• IS017799: Code of practice for information security management

o Originally established as British Standard (BS) 7799, 17799 gives recommendations for
developing organizational security standards and effective security management practice.

Universal Knowledge Solutions S.A.L.

-5-
 Standards

• TCSEC (US - Orange Book, Red Book)

• ITSEC (Europe)
• CTECPEC (Canada)

Example:
Orange Book Summary
The following is a summary of the US Department of Defense Trusted Computer System Evaluation
Criteria, known as the Orange Book. Although originally written for military systems, the security
classifications are now broadly used within the computer industry.
In fact, the DoD security categories range from D (Minimal Protection) to A (Verified Protection).

D (Minimal Protection)

Any system that does not comply to any other category, or has failed to receive a higher classification.
D-level certification is very rare.

C (Discretionary Protection)

Discretionary protection applies to Trusted Computer Bases (TCBs) with optional object (i.e. file,
directory, devices etc.) protection.

C1 (Discretionary Security Protection)

• Discretionary Access Control, for example Access Control Lists (ACLs), User/Group/World
protection.
• Usually for users who are all on the same security level.
• Username and Password protection and secure authorizations database (ADB).
• Protected operating system and system operations mode.
• Periodic integrity checking of TCB.
• Tested security mechanisms with no obvious bypasses.
• Documentation for User Security.
• Documentation for Systems Administration Security.
• Documentation for Security Testing.
• TCB design documentation.
• Typically for users on the same security level
• C1 certification is rare.
o Operating Systems: earlier versions of Unix, IBM RACF.

C2 (Controlled Access Protection) As C1, plus

• Object protection can be on a single-user basis, e.g. through an ACL or Trustee database.
• Authorization for access may only be assigned by authorized users.
• Object reuse protection (i.e. to avoid reallocation of secure deleted objects).
• Mandatory identification and authorization procedures for users, e.g. Username/Password.

Universal Knowledge Solutions S.A.L.

-6-
 • Full auditing of security events (i.e. date/time, event, user, success/failure, terminal ID)
• Protected system mode of operation.
• Added protection for authorization and audit data.
• Documentation as C1 plus information on examining audit information.
• This is one of the most common certifications.
o Operating Systems are: VMS, IBM OS/400, Windows NT, Novell NetWare 4.11, Oracle
7, DG AOS/VS II.

B (Mandatory Protection)

Division B specifies that the TCB protection systems should be mandatory, not discretionary.

B1 (Labelled Security Protection) As C2 plus

• Mandatory security and access labeling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity labels when data is exported).
• Auditing of labeled objects.
• Mandatory access control for all operations.
• Ability to specify security level printed on human-readable output (e.g. printers).
• Ability to specify security level on any machine-readable output.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Operating Systems are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS,
Harris CS/SX, SGI Trusted IRIX.

B2 (Structured Protection) As B1 plus

• Notification of security level changes affecting interactive users.

• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.
• B3 - Security Domains
• As B2 plus:
• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified operating system is Getronics/Wang Federal XTS-300.

Universal Knowledge Solutions S.A.L.

-7-
A (Verified Protection)

Division A is the highest security division.

A1 (Verified Protection) As B3 plus:

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network
Processor, Honeywell SCOMP.

A2 and above:
• Provision is made for security levels higher than A2, although these have not yet been
formally defined. No OSes are rated above A1.

Security Design Procedure

1. Formulate an executive policy.

2. Conduct risk analysis and decide on risk management.
3. Decide on security measure.

Managing Security: Introduction

• Perform Operational Security measures. Examples of such operational measures

o Prevention:
ƒ Introduce and maintain security policy
ƒ Conduct security training periodically (e.g. one/year)
ƒ Conduct security audit periodically (e.g. one/year)
ƒ Collect new vulnerability information and apply patch when necessary
o Detection:
ƒ Monitor network and system transactions and detect any security incidents
ƒ Analyze logs
o Recovery (Incident response)
ƒ Persons who violated the security policy are penalized.
ƒ Restore destructed data/systems, based on pre-determined business continuity plan

Universal Knowledge Solutions S.A.L.

-8-
• Tests to check whether the security measure is functioning properly
o Testing security functions using software tools
o Testing Performance (Load test)
o Checking emergency cases
o Checking systems configuration
o Checking inter-stuff communication

Managing Security: Security Training

Security training is oriented toward teaching users about the importance of security in order to let them
know what they should do for the security. The users are also given a clear understanding of security
policy.

The Training should cover:

• Training concerning the importance of information security:

o Importance of information
o Damage in the event that a threat occurs
o Security policy (organizational policy)
o Violations and penalties

• Training concerning security techniques:

o Information handling (hardcopy, disks, etc…)
o Management of IDs and passwords
o Security holes

Managing Security: Security Audit

The factors to be considered Audit process of information security management:

• Users compliance with the security policy

• Security policy is up to date
• Risks against new threats are assessed
• Security measures are functioning properly

Universal Knowledge Solutions S.A.L.

-9-
 Managing Security:
Business Continuity Planning
• Develop an Incident Recovery Plan beforehand to minimize the effects of an incident and resume
operation in a timely manner.

• The predetermined plans may include:

o Preparation: incident handling guidelines and procedures.
o Notification: procedures and responsibilities for reporting incidents.
o Assessment: procedures and responsibilities for investigating incidents.
o Management: procedures and responsibilities for dealing with security incidents.
o Recovery: procedures and responsibilities for recovery of normal service.
o Review: procedures and responsibilities for post-incident actions.

• Example:
o Verify the incident.
o Determine the type and magnitude of the incident (number of internal/external hosts).
o Assess damage.
o Protect the evidence (capture a system snapshot for further analysis).
o Determine whether to track or trace.
o Communicate the problem and actions taken to: management, operations group, all affected
sites, other response organizations (such as the CERT Coordination Center), appropriate
investigative agencies.
o Recover (restore programs and applications from vendor-supplied media, ensure programs and
applications are securely Configured, restore data from periodic backups, install all relevant
patches)
o Assess time and resources used and damage incurred
o Prepare report and/or statistics
o Support prosecution activity (if appropriate)
o Conduct a post-mortem (review lessons learned, evaluate procedures, update response plan if
appropriate)
o Update policy and procedures as necessary
o Be prepared for media inquiries

Security Policy

Security policy is a set of rules that an organization establish in order to maintain the necessary
security level. It becomes the basis for the whole security design procedure.

More precisely, due to the changes in computer environment, a security policy is a set of basic rules or
guidelines to be followed by a system user. For example:

• What users can and cannot do (Protection Level).

• Policy of giving access permission
• Policy of password management

Universal Knowledge Solutions S.A.L.

- 10 -
• Privacy policy
• Penalties for inappropriate behaviors
• Incident handling policy
• Rules of user authentication
• How security audit would be performed
• Plans for maintenance and recovery

There is security policy in the narrow sense and broad sense.

• In the narrow sense, security policy regards only settings of Operating Systems (such as UNIX) or
Firewall or Routers ...etc.
• In the broad sense, security policy covers the entire system, including operation and audit,
management …etc.

What happens without policy?

• Example:

Confidential No rule on Some users are Who is responsible

documents are left accessing outside using inadequate for patching
on an empty desk network through (too easy) software bug is not
modems password clear

• The number of divisions and employees within an organization increases; it becomes very
difficult to control the conduct of each employee.

• The employees within different divisions have different opinion towards security, and that could
become an obstacle when sharing information.

• In worst cases, because of differences of opinion, even frictions may occur between these
different divisions.

Universal Knowledge Solutions S.A.L.

- 11 -
• Without a common rule, or a security policy that all employees can relate to, there would always
be differences of opinion.

Advantage of Having a Security Policy

• Consensus of the system security can be obtained.

• Employees become security conscious, and understand the risk.

• The duty and the responsibility of each person can be defined.

• Effective and appropriate Security can be achieved with minimum cost.

• Security risks that cannot be countered using security tools can be controlled.
o For example security tools cannot restrict users from connecting modem to their PCs, but
security policy can deter them

General outline of security policy

Universal Knowledge Solutions S.A.L.

- 12 -
 Creating Security Policy documents

• Phase1 - Establishing Executive Policy:

o General orientations.
o Example of what is included in an Executive Policy:
ƒ Declaration
ƒ 0bjective
ƒ What is a security policy
ƒ Terms
ƒ Scope
ƒ Information security management framework
ƒ Compliance
ƒ Penalties

• Phase2 - Risk Analysis and Management:

o Conduct risk analysis
o Decide on the security measures
o Managing security measures

• Phase3 - Establishing Standards:

o General rules and regulations:
o Example of what is included in Standards
ƒ Passwords should be easy to remember, but they must not be easy to guess by a third
person.

• Phase4 - Establishing Procedures:

o Rules and regulations according to departments, and job description (specific details of each
standards are described in different documents)
o Example of what is included in Procedures (The general rules and regulations):
ƒ Procedures for user: Passwords must be at least 6 characters long.
ƒ Procedures for administrators: Passwords must be at least 8 characters long

Technical Considerations
(When Writing Security Policy)

The security policy must:

• Be accessible to anyone in the organization.
• Be easy to understand.
• Be doable.
• Be documented, applied and maintained.
• Be up-to-date.
• Establish security guidelines, standards, and procedures for all the activities in conformance with

Universal Knowledge Solutions S.A.L.

- 13 -
 the applicable policies, laws
• Establish security guidelines, standards, and procedures for all the activities in conformance with
the applied roles and privileges (administrative officials, users, others)
• Provide detailed analysis of potential threats and the feasibility of various security measures in
order to provide recommendations to administrative officials;
• Clarifies roles and responsibilities of users, administrators, and management. Provide also a clear
distribution of privileges and permissions in order to guaranty the privacy and confidentiality of the
various types of electronic data, in accordance with applicable laws and policies. Briefly, security
policy must clarify:
who should do what, why, how and at what time is clear
• Provide clear security measures that mitigate threats, consistent with the level of acceptable risk
established by administrative officials;
• Establish procedures to ensure that privileged accounts are kept to a minimum and that privileged
users comply with privileged access agreements;
• Establish the most recent software security patches, commensurate with the identified level of
acceptable risk.
• Provide suitable authentication and authorization functions, commensurate with appropriate use
and the acceptable level of risk.
• Provide suitable security installations to protect room or facility where server machines are located,
• Fix the main roles and activities
• Be Implemented regarding to the available materials and resources.

Interaction Considerations
(When Writing a Security Policy)
Security policy must be fixed and maintained with the collaboration of administrative officials and
users. Hence:

Administrative Officials (individuals with administrative responsibility or individuals having

functional ownership of data) must:
• Identify the electronic information resources within areas under their control;
• Define the purpose and function of the resources and ensure that requisite documentation are
provided as needed;
• Establish acceptable levels of security risk for resources by assessing factors such as:
o How sensitive the data is, such as sensible data or information protected by law or policy,
o The level of criticality to the continuing operations for each individual activity;
o How negatively the operations of one or more units would be affected by unavailability or
reduced availability of the resources,
o How likely it is that a resource could be used as a platform for inappropriate acts towards other
entities.

Users (individuals who access and use campus electronic information resources) must:

Universal Knowledge Solutions S.A.L.

- 14 -
• Become knowledgeable about relevant security requirements and guidelines;
• Protect the resources under their control, such as access passwords, computers, and data they
download.

Sample of Security Policy Document: Executive Policy

1. Purpose

The computer network has been a tool used in the management of our company for a long time. Since
its introduction, work efficiency has increased, and it has become a standard practice to use the
information stored on the computer network. We should continue to take full advantage of our
computer network as a management-support tool. However, network security is a high priority for a
company like us because we use the Internet to exploit business opportunities. We cannot afford to
ignore recent computer security attacks. Security issue is a business challenge we must address, to
prevent any problem in the future.
A security attack would significantly damage marketing and sales opportunities. For the sake of
customer satisfaction, we must establish a reputation of being a "secure" company.
To this end, we define the information system (e.g., the computers and the network) and the
information that resides on it as our fourth asset, hereinafter called "information assets." This
valuable asset must be carefully managed and protected.
We will formulate the Information Security Policy to protect information assets through
Information Security Management.
The Information Security Policy describes security measures, which protect the information
assets from problems such as falsification, damage, and leakage, whether intentional or not.
All parties who use the information assets must be aware of the importance of information
security and observe the Information Security Policy.
The following sample Information Security Policy statements are provided to guide
organizations in developing their own policies. It is general in nature and by no means definitive.
Each organization must assess whether the content and style is relevant to its own environment and
unique 'business requirements.

2. The Scope of the Information Security Policy

The scope of the Information Security Policy shall cover human, physical, and environmental
resources that are related to information assets.
A diagram of our system is shown in the figure below.

Universal Knowledge Solutions S.A.L.

- 15 -
3. To Whom the Information Security Policy Applies
The definition of 'employee' includes all full-time and part-time personnel, regardless of their
terms of employment.
The Information Security Policy applies to everyone, including managers and employees, who
use information assets.

3.1 Management Responsibilities

The management must show support for the Information Security Policy and actively be
involved in Information Security Management.

3.2 Employee Responsibilities

Employees have permission to use information assets, in order to efficiently fulfil their
professional duties. Use for personal purposes is not allowed.
To sustain/raise company profits and customer satisfaction, employees must accept and comply
with the Information Security Policy. Violators of the Policy shall be held responsible for the
consequence of their actions.

3.3 Outsourcing rules

When tasks within the scope of the Information Security Policy are outsourced, the contract
must clearly define the security measures that the outsourced contractors have to observe as well as
their responsibilities for security failures.

4. Components and Hierarchy of the Information Security Policy

Universal Knowledge Solutions S.A.L.

- 16 -
 hierarchical levels.

4.1 Basic Policy

The Basic Policy (hereinafter, "Policy") is the highest level of the Information Security Policy.
This document describes policies for Information Security Management and serves as the basis for
the documents underneath it.

4.2 The Standard for Information Security Measures

The Standard for Information Security Measures (hereinafter "Standard") is directly below the
Policy level. Each section describes general rules for information security.

4.3 Information Security Procedure

The Information Security Procedure (hereinafter, "Procedure") is the level right below the
Standard. This document describes the contents of the Standard in greater detail and is customized
for each audience.

4.4 Relationship with the existing rules

The Policy is regarded as important as, personnel regulations, office regulations or any other
company regulations. The Policy must be revised according to the specified rules.

4.5 Legal ramifications

The Information Security Policy must not violate the law. When necessary, security measures
must be implemented so that the Information Security Policy complies with related international
standards. Such laws and standards include:
ƒ Criminal Law
ƒ Unauthorized Computer Access Law
ƒ Building Standards Law and its related orders
ƒ Fire Service Law and related government orders and rules
ƒ Unfair Competition Prevention Law
ƒ Copyright Law
ƒ ISO/IEC 17799 & ISO/IEC TR 1333 5 (GMITS)

4.6 Disclosure of the Information Security Policy

The Information Security Policy is disclosed to all employees. Therefore, it should be treated as
confidential information, which may not be disclosed to the general public. Specifically, the
Standard and the Procedure are confidential, while the Policy can be disclosed to the public. The
contents of the Standard are disclosed to the Information Security Committee and the relevant
sections. The contents of the Procedure are disclosed to personnel who perform the pertinent tasks.

4.7 Disclosure of the Information Security Policy

The Information Security Policy is confidential and in principle, shall not be disclosed to
outsiders. When a task cannot be performed otherwise, such disclosure is permitted once a non-
disclosure agreement has been signed.

7. Definitions of Terms
Terms in the Information Security Policy are defined as follows:

Universal Knowledge Solutions S.A.L.

- 17 -
7.1 Information security (excerpt from ISO/IEC17799)
Preservation of confidentiality, integrity, and availability of information:
- Confidentiality: ensuring that information is accessible only to those authorized to have
access.
- Integrity: safeguarding the accuracy and completeness of information and processing
methods
- Availability: ensuring that authorized users have access to information and associated assets
when required.

7.2 Risk assessment (excerpt from ISO/IEC 17799)

Assessment of threats and vulnerabilities of information.

7.3 Risk management (excerpt from ISO/IEC17799)

Identifying, controlling and minimizing or eliminating security risks that may affect information
systems, for an acceptable cost.

7.4 Threats
Threats are direct causes of damage or loss: for example, natural disaster, mechanical
malfunction or failure, and malicious acts.

7.5 Vulnerabilities
Vulnerabilities are factors that contribute to the likelihood and frequency of threats. Examples
include structural flaws in buildings, failure to perform regular inspections, inadequate information
related security rules, and insufficient personnel training.
8. Organization
The following personnel and departments are involved in Information Security Management:

Universal Knowledge Solutions S.A.L.

- 18 -
8.1 Information Security Committee
An Information Security Committee shall be formed, which will institute a company-wide
management system for information security. For details of the Information Security Committee
and its members, refer to Section 9.
8.2 Information System Department
The Information System Department shall be charged with carrying out the decisions of the
Information Security Committee.
The Information System Department shall manage information equipment and collect security-
related information, with which it can enhance information security. Also, the department reports
information from employees to the Information Security Committee as necessary.
8.3 Head of System Security
The Head of System Security belongs to the Information System Department and supervises the
system administrators. The Head of System Security manages and directs system administrators
and ensures that a system of checks and balances among these administrators is in place.

8.4 System Administrators

System Administrators belong to the Information System Department and perform management
tasks delegated by the Head of System Security. System Administrators are in charge of on-site
security of information equipment and any measures taken in response to requests.

8.5 Operators

Universal Knowledge Solutions S.A.L.

- 19 -
 Operators belong to the Information System Department and perform on-site tasks under
supervision of System administrators.

8.6 Security Personnel

Except for the Information System Department, the head of each department selects at least one
member of the department as Security Personnel. The tasks of the Security Personnel are
enhancing department security; registering employee complaints and problems with information
system management and against security measures; and reporting to the Information System
Department.

9. Organization and Members of the Information Security Committee

9.1 Organization of the Information Security Committee
The Information Security Committee is organized as follows:

9.2 Full-time members

The full-time members are the Chairperson, the Vice Chairperson, and the regular members. It
is their responsibility to attend every committee meeting.

9.3 Part-time members

Part-time members include outside consultants, legal specialists, and the Head of System
Security. They attend meetings at the request of the Chairperson.
9.4 Chairperson

Universal Knowledge Solutions S.A.L.

- 20 -
 The Board of Directors appoints the Chairperson as the Director of Information Control.
The Chairperson must be a director of the company and must be responsible for Information
Security Management.
9.4 Vice Chairperson
The Vice Chairperson is the Head of the Information System Department, and acts as an aide to
the Chairperson. When the Chairperson is unable to perform his or her duties, the Vice Chairperson
performs them.

9.5 Regular members

The regular member of the Information Security Committee is each department head.
The regular members are allowed to propose items for the meeting agendas (e.g. responses to
security issues inside and outside the company).

9.6 Organizer
The Information System Department serves as the Organizer and carries out administrative
tasks for the Information Security Committee. The Organizer manages documents developed by
the Information Security Committee, such as Information Security Management Plans and the
Information Security Policy.

9.7 Task force

The Information Security Committee may form a task force to execute specific tasks.
One of the regular members is the head of the task force. The responsibilities of the task force
include formulation of the Information Security Policy, auditing, and incident response.

10. Tasks and Responsibilities of the Information Security Committee

The tasks of the Information Security Committee are as follows:

10.1 Planning for Information Security Management

The Information Security Committee must draft and carry out plans for Information Security
Management. The plan must address risk management and risk assessment, as well as plans to raise
employee awareness of the Information Security Policy. Also, the plan must allow for review of
the policy.

10.2 Distribution of the Information Security Policy document

Once the Information Security Policy has been developed or revised, the Information Security
Committee must distribute it to employees without delay.

10.3 Employee training

The Information Security Committee shall offer continuous in-house training on information
security to raise awareness and improve skills.

10.4 Revision of the Information Security Policy and assessment of employee compliance

Universal Knowledge Solutions S.A.L.

- 21 -
 The Information Security Committee shall regularly review the Information Security Policy and
assess employee compliance with the policy. The Committee shall survey and evaluate employee
opinions on the Policy, and revise it accordingly.

10.5 Evaluation of auditing results and revision

The Information Security Committee shall use the auditing results to evaluate the Information
Security Policy, and revise it as necessary.

10.6 Report to the Board of Directors

The Information Security Committee must report to the Board of Directors on information
security maintenance, management, failures and problems, and on any revisions to the Information
Security Policy.

10.7 Penalty for violators of the Information Security Policy

The Information Security Committee shall take appropriate actions against violators of the
Information Security Policy upon discovery of the violation. Depending on the case, the
Information Security Committee can request the Personnel Department to impose a penalty
according to the personnel regulations.

11. Information Security Management

To protect information assets of the company, the following measures will be taken for
Information Security Management:

11.1 Risk analysis

The Information Security Committee shall undertake risk assessment and manage information
assets of the company.

11.2 Policy formulation

The Information Security Committee shall develop, evaluate, and review the Information
Security Policy, and shall formulate the Policy (4.1) and the Standard (4.2). The personnel in
charge of information systems are appointed by the Information Security Committee to develop the
Procedure.

11.3 Implementation of security measures

The security measures in the Information Security Policy of the company must be implemented
systematically. The Information System Department must develop a plan for implementing security
measures and get it approved by the Information Security Committee.

11.4 Training and awareness

The company shall proactively provide information security training for all information asset
users with the aim of increasing skill level and understanding. All information asset users must
undergo this training. Also, should the occasion arise, inform the regular members of the
Information Security Committee of any recent developments in information security.

11.5 Auditing and evaluation

Universal Knowledge Solutions S.A.L.

- 22 -
 The Information Security Committee must evaluate vulnerabilities and threats to information
security on a regular basis, or whenever such problems arise. The Committee should evaluate
potential countermeasures for addition to the Information Security Policy. These actions by the
Committee are guided by auditing results, feedback from information asset users, and results from
surveys on information security vulnerabilities.

11.6 Document revision

The Board of Directors must approve revision of the Information Security Policy and the Policy
(4.1). The Information Security Committee has authority over the Standard and the Procedures.

12. Penalties for Violations

The company shall take strict measures against violators of the Information Security Policy.
The Information Security Committee shall take action consistent with the severity of the violation
of the Information Security Policy.

13. Response to Information Security Breach

Responses to information system security breaches should be timely and follow the pre-
established procedure.

14. Effective Date

This Policy was approved by the Board of Directors on April 1, 2004 and will take effect on
October 1, 2004.

Sample of Security Policy Document: Standards

User Authentication Standard

1. Objectives
User authentication is an important aspect of ensuring information security. This document has
been drafted to establish the standard for security and flexibility for user authentication. The
standard should be updated whenever necessary, such as length and type of characters, password
update frequency, and equipment, to follow changes in technology trend.

2. Persons Involved
This standard applies to all employees who use or are involved in user authentication.

3. Equipment and Systems

User authentication is required for use on any equipment, system, or application that belongs to
either one of the following categories: | t
1) Equipment that can be connected to a network and that runs a commonly used OS
2) Equipment with storage devices, such as hard disks
3) Routers
4) User mail services (e.g. email software)

Universal Knowledge Solutions S.A.L.

- 23 -
 5) Intranet software for information sharing within the organization

4. Rules to Follow

4.1 Security through user authentication

Equipment, systems and applications important for ensuring information security and capable of
user authentication must require user authentication.

4.2 Equipment and System selection

When building a user authentication system, the Information System Department must consider
the trade-off between the level of system security and the difficulty involved in reaching that level.
The information system that the Information System Department constructs must include
password- or biometric-based user authentication.

4.3 Password
(1) Passwords should be at least 8 characters long and is recommended that it contain at least one
special character.
(2) Easily guessed passwords, such as generally used words or words related to personal hobbies or
information, are unacceptable.
(3) It is recommended that passwords be changed once a month.
(4) In principle, system administrators shall create and manage passwords of their systems. Passwords
may be written down, but not such that unauthorized users could identify the equipment or system
involved. The entire string of password characters may not be written in an easily decipherable form.
(5) Users may not speak their password out loud, or keep items near themselves that could be a clue for
their password.
(6) A new password may not be the same password used before, even if it is not updated consecutively.
(7) A user may not reuse a password, even if for another system.

4.4 Default password

(1) The Information System Department shall issue default passwords to users orally or in
writing.
(2) Default passwords may not be based on regular or predictable patterns, e.g. employee number.
(3) When the default password is issued, the user must log in and change the password as soon as
possible.
(4) The system administrator must confirm that the user has changed the default password. In
principle, if the password remains unchanged 3 days after issuance, the account must be removed or
invalidated.

4.5 Forgotten passwords

(1) When the users forget their password, they must request a new one from the system administrator.
(2) The system administrator must verify the applicant's identity with a valid form of identification.
(3) The system administrator must respond immediately to such requests by issuing the password and
notifying the user.

4.6 One-time password

(1) One-time passwords must be in a form that requires authentication e.g. a PIN (personal
identification number).
(2) Only equipment that requires user authentication by time synchronization shall be used.
(3) The one-time password generator should be handled so that unauthorized users cannot see clues
for passwords, such as PINs.

4.7 Biometrics

Universal Knowledge Solutions S.A.L.

- 24 -
 (1) Biometrics may be used when it is problematic to memorize and manage passwords. The
specific method should be chosen by considering the cost and the state of the art.
(2) Biometric data is an important personal information. Therefore it must be handled with
strict care.
(3) Simple biometric information (e.g., fingerprints) can add flexibility to password use.
(4) Areas such as the server room must have a biometric system that provides the appropriate
high level of access security, e.g., an iris scan identification system.

5. Exception
If any part of this document cannot be followed for work-related reasons, users must request the
Information Security Committee for approval of exceptions. ^

6. Penalties
Violators of this document may be penalized according to the circumstances of the violation. The
"Penalty Standards" will determine the penalty.

7. Disclosure
This document is disclosed only to the Persons Involved.

8. Revisions
This document was approved by the Information Security Committee on April 1, 2004 and will
take effect on Oct 1, 2004. Requests for changes to this document must be submitted to the
Information Security Committee. The Committee must deliberate on each request, and if it concludes
that the changes are necessary, the Committee must modify the document promptly and inform the
Persons Involved. The Information Security Committee must review this document annually. Any
revision must be performed immediately, and the Committee must inform the Persons Involved of the
changes.

Sample of Security Policy Document: Standards

Password Standard
1.0 Overview
Passwords are an important aspect of computer security. They are the front line of protection for
user accounts. A poorly chosen password may result in the compromise of <Company Name>'s
entire corporate network. As such, all <Company Name> employees (including contractors and
vendors with access to <Company Name> systems) are responsible for taking the appropriate steps,
as outlined below, to select and secure their passwords.

2.0 Purpose
The purpose of this policy is to establish a standard for creation of strong passwords, the protection
of those passwords, and the frequency of change.

3.0 Scope
The scope of this policy includes all personnel who have or are responsible for an account (or any
form of access that supports or requires a password) on any system that resides at any <Company
Name> facility, has access to the <Company Name> network, or stores any non-public <Company
Name> information.

Universal Knowledge Solutions S.A.L.

- 25 -
4.0 Policy

4.1 General
• All system-level passwords (e.g., root, enable, NT admin, application administration accounts,
etc.) must be changed on at least a quarterly basis.
• All production system-level passwords must be part of the InfoSec administered global
password management database.
• All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least
every six months. The recommended change interval is every four months.
• User accounts that have system-level privileges granted through group memberships or
programs such as "su" must have a unique password from all other accounts held by that user.
• Passwords must not be inserted into email messages or other forms of electronic
communication.
• Where SNMP is used, the community strings must be defined as something other than the
standard defaults of "public," "private" and "system" and must be different from the passwords
used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
• All user-level and system-level passwords must conform to the guidelines described below.

4.2 Guidelines
General Password Construction Guidelines
Passwords are used for various purposes at <Company Name>. Some of the more common uses
include: user level accounts, web accounts, email accounts, screen saver protection, voicemail
password, and local router logins.
Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only
used once) everyone should be aware of how to select strong passwords.
Poor, weak passwords have the following characteristics:

• The password contains less than eight characters

• The password is a word found in a dictionary (English or foreign)
• The password is a common usage word such as:
o Names of family, pets, friends, co-workers, fantasy characters, etc. o Computer terms and
names, commands, sites, companies, hardware, software.
o The words "<Company Name>", "sanjose", "sanfran" or any derivation.
o Birthdays and other personal information such as addresses and phone numbers.
o Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
o Any of the above spelled backwards.
o Any of the above preceded or followed by a digit (e.g., secretl, 1 secret)
• Strong passwords have the following characteristics:
• Contain both upper and lower case characters (e.g., a-z, A-Z)
o Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%A&;1'()_+|~-=V
{}[]:";'<>?,./)
o Are at least eight alphanumeric characters long
o Are not words in any language, slang, dialect, jargon … etc.
o Are not based on personal information, names of family … etc.
• Passwords should never be written down or stored on-line. Try to create passwords that can be
easily remembered. One way to do this is create a password based on a song title, affirmation, or
other phrase. For example, the phrase might be: "This May Be One Way to Remember" and the
password could be: "TmBlw2R!" or "TmblW>r~" or some other variation.

NOTE: Do not use either of these examples as passwords!

Universal Knowledge Solutions S.A.L.

- 26 -
 Password Protection Standards
• Do not use the same password for <Company Name> accounts as for other non-<Company
Name> access (e.g., personal ISP account, option trading, benefits, etc.). Where possible, don't
use the same password for various <Company Name> access needs. For example, select one
password for the Engineering systems and a separate password for IT systems. Also, select a
separate password to be used for an NT account and a UNIX account.
• Do not share <Company Name> passwords with anyone, including administrative assistants or
secretaries.
• All passwords are to be treated as sensitive. Confidential <Company Name> information.
• Don't reveal a password over the phone to ANYONE
• Don't reveal a password in an email message
• Don't reveal a password to the boss
• Don't talk about a password in front of others
• Don't hint at the format of a password (e.g., "my family name")
• Don't reveal a password on questionnaires or security forms
• Don't share a password with family members
• Don't reveal a password to co-workers while on vacation
• If someone demands a password, refer them to this document or have them call someone in the
Information Security Department.
• Do not use the "Remember Password" feature of applications (e.g., Eudora, OutLook,
Netscape Messenger).
• Again, do not write passwords down and store them anywhere in your office. Do not store
passwords in a file on ANY computer system (including Palm Pilots or similar devices)
without encryption.
• Change passwords at least once every six months (except system-level passwords which must
be changed quarterly). The recommended change interval is every four months.
• If an account or password is suspected to have been compromised, report the incident to
InfoSec and change all passwords.
• Password cracking or guessing may be performed on a periodic or random basis by InfoSec or
its delegates. If a password is guessed or cracked during one of these scans, the user will be
required to change it.

Application Development Standards

• Application developers must ensure their programs contain the following security precautions.
• Applications:
o Should support authentication of individual users, not groups.
o Should not store passwords in clear text or in any easily reversible form.
o Should provide for some sort of role management, such that one user can take over the
functions without having to know the other's password.
o Should support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval, wherever
possible.

Use of Passwords and Passphrases for Remote Access Users

• Access to the <Company Name> Networks via remote access is to be controlled using either a
one-time password authentication or a public/private key system with a strong passphrase.

Passphrases
• Passphrases are generally used for public/private key authentication. A public/private key
system defines a mathematical relationship between the public key that is known by all, and
the private key, that is known only to the user. Without the passphrase to "unlock" the private

Universal Knowledge Solutions S.A.L.

- 27 -
 key, the user cannot gain access.
• Passphrases are not the same as passwords. A passphrase is a longer version of a password and
is, therefore, more secure. A passphrase is typically composed of multiple words. Because of
this, a passphrase is more secure against "dictionary attacks.
• A good passphrase is relatively long and contains a combination of upper and lowercase letters
and numeric and punctuation characters. An example of a good passphrase:
"The*?#>*@TrafficOnThel01Was*&#!#ThisMoming" All of the rules above that apply to
passwords apply to passphrases.

5.0 Enforcement
Any employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment.

Orange Book - Full Text

DoD 5200.28-STD
Supersedes
CSC-STD-001-83, dtd 15 Aug 83
Library No. S225,711

DEPARTMENT OF DEFENSE STANDARD

DEPARTMENT OF DEFENSE

TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA

DECEMBER 1985
FOREWORD

This publication, DoD 5200.28-STD, "Department of Defence Trusted Computer System Evaluation
Criteria," is issued under the authority of an in accordance with DoD Directive 5200.28, "Security
Requirements for Automatic Data Processing (ADP) Systems," and in furtherance of responsibilities
assigned by DoD Directive 5215.1, "Computer Security Evaluation Center." Its purpose is to provide
technical hardware/firmware/software security criteria and associated technical evaluation
methodologies in support of the overall ADP system security policy, evaluation and
approval/accreditation responsibilities promulgated by DoD Directive 5200.28.

The provisions of this document apply to the Office of the Secretary of Defence (ASD), the Military
Departments, the Organization of the Joint Chiefs of Staff, the Unified and Specified Commands, the
Defence Agencies and activities administratively supported by OSD (hereafter called "DoD

Universal Knowledge Solutions S.A.L.

- 28 -
Components").

This publication is effective immediately and is mandatory for use by all DoD Components in carrying
out ADP system technical security evaluation activities applicable to the processing and storage of
classified and other sensitive DoD information and applications as set forth herein.

Recommendations for revisions to this publication are encouraged and will be reviewed biannually by
the National Computer Security Center through a formal review process. Address all proposals for
revision through appropriate channels to: National Computer Security Center, Attention: Chief,
Computer Security Standards.

DoD Components may obtain copies of this publication through their own publications channels. Other
federal agencies and the public may obtain copies from: Office of Standards and Products, National
Computer Security Center, Fort Meade, MD 20755-6000, Attention: Chief, Computer Security
Standards.

_________________________________

Donald C. Latham Assistant Secretary of Defence (Command, Control, Communications, and

Intelligence)

ACKNOWLEDGEMENTS[toc]

Special recognition is extended to Sheila L. Brand, National Computer Security Center (NCSC), who
integrated theory, policy, and practice into and directed the production of this document.

Acknowledgment is also given for the contributions of: Grace Hammonds and Peter S. Tasker, the
MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell, former Deputy Director of NCSC, Marvin
Schaefer, NCSC, and Theodore M. P. Lee, Sperry Corp., who as original architects formulated and
articulated the technical issues and solutions presented in this document; Jeff Makey, formerly NCSC,
Warren F. Shadle, NCSC, and Carole S. Jordan, NCSC, who assisted in the preparation of this
document; James P. Anderson, James P. Anderson & Co., Steven B. Lipner, Digital Equipment Corp.,
Clark Weissman, System Development Corp., LTC Lawrence A. Noble, formerly U.S. Air Force,
Stephen T. Walker, formerly DoD, Eugene V. Epperly, DoD, and James E. Studer, formerly Dept. of
the Army, who gave generously of their time and expertise in the review and critique of this document;
and finally, thanks are given to the computer industry and others interested in trusted computing for
their enthusiastic advice and assistance throughout this effort.

Universal Knowledge Solutions S.A.L.

- 29 -
CONTENTS

FOREWORD

ACKNOWLEDGMENTS

PREFACE

INTRODUCTION

PART I: THE CRITERIA

1.0 DIVISION D: MINIMAL PROTECTION

2.0 DIVISION C: DISCRETIONARY PROTECTION

2.1 Class (C1): Discretionary Security Protection

2.2 Class (C2): Controlled Access Protection

3.0 DIVISION B: MANDATORY PROTECTION

3.1 Class (B1): Labeled Security Protection

3.2 Class (B2): Structured Protection

3.3 Class (B3): Security Domains

4.0 DIVISION A: VERIFIED

4.1 Class (A1): Verified Design

4.2 Beyond Class (A1)

PART II: RATIONALE AND GUIDELINES

5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS

5.1 A Need for Consensus

5.2 Definition and Usefulness

5.3 Criteria Control Objective

6.0 RATIONALE BEHIND THE EVALUATION CLASSES

6.1 The Reference Monitor Concept

6.2 A Formal Security Policy Model

Universal Knowledge Solutions S.A.L.

- 30 -
6.3 The Trusted Computing Base

6.4 Assurance

6.5 The Classes

7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA

7.1 Established Federal Policies

7.2 DoD Policies

7.3 Criteria Control Objective For Security Policy

7.4 Criteria Control Objective for Accountability

7.5 Criteria Control Objective for Assurance

8.0 A GUIDELINE ON COVERT CHANNELS

9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES

10.0 A GUIDELINE ON SECURITY TESTING

10.1 Testing for Division C

10.2 Testing for Division B

10.3 Testing for Division A

APPENDIX A: Commercial Product Evaluation Process

APPENDIX B: Summary of Evaluation Criteria Divisions

APPENDIX C: Sumary of Evaluation Criteria Classes

APPENDIX D: Requirement Directory

GLOSSARY

REFERENCES

PREFACE [toc]

The trusted computer system evaluation criteria defined in this document classify systems into four
broad hierarchical divisions of enhanced security protection. They provide a basis for the evaluation of
effectiveness of security controls built into automatic data processing system products. The criteria
were developed with three objectives in mind: (a) to provide users with a yardstick with which to
assess the degree of trust that can be placed in computer systems for the secure processing of classified

Universal Knowledge Solutions S.A.L.

- 31 -
or other sensitive information; (b) to provide guidance to manufacturers as to what to build into their
new, widely-available trusted commercial products in order to satisfy trust requirements for sensitive
applications; and (c) to provide a basis for specifying security requirements in acquisition
specifications. Two types of requirements are delineated for secure processing: (a) specific security
feature requirements and (b) assurance requirements. Some of the latter requirements enable evaluation
personnel to determine if the required features are present and functioning as intended. The scope of
these criteria is to be applied to the set of components comprising a trusted system, and is not
necessarily to be applied to each system component individually. Hence, some components of a system
may be completely untrusted, while others may be individually evaluated to a lower or higher
evaluation class than the trusted product considered as a whole system. In trusted products at the high
end of the range, the strength of the reference monitor is such that most of the components can be
completely untrusted. Though the criteria are intended to be application-independent, the specific
security feature requirements may have to be interpreted when applying the criteria to specific systems
with their own functional requirements, applications or special environments (e.g., communications
processors, process control computers, and embedded systems in general). The underlying assurance
requirements can be applied across the entire spectrum of ADP system or application processing
environments without special interpretation.

INTRODUCTION[toc]

Historical Perspective

In October 1967, a task force was assembled under the auspices of the Defence Science Board to
address computer security safeguards that would protect classified information in remote-access,
resource-sharing computer systems. The Task Force report, "Security Controls for Computer Systems,"
published in February 1970, made a number of policy and technical recommendations on actions to be
taken to reduce the threat of compromise of classified information processed on remote-access
computer systems.[34] Department of Defence Directive 5200.28 and its accompanying manual DoD
5200.28-M, published in 1972 and 1973 respectively, responded to one of these recommendations by
establishing uniform DoD policy, security requirements, administrative controls, and technical
measures to protect classified information processed by DoD computer systems.[8;9] Research and
development work undertaken by the Air Force, Advanced Research Projects Agency, and other
defence agencies in the early and mid 70's developed and demonstrated solution approaches for the
technical problems associated with controlling the flow of information in resource and information
sharing computer systems.[1] The DoD Computer Security Initiative was started in 1977 under the
auspices of the Under Secretary of Defence for Research and Engineering to focus DoD efforts
addressing computer security issues.[33]

Concurrent with DoD efforts to address computer security issues, work was begun under the leadership
of the National Bureau of Standards (NBS) to define problems and solutions for building, evaluating,
and auditing secure computer systems.[17] As part of this work NBS held two invitational workshops
on the subject of audit and evaluation of computer security.[20;28] The first was held in March 1977,
and the second in November of 1978. One of the products of the second workshop was a definitive
paper on the problems related to providing criteria for the evaluation of technical computer security
effectiveness.[20] As an outgrowth of recommendations from this report, and in support of the DoD
Computer Security Initiative, the MITRE Corporation began work on a set of computer security
evaluation criteria that could be used to assess the degree of trust one could place in a computer system
to protect classified data.[24;25;31] The preliminary concepts for computer security evaluation were

Universal Knowledge Solutions S.A.L.

- 32 -
defined and expanded upon at invitational workshops and symposia whose participants represented
computer security expertise drawn from industry and academia in addition to the government. Their
work has since been subjected to much peer review and constructive technical criticism from the DoD,
industrial research and development organizations, universities, and computer manufacturers.

The DoD Computer Security Center (the Center) was formed in January 1981 to staff and expand on
the work started by the DoD Computer Security Initiative.[15] A major goal of the Center as given in
its DoD Charter is to encourage the widespread availability of trusted computer systems for use by
those who process classified or other sensitive information.[10] The criteria presented in this document
have evolved from the earlier NBS and MITRE evaluation material.

Scope

The trusted computer system evaluation criteria defined in this document apply primarily to trusted
commercially available automatic data processing (ADP) systems. They are also applicable, as
amplified below, the evaluation of existing systems and to the specification of security requirements
for ADP systems acquisition. Included are two distinct sets of requirements: 1) specific security feature
requirements; and 2) assurance requirements. The specific feature requirements encompass the
capabilities typically found in information processing systems employing general-purpose operating
systems that are distinct from the applications programs being supported. However, specific security
feature requirements may also apply to specific systems with their own functional requirements,
applications or special environments (e.g., communications processors, process control computers, and
embedded systems in general). The assurance requirements, on the other hand, apply to systems that
cover the full range of computing environments from dedicated controllers to full range multilevel
secure resource sharing systems.

Purpose

As outlined in the Preface, the criteria have been developed to serve a number of intended purposes:

• To provide a standard to manufacturers as to what security features to build into their new
and planned, commercial products in order to provide widely available systems that satisfy
trust requirements (with particular emphasis on preventing the disclosure of data) for
sensitive applications.
• To provide DoD components with a metric with which to evaluate the degree of trust that
can be placed in computer systems for the secure processing of classified and other
sensitive information.
• To provide a basis for specifying security requirements in acquisition specifications.
• With respect to the second purpose for development of the criteria, i.e., providing DoD
components with a security evaluation metric, evaluations can be delineated into two
types: (a) an evaluation can be performed on a computer product from a perspective that
excludes the application environment; or, (b) it can be done to assess whether appropriate
security measures have been taken to permit the system to be used operationally in a
specific environment. The former type of evaluation is done by the Computer Security
Center through the Commercial Product Evaluation Process. That process is described in
Appendix A.

The latter type of evaluation, i.e., those done for the purpose of assessing a system's security attributes
with respect to a specific operational mission, is known as a certification evaluation. It must be
understood that the completion of a formal product evaluation does not constitute certification or
accreditation for the system to be used in any specific application environment. On the contrary, the
evaluation report only provides a trusted computer system's evaluation rating along with supporting
data describing the product system's strengths and weaknesses from a computer security point of view.

Universal Knowledge Solutions S.A.L.

- 33 -
The system security certification and the formal approval/accreditation procedure, done in accordance
with the applicable policies of the issuing agencies, must still be followed-before a system can be
approved for use in processing or handling classified information.[8;9] Designated Approving
Authorities (DAAs) remain ultimately responsible for specifying security of systems they accredit.

The trusted computer system evaluation criteria will be used directly and indirectly in the certification
process. Along with applicable policy, it will be used directly as technical guidance for evaluation of
the total system and for specifying system security and certification requirements for new acquisitions.
Where a system being evaluated for certification employs a product that has undergone a Commercial
Product Evaluation, reports from that process will be used as input to the certification evaluation.
Technical data will be furnished to designers, evaluators and the Designated Approving Authorities to
support their needs for making decisions.

Fundamental Computer Security Requirements

Any discussion of computer security necessarily starts from a statement of requirements, i.e., what it
really means to call a computer system "secure." In general, secure systems will control, through use of
specific security features, access to information such that only properly authorized individuals, or
processes operating on their behalf, will have access to read, write, create, or delete information. Six
fundamental requirements are derived from this basic statement of objective: four deal with what needs
to be provided to control access to information; and two deal with how one can obtain credible
assurances that this is accomplished in a trusted computer system.

Policy

Requirement 1 - 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.[7] 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).

Requirement 2 - 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.

Accountability

Requirement 3 - 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.

Requirement 4 - 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.

Universal Knowledge Solutions S.A.L.

- 34 -
Audit data must be protected from modification and unauthorized destruction to permit detection and
after-the-fact investigations of security violations.

Assurance

Requirement 5 - 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.

Requirement 6 - 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.

These fundamental requirements form the basis for the individual evaluation criteria applicable for
each evaluation division and class. The interested reader is referred to Section 5 of this document,
"Control Objectives for Trusted Computer Systems," for a more complete discussion and further
amplification of these fundamental requirements as they apply to general-purpose information
processing systems and to Section 7 for amplification of the relationship between Policy and these
requirements.

Structure of the Document

The remainder of this document is divided into two parts, four appendices, and a glossary. Part I
(Sections 1 through 4) presents the detailed criteria derived from the fundamental requirements
described above and relevant to the rationale and policy excerpts contained in Part II.

Part II (Sections 5 through 10) provides a discussion of basic objectives, rationale, and national policy
behind the development of the criteria, and guidelines for developers pertaining to: mandatory access
control rules implementation, the covert channel problem, and security testing. It is divided into six
sections. Section 5 discusses the use of control objectives in general and presents the three basic
control objectives of the criteria. Section 6 provides the theoretical basis behind the criteria. Section 7
gives excerpts from pertinent regulations, directives, OMB Circulars, and Executive Orders which
provide the basis for many trust requirements for processing nationally sensitive and classified
information with computer systems. Section 8 provides guidance to system developers on expectations
in dealing with the covert channel problem. Section 9 provides guidelines dealing with mandatory
security. Section 10 provides guidelines for security testing. There are four appendices, including a
description of the Trusted Computer System Commercial Products Evaluation Process (Appendix A),
summaries of the evaluation divisions (Appendix B) and classes (Appendix C), and finally a directory
of requirements ordered alphabetically. In addition, there is a glossary.

Structure of the Criteria

Universal Knowledge Solutions S.A.L.

- 35 -
The criteria are divided into four divisions: D, C, B, and A ordered in a hierarchical manner with the
highest division (A) being reserved for systems providing the most comprehensive security. Each
division represents a major improvement in the overall confidence one can place in the system for the
protection of sensitive information. Within divisions C and B there are a number of subdivisions
known as classes. The classes are also ordered in a hierarchical manner with systems representative of
division C and lower classes of division B being characterized by the set of computer security
mechanisms that they possess. Assurance of correct and complete design and implementation for these
systems is gained mostly through testing of the security- relevant portions of the system. The security-
relevant portions of a system are referred to throughout this document as the Trusted Computing Base
(TCB). Systems representative of higher classes in division B and division A derive their security
attributes more from their design and implementation structure. Increased assurance that the required
features are operative, correct, and tamperproof under all circumstances is gained through
progressively more rigorous analysis during the design process.

Within each class, four major sets of criteria are addressed. The first three represent features necessary
to satisfy the broad control objectives of Security Policy, Accountability, and Assurance that are
discussed in Part II, Section 5. The fourth set, Documentation, describes the type of written evidence in
the form of user guides, manuals, and the test and design documentation required for each class.

A reader using this publication for the first time may find it helpful to first read Part II, before
continuing on with Part I.

PART I: THE CRITERIA

Highlighting (UPPERCASE) is used in Part I to indicate criteria not contained in a lower class or
changes and additions to already defined criteria. Where there is no highlighting, requirements have
been carried over from lower classes without addition or modification. [Dynamoo.com note - this
marking is not present in this version of the criteria]

1.0 DIVISION D: MINIMAL PROTECTION [toc]

This division contains only one class. It is reserved for those systems that have been evaluated but that
fail to meet the requirements for a higher evaluation class.

2.0 DIVISION C: DISCRETIONARY PROTECTION [toc]

Classes in this division provide for discretionary (need-to-know) protection and, through the inclusion
of audit capabilities, for accountability of subjects and the actions they initiate.

Universal Knowledge Solutions S.A.L.

- 36 -
2.1 CLASS (C1): DISCRETIONARY SECURITY PROTECTION [toc]

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. The following are minimal
requirements for systems assigned a class (C1) rating:

2.1.1 Security Policy

2.1.1.1 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 or both.

2.1.2 Accountability

2.1.2.1 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.

2.1.3 Assurance

2.1.3.1 Operational Assurance

2.1.3.1.1 System Architecture

The TCB shall maintain a domain for its own execution 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.

2.1.3.1.2 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.

2.1.3.2 Life-Cycle Assurance

2.1.3.2.1 Security Testing

Universal Knowledge Solutions S.A.L.

- 37 -
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. (See
the Security Testing Guidelines.)

2.1.4 Documentation

2.1.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation shall describe the protection mechanisms
provided by the TCB, guidelines on their use, and how they interact with one another.

2.1.4.2 Trusted Facility Manual

A manual addressed to the ADP System Administrator shall present cautions about functions and
privileges that should be controlled when running a secure facility.

2.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document that describes the test plan, test
procedures that show how the security mechanisms were tested, and results of the security
mechanisms' functional testing.

2.1.4.4 Design Documentation

Documentation shall be available that provides a description of the manufacturer's philosophy of

protection and an explanation of how this philosophy is translated into the TCB. If the TCB is
composed of distinct modules, the interfaces between these modules shall be described.

2.2 CLASS (C2): CONTROLLED ACCESS PROTECTION [toc]

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. The following are minimal requirements for systems assigned a
class (C2) rating:

2.2.1 Security Policy

2.2.1.1 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.

2.2.1.2 Object Reuse

Universal Knowledge Solutions S.A.L.

- 38 -
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.

2.2.2 Accountability

2.2.2.1 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.

2.2.2.2 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.

2.2.3 Assurance

2.2.3.1 Operational Assurance

2.2.3.1.1 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.

2.2.3.1.2 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.

2.2.3.2 Life-Cycle Assurance

2.2.3.2.1 Security Testing

Universal Knowledge Solutions S.A.L.

- 39 -
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.)

2.2.4 Documentation

2.2.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation shall describe the protection mechanisms
provided by the TCB, guidelines on their use, and how they interact with one another.

2.2.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall present cautions about functions and
privileges that should be controlled when running a secure facility. The procedures for examining and
maintaining the audit files as well as the detailed audit record structure for each type of audit event
shall be given.

2.2.4.3 Test Documentation

The system developer shall provide to the evaluators a document that describes the test plan, test
procedures that show how the security mechanisms were tested, and results of the security
mechanisms' functional testing.

2.2.4.4 Design Documentation

Documentation shall be available that provides a description of the manufacturer's philosophy of

protection and an explanation of how this philosophy is translated into the TCB. If the TCB is
composed of distinct modules, the interfaces between these modules shall be described.

3.0 DIVISION B: MANDATORY PROTECTION [toc]

The notion of a TCB that preserves the integrity of sensitivity labels and uses them to enforce a set of
mandatory access control rules is a major requirement in this division. Systems in this division must
carry the sensitivity labels with major data structures in the system. The system developer also
provides the security policy model on which the TCB is based and furnishes a specification of the
TCB. Evidence must be provided to demonstrate that the reference monitor concept has been
implemented.

3.1 CLASS (B1): LABELED SECURITY PROTECTION [toc]

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. The following are minimal requirements for systems

Universal Knowledge Solutions S.A.L.

- 40 -
assigned a class (B1) rating:

3.1.1 Security Policy

3.1.1.1 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.

3.1.1.2 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.

3.1.1.3 Labels

Sensitivity labels associated with each subject and storage object under its control (e.g., process, file,
segment, device) shall be maintained by the TCB. These labels shall be used as the basis for mandatory
access control decisions. In order to import non-labelled data, the TCB shall request and receive from
an authorized user the security level of the data, and all such actions shall be auditable by the TCB.
3.1.1.3.1 Label Integrity

Sensitivity labels shall accurately represent security levels of the specific subjects or objects with
which they are associated. When exported by the TCB, sensitivity labels shall accurately and
unambiguously represent the internal labels and shall be associated with the information being
exported.

3.1.1.3.2 Exportation of Labeled Information

The TCB shall designate each communication channel and I/O device as either single-level or
multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB.
The TCB shall maintain and be able to audit any change in the security level or levels associated with a
communication channel or I/O device.

3.1.1.3.2.1 Exportation to Multilevel Devices

When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that
object shall also be exported and shall reside on the same physical medium as the exported information
and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports
or imports an object over a multilevel communication channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity labels and the associated information that
is sent or received.

Universal Knowledge Solutions S.A.L.

- 41 -
3.1.1.3.2.2 Exportation to Single-Level Devices

Single-level I/O devices and single-level communication channels are not required to maintain the
sensitivity labels of the information they process. However, the TCB shall include a mechanism by
which the TCb and an authorized user reliably communicate to designate the single security level of
information imported or exported via single-level communication channels or I/O devices.

3.1.1.3.2.3 Labelling Human-Readable Output

The ADP system administrator shall be able to specify the printable label names associated with
exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged,
hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB shall, be default, mark the top and bottom of each page
of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity
labels that properly* represent the overall sensitivity of the output or that properly* represent the
sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner,
mark other forms of human- readable output (e.g., maps, graphics) with human- readable sensitivity
labels that properly* represent the sensitivity of the touput. Any override of these marking defaults
shall be auditable by the TCB.

* The hierarchical classification component in human-readable sensitivity labels shall be equal to the
greatest hierarchical classification or any of the information in the output that the labels refer to; the
non-hierarchical category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical categories

3.1.1.4 Mandatory Access Control

The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its
control (e.g., processes, files, segments, devices). These subjects and objects shall be assigned
sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical
categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB
shall be able to support two or more such security levels. (See the Mandatory Access Control
Guidelines.) The following requirements shall hold for all accesses between subjects and objects
controlled by the TCB: a subject can read an object only if the hierarchical classification in the
subject's security level is greater than or equal to the hierarchical classification in the object's security
level and the non- hierarchical categories in the subject's security level include all the non-hierarchical
categories in the object's security level. A subject can write an object only if the hierarchical
classification in the subject's security level is less than or equal to the hierarchical classification in the
object's security level and all the non-hierarchical categories in the subject's security level are included
in the non-hierarchical categories in the object's security level. Identification and authentication data
shall be used by the TCB to authenti- cate the user's identity and to ensure that the security level and
authorization of subjects external to the TCB that may be created to act on behalf of the individual user
are dominated by the clearance and authorization of that user.

3.1.2 Accountability

3.1.2.1 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 maintain authentication data that
includes information for verifying the identity of individual users (e.g., passwords) as well as

Universal Knowledge Solutions S.A.L.

- 42 -
used by the TCB to authenticate the user's identity and to ensure that the security level and
authorizations of subjects external to the TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of that user. 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.

3.1.2.2 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 of 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. The TCB shall also be able to audit any override of human-
readable output markings. 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 and the object's security level. The ADP system administrator shall be able to
selectively audit the actions of any one or more users based on individual identity and/or object
security level.

3.1.3 Assurance

3.1.3.1 Operational Assurance

3.1.3.1.1 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 maintain process
isolation through the provision of distinct address spaces under its control. The TCB shall isolate the
resources to be protected so that they are subject to the access control and auditing requirements.

3.1.3.1.2 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.

3.1.3.2 Life-Cycle Assurance

3.1.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested and found to work as claimed in the
system documentation. A team of individuals who thoroughly understand the specific implementation
of the TCB shall subject its design documentation, source code, and object code to thorough analysis
and testing. Their objectives shall be: to uncover all design and implementation flaws that would
permit a subject external to the TCB to read, change, or delete data normally denied under the

Universal Knowledge Solutions S.A.L.

- 43 -
(without authorization to do so) is able to cause the TCB to enter a state such that it is unable to
respond to communications initiated by other users. All discovered flaws shall be removed or
neutralized and the TCB retested to demonstrate that they have been eliminated and that new flaws
have not been introduced. (See the Security Testing Guidelines.)

3.1.3.2.2 Design Specification and Verification

An informal or formal model of the security policy supported by the TCB shall be maintained over the
life cycle of the ADP system and demonstrated to be consistent with its axioms.

3.1.4 Documentation

3.1.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation shall describe the protection mechanisms
provided by the TCB, guidelines on their use, and how they interact with one another.

3.1.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall present cautions about functions and
privileges that should be controlled when running a secure facility. The procedures for examining and
maintaining the audit files as well as the detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and administrator functions related to security,
to include changing the security characteristics of a user. It shall provide guidelines on the consistent
and effective use of the protection features of the system, how they interact, how to securely generate a
new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to
operate the facility in a secure manner.

3.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document that describes the test plan, test
procedures that show how the security mechanisms were tested, and results of the security
mechanisms' functional testing.

3.1.4.4 Design Documentation

Documentation shall be available that provides a description of the manufacturer's philosophy of

protection and an explanation of how this philosophy is translated into the TCB. If the TCB is
composed of distinct modules, the interfaces between these modules shall be described. An informal or
formal description of the security policy model enforced by the TCB shall be available and an
explanation provided to show that it is sufficient to enforce the security policy. The specific TCB
protection mechanisms shall be identified and an explanation given to show that they satisfy the
model.

3.2 CLASS (B2): STRUCTURED PROTECTION [toc]

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

Universal Knowledge Solutions S.A.L.

- 44 -
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. The following are minimal requirements for systems assigned a class
(B2) rating:

3.2.1 Security Policy

3.2.1.1 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.

3.2.1.2 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.

3.2.1.3 Labels

Sensitivity labels associated with each ADP system resource (e.g., subject, storage object, ROM) that
is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB.
These labels shall be used as the basis for mandatory access control decisions. In order to import non-
labelled data, the TCB shall request and receive from an authorized user the security level of the data,
and all such actions shall be auditable by the TCB.

3.2.1.3.1 Label Integrity

Sensitivity labels shall accurately represent security levels of the specific subjects or objects with
which they are associated. When exported by the TCB, sensitivity labels shall accurately and
unambiguously represent the internal labels and shall be associated with the information being
exported.

3.2.1.3.2 Exportation of Labeled Information

The TCB shall designate each communication channel and I/O device as either single-level or
multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB.
The TCB shall maintain and be able to audit any change in the security level or levels associated with a
communication channel or I/O device. 3.2.1.3.2.1 Exportation to Multilevel Devices

When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that
object shall also be exported and shall reside on the same physical medium as the exported information

Universal Knowledge Solutions S.A.L.

- 45 -
and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports
or imports an object over a multilevel communication channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity labels and the associated information that
is sent or received.

3.2.1.3.2.2 Exportation to Single-Level Devices

Single-level I/O devices and single-level communication channels are not required to maintain the
sensitivity labels of the information they process. However, the TCB shall include a mechanism by
which the TCB and an authorized user reliably communicate to designate the single security level of
information imported or exported via single-level communication channels or I/O devices.

3.2.1.3.2.3 Labelling Human-Readable Output

The ADP system administrator shall be able to specify the printable label names associated with
exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged,
hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each
page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable
sensitivity labels that properly* represent the overall sensitivity of the output or that properly*
represent the sensitivity of the information on the page. The TCB shall, by default and in an
appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these
marking defaults shall be auditable by the TCB.

3.2.1.3.3 Subject Sensitivity Labels

The TCB shall immediately notify a terminal user of each change in the security level associated with
that user during an interactive session. A terminal user shall be able to query the TCB as desired for a
display of the subject's complete sensitivity label.

3.2.1.3.4 Device Labels

The TCB shall support the assignment of minimum and maximum security levels to all attached
physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the
physical environments in which the devices are located.

3.2.1.4 Mandatory Access Control

The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage
objects, and I/O devices that are directly or indirectly accessible by subjects external to the TCB. These
subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical
classification levels and non-hierarchical categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able to support two or more such security levels.
(See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses
between All subjects external to the TCB and all objects directly or indirectly accessible by these
subjects: A subject can read an object only if the hierarchical classification in the subject's security
level is greater than or equal to the hierarchical classification in the object's security level and the non-
hierarchical categories in the subject's security level include all the non-hierarchical categories in the
object's security level. A subject can write an object only if the hierarchical classification in the
subject's security level is less than or equal to the hierarchical classification in the object's security
level and all the non-hierarchical categories in the subject's security level are included in the non-

Universal Knowledge Solutions S.A.L.

- 46 -
hierarchical categories in the object's security level. Identification and authentication data shall be used
by the TCB to authenticate the user's identity and to ensure that the security level and authorization of
subjects external to the TCB that may be created to act on behalf of the individual user are dominated
by the clearance and authorization of that user.

3.2.2 Accountability

3.2.2.1 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 maintain authentication data that
includes information for verifying the identity of individual users (e.g., passwords) as well as
information for determining the clearance and authorizations of individual users. This data shall be
used by the TCB to authenticate the user's identity and to ensure that the security level and
authorizations of subjects external to the TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of that user. 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.

3.2.2.1.1 Trusted Path

The TCB shall support a trusted communication path between itself and user for initial login and
authentication. Communications via this path shall be initiated exclusively by a user.

3.2.2.2 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 of 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. The TCB shall also be able to audit any override of human-
readable output markings. 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 and the object's security level. The ADP system administrator shall be able to
selectively audit the actions of any one or more users based on individual identity and/or object
security level. The TCB shall be able to audit the identified events that may be used in the exploitation
of covert storage channels.

3.2.3 Assurance

3.2.3.1 Operational Assurance

3.2.3.1.1 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). The TCB shall maintain process

Universal Knowledge Solutions S.A.L.

- 47 -
isolation through the provision of distinct address spaces under its control. The TCB shall be internally
structured into well-defined largely independent modules. It shall make effective use of available
hardware to separate those elements that are protection-critical from those that are not. The TCB
modules shall be designed such that the principle of least privilege is enforced. Features in hardware,
such as segmentation, shall be used to support logically distinct storage objects with separate attributes
(namely: readable, writeable). The user interface to the TCB shall be completely defined and all
elements of the TCB identified.

3.2.3.1.2 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.

3.2.3.1.3 Covert Channel Analysis

The system developer shall conduct a thorough search for covert storage channels and make a
determination (either by actual measurement or by engineering estimation) of the maximum bandwidth
of each identified channel. (See the covert channels guideline section.)

3.2.3.1.4 Trusted Facility Management

The TCB shall support separate operator and administrator functions.

3.2.3.2 Life-Cycle Assurance

3.2.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested and found to work as claimed in the
system documentation. A team of individuals who thoroughly understand the specific implementation
of the TCB shall subject its design documentation, source code, and object code to thorough analysis
and testing. Their objectives shall be: to uncover all design and implementation flaws that would
permit a subject external to the TCB to read, change, or delete data normally denied under the
mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject
(without authorization to do so) is able to cause the TCB to enter a state such that it is unable to
respond to communications initiated by other users. The TCB shall be found relatively resistant to
penetration. All discovered flaws shall be corrected and the TCB retested to demonstrate that they have
been eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB
implementation is consistent with the descriptive top-level specification. (See the Security Testing
Guidelines.)

3.2.3.2.2 Design Specification and Verification

A formal model of the security policy supported by the TCB shall be maintained over the life cycle of
the ADP system that is proven consistent with its axioms. A descriptive top-level specification (DTLS)
of the TCB shall be maintained that completely and accurately describes the TCB in terms of
exceptions, error messages, and effects. It shall be shown to be an accurate description of the TCB
interface.

3.2.3.2.3 Configuration Management

During development and maintenance of the TCB, a configuration management system shall be in
place that maintains control of changes to the descriptive top-level specification, other design data,

Universal Knowledge Solutions S.A.L.

- 48 -
implementation documentation, source code, the running version of the object code, and test fixtures
and documentation. The configuration management system shall assure a consistent mapping among
all documentation and code associated with the current version of the TCB. Tools shall be provided for
generation of a new version of the TCB from source code. Also available shall be tools for comparing
a newly generated version with the previous TCB version in order to ascertain that only the intended
changes have been made in the code that will actually be used as the new version of the TCB.

3.2.4 Documentation

3.2.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation shall describe the protection mechanisms
provided by the TCB, guidelines on their use, and how they interact with one another.

3.2.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall present cautions about functions and
privileges that should be controlled when running a secure facility. The procedures for examining and
maintaining the audit files as well as the detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and administrator functions related to security,
to include changing the security characteristics of a user. It shall provide guidelines on the consistent
and effective use of the protection features of the system, how they interact, how to securely generate a
new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to
operate the facility in a secure manner. The TCB modules that contain the reference validation
mechanism shall be identified. The procedures for secure generation of a new TCB from source after
modification of any modules in the TCB shall be described.

3.2.4.3 Test Documentation The system developer shall provide to the evaluators a document that
describes the test plan, test procedures that show how the security mechanisms were tested, and results
of the security mechanisms' functional testing. It shall include results of testing the effectiveness of the
methods used to reduce covert channel bandwidths.

3.2.4.4 Design Documentation

Documentation shall be available that provides a description of the manufacturer's philosophy of

protection and an explanation of how this philosophy is translated into the TCB. The interfaces
between the TCB modules shall be described. A formal description of the security policy model
enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified and an explanation given to show that
they satisfy the model. The descriptive top-level specification (DTLS) shall be shown to be an accurate
description of the TCB interface. Documentation shall describe how the TCB implements the reference
monitor concept and give an explanation why it is tamper resistant, cannot be bypassed, and is
correctly implemented. Documentation shall describe how the TCB is structured to facilitate testing
and to enforce least privilege. This documentation shall also present the results of the covert channel
analysis and the tradeoffs involved in restricting the channels. All auditable events that may be used in
the exploitation of known covert storage channels shall be identified. The bandwidths of known covert
storage channels the use of which is not detectable by the auditing mechanisms, shall be provided. (See
the Covert Channel Guideline section.)

3.3 CLASS (B3): SECURITY DOMAINS [toc]

Universal Knowledge Solutions S.A.L.

- 49 -
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. The following are minimal requirements for systems assigned a class (B3) rating:

3.1.1 Security Policy

3.3.1.1 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., access control lists) shall allow users
to specify and control sharing of those objects, 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
specifying, for each named object, a list of named individuals and a list of groups of named individuals
with their respective modes of access to that object. Furthermore, for each such named object, it shall
be possible to specify a list of named individuals and a list of groups of named individuals for which
no access to the object is to be given. Access permission to an object by users not already possessing
access permission shall only be assigned by authorized users.

3.3.1.2 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 subjects actions is
to be available to any subject that obtains access to an object that has been released back to the
system.

3.3.1.3 Labels

Sensitivity labels associated with each ADP system resource (e.g., subject, storage object, ROM) that
is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB.
These labels shall be used as the basis for mandatory access control decisions. In order to import non-
labelled data, the TCB shall request and receive from an authorized user the security level of the data,
and all such actions shall be auditable by the TCB.

3.3.1.3.1 Label Integrity

Sensitivity labels shall accurately represent security levels of the specific subjects or objects with
which they are associated. When exported by the TCB, sensitivity labels shall accurately and
unambiguously represent the internal labels and shall be associated with the information being
exported.

3.3.1.3.2 Exportation of Labeled Information

The TCB shall designate each communication channel and I/O device as either single-level or
multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB.
The TCB shall maintain and be able to audit any change in the security level or levels associated with a
communication channel or I/O device.

Universal Knowledge Solutions S.A.L.

- 50 -
3.3.1.3.2.1 Exportation to Multilevel Devices

When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that
object shall also be exported and shall reside on the same physical medium as the exported information
and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports
or imports an object over a multilevel communication channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity labels and the associated information that
is sent or received.

3.3.1.3.2.2 Exportation to Single-Level Devices

Single-level I/O devices and single-level communication channels are not required to maintain the
sensitivity labels of the information they process. However, the TCB shall include a mechanism by
which the TCB and an authorized user reliably communicate to designate the single security level of
information imported or exported via single-level communication channels or I/O devices.

3.3.1.3.2.3 Labelling Human-Readable Output

The ADP system administrator shall be able to specify the printable label names associated with
exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged,
hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each
page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable
sensitivity labels that properly* represent the overall sensitivity of the output or that properly*
represent the sensitivity of the information on the page. The TCB shall, by default and in an
appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these
marking defaults shall be auditable by the TCB.

* The hierarchical classification component in human-readable sensitivity labels shall be equal to the
greatest hierarchical classification of any of the information in the output that the labels refer to; the
non-hierarchical category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical categories.

3.3.1.3.3 Subject Sensitivity Labels

The TCB shall immediately notify a terminal user of each change in the security level associated with
that user during an interactive session. A terminal user shall be able to query the TCB as desired for a
display of the subject's complete sensitivity label.

3.3.1.3.4 Device Labels

The TCB shall support the assignment of minimum and maximum security levels to all attached
physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the
physical environments in which the devices are located.

3.3.1.4 Mandatory Access Control

The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage
objects, and I/O devices) that are directly or indirectly accessible by subjects external to the TCB.
These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical
classification levels and non-hierarchical categories, and the labels shall be used as the basis for

Universal Knowledge Solutions S.A.L.

- 51 -
mandatory access control decisions. The TCB shall be able to support two or more such security levels.
(See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses
between all subjects external to the TCB and all objects directly or indirectly accessible by these
subjects: A subject can read an object only if the hierarchical classification in the subject's security
level is greater than or equal to the hierarchical classification in the object's security level and the non-
hierarchical categories in the subject's security level include all the non-hierarchical categories in the
object's security level. A subject can write an object only if the hierarchical classification in the
subject's security level is less than or equal to the hierarchical classification in the object's security
level and all the non-hierarchical categories in the subject's security level are included in the non-
hierarchical categories in the object's security level. Identification and authentication data shall be used
by the TCB to authenticate the user's identity and to ensure that the security level and authori- zation of
subjects external to the TCB that may be created to act on behalf of the individual user are dominated
by the clearance and authorization of that user.

3.3.2 Accountability

3.3.2.1 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 maintain authentication data that
includes information for verifying the identity of individual users (e.g., passwords) as well as
information for determining the clearance and authorizations of individual users. This data shall be
used by the TCB to authenticate the user's identity and to ensure that the security level and
authorizations of subjects external to the TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of that user. 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.

3.3.2.1.1 Trusted Path

The TCB shall support a trusted communication path between itself and users for use when a positive
TCB-to- user connection is required (e.g., login, change subject security level). Communications via
this trusted path shall be activated exclusively by a user of the TCB and shall be logically isolated and
unmistakably distinguishable from other paths.

3.3.2.2 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 of 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. The TCB shall also be able to audit any override of human-
readable output markings. 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 and the object's security level. The ADP system administrator shall be able to
selectively audit the actions of any one or more users based on individual identity and/or object

Universal Knowledge Solutions S.A.L.

- 52 -
security level. The TCB shall be able to audit the identified events that may be used in the exploitation
of covert storage channels. The TCB shall contain a mechanism that is able to monitor the occurrence
or accumulation of security auditable events that may indicate an imminent violation of security
policy. This mechanism shall be able to immediately notify the security administrator when thresholds
are exceeded, and if the occurrence or accumulation of these security relevant events continues, the
system shall take the least disruptive action to terminate the event.

3.3.3 Assurance

3.3.3.1 Operational Assurance

3.3.3.1.1 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). The TCB shall maintain process
isolation through the provision of distinct address spaces under its control. The TCB shall be internally
structured into well-defined largely independent modules. It shall make effective use of available
hardware to separate those elements that are protection-critical from those that are not. The TCB
modules shall be designed such that the principle of least privilege is enforced. Features in hardware,
such as segmentation, shall be used to support logically distinct storage objects with separate attributes
(namely: readable, writeable). The user interface to the TCB shall be completely defined and all
elements of the TCB identified. The TCB shall be designed and structured to use a complete,
conceptually simple protection mechanism with precisely defined semantics. This mechanism shall
play a central role in enforcing the internal structuring of the TCB and the system. The TCB shall
incorporate significant use of layering, abstraction and data hiding. Significant system engineering
shall be directed toward minimizing the complexity of the TCB and excluding from the TCB modules
that are not protection-critical.

3.3.3.1.2 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.

3.3.3.1.3 Covert Channel Analysis

The system developer shall conduct a thorough search for covert channels and make a determination
(either by actual measurement or by engineering estimation) of the maximum bandwidth of each
identified channel. (See the Covert Channels Guideline section.)

3.3.3.1.4 Trusted Facility Management

The TCB shall support separate operator and administrator functions. The functions performed in the
role of a security administrator shall be identified. The ADP system administrative personnel shall only
be able to perform security administrator functions after taking a distinct auditable action to assume the
security administrator role on the ADP system. Non-security functions that can be performed in the
security administration role shall be limited strictly to those essential to performing the security role
effectively.

3.3.3.1.5 Trusted Recovery

Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure or other
discontinuity, recovery without a protection compromise is obtained.

Universal Knowledge Solutions S.A.L.

- 53 -
3.3.3.2 Life-Cycle Assurance

3.3.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested and found to work as claimed in the
system documentation. A team of individuals who thoroughly understand the specific implementation
of the TCB shall subject its design documentation, source code, and object code to thorough analysis
and testing. Their objectives shall be: to uncover all design and implementation flaws that would
permit a subject external to the TCB to read, change, or delete data normally denied under the
mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject
(without authorization to do so) is able to cause the TCB to enter a state such that it is unable to
respond to communications initiated by other users. The TCB shall be found resistant to penetration.
All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been
eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB
implementation is consistent with the descriptive top-level specification. (See the Security Testing
Guidelines.) No design flaws and no more than a few correctable implementation flaws may be found
during testing and there shall be reasonable confidence that few remain.

3.3.3.2.2 Design Specification and Verification

A formal model of the security policy supported by the TCB shall be maintained over the life cycle of
the ADP system that is proven consistent with its axioms. A descriptive top-level specification (DTLS)
of the TCB shall be maintained that completely and accurately describes the TCB in terms of
exceptions, error messages, and effects. It shall be shown to be an accurate description of the TCB
interface. A convincing argument shall be given that the DTLS is consistent with the model.

3.3.3.2.3 Configuration Management

During development and maintenance of the TCB, a configuration management system shall be in
place that maintains control of changes to the descriptive top-level specification, other design data,
implementation documentation, source code, the running version of the object code, and test fixtures
and documentation. The configuration management system shall assure a consistent mapping among
all documentation and code associated with the current version of the TCB. Tools shall be provided for
generation of a new version of the TCB from source code. Also available shall be tools for comparing
a newly generated version with the previous TCB version in order to ascertain that only the intended
changes have been made in the code that will actually be used as the new version of the TCB.

3.3.4 Documentation

3.3.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation shall describe the protection mechanisms
provided by the TCB, guidelines on their use, and how they interact with one another.

3.3.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall present cautions about functions and
privileges that should be controlled when running a secure facility. The procedures for examining and
maintaining the audit files as well as the detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and administrator functions related to security,
to include changing the security characteristics of a user. It shall provide guidelines on the consistent
and effective use of the protection features of the system, how they interact, how to securely generate a

Universal Knowledge Solutions S.A.L.

- 54 -
new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to
operate the facility in a secure manner. The TCB modules that contain the reference validation
mechanism shall be identified. The procedures for secure generation of a new TCB from source after
modification of any modules in the TCB shall be described. It shall include the procedures to ensure
that the system is initially started in a secure manner. Procedures shall also be included to resume
secure system operation after any lapse in system operation.

3.3.4.3 Test Documentation

The system developer shall provide to the evaluators a document that describes the test plan, test
procedures that show how the security mechanisms were tested, and results of the security
mechanisms' functional testing. It shall include results of testing the effectiveness of the methods used
to reduce covert channel bandwidths.

3.3.4.4 Design Documentation

Documentation shall be available that provides a description of the manufacturer's philosophy of

protection and an explanation of how this philosophy is translated into the TCB. The interfaces
between the TCB modules shall be described. A formal description of the security policy model
enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified and an explanation given to show that
they satisfy the model. The descriptive top-level specification (DTLS) shall be shown to be an accurate
description of the TCB interface. Documentation shall describe how the TCB implements the reference
monitor concept and give an explanation why it is tamper resistant, cannot be bypassed, and is
correctly implemented. The TCB implementation (i.e., in hardware, firmware, and software) shall be
informally shown to be consistent with the DTLS. The elements of the DTLS shall be shown, using
informal techniques, to correspond to the elements of the TCB. Documentation shall describe how the
TCB is structured to facilitate testing and to enforce least privilege. This documentation shall also
present the results of the covert channel analysis and the tradeoffs involved in restricting the channels.
All auditable events that may be used in the exploitation of known covert storage channels shall be
identified. The bandwidths of known covert storage channels, the use of which is not detectable by the
auditing mechanisms, shall be provided. (See the Covert Channel Guideline section.)

4.0 DIVISION A: VERIFIED PROTECTION [toc]

This division is characterized by the use of formal security verification methods to assure that the
mandatory and discretionary security controls employed in the system can effectively protect classified
or other sensitive information stored or processed by the system. Extensive documentation is required
to demonstrate that the TCB meets the security requirements in all aspects of design, development and
implementation.

4.1 CLASS (A1): VERIFIED DESIGN [toc]

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

Universal Knowledge Solutions S.A.L.

- 55 -
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. Independent of the particular specification language or verification
system used, there are five important criteria for class (A1) design verification:

• A formal model of the security policy must be clearly identified and documented, including
a mathematical proof that the model is consistent with its axioms and is sufficient to
support the security policy.

• An FTLS must be produced that includes abstract definitions of the functions the TCB
performs and of the hardware and/or firmware mechanisms that are used to support
separate execution domains.

• The FTLS of the TCB must be shown to be consistent with the model by formal techniques
where possible (i.e., where verification tools exist) and informal ones otherwise.

• The TCB implementation (i.e., in hardware, firmware, and software) must be informally
shown to be consistent with the FTLS. The elements of the FTLS must be shown, using
informal techniques, to correspond to the elements of the TCB. The FTLS must express the
unified protection mechanism required to satisfy the security policy, and it is the elements
of this protection mechanism that are mapped to the elements of the TCB.

1. Formal analysis techniques must be used to identify and analyze covert channels. Informal
techniques may be used to identify covert timing channels. The continued existence of
identified covert channels in the system must be justified.

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.

The following are minimal requirements for systems assigned a class (A1) rating:

4.1.1 Security Policy

4.1.1.1 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., access control lists) shall allow users
to specify and control sharing of those objects, 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
specifying, for each named object, a list of named individuals and a list of groups of named individuals
with their respective modes of access to that object. Furthermore, for each such named object, it shall
be possible to specify a list of named individuals and a list of groups of named individuals for which
no access to the object is to be given. Access permission to an object by users not already possessing
access permission shall only be assigned by authorized users.

4.1.1.2 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

Universal Knowledge Solutions S.A.L.

- 56 -
system.

4.1.1.3 Labels

Sensitivity labels associated with each ADP system resource (e.g., subject, storage object, ROM) that
is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB.
These labels shall be used as the basis for mandatory access control decisions. In order to import non-
labelled data, the TCB shall request and receive from an authorized user the security level of the data,
and all such actions shall be auditable by the TCB.

4.1.1.3.1 Label Integrity

Sensitivity labels shall accurately represent security levels of the specific subjects or objects with
which they are associated. When exported by the TCB, sensitivity labels shall accurately and
unambiguously represent the internal labels and shall be associated with the information being
exported.

4.1.1.3.2 Exportation of Labeled Information

The TCB shall designate each communication channel and I/O device as either single-level or
multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB.
The TCB shall maintain and be able to audit any change in the security level or levels associated with a
communication channel or I/O device.

4.1.1.3.2.1 Exportation to Multilevel Devices

When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that
object shall also be exported and shall reside on the same physical medium as the exported information
and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports
or imports an object over a multilevel communication channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity labels and the associated information that
is sent or received.

4.1.1.3.2.2 Exportation to Single-Level Devices

Single-level I/O devices and single-level communication channels are not required to maintain the
sensitivity labels of the information they process. However, the TCB shall include a mechanism by
which the TCB and an authorized user reliably communicate to designate the single security level of
information imported or exported via single-level communication channels or I/O devices.

4.1.1.3.2.3 Labelling Human-Readable Output

The ADP system administrator shall be able to specify the printable label names associated with
exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged,
hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each
page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable
sensitivity labels that properly* represent the overall sensitivity of the output or that properly*
represent the sensitivity of the information on the page. The TCB shall, by default and in an
appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these
marking defaults shall be auditable by the TCB.

Universal Knowledge Solutions S.A.L.

- 57 -
* The hierarchical classification component in human-readable sensitivity labels shall be equal to the
greatest hierarchical classification of any of the information in the output that the labels refer to; the
non-hierarchical category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical categories.

4.1.1.3.3 Subject Sensitivity Labels

The TCB shall immediately notify a terminal user of each change in the security level associated with
that user during an interactive session. A terminal user shall be able to query the TCB as desired for a
display of the subject's complete sensitivity label.

4.1.1.3.4 Device Labels

The TCB shall support the assignment of minimum and maximum security levels to all attached
physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the
physical environments in which the devices are located.

4.1.1.4 Mandatory Access Control

The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage
objects, and I/O devices) that are directly or indirectly accessible by subjects external to the TCB.
These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical
classification levels and non-hierarchical categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able to support two or more such security levels.
(See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses
between all subjects external to the TCB and all objects directly or indirectly accessible by these
subjects: A subject can read an object only if the hierarchical classification in the subject's security
level is greater than or equal to the hierarchical classification in the object's security level and the non-
hierarchical categories in the subject's security level include all the non-hierarchical categories in the
object's security level. A subject can write an object only if the hierarchical classification in the
subject's security level is less than or equal to the hierarchical classification in the object's security
level and all the non-hierarchical categories in the subject's security level are included in the non-
hierarchical categories in the object's security level. Identification and authentication data shall be used
by the TCB to authenticate the user's identity and to ensure that the security level and authoriza- tion of
subjects external to the TCB that may be created to act on behalf of the individual user are dominated
by the clearance and authorization of that user.

4.1.2 Accountability

4.1.2.1 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 maintain authentication data that
includes information for verifying the identity of individual users (e.g., passwords) as well as
information for determining the clearance and authorizations of individual users. This data shall be
used by the TCB to authenticate the user's identity and to ensure that the security level and
authorizations of subjects external to the TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of that user. 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. 4.1.2.1.1 Trusted Path

Universal Knowledge Solutions S.A.L.

- 58 -
The TCB shall support a trusted communication path between itself and users for use when a positive
TCB-to- user connection is required (e.g., login, change subject security level). Communications via
this trusted path shall be activated exclusively by a user or the TCB and shall be logically isolated and
unmistakably distinguishable from other paths.

4.1.2.2 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 of 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. The TCB shall also be able to audit any override of human-
readable output markings. 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 and the object's security level. The ADP system administrator shall be able to
selectively audit the actions of any one or more users based on individual identity and/or object
security level. The TCB shall be able to audit the identified events that may be used in the exploitation
of covert storage channels. The TCB shall contain a mechanism that is able to monitor the occurrence
or accumulation of security auditable events that may indicate an imminent violation of security
policy. This mechanism shall be able to immediately notify the security administrator when thresholds
are exceeded, and, if the occurrence or accumulation of these security relevant events continues, the
system shall take the least disruptive action to terminate the event.

4.1.3 Assurance

4.1.3.1 Operational Assurance

4.1.3.1.1 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). The TCB shall maintain process
isolation through the provision of distinct address spaces under its control. The TCB shall be internally
structured into well-defined largely independent modules. It shall make effective use of available
hardware to separate those elements that are protection-critical from those that are not. The TCB
modules shall be designed such that the principle of least privilege is enforced. Features in hardware,
such as segmentation, shall be used to support logically distinct storage objects with separate attributes
(namely: readable, writeable). The user interface to the TCB shall be completely defined and all
elements of the TCB identified. The TCB shall be designed and structured to use a complete,
conceptually simple protection mechanism with precisely defined semantics. This mechanism shall
play a central role in enforcing the internal structuring of the TCB and the system. The TCB shall
incorporate significant use of layering, abstraction and data hiding. Significant system engineering
shall be directed toward minimizing the complexity of the TCB and excluding from the TCB modules
that are not protection-critical.

4.1.3.1.2 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.

Universal Knowledge Solutions S.A.L.

- 59 -
4.1.3.1.3 Covert Channel Analysis

The system developer shall conduct a thorough search for covert channels and make a determination
(either by actual measurement or by engineering estimation) of the maximum bandwidth of each
identified channel. (See the Covert Channels Guideline section.) Formal methods shall be used in the
analysis.

4.1.3.1.4 Trusted Facility Management

The TCB shall support separate operator and administrator functions. The functions performed in the
role of a security administrator shall be identified. The ADP system administrative personnel shall only
be able to perform security administrator functions after taking a distinct auditable action to assume the
security administrator role on the ADP system. Non-security functions that can be performed in the
security administration role shall be limited strictly to those essential to performing the security role
effectively.

4.1.3.1.5 Trusted Recovery

Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure or other
discontinuity, recovery without a protection compromise is obtained.

4.1.3.2 Life-Cycle Assurance

4.1.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested and found to work as claimed in the
system documentation. A team of individuals who thoroughly understand the specific implementation
of the TCB shall subject its design documentation, source code, and object code to thorough analysis
and testing. Their objectives shall be: to uncover all design and implementation flaws that would
permit a subject external to the TCB to read, change, or delete data normally denied under the
mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject
(without authorization to do so) is able to cause the TCB to enter a state such that it is unable to
respond to communications initiated by other users. The TCB shall be found resistant to penetration.
All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been
eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB
implementation is consistent with the formal top- level specification. (See the Security Testing
Guidelines.) No design flaws and no more than a few correctable implementation flaws may be found
during testing and there shall be reasonable confidence that few remain. Manual or other mapping of
the FTLS to the source code may form a basis for penetration testing.

4.1.3.2.2 Design Specification and Verification

A formal model of the security policy supported by the TCB shall be maintained over the life-cycle of
the ADP system that is proven consistent with its axioms. A descriptive top-level specification (DTLS)
of the TCB shall be maintained that completely and accurately describes the TCB in terms of
exceptions, error messages, and effects. A formal top-level specification (FTLS) of the TCB shall be
maintained that accurately describes the TCB in terms of exceptions, error messages, and effects. The
DTLS and FTLS shall include those components of the TCB that are implemented as hardware and/or
firmware if their properties are visible at the TCB interface. The FTLS shall be shown to be an
accurate description of the TCB interface. A convincing argument shall be given that the DTLS is
consistent with the model and a combination of formal and informal techniques shall be used to show
that the FTLS is consistent with the model. This verification evidence shall be consistent with that

Universal Knowledge Solutions S.A.L.

- 60 -
provided within the state-of-the-art of the particular computer security center-endorsed formal
specification and verification system used. Manual or other mapping of the FTLS to the TCB source
code shall be performed to provide evidence of correct implementation.

4.1.3.2.3 Configuration Management

During the entire life-cycle, i.e., during the design, development, and maintenance of the TCB, a
configuration management system shall be in place for all security- relevant hardware, firmware, and
software that maintains control of changes to the formal model, the descriptive and formal top-level
specifications, other design data, implementation documentation, source code, the running version of
the object code, and test fixtures and documentation. The configuration management system shall
assure a consistent mapping among all documentation and code associated with the current version of
the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also
available shall be tools, maintained under strict configuration control, for comparing a newly generated
version with the previous TCB version in order to ascertain that only the intended changes have been
made in the code that will actually be used as the new version of the TCB. A combination of technical,
physical, and procedural safeguards shall be used to protect from unauthorized modification or
destruction the master copy or copies of all material used to generate the TCB.

4.1.3.2.4 Trusted Distribution

A trusted ADP system control and distribution facility shall be provided for maintaining the integrity
of the mapping between the master data describing the current version of the TCB and the on-site
master copy of the code for the current version. Procedures (e.g., site security acceptance testing) shall
exist for assuring that the TCb software, firmware, and hardware updates distributed to a customer are
exactly as specified by the master copies.

4.1.4 Documentation

4.1.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation shall describe the protection mechanisms
provided by the TCB, guidelines on their use, and how they interact with one another.

4.1.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall present cautions about functions and
privileges that should be controlled when running a secure facility. The procedures for examining and
maintaining the audit files as well as the detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and administrator functions related to security,
to include changing the security characteristics of a user. It shall provide guidelines on the consistent
and effective use of the protection features of the system, how they interact, how to securely generate a
new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to
operate the facility in a secure manner. The TCB modules that contain the reference validation
mechanism shall be identified. The procedures for secure generation of a new TCB from source after
modification of any modules in the TCB shall be described. It shall include the procedures to ensure
that the system is initially started in a secure manner. Procedures shall also be included to resume
secure system operation after any lapse in system operation.

4.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document that describes the test plan, test

Universal Knowledge Solutions S.A.L.

- 61 -
procedures that show how the security mechanisms were tested, and results of the security
mechanisms' functional testing. It shall include results of testing the effectiveness of the methods used
to reduce covert channel bandwidths. The results of the mapping between the formal top-level
specification and the TCB source code shall be given.

4.1.4.4 Design Documentation

Documentation shall be available that provides a description of the manufacturer's philosophy of

protection and an explanation of how this philosophy is translated into the TCB. The interfaces
between the TCB modules shall be described. A formal description of the security policy model
enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified and an explanation given to show that
they satisfy the model. The descriptive top-level speci- fication (DTLS) shall be shown to be an
accurate description of the TCB interface. Documentation shall describe how the TCB implements the
reference monitor concept and give an explana- tion why it is tamper resistant, cannot be bypassed, and
is correctly implemented. The TCB implementation (i.e., in hardware, firmware, and software) shall be
informally shown to be consistent with the formal top-level specification (FTLS). The elements of the
FTLS shall be shown, using informal techniques, to correspond to the elements of the TCB.
Documentation shall describe how the TCB is structured to facilitate testing and to enforce least
privilege. This documentation shall also present the results of the covert channel analysis and the
tradeoffs involved in restricting the channels. All auditable events that may be used in the exploitation
of known covert storage channels shall be identified. The bandwidths of known covert storage
channels, the use of which is not detectable by the auditing mechanisms, shall be provided. (See the
Covert Channel Guideline section.) Hardware, firmware, and software mechanisms not dealt with in
the FTLS but strictly internal to the TCB (e.g., mapping registers, direct memory access I/O) shall be
clearly described.

4.2 BEYOND CLASS (A1) [toc]

Most of the security enhancements envisioned for systems that will provide features and assurance in
addition to that already provided by class (Al) systems are beyond current technology. The discussion
below is intended to guide future work and is derived from research and development activities already
underway in both the public and private sectors. As more and better analysis techniques are developed,
the requirements for these systems will become more explicit. In the future, use of formal verification
will be extended to the source level and covert timing channels will be more fully addressed. At this
level the design environment will become important and testing will be aided by analysis of the formal
top-level specification. Consideration will be given to the correctness of the tools used in TCB
development (e.g., compilers, assemblers, loaders) and to the correct functioning of the
hardware/firmware on which the TCB will run. Areas to be addressed by systems beyond class (A1)
include:

System Architecture

A demonstration (formal or otherwise) must be given showing that requirements of self-protection and
completeness for reference monitors have been implemented in the TCB.

Security Testing

Although beyond the current state-of-the-art, it is envisioned that some test-case generation will be
done automatically from the formal top-level specification or formal lower-level specifications.

Universal Knowledge Solutions S.A.L.

- 62 -
Formal Specification and Verification

The TCB must be verified down to the source code level, using formal verification methods where
feasible. Formal verification of the source code of the security-relevant portions of an operating system
has proven to be a difficult task. Two important considerations are the choice of a high-level language
whose semantics can be fully and formally expressed, and a careful mapping, through successive
stages, of the abstract formal design to a formalization of the implementation in low-level
specifications. Experience has shown that only when the lowest level specifications closely correspond
to the actual code can code proofs be successfully accomplished.

Trusted Design Environment

The TCB must be designed in a trusted facility with only trusted (cleared) personnel.

PART II:

RATIONALE AND GUIDELINES [toc]

5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS [toc]

The criteria are divided within each class into groups of requirements. These groupings were
developed to assure that three basic control objectives for computer security are satisfied and not
overlooked. These control objectives deal with:

• Security Policy
• Accountability
• Assurance

This section provides a discussion of these general control objectives and their implication in
terms of designing trusted systems.

5.1 A NEED FOR CONSENSUS [toc]

A major goal of the DoD Computer Security Center is to encourage the Computer Industry to develop
trusted computer systems and products, making them widely available in the commercial market place.
Achievement of this goal will require recognition and articulation by both the public and private
sectors of a need and demand for such products.

As described in the introduction to this document, efforts to define the problems and develop solutions
associated with processing nationally sensitive information, as well as other sensitive data such as

Universal Knowledge Solutions S.A.L.

- 63 -
financial, medical, and personnel information used by the National Security Establishment, have been
underway for a number of years. The criteria, as described in Part I, represent the culmination of these
efforts and describe basic requirements for building trusted computer systems. To date, however, these
systems have been viewed by many as only satisfying National Security needs. As long as this
perception continues the consensus needed to motivate manufacture of trusted systems will be lacking.

The purpose of this section is to describe in detail the fundamental control objectives. These objectives
lay the foundation for the requirements outlined in the criteria. The goal is to explain the foundations
so that those outside the National Security Establishment can assess their universality and, by
extension, the universal applicability of the criteria requirements to processing all types of sensitive
applications whether they be for National Security or the private sector.

5.2 DEFINITION AND USEFULNESS [toc]

The term "control objective" refers to a statement of intent with respect to control over some aspect of
an organization's resources, or processes, or both. In terms of a computer system, control objectives
provide a framework for developing a strategy for fulfilling a set of security requirements for any
given system. Developed in response to generic vulnerabilities, such as the need to manage and handle
sensitive data in order to prevent compromise, or the need to provide accountability in order to detect
fraud, control objectives have been identified as a useful method of expressing security goals.[3]

Examples of control objectives include the three basic design requirements for implementing the
reference monitor concept discussed in Section 6. They are:

• The reference validation mechanism must be tamperproof.

• The reference validation mechanism must always be invoked.
• The reference validation mechanism must be small enough to be subjected to analysis and
tests, the completeness of which can be assured.[1]

5.3 CRITERIA CONTROL OBJECTIVES [toc]

The three basic control objectives of the criteria are concerned with security policy, accountability, and
assurance. The remainder of this section provides a discussion of these basic requirements.

5.3.1 Security Policy

In the most general sense, computer security is concerned with controlling the way in which a
computer can be used, i.e., controlling how information processed by it can be accessed and
manipulated. However, at closer examination, computer security can refer to a number of areas.
Symptomatic of this, FIPS PUB 39, Glossary For Computer Systems Security, does not have a unique
definition for computer security.[16] Instead there are eleven separate definitions for security which
include: ADP systems security, administrative security, data security, etc. A common thread running
through these definitions is the word "protection." Further declarations of protection requirements can
be found in DoD Directive 5200.28 which describes an acceptable level of protection for classified
data to be one that will "assure that systems which process, store, or use classified data and produce
classified information will, with reasonable dependability, prevent: a. Deliberate or inadvertent access
to classified material by unauthorized persons, and b. Unauthorized manipulation of the computer and
its associated peripheral devices."[8]

In summary, protection requirements must be defined in terms of the perceived threats, risks, and goals
of an organization. This is often stated in terms of a security policy. It has been pointed out in the
literature that it is external laws, rules, regulations, etc. that establish what access to information is to

Universal Knowledge Solutions S.A.L.

- 64 -
be permitted, independent of the use of a computer. In particular, a given system can only be said to be
secure with respect to its enforcement of some specific policy.[30] Thus, the control objective for
security policy is:

SECURITY POLICY CONTROL OBJECTIVE

A statement of intent with regard to control over access to and dissemination of information, to be
known as the security policy must be precisely defined and implemented for each system that is used
to process sensitive information. The security policy must accurately reflect the laws, regulations, and
general policies from which it is derived.

5.3.1.1 Mandatory Security Policy

Where a security policy is developed that is to be applied to control of classified or other specifically
designated sensitive information, the policy must include detailed rules on how to handle that
information throughout its life-cycle. These rules are a function of the various sensitivity designations
that the information can assume and the various forms of access supported by the system. Mandatory
security refers to the enforcement of a set of access control rules that constrains a subject's access to
information on the basis of a comparison of that individual's clearance/authorization to the information,
the classification/sensitivity designation of the information, and the form of access being mediated.
Mandatory policies either require or can be satisfied by systems that can enforce a partial ordering of
designations, namely, the designations must form what is mathematically known as a "lattice."[5] A
clear implication of the above is that the system must assure that the designations associated with
sensitive data cannot be arbitrarily changed, since this could permit individuals who lack the
appropriate authorization to access sensitive information. Also implied is the requirement that the
system control the flow of information so that data cannot be stored with lower sensitivity designations
unless its "downgrading" has been authorized. The control objective is:

MANDATORY SECURITY CONTROL OBJECTIVE

Security policies defined for systems that are used to process classified or other specifically
categorized sensitive information must include provisions for the enforcement of mandatory access
control rules. That is, they must include a set of rules for controlling access based directly on a
comparison of the individual's clearance or authorization for the information and the classification or
sensitivity designation of the information being sought, and indirectly on considerations of physical
and other environmental factors of control. The mandatory access control rules must accurately reflect
the laws, regulations, and general policies from which they are derived.

5.3.1.2 Discretionary Security Policy

Discretionary security is the principal type of access control available in computer systems today. The
basis of this kind of security is that an individual user, or program operating on his behalf, is allowed
to specify explicitly the types of access other users may have to information under his control.
Discretionary security differs from mandatory security in that it implements an access control policy
on the basis of an individual's need-to-know as opposed to mandatory controls which are driven by the
classification or sensitivity designation of the information.

Discretionary controls are not a replacement for mandatory controls. In an environment in which
information is classified (as in the DoD) discretionary security provides for a finer granularity of
control within the overall constraints of the mandatory policy. Access to classified information requires
effective implementation of both types of controls as precondition to granting that access. In general,
no person may have access to classified information unless: (a) that person has been determined to be

Universal Knowledge Solutions S.A.L.

- 65 -
trustworthy, i.e., granted a personnel security clearance -- MANDATORY, and (b) access is necessary
for the performance of official duties, i.e., determined to have a need-to-know -- DISCRETIONARY.
In other words, discretionary controls give individuals discretion to decide on which of the permissible
accesses will actually be allowed to which users, consistent with overriding mandatory policy
restrictions. The control objective is:

DISCRETIONARY SECURITY CONTROL OBJECTIVE

Security policies defined for systems that are used to process classified or other sensitive information
must include provisions for the enforcement of discretionary access control rules. That is, they must
include a consistent set of rules for controlling and limiting access based on identified individuals who
have been determined to have a need-to-know for the information.

5.3.1.3 Marking

To implement a set of mechanisms that will put into effect a mandatory security policy, it is necessary
that the system mark information with appropriate classification or sensitivity labels and maintain
these markings as the information moves through the system. Once information is unalterably and
accurately marked, comparisons required by the mandatory access control rules can be accurately and
consistently made. An additional benefit of having the system maintain the classification or sensitivity
label internally is the ability to automatically generate properly "labelled" output. The labels, if
accurately and integrally maintained by the system, remain accurate when output from the system. The
control objective is:

MARKING CONTROL OBJECTIVE

Systems that are designed to enforce a mandatory security policy must store and preserve the integrity
of classification or other sensitivity labels for all information. Labels exported from the system must be
accurate representations of the corresponding internal sensitivity labels being exported.

5.3.2 Accountability

The second basic control objective addresses one of the fundamental principles of security, i.e.,
individual accountability. Individual accountability is the key to securing and controlling any system
that processes information on behalf of individuals or groups of individuals. A number of requirements
must be met in order to satisfy this objective.

The first requirement is for individual user identification. Second, there is a need for authentication of
the identification. Identification is functionally dependent on authentication. Without authentication,
user identification has no credibility. Without a credible identity, neither mandatory nor discretionary
security policies can be properly invoked because there is no assurance that proper authorizations can
be made.

The third requirement is for dependable audit capabilities. That is, a trusted computer system must
provide authorized personnel with the ability to audit any action that can potentially cause access to,
generation of, or affect the release of classified or sensitive information. The audit data will be
selectively acquired based on the auditing needs of a particular installation and/or application.
However, there must be sufficient granularity in the audit data to support tracing the auditable events
to a specific individual who has taken the actions or on whose behalf the actions were taken. The
control objective is:

ACCOUNTABILITY CONTROL OBJECTIVE

Universal Knowledge Solutions S.A.L.

- 66 -
Systems that are used to process or handle classified or other sensitive information must assure
individual accountability whenever either a mandatory or discretionary security policy is invoked.
Furthermore, to assure accountability, the capability must exist for an authorized and competent agent
to access and evaluate accountability information by a secure means, within a reasonable amount of
time, and without undue difficulty.

5.3.3 Assurance

The third basic control objective is concerned with guaranteeing or providing confidence that the
security policy has been implemented correctly and that the protection-relevant elements of the system
do, indeed, accurately mediate and enforce the intent of that policy. By extension, assurance must
include a guarantee that the trusted portion of the system works only as intended. To accomplish these
objectives, two types of assurance are needed. They are life-cycle assurance and operational
assurance.

Life-cycle assurance refers to steps taken by an organization to ensure that the system is designed,
developed, and maintained using formalized and rigorous controls and standards.[17] Computer
systems that process and store sensitive or classified information depend on the hardware and software
to protect that information. It follows that the hardware and software themselves must be protected
against unauthorized changes that could cause protection mechanisms to malfunction or be bypassed
completely. For this reason trusted computer systems must be carefully evaluated and tested during the
design and development phases and revaluated whenever changes are made that could affect the
integrity of the protection mechanisms. Only in this way can confidence be provided that the hardware
and software interpretation of the security policy is maintained accurately and without distortion.

While life-cycle assurance is concerned with procedures for managing system design, development,
and maintenance; operational assurance focuses on features and system architecture used to ensure that
the security policy is uncircumventably enforced during system operation. That is, the security policy
must be integrated into the hardware and software protection features of the system. Examples of steps
taken to provide this kind of confidence include: methods for testing the operational hardware and
software for correct operation, isolation of protection- critical code, and the use of hardware and
software to provide distinct domains. The control objective is:

ASSURANCE CONTROL OBJECTIVE

Systems that are used to process or handle classified or other sensitive information must be designed to
guarantee correct and accurate interpretation of the security policy and must not distort the intent of
that policy. Assurance must be provided that correct implementation and operation of the policy exists
throughout the system's life-cycle.

6.0 RATIONALE BEHIND THE EVALUATION CLASSES [toc]

6.1 THE REFERENCE MONITOR CONCEPT

In October of 1972, the Computer Security Technology Planning Study, conducted by James P.
Anderson & Co., produced a report for the Electronic Systems Division (ESD) of the United States Air
Force.[1] In that report, the concept of "a reference monitor which enforces the authorized access
relationships between subjects and objects of a system" was introduced. The reference monitor concept

Universal Knowledge Solutions S.A.L.

- 67 -
was found to be an essential element of any system that would provide multilevel secure computing
facilities and controls.

The Anderson report went on to define the reference validation mechanism as "an implementation of
the reference monitor concept . . . that validates each reference to data or programs by any user
(program) against a list of authorized types of reference for that user." It then listed the three design
requirements that must be met by a reference validation mechanism:

a. The reference validation mechanism must be tamper proof.

b. The reference validation mechanism must always be invoked.

c. The reference validation mechanism must be small enough to be subject to analysis and tests, the
completeness of which can be assured."[1]

Extensive peer review and continuing research and development activities have sustained the validity
of the Anderson Committee's findings. Early examples of the reference validation mechanism were
known as security kernels. The Anderson Report described the security kernel as "that combination of
hardware and software which implements the reference monitor concept."[1] In this vein, it will be
noted that the security kernel must support the three reference monitor requirements listed above.

6.2 A FORMAL SECURITY POLICY MODEL

Following the publication of the Anderson report, considerable research was initiated into formal
models of security policy requirements and of the mechanisms that would implement and enforce those
policy models as a security kernel. Prominent among these efforts was the ESD-sponsored
development of the Bell and LaPadula model, an abstract formal treatment of DoD security policy.[2]
Using mathematics and set theory, the model precisely defines the notion of secure state, fundamental
modes of access, and the rules for granting subjects specific modes of access to objects. Finally, a
theorem is proven to demonstrate that the rules are security-preserving operations, so that the
application of any sequence of the rules to a system that is in a secure state will result in the system
entering a new state that is also secure. This theorem is known as the Basic Security Theorem.

A subject can act on behalf of a user or another subject. The subject is created as a surrogate for the
cleared user and is assigned a formal security level based on their classification. The state transitions
and invariants of the formal policy model define the invariant relationships that must hold between the
clearance of the user, the formal security level of any process that can act on the user's behalf, and the
formal security level of the devices and other objects to which any process can obtain specific modes
of access. The Bell and LaPadula model, for example, defines a relationship between formal security
levels of subjects and objects, now referenced as the "dominance relation." From this definition,
accesses permitted between subjects and objects are explicitly defined for the fundamental modes of
access, including read-only access, read/write access, and write-only access. The model defines the
Simple Security Condition to control granting a subject read access to a specific object, and the *-
Property (read "Star Property") to control granting a subject write access to a specific object. Both the
Simple Security Condition and the *-Property include mandatory security provisions based on the
dominance relation between formal security levels of subjects and objects the clearance of the subject
and the classification of the object. The Discretionary Security Property is also defined, and requires
that a specific subject be authorized for the particular mode of access required for the state transition.
In its treatment of subjects (processes acting on behalf of a user), the model distinguishes between
trusted subjects (i.e., not constrained within the model by the *-Property) and untrusted subjects (those
that are constrained by the *-Property).

Universal Knowledge Solutions S.A.L.

- 68 -
From the Bell and LaPadula model there evolved a model of the method of proof required to formally
demonstrate that all arbitrary sequences of state transitions are security-preserving. It was also shown
that the *- Property is sufficient to prevent the compromise of information by Trojan Horse attacks.

6.3 THE TRUSTED COMPUTING BASE

In order to encourage the widespread commercial availability of trusted computer systems, these
evaluation criteria have been designed to address those systems in which a security kernel is
specifically implemented as well as those in which a security kernel has not been implemented. The
latter case includes those systems in which objective (c) is not fully supported because of the size or
complexity of the reference validation mechanism. For convenience, these evaluation criteria use the
term Trusted Computing Base to refer to the reference validation mechanism, be it a security kernel,
front-end security filter, or the entire trusted computer system.

The heart of a trusted computer system is the Trusted Computing Base (TCB) which contains all of the
elements of the system responsible for supporting the security policy and supporting the isolation of
objects (code and data) on which the protection is based. The bounds of the TCB equate to the
"security perimeter" referenced in some computer security literature. In the interest of understandable
and maintainable protection, a TCB should be as simple as possible consistent with the functions it has
to perform. Thus, the TCB includes hardware, firmware, and software critical to protection and must
be designed and implemented such that system elements excluded from it need not be trusted to
maintain protection. Identification of the interface and elements of the TCB along with their correct
functionality therefore forms the basis for evaluation.

For general-purpose systems, the TCB will include key elements of the operating system and may
include all of the operating system. For embedded systems, the security policy may deal with objects in
a way that is meaningful at the application level rather than at the operating system level. Thus, the
protection policy may be enforced in the application software rather than in the underlying operating
system. The TCB will necessarily include all those portions of the operating system and application
software essential to the support of the policy. Note that, as the amount of code in the TCB increases, it
becomes harder to be confident that the TCB enforces the reference monitor requirements under all
circumstances.

6.4 ASSURANCE

The third reference monitor design objective is currently interpreted as meaning that the TCB "must be
of sufficiently simple organization and complexity to be subjected to analysis and tests, the
completeness of which can be assured."

Clearly, as the perceived degree of risk increases (e.g., the range of sensitivity of the system's protected
data, along with the range of clearances held by the system's user population) for a particular system's
operational application and environment, so also must the assurances be increased to substantiate the
degree of trust that will be placed in the system. The hierarchy of requirements that are presented for
the evaluation classes in the trusted computer system evaluation criteria reflect the need for these
assurances.

As discussed in Section 5.3, the evaluation criteria uniformly require a statement of the security policy
that is enforced by each trusted computer system. In addition, it is required that a convincing argument
be presented that explains why the TCB satisfies the first two design requirements for a reference
monitor. It is not expected that this argument will be entirely formal. This argument is required for
each candidate system in order to satisfy the assurance control objective.

Universal Knowledge Solutions S.A.L.

- 69 -
The systems to which security enforcement mechanisms have been added, rather than built-in as
fundamental design objectives, are not readily amenable to extensive analysis since they lack the
requisite conceptual simplicity of a security kernel. This is because their TCB extends to cover much
of the entire system. Hence, their degree of trustworthiness can best be ascertained only by obtaining
test results. Since no test procedure for something as complex as a computer system can be truly
exhaustive, there is always the possibility that a subsequent penetration attempt could succeed. It is for
this reason that such systems must fall into the lower evaluation classes.

On the other hand, those systems that are designed and engineered to support the TCB concepts are
more amenable to analysis and structured testing. Formal methods can be used to analyze the
correctness of their reference validation mechanisms in enforcing the system's security policy. Other
methods, including less-formal arguments, can be used in order to substantiate claims for the
completeness of their access mediation and their degree of tamper-resistance. More confidence can be
placed in the results of this analysis and in the thoroughness of the structured testing than can be placed
in the results for less methodically structured systems. For these reasons, it appears reasonable to
conclude that these systems could be used in higher-risk environments. Successful implementations of
such systems would be placed in the higher evaluation classes.

6.5 THE CLASSES

It is highly desirable that there be only a small number of overall evaluation classes. Three major
divisions have been identified in the evaluation criteria with a fourth division reserved for those
systems that have been evaluated and found to offer unacceptable security protection. Within each
major evaluation division, it was found that "intermediate" classes of trusted system design and
development could meaningfully be defined. These intermediate classes have been designated in the
criteria because they identify systems that:

• are viewed to offer significantly better protection and assurance than would systems that
satisfy the basic requirements for their evaluation class; and

• there is reason to believe that systems in the intermediate evaluation classes could
eventually be evolved such that they would satisfy the requirements for the next higher
evaluation class.

Except within division A it is not anticipated that additional "intermediate" evaluation classes
satisfying the two characteristics described above will be identified.

Distinctions in terms of system architecture, security policy enforcement, and evidence of credibility
between evaluation classes have been defined such that the "jump" between evaluation classes would
require a considerable investment of effort on the part of implementors. Correspondingly, there are
expected to be significant differentials of risk to which systems from the higher evaluation classes will
be exposed.

7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA [toc]

Section 1 presents fundamental computer security requirements and Section 5 presents the control

Universal Knowledge Solutions S.A.L.

- 70 -
objectives for Trusted Computer Systems. They are general requirements, useful and necessary, for the
development of all secure systems. However, when designing systems that will be used to process
classified or other sensitive information, functional requirements for meeting the Control Objectives
become more specific. There is a large body of policy laid down in the form of Regulations,
Directives, Presidential Executive Orders, and OMB Circulars that form the basis of the procedures for
the handling and processing of Federal information in general and classified information specifically.
This section presents pertinent excerpts from these policy statements and discusses their relationship to
the Control Objectives. These excerpts are examples to illustrate the relationship of the policies to
criteria and may not be complete.

7.1 ESTABLISHED FEDERAL POLICIES

A significant number of computer security policies and associated requirements have been
promulgated by Federal government elements. The interested reader is referred to reference [32] which
analyzes the need for trusted systems in the civilian agencies of the Federal government, as well as in
state and local governments and in the private sector. This reference also details a number of relevant
Federal statutes, policies and requirements not treated further below.

Security guidance for Federal automated information systems is provided by the Office of
Management and Budget. Two specifically applicable Circulars have been issued. OMB Circular No.
A-71, Transmittal Memorandum No. 1, "Security of Federal Automated Information Systems,"[26]
directs each executive agency to establish and maintain a computer security program. It makes the
head of each executive branch, department and agency responsible "for assuring an adequate level of
security for all agency data whether processed in-house or commercially. This includes responsibility
for the establishment of physical, administrative and technical safeguards required to adequately
protect personal, proprietary or other sensitive data not subject to national security regulations, as well
as national security data."[26, para. 4 p. 2]

OMB Circular No. A-123, "Internal Control Systems,"[27] issued to help eliminate fraud, waste, and
abuse in government programs requires: (a) agency heads to issue internal control directives and assign
responsibility, (b) managers to review programs for vulnerability, and (c) managers to perform
periodic reviews to evaluate strengths and update controls. Soon after promulgation of OMB Circular
A-123, the relationship of its internal control requirements to building secure computer systems was
recognized.[4] While not stipulating computer controls specifically, the definition of Internal Controls
in A-123 makes it clear that computer systems are to be included:

"Internal Controls - The plan of organization and all of the methods and measures adopted within an
agency to safeguard its resources, assure the accuracy and reliability of its information, assure
adherence to applicable laws, regulations and policies, and promote operational economy and
efficiency."[27, sec. 4.C]

The matter of classified national security information processed by ADP systems was one of the first
areas given serious and extensive concern in computer security. The computer security policy
documents promulgated as a result contain generally more specific and structured requirements than
most, keyed in turn to an authoritative basis that itself provides a rather clearly articulated and
structured information security policy. This basis, Executive Order 12356, "National Security
Information," sets forth requirements for the classification, declassification and safeguarding of
"national security information" per se.[14]

7.2 DOD POLICIES

Within the Department of Defence, these broad requirements are implemented and further specified

Universal Knowledge Solutions S.A.L.

- 71 -
primarily through two vehicles: 1) DoD Regulation 5200.1-R [7], which applies to all components of
the DoD as such, and 2) DoD 5220.22-M, "Industrial Security Manual for Safeguarding Classified
Information" [11], which applies to contractors included within the Defence Industrial Security
Program. Note that the latter transcends DoD as such, since it applies not only to any contractors
handling classified information for any DoD component, but also to the contractors of eighteen other
Federal organizations for whom the Secretary of Defence is authorized to act in rendering industrial
security services.*

* i.e., NASA, Commerce Department, GSA, State Department, Small Business Administration, National
Science Foundation, Treasury Department, Transportation Department, Interior Department,
Agriculture Department, U.S. Information Agency, Labor Department, Environmental Protection
Agency, Justice Department, U.S. Arms Control and Disarmament Agency, Federal Emergency
Management Agency, Federal Reserve System, and U.S. General Accounting Office.

For ADP systems, these information security requirements are further amplified and specified in: 1)
DoD Directive 5200.28 [8] and DoD Manual 5200.28-M [9], for DoD components; and 2) Section XIII
of DoD 5220.22-M [11] for contractors. DoD Directive 5200.28, "Security Requirements for
Automatic Data Processing (ADP) Systems," stipulates: "Classified material contained in an ADP
system shall be safeguarded by the continuous employment of protective features in the system's
hardware and software design and configuration . . . ."[8, sec. IV] Furthermore, it is required that ADP
systems that "process, store, or use classified data and produce classified information will, with
reasonable dependability, prevent:

a. Deliberate or inadvertent access to classified material by unauthorized persons, and

b. Unauthorized manipulation of the computer and its associated peripheral devices."[8, sec. I B.3]

Requirements equivalent to these appear within DoD 5200.28-M [9] and in DoD 5220.22-M [11].

DoD Directove 5200.28 provides the security requirements for ADP systems. For some types of
information, such as Sensitive Compartmented Information (SCI), DoD Directive 5200.28 states that
other minimum security requirements also apply. These minima are found in DCID l/l6 (new reference
number 5) which is implemented in DIAM 50-4 (new reference number 6) for DoD and DoD
contractor ADP systems.

From requirements imposed by these regulations, directives and circulars, the three components of the
Security Policy Control Objective, i.e., Mandatory and Discretionary Security and Marking, as well as
the Accountability and Assurance Control Objectives, can be functionally defined for DoD
applications. The following discussion provides further specificity in Policy for these Control
Objectives.

7.3 CRITERIA CONTROL OBJECTIVE FOR SECURITY POLICY 7.3.1 Marking

The control objective for marking is: "Systems that are designed to enforce a mandatory security
policy must store and preserve the integrity of classification or other sensitivity labels for all
information. Labels exported from the system must be accurate representations of the corresponding
internal sensitivity labels being exported."

DoD 5220.22-M, "Industrial Security Manual for Safeguarding Classified Information," explains in
paragraph 11 the reasons for marking information:

Universal Knowledge Solutions S.A.L.

- 72 -
"a. General. Classification designation by physical marking, notation or other means serves to warn
and to inform the holder what degree of protection against unauthorized disclosure is required for that
information or material." (14)

Marking requirements are given in a number of policy statements.

Executive Order 12356 (Sections 1.5.a and 1.5.a.1) requires that classification markings "shall be
shown on the face of all classified documents, or clearly associated with other forms of classified
information in a manner appropriate to the medium involved."[14]

DoD Regulation 5200.1-R (Section 1-500) requires that: ". . . information or material that requires
protection against unauthorized disclosure in the interest of national security shall be classified in one
of three designations, namely: 'Top Secret,' 'Secret' or 'Confidential.'"[7] (By extension, for use in
computer processing, the unofficial designation "Unclassified" is used to indicate information that does
not fall under one of the other three designations of classified information.)

DoD Regulation 5200.1-R (Section 4-304b) requires that: "ADP systems and word processing systems
employing such media shall provide for internal classification marking to assure that classified
information contained therein that is reproduced or generated, will bear applicable classification and
associated markings." (This regulation provides for the exemption of certain existing systems where
"internal classification and applicable associated markings cannot be implemented without extensive
system modifications."[7] However, it is clear that future DoD ADP systems must be able to provide
applicable and accurate labels for classified and other sensitive information.)

DoD Manual 5200.28-M (Section IV, 4-305d) requires the following: "Security Labels - All classified
material accessible by or within the ADP system shall be identified as to its security classification and
access or dissemination limitations, and all output of the ADP system shall be appropriately
marked."[9]

7.3.2 Mandatory Security

The control objective for mandatory security is: "Security policies defined for systems that are used to
process classified or other specifically categorized sensitive information must include provisions for
the enforcement of mandatory access control rules. That is, they must include a set of rules for
controlling access based directly on a comparison of the individual's clearance or authorization for the
information and the classification or sensitivity designation of the information being sought, and
indirectly on considerations of physical and other environmental factors of control. The mandatory
access control rules must accurately reflect the laws, regulations, and general policies from which they
are derived."

There are a number of policy statements that are related to mandatory security.

Executive Order 12356 (Section 4.1.a) states that "a person is eligible for access to classified
information provided that a determination of trustworthiness has been made by agency heads or
designated officials and provided that such access is essential to the accomplishment of lawful and
authorized Government purposes."[14]

DoD Regulation 5200.1-R (Chapter I, Section 3) defines a Special Access Program as "any program
imposing 'need-to-know' or access controls beyond those normally provided for access to Confidential,
Secret, or Top Secret information. Such a program includes, but is not limited to, special clearance,
adjudication, or investigative requirements, special designation of officials authorized to determine
'need-to-know', or special lists of persons determined to have a 'need-to- know.'"[7, para. 1-328] This

Universal Knowledge Solutions S.A.L.

- 73 -
passage distinguishes between a 'discretionary' determination of need-to-know and formal need-to-
know which is implemented through Special Access Programs. DoD Regulation 5200.1-R, paragraph
7-100 describes general requirements for trustworthiness (clearance) and need-to-know, and states that
the individual with possession, knowledge or control of classified information has final responsibility
for determining if conditions for access have been met. This regulation further stipulates that "no one
has a right to have access to classified information solely by virtue of rank or position." [7, para. 7-
100])

DoD Manual 5200.28-M (Section II 2-100) states that, "Personnel who develop, test (debug), maintain,
or use programs which are classified or which will be used to access or develop classified material
shall have a personnel security clearance and an access authorization (need-to-know), as appropriate
for the highest classified and most restrictive category of classified material which they will access
under system constraints."[9]

DoD Manual 5220.22-M (Paragraph 3.a) defines access as "the ability and opportunity to obtain
knowledge of classified information. An individual, in fact, may have access to classified information
by being in a place where such information is kept, if the security measures which are in force do not
prevent him from gaining knowledge of the classified information."[11]

The above mentioned Executive Order, Manual, Directives and Regulations clearly imply that a trusted
computer system must assure that the classification labels associated with sensitive data cannot be
arbitrarily changed, since this could permit individuals who lack the appropriate clearance to access
classified information. Also implied is the requirement that a trusted computer system must control the
flow of information so that data from a higher classification cannot be placed in a storage object of
lower classification unless its "downgrading" has been authorized.

7.3.3 Discretionary Security

The term discretionary security refers to a computer system's ability to control information on an
individual basis. It stems from the fact that even though an individual has all the formal clearances for
access to specific classified information, each individual's access to information must be based on a
demonstrated need-to-know. Because of this, it must be made clear that this requirement is not
discretionary in a "take it or leave it" sense. The directives and regulations are explicit in stating that
the need-to-know test must be satisfied before access can be granted to the classified information. The
control objective for discretionary security is: "Security policies defined for systems that are used to
process classified or other sensitive information must include provisions for the enforcement of
discretionary access control rules. That is, they must include a consistent set of rules for controlling
and limiting access based on identified individuals who have been determined to have a need-to-know
for the information."

DoD Regulation 5200.1-R (Paragraph 7-100) In addition to excerpts already provided that touch on
need-to- know, this section of the regulation stresses the need- to-know principle when it states "no
person may have access to classified information unless . . . access is necessary for the performance of
official duties."[7]

Also, DoD Manual 5220.22-M (Section III 20.a) states that "an individual shall be permitted to have
access to classified information only . . . when the contractor determines that access is necessary in the
performance of tasks or services essential to the fulfilment of a contract or program, i.e., the individual
has a need-to-know."[11]

7.4 CRITERIA CONTROL OBJECTIVE FOR ACCOUNTABILITY

Universal Knowledge Solutions S.A.L.

- 74 -
The control objective for accountability is: "Systems that are used to process or handle classified or
other sensitive information must assure individual accountability whenever either a mandatory or
discretionary security policy is invoked. Furthermore, to assure accountability the capability must exist
for an authorized and competent agent to access and evaluate accountability information by a secure
means, within a reasonable amount of time, and without undue difficulty."

This control objective is supported by the following citations:

DoD Directive 5200.28 (VI.A.1) states: "Each user's identity shall be positively established, and his
access to the system, and his activity in the system (including material accessed and actions taken)
controlled and open to scrutiny."[8]

DoD Manual 5200.28-M (Section V 5-100) states: "An audit log or file (manual, machine, or a
combination of both) shall be maintained as a history of the use of the ADP System to permit a regular
security review of system activity. (e.g., The log should record security related transactions, including
each access to a classified file and the nature of the access, e.g., logins, production of accountable
classified outputs, and creation of new classified files. Each classified file successfully accessed
[regardless of the number of individual references] during each 'job' or 'interactive session' should also
be recorded in the audit log. Much of the material in this log may also be required to assure that the
system preserves information entrusted to it.)"[9]

DoD Manual 5200.28-M (Section IV 4-305f) states: "Where needed to assure control of access and
individual accountability, each user or specific group of users shall be identified to the ADP System by
appropriate administrative or hardware/software measures. Such identification measures must be in
sufficient detail to enable the ADP System to provide the user only that material which he is
authorized."[9]

DoD Manual 5200.28-M (Section I 1-102b) states:

"Component's Designated Approving Authorities, or their designees for this purpose . . . will assure:

.................

(4) Maintenance of documentation on operating systems (O/S) and all modifications thereto, and its
retention for a sufficient period of time to enable tracing of security- related defects to their point of
origin or inclusion in the system.

.................

(6) Establishment of procedures to discover, recover, handle, and dispose of classified material
improperly disclosed through system malfunction or personnel action.

(7) Proper disposition and correction of security deficiencies in all approved ADP Systems, and the
effective use and disposition of system housekeeping or audit records, records of security violations or
security-related system malfunctions, and records of tests of the security features of an ADP
System."[9]

DoD Manual 5220.22-M (Section XIII 111) states: "Audit Trails

a. The general security requirement for any ADP system audit trail is that it provide a documented
history of the use of the system. An approved audit trail will permit review of classified system activity

Universal Knowledge Solutions S.A.L.

- 75 -
and will provide a detailed activity record to facilitate reconstruction of events to determine the
magnitude of compromise (if any) should a security malfunction occur. To fulfil this basic
requirement, audit trail systems, manual, automated or a combination of both must document
significant events occurring in the following areas of concern: (i) preparation of input data and
dissemination of output data (i.e., reportable interactivity between users and system support personnel),
(ii) activity involved within an ADP environment (e.g., ADP support personnel modification of
security and related controls), and (iii) internal machine activity.

b. The audit trail for an ADP system approved to process classified information must be based on the
above three areas and may be stylized to the particular system. All systems approved for classified
processing should contain most if not all of the audit trail records listed below. The contractor's SPP
documentation must identify and describe those applicable:

1. Personnel access;

2. Unauthorized and surreptitious entry into the central computer facility or remote terminal areas;

3. Start/stop time of classified processing indicating pertinent systems security initiation and
termination events (e.g., upgrading/downgrading actions pursuant to paragraph 107);

4. All functions initiated by ADP system console operators;

5. Disconnects of remote terminals and peripheral devices (paragraph 107c);

6. Log-on and log-off user activity;

7. Unauthorized attempts to access files or programs, as well as all open, close, create, and file destroy
actions;

8. Program aborts and anomalies including identification information (i.e., user/program name, time
and location of incident, etc.);

9. System hardware additions, deletions and maintenance actions;

10. Generations and modifications affecting the security features of the system software.

c. The ADP system security supervisor or designee shall review the audit trail logs at least weekly to
assure that all pertinent activity is properly recorded and that appropriate action has been taken to
correct any anomaly. The majority of ADP systems in use today can develop audit trail systems in
accord with the above; however, special systems such as weapons, communications, communications
security, and tactical data exchange and display systems, may not be able to comply with all aspects of
the above and may require individualized consideration by the cognizant security office.

d. Audit trail records shall be retained for a period of one inspection cycle."[11]

7.5 CRITERIA CONTROL OBJECTIVE FOR ASSURANCE

The control objective for assurance is: "Systems that are used to process or handle classified or other
sensitive information must be designed to guarantee correct and accurate interpretation of the security
policy and must not distort the intent of that policy. Assurance must be provided that correct
implementation and operation of the policy exists throughout the system's life-cycle."

Universal Knowledge Solutions S.A.L.

- 76 -
A basis for this objective can be found in the following sections of DoD Directive 5200.28:

DoD Directive 5200.28 (IV.B.1) stipulates: "Generally, security of an ADP system is most effective
and economical if the system is designed originally to provide it. Each Department of Defence
Component undertaking design of an ADP system which is expected to process, store, use, or produce
classified material shall: From the beginning of the design process, consider the security policies,
concepts, and measures prescribed in this Directive."[8]

DoD Directive 5200.28 (IV.C.5.a) states: "Provision may be made to permit adjustment of ADP
system area controls to the level of protection required for the classification category and type(s) of
material actually being handled by the system, provided change procedures are developed and
implemented which will prevent both the unauthorized access to classified material handled by the
system and the unauthorized manipulation of the system and its components. Particular attention shall
be given to the continuous protection of automated system security measures, techniques and
procedures when the personnel security clearance level of users having access to the system
changes."[8]

DoD Directive 5200.28 (VI.A.2) states: "Environmental Control. The ADP System shall be externally
protected to minimize the likelihood of unauthorized access to system entry points, access to classified
information in the system, or damage to the system."[8]

DoD Manual 5200.28-M (Section I 1-102b) states:

"Component's Designated Approving Authorities, or their designees for this purpose . . . will assure:

.................

(5) Supervision, monitoring, and testing, as appropriate, of changes in an approved ADP System which
could affect the security features of the system, so that a secure system is maintained.

.................

(7) Proper disposition and correction of security deficiencies in all approved ADP Systems, and the
effective use and disposition of system housekeeping or audit records, records of security violations or
security-related system malfunctions, and records of tests of the security features of an ADP System.

(8) Conduct of competent system ST&E, timely review of system ST&E reports, and correction of
deficiencies needed to support conditional or final approval or disapproval of an ADP System for the
processing of classified information.

(9) Establishment, where appropriate, of a central ST&E coordination point for the maintenance of
records of selected techniques, procedures, standards, and tests used in the testing and evaluation of
security features of ADP Systems which may be suitable for validation and use by other Department of
Defence Components."[9]

DoD Manual 5220.22-M (Section XIII 103a) requires: "the initial approval, in writing, of the cognizant
security office prior to processing any classified information in an ADP system. This section requires
reapproval by the cognizant security office for major system modifications made subsequent to initial
approval. Reapprovals will be required because of (i) major changes in personnel access requirements,
(ii) relocation or structural modification of the central computer facility, (iii) additions, deletions or
changes to main frame, storage or input/output devices, (iv) system software changes impacting
security protection features, (v) any change in clearance, declassification, audit trail or

Universal Knowledge Solutions S.A.L.

- 77 -
hardware/software maintenance procedures, and (vi) other system changes as determined by the
cognizant security office."[11]

A major component of assurance, life-cycle assurance, as described in DoD Directive 7920.l, is

concerned with testing ADP systems both in the development phase as well as during operation (17).
DoD Directive 5215.1 (Section F.2.C.(2)) requires "evaluations of selected industry and government-
developed trusted computer systems against these criteria."[10]

8.0 A GUIDELINE ON COVERT CHANNELS [toc]

A covert channel is any communication channel that can be exploited by a process to transfer
information in a manner that violates the system's security policy. There are two types of covert
channels: storage channels and timing channels. Covert storage channels include all vehicles that
would allow the direct or indirect writing of a storage location by one process and the direct or indirect
reading of it by another. Covert timing channels include all vehicles that would allow one process to
signal information to another process by modulating its own use of system resources in such a way that
the change in response time observed by the second process would provide information.

From a security perspective, covert channels with low bandwidths represent a lower threat than those
with high bandwidths. However, for many types of covert channels, techniques used to reduce the
bandwidth below a certain rate (which depends on the specific channel mechanism and the system
architecture) also have the effect of degrading the performance provided to legitimate system users.
Hence, a trade-off between system performance and covert channel bandwidth must be made. Because
of the threat of compromise that would be present in any multilevel computer system containing
classified or sensitive information, such systems should not contain covert channels with high
bandwidths. This guideline is intended to provide system developers with an idea of just how high a
"high" covert channel bandwidth is.

A covert channel bandwidth that exceeds a rate of one hundred (100) bits per second is considered
"high" because 100 bits per second is the approximate rate at which many computer terminals are run.
It does not seem appropriate to call a computer system "secure" if information can be compromised at
a rate equal to the normal output rate of some commonly used device.

In any multilevel computer system there are a number of relatively low-bandwidth covert channels
whose existence is deeply ingrained in the system design. Faced with the large potential cost of
reducing the bandwidths of such covert channels, it is felt that those with maximum bandwidths of less
than one (1) bit per second are acceptable in most application environments. Though maintaining
acceptable performance in some systems may make it impractical to eliminate all covert channels with
bandwidths of 1 or more bits per second, it is possible to audit their use without adversely affecting
system performance. This audit capability provides the system administration with a means of
detecting -- and procedurally correcting -- significant compromise. Therefore, a Trusted Computing
Base should provide, wherever possible, the capability to audit the use of covert channel mechanisms
with bandwidths that may exceed a rate of one (1) bit in ten (10) seconds.

The covert channel problem has been addressed by a number of authors. The interested reader is
referred to references [5], [6], [19], [21], [22], [23], and [29].

Universal Knowledge Solutions S.A.L.

- 78 -
9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES [toc]

The Mandatory Access Control requirement includes a capability to support an unspecified number of
hierarchical classifications and an unspecified number of non-hierarchical categories at each
hierarchical level. To encourage consistency and portability in the design and development of the
National Security Establishment trusted computer systems, it is desirable for all such systems to be
able to support a minimum number of levels and categories. The following suggestions are provided
for this purpose:

* The number of hierarchical classifications should be greater than or equal to sixteen (16).

* The number of non-hierarchical categories should be greater than or equal to sixty-four (64).

10.0 A GUIDELINE ON SECURITY TESTING [toc]

These guidelines are provided to give an indication of the extent and sophistication of testing
undertaken by the DoD Computer Security Center during the Formal Product Evaluation process.
Organizations wishing to use "Department of Defence Trusted Computer System Evaluation Criteria"
for performing their own evaluations may find this section useful for planning purposes.

As in Part I, highlighting is used to indicate changes in the guidelines from the next lower division.

10.1 TESTING FOR DIVISION C

10.1.1 Personnel

The security testing team shall consist of at least two individuals with bachelor degrees in Computer
Science or the equivalent. Team members shall be able to follow test plans prepared by the system
developer and suggest additions, shall be familiar with the "flaw hypothesis" or equivalent security
testing methodology, and shall have assembly level programming experience. Before testing begins,
the team members shall have functional knowledge of, and shall have completed the system
developer's internals course for, the system being evaluated.

10.1.2 Testing

The team shall have "hands-on" involvement in an independent run of the tests used by the system
developer. The team shall independently design and implement at least five system-specific tests in an
attempt to circumvent the security mechanisms of the system. The elapsed time devoted to testing shall
be at least one month and need not exceed three months. There shall be no fewer than twenty hands-on
hours spent carrying out system developer-defined tests and test team-defined tests.

10.2 TESTING FOR DIVISION B

10.2.1 Personnel

Universal Knowledge Solutions S.A.L.

- 79 -
Science or the equivalent and at least one individual with a master's degree in Computer Science or
equivalent. Team members shall be able to follow test plans prepared by the system developer and
suggest additions, shall be conversant with the "flaw hypothesis" or equivalent security testing
methodology, shall be fluent in the TCB implementation language(s), and shall have assembly level
programming experience. Before testing begins, the team members shall have functional knowledge
of, and shall have completed the system developer's internals course for, the system being evaluated.
At least one team member shall have previously completed a security test on another system.

10.2.2 Testing

The team shall have "hands-on" involvement in an independent run of the test package used by the
system developer to test security-relevant hardware and software. The team shall independently design
and implement at least fifteen system- specific tests in an attempt to circumvent the security
mechanisms of the system. The elapsed time devoted to testing shall be at least two months and need
not exceed four months. There shall be no fewer than thirty hands-on hours per team member spent
carrying out system developer-defined tests and test team-defined tests.

10.3 TESTING FOR DIVISION A

10.3.1 Personnel

The security testing team shall consist of at least one individual with a bachelor's degree in Computer
Science or the equivalent and at least two individuals with masters' degrees in Computer Science or
equivalent. Team members shall be able to follow test plans prepared by the system developer and
suggest additions, shall be conversant with the "flaw hypothesis" or equivalent security testing
methodology, shall be fluent in the TCB implementation language(s), and shall have assembly level
programming experience. Before testing begins, the team members shall have functional knowledge
of, and shall have completed the system developer's internals course for, the system being evaluated.
At least one team member shall be familiar enough with the system hardware to understand the
maintenance diagnostic programs and supporting hardware documentation. At least two team members
shall have previously completed a security test on another system. At least one team member shall
have demonstrated system level programming competence on the system under test to a level of
complexity equivalent to adding a device driver to the system.

10.3.2 Testing

The team shall have "hands-on" involvement in an independent run of the test package used by the
system developer to test security-relevant hardware and software. The team shall independently design
and implement at least twenty-five system- specific tests in an attempt to circumvent the security
mechanisms of the system. The elapsed time devoted to testing shall be at least three months and need
not exceed six months. There shall be no fewer than fifty hands-on hours per team member spent
carrying out system developer-defined tests and test team-defined tests.

APPENDIX A [toc]

COMMERCIAL PRODUCE EVALUATION PROCESS

"Department of Defence Trusted Computer System Evaluation Criteria" forms the basis upon which
the Computer Security Center will carry out the commercial computer security evaluation process.
This process is focused on commercially produced and supported general-purpose operating system

Universal Knowledge Solutions S.A.L.

- 80 -
products that meet the needs of government departments and agencies. The formal evaluation is aimed
at "off-the-shelf" commercially supported products and is completely divorced from any consideration
of overall system performance, potential applications, or particular processing environments. The
evaluation provides a key input to a computer system security approval/accreditation. However, it does
not constitute a complete computer system security evaluation. A complete study (e.g., as in reference
[18]) must consider additional factors dealing with the system in its unique environment, such as it's
proposed security mode of operation, specific users, applications, data sensitivity, physical and
personnel security, administrative and procedural security, TEMPEST, and communications security.

The product evaluation process carried out by the Computer Security Center has three distinct
elements:

• Preliminary Product Evaluation - An informal dialogue between a vendor and the Center in
which technical information is exchanged to create a common understanding of the
vendor's product, the criteria, and the rating that may be expected to result from a formal
product evaluation.

• Formal Product Evaluation - A formal evaluation, by the Center, of a product that is

available to the DoD, and that results in that product and its assigned rating being placed
on the Evaluated Products List.

• Evaluated Products List - A list of products that have been subjected to formal product
evaluation and their assigned ratings.

Preliminary Product Evaluation

Since it is generally very difficult to add effective security measures late in a product's life cycle, the
Center is interested in working with system vendors in the early stages of product design. A
preliminary product evaluation allows the Center to consult with computer vendors on computer
security issues found in products that have not yet been formally announced.

A preliminary evaluation is typically initiated by computer system vendors who are planning new
computer products that feature security or major security-related upgrades to existing products. After
an initial meeting between the vendor and the Center, appropriate non-disclosure agreements are
executed that require the Center to maintain the confidentiality of any proprietary information
disclosed to it. Technical exchange meetings follow in which the vendor provides details about the
proposed product (particularly its internal designs and goals) and the Center provides expert feedback
to the vendor on potential computer security strengths and weaknesses of the vendor's design choices,
as well as relevant interpretation of the criteria. The preliminary evaluation is typically terminated
when the product is completed and ready for field release by the vendor. Upon termination, the Center
prepares a wrap-up report for the vendor and for internal distribution within the Center. Those reports
containing proprietary information are not available to the public.

During preliminary evaluation, the vendor is under no obligation to actually complete or market the
potential product. The Center is, likewise, not committed to conduct a formal product evaluation. A
preliminary evaluation may be terminated by either the Center or the vendor when one notifies the
other, in writing, that it is no longer advantageous to continue the evaluation.

Formal Product Evaluation

The formal product evaluation provides a key input to certification of a computer system for use in
National Security Establishment applications and is the sole basis for a product being placed on the

Universal Knowledge Solutions S.A.L.

- 81 -
Evaluated Products List.

A formal product evaluation begins with a request by a vendor for the Center to evaluate a product for
which the product itself and accompanying documentation needed to meet the requirements defined by
this publication are complete. Non-disclosure agreements are executed and a formal product evaluation
team is formed by the Center. An initial meeting is then held with the vendor to work out the schedule
for the formal evaluation. Since testing of the implemented product forms an important part of the
evaluation process, access by the evaluation team to a working version of the system is negotiated with
the vendor. Additional support required from the vendor includes complete design documentation,
source code, and access to vendor personnel who can answer detailed questions about specific portions
of the product. The evaluation team tests the product against each requirement, making any necessary
interpretations of the criteria with respect to the product being evaluated.

The evaluation team writes a final report on their findings about the system. The report is publicly
available (containing no proprietary or sensitive information) and contains the overall class rating
assigned to the system and the details of the evaluation team's findings when comparing the product
against the evaluation criteria. Detailed information concerning vulnerabilities found by the evaluation
team is furnished to the system developers and designers as each is found so that the vendor has a
chance to eliminate as many of them as possible prior to the completion of the Formal Product
Evaluation. Vulnerability analyses and other proprietary or sensitive information are controlled within
the Center through the Vulnerability Reporting Program and are distributed only within the U.S.
Government on a strict need-to-know and non-disclosure basis, and to the vendor.

APPENDIX B [toc]

SUMMARY OF EVALUATION CRITERIA DIVISIONS

The divisions of systems recognized under the trusted computer system evaluation criteria are as
follows. Each division represents a major improvement in the overall confidence one can place in the
system to protect classified and other sensitive information.

Division (D): Minimal Protection

This division contains only one class. It is reserved for those systems that have been evaluated but that
fail to meet the requirements for a higher evaluation class.

Division (C): Discretionary Protection

Classes in this division provide for discretionary (need-to-know) protection and, through the inclusion
of audit capabilities, for accountability of subjects and the actions they initiate.

Division (B): Mandatory Protection

The notion of a TCB that preserves the integrity of sensitivity labels and uses them to enforce a set of
mandatory access control rules is a major requirement in this division. Systems in this division must
carry the sensitivity labels with major data structures in the system. The system developer also
provides the security policy model on which the TCB is based and furnishes a specification of the

Universal Knowledge Solutions S.A.L.

- 82 -
TCB. Evidence must be provided to demonstrate that the reference monitor concept has been
implemented.

Division (A): Verified Protection

This division is characterized by the use of formal security verification methods to assure that the
mandatory and discretionary security controls employed in the system can effectively protect classified
or other sensitive information stored or processed by the system. Extensive documentation is required
to demonstrate that the TCB meets the security requirements in all aspects of design, development and
implementation.

APPENDIX C [toc]

SUMMARY OF EVALUATION CRITERIA CLASSES

The classes of systems recognized under the trusted computer system evaluation criteria are as follows.
They are presented in the order of increasing desirability from a computer security point of view.

Class (D): Minimal Protection

This class is reserved for those systems that have been evaluated but that fail to meet the requirements
for a higher evaluation class.

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.

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.

Class (B1): Labeled 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.

Class (B2): Structured Protection

Universal Knowledge Solutions S.A.L.

- 83 -
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.

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.

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.

APPENDIX D [toc]

REQUIREMENT DIRECTORY

This appendix lists requirements defined in "Department of Defence Trusted Computer System
Evaluation Criteria" alphabetically rather than by class. It is provided to assist in following the
evolution of a requirement through the classes. For each requirement, three types of criteria may be
present. Each will be preceded by the word: NEW, CHANGE, or ADD to indicate the following:

NEW: Any criteria appearing in a lower class are superseded by the criteria that follow.

CHANGE: The criteria that follow have appeared in a lower class but are changed for this class.
Highlighting is used to indicate the specific changes to previously stated criteria.

Universal Knowledge Solutions S.A.L.

- 84 -
ADD: The criteria that follow have not been required for any lower class, and are added in this class to
the previously stated criteria for this requirement.

Abbreviations are used as follows:

NR: (No Requirement) This requirement is not included in this class.

NAR: (No Additional Requirements) This requirement does not change from the previous class.

The reader is referred to Part I of this document when placing new criteria for a requirement into the
complete context for that class.

Figure 1 provides a pictorial summary of the evolution of requirements through the classes. [see chart
elsewhere]

Audit

C1: NR.

C2: NEW: 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 of 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.

B1: CHANGE: 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 and the object's security level. The ADP
system administrator shall be able to selectively audit the actions of any one or more users based on
individual identity and/or object security level.

ADD: The TCB shall also be able to audit any override of human-readable output markings.

B2: ADD: The TCB shall be able to audit the identified events that may be used in the exploitation of
covert storage channels.

B3: ADD: The TCB shall contain a mechanism that is able to monitor the occurrence or accumulation
of security auditable events that may indicate an imminent violation of security policy. This
mechanism shall be able to immediately notify the security administrator when thresholds are
exceeded, and, if the occurrence or accumulation of these security relevant events continues, the
system shall take the lease disruptive action to terminate the event.

A1: NAR.

Configuration Management

Universal Knowledge Solutions S.A.L.

- 85 -
C1: NR.

C2: NR.

B1: NR.

B2: NEW: During development and maintenance of the TCB, a configuration management system
shall be in place that maintains control of changes to the descriptive top-level specification, other
design data, implementation documentation, source code, the running version of the object code, and
test fixtures and documentation. The configuration management system shall assure a consistent
mapping among all documentation and code associated with the current version of the TCB. Tools
shall be provided for generation of a new version of the TCB from source code. Also available shall be
tools for comparing a newly generated version with the previous TCB version in order to ascertain that
only the intended changes have been made in the code that will actually be used as the new version of
the TCB.

B3: NAR.

A1: CHANGE: During the entire life-cycle, i.e., during the design, development, and maintenance of
the TCB, a configuration management system shall be in place for all security-relevant hardware,
firmware, and software that maintains control of changes to the formal model, the descriptive and
formal top-level specifications, other design data, implementation documentation, source code, the
running version of the object code, and test fixtures and documentation. Also available shall be tools,
maintained under strict configuration control, for comparing a newly generated version with the
previous TCB version in order to ascertain that only the intended changes have been made in the code
that will actually be used as the new version of the TCB.

ADD: A combination of technical, physical, and procedural safeguards shall be used to protect from
unauthorized modification or destruction the master copy or copies of all material used to generate the
TCB.

Covert Channel Analysis

C1: NR.

C2: NR.

B1: NR.

B2: NEW: The system developer shall conduct a thorough search for covert storage channels and make
a determination (either by actual measurement or by engineering estimation) of the maximum
bandwidth of each identified channel. (See the Covert Channels Guideline section.)

B3: CHANGE: The system developer shall conduct a thorough search for covert channels and make a
determination (either by actual measurement or by engineering estimation) of the maximum bandwidth
of each identified channel.

A1: ADD: Formal methods shall be used in the analysis.

Design Documentation

Universal Knowledge Solutions S.A.L.

- 86 -
C1: NEW: Documentation shall be available that provides a description of the manufacturer's
philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the
TCB is composed of distinct modules, the interfaces between these modules shall be described.

C2: NAR.

B1: ADD: An informal or formal description of the security policy model enforced by the TCB shall
be available and an explanation provided to show that it is sufficient to enforce the security policy. The
specific TCB protection mechanisms shall be identified and an explanation given to show that they
satisfy the model.

B2: CHANGE: The interfaces between the TCB modules shall be described. A formal description of
the security policy model enforced by the TCB shall be available and proven that it is sufficient to
enforce the security policy.

ADD: The descriptive top-level specification (DTLS) shall be shown to be an accurate description of
the TCB interface. Documentation shall describe how the TCB implements the reference monitor
concept and give an explanation why it is tamper resistant, cannot be bypassed, and is correctly
implemented. Documentation shall describe how the TCB is structured to facilitate testing and to
enforce least privilege. This documentation shall also present the results of the covert channel analysis
and the tradeoffs involved in restricting the channels. All auditable events that may be used in the
exploitation of known covert storage channels shall be identified. The bandwidths of known covert
storage channels, the use of which is not detectable by the auditing mechanisms, shall be provided.
(See the Covert Channel Guideline section.)

B3: ADD: The TCB implementation (i.e., in hardware, firmware, and software) shall be informally
shown to be consistent with the DTLS. The elements of the DTLS shall be shown, using informal
techniques, to correspond to the elements of the TCB.

A1: CHANGE: The TCB implementation (i.e., in hardware, firmware, and software) shall be
informally shown to be consistent with the formal top-level specification (FTLS). The elements of the
FTLS shall be shown, using informal techniques, to correspond to the elements of the TCB.

ADD: Hardware, firmware, and software mechanisms not dealt with in the FTLS but strictly internal to
the TCB (e.g., mapping registers, direct memory access I/O) shall be clearly described.

Design Specification and Verification

C1: NR.

C2: NR.

B1: NEW: An informal or formal model of the security policy supported by the TCB shall be
maintained over the life cycle of the ADP system that is shown to be consistent with its axioms.

B2: CHANGE: A formal model of the security policy supported by the TCB shall be maintained over
the life cycle of the ADP system that is proven consistent with its axioms.

ADD: A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely
and accurately describes the TCB in terms of exceptions, error messages, and effects. It shall be shown
to be an accurate description of the TCB interface.

Universal Knowledge Solutions S.A.L.

- 87 -
B3: ADD: A convincing argument shall be given that the DTLS is consistent with the model.

A1: CHANGE: The FTLS shall be shown to be an accurate description of the TCB interface. A
convincing argument shall be given that the DTLS is consistent with the model and a combination of
formal and informal techniques shall be used to show that the FTLS is consistent with the model.

ADD: A formal top-level specification (FTLS) of the TCB shall be maintained that accurately
describes the TCB in terms of exceptions, error messages, and effects. The DTLS and FTLS shall
include those components of the TCB that are implemented as hardware and/or firmware if their
properties are visible at the TCB interface. This verification evidence shall be consistent with that
provided within the state-of-the-art of the particular Computer Security Center- endorsed formal
specification and verification system used. Manual or other mapping of the FTLS to the TCB source
code shall be performed to provide evidence of correct implementation.

Device Labels

C1: NR.

C2: NR.

B1: NR.

B2: NEW: The TCB shall support the assignment of minimum and maximum security levels to all
attached physical devices. These security levels shall be used by the TCB to enforce constraints
imposed by the physical environments in which the devices are located.

B3: NAR.

A1: NAR.

Discretionary Access Control

C1: NEW: 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 or both.

C2: CHANGE: 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.

ADD: 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.

B1: NAR.

B2: NAR.

B3: CHANGE: The enforcement mechanism (e.g., access control lists) shall allow users to specify and

Universal Knowledge Solutions S.A.L.

- 88 -
control sharing of those objects, and shall provide controls to limit propagation of access rights. These
access controls shall be capable of specifying, for each named object, a list of named individuals and a
list of groups of named individuals with their respective modes of access to that object.

ADD: Furthermore, for each such named object, it shall be possible to specify a list of named
individuals and a list of groups of named individuals for which no access to the object is to be given.

A1: NAR.

Exportation of Labeled Information

C1: NR.

C2: NR.

B1: NEW: The TCB shall designate each communication channel and I/O device as either single-level
or multilevel. Any change in this designation shall be done manually and shall be auditable by the
TCB. The TCB shall maintain and be able to audit any change in the security level or levels associated
with a communication channel or I/O device.

B2: NAR.

B3: NAR.

A1: NAR.

Exportation to Multilevel Devices

C1: NR.

C2: NR.

B1: NEW: When the TCB exports an object to a multilevel I/O device, the sensitivity label associated
with that object shall also be exported and shall reside on the same physical medium as the exported
information and shall be in the same form (i.e., machine-readable or human-readable form). When the
TCB exports or imports an object over a multilevel communication channel, the protocol used on that
channel shall provide for the unambiguous pairing between the sensitivity labels and the associated
information that is sent or received.

B2: NAR.

B3: NAR.

A1: NAR.

Exportation to Single-Level Devices

C1: NR.

C2: NR.

Universal Knowledge Solutions S.A.L.

- 89 -
B1: NEW: Single-level I/O devices and single-level communication channels are not required to
maintain the sensitivity labels of the information they process. However, the TCB shall include a
mechanism by which the TCB and an authorized user reliably communicate to designate the single
security level of information imported or exported via single-level communication channels or I/O
devices.

B2: NAR.

B3: NAR.

A1: NAR.

Identification and Authentication

C1: NEW: 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.

C2: ADD: 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.

B1: CHANGE: Furthermore, the TCB shall maintain authentication data that includes information for
verifying the identity of individual users (e.g., passwords) as well as information for determining the
clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the
user's identity and to ensure that the security level and authorizations of subjects external to the TCB
that may be created to act on behalf of the individual user are dominated by the clearance and
authorization of that user.

B2: NAR.

B3: NAR.

A1: NAR.

Label Integrity

C1: NR.

C2: NR.

B1: NEW: Sensitivity labels shall accurately represent security levels of the specific subjects or objects
with which they are associated. When exported by the TCB, sensitivity labels shall accurately and
unambiguously represent the internal labels and shall be associated with the information being
exported.

B2: NAR.

B3: NAR.

Universal Knowledge Solutions S.A.L.

- 90 -
A1: NAR.

Labelling Human-Readable Output

C1: NR.

C2: NR.

B1: NEW: The ADP system administrator shall be able to specify the printable label names associated
with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable,
paged, hardcopy output (e.g., line printer output) with human- readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each
page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable
sensitivity labels that properly* represent the overall sensitivity of the output or that properly*
represent the sensitivity of the information on the page. The TCB shall, by default and in an
appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these
marking defaults shall be auditable by the TCB.

B2: NAR.

B3: NAR.

A1: NAR.

* The hierarchical classification component in human-readable sensitivity labels shall be equal to the
greatest hierarchical classification of any of the information in the output that the labels refer to; the
non-hierarchical category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical categories.

Labels

C1: NR.

C2: NR.

B1: NEW: Sensitivity labels associated with each subject and storage object under its control (e.g.,
process, file, segment, device) shall be maintained by the TCB. These labels shall be used as the basis
for mandatory access control decisions. In order to import non- labelled data, the TCB shall request
and receive from an authorized user the security level of the data, and all such actions shall be
auditable by the TCB.

B2: CHANGE: Sensitivity labels associated with each ADP system resource (e.g., subject, storage
object, ROM) that is directly or indirectly accessible by subjects external to the TCB shall be
maintained by the TCB.

B3: NAR.

A1: NAR.

Mandatory Access Control

Universal Knowledge Solutions S.A.L.

- 91 -
C1: NR.

C2: NR.

B1: NEW: The TCB shall enforce a mandatory access control policy over all subjects and storage
objects under its control (e.g., processes, files, segments, devices). These subjects and objects shall be
assigned sensitivity labels that are a combination of hierarchical classification levels and non-
hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions.
The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control
guidelines.) The following requirements shall hold for all accesses between subjects and objects
controlled by the TCB: A subject can read an object only if the hierarchical classification in the
subject's security level is greater than or equal to the hierarchical classification in the object's security
level and the non-hierarchical categories in the subject's security level include all the non-hierarchical
categories in the object's security level. A subject can write an object only if the hierarchical
classification in the subject's security level is less than or equal to the hierarchical classification in the
object's security level and all the non-hierarchical categories in the subject's security level are included
in the non-hierarchical categories in the object's security level. Identification and authentication data
shall be used by the TCB to authenticate the user's identity and to ensure that the security level and
authori- zation of subjects external to the TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of that user.

B2: CHANGE: The TCB shall enforce a mandatory access control policy over all resources (i.e.,
subjects, storage objects, and I/O devices) that are directly or indirectly accessible by subjects external
to the TCB. The following requirements shall hold for all accesses between all subjects external to the
TCB and all objects directly or indirectly accessible by these subjects:

B3: NAR.

A1: NAR.

Object Reuse

C1: NR.

C2: NEW: 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.

B1: NAR.

B2: NAR.

B3: NAR.

A1: NAR.

Security Features User's Guide

C1: NEW: A single summary, chapter, or manual in user documentation shall describe the protection

Universal Knowledge Solutions S.A.L.

- 92 -
mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.

C2: NAR.

B1: NAR.

B2: NAR.

B3: NAR.

A1: NAR.

Security Testing

C1: NEW: 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. (See
the Security Testing guidelines.)

C2: ADD: 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.

B1: NEW: The security mechanisms of the ADP system shall be tested and found to work as claimed
in the system documentation. A team of individuals who thoroughly understand the specific
implementation of the TCB shall subject its design documentation, source code, and object code to
thorough analysis and testing. Their objectives shall be: to uncover all design and implementation
flaws that would permit a subject external to the TCB to read, change, or delete data normally denied
under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no
subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to
respond to communications initiated by other users. All discovered flaws shall be removed or
neutralized and the TCB retested to demonstrate that they have been eliminated and that new flaws
have not been introduced. (See the Security Testing Guidelines.)

B2: CHANGE: All discovered flaws shall be corrected and the TCB retested to demonstrate that they
have been eliminated and that new flaws have not been introduced.

ADD: The TCB shall be found relatively resistant to penetration. Testing shall demonstrate that the
TCB implementation is consistent with the descriptive top-level specification.

B3: CHANGE: The TCB shall be found resistant to penetration.

ADD: No design flaws and no more than a few correctable implementation flaws may be found during
testing and there shall be reasonable confidence that few remain.

A1: CHANGE: Testing shall demonstrate that the TCB implementation is consistent with the formal
top-level specification.

ADD: Manual or other mapping of the FTLS to the source code may form a basis for penetration
testing.

Subject Sensitivity Labels

Universal Knowledge Solutions S.A.L.

- 93 -
C1: NR.

C2: NR.

B1: NR.

B2: NEW: The TCB shall immediately notify a terminal user of each change in the security level
associated with that user during an interactive session. A terminal user shall be able to query the TCB
as desired for a display of the subject's complete sensitivity label.

B3: NAR.

A1: NAR.

System Architecture

C1: NEW: 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.

C2: ADD: The TCB shall isolate the resources to be protected so that they are subject to the access
control and auditing requirements.

B1: ADD: The TCB shall maintain process isolation through the provision of distinct address spaces
under its control.

B2: NEW: 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). The TCB shall maintain
process isolation through the provision of distinct address spaces under its control. The TCB shall be
internally structured into well- defined largely independent modules. It shall make effective use of
available hardware to separate those elements that are protection- critical from those that are not. The
TCB modules shall be designed such that the principle of least privilege is enforced. Features in
hardware, such as segmentation, shall be used to support logically distinct storage objects with separate
attributes (namely: readable, writeable). The user interface to the TCB shall be completely defined and
all elements of the TCB identified.

B3: ADD: The TCB shall be designed and structured to use a complete, conceptually simple protection
mechanism with precisely defined semantics. This mechanism shall play a central role in enforcing the
internal structuring of the TCB and the system. The TCB shall incorporate significant use of layering,
abstraction and data hiding. Significant system engineering shall be directed toward minimizing the
complexity of the TCB and excluding from the TCB modules that are not protection-critical.

A1: NAR.

System Integrity

C1: NEW: 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.

C2: NAR.

Universal Knowledge Solutions S.A.L.

- 94 -
B1: NAR.

B2: NAR.

B3: NAR.

A1: NAR.

Test Documentation

C1: NEW: The system developer shall provide to the evaluators a document that describes the test
plan, test procedures that show how the security mechanisms were tested and results of the security
mechanisms' functional testing.

C2: NAR.

B1: NAR.

B2: ADD: It shall include results of testing the effectiveness of the methods used to reduce covert
channel bandwidths.

B3: NAR.

A1: ADD: The results of the mapping between the formal top-level specification and the TCB source
code shall be given.

Trusted Distribution

C1: NR.

C2: NR.

B1: NR.

B2: NR.

B3: NR.

A1: NEW: A trusted ADP system control and distribution facility shall be provided for maintaining the
integrity of the mapping between the master data describing the current version of the TCB and the on-
site master copy of the code for the current version. Procedures (e.g., site security acceptance testing)
shall exist for assuring that the TCB software, firmware, and hardware updates distributed to a
customer are exactly as specified by the master copies.

Trusted Facility Management

C1: NR.

C2: NR.

B1: NR.

Universal Knowledge Solutions S.A.L.

- 95 -
B2: NEW: The TCB shall support separate operator and administrator functions.

B3: ADD: The functions performed in the role of a security administrator shall be identified. The ADP
system administrative personnel shall only be able to perform security administrator functions after
taking a distinct auditable action to assume the security administrator role on the ADP system. Non-
security functions that can be performed in the security administration role shall be limited strictly to
those essential to performing the security role effectively.

A1: NAR.

Trusted Facility Manual

C1: NEW: A manual addressed to the ADP system administrator shall present cautions about functions
and privileges that should be controlled when running a secure facility.

C2: ADD: The procedures for examining and maintaining the audit files as well as the detailed audit
record structure for each type of audit event shall be given.

B1: ADD: The manual shall describe the operator and administrator functions related to security, to
include changing the characteristics of a user. It shall provide guidelines on the consistent and effective
use of the protection features of the system, how they interact, how to securely generate a new TCB,
and facility procedures, warnings, and privileges that need to be controlled in order to operate the
facility in a secure manner.

B2: ADD: The TCB modules that contain the reference validation mechanism shall be identified. The
procedures for secure generation of a new TCB from source after modification of any modules in the
TCB shall be described.

B3: ADD: It shall include the procedures to ensure that the system is initially started in a secure
manner. Procedures shall also be included to resume secure system operation after any lapse in system
operation.

A1: NAR.

Trusted Path

C1: NR.

C2: NR.

B1: NR.

B2: NEW: The TCB shall support a trusted communication path between itself and user for initial
login and authentication. Communications via this path shall be initiated exclusively by a user.

B3: CHANGE: The TCB shall support a trusted communication path between itself and users for use
when a positive TCB-to-user connection is required (e.g., login, change subject security level).
Communications via this trusted path shall be activated exclusively by a user or the TCB and shall be
logically isolated and unmistakably distinguishable from other paths.

A1: NAR.

Universal Knowledge Solutions S.A.L.

- 96 -
Trusted Recovery

C1: NR.

C2: NR.

B1: NR.

B2: NR.

B3: NEW: Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure
or other discontinuity, recovery without a protection compromise is obtained.

A1: NAR.

(this page is reserved for Figure 1)

GLOSSARY [toc]

Access - A specific type of interaction between a subject and an object that results in the flow of
information from one to the other.

Approval/Accreditation - The official authorization that is granted to an ADP system to process

sensitive information in its operational environment, based upon comprehensive security evaluation of
the system's hardware, firmware, and software security design, configuration, and implementation and
of the other system procedural, administrative, physical, TEMPEST, personnel, and communications
security controls.

Audit Trail - A set of records that collectively provide documentary evidence of processing used to aid
in tracing from original transactions forward to related records and reports, and/or backwards from
records and reports to their component source transactions.

Authenticate - To establish the validity of a claimed identity.

Automatic Data Processing (ADP) System - An assembly of computer hardware, firmware, and
software configured for the purpose of classifying, sorting, calculating, computing, summarizing,
transmitting and receiving, storing, and retrieving data with a minimum of human intervention.

Bandwidth - A characteristic of a communication channel that is the amount of information that can be
passed through it in a given amount of time, usually expressed in bits per second.

Bell-LaPadula Model - A formal state transition model of computer security policy that describes a set
of access control rules. In this formal model, the entities in a computer system are divided into abstract

Universal Knowledge Solutions S.A.L.

- 97 -
sets of subjects and objects. The notion of a secure state is defined and it is proven that each state
transition preserves security by moving from secure state to secure state; thus, inductively proving that
the system is secure. A system state is defined to be "secure" if the only permitted access modes of
subjects to objects are in accordance with a specific security policy. In order to determine whether or
not a specific access mode is allowed, the clearance of a subject is compared to the classification of the
object and a determination is made as to whether the subject is authorized for the specific access mode.
The clearance/classification scheme is expressed in terms of a lattice. See also: Lattice, Simple
Security Property, *- Property.

Certification - The technical evaluation of a system's security features, made as part of and in support
of the approval/accreditation process, that establishes the extent to which a particular computer
system's design and implementation meet a set of specified security requirements.

Channel - An information transfer path within a system. May also refer to the mechanism by which the
path is effected.

Covert Channel - A communication channel that allows a process to transfer information in a manner
that violates the system's security policy. See also: Covert Storage Channel, Covert Timing Channel.

Covert Storage Channel - A covert channel that involves the direct or indirect writing of a storage
location by one process and the direct or indirect reading of the storage location by another process.
Covert storage channels typically involve a finite resource (e.g., sectors on a disk) that is shared by two
subjects at different security levels.

Covert Timing Channel - A covert channel in which one process signals information to another by
modulating its own use of system resources (e.g., CPU time) in such a way that this manipulation
affects the real response time observed by the second process.

Data - Information with a specific physical representation.

Data Integrity - The state that exists when computerized data is the same as that in the source
documents and has not been exposed to accidental or malicious alteration or destruction.

Descriptive Top-Level Specification (DTLS) - A top-level specification that is written in a natural

language (e.g., English), an informal program design notation, or a combination of the two.

Discretionary Access Control - A means of restricting access to objects based on the identity of
subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject
with a certain access permission is capable of passing that permission (perhaps indirectly) on to any
other subject (unless restrained by mandatory access control).

Domain - The set of objects that a subject has the ability to access.

Dominate - Security level S1 is said to dominate security level S2 if the hierarchical classification of
S1 is greater than or equal to that of S2 and the non-hierarchical categories of S1 include all those of
S2 as a subset.

Exploitable Channel - Any channel that is useable or detectable by subjects external to the Trusted
Computing Base.

Flaw Hypothesis Methodology - A system analysis and penetration technique where specifications and

Universal Knowledge Solutions S.A.L.

- 98 -
documentation for the system are analyzed and then flaws in the system are hypothesized. The list of
hypothesized flaws is then prioritized on the basis of the estimated probability that a flaw actually
exists and, assuming a flaw does exist, on the ease of exploiting it and on the extent of control or
compromise it would provide. The prioritized list is used to direct the actual testing of the system.

Flaw - An error of commission, omission, or oversight in a system that allows protection mechanisms
to be bypassed.

Formal Proof - A complete and convincing mathematical argument, presenting the full logical
justification for each proof step, for the truth of a theorem or set of theorems. The formal verification
process uses formal proofs to show the truth of certain properties of formal specification and for
showing that computer programs satisfy their specifications.

Formal Security Policy Model - A mathematically precise statement of a security policy. To be

adequately precise, such a model must represent the initial state of a system, the way in which the
system progresses from one state to another, and a definition of a "secure" state of the system. To be
acceptable as a basis for a TCB, the model must be supported by a formal proof that if the initial state
of the system satisfies the definition of a "secure" state and if all assumptions required by the model
hold, then all future states of the system will be secure. Some formal modelling techniques include:
state transition models, temporal logic models, denotational semantics models, algebraic specification
models. An example is the model described by Bell and LaPadula in reference [2]. See also: Bell-
LaPadula Model, Security Policy Model.

Formal Top-Level Specification (FTLS) - A Top-Level Specification that is written in a formal

mathematical language to allow theorems showing the correspondence of the system specification to
its formal requirements to be hypothesized and formally proven.

Formal Verification - The process of using formal proofs to demonstrate the consistency (design
verification) between a formal specification of a system and a formal security policy model or
(implementation verification) between the formal specification and its program implementation.

Front-End Security Filter - A process that is invoked to process data according to a specified security
policy prior to releasing the data outside the processing environment or upon receiving data from an
external source.

Functional Testing - The portion of security testing in which the advertised features of a system are
tested for correct operation.

General-Purpose System - A computer system that is designed to aid in solving a wide variety of
problems.

Granularity - The relative fineness or coarseness by which a mechanism can be adjusted. The phrase
"the granularity of a single user" means the access control mechanism can be adjusted to include or
exclude any single user.

Lattice - A partially ordered set for which every pair of elements has a greatest lower bound and a least
upper bound.

Least Privilege - This principle requires that each subject in a system be granted the most restrictive set
of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of
this principle limits the damage that can result from accident, error, or unauthorized use.

Universal Knowledge Solutions S.A.L.

- 99 -
Mandatory Access Control - A means of restricting access to objects based on the sensitivity (as
represented by a label) of the information contained in the objects and the formal authorization (i.e.,
clearance) of subjects to access information of such sensitivity.

Multilevel Device - A device that is used in a manner that permits it to simultaneously process data of
two or more security levels without risk of compromise. To accomplish this, sensitivity labels are
normally stored on the same physical medium and in the same form (i.e., machine-readable or human-
readable) as the data being processed.

Multilevel Secure - A class of system containing information with different sensitivities that
simultaneously permits access by users with different security clearances and needs-to- know, but
prevents users from obtaining access to information for which they lack authorization.

Object - A passive entity that contains or receives information. Access to an object potentially implies
access to the information it contains. Examples of objects are: records, blocks, pages, segments, files,
directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video
displays, keyboards, clocks, printers, network nodes, etc.

Object Reuse - The reassignment to some subject of a medium (e.g., page frame, disk sector, magnetic
tape) that contained one or more objects. To be securely reassigned, such media must contain no
residual data from the previously contained object(s).

Output - Information that has been exported by a TCB.

Password - A private character string that is used to authenticate an identity.

Penetration Testing - The portion of security testing in which the penetrators attempt to circumvent the
security features of a system. The penetrators may be assumed to use all system design and
implementation documentation, which may include listings of system source code, manuals, and
circuit diagrams. The penetrators work under no constraints other than those that would be applied to
ordinary users.

Process - A program in execution. It is completely characterized by a single current execution point

(represented by the machine state) and address space.

Protection-Critical Portions of the TCB - Those portions of the TCB whose normal function is to deal
with the control of access between subjects and objects.

Protection Philosophy - An informal description of the overall design of a system that delineates each
of the protection mechanisms employed. A combination (appropriate to the evaluation class) of formal
and informal techniques is used to show that the mechanisms are adequate to enforce the security
policy.

Read - A fundamental operation that results only in the flow of information from an object to a
subject.

Read Access - Permission to read information.

Read-Only Memory (ROM) - A storage area in which the contents can be read but not altered during
normal computer processing.

Universal Knowledge Solutions S.A.L.

- 100 -
Reference Monitor Concept - An access control concept that refers to an abstract machine that
mediates all accesses to objects by subjects.

Resource - Anything used or consumed while performing a function. The categories of resources are:
time, information, objects (information containers), or processors (the ability to use information).
Specific examples are: CPU time; terminal connect time; amount of directly-addressable memory; disk
space; number of I/O requests per minute, etc.

Security Kernel - The hardware, firmware, and software elements of a Trusted Computing Base that
implement the reference monitor concept. It must mediate all accesses, be protected from modification,
and be verifiable as correct.

Security Level - The combination of a hierarchical classification and a set of non-hierarchical

categories that represents the sensitivity of information.

Security Policy - The set of laws, rules, and practices that regulate how an organization manages,
protects, and distributes sensitive information.

Security Policy Model - An informal presentation of a formal security policy model.

Security Relevant Event - Any event that attempts to change the security state of the system, (e.g.,
change discretionary access controls, change the security level of the subject, change user password,
etc.). Also, any event that attempts to violate the security policy of the system, (e.g., too many attempts
to login, attempts to violate the mandatory access control limits of a device, attempts to downgrade a
file, etc.).

Security Testing - A process used to determine that the security features of a system are implemented
as designed and that they are adequate for a proposed application environment. This process includes
hands-on functional testing, penetration testing, and verification. See also: Functional Testing,
Penetration Testing, Verification.

Sensitive Information - Information that, as determined by a competent authority, must be protected

because its unauthorized disclosure, alteration, loss, or destruction will at least cause perceivable
damage to someone or something.

Sensitivity Label - A piece of information that represents the security level of an object and that
describes the sensitivity (e.g., classification) of the data in the object. Sensitivity labels are used by the
TCB as the basis for mandatory access control decisions.

Simple Security Condition - A Bell-LaPadula security model rule allowing a subject read access to an
object only if the security level of the subject dominates the security level of the object.

Single-Level Device - A device that is used to process data of a single security level at any one time.
Since the device need not be trusted to separate data of different security levels, sensitivity labels do
not have to be stored with the data being processed.

*-Property (Star Property) - A Bell-LaPadula security model rule allowing a subject write access to an
object only if the security level of the subject is dominated by the security level of the object. Also
known as the Confinement Property.

Storage Object - An object that supports both read and write accesses.

Universal Knowledge Solutions S.A.L.

- 101 -
Subject - An active entity, generally in the form of a person, process, or device that causes information
to flow among objects or changes the system state. Technically, a process/domain pair.

Subject Security Level - A subject's security level is equal to the security level of the objects to which
it has both read and write access. A subject's security level must always be dominated by the clearance
of the user the subject is associated with.

TEMPEST - The study and control of spurious electronic signals emitted from ADP equipment.

Top-Level Specification (TLS) - A non-procedural description of system behaviour at the most

abstract level. Typically a functional specification that omits all implementation details.

Trap Door - A hidden software or hardware mechanism that permits system protection mechanisms to
be circumvented. It is activated in some non-apparent manner (e.g., special "random" key sequence at a
terminal).

Trojan Horse - A computer program with an apparently or actually useful function that contains
additional (hidden) functions that surreptitiously exploit the legitimate authorizations of the invoking
process to the detriment of security. For example, making a "blind copy" of a sensitive file for the
creator of the Trojan Horse.

Trusted Computer System - A system that employs sufficient hardware and software integrity
measures to allow its use for processing simultaneously a range of sensitive or classified information.

Trusted Computing Base (TCB) - The totality of protection mechanisms within a computer system --
including hardware, firmware, and software -- the combination of which is responsible for enforcing a
security policy. A TCB consists of one or more components that together enforce a unified security
policy over a product or system. The ability of a trusted computing base to correctly enforce a security
policy depends solely on the mechanisms within the TCB and on the correct input by system
administrative personnel of parameters (e.g., a user's clearance) related to the security policy.

Trusted Path - A mechanism by which a person at a terminal can communicate directly with the
Trusted Computing Base. This mechanism can only be activated by the person or the Trusted
Computing Base and cannot be imitated by untrusted software.

Trusted Software - The software portion of a Trusted Computing Base.

User - Any person who interacts directly with a computer system.

Verification - The process of comparing two levels of system specification for proper correspondence
(e.g., security policy model with top-level specification, TLS with source code, or source code with
object code). This process may or may not be automated.

Write - A fundamental operation that results only in the flow of information from a subject to an
object.

Write Access - Permission to write an object.

Universal Knowledge Solutions S.A.L.

- 102 -
REFERENCES [toc]

1. Anderson, J. P. Computer Security Technology Planning Study, ESD-TR-73-51, vol. I, ESD/AFSC,

Hanscom AFB, Bedford, Mass., October 1972 (NTIS AD-758 206).

2. Bell, D. E. and LaPadula, L. J. Secure Computer Systems: Unified Exposition and Multics
Interpretation, MTR-2997 Rev. 1, MITRE Corp., Bedford, Mass., March 1976.

3. Brand, S. L. "An Approach to Identification and Audit of Vulnerabilities and Control in Application
Systems," in Audit and Evaluation of Computer Security II: System Vulnerabilities and Controls, Z.
Ruthberg, ed., NBS Special Publication #500-57, MD78733, April 1980.

4. Brand, S. L. "Data Processing and A-123," in Proceedings of the Computer Performance Evaluation
User's Group 18th Meeting, C. B. Wilson, ed., NBS Special Publication #500-95, October 1982.

5. DCID l/l6, Security of Foreign Intelligence in Automated Data Processing Systems and Networks
(U), 4 January l983.

6. DIAM 50-4, Security of Compartmented Computer Operations (U), 24 June l980.

7. Denning, D. E. "A Lattice Model of Secure Information Flow," in Communications of the ACM,
vol. 19, no. 5 (May 1976), pp. 236-243.

8. Denning, D. E. Secure Information Flow in Computer Systems, Ph.D. dissertation, Purdue Univ.,
West Lafayette, Ind., May 1975.

9. DoD Directive 5000.29, Management of Computer Resources in Major Defence Systems, 26 April
l976.

10. DoD 5200.1-R, Information Security Program Regulation, August 1982.

11. DoD Directive 5200.28, Security Requirements for Automatic Data Processing (ADP) Systems,
revised April 1978.

12. DoD 5200.28-M, ADP Security Manual -- Techniques and Procedures for Implementing,
Deactivating, Testing, and Evaluating Secure Resource-Sharing ADP Systems, revised June 1979.

13. DoD Directive 5215.1, Computer Security Evaluation Center, 25 October 1982.

14. DoD 5220.22-M, Industrial Security Manual for Safeguarding Classified Information, March
1984.

15. DoD 5220.22-R, Industrial Security Regulation, February 1984.

16. DoD Directive 5400.11, Department of Defence Privacy Program, 9 June 1982.

17. DoD Directive 7920.1, Life Cycle Management of Automated Information Systems (AIS), 17
October 1978

18. Executive Order 12356, National Security Information, 6 April 1982.

Universal Knowledge Solutions S.A.L.

- 103 -
19. Faurer, L. D. "Keeping the Secrets Secret," in Government Data Systems, November - December
1981, pp. 14-17.

20. Federal Information Processing Standards Publication (FIPS PUB) 39, Glossary for Computer
Systems Security, 15 February 1976.

21. Federal Information Processing Standards Publication (FIPS PUB) 73, Guidelines for Security of
Computer Applications, 30 June 1980.

22. Federal Information Processing Standards Publication (FIPS PUB) 102, Guideline for Computer
Security Certification and Accreditation.

23. Lampson, B. W. "A Note on the Confinement Problem," in Communications of the ACM, vol. 16,
no. 10 (October 1973), pp. 613-615.

24. Lee, T. M. P., et al. "Processors, Operating Systems and Nearby Peripherals: A Consensus Report,"
in Audit and Evaluation of Computer Security II: System Vulnerabilities and Controls, Z. Ruthberg,
ed., NBS Special Publication #500-57, MD78733, April 1980.

25. Lipner, S. B. A Comment on the Confinement Problem, MITRE Corp., Bedford, Mass.

26. Millen, J. K. "An Example of a Formal Flow Violation," in Proceedings of the IEEE Computer
Society 2nd International Computer Software and Applications Conference, November 1978, pp. 204-
208.

27. Millen, J. K. "Security Kernel Validation in Practice," in Communications of the ACM, vol. 19, no.
5 (May 1976), pp. 243-250.

28. Nibaldi, G. H. Proposed Technical Evaluation Criteria for Trusted Computer Systems, MITRE
Corp., Bedford, Mass., M79-225, AD-A108-832, 25 October 1979.

29. Nibaldi, G. H. Specification of A Trusted Computing Base, (TCB), MITRE Corp., Bedford, Mass.,
M79-228, AD-A108- 831, 30 November 1979.

30. OMB Circular A-71, Transmittal Memorandum No. 1, Security of Federal Automated Information
Systems, 27 July 1978.

31. OMB Circular A-123, Internal Control Systems, 5 November 1981.

32. Ruthberg, Z. and McKenzie, R., eds. Audit and Evaluation of Computer Security, in NBS Special
Publication #500-19, October 1977.

33. Schaefer, M., Linde, R. R., et al. "Program Confinement in KVM/370," in Proceedings of the ACM
National Conference, October 1977, Seattle.

34. Schell, R. R. "Security Kernels: A Methodical Design of System Security," in Technical Papers,
USE Inc. Spring Conference, 5-9 March 1979, pp. 245-250.

35. Trotter, E. T. and Tasker, P. S. Industry Trusted Computer Systems Evaluation Process, MITRE
Corp., Bedford, Mass., MTR-3931, 1 May 1980.

Universal Knowledge Solutions S.A.L.

- 104 -
36. Turn, R. Trusted Computer Systems: Needs and Incentives for Use in government and Private
Sector, (AD # A103399), Rand Corporation (R-28811-DR&E), June 1981.

37. Walker, S. T. "The Advent of Trusted Computer Operating Systems," in National Computer
Conference Proceedings, May 1980, pp. 655-665.

38. Ware, W. H., ed., Security Controls for Computer Systems: Report of Defence Science Board Task
Force on Computer Security, AD # A076617/0, Rand Corporation, Santa Monica, Calif., February
1970, reissued October 1979.

Universal Knowledge Solutions S.A.L.

- 105 -
 Part 2

Risk Analysis and Management

Keywords:
Risk, Addressing Risk, Threats, Vulnerabilities, Loss.

Summary:
In recent years all sectors of the economy have focused on management of risk as the key to making
organisations successful in delivering their objectives whilst protecting the interests of their
stakeholders.
Risk is uncertainty of outcome, and good risk management allows an organisation to:
• Have increased confidence in achieving its desired outcomes;
• Effectively constrain threats to acceptable levels;
• Take informed decisions about exploiting opportunities.
Good risk management also allows stakeholders to have increased confidence in the organisation’s
corporate governance and ability to deliver to the wider environment in which it functions.

Objectives:
Upon completion of this part, the student will be able to understand:
• What is risk?
• What is risk analysis?
• Why risk analysis is necessary and relationship between threat, vulnerability, and loss
• Risk Analysis Approaches
• Comparison of Risk Analysis Approaches
• Detailed Risk Analysis Approach

Universal Knowledge Solutions S.A.L.

- 106 -
 Introduction

It is a matter of definition that organizations exist for a purpose –perhaps to deliver a service, or to
achieve particular outcomes.

In the private sector the primary purpose of an organization is generally concerned with the
enhancement of shareholder value.

In the central government sector the purpose is generally concerned with the delivery of service or with
the delivery of a beneficial outcome in the public interest.

Whatever the purpose of the organization may be, the delivery of its objectives is surrounded by
uncertainty which both poses threats to success and offers opportunity for increasing success.

Introduction: Risk & Risk Management

Risk is defined as the uncertainty of outcome, whether positive opportunity or negative threat, of
actions and events.

The risk has to be assessed in respect of the combination of the likelihood of something happening, and
the impact which arises if it does actually happen.

Risk management includes identifying and assessing risks (the “inherent risks”) and then responding
to them.

Introduction: Risk appetite

The resources available for managing risk are finite and so the aim is to achieve an optimum response
to risk, prioritized in accordance with an evaluation of the risks.

Risk is unavoidable, and every organization needs to take action to manage risk in a way which it can
justify to a level which is tolerable.
The amount of risk which is judged to be tolerable and justifiable is the risk appetite.

Universal Knowledge Solutions S.A.L.

- 107 -
 Introduction: Response to Risk

Response, which is initiated within the organization, to risk is called internal control and may involve
one or more of the following:
• Tolerating the risk;
• Treating the risk in an appropriate way to constrain the risk to an acceptable level or actively taking
advantage, regarding the uncertainty as an opportunity to gain a benefit;
• Transferring the risk;
• Terminating the activity giving rise to the risk;

In any of these cases the issue of opportunity arising from the uncertainty should be considered.

The level of risk remaining after internal control has been exercised (the “residual risk”) is the
exposure in respect of that risk, and should be acceptable and justifiable – it should be within the risk
appetite.

Introduction: Managing Risk

Effective risk management needs to give full consideration to the context in which the organization
functions and to the risk priorities of partner organizations.

The management of risk at strategic and operational levels needs to be integrated so that the levels of
activity support each other. In this way the risk management strategy of the organization will be led
from the top and embedded in the normal working routines and activities of the organization.

All staff should be aware of the relevance of risk to the achievement of their objectives and training to
support staff in risk management should be available. Managers at each level therefore need to be
equipped with appropriate skills which will allow them to manage risk effectively and the organization
as a whole needs a means of being assured that risk management is being implemented in an
appropriate way at each level.

Every organization should have a risk management strategy, designed to achieve the principles set out
in this publication.
The application of that strategy should be embedded into the organization’s business systems,
including strategy and policy setting processes, to ensure that risk management is an intrinsic part of
the way business is conducted.

Universal Knowledge Solutions S.A.L.

- 108 -
 Introduction: The Risk Management Model

The management of risk is not a linear process; rather it is the balancing of a number of interwoven
elements which interact with each other and which have to be in balance with each other if risk
management is to be effective.

Furthermore, specific risks cannot be addressed in isolation from each other; the management of one
risk may have an impact on another, or management actions which are effective in controlling more
than one risk simultaneously may be achievable.

The whole model has to function in an environment in which risk appetite has been defined. The
concept of risk appetite (how much risk is tolerable and justifiable) can be regarded as an “overlay”
across the whole of this model.

The model presented here, by necessity, dissects the core risk management process into elements for
illustrative purposes but in reality they blend together.

In addition, the particular stage in the process which one may be at for any particular risk will not
necessarily be the same for all risks.

The model illustrates how the core risk management process is not isolated, but takes place in a
context; and, how certain key inputs have to be given to the overall process in order to generate the
outputs which will be desired from risk management.

Universal Knowledge Solutions S.A.L.

- 109 -
 What is Risk Analysis?

Objective of risk analysis is to identify threats and vulnerabilities, to avoid any security failure
(business loss).

Threat Loss

(Threat) ∩ (Vulnerability) = (Loss)

(Computer virus) ∩ (No Anti-Virus Installed) = Data Destruction

Examples of Relationship between Threat, Vulnerability, and Loss

Threats Vulnerabilities Possible loss

Keyboard operation Inadequate manual Interruption of
error service due to system
shutdown
Hardware failure Inadequate Interruption of
maintenance service due to system
shutdown
Illegal procedure by Inadequate training Loss of credit and
employee inadequate log compensation for
setting damage caused by
leakage personal
information
Illegal access from Software bug Data alteration <=
remote site loss of credit recovery
cost (monetary
&time (
Building break-in Inadequate security Damage caused by
check at the entrance stolen hardware

Universal Knowledge Solutions S.A.L.

- 110 -
 Classification of a loss

• Total cost of loss = direct loss + indirect loss

o Direct loss:
ƒ Direct damage to assets (e.g. loss of information)

o Indirect loss:
ƒ Loss of profit (from disruption of service & loss of credibility)
ƒ Incurred liability (e.g. compensations for loss

• An asset is something that the organization values and therefore has to protect. Examples:
o Hardware: servers, PC, routers, firewalls, printers
o Software: programs, OS, utilities
o Data: database, e-mails, backups, logs, data in transit over transmission line
o People: users, administrators, clients
o Printed documents: contracts, financial documents

Why is risk analysis necessary?

• What may happen if we omit the analysis?

o Cannot detect vulnerabilities
o Introduce countermeasures without specific reason
o Remake the whole system
o Take huge cost and time

• Risk analysis leads us to:

o Identify threats to your system
o Estimate damages and possibility of occurrence
o Develop countermeasures to minimize threats

Identifying Risk
In order to manage risk, an organisation needs to know what risks it faces, and to evaluate them.

Identifying risks is the first step in building the organisation’s risk profile. There is no single right way
to document an organisation’s risk profile, but documentation is critical to effective management of
risk.

The identification of risk can be separated into two distinct phases.

Universal Knowledge Solutions S.A.L.

- 111 -
There is:
• Initial risk identification (for an organisation which has not previously identified its risks in a
structured way, or for a new organisation, or perhaps for a new project or activity within an
organisation);
• Continuous risk identification which is necessary to identify new risks which did not previously
arise, changes in existing risks, or risks which did exist ceasing to be relevant to the organisation
(this should be a routine element of the conduct of business).

It is also necessary to adopt an appropriate approach or tool for the identification of risk. Two of the
most commonly used approaches are:
• Commissioning a risk review: A designated team is established (either in- house or contracted in)
to consider all the operations and activities of the organisation in relation to its objectives and to
identify the associated risks. The team should work by conducting a series of interviews with key
staff at all levels of the organisation to build a risk profile for the whole range of activities (but it is
important that the use of this approach should not undermine line management ’s understanding of
their responsibility for managing the risks which are relevant to their objectives);
• Risk self-assessment: An approach by which each level and part of the organisation is invited to
review its activities and to contribute its diagnosis of the risks it faces. This may be done through a
documentation approach (with a framework for diagnosis set out through questionnaires),but is
often more effectively conducted through a facilitated workshop approach (with facilitators with
appropriate skills helping groups of staff to work out the risks affecting their objectives).A
particular strength of this approach is that better ownership of risk tends to be established when the
owners themselves identify the risks.

Risk Appetite
The concept of a risk appetite is key concept to achieve effective risk management and it is essential
to consider it before moving on to consideration of how risks can be addressed.

The concept may be looked at in different ways depending on whether the risk (the uncertainty) being
considered is a threat or an opportunity:
• When considering threats the concept of risk appetite embraces the level of exposure which is
considered tolerable and justifiable should it be realised. In this sense it is about comparing the cost
(financial or otherwise) of constraining the risk with the cost of the exposure should the exposure
become a reality and finding an acceptable balance;
• When considering opportunities the concept embraces consideration of how much one is prepared
to actively put at risk in order to obtain the benefits of the opportunity. In this sense it is about
comparing the value (financial or otherwise) of potential benefits with the losses which might be
incurred (some losses may be incurred with or without realising the benefits).

It should be noted that some risk is unavoidable and it is not within the ability of the organisation to
completely manage it to a tolerable level – for example many organisations have to accept that there is
a risk arising from terrorist activity which they cannot control. In these cases the organisation needs to
make contingency plans.

Universal Knowledge Solutions S.A.L.

- 112 -
 Addressing Risk

Possibility
of
facing
the TREAT TERMINATE
risk

TOLERATE TRANSFER

Cost of Loss

The purpose of addressing risks is to turn uncertainty to the organisation’s benefit by constraining
threats and taking advantage of opportunities.

Any action that is taken by the organisation to address a risk forms part of what is known as “internal
control”. There are five key aspects of addressing risk:

TOLERATE
The exposure may be tolerable without any further action being taken. Even if it is not tolerable, ability
to do anything about some risks may be limited, or the cost of taking any action may be
disproportionate to the potential benefit gained.
In these cases the response may be to tolerate the existing level of risk.
This option, of course, may be supplemented by contingency planning for handling the impacts that
will arise if the risk is realised.

TREAT
By far the greater number of risks will be addressed in this way. The purpose of treatment is that whilst
continuing within the organisation with the activity giving rise to the risk, action (control) is taken
constrain the risk to an acceptable level.
Such controls can be further sub-divided according to their particular purpose.

TRANSFER
For some risks the best response may be to transfer them. This might be done by conventional
insurance, or it might be done by paying a third party to take the risk in another way.
This option is particularly good for mitigating financial risks or risks to assets. The transfer of risks
may be considered to either reduce the exposure of the organisation or because another organisation
(which may be another government organisation)is more capable of effectively managing the risk. It is
important to note that some risks are not (fully) transferable –in particular it is generally not possible to
transfer reputational risk even if the delivery of a service is contracted out.
The relationship with the third party to which the risk is transferred needs to be carefully managed to
ensure successful transfer of risk

TERMINATE
Some risks will only be treatable, or containable to acceptable levels, by terminating the activity.
It should be noted that the option of termination of activities may be severely limited in government

Universal Knowledge Solutions S.A.L.

- 113 -
when compared to the private sector; a number of activities are conducted in the government sector
because the associated risks are so great that there is no other way in which the output or outcome,
which is required for the public benefit, can be achieved.
This option can be particularly important in project management if it becomes clear that the projected
cost /benefit relationship is in jeopardy.

TAKE THE OPPORTUNITY

This option is not an alternative to those above; rather it is an option which should be considered
whenever tolerating, transferring or treating a risk.
There are two aspects to this:
• The first is whether or not at the same time as mitigating threats; an opportunity arises to exploit
positive impact. For example, if a large sum of capital funding is to be put at risk in a major
project, are the relevant controls judged to be good enough to justify increasing the sum of money
at stake to gain even greater advantages?
• The second is whether or not circumstances arise which, whilst not generating threats, offer
positive opportunities. For example, a drop in the cost of goods or services frees up resources
which can be re-deployed.

Risk Analysis Approaches

• Baseline Approach
o Apply a set of safeguards to achieve a baseline of protection of each system
o Using safeguard baseline materials: ISO17799, GMITS

• Detailed Approach
o In-depth identification and evaluation of assets
o In-depth Assessment of the levels of threats and associated vulnerabilities

• Follow-up combined Approach

o Combination of baseline and detailed approaches

• Informal Approach
o Not based on a structured analysis
o Exploit the knowledge and experience of individuals

Universal Knowledge Solutions S.A.L.

- 114 -
 Comparison of Risk Analysis Approaches

Baseline Detailed Follow-up Informal

Approach Approach Approach Approach

Advantages Less Cost Near complete Focus attention Least cost

and time to important and time
assets

Disadvantages Overlook Take time and Require skills Depends on

some cost of baseline and the skill of
factors detailed the person
approach

Detailed Risk Analysis Approach

Universal Knowledge Solutions S.A.L.

- 115 -
Detailed Risk Analysis Approach:
Quantitative & Qualitative analysis

Detailed Risk Analysis Approach:

Analysis of asset (C, I, A)

Universal Knowledge Solutions S.A.L.

- 116 -
 Detailed Risk Analysis Approach:
Level of Threats and Vulnerabilities

Detailed Risk Analysis Approach:

Level of overall risk

(Result > 9) Æ Risk is high

Universal Knowledge Solutions S.A.L.

- 117 -
 Part 3
Threats & Vulnerabilities
Keywords:
Trojan horse, Back Orifice, Malicious Code, Virus, Anti-Virus, Mobile Code, ActiveX, Java Applet,
JavaScript.

Summary:
A typical attack is not a simple, one-step procedure. It's rare that an attacker can get online or dial up a
remote computer and use only one method to gain full access. It's more likely that the attacker will
need several techniques in combination to bypass the many layers of protection standing between the
attacker and root administrative access. Therefore, as a security consultant or network administrator,
you should be well-versed in these techniques in order to thwart them. This section introduces the main
types of attacks as well as system vulnerabilities. Later sections discuss some of the more popular
measures.

Objectives:
Upon completion of this part, the student will be able to understand:
• Threats to computer systems.
• Vulnerabilities of computer systems.
• Examples of threats and vulnerabilities.
• General procedure of illegal access.

Universal Knowledge Solutions S.A.L.

- 118 -
 Security Design Procedure

• Phase1 - Establishing Executive Policy:

• Phase2 - Risk Analysis and Management:

• Phase3 & Phase4 - Establishing Standards & Procedures:

o Conduct Risk Analysis
ƒ Require Knowledge of threats and vulnerabilities

Threats to computer systems

• External
o Illegal access from the Internet.

• Internal
o Steal, alter, or delete confidential files.
o Steal hardware devices.
o Virus Infection.
o Operation mistake.
o Illegal access to the Internet.

Likely sources of Attacks (US Statistics)

Percentage of
companies
attacked by each
kind of attack

Foreign Foreign Independent US. Disgruntled

gov. Corp. Hackers Competitors Employee

• 26% of US companies have been attacked by foreign Government.

Universal Knowledge Solutions S.A.L.

- 119 -
• 26% of US companies have been attacked by foreign Corporations.
• 82% of US companies have been attacked by Independent Hackers.
• 38% of US companies have been attacked by Local (US) Competitors.
• 75% of US companies have been attacked internally.

Who are these guys?

Originally all people with a high level of skills at computing were known as hackers. Over time, the
distinction between those perceived to use such skills with social responsibility and those who used
them maliciously or criminally became perceived as an important divide. Two terminologies
developed: the former became known as hackers or (within the computer security industry) as white
hats, and the latter as crackers or black hats.
The general public tends to use the term "hackers" for both types, a source of some conflict when the
word is perceived to be used incorrectly in written reports. In computer jargon the meaning of "hacker"
can be much broader.

Hacker (A White Hat):

A hacker is often someone who creates and modifies computer software or computer hardware,
including computer programming, administration, and security-related items. A hacker is also someone
who modifies electronics, for example, ham radio transceivers, printers or even home sprinkler systems
to get extra functionality or performance. The term usually bears strong connotations, but may be
either favorable or denigrating depending on cultural context.

Cracker (A Black Hat):

Usually a Black Hat is a person who uses their knowledge of vulnerabilities and exploits for private
gain, rather than revealing them either to the general public or the manufacturer for correction.
Black Hats may seek to expand holes in systems; any attempts made to patch software are generally
done to prevent others from also compromising a system they have already obtained secure control
over. In the most extreme cases, Black Hats may work to cause damage maliciously, and/or make
threats to do so..

Actually, Hacking and cracking become easier since thousands of hacking tools are available on the
Internet. Such tools can:
• Decode encrypted password file.
• Detect a security hole in the firewall.
• Detect a bug on server.
• Create a computer virus.
• and more...

Universal Knowledge Solutions S.A.L.

- 120 -
 Vulnerabilities of computer systems

• Vulnerability:
o A weakness in the organization, computer system, or network.

• Example:
o Security policy is not set.
o Roles and responsibilities are vague.
o Security training of employees are inadequate.
o Building entrance are not checked completely.
o There is no protection against computer viruses.
o Software bugs exist.
o No password rules are set.
o Confidential data are sent without encryption over the network.

Security Holes

• A security hole is security problem of the system or a place where the security problem may occur

Voice Over
(Same text of the slide)

Propositions

(No Proposition)

Slide
Within the office

• Threats
o Break-ins: by delivery man for example.
o Theft of keys, ID cards.
o Access of an unauthorized person.

• Vulnerabilities
o Lost of keys or ID Cards.

Universal Knowledge Solutions S.A.L.

- 121 -
 Malicious Code

• Trojan Horse
• Virus
• Mobile Code

Malicious Code: Trojan Horses

The Greek siege of Troy had lasted for ten years. The Greeks devised a new ruse: a giant hollow
wooden horse. It was built by Epeius and filled with Greek warriors led by Odysseus. The rest of the
Greek army appeared to leave, but actually hid behind Tenedos. Meanwhile, a Greek spy, Sinon,
convinced the Trojans that the horse was a gift despite the warnings of Laocoon and Cassandra; Helen
and Deiphobus even investigated the horse; in the end, the Trojans accepted the gift. In ancient times it
was customary for a defeated general to surrender his horse to the victorious general in a sign of
respect. It should be noted here that the horse was the sacred animal of Poseidon; during the contest
with Athena over the patronage of Athens, Poseidon gave men the horse, and Athena gave the olive
tree.

The Trojans hugely celebrated the end of the siege, so that, when the Greeks emerged from the horse,
the city was in a drunken stupor. The Greek warriors opened the city gates to allow the rest of the army
to enter, and the city was pillaged ruthlessly, all the men were killed, and all the women and children
were taken into slavery.
The Trojan Bell is an ancillary component to the myth; according to lore, it signaled the beginning of
the assault on Troy. The Trojan horse may or may not actually have been built and used. The only
evidence known to modern scholars are literary references written long after the alleged event.
Within the territories of the ancient city of Troy, near the Dardanelles (modern Turkey), is a small
museum, founded in 1955, that includes the remnants of the city, along with a wooden horse built in
the museum garden to depict the legendary Trojan horse. The wooden horse from the recent film Troy
is displayed on the seafront in the nearby town of Çanakkale.

From this mythological episode comes the term Trojan horse as a general term describing an apparent
advantage that is actually a trick; "Trojan horse" tactics are those considered sneaky, underhand,
deceitful. The term can also refer to a "sneak attack" in general. The term "Trojan" is also widely used
today to refer to malicious computer software that looks harmless to the user but actually contains a
computer virus or spyware.

Malicious Code: Trojan Horses

What is a Trojan horse?

• Trojan horse attacks pose one of the most serious threats to computer security.

• According to legend, the Greeks won the Trojan war by hiding in a huge, hollow wooden horse to
sneak into the fortified city of Troy.

Universal Knowledge Solutions S.A.L.

- 122 -
• In today's computer world, a Trojan horse is defined as a "malicious, security-breaking program
that is disguised as something benign".

• For example, we download what appears to be a movie or music file, but when we click on it, we
unleash a dangerous program that erases our disk, sends our credit card numbers and passwords to
a stranger, or lets that stranger hijack our computer to commit illegal denial of service attacks like
those that have virtually crippled the DALnet IRC network for months on end.

• The following general information applies to all operating systems, but by far most of the damage
is done to/with Windows users due to its vast popularity and many weaknesses.

Malicious Code: Trojan Horses

How did we get Infected?

• Trojans are executable programs, which means that when we open the file, it will perform some
action(s).

• In Windows, executable programs have file extensions like "exe", "vbs", "com", "bat", etc.

• Some actual trojan filenames include: "dmsetup.exe" and "LOVE-LETTER-FOR-YOU.TXT.vbs"

(when there are multiple extensions, only the last one counts, thus, we must be sure to unhide our
extensions so that you see it).

• Trojans can be spread in the guise of literally ANYTHING people find desirable, such as a free
game, movie, song, etc.

• Victims typically downloaded the trojan from a WWW or FTP archive, got it via peer-to-peer file
exchange using IRC/instant messaging/Kazaa etc., or just carelessly opened some email
attachment.

• Trojans usually do their damage silently. The first sign of trouble is often when others tell us that
we are attacking them or trying to infect them!

Malicious Code: Trojan Horses

How do we avoid getting infected?

We must be certain of BOTH the source AND content of each file you download! In other words,
we need to be sure that we trust not only the person or file server that gave us the file, but also the
contents of the file itself.

Universal Knowledge Solutions S.A.L.

- 123 -
Here are some practical tips to avoid getting infected:
1. NEVER download blindly from people or sites which we aren't 100% sure about. If we do a
lot of file downloading, it's often just a matter of time before we fall victim to a trojan.
2. Even if the file comes from a friend, we still must be sure what the file is before opening it,
because many trojans will automatically try to spread themselves to friends in an email address
book or on an IRC channel. There is seldom reason for a friend to send us a file that we didn't ask
for. When in doubt, we must ask them first, and scan the attachment with a fully updated anti-virus
program.
3. Beware of hidden file extensions! Windows by default hides the last extension of a file, so that
innocuous-looking "susie.jpg" might really be "susie.jpg.exe" - an executable trojan! To reduce the
chances of being tricked, we must unhide those extensions.
4. NEVER use features in our programs that automatically get or preview files. Those features
may seem convenient, but they let anybody send us anything which is extremely reckless. For
example, we must never turn on "auto DCC get" in mIRC, instead ALWAYS screen every single
file we get manually. Likewise, disable the preview mode in Outlook and other email programs.
5. Never blindly type commands that others tell us to type, or go to web addresses mentioned by
strangers, or run pre-fabricated programs or scripts (not even popular ones). If we do so, we
are potentially trusting a stranger with control over our computer, which can lead to trojan infection
or other serious harm.
6. Don't be lulled into a false sense of security just because you run anti-virus programs. Those
do not protect perfectly against many viruses and trojans, even when fully up to date. Anti-virus
programs should not be our front line of security, but instead they serve as a backup in case
something sneaks onto our computer.
7. Finally, we must avoid any download of executable programs just to "check it out" - if it's a
trojan, the first time we run it, we’re already infected!

Malicious Code: Trojan Horses

How do We get rid of trojans?

1. Clean Re-installation:
• Although arduous, this will always be the only sure way to eradicate a trojan or virus.
• In this case, we must:
o Back up our entire hard disk,
o Reformat the disk,.
o Re-install the operating system and all our applications from original CDs,
o Restore our user files from the backup if we’re certain they are not infected.

2. Anti-Virus Software:
• Some of these can handle most of the well known trojans, but none are perfect, no matter what
their advertising claims.
• We absolutely MUST make sure we have the very latest update files for our programs, or else
they will miss the latest trojans.
• Compared to traditional viruses, today's trojans evolve much quicker and come in many
seemingly innocuous forms, so anti-virus software is always going to be playing catch up.
• Also, if they fail to find every trojan, anti-virus software can give us a false sense of security,
such that we go about our business not realizing that we are still dangerously compromised.

Universal Knowledge Solutions S.A.L.

- 124 -
 • There are many products to choose from, but the following are generally effective: AVP, PC-
cillin, and McAfee VirusScan. All are available for immediate downloading typically with a 30
day free trial.

3. Anti-Trojan Programs:
• These programs are the most effective against trojan horse attacks, because they specialize in
trojans instead of general viruses.
• A popular choice is The Cleaner, $30 commercial software with a 30 day free trial.
• To use it effectively, we must follow hackfix.org's configuration suggestions.
• When we are done, we must make sure we’ve updated Windows with all security patches, then
we must change all our passwords because they may have been seen by every "hacker" in the
world.

Malicious Code: Trojan Horses

Back Orifice 2000

• Created by a group called “The Cult of the Dead Cow”: www.CultDeadCow.com and presented
as a remote administration tool.

• It is composed of 3 parts:
o Server Side Program (112 KB)
o Configuration tool (Automatic Installation)
o Client Side Tool (User Friendly)

• It provides more than 77 Functionalities. For example:

o Restart the Computer Remotely
o Lock the Computer Remotely
o Detect the Passwords Remotely
o Collect Information Remotely

Malicious Code: Viruses

What is a computer virus?

Computer viruses are software programs that are deliberately designed to interfere with computer
operation, record, corrupt, or delete data, or spread themselves to other computers and throughout the
Internet.

The term comes from the term virus in biology. A computer virus reproduces by making, possibly
modified, copies of itself in the computer's memory, storage, or over a network. This is similar to the
way a biological virus works.The copies may modified (or modify themselves, as occurs in a
metamorphic virus).

Universal Knowledge Solutions S.A.L.

- 125 -
It can only spread from one computer to another when its host is taken to the uninfected computer, for
instance by a user sending it over a network or carrying it on a removable medium.

It can spread to other computers by infecting files on a network file system or a file system that is
accessed by another computer. In fact, many personal computers are now connected to the Internet and
to local-area networks, facilitating their spread.

In fact, Some viruses are programmed to damage the computer by damaging programs, deleting files,
or reformatting the hard disk. Others are not designed to do any damage, but simply replicate
themselves and perhaps make their presence known by presenting text, video, or audio messages. Even
these benign viruses can create problems for the computer user. They typically take up computer
memory used by legitimate programs. As a result, they often cause erratic behavior and can result in
system crashes.

Malicious Code: Viruses

The Electronic Infection

Viruses are sometimes confused with computer worms which, can spread themselves to other
computers without needing to be transferred as part of a host. They can replicate and send themselves
automatically to other computers by controlling other software programs, such as an e-mail sharing
application.

In fact, when we listen to the news, we hear about many different forms of electronic infection. The
most common are:
• Viruses - A virus is a small piece of software that piggybacks on real programs. For example,
a virus might attach itself to a program such as a spreadsheet program. Each time the
spreadsheet program runs, the virus runs, too, and it has the chance to reproduce (by attaching
to other programs) or wreak havoc.
• E-mail viruses - e-mail virus moves around in e-mail messages, and usually replicates itself
by automatically mailing itself to dozens of people in the victim's e-mail address book.
• Trojan horses - A Trojan horse is simply a computer program. The program claims to do one
thing (it may claim to be a game) but instead does damage when you run it (it may erase your
hard disk). Trojan horses have no way to replicate automatically.
• Worms - A worm is a small piece of software that uses computer networks and security holes
to replicate itself. A copy of the worm scans the network for another machine that has a
specific security hole. It copies itself to the new machine using the security hole, and then
starts replicating from there, as well. We'll take a closer look at how a worm works in the next
section.

Today's viruses may also take advantage of network services such as the World Wide Web, e-mail, and
file sharing systems to spread, blurring the line between viruses and worms.

Computer viruses can spread very fast. For example, it is estimated that the Mydoom worm infected a
quarter-million computers in a single day in January 2004. Another example is the ILOVEYOU worm,

Universal Knowledge Solutions S.A.L.

- 126 -
which had a similar effect in 2000.

There are many viruses operating in the general Internet today, and new ones are discovered every day.

Malicious Code: Viruses

How Worms Work: Code Red

The most common version of Code Red is a variation, typically referred to as a mutated strain, of the
original Ida Code Red that replicated itself on July 19, 2001. According to the National Infrastructure
Protection Center:

The Ida Code Red Worm, which was first reported by eEye
Digital Security, is taking advantage of known vulnerabilities in
the Microsoft IIS Internet Server Application Program Interface
(ISAPI) service. Un-patched systems are susceptible to a "buffer
overflow" in the Idq.dll, which permits the attacker to run
embedded code on the affected system. This memory resident
worm, once active on a system, first attempts to spread itself by
creating a sequence of random IP addresses to infect
unprotected web servers. Each worm thread will then inspect the
infected computer's time clock. The NIPC has determined that
the trigger time for the DOS execution of the Ida Code Red
Worm is at 0:00 hours, GMT on July 20, 2001. This is 8:00 PM,
EST.

A worm called Code Red made huge headlines in 2001. Experts predicted that this worm could clog
the Internet so effectively that things would completely grind to a halt.

Worms normally move around and infect other machines through computer networks. Using a
network, a worm can expand from a single copy incredibly quickly. The Code Red worm replicated
itself over 250,000 times in approximately nine hours on July 19, 2001.

A worm usually exploits some sort of security hole in a piece of software or the operating system. For
example, the Slammer worm (which caused mayhem in January 2003) exploited a hole in Microsoft's
SQL server.

The Code Red worm slowed down Internet traffic when it began to replicate itself, but not nearly as
badly as predicted. Each copy of the worm scanned the Internet for Windows NT or Windows 2000
servers that do not have the Microsoft security patch installed. Each time it found an unsecured server,
the worm copied itself to that server.

The new copy then scanned for other servers to infect. Depending on the number of unsecured servers,
a worm could conceivably create hundreds of thousands of copies. The Code Red worm was designed
to do three things:
• Replicate itself for the first 20 days of each month.
• Replace Web pages on infected servers with a page that declares "Hacked by Chinese".
• Launch a concerted attack on the White House Web server in an attempt to overwhelm it

Universal Knowledge Solutions S.A.L.

- 127 -
 Malicious Code: Viruses
Signs of viruses: Are you infected?
When we open and run an infected program or attachment on our computer, we might not realize that
we’ve introduced a virus until we notice something isn't quite right.

Here are a few primary indicators that our computer might be infected:
• The computer runs more slowly than normal
• The computer stops responding or locks up often
• The computer crashes and restarts every few minutes
• The computer restarts on its own and then fails to run normally
• Applications on the computer don't work correctly
• Disks or disk drives are inaccessible
• We can't print correctly
• We see unusual error messages
• We see distorted menus and dialog boxes

Malicious Code: Viruses

Virus Structure

• Replicator
• Protector
• Trigger
• Payload

Malicious Code: Viruses

How to Protect Ourselves from Viruses
Computer viruses tend to grab our attention. On the one hand, viruses show us how vulnerable we are.
A properly engineered virus can have an amazing effect on the worldwide Internet. On the other hand,
they show how sophisticated and interconnected human beings have become.

• Avoid programs from unknown sources

• Disable floppy disk booting
• Make sure that Macro Virus Protection is enabled in all Microsoft applications,
• NEVER run macros in a document.
• Update the antivirus software, and perform a thorough scan of the computer.
• Download, install, and run the Malicious Software Removal Tool (for Microsoft Windows XP or
Windows 2000 users especially).

Universal Knowledge Solutions S.A.L.

- 128 -
 Malicious Code:
Mobile Code related to Web Applications

In the early days, when Web pages were just static HTML files, they did not contain executable code.

Now they often contain small programs, including Java applets, ActiveX controls, and JavaScripts.
Downloading and executing such mobile code is obviously a massive security risk, so various methods
have been devised to minimize it.

We will take a quick look at some of the issues raised by mobile code and some approaches to dealing
with it. We will focus on 3 mobile code types:

• Java Applet

• ActiveX

• JavaScript

Malicious Code: Mobile Code

Java Applet

Java applets are small Java programs compiled to a stack-oriented machine language called JVM
(Java Virtual Machine).

They can be placed on a Web page for downloading along with the page. After the page is loaded, the
applets are inserted into a JVM interpreter inside the browser, as illustrated in the slide.

The advantage of running interpreted code over compiled code is that every instruction is examined by
the interpreter before being executed. This gives the interpreter the opportunity to check whether the
instruction’s address is valid.

In addition, system calls are also caught and interpreted. How these calls are handled is a matter of the
security policy. For example, if an applet is trusted (e.g., it came from the local disk), its system calls
could be carried out without question.

Universal Knowledge Solutions S.A.L.

- 129 -
However, if an applet is not trusted (e.g., it came in over the Internet), it could be encapsulated in what
is called a sandbox to restrict its behaviour and trap its at-tempts to use system resources.

When an applet tries to use a system resource, its call is passed to a security monitor for approval. The
monitor examines the call in light of the local security policy and then makes a decision to allow or
reject it. In this way, it is possible to give applets access to some resources but not all. Unfortunately,
the reality is that the security model works badly and that bugs in it crop up all the time.

Malicious Code: Mobile Code

ActiveX
ActiveX controls are Pentium binary programs that can be embedded in Web pages. When one of them
is encountered, a check is made to see if it should be executed, and it if passes the test, it is executed.

It is not interpreted or sandboxed in any way, so it has as much power as any other user program and
can potentially do great harm. Thus, all the security is in the decision whether to run the ActiveX
control.

The method that Microsoft chose for making this decision is based on the idea of code signing. The
Microsoft system for verifying ActiveX controls is called Authenticode.
• Each ActiveX control is accompanied by a digital signature—a hash of the code that is signed by
its creator using public key cryptography.
• When an ActiveX control shows up, the browser first verifies the signature to make sure it has not
been tampered with in transit.
o If the signature is correct, the browser then checks its internal tables to see if the program’s
creator is trusted or there is a chain of trust back to a trusted creator.
o If the creator is trusted, the program is executed; otherwise, it is not.

Malicious Code: Mobile Code

JavaScript

JavaScript does not have any formal security model, but it does have a long history of leaky implementations.

Each vendor handles security in a different way. For example, Netscape Navigator version 2 used something
akin to the Java model, but by version 4 that had been abandoned for a code signing model.

The fundamental problem is that letting foreign code run on your machine is asking for trouble.

The tension here is that mobile code allows flashy graphics and fast interaction, and many Web site designers
think that this is much more important than security, especially when it is somebody else’s machine at risk.

Universal Knowledge Solutions S.A.L.

- 130 -
 Network Attacks
Introduction
A typical attack is not a simple, one-step procedure. It's rare that an attacker can get online or dial up a
remote computer and use only one method to gain full access. It's more likely that the attacker will
need several techniques in combination to bypass the many layers of protection standing between the
attacker and root administrative access.

Therefore, as a security consultant or network administrator, we should be well-versed in these

techniques in order to thwart them. Thus, we will introduce the main types of network attacks. Later
parts discuss some of the more popular defenses and measures.

The stereotypical image conjured by most people when they hear the term hacker is that of a pallid,
atrophied recluse cloistered in a dank bedroom, whose spotted complexion is revealed only by the
unearthly glare of a Linux box used for remote exploit scanning in Perl.

However, while computer skill is central to a hacker's profession, there are many additional facets that
he (or she) must master.

A real hacker must also rely on physical and interpersonal skills such as social engineering and other
"wet work" that involves human interaction. However, because most people have a false stereotype of
hackers, they fail to realize that the person they're chatting with in the office or talking to on the phone
may in fact be a hacker in disguise. In fact, this common misunderstanding is one of the hacker's
greatest assets.

Network Attacks
Collect of Information

• Foot Printing
• Scanning: Ping Sweeps, Port Sweeps
• Enumeration

Network Attacks
Collect of Information: Foot Printing

• Functional Information:
o Names of employees in order to deduce user names and passwords.
o Email addresses.
o Technical levels of the employees.
o Business type and information transmitted over the network.
o … etc.

Universal Knowledge Solutions S.A.L.

- 131 -
• Financial Information

Network Attacks
Collect of Information: Scanning

ICMP Echo Request (type 8)

ICMP Echo Reply (type 0)

Scanning Goal:

• Detect TCP/UDP Services.

• Detect architecture type (Sparc, Alpha, X86).
• Detect internet connections.

IP Scanning

• Is performed using:
o ping tool.
o OR ICMP-echo request and ICMP-echo reply packet.

Port Scanning:

• Based on The Three Way Handshake procedure

Client Æ SYN
Server Æ SYN-ACK
Client Æ ACK

• The Procedure:
Repeat for all Ports
ClientÆ SYN
If (ServerÆ SYN-ACK) then Port
Else
if (ServerÆ RST-ACK) then No Port
ClientÆ ACK

Tools:

• UNIX
o fping, gping: ftp://tamu.edu/pub/Unix/src

Universal Knowledge Solutions S.A.L.

- 132 -
 o Nmap: http://www.InSecure.Org

• Windows
o Pinger : http://207.98.195.250/Software
o INetTools: http://www.wildpackets.com/Products/inettools

Network Attacks
Collect of Information: Enumeration

• Collecting Information about:

o User Accounts
o Routers
o Shared Folders
o Servers Names

Network Attacks
Sniffing
A sniffer is a program and/or device that monitors all information passing through a computer network.

It "sniffs" the data passing through the network off the wire and determines where the data is going,
where it originated, and what it is.

In addition to these basic functions, sniffers can have extra features that allow them to filter one type of
data, capture passwords, and more.

There are even some sniffers—for example, the FBI's controversial mass-monitoring tool formerly
known as Carnivore—that can rebuild files sent across a network, such as an email or web page.

A sniffer is one of the most important information-gathering tools in a hacker's arsenal.

The sniffer gives the hacker a complete picture of the data sent and received by the computer or
network that the sniffer is monitoring. This data includes but is not limited to all email messages,
passwords, usernames, and documents.

With this information, a hacker can form a complete picture of the data traveling on a network, as well
as capture important tidbits of data that can help him gain complete control over the network.

Universal Knowledge Solutions S.A.L.

- 133 -
 Network Attacks
Sniffing: How Does a Sniffer Work?
A network card normally accepts only information that has been sent to its specific network address.

This network address is properly known as the Media Access Control (MAC) address. The MAC
address is also called the physical address.

For a computer to have the ability to sniff a network, it must have a network card running in
promiscuous mode, which means that it can receive all the traffic that's sent across the network,
regardless of whether the data is destined for the machine running the sniffer.

An exception to this rule is monitor mode, which stops all interaction. This type of network card status
applies only to wireless network interface cards.

Due to the unique properties of a wireless network, any data traveling through the airwaves is open to
any device that's configured to listen. While a card in promiscuous mode will work in wireless
environments, there's no need for it to be part of the network. Instead, a wireless NIC can simply enter
a listening status in which it's restricted from sending data out to the network.

The destination address is the MAC address of the computer; there's a unique MAC address for every
network card in the world. Although you can change the address, the MAC address ensures that the
data is delivered to the right computer. If a computer's address doesn't match the address in the packet,
the data is normally ignored.

Network cards have the option to run in promiscuous mode for the sake of troubleshooting. Normally,
a computer doesn't need to send information to other computers on the network. However, in the event
that something goes wrong with the network wiring or hardware, it's important for a network
technician to look inside the data traveling on the network to see what's causing the problem. For
example, one common indication of a bad network card is when computers start to have a difficult time
transferring data. This could be the result of an information overload on the network wires.

The flood of data would jam the network and would stop any productive communication. Once a
technician plugs in a computer with the ability to examine the network, he can quickly pinpoint the
origin of the corrupt data and thus the location of the broken network card. He can then simply replace
the bad card and everything is back to normal.

Although sniffers most commonly show up within closed business networks, they can also be used
throughout the Internet. As mentioned previously, the FBI has a program that captures all the
information both coming from and going to computers online. This tool, previously known as
Carnivore, simply has to be plugged in and turned on. (The FBI backed away from the aggressive
name Carnivore because of negative public reaction.) Although it's purported to filter out any
information that's not intended for the target, this tool actually captures everything traveling through
wires to which it's connected and then filters it according to the rules set up in the program. Thus,
Carnivore can potentially capture all of the passwords, emails, and chats passing through its
connection.

Universal Knowledge Solutions S.A.L.

- 134 -
 Network Attacks
IP Spoofing
Spoofing is the term hackers use to describe the act of faking the source address of information sent to
a computer. This is a broad definition, but there are many subtle variations of this attack. However, the
purpose of each variation is generally the same: to disguise the location from which the attack
originates.

Session hijacking takes the act of spoofing one step further. It involves faking someone's identity in
order to take over a connection that's already established. Because spoofing is required in order to
successfully hijack a connection.

The most common spoofing attack is called an IP spoof. This type of attack takes advantage of the
Internet Protocol (IP), which is part of the Transmission Control Protocol/Internet Protocol (TCP/IP)
suite. In this case, the return address of a packet sent to a computer is faked. This trick protects the
identity of the attacker.

Network Attacks
Denial of Service: ICMP-echo Flooding
ECHO REPLY
ICMP ECHO

C
ICMP ECHO
Internet

ECHO REPLY

Host A try to attack Host B & Host C

Universal Knowledge Solutions S.A.L.

- 135 -
 A::Attack(B,C)
{
P1, P2: ICMP-packet;
Repeat
{
P1:=A.Create-ICMP-echo-packet( );
P1.SourceAddress:=C.IPAddress
P1.DestinationAddress=B.IPAddress
A.Send(P1);

P2:=B.Create-ICMP-echo-reply-packet( );
P2.SourceAddress=B.IPAddress;
P2.DestinationAddress:=P1.SourceAddress;
B.Send(P2);

// Consequently, the ICMP-reply will be sent to C

}
}

Hackers can wreak havoc without ever penetrating a system. For example, a hacker can effectively
shut down a computer by flooding this computer with obnoxious signals or malicious code.

This technique is known as a denial-of-service (DoS) attack. In addition, there are numerous other
kinds of DoS attacks that can be launched and that may deserve coverage—chief among these being
the Distributed DoS (DDoS):

Hackers execute a denial-of-service attack using one of two methods:

• The flooding method drowns the target computer or hardware device with so much traffic that
it becomes overwhelmed and cannot process it all, let alone legitimate traffic. A common type
of flooding is SYN flooding.

• The alternative method is to send a well-crafted command or piece of erroneous data that
crashes the target computer device.

Universal Knowledge Solutions S.A.L.

- 136 -
 Network Attacks
Smurf Attack

ECHO REPLY
1*ICMP ECHO

C
A
1*ICMP ECHO
Internet

N*ECHO REPLY
B

One variation of the flooding DoS is the smurf attack.

Imagine a company with 50 employees available to respond to customer questions by email. Each
employee has an auto-responder that automatically sends a courtesy reply when a question is received.
What would happen if an angry customer mailed 100 email messages, copied to each of the 50
employees, using a fake return email address? The 100 incoming messages would suddenly become
5,000 outgoing messages—all going to one mailbox. Whoever owned the fake return address would be
overwhelmed with all that mail! And he would have to search through all of it to make sure that he
didn't miss an important message from his boss or a friend.

In a smurf attack, the attacker sends a request signal into a network of computers, each of which reply
to a faked return address. Special programs and other techniques can amplify this attack until a flood of
information is headed toward one unfortunate computer.

The rules of TCP/IP specify that a computer generally ignores all packets that are not expressly
addressed to it. One exception is if a computer has a network card running in promiscuous mode.
Another exception occurs when a system uses broadcast packets.

Because of the way IP addresses are set up within a network, there's always one address to which every
computer will answer. This broadcast address is used to update name lists and other necessary items
that computers need to keep the network up and running. Although the broadcast address is necessary
in some cases, it can lead to what's known as a broadcast storm.

A broadcast storm is like an echo that never dies. More specifically, it's like an echo that crescendos
until you can't hear anything over the pure noise. If a computer sends a request to a network using the
broadcast address and the return address of the broadcast address, every computer will respond to
every other computer's response; this continues in a snowball effect until the network is so full of
echoes that nothing else can get through.

These types of attacks not only quickly and effectively shut down a server, but keep the hacker
invisible. The original packets sent by the hacker are untraceable. In the smurf attack, the hacker
doesn't directly attack the target, but instead uses the side-effect of sending broadcast signals into a
network to do the job indirectly. Therefore, the attack appears to have come from another computer or

Universal Knowledge Solutions S.A.L.

- 137 -
network.

Network Attacks
SYN Flooding

A SYN (short for synchronize) flooding attack ties up the target computer's resources by making it
respond to a flood of connection requests that are never completed.

Imagine that you're a secretary whose job is to answer and redirect phone calls. What if 200 people
called you at the same time, and then simply kept the line open while you sat there saying "Hello?
Hello?" You would be so busy picking up dead lines that you would never get any work done.
Eventually, you might suffer a mental breakdown and quit your job. This is the same technique that
hackers use when they employ a denial-of-service attack.

A SYN DoS attack takes advantage of the required TCP/IP handshake that takes place when two
computers set up a communications session. The client computer sends a SYN packet to the server
computer to start the communication. When the server receives this data, it processes the return
address and sends back the SYN ACK (acknowledge) packet. The server then waits for the client to
respond with a final ACK packet, which completes the connection initiation.

A server has a limited number of resources designated for client connections. When the server receives
the initial SYN packet from a client, the server allocates some of these resources. This limitation is
meant to cap the number of simultaneous client connections. If too many clients connect at once, the
server will become overloaded and crash under the excess processing load. (Note that both server
defences and attacks have continued to evolve since the discovery of this weakness.)

The weakness in this system occurs when the hacker inserts a fake return address in the initial SYN
packet. Thus, when the server sends back the SYN ACK to the fake client, it never receives the final
ACK. This means that for every fake SYN packet, further resources are tied up until the server refuses
any more connections.

A successful attack requires myriad fake packets, but if a hacker has several slave computers sending
packets he can overload a server quickly. A well-known example of this type of attack occurred in
February 2000. Several high-profile web sites were brought to their knees by a flood of signals coming
from hundreds of different computers simultaneously. The web sites would have had no problem
handling an attack from one source; however, through the use of remote-control programs, one or more
hackers launched a concerted attack using hundreds of computers, thus quickly overloading their
targets.

To perform a DoS attack, the hacker must first determine the IP address of the target. Using this IP
address, the hacker connects to it using a client computer. To amplify the force of the attack, hackers
often set up several client computers programmed to attack the target at the same time. This is usually
accomplished by doing some preliminary hacking in order to gain ownership of several computers with
high bandwidth connections. The most popular sources of these "slave" or "zombie" computers are
university systems and broadband customers. Once the hacker has his slave computers set up, he
launches the attack from a central point (the master).

Universal Knowledge Solutions S.A.L.

- 138 -
 Network Attacks
Hijacking

To get the information exchanged between two sides, the Hacker start Sniffing the Client

1. When, Client Æ Server: SYN

a. Hacker Æ Server: false RST-SYN
b. Hacker Æ Client: false ACK

2. Thus, Server Æ Client: new SYN-ACK (responding to 1.a)

c. Hacker Æ Server: ACK
d. Server Æ Hacker: ACK (Established with Hacker)

3. Client Æ Hacker: ACK (Established with Hacker) (responding to 1.b)

Ping of Death
A TCP/IP packet with a theoretical length greater than 65536-bytes has been sent to the machine.

This attack was popular around July of 1997, but since then most systems have been patched to prevent
this bug.

TCP/IP supports a feature called "fragmentation", where a single IP-packet can be broken down into
smaller segments. This is needed because the typical Internet connection (dial-up, Ethernet, cable-
modem, etc.) only supports packets of around a couple thousand bytes, but IP supports packets up to
64-kbytes. Thus, when sending a single packet that is too large for a link, it is broken up into smaller
packet fragments.

A quirk of IP is that while a single packet cannot exceed 65536-bytes, the fragments themselves can
add up to more than that. The "Ping of Death" technique does just that. Since this is a condition
thought impossible, operating systems crash when they receive this data.

Ping of death can actually be run from older versions of Windows. At a command line, simply type:
ping -l 65550 VICTIM A further bug in Windows is that it not only crashes when it receives the
invalid data, but it can accidentally also generate it. Newer versions of Windows prevent you from
sending these packets.

Universal Knowledge Solutions S.A.L.

- 139 -
 DNS Spoofing

When visiting websites, such as, http://www.example.com, the system must first resolve the name into
an IP address using DNS. This is similar to how you must lookup someone name in the phone book in
order to dial their telephone number.

There exists a hacker technique whereby they can sometimes force a duplicate reply to the DNS
lookup. Using the phone book analogy, it is similar to calling 411/information for somebody's number
and getting back two replies. Imagine a hacker breaking into the phone system such that the first
number you heard was to the hacker. The hacker who broke into the telephone system might use this
technique to redirect people buying with credit cards to his own phone number, and then pretend to be
the real vendor, and then steal the credit card numbers.

In much the same way, hackers use this DNS spoof in order to redirect people to their own website.

However, we are finding that home users are seeing such behaviour from ISPs. Some ISPs attempt to
re-direct users through their own caching servers. Therefore, this "spoof" symptom doesn't actually
indicate a hostile attack.

In fact, DNS spoofing works by forcing a DNS "client" to generate a request to a "server", then by
spoofing the response from the "server".

One way this works is through the scheme that most DNS servers support "recursive" queries. You can
therefore send a request to any DNS server asking for it to resolve a name-to-address. That DNS server
will then send the proper queries to the proper servers in order to discover the appropriate information.
However, an intruder can predict what request that victim server will send out to satisfy the request,
and can spoof the response, which will arrive before the real response arrives.

This is useful because DNS servers will "cache" information for a certain amount of time. If an
intruder can successfully spoof a response for "www.microsoft.com", any legitimate users of that DNS
server will then be redirected to the intruder's site.

Social Engineering
Social engineering, or interpersonal manipulation, is not unique to hacking. In fact, many people use
this type of trickery every day, both criminally and professionally.

We are probably guilty of using social engineering techniques to get something we wanted. Whether
it's haggling for a lower price on a lawnmower at a garage sale.

One example of social engineering that information technology managers face on a weekly basis is
solicitation from vendors. This inimical form of sales takes the form of thinly disguised telemarketing.
Straying far from ethical standards of sales technique, such vendors attempt to trick us into giving
them information so they can put our company's name on a mailing list.

Here's one such attempt:

Universal Knowledge Solutions S.A.L.

- 140 -
"Hi, this is the copier repair company. We need to get the model of your copier for our service
records. Can you get that for us?"

This request sounds innocent enough, and many people fall for this tactic. The attacker is simply trying
to trick us into providing "sensitive" information—details that he or she really has no right to know.

However, we might try to reverse the social engineering ourselves: Play along, and even tempt the
caller with statements indicating that you're dissatisfied with our current copier, and that we wish we
could purchase another brand. Once scammers sense money, they often foolishly make their true
identity known.

Like the scam artist's trick, a common hacker method is to pretend to be conducting a survey—asking
all kinds of questions about the network operating systems, intrusion-detection systems, firewalls, and
more, in the guise of a researcher. A really malicious hacker might even offer a cash reward to pay for
the network administrator's time in answering the questions. The most popular social engineering
method involves pretending to be a user who has trouble getting the VPN to work, has lost the
password to the mail server, etc. Unfortunately, most people fall for the bait and reveal sensitive
network information.

Social Spying
Social spying is the process of using observation to acquire information. While social engineering can
provide an attacker with crucial information, small businesses are more resistant to social engineering
because people in small companies all know each other. For example, if one of the IT staff received a
call from an attacker pretending to be a distressed CEO, she would probably recognize the voice as not
belonging to the real CEO. In this case, social spying becomes more important.

To illustrate one of the non-technical ways in which social spying can be used, consider how many
people handle their ATM cards.
• Do we hide your PIN when we get cash at the ATM?
• Most people don't; they whip out the card and punch the numbers without noticing who might be
watching.
• If someone else memorizes the PIN, he'll have all the information needed to access the funds in the
account—provided that he can get his hands on the ATM card.

Snooping on people as they actively type their user information isn't the only technique. Most offices
have at least a few people who post passwords on or near their computer monitors. This type of blatant
disregard for security is every network administrator's worst nightmare.

Regardless of repeated memos, personal visits, and warnings, some people seem to find an excuse to
post network passwords in plain view. Even if some people are at least security-conscious enough to
hide the Post-it note with the password in a discreet place, it still takes only a few seconds to lift a
keyboard or pull open a desk drawer.

Universal Knowledge Solutions S.A.L.

- 141 -
 Part 4
Security Measures (1)

Keywords:
IDS, Firewall antivirus, Leased Line, Router, Remote Access server.

Summary:
In this section, we will present the main security measures related to network, services and application
security.

Objectives:
Upon completion of this part, the student will be able to understand:
• Networks related security measures.
• OS and DB and services related security measures

Universal Knowledge Solutions S.A.L.

- 142 -
 Classification of Security Measures

• Technical security measures

o Network Related security measures
o OS and DB related security measures
o Application security measures

• Operational security measures

o Security training
o Incident response

Types of Security Measures

• Techniques of prevention

• Techniques of detection

• Techniques of recovery

Universal Knowledge Solutions S.A.L.

- 143 -
Network Related Security Measures

Network Related Security Measures:

Physical Security Measures

Universal Knowledge Solutions S.A.L.

- 144 -
 Network Related Security Measures:
Physical Security Measures - Leased Line

Network Related Security Measures:

Physical Security Measures – Call Back

Universal Knowledge Solutions S.A.L.

- 145 -
 Network Related Security Measures:
Physical Security Measures – Use of Switches

Network Related Security Measures:

Logical Security Measures – Packet Filtering

Packet Headers Filtering by Screened Router:

• Filtering Addresses & Ports

o Pessimist Filtering
o Optimist Filtering

• It’s the Simplest Method

Email

Local Network The Internet

Connected to the FTP
Internet

Universal Knowledge Solutions S.A.L.

- 146 -
 Content Filtering - Firewalls

Example:

Voice Over

A firewall is simply a program or hardware device that filters the information coming through the
Internet connection into a private network or computer system. If an incoming packet of information is
flagged by the filters, it is not allowed through.
Let's say that we work at a company with 500 employees. The company will therefore have hundreds
of computers that all have network cards connecting them together. In addition, the company will have
one or more connections to the Internet through something like T1 or T3 lines.
Without a firewall in place, all of those hundreds of computers are directly accessible to anyone on the

Universal Knowledge Solutions S.A.L.

- 147 -
Internet. A person who knows what he or she is doing can probe those computers, try to make FTP
connections to them, try to make telnet connections to them and so on. If one employee makes a
mistake and leaves a security hole, hackers can get to the machine and exploit the hole.
With a firewall in place, the landscape is much different. A company will place a firewall at every
connection to the Internet (for example, at every T1 line coming into the company). The firewall can
implement security rules. For example, one of the security rules inside the company might be:
Out of the 500 computers inside this company, only one of them is permitted to receive public FTP
traffic. Allow FTP connections only to that one computer and prevent them on all others.
A company can set up rules like this for FTP servers, Web servers, Telnet servers and so on. In
addition, the company can control how employees connect to Web sites, whether files are allowed to
leave the company over the network and so on. A firewall gives a company tremendous control over
how people use the network.
Firewalls use one or more of three methods to control traffic flowing in and out of the network:
• Packet filtering - Packets (small chunks of data) are analyzed against a set of filters. Packets
that make it through the filters are sent to the requesting system and all others are discarded.

• Proxy service - Information from the Internet is retrieved by the firewall and then sent to the
requesting system and vice versa.

• Stateful inspection - A newer method that doesn't examine the contents of each packet but
instead compares certain key parts of the packet to a database of trusted information.
Information travelling from inside the firewall to the outside is monitored for specific defining
characteristics, then incoming information is compared to these characteristics. If the
comparison yields a reasonable match, the information is allowed through. Otherwise it is
discarded.

Firewall Actions

There are many creative ways that unscrupulous people use to access or abuse unprotected computers:

Remote login - When someone is able to connect to your computer and control it in some form.
This can range from being able to view or access your files to actually running programs on your
computer.

Application backdoors - Some programs have special features that allow for remote access. Others
contain bugs that provide a backdoor or hidden access that provides some level of control of the
program.

SMTP session hijacking - SMTP is the most common method of sending e-mail over the Internet.
By gaining access to a list of e-mail addresses, a person can send unsolicited junk e-mail (spam) to
thousands of users. This is done quite often by redirecting the e-mail through the SMTP server of an
unsuspecting host, making the actual sender of the spam difficult to trace.

Universal Knowledge Solutions S.A.L.

- 148 -
Operating system bugs - Like applications, some operating systems have backdoors. Others
provide remote access with insufficient security controls or have bugs that an experienced hacker
can take advantage of.

Denial of service - You have probably heard this phrase used in news reports on the attacks on
major Web sites. This type of attack is nearly impossible to counter. What happens is that the
hacker sends a request to the server to connect to it. When the server responds with an
acknowledgement and tries to establish a session, it cannot find the system that made the request.
By inundating a server with these unanswerable session requests, a hacker causes the server to slow
to a crawl or eventually crash.

E-mail bombs - An e-mail bomb is usually a personal attack. Someone sends you the same e-mail
hundreds or thousands of times until your e-mail system cannot accept any more messages.

Macros - To simplify complicated procedures, many applications allow you to create a script of
commands that the application can run. This script is known as a macro. Hackers have taken
advantage of this to create their own macros that, depending on the application, can destroy your
data or crash your computer.

Viruses - Probably the most well-known threat is computer viruses. A virus is a small program that
can copy itself to other computers. This way it can spread quickly from one system to the next.
Viruses range from harmless messages to erasing all of your data.

Spam - Typically harmless but always annoying, spam is the electronic equivalent of junk mail.
Spam can be dangerous though. Quite often it contains links to Web sites. Be careful of clicking on
these because you may accidentally accept a cookie that provides a backdoor to your computer.

Redirect bombs - Hackers can use ICMP to change (redirect) the path information takes by
sending it to a different router. This is one of the ways that a denial of service attack is set up.

Source routing - In most cases, the path a packet travels over the Internet (or any other network) is
determined by the routers along that path. But the source providing the packet can arbitrarily
specify the route that the packet should travel. Hackers sometimes take advantage of this to make
information appear to come from a trusted source or even from inside the network! Most firewall
products disable source routing by default.

Some of the items in the list above are hard, if not impossible, to filter using a firewall. While some
firewalls offer virus protection, it is worth the investment to install anti-virus software on each
computer. And, even though it is annoying, some spam is going to get through your firewall as long as
you accept e-mail.

Universal Knowledge Solutions S.A.L.

- 149 -
 Firewall Placement

Screened Host

Internal Fire- Router Internet

wall
Network

Screened Subnet

Internal Router Fire- Router Internet

Wall
Network

DMZ (De-Militarized Zone)

Internal Router
Fire- Router Internet
Wall
Network
web, ftp, email

Firewall Products

• Check Point: www.checkpoint.com:

o NT & Sparc Solaris

• Sun Screen, Trusted Solaris: www.sun.com/Security:

o Sparc Solaris & Intel

• Raptor: www.Raptor.com

• IBM: Internet Connection Secured Network Gateway WWW.IBM.COM

• Pix Firewall: www.cisco.com

Universal Knowledge Solutions S.A.L.

- 150 -
 Intrusion Detection Systems (IDS)

An intrusion detection system (IDS) generally detects unwanted manipulations to computer systems,
mainly through the Internet. The manipulations may take the form of attacks by skilled malicious
hackers, or script kiddies using automated tools.

An intrusion detection system is used to detect all types of malicious network traffic and computer
usage that can't be detected by a conventional firewall. This includes network attacks against
vulnerable services, data driven attacks on applications, host based attacks such as privilege escalation,
unauthorized logins and access to sensitive files, and malware (viruses, trojan horses, and worms).

An IDS is composed of several components:

• Sensors which generate security events,
• Console to monitor events and alerts and control the sensors,
• Central Engine that records events logged by the sensors in a database and uses a system of rules
to generate alerts from security events received.

There are several ways to categorize an IDS depending on the type and location of the sensors and the
methodology used by the engine to generate alerts.

In many simple IDS implementations all three components are combined in a single device or
appliance.

Intrusion Detection Systems (IDS)

IDS Categories

There are several ways to categorize an IDS:

• Misuse Detection vs. Anomaly Detection: in misuse detection, the IDS analyzes the information
it gathers and compares it to large databases of attack signatures. Essentially, the IDS looks for a
specific attack that has already been documented. Like a virus detection system, misuse detection
software is only as good as the database of attack signatures that it uses to compare packets against.
In anomaly detection, the system administrator defines the baseline, or normal, state of the
network’s traffic load, breakdown, protocol, and typical packet size. The anomaly detector
monitors network segments to compare their state to the normal baseline and look for anomalies.

• Network-based vs. Host-based Systems: in a network-based system, or NIDS, the individual

packets flowing through a network are analyzed. The NIDS can detect malicious packets that are
designed to be overlooked by a firewall’s simplistic filtering rules. In a host-based system, the IDS
examines at the activity on each individual computer or host.

• Passive System vs. Reactive System: in a passive system, the IDS detects a potential security
breach, logs the information and signals an alert. In a reactive system, the IDS responds to the
suspicious activity by logging off a user or by reprogramming the firewall to block network traffic
from the suspected malicious source.

Universal Knowledge Solutions S.A.L.

- 151 -
 Intrusion Detection Systems (IDS)
IDS Categories

Though they both relate to network security, an IDS differs from a firewall in that:
• A firewall looks out for intrusions in order to stop them from happening.
• The firewall limits the access between networks in order to prevent intrusion and does not signal an
attack from inside the network.
• An IDS evaluates a suspected intrusion once it has taken place and signals an alarm.
• An IDS also watches for attacks that originate from within a system.

Intrusion Detection Systems (IDS)

Passive & Reactive IDS

Passive IDS
A passive IDS simply detects and alerts. When suspicious or malicious traffic is detected an alert is
generated and sent to the administrator or user and it is up to them to take action to block the activity
or respond in some way.

Reactive IDS

Reactive IDS will not only detect suspicious or malicious traffic and alert the administrator, but will
take pre-defined proactive actions to respond to the threat. Typically this means blocking any further
network traffic from the source IP address or user.

One of the most well known and widely used intrusion detection systems is the open source, freely
available Snort. It is available for a number of platforms and operating systems including both Linux
and Windows. Snort has a large and loyal following and there are many resources available on the
Internet where you can acquire signatures to implement to detect the latest threats.

Combining Firewall and IDS

There is also technology called IPS – Intrusion Prevention System. An IPS is essentially a firewall
which combines network-level and application-level filtering with a reactive IDS to proactively protect
the network.

It seems that as time goes on firewalls, IDS and IPS take on more attributes from each other and blur
the line even more.
Essentially, the firewall is our first line of perimeter defence. Best practices recommend that the
firewall be explicitly configured to DENY all incoming traffic and then we open up holes where

Universal Knowledge Solutions S.A.L.

- 152 -
necessary.

We may need to open up port 80 to host web sites or port 21 to host an FTP file server. Each of these
holes may be necessary from one standpoint, but they also represent possible vectors for malicious
traffic to enter the network rather than being blocked by the firewall.

That is where the IDS would come in. Whether we implement a NIDS across the entire network or a
HIDS on a specific device, the IDS will monitor the inbound and outbound traffic and identify
suspicious or malicious traffic which may have somehow bypassed the firewall or it could possibly be
originating from inside the network as well.

An IDS can be a great tool for proactively monitoring and protecting the network from malicious
activity, however they are also prone to false alarms.

With just about any IDS solution we implement we will need to “tune it” once it is first installed. We
need the IDS to be properly configured to recognize what is normal traffic on your network vs. what
might be malicious traffic and we, or the administrators responsible for responding to IDS alerts, need
to understand what the alerts mean and how to effectively respond.

Using Antivirus

Universal Knowledge Solutions S.A.L.

- 153 -
 Virus Prevention

• Username & Passwords must stay individuals;

• Files & Folders must be “Backuped”;
• A firewall must be used;
• Internet Explorer must be configured;
• Anti-Virus Use;
• Hard Disk Verification;
• Floppy must be tested before any use;
• Macros must be “Desactivated”;
• Use the Virus Check functionality of the BIOS;
• Software and Hardware Installation must stay as administrator Privileges.
• A team of Information security should supervise the System

Standard Conformity
Example of Windows 2000 C2-Conformity (Orange Book Standard)

• Using BIOS Password.

• Using NTFS Disks.
• Using One Operating System/Computer.
• Password must be well chosen.
• Registry Backup.
• Installing Pack Service (Hot Fixes) periodically.
• Using TCP/IP only for networking.
• Using Drivers with Microsoft Signature only.
• Using DNS Servers.
• Configuring permissions using ACL (Access Control List) and EFS (Encryption File System).
• Sharing and Installation must be Administrator Privileges only.
• Registry must be protected by Permissions.
• Guest Account must be locked or deleted.
• Configuring Account Policy.
• Configuring Local Policies & User Right Assignment.
• Configuring Audit Policy.

Universal Knowledge Solutions S.A.L.

- 154 -
 Cryptography and Secure Communication
Does increased security provide comfort to paranoid people? Or does security provide some very basic
protections that we are naive to believe that we don't need?

During this time when the Internet provides essential communication between tens of millions of
people and is being increasingly used as a tool for commerce, security becomes a tremendously
important issue to deal with.

There are many aspects to security and many applications, ranging from secure commerce and
payments to private communications and protecting passwords.

One essential aspect for secure communications is that of cryptography, which will be the focus of the
next section.

But it is important to note that while cryptography is necessary for secure communications, it is not by
itself sufficient.

Universal Knowledge Solutions S.A.L.

- 155 -
 Part 5
Security Measures (2): Cryptography Basis
Keywords:
Cipher, Secret Key, Public Key, Block Cipher, Stream Cipher, Symmetric key, Asymmetric Key, Hash
Function, RSA, Deffie-Hellman, MD5, SHA-1, Kerberos, PGP, Certificate, Certificate Authority, SSL.

Summary:
There are many aspects to security and many applications, ranging from secure commerce and
payments to private communications and protecting passwords. One essential aspect for secure
communications is that of cryptography. But it is important to note that while cryptography is
necessary for secure communications, it is not by itself sufficient.

Objectives:
Upon completion of this part, the student will be able to understand:
• Types of Cryptography.
• Secret Key Cryptography.
• Public Key Cryptography.
• Hash Functions

Universal Knowledge Solutions S.A.L.

- 156 -
 The Purpose of Cryptography
Cryptography is the science of writing in secret code and is an ancient art; the first documented use of
cryptography in writing dates back to circa 1900 B.C. when an Egyptian scribe used non-standard
hieroglyphs in an inscription.

Some experts argue that cryptography appeared spontaneously sometime after writing was invented,
with applications ranging from diplomatic missives to war-time battle plans.

It is no surprise, then, that new forms of cryptography came soon after the widespread development of
computer communications. In data and telecommunications, cryptography is necessary when
communicating over any untrusted medium, which includes just about any network, particularly the
Internet.

The use of Cryptography

Within the context of any application-to-application communication, there are some specific security
requirements, including:
• Authentication: The process of proving one's identity. (The primary forms of host-to-host
authentication on the Internet today are name-based or address-based, both of which are
notoriously weak.)
• Privacy/confidentiality: Ensuring that no one can read the message except the intended receiver.
• Integrity: Assuring the receiver that the received message has not been altered in any way from the
original.
• Non-repudiation: A mechanism to prove that the sender really sent this message.

Cryptography, not only protects data from theft or alteration, but can also be used for user
authentication, for confirming data integrity, and for proving sender or receiver identity.

Cryptography Schemes
There are, in general, three types of cryptographic schemes typically used to accomplish these goals:

• Secret key (or symmetric) cryptography,

• Public-key (or asymmetric) cryptography,
• Hash functions,

In all cases, the initial unencrypted data is referred to as plaintext. It is encrypted into ciphertext, which
will in turn (usually) be decrypted into usable plaintext.

Universal Knowledge Solutions S.A.L.

- 157 -
 Types of Cryptographic Algorithms

There are several ways of classifying cryptographic algorithms.

We will categorize them regarding to the number of keys that are employed for encryption and
decryption, and further defined by their application and use.

The three types of algorithms that will be discussed are:

• Secret Key Cryptography (SKC): Uses a single key for both encryption and decryption.
• Public Key Cryptography (PKC): Uses one key for encryption and another for decryption.
• Hash Functions: Uses a mathematical transformation to irreversibly "encrypt" information.

Secret Key Cryptography

With secret key cryptography, a single key is used for both encryption and decryption.
• The sender uses the key (or some set of rules) to encrypt the plaintext and sends the ciphertext to
the receiver.
• The receiver applies the same key (or ruleset) to decrypt the message and recover the plaintext.

Because a single key is used for both functions, secret key cryptography is also called symmetric
encryption.

Universal Knowledge Solutions S.A.L.

- 158 -
With this form of cryptography, it is obvious that the key must be known to both the sender and the
receiver; that, in fact, is the secret.

The biggest difficulty with this approach, of course, is the distribution of the key.

Secret Key Cryptography:

Stream Cipher and Block Cipher
Secret key cryptography schemes are generally categorized as being either stream ciphers or block
ciphers.
• Stream ciphers operate on a single bit (byte or computer word) at a time and implement some form
of feedback mechanism so that the key is constantly changing.
• Block cipher is so-called because the scheme encrypts one block of data at a time using the same
key on each block.

In general, the same plaintext block will always encrypt to the same ciphertext when using the same
key in a block cipher whereas the same plaintext will encrypt to different ciphertext in a stream cipher.

Secret Key Cryptography:

Stream Cipher
Stream ciphers come in several flavours but two are worth mentioning here.
• Self-synchronizing stream ciphers calculate each bit in the keystream as a function of the previous
n bits in the keystream. It is termed "self-synchronizing" because the decryption process can stay
synchronized with the encryption process merely by knowing how far into the n-bit keystream it is.
One problem is error propagation; a garbled bit in transmission will result in n garbled bits at the
receiving side.
• Synchronous stream ciphers generate the keystream in a fashion independent of the message
stream but by using the same keystream generation function at sender and receiver. While stream
ciphers do not propagate transmission errors, they are, by their nature, periodic so that the
keystream will eventually repeat.

Universal Knowledge Solutions S.A.L.

- 159 -
 Secret Key Cryptography:
Block Cipher
Block ciphers can operate in one of several modes; the following four are the most important:
• Electronic Codebook (ECB) mode is the simplest, most obvious application: the secret key is used
to encrypt the plaintext block to form a ciphertext block. Two identical plaintext blocks, then, will
always generate the same ciphertext block. Although this is the most common mode of block
ciphers, it is susceptible to a variety of brute-force attacks.
• Cipher Block Chaining (CBC) mode adds a feedback mechanism to the encryption scheme. In
CBC, the plaintext is exclusively-ORed (XORed) with the previous ciphertext block prior to
encryption. In this mode, two identical blocks of plaintext never encrypt to the same ciphertext.
• Cipher Feedback (CFB) mode is a block cipher implementation as a self-synchronizing stream
cipher. CFB mode allows data to be encrypted in units smaller than the block size, which might be
useful in some applications such as encrypting interactive terminal input. If we were using 1-byte
CFB mode, for example, each incoming character is placed into a shift register the same size as the
block, encrypted, and the block transmitted. At the receiving side, the ciphertext is decrypted and
the extra bits in the block (i.e., everything above and beyond the one byte) are discarded.
• Output Feedback (OFB) mode is a block cipher implementation conceptually similar to a
synchronous stream cipher. OFB prevents the same plaintext block from generating the same
ciphertext block by using an internal feedback mechanism that is independent of both the plaintext
and ciphertext bitstreams.

Secret Key Cryptography Algorithms

Data Encryption Standard (DES):
• The most common SKC scheme used today.
• DES was designed by IBM in the 1970s and adopted by the National Bureau of Standards (NBS)
[now the National Institute for Standards and Technology (NIST)] in 1977 for commercial and
unclassified government applications.
• DES is a block-cipher employing a 56-bit key that operates on 64-bit blocks.
• DES has a complex set of rules and transformations that were designed specifically to yield fast
hardware implementations and slow software implementations, although this latter point is
becoming less significant today since the speed of computer processors is several orders of
magnitude faster today than twenty years ago.
• IBM also proposed a 112-bit key for DES, which was rejected at the time by the government; the
use of 112-bit keys was considered in the 1990s, however, conversion was never seriously
considered.
• DES is defined in American National Standard X3.92 and three Federal Information Processing
Standards (FIPS):
o FIPS 46-3: DES
o FIPS 74: Guidelines for Implementing and Using the NBS Data Encryption Standard
o FIPS 81: DES Modes of Operation

Triple-DES (3DES):
• A variant of DES that employs up to three 56-bit keys and makes three encryption/decryption

Universal Knowledge Solutions S.A.L.

- 160 -
 passes over the block; 3DES is also described in FIPS 46-3 and is the recommended replacement to
DES.

Advanced Encryption Standard (AES):

• In 1997, NIST initiated a very public, 4.5 year process to develop a new secure cryptosystem for
U.S. government applications. The result, the Advanced Encryption Standard, became the official
successor to DES in December 2001.
• AES uses an SKC scheme called Rijndael, a block cipher designed by Belgian cryptographers Joan
Daemen and Vincent Rijmen.
• The algorithm can use a variable block length and key length; the latest specification allowed any
combination of keys lengths of 128, 192, or 256 bits and blocks of length 128, 192, or 256 bits.
NIST initially selected Rijndael in October 2000 and formal adoption as the AES standard came in
December 2001. FIPS PUB 197 describes a 128-bit block cipher employing a 128-, 192-, or 256-
bit key.

International Data Encryption Algorithm (IDEA):

• Secret-key cryptosystem written by Xuejia Lai and James Massey, in 1992 and patented by Ascom;
a 64-bit SKC block cipher using a 128-bit key.
• Also available internationally.

Secret Key Cryptography Algorithms

DES
The Data Encryption Standard (DES) has been in use since the mid-1970s, adopted by the National
Bureau of Standards (NBS) as Federal Information Processing Standard 46 (FIPS 46-3) and by the
American National Standards Institute (ANSI) as X3.92.

DES uses the Data Encryption Algorithm (DEA), a secret key block-cipher employing a 56-bit key
operating on 64-bit blocks. FIPS 81 describes four modes of DES operation: Electronic Codebook
(ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), and Output Feedback (OFB). Despite
all of these options, ECB is the most commonly deployed mode of operation.

NIST finally declared DES obsolete in 2004, and withdrew FIPS 46-3, 74, and 81 (Federal Register,
July 26, 2004, 69(142), 44509-44510). Although other block ciphers will replace DES, it is still
interesting to see how DES encryption is performed; not only is it sort of neat, but DES was the first
crypto scheme commonly seen in non-governmental applications and was the catalyst for modern
"public" cryptography. DES remains in many products — and cryptography students and
cryptographers will continue to study DES for years to come.

Universal Knowledge Solutions S.A.L.

- 161 -
 Secret Key Cryptography Algorithms
Overview of DES Operations

Example:

Key: 1100101 0100100 1001001 0011101 0110101 0101011 1101100

0011010
Input GoAggies
character
string:
Input bit 11100010 11110110 10000010 11100110 11100110
string: 10010110 10100110 11001110
Output 10011111 11110010 10000000 10000001 01011011
bit 00101001 00000011 00101111
string:

Universal Knowledge Solutions S.A.L.

- 162 -
 Output ùO••Ú”Àô
character
string:

DES uses a 56-bit key. The 56-bit key is divided into eight 7-bit blocks and an 8th odd parity bit is
added to each block (i.e., a "0" or "1" is added to the block so that there are an odd number of 1 bits in
each 8-bit block).

By using the 8 parity bits for rudimentary error detection, a DES key is actually 64 bits in length for
computational purposes (although it only has 56 bits worth of randomness, or entropy).

DES acts on 64-bit blocks of the plaintext, invoking 16 rounds of permutations, swaps, and substitutes.

The standard includes tables describing all of the selection, permutation, and expansion operations
mentioned below; these aspects of the algorithm are not secrets. The basic DES steps are:
1. The 64-bit block to be encrypted undergoes an initial permutation (IP), where each bit is moved to
a new bit position; e.g., the 1st, 2nd, and 3rd bits are moved to the 58th, 50th, and 42nd position,
respectively.
2. The 64-bit permuted input is divided into two 32-bit blocks, called left and right, respectively. The
initial values of the left and right blocks are denoted L0 and R0.
3. There are then 16 rounds of operation on the L and R blocks. During each iteration (where n ranges
from 1 to 16), the following formulae apply:
Ln = Rn-1
Rn = Ln-1 XOR f(Rn-1,Kn)
4. At any given step in the process, then, the new L block value is merely taken from the prior R
block value. The new R block is calculated by taking the bit-by-bit exclusive-OR (XOR) of the
prior L block with the results of applying the DES cipher function, f, to the prior R block and Kn.
(Kn is a 48-bit value derived from the 64-bit DES key. Each round uses a different 48 bits
according to the standard's Key Schedule algorithm.)
5. The cipher function, f, combines the 32-bit R block value and the 48-bit subkey in the following
way. First, the 32 bits in the R block are expanded to 48 bits by an expansion function (E); the
extra 16 bits are found by repeating the bits in 16 predefined positions. The 48-bit expanded R-
block is then ORed with the 48-bit subkey. The result is a 48-bit value that is then divided into
eight 6-bit blocks. These are fed as input into 8 selection (S) boxes, denoted S1,...,S8. Each 6-bit
input yields a 4-bit output using a table lookup based on the 64 possible inputs; this results in a 32-
bit output from the S-box. The 32 bits are then rearranged by a permutation function (P), producing
the results from the cipher function.
6. The results from the final DES round — i.e., L16 and R16 — are recombined into a 64-bit value and
fed into an inverse initial permutation (IP-1). At this step, the bits are rearranged into their original
positions, so that the 58th, 50th, and 42nd bits, for example, are moved back into the 1st, 2nd, and
3rd positions, respectively. The output from IP-1 is the 64-bit ciphertext block.

Universal Knowledge Solutions S.A.L.

- 163 -
 Secret Key Cryptography Algorithms
Breaking DES
The mainstream cryptographic community has long held that DES's 56-bit key was too short to
withstand a brute-force attack from modern computers.

Remember Moore's Law: computer power doubles every 18 months. Given that increase in power, a
key that could withstand a brute-force guessing attack in 1975 could hardly be expected to withstand
the same attack a quarter century later.

DES is even more vulnerable to a brute-force attack because it is often used to encrypt words, meaning
that the entropy of the 64-bit block is, effectively, greatly reduced. That is, if we are encrypting
random bit streams, then a given byte might contain any one of 28 (256) possible values and the entire
64-bit block has 264, or about 18.5 quintillion, possible values. If we are encrypting words, however,
we are most likely to find a limited set of bit patterns; perhaps 70 or so if we account for upper and
lower case letters, the numbers, space, and some punctuation. This means that only about ¼ of the bit
combinations of a given byte are likely to occur.

Despite this criticism, the U.S. government insisted throughout the mid-1990s that 56-bit DES was
secure and virtually unbreakable if appropriate precautions were taken. In response, RSA Laboratories
sponsored a series of cryptographic challenges to prove that DES was no longer appropriate for use.

DES Challenge I was launched in March 1997. It was completed in 84 days by R. Verser in a
collaborative effort using thousands of computers on the Internet.

The first DES II challenge lasted 40 days in early 1998. This problem was solved by distributed.net, a
worldwide distributed computing network using the spare CPU cycles of computers around the
Internet (participants in distributed.net's activities load a client program that runs in the background,
conceptually similar to the SETI @Home "Search for Extraterrestrial Intelligence" project). The
distributed.net systems were checking 28 billion keys per second by the end of the project.

The second DES II challenge lasted less than 3 days. On July 17, 1998, the Electronic Frontier
Foundation (EFF) announced the construction of hardware that could brute-force a DES key in an
average of 4.5 days. Called Deep Crack, the device could check 90 billion keys per second and cost
only about $220,000 including design (it was erroneously and widely reported that subsequent devices
could be built for as little as $50,000). Since the design is scalable, this suggests that an organization
could build a DES cracker that could break 56-bit keys in an average of a day for as little as
$1,000,000.

The DES III challenge, launched in January 1999, was broken is less than a day by the combined
efforts of Deep Crack and distributed.net. This is widely considered to have been the final nail in
DES's coffin.

Universal Knowledge Solutions S.A.L.

- 164 -
 Secret Key Cryptography Algorithms
Breaking DES: Deep Cracker

The Deep Crack algorithm is actually quite interesting. The general approach that the DES Cracker
Project took was not to break the algorithm mathematically but instead to launch a brute-force attack
by guessing every possible key. A 56-bit key yields 256, or about 72 quadrillion, possible values. So the
DES cracker team looked for any shortcuts they could find!

First, they assumed that some recognizable plaintext would appear in the decrypted string even though
they didn't have a specific known plaintext block.

They then applied all 256 possible key values to the 64-bit block (I don't mean to make this sound
simple!). The system checked to see if the decrypted value of the block was "interesting," which they
defined as bytes containing one of the alphanumeric characters, space, or some punctuation. Since the
likelihood of a single byte being "interesting" is about ¼, then the likelihood of the entire 8-byte stream
being "interesting" is about ¼8, or 1/65536 (½16). This dropped the number of possible keys that might
yield positive results to about 240, or about a trillion.

They then made the assumption that an "interesting" 8-byte block would be followed by another
"interesting" block. So, if the first block of ciphertext decrypted to something interesting, they
decrypted the next block; otherwise, they abandoned this key. Only if the second block was also
"interesting" did they examine the key closer. Looking for 16 consecutive bytes that were "interesting"
meant that only 224, or 16 million, keys needed to be examined further. This further examination was
primarily to see if the text made any sense. Note that possible "interesting" blocks might be
1hJ5&aB7 or DEPOSITS; the latter is more likely to produce a better result. And even a slow laptop
today can search through lists of only a few million items in a relatively short period of time.

It is well beyond the scope of this paper to discuss other forms of breaking DES and other codes.
Nevertheless, it is worth mentioning a couple of forms of cryptanalysis that have been shown to be
effective against DES. Differential cryptanalysis, invented in 1990 by E. Biham and A. Shamir (of
RSA fame), is a chosen-plaintext attack. By selecting pairs of plaintext with particular differences, the
cryptanalyst examines the differences in the resultant ciphertext pairs. Linear plaintext, invented by M.
Matsui, uses a linear approximation to analyze the actions of a block cipher (including DES). Both of
these attacks can be more efficient than brute force.

Secret Key Cryptography Algorithms

DES Variants
Once DES was "officially" broken, several variants appeared. But none of them came overnight; work
at hardening DES had already been underway.

In the early 1990s, there was a proposal to increase the security of DES by effectively increasing the
key length by using multiple keys with multiple passes. But for this scheme to work, it had to first be
shown that the DES function is not a group, as defined in mathematics.

Universal Knowledge Solutions S.A.L.

- 165 -
If DES was a group, then we could show that for two DES keys, X1 and X2, applied to some plaintext
(P), we can find a single equivalent key, X3, that would provide the same result; i.e.,:
EX2(EX1(P)) = EX3(P)
Where EX(P) represents DES encryption of some plaintext P using DES key X.

If DES were a group, it wouldn't matter how many keys and passes we applied to some plaintext; we
could always find a single 56-bit key that would provide the same result. As it happens, DES was
proven to not be a group so that as we apply additional keys and passes, the effective key length
increases.

Secret Key Cryptography Algorithms

DES Variants: Double DES
One obvious choice, then, might be to use two keys and two passes, yielding an effective key length of
112 bits. Let's call this Double-DES. The two keys, Y1 and Y2, might be applied as follows:
C = EY2(EY1(P))
P = DY1(DY2(C))
Where EY(P) and DY(C) represent DES encryption and decryption, respectively, of some plaintext P
and ciphertext C, respectively, using DES key Y.

But there's an interesting attack that can be launched against this "Double-DES" scheme. First, notice
that the applications of the formula above can be thought of with the following individual steps (where
C' and P' are intermediate results):
C' = EY1(P) and C = EY2(C')
P' = DY2(C) and P = DY1(P')

Unfortunately, C'=P'. That leaves us vulnerable to a simple known plaintext attack (sometimes called
"Meet-in-the-middle") where the attacker knows some plaintext (P) and its matching ciphertext (C). To
obtain C', the attacker needs to try all 256 possible values of Y1 applied to P; to obtain P', the attacker
needs to try all 256 possible values of Y2 applied to C. Since C'=P', the attacker knows when a match
has been achieved — after only 256 + 256 = 257 key searches, only twice the work of brute-forcing DES.
So "Double-DES" won't work.

Secret Key Cryptography Algorithms

DES Variants: Triple DES
Triple-DES (3DES), based upon the Triple Data Encryption Algorithm (TDEA), is described in FIPS
46-3.

3DES, which is not susceptible to a meet-in-the-middle attack, employs three DES passes and one,
two, or three keys called K1, K2, and K3. Generation of the ciphertext (C) from a block of plaintext
(P) is accomplished by:

Universal Knowledge Solutions S.A.L.

- 166 -
 C = EK3(DK2(EK1(P)))

Where EK(P) and DK(P) represent DES encryption and decryption, respectively, of some plaintext P
using DES key K. (For obvious reasons, this is sometimes referred to as an encrypt-decrypt-encrypt
mode operation.)

Decryption of the ciphertext into plaintext is accomplished by:

P = DK1(EK2(DK3(C)))

The use of three, independent 56-bit keys provides 3DES with an effective key length of 168 bits. The
specification also defines use of two keys where, in the operations above, K3 = K1; this provides an
effective key length of 112 bits. Finally, a third keying option is to use a single key, so that K3 = K2 =
K1 (in this case, the effective key length is 56 bits and 3DES applied to some plaintext, P, will yield
the same ciphertext, C, as normal DES would with that same key). Given the relatively low cost of key
storage and the modest increase in processing due to the use of longer keys, the best recommended
practices are that 3DES be employed with three keys.

Secret Key Cryptography Algorithms

DES Variants: DESX
Another variant of DES, called DESX, is due to Ron Rivest. Developed in 1996, DESX is a very
simple algorithm that greatly increases DES's resistance to brute-force attacks without increasing its
computational complexity.

In DESX, the plaintext input is XORed with 64 additional key bits prior to encryption and the output is
likewise XORed with the 64 key bits.

By adding just two XOR operations, DESX has an effective keylength of 120 bits against an
exhaustive key-search attack.

As it happens, DESX is no more immune to other types of more sophisticated attacks, such as
differential or linear cryptanalysis, but brute-force is the primary attack vector on DES.

Secret Key Cryptography Algorithms: IDEA

1. First set of 8 SubKeys composing the original Key (128 bits):
16 16 16 16 16 16 16 16

2. From the first set we perform a shift left of 25 bits:

Universal Knowledge Solutions S.A.L.

- 167 -
Voice Over
16Text of 16
(Same the Slide) 16 16 16 16 16 16

Shift of 25 bit

3. From the previous shift left, we obtain a second set of 8 SubKeys (128 bits). Thus a 256 bit key is
obtained (composed from 16 subkeys):
16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

4. We repeat the shift left operation on each last set of 8 subkeys obtained. The loop should stop after
the composition of 52 subkeys:
16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

16 16 16 16 16 16 16 16

16 16 16 16
5. We have now: 52 sub-keys of 16 bits each, and a plaintext composed of 64 bits blocks (Composed
of 4 sub-blocks with 16 bits length each):

Universal Knowledge Solutions S.A.L.

- 168 -
 Keys
16 16
S1 S52

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

6. The functions used to computer the ciphertext are: XOR, + (modulo 216), and * (modulo 216+1):
Keys
16 16
S1 S52

XOR + (mod 216) * (mod 216+1)

Plain Text Block (64 bits)

16 16 16 16
P1 P2 P3 P4
7. For each block composed of 4 subblocks (P1,P2,P3,P4) of 16 bits length, we repeat the following
computations:

Universal Knowledge Solutions S.A.L.

- 169 -
 Keys
16 16
Inputs st
S1 1 Round S52
p1 * s1 Æ d1
p2 + s2 Æ d2 d8 * s6 Æ d9
(1)
p3 + s3 Æ d3 (4) d7 + d9 Æ d10
p4 * s4 Æ d4
d1 XOR d9 Æ d11
d1 XOR d3 Æ d5 (5) d3 XOR d9 Æ d12
(2) d2 XOR d4 Æ d6 d2 XOR d10 Æ d13
d4 XOR d10 Æ d14
(3) d5 * s5 Æ d7
d6 + d7 Æ d8
Outputs
PlainText Block (64 bits)
16 16 16 16
P1 P2 P3 P4

Keys
16 16
Inputs nd
S1 2 Round S52
d11 * s7 Æ d15
d13 + s8 Æ d16 d22 * s12 Æ d23
(1)
d12 + s9 Æ d17 (4) d21 + d23 Æ d24
d14 * s10 Æ d18
d11 XOR d23 Æ d25
d11 XOR d12 Æ d19 (5) d13 XOR d23 Æ d26
(2) d13 XOR d14 Æ d20 d12 XOR d24 Æ d27
d14 XOR d24 Æ d28
(3) d19 * s11 Æ d21
d20 + d21 Æ d22
Outputs
Text Block (64 bits)
16 16 16 16
P1 P2 P3 P4

Universal Knowledge Solutions S.A.L.

- 170 -
 Keys
16 16
rd
S1 3 Round S52

Inputs
s13, s14, s15, s16, s17, s18

d29, d30, d31, d32

Outputs

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

Keys
16 bits 16 bits
th
S1 4 Round S52

s19, s20, s21, s22, s23, s24

d33, d34, d35, d36

PlainText Block (64 bits)

16 bits 16 bits 16 bits 16 bits
P1 P2 P3 P4

Universal Knowledge Solutions S.A.L.

- 171 -
 Keys
16 16
th
S1 5 Round S52

s25, s26, s27, s28, s29, s30

d37, d38, d39, d40

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

Keys
16 16
th
S1 6 Round S52

s31, s32, s33, s34, s35, s36

d41, d42, d43, d44

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

Universal Knowledge Solutions S.A.L.

- 172 -
 Keys
16 16
th
S1 7 Round S52

s37, s38, s39, s40, s41, s42

d45, d46, d47, d48

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

Keys
16 16
th
S1 8 Round S52

s43, s44, s45, s46, s47, s48

d49, d50, d51, d52 e1, e2, e3, e4

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

Universal Knowledge Solutions S.A.L.

- 173 -
 Keys
16 16
S1 S52

e1 * s49 Æ c1 16

e2 * s50 Æ c2 16 CipherText
Block
e3 * s51 Æ c3 16

e4 * s52 Æ c4 16

PlainText Block (64 bits)

16 16 16 16
P1 P2 P3 P4

Public Key Cryptography

Public-key cryptography has been said to be the most significant new development in cryptography in
the last 300-400 years.

Modern PKC was first described publicly by Stanford University professor Martin Hellman and
graduate student Whitfield Diffie in 1976. Their paper described a two-key crypto system in which two
parties could engage in a secure communication over a non-secure communications channel without
having to share a secret key.

PKC depends upon the existence of so-called one-way functions, or mathematical functions that are
easy to compute whereas their inverse function is relatively difficult to compute. Two simple
examples:

• Multiplication vs. factorization: Suppose we have two numbers, 9 and 16, and that we want to
calculate the product; it should take almost no time to calculate the product, 144. Suppose instead
we have a number, 144, and we need to guess which pair of integers are multiplied together to
obtain that number. We will eventually come up with the solution but whereas calculating the
product took milliseconds, factoring will take longer because we first need to find the 8 pair of
integer factors and then determine which one is the correct pair.
• Exponentiation vs. logarithms: Suppose wer want to take the number 3 to the 6th power; again, it is
easy to calculate 36=729. But if we I have the number 729 and we want to guess the two integers
used, x and y so that logx 729 = y, it will be more difficult to have all possible solutions and select
the pair that I used.

Universal Knowledge Solutions S.A.L.

- 174 -
While the examples above are trivial, they do represent two of the functional pairs that are used with
PKC; namely, the ease of multiplication and exponentiation versus the relative difficulty of factoring
and calculating logarithms, respectively.

The mathematical "trick" in PKC is to find a trap door in the one-way function so that the inverse
calculation becomes easy given knowledge of some item of information.

Public Key Cryptography:

Asymmetric Cryptography
Generic PKC employs two keys that are mathematically related although knowledge of one key does
not allow someone to easily determine the other key.

One key is used to encrypt the plaintext and the other key is used to decrypt the ciphertext. The
important point here is that it does not matter which key is applied first, but that both keys are
required for the process to work.

Because a pair of keys is required, this approach is also called asymmetric cryptography.

In PKC, one of the keys is designated the public key and may be advertised as widely as the owner
wants.
The other key is designated the private key and is never revealed to another party. It is straight forward
to send messages under this scheme.

Suppose Alice wants to send Bob a message. Alice encrypts some information using Bob's public key;
Bob decrypts the ciphertext using his private key.

This method could be also used to prove who sent a message; Alice, for example, could encrypt some
plaintext with her private key; when Bob decrypts using Alice's public key, he knows that Alice sent
the message and Alice cannot deny having sent the message (non-repudiation).

Public Key Cryptography Algorithms

RSA:
• The first, and still most common, PKC implementation, named for the three MIT mathematicians
who developed it — Ronald Rivest, Adi Shamir, and Leonard Adleman.
• RSA today is used in hundreds of software products and can be used for key exchange, digital
signatures, or encryption of small blocks of data.
• RSA uses a variable size encryption block and a variable size key.

Universal Knowledge Solutions S.A.L.

- 175 -
 o The key-pair is derived from a very large number, n, that is the product of two prime numbers
chosen according to special rules; these primes may be 100 or more digits in length each,
yielding an n with roughly twice as many digits as the prime factors.
o The public key information includes n and a derivative of one of the factors of n; an attacker
cannot determine the prime factors of n (and, therefore, the private key) from this information
alone and that is what makes the RSA algorithm so secure.
o Some descriptions of PKC erroneously state that RSA's safety is due to the difficulty in
factoring large prime numbers. In fact, large prime numbers, like small prime numbers, only
have two factors!
• The ability for computers to factor large numbers, and therefore attack schemes such as RSA, is
rapidly improving and systems today can find the prime factors of numbers with more than 140
digits.
• The presumed protection of RSA, however, is that users can easily increase the key size to always
stay ahead of the computer processing curve. As an aside, the patent for RSA expired in September
2000 which does not appear to have affected RSA's popularity one way or the other.

Diffie-Hellman:
• After the RSA algorithm was published, Diffie and Hellman came up with their own algorithm.
• D-H is used for secret-key key exchange only, and not for authentication or digital signatures.

Digital Signature Algorithm (DSA):

• The algorithm specified in NIST's Digital Signature Standard (DSS), provides digital signature
capability for the authentication of messages.

ElGamal:
• Designed by Taher Elgamal, a PKC system similar to Diffie-Hellman and used for key exchange.

Elliptic Curve Cryptography (ECC):

• A PKC algorithm based upon elliptic curves.
• ECC can offer levels of security with small keys comparable to RSA and other PKC methods. It
was designed for devices with limited compute power and/or memory, such as smartcards and
PDAs.

Who invented PKC?

• Diffie and Hellman "first described publicly" a PKC scheme.

• Although we have categorized PKC as a two-key system, that has been merely for convenience.

• The real criteria for a PKC scheme is that it allows two parties to exchange a secret even though
the communication with the shared secret might be overheard.
o There seems to be no question that Diffie and Hellman were first to publish; their method is
described in the classic paper, "New Directions in Cryptography," published in the November
1976 issue of IEEE Transactions on Information Theory.
o Diffie-Hellman uses the idea that finding logarithms is relatively harder than exponentiation.

Universal Knowledge Solutions S.A.L.

- 176 -
 And, indeed, it is the precursor to modern PKC which does employ two keys.

• Rivest, Shamir, and Adleman described an implementation that extended this idea in their paper "A
Method for Obtaining Digital Signatures and Public-Key Cryptosystems," published in the
February 1978 issue of the Communications of the ACM (CACM).

• Their method is based upon the relative ease of finding the product of two large prime numbers
compared to finding the prime factors of a large number.

Deffie- Hellman

Alice... Bob...

Choose a large random number, x Choose a large random number, y

Send to Bob: X = gx mod n Send to Alice: Y = gy mod n
Compute: KA = Yx mod n Compute: KB = Xy mod n

Alice... Bob...

Choose x=2 Choose y=3

Send to Bob: X = 32 mod 7 = 2 Send to Alice: Y = 33 mod 7 = 6
KA = 62 mod 7 = 1 KB = 23 mod 7 = 1

The first published public-key crypto algorithm was Diffie-Hellman. The mathematical "trick" of this
scheme is that it is relatively easy to compute exponents compared to computing discrete logarithms.
Diffie-Hellman allows two parties — the ubiquitous Alice and Bob — to generate a secret key; they
need to exchange some information over an unsecure communications channel to perform the
calculation but an eavesdropper cannot determine the shared key based upon this information.

Diffie-Hellman works like this:

• Alice and Bob start by agreeing on a large prime number, n. They also have to choose some
number g so that g<n.

• There is actually another constraint on g, specifically that it must be primitive with respect to n.

• Primitive is a definition that is a little beyond the scope of our discussion but basically g is
primitive to n if we can find integers i so that gi = j mod n for all values of j from 1 to n-1.

• As an example, 2 is not primitive to 7 because the set of powers of 2 from 1 to 6, mod 7 =

{2,4,1,2,4,1}. On the other hand, 3 is primitive to 7 because the set of powers of 3 from 1 to 6, mod

Universal Knowledge Solutions S.A.L.

- 177 -
 7 = {3,2,6,4,5,1}.(The definition of primitive introduced a new term to some readers, namely mod.
The phrase x mod y (and read as written!) means "take the remainder after dividing x by y." Thus, 1
mod 7 = 1, 9 mod 6 = 3, and 8 mod 8 = 0.)

• Anyway, either Alice or Bob selects n and g; they then tell the other party what the values are.
Alice and Bob then work independently:

• Note that x and y are kept secret while X and Y are openly shared; these are the private and public
keys, respectively. Based on their own private key and the public key learned from the other party,
Alice and Bob have computed their secret keys, KA and KB, respectively, which are equal to gxy
mod n.

• Perhaps a small example will help here. Although Alice and Bob will really choose large values for
n and g, I will use small values for example only; let's use n=7 and g=3.

• In this example, then, Alice and Bob will both find the secret key 1 which is, indeed, 36 mod 7. If
an eavesdropper (Mallory) was listening in on the information exchange between Alice and Bob,
he would learn g, n, X, and Y which is a lot of information but insufficient to compromise the key;
as long as x and y remain unknown, K is safe. As said above, calculating X as gx is a lot easier than
finding x as logg X!

RSA
Unlike Diffie-Hellman, RSA can be used for key exchange as well as digital signatures and the
encryption of small blocks of data.

Today, RSA is primary used to encrypt the session key used for secret key encryption (message
integrity) or the message's hash value (digital signature). RSA's mathematical hardness comes from the
ease in calculating large numbers and the difficulty in finding the prime factors of those large numbers.

Although employed with numbers using hundreds of digits, the math behind RSA is relatively straight-
forward.

To create an RSA public/private key pair, here are the basic steps:
1. Choose two prime numbers, p and q.
2. From these numbers you can calculate the modulus, n = pq.
3. Select a third number, e, that is relatively prime to (i.e., it does not divide evenly into) the product
(p-1)(q-1).
4. The number e is the public exponent.
5. Calculate an integer d from the quotient (ed-1)/[(p-1)(q-1)].
6. The number d is the private exponent.
7. The public key is the number pair (n,e).
8. Although these values are publicly known, it is computationally infeasible to determine d from n and
e if p and q are large enough.

Universal Knowledge Solutions S.A.L.

- 178 -
To encrypt a message, M, with the public key,
1. Create the ciphertext, C, using the equation: C = Me mod n
2. The receiver then decrypts the ciphertext with the private key using the equation: M = Cd mod n

Since p and q may be 100 digits (decimal) or more, d and e will be about the same size and n may be
over 200 digits.

Hash Functions
Hash functions, also called message digests and one-way encryption, are algorithms that, in some
sense, use no key. Instead, a fixed-length hash value is computed based upon the plaintext that makes it
impossible for either the contents or length of the plaintext to be recovered.

Hash algorithms are typically used to provide a digital fingerprint of a file's contents often used to
ensure that the file has not been altered by an intruder or virus.

Hash functions are also commonly employed by many operating systems to encrypt passwords. Hash
functions, then, provide a measure of the integrity of a file.

Hash functions are sometimes misunderstood and some sources claim that no two files can have the
same hash value. This is, in fact, not correct. Consider a hash function that provides a 128-bit hash
value. There are, obviously, 2128 possible hash values. But there are a lot more than 2128 possible files.
Therefore, there have to be multiple files — in fact, there have to be an infinite number of files! — that
can have the same 128-bit hash value.

The difficulty is finding two files with the same hash! What is, indeed, very hard to do is to try to
create a file that has a given hash value so as to force a hash value collision — which is the reason that
hash functions are used extensively for information security and computer forensics applications.

Alas, researchers in 2004 found that practical collision attacks could be launched on MD5, SHA-1,
and other hash algorithms. At this time, there is no obvious successor to MD5 and SHA-1 that could be
put into use quickly; there are so many products using these hash functions that it could take many
years to flush out all use of 128- and 160-bit hashes.

Secure Hash Algorithm (SHA-1)

SHA is a hashing function that produces digests composed of 160 bits.

Variables:
SHA uses 5 variables, presented in hexadecimal as follows:

Universal Knowledge Solutions S.A.L.

- 179 -
• A = 67 45 23 01
• B = EF CD AB 89
• C = 98 BA DC FE
• D = 10 32 54 76
• E = C3 D2 E1 F0

Padding:

If the size of the message is not a multiple of 512, then the algorithm must complete the message by
adding one 1 and a suite of 0 until the end of an accepted size of the message (multiple of 512).

Functions:

SHA-1 uses 4 loops. In each loop 20 operations are performed. This algorithm uses 80 functions based
on three variables of 32 bits B, C and D and these functions produce words of 32 bits.

The 80 functions are defined as follows:

• ft(B,C,D) = (B AND C) OR ((NOT B) AND D) (t between 0 and 19)
• ft (B,C,D) = B XOR C XOR D (t between 20 and 39)
• ft (B,C,D) = (B AND C) OR (B AND D) OR (C AND D) (t between 40 and 59)
• ft (B,C,D) = B XOR C XOR D (t between 60 and 79)

Constants
SHA-1 uses constants. These constants are:
• Kt = 5A827999 (t between 0 and 19)
• Kt = 6ED9EBA1 (t between 20 and 39)
• Kt = 8F1BBCDC (t between 40 and 59)
• Kt = CA62C1D6 (t between 60 and 79)

The Algorithm
The algorithm uses 2 buffers of 5 words each (a word is composed of 32 bits), a sequence of 80 words,
and a temporary buffer called TEMP.
• The first buffer is denoted {A, B, C, D, E}.
• The second buffer se denoted {H0, H1, H2, H3, H4}.
• The 80 words are denoted W0 to W79.
• The message is divided into blocs of 512 bits, denoted M1 … Mn.

H0 = 67452301
H1 = EFCDAB89
H2 = 98BADCFE
H3 = 10325476
H4 = C3D2E1F0.

From each bloc of 512 bits

Begin
• Create 16 words of 32 bits each and assign the words to W0, W1 W15;
• For t varies between 16 and 79

Universal Knowledge Solutions S.A.L.

- 180 -
 o Assign the words Wt as follows:
Wt = Wt-3 XOR Wt-8 XOR Wt- 14 XOR Wt-16 ;
o Assign The variables as follows:
A = H0; B = H1; C = H2; D = H3;E = H4;
• For t varies between 0 and 79
o Let Sn be a circular shift left of n bits
o We perform the following computation:
TEMP = S5(A) + ft(B,C,D) + E + Wt + Kt;
E = D;
D = C;
C = S30(B);
B = A;
A = TEMP;
• We perform the following assignment:
H0 = H0 + A
H1 = H1 + B
H2 = H2 + C
H3 = H3 + D
H4 = H4 + E.
End

Result: The digest composed of {H0 H1 H2 H3 H4}

Password Protection Using Hash Techniques

A) /etc/passwd file

root:Jbw6BwE4XoUHo:0:0:root:/root:/bin/bash
carol:FM5ikbQt1K052:502:100:Carol Monaghan:/home/carol:/bin/bash
alex:LqAi7Mdyg/HcQ:503:100:Alex Insley:/home/alex:/bin/bash
gary:FkJXupRyFqY4s:501:100:Gary Kessler:/home/gary:/bin/bash
todd:edGqQUAaGv7g6:506:101:Todd Pritsky:/home/todd:/bin/bash
josh:FiH0ONcjPut1g:505:101:Joshua Kessler:/home/webroot:/bin/bash

B.1) /etc/passwd file (with shadow passwords)

root:x:0:0:root:/root:/bin/bash
carol:x:502:100:Carol Monaghan:/home/carol:/bin/bash
alex:x:503:100:Alex Insley:/home/alex:/bin/bash
gary:x:501:100:Gary Kessler:/home/gary:/bin/bash
todd:x:506:101:Todd Pritsky:/home/todd:/bin/bash
josh:x:505:101:Joshua Kessler:/home/webroot:/bin/bash

B.2) /etc/shadow file

root:AGFw$1$P4u/uhLK$l2.HP35rlu65WlfCzq:11449:0:99999:7:::
carol:kjHaN%35a8xMM8a/0kMl1?fwtLAM.K&kw.:11449:0:99999:7:::
alex:1$1KKmfTy0a7#3.LL9a8H71lkwn/.hH22a:11449:0:99999:7:::

Universal Knowledge Solutions S.A.L.

- 181 -
 gary:9ajlknknKJHjhnu7298ypnAIJKL$Jh.hnk:11449:0:99999:7:::
todd:798POJ90uab6.k$klPqMt%alMlprWqu6$.:11492:0:99999:7:::
josh:Awmqpsui*787pjnsnJJK%aappaMpQo07.8:11492:0:99999:7:::

The password password, for example, might be stored as the hash value (in hexadecimal)
60771b22d73c34bd4a290a79c8b09f18.

Nearly all modern multiuser computer and network operating systems employ passwords at the very
least to protect and authenticate users accessing computer and/or network resources.

But passwords are not typically kept on a host or server in plaintext, but are generally encrypted using
some sort of hash scheme.

Unix/Linux, for example, uses a well-known hash via its crypt() function. Passwords are stored in the
/etc/passwd file; each record in the file contains the username, hashed password, user's individual and
group numbers, user's name, home directory, and shell program; these fields are separated by colons
(:).

Note that each password is stored as a 13-byte string. The first two characters are actually a salt,
randomness added to each password so that if two users have the same password, they will still be
encrypted differently; the salt, in fact, provides a means so that a single password might have 4096
different encryptions. The remaining 11 bytes are the password hash, calculated using DES.

As it happens, the /etc/passwd file is world-readable on Unix systems. This fact, coupled with the weak
encryption of the passwords, resulted in the development of the shadow password system where
passwords are kept in a separate, non-world-readable file used in conjunction with the normal
password file.

When shadow passwords are used, the password entry in /etc/passwd is replaced with a "*" or "x" and
the MD5 hash of the passwords are stored in /etc/shadow along with some other account information
(Figure 5B.2).

Windows NT uses a similar scheme to store passwords in the Security Access Manager (SAM) file. In
the NT case, all passwords are hashed using the MD4 algorithm, resulting in a 128-bit (16-byte) hash
value.

The password password, for example, might be stored as the hash value (in hexadecimal)
60771b22d73c34bd4a290a79c8b09f18.

Combining Encryption Techniques

So, why are there so many different types of cryptographic schemes? Why can't we do everything we
need with just one?

• Hash functions, are well-suited for ensuring data integrity because any change made to the contents
of a message will result in the receiver calculating a different hash value than the one placed in the

Universal Knowledge Solutions S.A.L.

- 182 -
 transmission by the sender. Since it is highly unlikely that two different messages will yield the
same hash value, data integrity is ensured to a high degree of confidence.

• Secret key cryptography, on the other hand, is ideally suited to encrypting messages. The sender
can generate a session key on a per-message basis to encrypt the message; the receiver, of course,
needs the same session key to decrypt the message.

• Key exchange, of course, is a key application of public-key cryptography (no pun intended).

• Asymmetric schemes can also be used for non-repudiation; if the receiver can obtain the session
key encrypted with the sender's private key, then only this sender could have sent the message.

• Public-key cryptography could, theoretically, also be used to encrypt messages although this is
rarely done because secret-key cryptography operates about 1000 times faster than public-key
cryptography.

Digital Signature & Digital Envelope

A hybrid cryptographic scheme combines all of these functions to form a secure transmission
comprising digital signature and digital envelope. Thus, a digital envelope comprises an encrypted
message and an encrypted session key.

For example:
• Alice uses secret key cryptography to encrypt her message using the session key, which she

Universal Knowledge Solutions S.A.L.

- 183 -
 generates at random with each session.
• Alice then encrypts the session key using Bob's public key.
• The encrypted message and encrypted session key together form the digital envelope.
• Upon receipt, Bob recovers the session secret key using his private key and then decrypts the
encrypted message.
• The digital signature is formed in two steps:
o First, Alice computes the hash value of her message;
o Next, she encrypts the hash value with her private key.
• Upon receipt of the digital signature, Bob recovers the hash value calculated by Alice by
decrypting the digital signature with Alice's public key.
• Bob can then apply the hash function to Alice's original message, which he has already decrypted
(see previous paragraph).
• If the resultant hash value is not the same as the value supplied by Alice, then Bob knows that the
message has been altered; if the hash values are the same, Bob should believe that the message he
received is identical to the one that Alice sent.

This scheme also provides non-repudiation since:

• It proves that Alice sent the message; if the hash value recovered by Bob using Alice's public key
proves that the message has not been altered, then only Alice could have created the digital
signature.
• Bob also has proof that he is the intended receiver; if he can correctly decrypt the message, then he
must have correctly decrypted the session key meaning that his is the correct private key.

The significance of key length

In a recent article in, a writer made the claim that 56-bit keys do not provide as sufficient protection for
DES today as they did in 1975 because computers are 1000 times faster today than in 1975.

Therefore, the writer went on, we should be using 56,000-bit keys today instead of 56-bit keys to
provide adequate protection.

The conclusion was then drawn that because 56,000-bit keys are infeasible (true), we should accept the
fact that we have to live with weak cryptography (false!).

The major error here is that the writer did not take into account that the number of possible key values
double whenever a single bit is added to the key length; thus, a 57-bit key has twice as many values as
a 56-bit key (because 257 is two times 256). In fact, a 66-bit key would have 1024 times the possible
values as a 56-bit key.

But this does bring up the issue, what is the precise significance of key length as it
affects the level of protection?
In cryptography, size does matter. The larger the key, the harder it is to crack a block of encrypted
data. The reason that large keys offer more protection is almost obvious; computers have made it easier
to attack ciphertext by using brute force methods rather than by attacking the mathematics (which are
generally well-known anyway). With a brute force attack, the attacker merely generates every possible

Universal Knowledge Solutions S.A.L.

- 184 -
key and applies it to the ciphertext. Any resulting plaintext that makes sense offers a candidate for a
legitimate key.

Until the mid-1990s or so, brute force attacks were beyond the capabilities of computers that were
within the budget of the attacker community. Today, however, significant compute power is commonly
available and accessible. General purpose computers such as PCs are already being used for brute force
attacks.

How big is big enough?

DES, invented in 1975, is still in use today, nearly 25 years later. If we take that to be a design criteria
(i.e., a 20-plus year lifetime) and we believe Moore's Law ("computing power doubles every 18
months"), then a key size extension of 14 bits (i.e., a factor of more than 16,000) should be adequate.

The 1975 DES proposal suggested 56-bit keys; by 1995, a 70-bit key would have been required to
offer equal protection and an 85-bit key will be necessary by 2015.

While a large key is good, a huge key may not always be better. That is, many public-key
cryptosystems use 1024- or 2048-bit keys; expanding the key to 4096 bits probably doesn't add any
protection at this time but it does add significantly to processing time.

The most effective large-number factoring methods today use a mathematical Number Field Sieve to
find a certain number of relationships and then use a matrix operation to solve a linear equation to
produce the two prime factors.

The sieve step actually involves a large number of operations of operations that can be performed in
parallel; solving the linear equation, however, requires a supercomputer.

Indeed, finding the solution to the RSA-140 challenge in February 1999 — factoring a 140-digit (465-
bit) prime number — required 200 computers across the Internet about 4 weeks for the first step and a
Cray computer 100 hours and 810 MB of memory to do the second step.

In early 1999, Shamir (of RSA fame) described a new machine that could increase factorization speed
by 2-3 orders of magnitude.

There still appear to be many engineering details that have to be worked out before such a machine
could be built. Furthermore, the hardware improves the sieve step only; the matrix operation is not
optimized at all by this design and the complexity of this step grows rapidly with key length, both in
terms of processing time and memory requirements. Nevertheless, this plan conceptually puts 512-bit
keys within reach of being factored. Although most PKC schemes allow keys that are 1024 bits and
longer, Shamir claims that 512-bit RSA keys "protect 95% of today's E-commerce on the Internet."

Universal Knowledge Solutions S.A.L.

- 185 -
 Part 6
Security Measures (3): Cryptography Applications
Keywords:
Certificate, VPN, AAA Server, Certificate Authority, Pretty Good Privacy, Secure Socket Layer,
Kerberos.

Summary:
This section describes different trust models and many secure protocols used for one of the biggest and
fastest growing applications of cryptography today, though, is electronic commerce (e-commerce), a
term that itself begs for a formal definition.
The section describes also enhanced configuration of a corporate network using VPN which is based
on many theoretical and practical elements of cryptography.

Objectives:
Upon completion of this part, the student will be able to understand:
• Secure Protocols
• Trust Models
• VPN

Universal Knowledge Solutions S.A.L.

- 186 -
 Trust Models

Secure use of cryptography requires trust. While secret key cryptography can ensure message
confidentiality and hash codes can ensure integrity, none of this works without trust.

In SKC, Alice and Bob had to share a secret key. PKC solved the secret distribution problem, but how
does Alice really know that Bob is who he says he is? Just because Bob has a public and private key,
and purports to be "Bob," how does Alice know that a malicious person (Mallory) is not pretending to
be Bob?

There are a number of trust models employed by various cryptographic schemes. We will explore three
of them:
• The web of trust employed by Pretty Good Privacy (PGP) users, who hold their own set of trusted
public keys.
• Kerberos, a secret key distribution scheme using a trusted third party.
• Certificates, which allow a set of trusted third parties to authenticate each other and, by
implication, each other's users.

Each of these trust models differs in complexity, general applicability, scope, and scalability.

Trust Models: PGP Web of Trust

Definition
Pretty Good Privacy is a widely used private e-mail scheme based on public key methods.

A PGP user maintains a local keyring of all their known and trusted public keys.

The user makes his determination about the trustworthiness of a key using what is called a "web of
trust."

PGP makes no statement and has no protocol about how one user determines whether they trust
another user or not. In any case, encryption and signatures based on public keys can only be used when
the appropriate public key is on the user's keyring.

How does it Work?

• If Alice needs Bob's public key, Alice can ask Bob for it in another e-mail or, in many cases,
download the public key from an advertised server; this server might a well-known PGP key
repository or a site that Bob maintains himself. In fact, Bob's public key might be stored or listed in
many places.
• Alice is prepared to believe that Bob's public key, as stored at these locations, is valid.
• Suppose Carol claims to hold Bob's public key and offers to give the key to Alice; How does Alice
know that Carol's version of Bob's key is valid or if Carol is actually giving Alice a key that will
allow Mallory access to messages?
• The answer is, "It depends." If Alice trusts Carol and Carol says that she thinks that her version of
Bob's key is valid, then Alice may — at her option — trust that key.
• And trust is not necessarily transitive; if Dave has a copy of Bob's key and Carol trusts Dave, it

Universal Knowledge Solutions S.A.L.

- 187 -
 does not necessarily follow that Alice trusts Dave even if she does trust Carol.
• The point here is that that Alice trusts and how she makes that determination is strictly up to Alice.

Kerberos

Definition
Kerberos is a commonly used authentication scheme on the Internet. Developed by MIT's Project
Athena, Kerberos is named for the three-headed dog that, according to Greek mythology, guards the
entrance of Hades (rather than the exit, for some reason!).

Kerberos employs client/server architecture and provides user-to-server authentication rather than host-
to-host authentication. In this model, security and authentication will be based on secret key
technology where every host on the network has its own secret key.

It would clearly be unmanageable if every host had to know the keys of all other hosts so a secure,
trusted host somewhere on the network, known as a Key Distribution Center (KDC), knows the keys
for all of the hosts (or at least some of the hosts within a portion of the network, called a realm). In this
way, when a new node is brought online, only the KDC and the new node need to be configured with
the node's key; keys can be distributed physically or by some other secure means.

The current shipping version of this protocol is Kerberos V5 (described in RFC 1510), although
Kerberos V4 still exists and is seeing some use. While the details of their operation, functional

Universal Knowledge Solutions S.A.L.

- 188 -
capabilities, and message formats are different, the conceptual overview above pretty much holds for
both. One primary difference is that Kerberos V4 uses only DES to generate keys and encrypt
messages, while V5 allows other schemes to be employed (although DES is still the most widely
algorithm used).

How does it Work?

The Kerberos Server/KDC has two main functions, known as the Authentication Server (AS) and
Ticket-Granting Server (TGS).

The steps in establishing an authenticated session between an application client and the application
server are:
1. The Kerberos client software establishes a connection with the Kerberos server's AS function. The
AS first authenticates that the client is who it purports to be. The AS then provides the client with a
secret key for this login session (the TGS session key) and a ticket-granting ticket (TGT), which
gives the client permission to talk to the TGS. The ticket has a finite lifetime so that the
authentication process is repeated periodically.
2. The client now communicates with the TGS to obtain the Application Server's key so that it (the
client) can establish a connection to the service it wants. The client supplies the TGS with the TGS
session key and TGT; the TGS responds with an application session key (ASK) and an encrypted
form of the Application Server's secret key; this secret key is never sent on the network in any
other form.
3. The client has now authenticated itself and can prove its identity to the Application Server by
supplying the Kerberos ticket, application session key, and encrypted Application Server secret
key. The Application Server responds with similarly encrypted information to authenticate itself to
the client. At this point, the client can initiate the intended service requests (e.g., Telnet, FTP,
HTTP, or e-commerce transaction session establishment).

Public Key Certificates

And Certificate Authorities

Principle:
Certificates and Certificate Authorities (CA) are necessary for widespread use of cryptography for e-
commerce applications.

While a combination of secret and public key cryptography can solve the business issues discussed
above, crypto cannot alone address the trust issues that must exist between a customer and vendor in
the very fluid, very dynamic e-commerce relationship.

• How, for example, does one site obtain another party's public key?
• How does a recipient determine if a public key really belongs to the sender?
• How does the recipient know that the sender is using their public key for a legitimate purpose for
which they are authorized?
• When does a public key expire? How can a key be revoked in case of compromise or loss?

Example:
The basic concept of a certificate is one that is familiar to all of us. A driver's license, credit card, or
SCUBA certification, for example, identify us to others, indicate something that we are authorized to
do, have an expiration date, and identify the authority that granted the certificate.

Universal Knowledge Solutions S.A.L.

- 189 -
Let us consider driver's licenses. Suppose this driver has one issued by one US stat. The license
establishes the identity, indicates the type of vehicles that the driver can conduct.

When he drives outside of its US state, the other jurisdictions throughout the U.S. recognize the
authority of this particular state to issue this "certificate" and they trust the information it contains.
Now, when the driver leave the U.S., everything changes.

When he drives in Canada and many other countries, they will accept not the his state license, per se,
but any license issued in the U.S.;

How does it Work?

Contents of an X.509 V3 Certificate.
version number
certificate serial number
signature algorithm identifier
issuer's name and unique identifier
validity (or operational) period
subject's name and unique identifier
subject public key information
standard extensions
certificate appropriate use definition
key usage limitation definition
certificate policy information
other extensions
Application-specific
CA-specific

For purposes of electronic transactions, certificates are digital documents. The specific functions of the
certificate include:
• Establish identity: Associate, or bind, a public key to an individual, organization, corporate
position, or other entity.
• Assign authority: Establish what actions the holder may or may not take based upon this certificate.
• Secure confidential information (e.g., encrypting the session's symmetric key for data
confidentiality).

Typically, a certificate contains a public key, a name, an expiration date, the name of the authority that
issued the certificate (and, therefore, is vouching for the identity of the user), a serial number, any
pertinent policies describing how the certificate was issued and/or how the certificate may be used, the
digital signature of the certificate issuer, and perhaps other information.

A sample abbreviated certificate is shown in the following. This is a typical certificate found in a
browser. When the browser makes a connection to a secure Web site, the Web server sends its public
key certificate to the browser. The browser then checks the certificate's signature against the public key
that it has stored; if there is a match, the certificate is taken as valid and the Web site verified by this
certificate is considered to be "trusted."

Standards
The most widely accepted certificate format is the one defined in International Telecommunication
Union Telecommunication Standardization Sector (ITU-T) Recommendation X.509.

Universal Knowledge Solutions S.A.L.

- 190 -
Rec. X.509 is a specification used around the world and any applications complying with X.509 can
share certificates.

Most certificates today comply with X.509 Version 3 and contain the information listed in Table 2.

Certificate Authority

Certificate authorities are the repositories for public-keys and can be any agency that issues
certificates.

A company, for example, may issue certificates to its employees, a college/university to its students, a
store to its customers, an Internet service provider to its users, or a government to its constituents.

When a sender needs an intended receiver's public key, the sender must get that key from the receiver's
CA. That scheme is straight-forward if the sender and receiver have certificates issued by the same
CA.

Some CAs will be trusted because they are known to be reputable, such as the CAs operated by AT&T,
BBN, Canada Post Corp., CommerceNe. CAs, in turn, form trust relationships with other CAs. Thus, if
a user queries a foreign CA for information, the user may ask to see a list of CAs that establishes a
"chain of trust" back to the user.

Secure Protocols: Pretty Good Privacy

Principle
A family of cryptographic routines for e-mail and file storage applications developed by Philip
Zimmermann. PGP 2.6.x uses RSA for key management and digital signatures, IDEA for message
encryption, and MD5 for computing the message's hash value (RFC 1991).

PGP 5.x (formerly known as "PGP 3") uses Diffie-Hellman/DSS for key management and digital
signatures; IDEA, CAST, or 3DES for message encryption; and MD5 or SHA for computing the

Universal Knowledge Solutions S.A.L.

- 191 -
message's hash value. OpenPGP, described in RFC 2440, is an open definition of security software
based on PGP 5.x.

Composition:
PGP can be used to sign or encrypt e-mail messages with the mere click of the mouse. Depending upon
the version of PGP, the software uses SHA or MD5 for calculating the message hash; CAST, Triple-
DES, or IDEA for encryption; and RSA or DSS/Diffie-Hellman for key exchange and digital
signatures.

When PGP is first installed, the user has to create a key-pair.

• One key, the public key, can be advertised and widely circulated.
• The private key is protected by use of a passphrase.
• The passphrase has to be entered every time the user accesses their private key.

Signed Messages

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Hi Carol.

What was that pithy Groucho Marx quote?

/kess

-----BEGIN PGP SIGNATURE-----

Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBNFUdO5WOcz5SFtuEEQJx/ACaAgR97+vvDU6XWELV/GANjAAgBtUAnjG3
Sdfw2JgmZIOLNjFe7jP0Y8/M
=jUAU
-----END PGP SIGNATURE-----

A PGP signed message. The sender uses their private key; at the destination, the
sender's e-mail address yields the public key from the receiver's keyring.

The slide shows PGP signed message. This message will not be kept secret from an eavesdropper, but
a recipient can be assured that the message has not been altered from what the sender transmitted.

In this instance, the sender signs the message using their own private key. The receiver uses the
sender's public key to verify the signature; the public key is taken from the receiver's keyring based on
the sender's e-mail address. Note that the signature process does not work unless the sender's public
key is on the receiver's keyring.

Encrypted Messages

-----BEGIN PGP MESSAGE-----

Version: PGP for Personal Privacy 5.0
MessageID: DAdVB3wzpBr3YRunZwYvhK5gBKBXOb/m

qANQR1DBwU4D/TlT68XXuiUQCADfj2o4b4aFYBcWumA7hR1Wvz9rbv2BR6WbEUsy
ZBIEFtjyqCd96qF38sp9IQiJIKlNaZfx2GLRWikPZwchUXxB+AA5+lqsG/ELBvRa
c9XefaYpbbAZ6z6LkOQ+eE0XASe7aEEPfdxvZZT37dVyiyxuBBRYNLN8Bphdr2zv

Universal Knowledge Solutions S.A.L.

- 192 -
 z/9Ak4/OLnLiJRk05/2UNE5Z0a+3lcvITMmfGajvRhkXqocavPOKiin3hv7+Vx88
uLLem2/fQHZhGcQvkqZVqXx8SmNw5gzuvwjV1WHj9muDGBY0MkjiZIRI7azWnoU9
3KCnmpR60VO4rDRAS5uGl9fioSvze+q8XqxubaNsgdKkoD+tB/4u4c4tznLfw1L2
YBS+dzFDw5desMFSo7JkecAS4NB9jAu9K+f7PTAsesCBNETDd49BTOFFTWWavAfE
gLYcPrcn4s3EriUgvL3OzPR4P1chNu6sa3ZJkTBbriDoA3VpnqG3hxqfNyOlqAka
mJJuQ53Ob9ThaFH8YcE/VqUFdw+bQtrAJ6NpjIxi/x0FfOInhC/bBw7pDLXBFNaX
HdlLQRPQdrmnWskKznOSarxq4GjpRTQo4hpCRJJ5aU7tZO9HPTZXFG6iRIT0wa47
AR5nvkEKoIAjW5HaDKiJriuWLdtN4OXecWvxFsjR32ebz76U8aLpAK87GZEyTzBx
dV+lH0hwyT/y1cZQ/E5USePP4oKWF4uqquPee1OPeFMBo4CvuGyhZXD/18Ft/53Y
WIebvdiCqsOoabK3jEfdGExce63zDI0=
=MpRf
-----END PGP MESSAGE-----

A PGP encrypted message. The receiver's e-mail address is the pointer to the public
key in the sender's keyring. At the destination side, the receiver uses their own private
key.

Hi Gary,

"Outside of a dog, a book is man's best friend.

Inside of a dog, it's too dark to read."

Carol

The decrypted message.

The slide shows a PGP encrypted message (PGP compresses the file, where practical, prior to
encryption because encrypted files lose their randomness and, therefore, cannot be compressed).

In this case, public key methods are used to exchange the session key for the actual message
encryption using secret-key cryptography. In this case, the receiver's e-mail address is the pointer to
the public key in the sender's keyring; in fact, the same message can be sent to multiple recipients and
the message will not be significantly longer since all that needs to be added is the session key
encrypted by each receiver's private key.

When the message is received, the recipient must use their private key to extract the session secret key
to successfully decrypt the message.

Secure Protocols: Secure Socket Layer (SSL)

Definition
SSL is developed by Netscape Communications to provide application-independent security and
privacy over the Internet. SSL is designed so that protocols such as HTTP, FTP (File Transfer
Protocol), and Telnet can operate over it transparently.

SSL allows both server authentication (mandatory) and client authentication (optional). RSA is used
during negotiation to exchange keys and identify the actual cryptographic algorithm (DES, IDEA,

Universal Knowledge Solutions S.A.L.

- 193 -
RC2, RC4, or 3DES) to use for the session. SSL also uses MD5 for message digests and X.509 public-
key certificates. (Found to be breakable soon after the IETF announced formation of group to work on
TLS.)

How does it Work?

1. URLs specifying the protocol https:// are directed to HTTP servers secured using SSL/TLS. The
client will automatically try to make a TCP connection to the server at port 443. The client initiates
the secure connection by sending a ClientHello message containing a Session identifier,
highest SSL version number supported by the client, and lists of supported crypto and compression
schemes (in preference order).

2. The server examines the Session ID and if it is still in the server's cache, it will attempt to re-
establish a previous session with this client. If the Session ID is not recognized, the server will
continue with the handshake to establish a secure session by responding with a ServerHello
message. The ServerHello repeats the Session ID, indicates the SSL version to use for this
connection (which will be the highest SSL version supported by the server and client), and
specifies which encryption method and compression method to be used for this connection.

3. There are a number of other optional messages that the server might send, including:
a. Certificate, which carries the server's X.509 public key certificate (and, generally, the
server's public key). This message will always be sent unless the client and server have already
agreed upon some form of anonymous key exchange. (This message is normally sent.)
b. ServerKeyExchange, which will carry a premaster secret when the server's
Certificate message does not contain enough data for this purpose; used in some key
exchange schemes.
c. CertificateRequest, used to request the client's certificate in those scenarios where
client authentication is performed.
d. ServerHelloDone, indicating that the server has completed its portion of the key exchange
handshake.

Universal Knowledge Solutions S.A.L.

- 194 -
4. The client now responds with a series of mandatory and optional messages:
a. Certificate, contains the client's public key certificate when it has been requested by the
server.
b. ClientKeyExchange, which usually carries the secret key to be used with the secret key
crypto scheme.
c. CertificateVerify, used to provide explicit verification of a client's certificate if the
server is authenticating the client.

5. TLS includes the change cipher spec protocol to indicate changes in the encryption method. This
protocol contains a single message, ChangeCipherSpec, which is encrypted and compressed
using the current (rather than the new) encryption and compression schemes. The
ChangeCipherSpec message is sent by both client and server to notify the other station that all
following information will employ the newly negotiated cipher spec and keys.

6. The Finished message is sent after a ChangeCipherSpec message to confirm that the key
exchange and authentication processes were successful.

7. At this point, both client and server can exchange application data using the session encryption and
compression schemes.

a. Side Note: It would probably be helpful to make some mention of SSL as it is used today.
Most of us have used SSL to engage in a secure, private transaction with some vendor. The
steps are something like this. During the SSL exchange with the vendor's secure server, the
server sends its certificate to our client software. The certificate includes the vendor's public
key and a signature from the CA that issued the vendor's certificate. Our browser software is
shipped with the major CAs' certificates which contains their public key; in that way we
authenticate the server. Note that the server does not use a certificate to authenticate us!
Instead, we are generally authenticated when we provide our credit card number; the server
checks to see if the card purchase will be authorized by the credit card company and, if so,
considers us valid and authenticated! While bidirectional authentication is certainly supported
by SSL, this form of asymmetric authentication is more commonly employed today since most
users don't have certificates.

b. Microsoft's Server Gated Cryptography (SGC) protocol is another extension to SSL/TLS. For
several decades, it has been illegal to generally export products from the U.S. that employed
secret-key cryptography with keys longer than 40 bits. For that reason, SSL/TLS has an
exportable version with weak (40-bit) keys and a domestic (North American) version with
strong (128-bit) keys. Within the last several years, however, use of strong SKC has been
approved for the worldwide financial community. SGC is an extension to SSL that allows
financial institutions using Windows NT servers to employ strong cryptography. Both the client
and server must implement SGC and the bank must have a valid SGC certificate. During the
initial handshake, the server will indicate support of SGC and supply its SGC certificate; if the
client wishes to use SGC and validates the server's SGC certificate, the session can employ
128-bit RC2, 128-bit RC4, 56-bit DES, or 168-bit 3DES. Microsoft supports SGC in the
Windows 95/98/NT versions of Internet Explorer 4.0, Internet Information Server (IIS) 4.0, and
Money 98.

Other field of Applications

As mentioned above, SSL was designed to provide application-independent transaction security for
the Internet. Although the discussion above has focused on HTTP over SSL (https/TCP port 443),

Universal Knowledge Solutions S.A.L.

- 195 -
 SSL is also applicable to:

Protocol TCP Port Name/Number

File Transfer Protocol (FTP) ftps-data/989 & ftps/990
Internet Message Access Protocol v4 (IMAP4) imaps/993
Lightweight Directory Access Protocol (LDAP) ldaps/636
Network News Transport Protocol (NNTP) nntps/563
Post Office Protocol v3 (POP3) pop3s/995
Telnet telnets/992

VPN

1- Principle

The world has changed a lot in the last couple of decades. Instead of simply dealing with local or
regional concerns, many businesses now have to think about global markets and logistics. Many
companies have facilities spread out across the country or around the world, and there is one thing that
all of them need: A way to maintain fast, secure and reliable communications wherever their offices
are.
Until fairly recently, this has meant the use of leased lines to maintain a wide area network (WAN).

Leased lines, ranging from ISDN (integrated services digital network, 128 Kbps) to OC3 (Optical
Carrier-3, 155 Mbps) fiber, provided a company with a way to expand its private network beyond its
immediate geographic area.

A WAN had obvious advantages over a public network like the Internet when it came to reliability,
performance and security. But maintaining a WAN, particularly when using leased lines, can become
quite expensive and often rises in cost as the distance between the offices increases.

Universal Knowledge Solutions S.A.L.

- 196 -
2- What Makes a VPN?
A well-designed VPN can greatly benefit a company. For example, it can:
• Extend geographic connectivity
• Improve security
• Reduce operational costs versus traditional WAN
• Reduce transit time and transportation costs for remote users
• Improve productivity
• Simplify network topology
• Provide global networking opportunities
• Provide telecommuter support
• Provide broadband networking compatibility
• Provide faster ROI (return on investment) than traditional WAN

3- What features are needed in a well-designed VPN?

It should incorporate:
• Security
• Reliability
• Scalability
• Network management
• Policy management

4- Types of VPN
There are three types of VPN. In the next couple of sections, we'll describe them in detail.

Remote-Access VPN

There are two common types of VPN. Remote-access, also called a virtual private dial-up network
(VPDN), is a user-to-LAN connection used by a company that has employees who need to connect to
the private network from various remote locations. Typically, a corporation that wishes to set up a
large remote-access VPN will outsource to an enterprise service provider (ESP). The ESP sets up a
network access server (NAS) and provides the remote users with desktop client software for their
computers. The telecommuters can then dial a toll-free number to reach the NAS and use their VPN
client software to access the corporate network.
A good example of a company that needs a remote-access VPN would be a large firm with hundreds of
sales people in the field. Remote-access VPNs permit secure, encrypted connections between a

Universal Knowledge Solutions S.A.L.

- 197 -
company's private network and remote users through a third-party service provider.

Site-to-Site VPN
Through the use of dedicated equipment and large-scale encryption, a company can connect multiple
fixed sites over a public network such as the Internet. Site-to-site VPNs can be one of two types:
• Intranet-based - If a company has one or more remote locations that they wish to join in a
single private network, they can create an intranet VPN to connect LAN to LAN.
• Extranet-based - When a company has a close relationship with another company (for
example, a partner, supplier or customer), they can build an extranet VPN that connects LAN to
LAN, and that allows all of the various companies to work in a shared environment.

5- VPN Security
A well-designed VPN uses several methods for keeping your connection and data secure:
• Firewalls
• Encryption
• IPSec
• AAA Server

VPN Security: Firewalls

A firewall provides a strong barrier between your private network and the Internet. You can set
firewalls to restrict the number of open ports, what type of packets are passed through and which
protocols are allowed through. Some VPN products, such as Cisco's 1700 routers, can be upgraded to
include firewall capabilities by running the appropriate Cisco IOS on them. You should already have a
good firewall in place before you implement a VPN, but a firewall can also be used to terminate the
VPN sessions.

VPN Security: Encryption

Encryption is the process of taking all the data that one computer is sending to another and encoding it
into a form that only the other computer will be able to decode. Most computer encryption systems
belong in one of two categories:
• Symmetric-key encryption
• Public-key encryption

VPN Security: IPSec

IPSec has two encryption modes: tunnel and transport. Tunnel encrypts the header and the payload of
each packet while transport only encrypts the payload. Only systems that are IPSec compliant can take
advantage of this protocol. Also, all devices must use a common key and the firewalls of each network
must have very similar security policies set up. IPSec can encrypt data between various devices, such
as:
• Router to router
• Firewall to router
• PC to router
• PC to server

VPN Security: AAA Servers

AAA (authentication, authorization and accounting) servers are used for more secure access in a
remote-access VPN environment. When a request to establish a session comes in from a dial-up client,
the request is proxied to the AAA server. AAA then checks the following:
• Who you are (authentication)
• What you are allowed to do (authorization)
• What you actually do (accounting)

Universal Knowledge Solutions S.A.L.

- 198 -
The accounting information is especially useful for tracking client use for security auditing, billing or
reporting purposes.

6- VPN Technologies
Depending on the type of VPN (remote-access or site-to-site), you will need to put in place certain
components to build your VPN. These might include:
• Desktop software client for each remote user
• Dedicated hardware such as a VPN concentrator or secure PIX firewall
• Dedicated VPN server for dial-up services
• NAS (network access server) used by service provider for remote-user VPN access
• VPN network and policy-management center
Because there is no widely accepted standard for implementing a VPN, many companies have
developed turn-key solutions on their own. In the next few sections, we'll discuss some of the solutions
offered by Cisco, one of the most prevelant networking technology companies.

VPN Concentrator
Incorporating the most advanced encryption and authentication techniques available, Cisco VPN
concentrators are built specifically for creating a remote-access VPN. They provide high availability,
high performance and scalability and include components, called scalable encryption processing
(SEP) modules, that enable users to easily increase capacity and throughput. The concentrators are
offered in models suitable for everything from small businesses with up to 100 remote-access users to
large organizations with up to 10,000 simultaneous remote users.

VPN-Optimized Router
Cisco's VPN-optimized routers provide scalability, routing, security and QoS (quality of service).
Based on the Cisco IOS (Internet Operating System) software, there is a router suitable for every
situation, from small-office/home-office (SOHO) access through central-site VPN aggregation, to
large-scale enterprise needs.

Cisco Secure PIX Firewall

An amazing piece of technology, the PIX (private Internet exchange) firewall combines dynamic
network address translation, proxy server, packet filtration, firewall and VPN capabilities in a single
piece of hardware.
Instead of using Cisco IOS, this device has a highly streamlined OS that trades the ability to handle a
variety of protocols for extreme robustness and performance by focusing on IP.

7- Tunneling
Most VPNs rely on tunneling to create a private network that reaches across the Internet. Essentially,
tunneling is the process of placing an entire packet within another packet and sending it over a
network. The protocol of the outer packet is understood by the network and both points, called tunnel
interfaces, where the packet enters and exits the network.

Tunneling requires three different protocols:

• Carrier protocol - The protocol used by the network that the information is travelling over
• Encapsulating protocol - The protocol (GRE, IPSec, L2F, PPTP, L2TP) that is wrapped
around the original data
• Passenger protocol - The original data (IPX, NetBeui, IP) being carried

Tunneling has amazing implications for VPNs. For example, you can place a packet that uses a
protocol not supported on the Internet (such as NetBeui) inside an IP packet and send it safely over the
Internet. Or you could put a packet that uses a private (non-routable) IP address inside a packet that

Universal Knowledge Solutions S.A.L.

- 199 -
uses a globally unique IP address to extend a private network over the Internet.

Universal Knowledge Solutions S.A.L.

- 200 -