Chapter 13

Security Standards

The framework component of COBIT is one of the aspects of the standard that makes it relatively easy to integrate other standards. This component is rather general and requires that organizations develop good practices related to their business requirements. “Good practices” is a broadly defined term. In this component of COBIT, it would be appropriate to integrate any standards that are pertinent to the organization in question. For example, a company that processes credit cards would integrate the PCI DSS standard in the framework component of COBIT. Then the organization would develop practices based on the PCI DSS standard. This illustrates not only the fact that COBIT is flexible and can be integrated with many standards, but that those standards are not in and of themselves complete approaches to cyber security. The fact that any of these standards would accommodate only one part of the COBIT framework is indicative of the narrow focus of these IT standards.

The next component of COBIT is process descriptions. While this is applicable to any network environment, it goes beyond existing standards such as HIPAA and PCI DSS, both of which will be discussed later in this chapter. This component requires the organization to clearly describe all business processes. This is a critical early step, because one cannot effectively approach security for any organization until one has a firm grasp on the processes of that organization.

Process descriptions in COBIT need to be detailed. These descriptions will include all inputs to a given process as well as expected outputs. Every process within the organization must be described. This detailed description provides a guide to the security needs of that process. For example, if a given process is to process credit card information, understanding the inputs and outputs will help determine the security controls that would be appropriate.

The third component of COBIT are control objectives. This is another aspect of COBIT that goes beyond security standards, and instead provides a framework for information assurance. This component requires the organization to establish clear objectives for each security control. Whether that control is administrative or technological in nature, there must be a clearly articulated objective for the control. Without such objectives, it is impossible to evaluate the efficacy of a security control.

The more specific and detailed the objectives are the more effective they can be. One example of a control objective would be the implementation of an antivirus software solution. A generic objective would be to simply state the objective is to mitigate the risk of malware. A more detailed objective would be to target a 20% reduction either in the frequency or deleterious impact of malware outbreaks within the organization’s network. The more precise the objective is, the easier it will be to measure and improve performance.

The control objectives lead naturally to management guidelines, the fourth component of COBIT. This component requires management to establish responsibility for achieving security goals, and implements methods to measure performance of security controls. It is noteworthy that management guidelines are fourth in the COBIT components. Only after addressing the three previous components is it possible to develop effective management guidelines. Without clear control objectives, an understanding of business processes, and similar information, it is difficult to manage.

Finally, COBIT includes maturity models. Maturity models examine any process from the point of view of how developed that process is. Essentially, each individual security process is first assessed to determine how mature that process is. Maturity is defined as how that control is performing against objectives. Then, over time, the security process is evaluated to determine if it is maturing and improving. As an example, a policy regarding passwords might initially be developed based on generic guidelines. Then later, the policy could be revised in light of events within the organization, published standards, or increasing understanding of the security personnel. This process would then be said to be maturing.

ISO/IEC 15408: The Common Criteria for Information Technology Security Evaluation

ISO/IEC 25000: Systems and Software Engineering

ISO/IEC 27000: Information technology — Security Technology

ISO/IEC 27001: Information Security Management

ISO/IEC 27005: Risk Management

ISO/IEC 27006: Accredited Certification Standard

ISO/IEC 28000: Specification for security management systems for the supply chain

ISO 27002: Information Security Controls

ISO 27003: ISMS Implementation

ISO 27004: IS Metrics

ISO 27005: Risk management

ISO 27006: ISMS certification

ISO 27007: Management System Auditing

ISO 27008: Technical Auditing

ISO 27010: Inter-organization communication

ISO 27011: Telecommunications

ISO 27033: Network security

ISO 27034: Application security

ISO 27035: Incident Management

ISO 27036: Supply chain

ISO 27037: Digital forensics

ISO 27038: Document reduction

ISO 27039: Intrusion prevention

ISO 27040: Storage security

ISO 27041: Investigation assurance

ISO 27042: Analyzing digital evidence

ISO 27043: Incident Investigation

1. Computer security supports the mission of the organization.

