Need today 2 hours

Security Architecture

Week3Part1-ISrevisionSu2013

Security Architecture

Security Architecture relates to generally accepted principles, practices and standards that are used to design, implement, operate and test components of a system to ensure they comply with security requirements. Components include operating systems, applications, subsystems and networks that are related to security.

One could argue that this lesson should be the first lesson of the course; however I wanted to discuss some fairly common operational concepts with pragmatic examples before delving into architecture which can be a somewhat abstract topic.

Architecture issues and concepts should support the tenets of the CIA Triad (Confidentiality, Integrity and Availability). Many of the practices and procedures involved with security architecture are derived from computer science research and implementations that have been used in a broad range of fields. The practices and procedures have been sharpened to be security centric.

Trusted Computing Base

Trusted Computing Base (TCB) refers to all of the hardware, software and firmware components that contribute to the security of the system. A TCB can consist of any number of components that taken together enforce a security policy over a system. The smaller the number of components (hardware, software, and firmware) that comprise the TCB the easier it is to verify the correctness of the TCB through testing and examination using both manual and automated techniques. Verification of the TCB ultimately has to happen on the implemented system. However, at different stages of the system design and development it is beneficial to be able to verify the TCB by using models, prototype code, beta releases.

Being able to test ideas and concepts before building the final product makes sense for more than just the TCB in an information system. Testing and validation of concepts makes sense for anything that would be expensive to build in terms of time and resources. This is not to say that testing and verification on the final product does not need to occur, it absolutely does. Performing incremental testing and verification along the development process finds problems, fleshes out concepts and builds confidence in the final product.

The TCB must be verified for government and some commercial systems. In time we will discuss standards and criteria that guide the verification process. Ensuring that the components that comprise the TCB are simple and small makes a lot of sense.

To implement protection access to objects should be isolated. Having a particular object that is part of the TCB accessed by one procedure is a lot more secure than having the object accessed by many procedures. Access to these security objects is controlled through a reference monitor. A reference monitor can exist in an abstract machine or an actual implementation.

The reference monitor has to have the following attributes:

· Mediates every access to an object that is part of the TCB.

· Completely isolated from tampering, modification by any other component in the system

· All operations are verifiable. Isolation from tampering, either malicious or error is verifiable.

The entities that are dealt with in a reference monitor are:

1. Object: any resource that needs to have access to it controlled. Examples are memory, processes, devices, files.

2. Subject: any user or process that accesses an object.

A security kernel is an implementation of a reference monitor. The security kernel is that part of an operating system that accesses objects (components) that contribute to the TCB. For some systems this could be the entire operating system, but in most cases the operating system is defined into layers, or rings that have security code segmented into modules.

Rings of Trust

The TCB is typically illustrated by using concentric circles. Each ring represents a ring of trust. The outer rings have the least trust. Each inner ring has more trust associated with it than any outer ring. The inner most ring has the highest level of trust. A user or process that moves from an outer ring to an inner ring is increasing their trust level. Conversely, moving from inner to outer rings you are decreasing the trust level.

Ring 1

Ring 2

Ring 0

More

Trust

Less

Trust

The concept of rings of trust has been used for decades for operating system and hardware systems. Several operating systems have two rings denoted as user and supervisor, also called kernel. User programs run in the “user ring of trust”. The user program cannot explicitly gain access to the services provided by the kernel. If a user process requires the services of the kernel a well defined interface will transition control into the kernel.

The types of operations implemented in the kernel are functions to support the operating system, such as file system (read, write, delete), memory management (paging, swapping), process management (state transitions) and other functions.

User

Kernel

More

Trust

Less

Trust

You need to differentiate between rings of trust in the hardware and rings of trust in the software. There is not a 1:1 mapping between their use in software and hardware. The Intel X86 machine architecture implements several rings of trust. Several operating systems that run on the X86 architecture (Windows, Linux, UNIX) implement rings of trust however they do not fully exploit all of the rings of trust that are implemented in the hardware. For example, UNIX or Linux operating systems have two rings of trust, user mode or kernel (supervisor) mode. Despite the hardware having more rings the software does not make use of it.

Example Operating System Implementations

UNIX/Linux has two (2) rings of trust. They are known as user and kernel mode.

Because there are only two modes of access this is sometimes referred to as an ALL or NOTHING model for access. It is more accurate to refer to it as ALL or LIMITED access. The point here is that a typical user has user access. If there is some operation that needs to be done which requires more privileges than kernel access needs to be granted. A user with kernel access has access to every aspect of the system. This opens up the system to enormous security risk from malicious or accidental actions.

Multics (Multiplexed Information and Computing Service) is a mainframe timesharing operating system developed in 1965 and used until 2000. It was a joint development effort involving MIT (Massachusetts Institute of Technology), GE (General Electric) and Bell Labs. Multics was designed from the bottom up with security in mind. Multics implemented eight (8) rings of trust. Many of the concepts implemented in Multics are in use in today’s operating systems. The hierarchical file system, virtual memory and security concepts were implemented in Multics, as well as other features. Learning about Multics is recommended for understanding the history of computing as well as understanding security concepts.

VMS (Virtual Memory System) was implemented by Digital Equipment Corporation. It was first designed to run on the VAX (Virtual Address eXtension) machine. VMS implemented four (4) access modes. This provided increased granularity of access over the UNIX scheme, without the complexity of the 8 ring model in Multics. The 4 rings starting from the inside (most privileged) are:

Kernel – Operating system services and system wide protected data structures. (most privileged)

Executive – File system services and some system services.

Supervisor – Command language interpreter.

User – User mode programs. (least privileged)

