Chapter 13. Security Standards

This book outlines the criteria for rating various operating systems. In the chapters you have already read, we have primarily focused on Windows with some attention to Linux. For most settings these operating systems provide enough security. However, you need to be aware of the various security levels of secure operating systems available. If you are considering operating systems for key servers, you should consider the underlying security rating for that operating system. If your organization intends to do any work with any military, defense, or intelligence agencies, you may be required to have operating systems that reach a specified level of security.

Actual copies of the Orange Book are notoriously difficult to obtain for anyone not working for the U.S. government, which makes understanding the security ratings difficult. The book is not classified; it simply is not widely published. However, you can find excerpts, chapters, and standards from it at the following Web addresses:

The Orange Book Site: www.dynamoo.com/orange/

Department of Defense Orange Book: http://csrc.nist.gov/publications/history/dod85.pdf

The Department of Defense Standard: http://csrc.nist.gov/publications/history/dod85.pdf#search=’the%20orange%20book%20computer%20security

The DoD security categories are designated by a letter ranging from D (minimal protection) to A (verified protection). The Orange Book designations are generally used to evaluate the security level of operating systems rather than entire networks. However, your network will not be particularly secure if the operating systems running on your servers and workstations are not secure. We will take a moment to examine each of these categories.

Discretionary access control, for example access control lists (ACLs), user/group/world protection

Usually for users who are all on the same security level.

Periodic checking of the trusted computing base (TCB). The trusted computing base is the Orange Book’s general term for any computing system.

Username and password protection and secure authorizations database

Protected operating system and system operations mode

Tested security mechanisms with no obvious bypasses

Documentation for user security

Documentation for systems administration security

Documentation for security testing

This list may not be particularly clear to some readers. In order to clarify exactly what C1 security is, let’s look at a few actual excerpts from the Orange Book about C-level and then explain what these excerpts mean:

“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 (for example, passwords) to authenticate the user’s identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user.”

This simply means that users must log in before they can do anything. That may sound obvious, but earlier versions of Windows (3.1 and before) did not require users to log in. This was true of many older desktop operating systems.

“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.”

That sounds pretty vague. It simply means that the operating system has been tested to ensure that it does what its own documentation claims it will do. It says nothing about what level of security the documentation should claim, merely that there must have been testing to ensure the operating system meets the claims made in the documentation. The reader may also wish to note that ADP stands for automatic data processing. It refers to any system that processes data without direct step-by-step human intervention. This may sound like a description of most computer systems, and it is. Remember that the Orange Book was first conceived many years ago.

Object protection can be on a single-user basis, for example, through an ACL or Trustee database.

Authorization for access may be assigned only by authorized users.

Mandatory identification and authorization procedures for users, for example, username/password

Full auditing of security events (the event, date, time, user, success/ failure, terminal ID)

Protected system mode of operation

Documentation as C1 plus information on examining audit information

You will find this level of certification in IBM OS/400, Windows NT/2000/XP, and Novell Netware. Again it might be helpful to explain this level of security by examining what the Orange Book actually says and elaborating on that a bit.