2. Computer security is an integral element of sound management.

3. Computer security should be cost-effective.

4. System owners have security responsibilities outside their own organizations.

5. Computer security responsibilities and accountability should be made explicit.

6. Computer security requires a comprehensive and integrated approach.

7. Computer security should be periodically reassessed.

8. Computer is security is constrained by societal factors.

Phase 1: Initiation. At this point the organization is looking into implementing some IT security service, device, or process.

Phase 2: Assessment. This phase involves determining and describing the organization’s current security posture. It is recommended that this phase use quantifiable metrics.

Phase 3: Solution. This is where various solutions are evaluated and one or more are selected.

Phase 4: Implementation. In this phase the IT security service, device, or process is implemented.

Phase 5: Operations. Phase 5 is the ongoing operation and maintenance of the security service, device, or process that was implemented in phase 4.

Phase 6: Closeout. At some point, whatever was implemented in phase 4 will be concluded. Often this is when a system is replaced by a newer and better system.

STEP 1. System Characterization

STEP 2. Threat Identification

STEP 3. Vulnerability Identification

STEP 4. Control Analysis

STEP 5. Likelihood Determination

STEP 6. Impact Analysis

STEP 7. Risk Determination

STEP 8. Control Recommendations

STEP 9. Results documentation

Defense Information Assurance Certification and Accreditation Process (DIACAP) was the DoD procedure for identifying, implementing, validating, certifying, and managing IA capabilities and services, expressed as IA controls, and authorizing the operation of DoD ISs. It also describes the processes for configuration management of DoD IA controls and supporting implementation materials. DIACAP was replaced by RMF.

The 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. Most Windows Systems today would be C2. 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.

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.

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.

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

This paragraph tells us that in a B1-rated system there are security levels (labels) 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 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.

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 user’s 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:

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.

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.

This paragraph 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.

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.

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. The textbook you are reading right now includes 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 not used today, but it still is a valuable view of how systems security works, 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 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/ITSicherheitskriterien/itsec-en_pdf.pdf?__blob=publicationFile. 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. The idea of the Common Criteria is, as the name suggests, to have common criteria for security: common, as in applicable to a wide range of organizations and industries.

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 Standard 15408 in 1999. Subsequent minor revisions of the Common Criteria were also adopted by ISO. The Common Criteria was originally developed to supersede 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.

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 Profile: This is a document created by a user that identifies user security requirements.

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

Security Functional Requirements: Specify individual security functions that a particular product should provide.

Security Assurance Requirements: Describe what measures are taken during the development (and eventual evaluation) of a product to ensure that it actually complied with the security functionality.

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. Essentially the EALs are based on the security targets, security functional requirements, and security assurance requirements described earlier in this section.

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

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 corporation’s 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.

Throughout the 1970s and early 1980s, the frequency and severity of computer crimes increased, as we have seen in the preceding two chapters. In response to this growing problem, the Comprehensive Crime Control Act of 1984 was amended to include provisions to specifically address the unauthorized access and use of computers and computer networks. These provisions made it a felony offense to access classified information in a computer without authorization. They also made it a misdemeanor offense to access financial records in a computer system.

However, these amendments were not considered in and of themselves to be adequate. Thus during 1985, both the House and the Senate held hearings on potential computer crime bills. These hearings eventually culminated in the Computer Fraud and Abuse Act (CFAA), enacted by Congress in 1986, which amended 18 U.S.C. § 1030. The original goal of this act was to provide legal protection for computers and computer systems that were in one of the following categories:

Under direct control of some federal entity

Part of a financial institution

Involved in interstate or foreign commerce

As you can see, this law was aimed at protecting computer systems that came within the federal purview. This act made several activities explicitly criminal. First and foremost was accessing a computer without authorization in order to obtain any of the following types of information:

National security information

Financial records

Information from a consumer reporting agency

Information from any department or agency of the United States

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:

1. Perform testing when configurations change

2. Identify all connections to cardholder information

3. 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 a 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 to 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 standard.

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.