Movement from a less privileged mode to a more privileged mode can only be done by executing an explicit instruction. Very few users are explicitly granted the privilege to move from user mode to more privileged inner modes. However, when a user with simple user mode privileges needs certain privileged services the system will on the users behalf execute in a more privileged mode when required.

Trust Concepts Across Systems

We started this section with the following definition:

Trusted Computing Base (TCB) refers to all of the hardware, software and firmware components that contribute to the security of the system.

A system (general term) can be considered to be one system, multiple systems, internet, extranet or intranet of systems. The implementation of the mechanisms that support the TCB across the different topologies may differ, but the concepts needing to be supported are the same.

In a network there are machines that are used for different purposes. Some machines have minimal security implemented on them while other machines are very secure. The network of these machines form a trust hierarchy where the most trusted or secure machine is in the center ring, and less trusted systems are in outer rings. The concept of trusted systems in a TCB is the same as trusted components within one system.

“Mid”

Trus

ted

Untrusted

Systems

Most

Trusted

More

Trust

Less

Trust

Summary

In this section we discussed what the TCB is and why it is important to a secure environment. In the next section we will review some of the elements that comprise the TCB in actual implementations. We will also review standards that are used to guide the development of the TCB for various systems.

Mechanisms in TCB

Week3Part2-ISrevisionSu13

An implementation of a TCB requires adhering to some fundamental principles. Depending on the type of system being implemented different programming methodologies and hardware implementations may be used.

The text Information Security – Principles and Practices by Merkow and Breithaupt does a good job summarizing some of these concepts. In this section we will reference this text and embellish on some of the concepts.

The concepts we will discuss guide the design of systems and are carried through the implementation.

Least Privilege: This is the concept that a particular user or process should only possess the minimal privilege required to get their job done. Adhering to a concept of least privilege will minimize the occurrence of damage occurring to a system, either accidentally or maliciously.

Process Isolation: The concept that a process can run in isolation from any other process. This means there is no interference between two or more processes that are running on the same system. Further, if two or more processes are running on different systems and sharing common resources on a third system there is no interference between these systems.

Note: The term process refers to an instance of a running program or group or programs. A program is the entity that is not running. The process is the operating environment the program runs in. This includes operating system and hardware support.

Granularity of Access: A concept that supports accessing of a system resource in the smallest increment. For example, if a piece of data that is stored in a record that is stored in a file is needed access to, the access is regulated to the particular piece of data rather than granting access to the entire file.

Abstraction: A concept used in designing that allows complexity to be factored out so that a few important details or concepts can be focused on at any point in time. Abstract thinking can reduce the complexity of a problem into manageable pieces so that one can deal with a subset of the concepts involved in a system. Abstraction can apply to both control structures and data.

Programs vary in their size and complexity. A large (well structured) program is comprised of routines or functions that perform various operations that contribute to the overall problem being solved. These routines operate on data. Routines create data and transform data, they also control the flow through the program based on the data.

If you were going to discuss one aspect of the system and you had to consider every detail and bit of minutia involved in the system you would quickly be overcome with complexity and forget what you were trying to answer. You would not be able to see the forest through the trees. Abstraction allows you to limit or ignore the details that occur throughout the entire system and focus on the areas important to you.

Layering : Layering is a concept that supports abstract thinking. Layering divides the functionality of a system into discrete functional pieces or layers. Each layer deals with different functions. The functions that occur in a particular layer correspond to a “layer or abstraction”. The most basic or primitive operations occur at the lowest layer(s). Operations at higher layers are dependent on the services provided by the lower layers. The higher level functions are not necessarily more complex than the lower level functions but they are dependent on the lower level functions providing their services.

A classic example of functional layering is shown in the layers of a network. Networks are described using the OSI model of networks which consists of seven layers. Each layer performs different operations that are at a different layer of abstraction in the network model. The seven layers in the OSI network model are:

Layer 7: Application Layer

Layer 6: Presentation Layer

Layer 5: Session Layer

Layer 4: Transport Layer

Layer 3: Network Layer

Layer 2: Data Link Layer

Layer 1: Physical Layer

Don’t worry about the details of the network model at this point. We will be discussing them later. The point here is that the network model demonstrates an example of layering of which control and data abstraction occurs at each level. For example in this model one can discuss what occurs at any given layer without having to deal with the intricacies of the control flow and data that is dealt with in higher or lower layers.

Data Hiding or Information Hiding: Conceptually data hiding is used in design methodology when abstraction is used. The data used at one level of abstraction is not used at another level of abstraction. Further, data at one level of abstraction should not be available at another level of abstraction. Some computer languages support data hiding by restricting the access to data by different routines. Object oriented programming strives to support data hiding different ways depending on the implementation.

In the above description of layering there is data associated with each layer in the OSI model. There is no reason for routines or procedures operating at one layer in the OSI model to access data being used at another layer in the model. This concept can be enforced by a combination of procedures/standards and implementation languages.

Implementation

There are several types of system architectures, hardware and programming implementations that are used. Depending on the problems to be solved a system may support different system architectures, different programming models and different hardware. General purpose systems are used to solve a wide range of problems. They require flexible programming models that can be applied across a spectrum of problems. Specific or targeted systems are used to solve a very narrow range of problems. They do not need general and flexible programming models since they are targeting specific problems.

Keep in mind that these different types of systems, components and programming models contribute to the overall complexity of implementing a TCB. The more variability that needs to be accounted for the more complexity results in the final implementation.

System Types

Closed systems: These tend to be proprietary systems that use proprietary hardware and software. Typically these systems are used to solve very specific problem(s). The programming environment is limited as is the capability of the hardware. They can be secure since hardware and software is proprietary and there are fewer general purpose tools available to thwart security.