“The TCB shall define and control access between named users and named objects (for example, files and programs) in the ADP system. The enforcement mechanism (for example, 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.”

What this means in plain English is that once a user has logged on and has access to specific objects, that user cannot easily “promote” himself to a higher level of access. It also means that for an operating system to be rated C2, you must be able to assign security permissions to individual users rather than simply to entire groups.

“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.”

This paragraph means that if one user logs on and uses some system object, all of its permissions are revoked before that object can be reused by another user. This prevents a user with lower security access from logging on immediately after a user with higher security access and perhaps reusing some system object the previous user left in memory. It is yet another way to prevent a user from accessing items that he may not be authorized to access.

“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 (for example, 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.”

In short this paragraph means that not only should security activities be able to be logged, but they should also be associated with a specific user. That way an administrator can tell which user did what activity. Again, if you have ever looked at a Windows Security log, you will see this. Figure 13.1 shows an event from a Windows 2000 event log. Note that the individual username is shown.

Mandatory security and access labeling of all objects. The term objects, in this context, encompasses files, processes, devices, and so on.

Auditing of labeled objects

Mandatory access control for all operations

Ability to specify security level printed on human-readable output (for example, printers)

Ability to specify security level on any machine-readable output

Enhanced auditing

Enhanced protection of operating system

Improved documentation

Let us again turn to what the Orange Book actually states about this security level and use that as a guide to better understanding this particular security rating.

“Sensitivity labels associated with each subject and storage object under its control (for example, 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-labeled 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.”

This paragraph tells us that in a B1-rated system there are security levels (label) assigned to every single object (that would include any file and any device) and for every subject (user). No new subject or object can be added to the system without a security level. This means that unlike C1 and C2 systems where such access control is discretionary (i.e., optional), it is impossible to have any subject or object in a B1 system that does not have access control defined. Consider again the Windows 2000 operating system. Many items in that system have restricted access (often restricted only to administrators). This includes the control panel and various administrative utilities. However, some items (such as the accessories) have no access control. In a B1- (or higher) rated system, everything in that system has access control.

These security labels are the real key to B1 security ratings. Much of the Orange Book documentation regarding the B1 rating surrounds how such labels are imported or exported.

“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 (for example, passwords) as well as information for determining the clearance and authorizations or 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.”

Now this paragraph may sound like the same paragraph from the C category indicating that security activities should be audited. However, this goes a bit further. Every action is not only audited along with the user that performed that action, but the users’ access rights/security level are also noted. This provides a clear indication of any user attempting to perform some action that is beyond his security rights.

This level of operating system security can be found on several very high-end systems such as:

HP-UX BLS (a highly secure version of Unix)

Cray Research Trusted Unicos 8.0 (an operating system for the famous Cray research computers)

Digital SEVMS (a highly secure VAX operating system)

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

Improved security testing

Version, update, and patch analysis and auditing

This level of security is actually found in a few operating systems:

Honeywell Multics: This is a highly secure mainframe operating system.

Cryptek VSLAN: This is a very secure component to network operating systems. The Verdix Secure Local Area Network (VSLAN) is a network component that is capable of interconnecting host systems operating at different ranges of security levels allowing a multi-level secure (MLS) LAN operation.

Trusted XENIX: This is a very secure Unix variant.

Examining the Orange Book will give us a better view of the differences between B2 and B1 levels of security. A few paragraphs seem to really illustrate the primary differences:

“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.”

This paragraph tells us that not only must the user be authenticated before accessing any of the system’s resources, but that the communication used to authenticate must be secure. This is particularly important in client server situations. A B2-rated server allows clients to log on only if their log-on process is secure. This means the log-on communication should be encrypted via a VPN or some other method that keeps the username and password secure. Notice that the first two B2-rated operating systems are for distributed environments.

“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.”

In this excerpt we see that if a user is logged on to the system and something should change in either his security level or in the security level of some object he is accessing, that the user will immediately be notified and, if necessary, his access will be changed. In many systems you are probably most familiar with (Windows, Unix, Linux), if a user’s permissions are changed, the changes do not take effect until the next time the user logs on. With a B2-rated system the changes take effect immediately.

ACLs additionally based on groups and identifiers

Trusted path access and authentication

Automatic security analysis

Auditing of security auditing events

Trusted recovery after system down and relevant documentation

Zero design flaws in the TCB and a minimum of implementation flaws

To the best of this author’s knowledge, there is only one B3-certified operating system, Getronics/Wang Federal XTS-300. This is a highly secure Unix-like operating system, complete with a graphical user interface. There are a couple of fascinating segments of the Orange Book’s description of the B3 security rating that help illustrate the differences between B2 and B3.

“The TCB shall define and control access between named users and named objects (for example, files and programs) in the ADP system. The enforcement mechanism (for example, 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.”

This paragraph (note the portion in bold) says that access control is taken to a higher level with B3 systems. In such a system every single object must have a specific list of authorized users and may have a specific list of prohibited users. This goes beyond the C level, where an object may have a list of authorized users. It also goes beyond the lower B ratings with its list of specifically disallowed users.

“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 (for example, file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers and other security relevant events. The TCB shall also be able to audit any override of human-readable output markings. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (for example, 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.”

Again, pay particular attention to the bold section. This paragraph tells us that auditing in a B3 system is taken to a higher level. In such a system not only are all security related events audited, but any occurrence or accumulation of occurrences that might indicate a potential violation of a security policy will trigger an alert to the administrator. This is conceptually similar to an intrusion detection system. However, in this incident it is not simply signs of intrusions that are being monitored but any event or series of events that might lead to any compromise of any part of the operating system’s security.

You can actually find a few A1-certified systems:

Boeing MLS LAN: This is a highly secure and specialized network operating system.

Honeywell SCOMP (Secure Communications Processor): This is a highly secure and specialized network operating system.

FAS Rainbow Series page: www.fas.org/irp/nsa/rainbow.htm

Introduction to the Rainbow Series: www.palowireless.com/wireless/security_rainbow.asp

Below is a list of the books in the series, along with a brief description of each. Some books are more applicable to your study of network defense than others. For those books that are less relevant to our study, the description is briefer. You may think that if you are not directly involved in systems related to defense or intelligence, you do not need to be familiar with these standards. However, consider that when you are trying to secure any network, would it not be useful to consider the security standards and requirements of the most secure systems? Many private companies have done just that and have adopted one or more of these standards for their own use.

Tan Book—A Guide to Understanding Audit in Trusted Systems [Version 2 6/01/88]. This book describes recommended processes for auditing trusted systems. Recall that event auditing is a significant feature of several security classifications in the Orange Book. The Tan Book describes exactly how auditing should be done. This book is a worthwhile read for any security professional.

Bright Blue Book—Trusted Product Evaluation - A Guide for Vendors [Version 1 3/1/88]. As the name indicates, this is a guide for vendors. This will be of use to you only if your company is attempting to market secure systems to the United States Department of Defense.

Orange Book—A Guide to Understanding Discretionary Access Control in Trusted Systems. This section has been examined in great detail in the first portion of this chapter.

Aqua Book—Glossary of Computer Security Terms. Bookstores and the Internet are replete with computer security glossaries. Appendix B of the textbook you are reading right now is such a glossary. The Aqua Book is the Department of Defense computer security glossary. It is worth at least a cursory examination.

Burgundy Book—A Guide to Understanding Design Documentation in Trusted Systems. As the name suggests, this book examines what is required for documentation. As with most government agencies, the standard here is for a lengthy amount of documentation probably much more detailed than most organizations will require.

Lavender Book—A Guide to Understanding Trusted Distribution in Trusted Systems. This book discusses standards for security in distributed systems. In this day of e-commerce it would be quite useful for any security professional to spend some time studying these standards.

Venice Blue Book—Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria. This book describes criteria for evaluating any hardware or software that is to be added to an existing secure system. While the specifics of this particular document are not critical to your study of network defense, the concept is. Recall in Chapter 12 we discussed change control processes. One reason this is so important is that even a very secure system can have its security compromised by the addition of a device or software that is not secure.

Red Book—Trusted Network Interpretation Environments Guideline - Guidance for Applying the Trusted Network Interpretation. In this book you will find criteria for evaluating network security technologies. This is closely related to the material in the Lavender Book.

Pink Book—Rating Maintenance Phase Program Document. In this document you will see the criteria for rating maintenance programs. This again relates back to change control processes discussed in Chapter 12 and is related to the Venice Blue Book. Routine maintenance of a secure system can either enhance or compromise system security, depending on how it is executed.

Purple Book—Guidelines for Formal Verification Systems. For a vendor developing a system it wishes to be rated according to Department of Defense guidelines, this book outlines the process of verifying the security of that system.

Brown Book—A Guide to Understanding Trusted Facility Management [6/89]. Because secure systems must reside in some building/facility, then the management of that facility is of concern to a security professional. This book details guidelines for the management of a trusted facility.

Yellow-Green Book—Writing Trusted Facility Manuals. Anyone familiar with government documents of any type is accustomed to a great deal of paperwork and an excessive amount of manuals. This particular book is a guide to writing manuals.

Light Blue Book—A Guide to Understanding Identification and Authentication in Trusted Systems. In this manual the process of authentication is explored in great detail. This information is critical to you only if you are attempting to create your own authentication process rather than using one of the many existing authentication protocols.

Blue Book—Trusted Product Evaluation Questionnaire [Version-2 - 2 May 1992]. This document is closely related to the Orange Book, as it contains questions that must be answered in order to get an operating system rated according to Orange Book standards.

Grey/Silver Book—Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX System. For readers using Unix this book is of particular value. It examines the standards for choosing specific access control list options in a Unix operating system.

Lavender/Purple Book—Trusted Database Management System Interpretation. As the name suggests, this book details the requirements for a secure database management system. Given that databases are at the heart of all business programming, the security of such database systems is an important issue.

Yellow Book—A Guide to Understanding Trusted Recovery. Should any failure occur (hard drive crash, flood, fire, etc.), you must restore your systems. For secure systems, even such recovery must be done in accordance with security guidelines, which this book outlines.

Forest Green Book—A Guide to Understanding Data Remanence in Automated Information Systems. This particular book covers requirements for the secure storage of data.

Hot Peach Book—A Guide to Writing the Security Features User’s Guide for Trusted Systems. This book is yet another manual on how to write manuals.

Turquoise Book—A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems. In many government agencies or in defense contractor companies, there is a designated security officer with overall responsibilities for security. This book outlines the responsibilities of such an officer. It is not directly relevant to network defense but can provide background information when formulating organizational security policies.

Violet Book—Assessing Controlled Access Protection. In this particular book the reader will find standards related to how to assess access control procedures. Most operating systems (at least C-rated or better) have some sort of access control (discretionary in C-rated systems, mandatory in B-rated systems).

Blue Book—Introduction to Certification and Accreditation. This manual explains the process of achieving Department of Defense certification for a product.

Light Pink Book—A Guide to Understanding Covert Channel Analysis of Trusted Systems [11/93]. One feature of some higher rated systems (B2 and above) is the handling of communication channels. This document discusses analyzing such channels in great detail.

Clearly no one can be expected to study, much less memorize, all of these books. The Orange Book is commonly used, so you should certainly have a basic familiarity with it. Beyond that, simply select the one or two books that are most pertinent to your job role or to your personal research interests, and familiarize yourself with those. The most important thing to gather from this section is what the various books are responsible for. You should know which book to consult for a given purpose.

The Common Criteria originated out of three standards:

ITSEC (Information Technology Security Evaluation Criteria), a European standard used by UK, France, the Netherlands, Germany, and Australia. You can learn more about ITSEC at http://www.iitsec.org/Pages/default.aspx. However, remember that in most cases this has been supplanted by the Common Criteria.

The United States Department of Defense Orange Book.

CTCPEC (Canadian Trusted Computer Product Evaluation Criteria), the Canadian standard. This standard is roughly equivalent in purpose to the Orange Book.

The Common Criteria is essentially a fusion of these three standards. While they can now be applied to any product, the original intent was to outline standards for companies selling computer products for use in defense or intelligence organizations.

As with most things in information technology, the Common Criteria was eventually revised. Version 2.0 of the Common Criteria was released in April 1998. This version of the Common Criteria was adopted as ISO (International Standards Organization) International Standard 15408 in 1999. Subsequent minor revisions of the Common Criteria were also adopted by ISO. The Common Criteria was originally developed to supercede parts of the Rainbow Series and similar standards used in Europe and Canada. However, its use has gone well beyond defense-related applications. The Common Criteria are now often used in private organizational security settings. In fact, a basic knowledge of this standard is part of the CISSP (Certified Information Systems Security Professional) certification test. This certification and others are discussed in detail in Appendix B.

Clearly the Common Criteria is important and widely used, but what exactly does it cover? The Common Criteria (often abbreviated as just CC) defines a common set of security requirements. These requirements are divided into functional requirements and assurance requirements. The CC further defines two kinds of documents that can be built using this common set:

Protection Profiles: This is a document created by a user that identifies user security requirements.

Security Targets: This is a document created by the developer of a particular system that identifies the security capabilities of a particular product.

Frequently, organizations ask for an independent evaluation of a product to show that the product does in fact meet the claims in a particular security target. This evaluation is referred to as the Target of Evaluation, or TOE. The Common Criteria has built-in mechanisms to support these independent evaluations.

The Common Criteria outlines some requirements/levels of security assurance. These levels are usually called Evaluation Assurance Levels (EALs). These EALs are numbered 1 to 7, with higher numbers representing more thoroughly evaluated security. The idea is to rate security products, operating systems, and security on a numeric scale. The criteria for each level are well established and are the same for all parties using the Common Criteria.

It must be stressed that these models are theoretical frameworks that can assist you in guiding your network defense strategy. You can certainly be successful at defending networks without them, but in this book our goal is to give you a well-rounded understanding of network defense.

A system is secure if and only if the initial state is a secure state and all state transitions are secure, then every subsequent state will also be secure, no matter what inputs occur.

In other words if you start out with a secure system, and then every single transaction that occurs that might change the state of the system in any way is also secure, then the system will remain secure. Therefore the Bell-LaPadula model focuses on any transaction that changes the system’s state.

The model divides a system into a serious of subjects and objects. A subject is any entity that is attempting to access a system or data. That usually refers to an application or system that is accessing another system or data within that system. For example, if a program is designed to perform data-mining operations, requiring it to access data, then that program is the subject, and the data it is trying to access is the object. An object, in this context, is literally any resource the user may be trying to access.

The model defines the access control for these subjects and objects. All interactions between any subjects and objects are based on their individual security levels. There are usually four security levels:

Unclassified

Confidential

Secret

Top secret

It is no coincidence that these are the same four classifications the United States military uses. This particular model was originally designed with military applications in mind.

There are two properties that describe the mandatory access in this model. These are the simple-security property and the * property:

Simple-security property (also referred to as ss-property): This means that a subject can read an object only if the security level of the subject is higher than or equal to the security of the object. This is often referred to as read-down. What this means is that if the subject has a secret level of security it can read only secret, confidential, and un-classified materials. That subject cannot read top secret material.

* Property (also referred to as the star property): A subject can write on an object only if the security level of the object is higher than or equal to the security level of the subject. This is often referred to as write up. It may seem odd to allow a system to write to a higher security level than itself; however, the key is to use a broad definition for the word write. What this means is that a system that is classified secret cannot output less than secret. This prevents a secret system from classifying its output as confidential or unclassified.

The Bell-LaPadula model also has a third rule that is applied to discretionary access control (DAC), called the Discretionary Security Property. Discretionary access is defined as the policies that control access based on named users and named objects.

Discretionary security property (also called ds-property): Each element of the set of current accesses, as well as the specific access mode (for example, read, write, or append) is included in the access matrix entry for the corresponding subject-object pair.

The Biba Integrity model consists of three parts. The first two are very similar in wording and concept to the Bell-LaPadula model but with wider applications.

A subject cannot execute objects that have a lower level of integrity than the subject.

A subject cannot modify objects that have a higher level of integrity.

A subject may not request service from objects that have a higher integrity level.

Essentially this last item means that a subject that has a confidential clearance cannot even request a service from any object with a secret or top secret clearance. The idea is to prevent subjects from even requesting data from objects with higher security levels.

Well-formed transaction

Separation of duties

Well-formed transaction simply means users cannot manipulate or change the data without careful restrictions. This prevents transactions from inadvertently altering secure data. Separation of duties prevents authorized users from making improper modifications, thus preserving the external consistency of data.

The Clark-Wilson model uses integrity verification and transformation procedures to maintain internal and external consistency of data. The verification procedures confirm that the data conforms to the integrity specifications at the time the verification is performed. What this means in simple terms is that this model explicitly calls for outside auditing to ensure that the security procedures are in place and effective. The model essentially encompasses three separate but related goals:

Prevent unauthorized users from making modifications

Prevent authorized users from making improper modifications

Maintain internal and external consistency

The Chinese Wall Model was proposed by Brewer and Nash. This model seeks to prevent information flow that can cause a conflict of interest. For example, write access is granted only if no other object containing unsanitized information can be read. Unlike Bell-LaPadula, access to data is not constrained by attributes of the data in question but by what data the subject already holds access rights to. Also unlike Bell-LaPadula and Biba, this model originates with business concepts rather than military concepts. With this model sets of data are grouped into “conflict of interest classes” and all subjects are allowed access to at most one dataset belonging to each such conflict of interest class.

The basis of this model is that users are allowed access only to information that is not considered to be in conflict with any other information that they already possess. From the perspective of the computer system, the only information already possessed by a user must be information that the user has previously accessed.

Users

States

Commands

Output

A state machine model considers a system to be in a secure state when there is no instance of security breach at the time of state transition. In other words, a state transition should occur only by intent; otherwise, it is a security breach. Any state transition that is not intentional is considered a security breach.

Creating incentives for developing a meaningful use of electronic health records

Changing the liability and responsibilities of business associates

Redefining what a breach is

Creating stricter notification standards

Tightening enforcement

Raising the penalties for a violation

Creating new code and transaction sets

The legislation affects not only the financial side of corporations, but also the IT departments whose job it is to store a corporations electronic records. The Sarbanes-Oxley Act states that all business records, including electronic records and electronic messages, must be saved for “not less than five years.” The consequences for non-compliance are fines, imprisonment, or both

1.1 Requirement: All merchants must protect cardholder information by installing a firewall and router system. Installing a firewall system provides control over who can access an organization’s network and a router is a device that connects networks, and is therefore, PCI compliant.

Program the standards of firewall and router to:

Perform testing when configurations change

Identify all connections to cardholder information

Review configuration rules every six months

Configure firewall to prohibit unauthorized access from networks and hosts and deny direct public access to any information about the cardholder. Additionally, install firewall software on all computers that access the organization’s PCI compliance network.

1.2 Requirement: Change all default passwords. Default passwords provided when first setting up software are discernible and can be easily discovered by hackers to access sensitive information.

2.1 Requirement: Cardholder data is any personal information about the cardholder that is found on the payment card and can never be saved by a merchant—this includes preserving encrypted authentication data after authorization. Merchants can only display the maximum of the first six and last four digits of the primary account number (PAN). If merchant stores PAN, ensure that the data is secure by saving it in a cryptographic form.

2.2 Requirement: It is required that all information is encrypted when transmitting the data across public networks, such as the Internet, to prevent criminals from stealing the personal information during the process.

3.1 Requirement: Computer viruses make their way onto computers in many ways, but mainly through e-mail and other online activities. The viruses compromise the security of personal cardholder information on a merchant’s computer, and therefore anti-virus software must be present on all computers associated on the network.

3.2 Requirement: In addition to anti-virus software, computers are also susceptible to a breach in the applications and systems installed on the computer. Merchants must install vendor-provided security patches within a month of their release to avoid exposing cardholder data. Security alert programs, scanning services, or software may be used signal the merchant of any vulnerable information.

4.1 Requirement: As a merchant, you must limit the accessibility of cardholder information. Install passwords and other security measurements to limit employees’ access to cardholder data. Only employees who must access the information to complete their job are allowed to access the information.

4.2 Requirement: In order to trace employees’ activities when accessing sensitive information, assign each user an unreadable password used to access the cardholder data.

4.3 Requirement: Monitor the physical access to cardholder data; do not allow unauthorized persons the opportunity to retrieve the information by securing printed information as well as digital. Destroy all outdated cardholder information. Maintain a visitor log and save the log for at least three months.

5.1 Requirement: Keep system activity logs that trace all activity and review daily. The information stored in the logs is useful in the event of a security breach to trace employee activities and locate the source of the violation. Record entries reflect at a minimum: the user, event, date and time, success or failure signal, source of the affected data, and the system component.

5.2 Requirement: Each quarter, use a wireless analyzer to check for wireless access points to prevent unauthorized access. Also, scan internal and external networks to identify any possible vulnerable areas in the system. Install software to recognize any modification by unauthorized personnel. Additionally, ensure that all IDS/IPS engines are up to date.

If you process credit cards it is imperative that you be in compliance with this law.

The Common Criteria is another series of criteria formed by a merger of the criteria used by several different nations. This Common Criteria is also used to evaluate the security of systems, particularly systems that are intended for use by defense- or intelligence-related organizations.

Security can also be viewed from the perspective of different models. The Bell-LaPadula model, the Clark-Wilson model, and the Biba Integrity model all view data access as a relationship between subjects and objects. These models originated in the defense industry. The Chinese Wall model, on the other hand, originated in private business and views information security from a conflict of interest perspective. Finally, we examined the state machine model, which concerns itself with system transitions from one state to another.

A. evaluating programs for security levels

B. evaluating overall security of networks

C. evaluating security of operating systems

D. assessing the security of firewalls

2. To which of the following does the C2 rating apply?

A. most firewalls

B. Windows

C. Honeywell Multics

D. networks with appropriate security

3. Mandatory access over all objects and devices is required at what level of security rating?

A. C2

B. B1

C. B2

D. A2

4. Which operating systems qualify for an A2 rating?

A. Honeywell SCOMP

B. Trusted XENIX

C. Windows 2000

D. None

5. Which book in the Rainbow series would you consult to look up a particular security term?

A. Orange Book

B. Aqua Book

C. Pink Book

D. Red Book

6. If you wanted to study methods for verification of trusted systems, which book in the Rainbow series should you consult?

A. Purple Book

B. Orange Book

C. Red Book

D. Blue Book

7. What Canadian standard was used as one basis for the Common Criteria?

A. ITSEC

B. Orange Book

C. CTCPEC

D. CanSec

8. The Common Criteria applies mostly to what types of system?

A. Home user systems

B. Military/intelligence systems

C. Business systems

D. Commercial systems

9. What is an EAL?

A. Evaluation authority level

B. Execution assurance load

C. Execution authority level

D. Evaluation assurance level

10. Which of the following models focuses on any transaction that changes the system’s state?

A. Biba Integrity

B. ITSEC

C. Clark-Wilson

D. Bell-LaPadula

11. What does the concept of “write up” mean?

A. Writing files to a secure location

B. Sending data to an object at a higher security level

C. Documenting security flaws

D. Logging transactions

12. Which of the following subject-object models introduced the element of programs?

A. Bell-LaPadula

B. Chinese Wall

C. Clark-Wilson

D. Biba Integrity

13. What is a Chinese wall, in the context of business practices?

A. A barrier to information flow within an organization

B. A highly secure network perimeter

C. A barrier to information flow between organizations

D. An A2-rated network perimeter

14. Which of the following models is based on the concept of conflict of interest?

A. Biba Integrity

B. State Machine

C. Chinese Wall

D. Bell-LaPadula

15. Which of the following models considers a system to be in a secure state when there is no instance of security breach at the time of state transition?

A. Clark-Wilson

B. State Machine

C. Bell-LaPadula

D. Chinese Wall

1. Pick an Orange Book level C2 or better.

2. Select an operating system that matches this particular level.

3. Using the Orange Book guidelines and the documentation for that operating system (you may even find this online), identify specific features of that operating system that satisfy the Orange Book level.

Exercise 13.2: Using the Aqua Book

1. Using the Aqua Book, find the definitions for the following terms.

DAC

entrapment

environment

hand shaking

You can find the Aqua Book online at www.fas.org/irp/nsa/rainbow/tg004.htm.

Exercise 13.3: Using the Blue Book

1. Using the Blue Book, found at www.fas.org/irp/nsa/rainbow/tg019-2.htm, define the following:

subject

object

Exercise 13.4: Applying the Common Criteria

1. Using the Web or other resources, find out what the Common Criteria version 2.1’s guiding philosophy is. (Hint: It is clearly stated as such in the CC documentation.)

2. Find some examples of organizations that use the Common Criteria.

3. What are some advantages and disadvantages of the Common Criteria?

4. What situations are most appropriate for the Common Criteria?

Exercise 13.5: The Biba Integrity Model

1. Using the Web or other resources, identify the company that created the Biba Integrity model. (Hint: Web Searches on Biba Integrity model will reveal Web sites that include this detail.)

2. What was the original purpose of the development of this model?

3. Identify companies or organizations that use this model today.

4. What are some advantages and disadvantages of this model?

5. What situations are most appropriate for this model?

Project 13.1: Applying ITSEC

Using various resources including Web sites listed below, find the following information about ITSEC.

Is the system still being used?

If so, where?

On what areas of security does the system focus?

What are some advantages and disadvantages of this system?

The following Web sites may help:

IT Security Dictionary: http://www.amazon.com/The-Information-Security-Dictionary-Engineering/dp/1441954473

The Information Warfare Site: www.iwar.org.uk/comsec/resources/standards/itsec.htm

ITSEC Criteria: www.boran.com/security/itsec.htm

Project 13.2: CTCPEC

Using various resources including Web sites listed below, look up information on CTCPEC, and find answers to the following questions.

Is the system still being used?

If so, where?

On what areas of security does the system focus?

What are some advantages and disadvantages of this system?

The following Web sites may help:

Computer Security Evaluation FAQ: www.opennet.ru/docs/FAQ/security/evaluations.html

Canadian Communications Security: http://www.acronymfinder.com/Canadian-Trusted-Computer-Product-Evaluation-Criteria-(CTCPEC).html

Project 13.3: The Common Criteria

Using the Web and other resources, write a brief essay on the Common Criteria. Feel free to elaborate on areas that interest you, but your paper must address the following questions:

What is the current version being used?

When was it released?

How does this version define the scope of security?

What industry certifications use the common criteria?