Data Security

Datta Securiitty Da a Secur y

Conttentt descriipttiion Con en descr p on

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 documents are left on an empty desk

No rule on accessing outside network through modems

Some users are using inadequate (too easy) password

Who is responsible for patching software bug is not 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 nondisclosure 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 securityrelated 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 preestablished 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

FOREWORD

DECEMBER 1985

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 securityrelevant 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 securityrelevant 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 humanreadable 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 nonlabelled 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 humanreadable 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 nonhierarchical 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 nonUniversal 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 humanreadable 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 securityrelevant 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 nonlabelled 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 humanreadable 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 nonhierarchical 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 nonhierarchical 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 humanreadable 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 nonlabelled 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 humanreadable 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 nonhierarchical 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 nonhierarchical 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 humanreadable 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-toknow 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. 7100]) 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 governmentdeveloped 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 securityrelevant 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 securityrelevant 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 humanreadable 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 nonhierarchical 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 onsite 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. Nonsecurity 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: BellLaPadula 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 humanreadable) 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. 204208. 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
Keyboard operation error Hardware failure

Vulnerabilities
Inadequate manual

Possible loss

Illegal procedure by employee

Illegal access from remote site

Building break-in

Interruption of service due to system shutdown Inadequate Interruption of maintenance service due to system shutdown Inadequate training Loss of credit and inadequate log compensation for setting damage caused by leakage personal information Software bug Data alteration <= loss of credit recovery cost (monetary &time ( 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 risk

TREAT

TERMINATE

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 Approach Approach Follow-up Approach Informal 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 gov.

Foreign Corp.

Independent US. Disgruntled 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, PCcillin, 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

B
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 Internet
1*ICMP ECHO

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, cablemodem, 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 Connected to the Internet

FTP

The 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 Network

Firewall

Router

Internet

Screened Subnet

Internal Network

Router

FireWall

Router

Internet

DMZ (De-Militarized Zone)

Internal Network

Router

FireWall

Router

Internet

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 256bit 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: Input character string: Input bit string: Output bit string: 1100101 0100100 1001001 0011101 0110101 0101011 1101100 0011010 GoAggies 11100010 10010110 10011111 00101001 11110110 10100110 11110010 00000011 10000010 11100110 11100110 11001110 10000000 10000001 01011011 00101111

Universal Knowledge Solutions S.A.L. - 162 -

ùO••Ú”Àô Output 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 Rblock 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 32bit 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 16 (Same Text of 16 Slide) 16 the

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 S1 16 S52

PlainText Block (64 bits) 16 P1 16 P2 16 P3 16 P4

6. The functions used to computer the ciphertext are: XOR, + (modulo 216), and * (modulo 216+1):

Keys 16 S1 16 S52

XOR

+ (mod 216)

* (mod 216+1)

Plain Text Block (64 bits) 16 P1 16 P2 16 P3 16 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 S1 (1) Inputs p1 * s1 p2 + s2 p3 + s3 p4 * s4 d1 d2 d3 d4 d5 d6 1 Round d8 * s6 d7 + d9 d9 d10
st

16 S52

(4)

(2) (3)

d1 XOR d3 d2 XOR d4 d5 * s5 d6 + d7 d7 d8

(5)

d1 XOR d9 d11 d3 XOR d9 d12 d2 XOR d10 d13 d4 XOR d10 d14 Outputs

PlainText Block (64 bits) 16 P1 16 P2 16 P3 16 P4

Keys 16 S1 (1) Inputs d11 * s7 d15 d13 + s8 d16 d12 + s9 d17 d14 * s10 d18 d11 XOR d12 d13 XOR d14 d19 * s11 d20 + d21 d21 d22 d19 d20 2 Round d22 * s12 (4) d21 + d23 d23 d24 d25 d26 d27 d28
nd

16 S52

(2) (3)

d11 XOR d23 (5) d13 XOR d23 d12 XOR d24 d14 XOR d24

Outputs Text Block (64 bits) 16 P1 16 P2 16 P3 16 P4

Universal Knowledge Solutions S.A.L. - 170 -

Keys 16 S1 3 Round Inputs s13, s14, s15, s16, s17, s18 d29, d30, d31, d32 Outputs
rd

16 S52

PlainText Block (64 bits) 16 P1 Keys 16 bits S1 4 Round
th

16 P2

16 P3

16 P4

16 bits S52

s19, s20, s21, s22, s23, s24 d33, d34, d35, d36

PlainText Block (64 bits) 16 bits P1 16 bits P2 16 bits P3 16 bits P4

Universal Knowledge Solutions S.A.L. - 171 -

Keys 16 S1 5 Round
th

16 S52

s25, s26, s27, s28, s29, s30 d37, d38, d39, d40

PlainText Block (64 bits) 16 P1 Keys 16 S1 6 Round
th

16 P2

16 P3

16 P4

16 S52

s31, s32, s33, s34, s35, s36 d41, d42, d43, d44

PlainText Block (64 bits) 16 P1 16 P2 16 P3 16 P4

Universal Knowledge Solutions S.A.L. - 172 -

Keys 16 S1 7 Round
th

16 S52

s37, s38, s39, s40, s41, s42 d45, d46, d47, d48

PlainText Block (64 bits) 16 P1 Keys 16 S1 8 Round
th

16 P2

16 P3

16 P4

16 S52

s43, s44, s45, s46, s47, s48 d49, d50, d51, d52 e1, e2, e3, e4

PlainText Block (64 bits) 16 P1 16 P2 16 P3 16 P4

Universal Knowledge Solutions S.A.L. - 173 -

Keys 16 S1 e1 * s49 e2 * s50 e3 * s51 e4 * s52 PlainText Block (64 bits) 16 P1 16 P2 16 P3 16 P4 c1 c2 c3 c4 16 16 16 16 CipherText Block 16 S52

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... Choose a large random number, x Send to Bob: X = gx mod n Compute: KA = Yx mod n

Bob... Choose a large random number, y Send to Alice: Y = gy mod n Compute: KB = Xy mod n

Alice... Choose x=2 Send to Bob: X = 32 mod 7 = 2 KA = 62 mod 7 = 1

Bob... Choose y=3 Send to Alice: Y = 33 mod 7 = 6 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 straightforward. 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 -

•

•

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

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 (465bit) 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 hostto-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 ecommerce 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, TripleDES, 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 publickey 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 reestablish 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 File Transfer Protocol (FTP) Internet Message Access Protocol v4 (IMAP4) Lightweight Directory Access Protocol (LDAP) Network News Transport Protocol (NNTP) Post Office Protocol v3 (POP3) Telnet TCP Port Name/Number ftps-data/989 & ftps/990 imaps/993 ldaps/636 nntps/563 pop3s/995 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 -