Discussion: There are arguments that can be made that closed systems may not be as secure as one thinks. This is because a closed system is not as rigorously tested by the commercial, government and academic communities. We will learn that some of the strongest encryption algorithms are in the public domain. They have gained there strength over the years by being exposed to rigors of testing. Another example of well performing, secure and functional systems are those systems and components in the GNU library of “free’ software governed by the principles of the GPL (GNU Public license).

Open systems: These are systems that use standard programming languages, standard programming and hardware interfaces. These systems also promote full access to the system within the constraints of the TCB, which includes access control and authentication.

Discussion: It is interesting to note that systems such as Windows were considered open systems. How could that be since their operating system and application code base is controlled by a single company and the source code for them is not available to the public at large? This is compared to some Unix and Linux implementations that had their code base available to the public. Also, proprietary application programs such as word processing and mail programs with proprietary file formats, produced by private companies are viewed as “open”. Open does not mean a package is used by millions of users. Open means that standards are utilized throughout its implementations. During the earlier days of computing many companies had proprietary systems. When I worked at DEC all of our operating systems were proprietary as were other components. As technology advanced customers did not want to be locked into one vendor for their hardware or software needs. They wanted the ability to easily move between vendors, or include other vendors in their environments. The requirement for various vendors to inter-operate forced vendors to build their systems around agreed to standards.

Memory Types

There are different types of memory that are used for different purposes. The various attributes are not to be viewed as a singular attribute of a memory type. For example, volatile memory could also be random access and primary memory.

Volatile: Memory that does not retain what is in it when there is no power is volatile memory. Memory used by the CPU for direct execution of a program is volatile memory.

Nonvolatile: Memory that retains what is in it when there is no power is non-volatile memory. Disk drives, memory sticks, magnetic tapes are nonvolatile memory.

Random Access: Type of memory in which accesses to any memory location takes the same amount of time. Random access memory is directly addressable by the CPU. Random access memory is also used for high speed graphics displays and other devices.

Sequential Access: Type of memory that each memory location is accessed sequentially. For example, if a process started to access memory at memory location “1” and intended to get to memory location “4” the process needs to move through memory locations “2” and “3”. This characteristic means there is varying amounts of time required to access a memory location. For example, a process starting at memory location 1 can get to memory location 2 much quicker than to get to memory location 1000.

Primary Memory: This is the memory that is used by the CPU. Programs or data is loaded into primary memory for fast access. Primary memory tends to be volatile, random access memory.

Secondary Memory: This is nonvolatile memory that is used to store information that must persist over lost of power or system restarts. It can be disk drives (random access), memory sticks (random access), tape drives (sequential) and other devices.

Virtual Memory: This is a concept used in programming that extends the amount of physical memory available to a process by utilizing secondary storage. By using programming techniques and hardware support a user process can use a virtually unlimited amount of memory for processing irrespective of the physical limitations of the amount of physical memory on the system.

Operating System Types

There are different types of operating systems each with their own nuances and complexities. The more operations that can occur concurrently generally relates to the overall complexity of the operational environment (i.e. operating system). Recall that process isolation is fundamental to providing a secure operating environment and hence a trusted computing base. The more concurrency the more chance process isolation could be undermined.

Multitasking/Multiprogramming: Techniques where multiple tasks or processes in separate address spaces share common computing resources. Access to the common resources such as the CPU, are shared in an interleaved, cooperative or preemptive fashion.

Multiprocessing: A technique of allowing multiple tasks or processes to share common computing resources on a system with multiple CPUs.

Single threading: A technique where one task (or thread of execution) operates within the context of a single process (shared address space).

Multithreading: A technique where separate tasks (or multiple threads of execution) can operate within the context of a single process (shared address space). Benefit of multithreading over multitasking is the saving in context switching between separate threads versus separate processes (or tasks).

There are other operating system models. There is cooperative multitasking, preemptive multitasking, timesharing, real time processing to name a few more. Some systems support multiple programming models.

Summary

In this section we discussed some of the tenets that need to be supported in order to implement a TCB. We discussed various design and implementation techniques that are used in practice and are beneficial in producing a TCB. We completed by a cursory survey of some of the system, physical memory and operating system types to raise awareness in the numerous elements that need to be considered in implementing a TCB.

Validating a TCB

Week3Part3-ISrevisionSu2013

Requirements Specification

In order to build anything you need a clear unambiguous definition of requirements. Building a system that supports Information Security is no different in this regard. Clear, concise requirements need to be defined, reviewed and agreed to by the various stakeholders. The requirements specifications should always be expressed by a formal definition. By formal, I mean the requirements should be written down and placed under revision control so that the stakeholders have a clear understanding of what the currently agreed to set of requirements are. Following agreement of the requirements a formal signoff of the requirements document should be done by all stakeholders. This process of review and signoff should also take place when any change is made to the requirements.

A valuable document for guiding the requirements definition is FIPS PUB 200 Minimum Security Requirements for Federal Information and Information Systems. This document provides 17 areas that are relevant to defining “Minimum Security Requirements”. For a particular Information Security infrastructure this document provides a valuable cross checking mechanism between industry standard requirements and the requirements of any particular Information Security requirements.

Part of the requirements document should include assurance or compliance requirements. Assurance requirements define how the functional requirements are verified. Typically we think of testing as a form of verification, however in addition to testing there are formal models that can be used for requirements verification. The goal of assurance is to verify the system accurately implements the functional requirements. Functional requirements can involve: user functionality, user interface, performance, security, proper algorithms and numerous other dimensions unique to the requirements of each system.

Assurance also includes an audit of the development practices used, the supporting documentation, configuration management and testing systems. Assurance is more then just testing.

The requirements are reproduced below for your convenience. The complete document is found at the following link. http://csrc.nist.gov/publications/fips/fips200/FIPS - 200 - final - march.pdf

Specifications for Minimum Security Requirements

Access Control (AC): Organizations must limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems) and to the types of transactions and functions that authorized users are permitted to exercise.

Awareness and Training (AT): Organizations must: (i) ensure that managers and users of organizational information systems are made aware of the security risks associated with their activities and of the applicable laws, Executive Orders, directives, policies, standards, instructions, regulations, or procedures related to the security of organizational information systems; and (ii) ensure that organizational personnel are adequately trained to carry out their assigned information security-related duties and responsibilities.

Audit and Accountability (AU): Organizations must: (i) create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; and (ii) ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions.

Certification, Accreditation, and Security Assessments (CA): Organizations must: (i) periodically assess the security controls in organizational information systems to determine if the controls are effective in their application; (ii) develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational information systems; (iii) authorize the operation of organizational information systems and any associated information system connections; and (iv) monitor information system security controls on an ongoing basis to ensure the continued effectiveness of the controls.

Configuration Management (CM): Organizations must: (i) establish and maintain baseline configurations and inventories of organizational information systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles; and (ii) establish and enforce security configuration settings for information technology products employed in organizational information systems.

Contingency Planning (CP): Organizations must establish, maintain, and effectively implement plans for emergency response, backup operations, and post-disaster recovery for organizational information systems to ensure the availability of critical information resources and continuity of operations in emergency situations. Identification and Authentication (IA): Organizations must identify information system users, processes acting on behalf of users, or devices and authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.

Incident Response (IR): Organizations must: (i) establish an operational incident handling capability for organizational information systems that includes adequate preparation, detection, analysis, containment, recovery, and user response activities; and (ii) track, document, and report incidents to appropriate organizational officials and/or authorities.

Maintenance (MA): Organizations must: (i) perform periodic and timely maintenance on organizational information systems; and (ii) provide effective controls on the tools, techniques, mechanisms, and personnel used to conduct information system maintenance.

Media Protection (MP): Organizations must: (i) protect information system media, both paper and digital; (ii) limit access to information on information system media to authorized users; and (iii) sanitize or destroy information system media before disposal or release for reuse.

Physical and Environmental Protection (PE): Organizations must: (i) limit physical access to information systems, equipment, and the respective operating environments to authorized individuals; (ii) protect the physical plant and support infrastructure for information systems; (iii) provide supporting utilities for information systems; (iv) protect information systems against environmental hazards; and (v) provide appropriate environmental controls in facilities containing information systems.

Planning (PL): Organizations must develop, document, periodically update, and implement security plans for organizational information systems that describe the security controls in place or planned for the information systems and the rules of behavior for individuals accessing the information systems.

Personnel Security (PS): Organizations must: (i) ensure that individuals occupying positions of responsibility within organizations (including third-party service providers) are trustworthy and meet established security criteria for those positions; (ii) ensure that organizational information and information systems are protected during and after personnel actions such as terminations and transfers; and (iii) employ formal sanctions for personnel failing to comply with organizational security policies and procedures.

Risk Assessment (RA): Organizations must periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational information systems and the associated processing, storage, or transmission of organizational information.

System and Services Acquisition (SA): Organizations must: (i) allocate sufficient resources to adequately protect organizational information systems; (ii) employ system development life cycle processes that incorporate information security considerations; (iii) employ software usage and installation restrictions; and (iv) ensure that third-party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization.

System and Communications Protection (SC): Organizations must: (i) monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems; and (ii) employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational information systems.

System and Information Integrity (SI): Organizations must: (i) identify, report, and correct information and information system flaws in a timely manner; (ii) provide protection from malicious code at appropriate locations within organizational information systems; and (iii) monitor information system security alerts and advisories and take appropriate actions in response.

Functional Specification

Preceding along the path of a sound design and implementation methodology the development of a functional specification should follow the requirements specifications. A functional specification describes how the requirements will be implemented from the perspective of the user. The functional specification does not specify how implementation will occur; implementation decisions are left for the design documentation. The functional specification describes how the system will behave from the user’s perspective. Among other things the functional specification includes the user interface, and the various inputs and outputs to any user controlled or operated process.

As with the other documents the functional specification should be reviewed and agreed to by the various stakeholders. It should also be subject to a formal signoff procedure and the document kept under change control.

Evaluation Criteria

Trusted Computer System Evaluation Criteria (TCSEC)

As with many areas of technical advancement the government is the impetus for the initial development of solutions for problems. The need for security in information systems was widely understood by commercial and government enterprises. A government program known as TCSEC endeavored to formalize various levels of security. The government security model was based on criteria known as Trusted Computer System Evaluation Criteria (TCSEC). This document is known as the Orange

Book because it had an orange cover. The document was part of a DOD series called the

“Rainbow Series”. The use of TCSEC was advanced by the United States Department of Defense (DOD) and other government agencies. The documents are now obsolete but the concepts live on in other documents and standards. TCSEC was most interested in the area of confidentiality.

Each level defined the security functional requirements and the assurance criteria used to validate the functional requirements. It is worth amplifying that the requirements included both functionality and assurance criteria. Defining tests to validate that the systems work as defined by the requirements is a large part of developing a TCB. As functionality evolves in a system so must the test system and suite of tests evolve.

Discussion:

When I worked ar DEC in different development groups we had a testing policy for developing and maintaining a system. The initial building of a functional test suite is quite a job. At some levels of abstraction code modules map 1:1 to user commands. However, when implementing system services or lower level modules that will be used by many callers (various programs working on behalf of users) special test harnesses need to be developed that test the inputs and outputs of the modules to verify correctness. Once tests of the low level routines have been built up they can be added to the regression test suite to become the “assurance” for the lower level routines.

Typically, the regression test systems were built up to include thousands of tests. The tests were repeatedly run against the system throughout the entire life of the system. The test system stored 2 sets of files (actually more). Each test was stored in a file, associated with each file was the results of the last valid test execution. This was referred to as the benchmark file.

When tests were run the results were compared against the benchmark. If the tests results matched the benchmark file then the test was successful. In other words there was no test regression. If the test results were different the differences needed to be understood to determine if something was wrong. As ongoing development on the system takes place the regression tests were regularly run. Typically the tests ran each night when system use was light and the results would be reviewed the next day. Each nights test run included any code of configuration changes from the previous day. By testing every day it was easier to rationalize any changes to the test results. The tests ran automatically comparing the results and benchmark files. If any differences to the test results were reported they would be checked by the development staff. If the changes to the test results made sense the tests benchmark files were updated to include the new results. If the changes did not make sense the cause of the change was understood perhaps resulting in the previous day’s changes to be removed from the code base.

When fixing bugs in a system the policy was that a code change could not be checked into the code base unless a regression test was checked into the regression test suite. This built up a valuable base of tests which was used for years (decades in some cases) to verify the system. The transaction processing system I managed development of had a regression test suite of over 5000 tests. It took several days to run. It certainly added a lot to the Trusted Computing Base of the overall product.

This is just the regression tests. We also had load test and performance test suites.

TCSEC defined divisions of security that roughly correspond to government classifications of Unclassified, Secret, Top Secret and “Beyond” Top Secret. The divisions were designated D, C, B and A. Each division is made up of classes which can be further broken down into security requirements (functional and assurance) within each division.

Division D defines minimal protection. It basically means a system has been evaluated by the TCSEC but it failed to meet any standards and therefore is designated as providing minimal protection.

Division C defines discretionary protections also known as discretionary access control (DAC). These are protections that the owner or creator of the data can assign to others based on their “discretion”. DAC is a common form of access control used in commercial systems. It is the default form of access control in Windows and UNIX/Linux systems. Within division C are classes C1 and C2.

Division B defines mandatory protection. This is the division of interest to government and military agencies. Mandatory protection is also known as mandatory access control (MAC). MAC is a form of access control where security “tags” that correspond to the classifications of secrecy or access are defined. For example security or access tags could be defined as unclassified, confidential, secret, top secret. These tags are placed on “objects” based on the classification of the “object”. The access tags are also assigned to the “subjects” that will access the “objects”. When a subject attempts to access an object the tag of the subject is compared against the tag of the object. If the tags are the same access is allowed. If the tags are not the same access is denied. It should be noted that depending on the system access can be allowed if the tag of a subject is “higher” then the tag on the object and not just equal to. In other words, a subject with a tag secret can access objects tagged as unclassified, confidential or secret. However, they cannot access objects tagged as top secret.

MAC access control is supported by many DBMS systems. Examples of operating systems that provide support for MAC functionality are: Trusted Solaris, SElinux, Linux addon packages, Microsoft Vista and Server 2008 implement Mandatory Integrity Control. Within division B are classes B1, B2 and B3.

Division A defines verified protection. There is no functionality difference between Division A and B, however Division A must be a verifiable in design and functional operation using formal analysis methods as well as proofs derived from formal confidentiality and integrity models. Division A is subjected to a bit more rigor in the testing, verification and analysis of results.

We will cover DAC and MAC access control models in more detail when we discuss access control.

Information Technology Security Evaluation Criteria (ITSEC)

The European computing community was developing security criteria under the guise of

Information Technology Security Evaluation Criteria (ITSEC). This was similar in its intent to the TCSEC effort; however ITSEC placed additional effort on Availability and Integrity, whereas TCSEC was more focused on Confidentiality.

There are mappings between the ITSEC designations for functionality and assurance classes and the TCSEC divisions and classes. Some differences between ITSEC and TCSEC are worth noting.

· ITSEC introduces the concept of Target of Evaluation (TOE). This refers to a specific product or system under evaluation.

· ITSEC defines functionality classes which are designated as F-xx, where xx designates a TCSEC class.

· ITSEC has assurance classes defined as E0 – E6. E0 is the lowest level of assurance and E6 the highest level.

Mapping between the TCSEC classes and ITSEC requires using the combination of functionality class and assurance class for ITSEC to map to a corresponding TCSEC Class.

Table reproduced from Information Security- Merkow and Breithaupt

TCSEC Classes	ITSEC Functional and Assurance Classes
C1	F-C1, E1
C2	F-C2, E2
B1	F-B1, E3
B2	F-B2, E4
B3	F-B3, E5
A1	F-B3, E6

Complete documentation for ITSEC including Functional and Assurance Classes can be found at:

http://www.iwar.org.uk/comsec/resources/standards/itsec.htm

The Common Criteria

With globalization increasing there is the need for suppliers to standardize around common standards of functionality, assurance (testing) and the specification of both. Clients want to be able to evaluate systems from a range of international suppliers and be able to compare systems using standard criteria. Clients may want to combine components from different suppliers that have been evaluated at the same functional and assurance levels.

These were the driving forces for TCSEC, ITSEC and CTCPE (Canadian Trusted Computer Product Evaluation Criteria) to develop a standard evaluation criterion. The result of this effort was “The Common Criteria for IT Security Evaluation”, which was published under ISO 15408.

The Common Criteria uses a Protection Profile (PP) which is a set of security requirements, their meaning and reasoning, and the corresponding Evaluation Assurance Levels (EAL) that the intended product will require. EAL levels can be mapped to the assurance in the TCSEC and ITSEC models.

Table reproduced from Information Security- Merkow and Breithaupt with added commentary.

Common Criteria Assurance Levels	Orange Book Criteria Level	ITSEC Criteria Level	Comments
	D: Minimal Protection	E0	No protection
EAL1			Functionally tested. Security not viewed as a threat.
EAL2	C1: Discretionary security protection	E1	Structurally Tested. Informal development and testing documentation available.
EAL3	C2: Controlled Access Protection	E2	Methodical testing
EAL4	B1: Labeled Security Protections	E3	Methodically designed, tested, and reviewed.
EAL5	B2: Structured Protections	E4	Designed and tested with security engineering.
EAL6	B3: Security Domains	E5	Rigorously designed and tested with security engineering.
EAL7	A1: Verified design	E6	Rigorously designed, tested with security engineering. Formal design verification.

Note that delivery of a system requires that not only is the functionally operating system delivered. The supporting documentation, configuration management and testing systems are part of the system and available for reuse.

Following is the url for all publically available ISO standards (including the 3 section ISO 15408) http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

A readable summary of the salient points of ISO 15408 can be found at http://en.wikipedia.org/wiki/Common_Criteria

Another reference is http://www.commoncriteriaportal.org/

As with all standards development getting diverse groups to come to consensus takes time. This makes acceptance of the standard slow. Despite the fact the TCSEC, ITSEC and CTCPE standards are no longer being developed many organizations in these respective geographies will still implement and validate to these standards as well as the Common Criteria. The Common Criteria is rapidly gaining acceptance but blanket acceptance is not there yet.

The text Information Security – Principles and Practices by Merkow and Breithaupt does a good job summarizing the mapping between TCSEC, ITSEC and the Common Criteria.

Formal Security Models

Building systems is very expensive. The earlier in the system implementation cycle that problems can be identified the cheaper and easier it is to fix. If problems are found during design they can be fixed on “paper” with relatively little cost. On the other end of the spectrum if problems are not discovered until after the systems are deployed and running the cost of repair increases dramatically. Developing and distributing patch kits for software problems or producing change kits for hardware are very expensive for a supplier. Customers that encounter problems with a running system can experience a range of issues from simple nuisances to complete outages that damage information assets. For the client loses affecting the CIA dimensions can be enormous.

It is near impossible to build a system that is not vulnerable to security attacks. Efforts in the attacker community developing malware and attack strategies is equal to and in many cases exceed efforts in the development community to make systems secure. Security patch kits are regularly issued for Windows systems. Virus and attack signatures are regularly downloaded by virus scanners and IDS systems respectively. This is one example of the ongoing exploitation of vulnerabilities and the need to fix them.

These problems have led to the development of models that can be used to prove mathematically or logically that a particular security design will conform to the security requirements as defined. These formal systems were initially funded by the Department of Defense to formally prove that systems requiring the highest levels of TCSEC security were in fact secure to that level. The work on formal proofs of system correctness was used on various systems and not limited to security requirements.

Formal systems are used to ensure that each access of an Object by a Subject advances the state of the model to a consistent and secure state. If all permutations of Subjects and Objects are tested through the model and each results in a consistent and secure state, then the model is verified and in theory so is the system being modeled.

· A system starts in a consistent and secure state

· A Subject accesses an Object using the semantics defined by the formal model

· If the access is successful the system results in a consistent and secure state.  If the access is not success the system results in a consistent and secure state.

Some objects or subjects may not conform to the defined semantics of the model. In this case special semantics may be defined for these entities.

Bell-LaPadula Model

The Bell-LaPadula (BLP) model was developed as a formal model to validate access control systems. BLP is a confidentiality model. The model uses Subjects and Objects which are assigned a security class. The security class controls the way a subject accesses an object. This conforms to the mandatory access model (MAC) which models access modes used by the US Department of Defense and other government agencies. The model is intended to enforce the least privilege principle. BLP is built on the concept of a state machine.

The model defines four access modes, although more modes or different modes could be used.

· Read: The subject is allowed only read access to the object.

· Append: The subject is allowed only write access to the object.

· Write: The subject is allowed read and write access to the object.

· Execute: The subject can invoke execution of the object, but cannot read or write to it.

There are various requirements for access that must be conformed to in the BLP model.

· No read up: A subject can only read an object of equal or less security level. This ensures confidentiality since a subject of a lower security class can not see information assigned to a higher security class.

· No write down: A subject can only write into an object of equal or greater security level. This ensures confidentiality since a subject of a higher security class can not make information available to an object of a lesser security class.

This is referred to as the confinement property.

· Discretionary access can be allowed using an access control matrix.

Following these rules would conform to the confidentiality required by the MAC model.

BIBA

The Biba model deals with integrity and is concerned with the unauthorized modification of data.

The access modes used in BIBA are:

· Modify: Write or update information in an object

· Observe: Read information in an object

· Execute: Execute an object

· Invoke: Communicate from one subject to another subject

The first 3 modes are analogous to the access modes in the BLP model. The 4th mode, invoke is new.

The requirements the Biba model conforms to are the reverse of the BLP model:

· Read up (no read down): Subjects cannot read objects of a lesser integrity level.

Subjects can only view content at or above their own integrity level.

· Write down (no write up}: Subjects cannot write to objects of a greater integrity level. Subjects can only create content at or below their own integrity level.

Other Formal Models

There are other formal security models: Chinese Wall model, Clark and Wilson model and others. We will be looking into Access Matrices when we cover access control. Formal proofs were used for verification of defense systems that required rigorous proof of correctness. They are also used in academic circles to develop solid design approaches. Formal models are not used that prevalently in commercial systems. Formal security model should be considered as another tool to be considered in the security assurance realm. A formal model can provide a valuable tool for describing the design and access model of a system even if the model never goes beyond paper.

Summary

In this section we discussed how a TCB is evaluated. We reviewed the attributes of various methodologies that define functionality and assurance methodologies for security system. These systems were developed by the United States, Canada and European communities. We introduced the Common Criteria which is an effort to coalesce the various standards into a grand ISO standard that will support a standard methodology for implementing security system functionality, evaluation, assurance and specification. Finally we touched on the use of formal systems for use in evaluating security systems to determine if the design and/or implementation satisfy the requirements.

Business Continuity and Disaster Recover

Week3Part4-ISrevisionSu2013

Introduction

Organizations grow by providing needed products and services. Overtime, successful companies will grow as they continue to fill the need of their customer base. This includes providing the product and services in a predictable fashion that the client base has grown to expect. Sometimes disasters occur which are unexpected. These disasters take various forms and can be caused by various events. Some disasters are manmade and some are not. Generally, the disasters are not predictable when they happen.

Organizations need to prepare for these disasters. They need to have a plan that protects their assets, the assets of their clients and provides for continuing business according to their service level agreements.

The outages that result from a disaster can range from a nuisance to a full blown catastrophe. Consider an outage that occurs to a computer system that is controlling an online gaming site, versus an outage to a computer system controlling a nuclear reactor or hospital intensive care until.

If something interrupts an organizations ability to provide their product and services clients will quickly seek other alternatives.

Sudden interruptions in the delivery of an organizations product and services can occur in a variety of ways; consider the following few:

· Natural disasters such as earthquakes, fire, floods.

When Japan was hit by an earthquake, tsunami and nuclear plant breach their infrastructure was devastated. Many dependent businesses thousands of miles away were affected by the inability of the Japanese manufacturers to deliver on manufacturing commitments such as automobiles and auto parts. The lack of parts impacted car dealers and car users the world over. Similarly, when Thailand was hit by floods their ability to deliver disk drives and other semi-conductor parts to computer manufacturers forced these manufacturers to seek alternate suppliers.

In both these cases organizations that relied on Japan and Thailand to deliver products to them had to have contingency plans in place for their supply chain. Without a business continuity plan that had contingencies for alternate suppliers customers would turn to other alternatives.

· Job actions such as: strikes, slowdowns, walkouts

Airline pilots go on strike; forcing customers to seek alternate means of travel for personal use and business. In some cases, people were forced to seek alternatives to travel. In some cases business travel was replaced with technology alternatives such as video conferencing, messages and email. Personal travel was supplanted with train travel and trips closer to home that could be done with an automobile.

There isn’t much of a contingency for not having trained pilots. But part of a disaster recovery plan would be to have some good-will gestures in place to win back the customer base.

· Massive IT technology failures related to security breaches.

TJX Corporation reports a security breach resulting in the theft of millions of credit card numbers. A plan is needed to notify users and banks of the breach. The plan has to address how the breach is fixed so that business can continue.

A multi-national computer manufacturer loses a laptop that contains pension information of over 50000 employees. The information is not encrypted. There is a level of disaster for the owners of this data. There must be a disaster recovery plan in place to recover from a failure to maintain the confidentiality of this information.

An online retail system is taken offline by an attack which launches a DDOS (distributed denial of service) attack on the website. There must be a business continuation plan in place to resolve the DDOS and to ensure business transactions can be restored.

· Massive technology failures leading to shortage of materials, pollution, contamination and death.

BP oil well in the Gulf of Mexico blows out resulting in millions of barrels of oil leaking into the Gulf. Disaster recovery plan is needed to cap the run-away well.

Failures at nuclear plants at Chernobyl, Ukraine; Fukushima Daiichi, Japan and Three Mile Island, Pa. lead to the need for Business Continuity plans to maintain the level of power to the electrical grid, as well as disaster recovery plans to evacuate areas and to control the overheating reactors.

Large chemical leak in Bhopal, India results in the death of more than 10,000 people, and tens of thousands of people affected with long term diseases. Inadequate disaster recovery and response planning contributes to poor response.

· Political upheaval that disrupts foreign supply chains.

Mideast problems disrupt the supply chain of petroleum products.

· External or internal terrorist attacks; or sabotage.

9/11 Terrorist attacks takes out World Trade Center Towers in New York. With this attack more than 50% of the companies in the trade towers were forced out of business.

· Criminal activity that can bankrupt organizations.

Enron Corporation, WorldCom, Tyco, Arthur Anderson to name a few of the companies implicated in some level of corporate fraud. Some companies have been able to survive others have not.

These are just a few examples of the type of disasters that can occur to an organization. In some cases, business continuity and disaster recovery plans can help contain the damage. In extreme cases the disruption and devastation is so severe nothing seems to help.

In the case of a disaster there is nothing that damages a company’s reputation more than not having proper contingency planning. In many cases clients understand that disruptions can happen due to the complexity of technology, acts of nature, or criminal evil doers. While no one likes to experience an outage, the reasons they can occur are (somewhat) understood. What is generally not tolerated is when an organization does not have plans in place to deal with an outage. This can result in irreparable damage to an organizations reputation.

Two items that ever organization must have is a business continuity plan and a disaster recovery plan. In some cases organizations are mandated by law to have business continuity and disaster recovery plans in place. These plans must be reviewed, rehearsed, tested and approved by management. Organizations that are publicly traded or provide critical infrastructure are not simply allowed to say “whoops”. They are required by law to show due diligence in the protection of assets and the continuation of service in the face of disaster.

Without these plans in place organizations are on a path to disaster.

Organizations that fail to plan are said to have a plan to fail.

Business Continuity Plan

A business continuity plan (BCP) is a plan or a roadmap for how an organization will operate under adverse or less than optimal conditions.

A business continuity plan (BCP) is used to describe the critical components required to keep the business running. Major components for the BCP are an inventory of the critical aspects of the business which must continue to run. This includes key processes, procedures, physical assets, software, key personnel and key skill sets.

A key item that contributes to the BCP is the risk analysis of the key assets. This includes identifying the assets, determining the values of the assets, the threats to the assets (internal and external), and the vulnerabilities of the assets. From this the importance of the asset to the overall operation of the business can be determined.

While everyone serves an important role in an organization some individuals are in roles that are more critical if the business is operating in a business continuation mode. Also, required is to identify key skills that are needed for implementing the BCP. It is always better to have multiple people with needed skills. To be overly dependent on one person is not a good plan. People leave; through job changes, promotions; termination, retirement, sickness and death. Ideally, identifying the skills needed for the BCP and identifying multiple people that have these skills will provide an added contingency layer for the BCP.

The results of this analysis will feed into the business impact statement. This is a statement of the operating loss and overall financial impact to the organization should a disruption in business occur.

As with any plan it is important to get buy-in from all the stakeholders and management. This requires selling the idea to management and getting signatures on the plan which codifies their support.

Once the BCP is agreed to it needs to be implemented through the use of best practices and incorporated into the policy and procedures of the organization. The BCP needs to be regularly tested in various simulated scenarios with a complete review of the results. As the results of testing the BCP dictate, the policy and procedures should be updated in a continuous improvement cycle.

Disaster Recovery Plan

A disaster recovery plan (DRP) is used to describe how the organization can recover from the disaster. The DRP identifies the processes, procedures, assets, people, roles and skills that are needed to recover from the natural or manmade disaster. The DRP is a subset of the BCP.

From the standpoint of Information Technology and security an organization needs to recover their IT assets so that the CIA (Confidentiality, Integrity and Availability) of their assets is restored to the state prior to the disaster.

Physical Assets

To prepare for various disasters IT organizations need to consider having redundant computing resources that can be quickly brought up so that business processes can continue and recovery from the disaster can occur. The best case scenario for this is to have a completely duplicated redundant site geographically separated from the original site that is fully staffed with qualified personnel which can be quickly brought up. Of course the expense of duplicating all assets prohibits this approach.

One approach is to have shared alternate sites with other organizations which share the cost of assets. A major problem with this approach is that seldom do organizations share the same equipment, process and procedures and trained staff. On the other hand, as more and more IT resources move to the cloud, cloud providers are addressing this problem by setting up redundant computing centers which distribute data and duplicate assets so that service level agreements (SLAs) can be met. The cloud model is not a perfect fit, but as organizations move to the cloud they need to consider the BCP and DRP in the context of the cloud.

Intellectual Assets

A major part of recovering from an IT disaster is being able to recover critical data. In order to do this you must be able to identify which data is critical and which is not. If a proper risk assessment was done all assets (physical and intellectual assets) would be ranked into tiers which categorize the assets based on its importance to the BCP and DRP.

In the case of intellectual assets the most important data would be ranked as tier 1, and data of lesser importance tier 2, 3, etc. This ranking provides a prioritization of which data needs to be restored first to support the BCP and the DRP.

In order to restore data, one needs to have backed up the data in the first place. As we discussed in the lecture on Operational Security having a backup plan that is thought out, planned and tested is very important. When disaster strikes the IT staff is quickly thinking about the state of their backup files.

Backup Scenarios

Depending on the speed needed to recover information and the cost the organization is willing to incur there are different backup recovery plans that can be instituted. They are termed Hot Site, Warm Site and Cold Site.

A hot site facility is one that provides completely mirrored IT services. This means services can be restored “almost seamlessly”. There is duplicate hardware, software and backup data. There is also a trained staff that can support the specific services of the organization. The hot site is the most expensive scenario, but for critical systems that need to be quickly restored it may be the right choice.

A warm site has some of the physical assets of the hot site, but installation, configuration and testing of software needs to be done. Backups need to be restored, and tested for integrity. There may be a staff in place that has general IT knowledge, but does not know the intricacies of the particular organization.

A cold site provides the facilities needed to house a subset of the physical assets needed for recovery. It is the responsibility of the organization to provide the hardware, software and trained personnel to get the cold site up and running. While a cold site solution might be feasible to recover from a partial outage, recovery from a complete outage may be another story. If an organization needs to quickly restore critical systems to meet SLAs a cold site is not the solution.

Summary

In this section we touched on some aspects of business continuity and disaster recovery and how it relates to information security. We have shown how risk assessment relates to the BCP and DRP. We have shown how some operational security functions such as having a thought out and tested backup strategy relate to the BCP and DCP.

Having a BCP and DRP is a key component of an Information Security Strategy. As with all plans they must be well thought out, tested and supported by management. These plans must be integrated into the full set of process and procedures for the organization which are regularly reviewed, tested and changed as needed.

Remember, not having a plan is planning to fail.