Book review: Software Security: Building Security in – Part II: Seven Touchpoints for Software Security

This is a review of the second part of the Software Security: Building Security in book.

Chapter 3: Introduction to Software Security TouchpointsSecuritySoftwareBookCover

This is an introductory chapter for the second part of the book. A very brief description is made for every security touch point.

Each one of the touchpoints are applied on a specific artifact and each touchpoints represents either a destructive or constructive activity. Based on the author experience, the ideal order based on effectiveness in which the touch points should be implemented is the following one:

  1. Code Review (Tools). Artifact: code. Constructive activity.
  2. Architectural Risk Analysis. Artifact: design and specification. Constructive activity.
  3. Penetration Testing. Artifact: system in its environment. Destructive activity
  4. Risk-Based Security Testing. Artifact system. Mix between destructive and constructive activities
  5. Abuse Cases. Artifact: requirements and use cases. Predominant destructive activity.
  6. Security Requirements. Artifact: requirements. Constructive activity.
  7. Security Operations. Artifact: fielded system. Constructive activity.

Another idea to mention that is worth mentioning is that the author propose to add the securty aspects as soon as possible in the software development cycle;moving left as much as possible (see the next figure that pictures the applicability of the touchpoints in the development cycle); for example it’s much better to integrate security in the requirements or architecture and design (using the risk analysis and abuse cases touchpoints) rather than waiting for the penetration testing to find the problems.

Security touchpoints

Security touchpoints

Chapter 4: Code review with a tool

For the author the code review is essential in finding security problems early in the process. The tools (the static analysis tools) can help the user to make a better job, but the user should also try to understand the output from the tool; it’s very important to not just expect that the tool will find all the security problems with no further analysis.

In the chapter a few tools (commercial or not) are named, like CQual, xg++, BOON, RATS, Fortify (which have his own paragraph) but the most important part is the list of key characteristics that a good analysis tool should have and some of the characteristics to avoid.

The key characteristics of a static analysis tool:

  • be designed for security
  • support multi tiers architecture
  • be extensible
  • be useful for security analysts and developers
  • support existing development processes

The key characteristics of a static analysis tool to avoid:

  • too many false positives
  • spotty integration with the IDE
  • single-minded support for C language

Chapter 5: Architectural Risk Analysis

Around 50% of the security problems are the result of design flows, so performing an architecture risk analysis at design level is an important part of a solid software security program.

In the beginning of the chapter the author present very briefly some existing security risk analysis methodologies: STRIDE (Microsoft), OCTAVE (Operational Critical Threat, Asset and Vulnerability Evaluation), COBIT (Control Objectives for Information and Related Technologies).

Two things are very important for the author; the ara (architectural risk analysis) must be integrated in and with the Risk Management Framework (presented briefly in Book review: Software Security: Building Security in – Part I: Software Security Fundamentals), and we must have a “forest-level” view of the system.

In the last part of the chapter the author present the Cigital way of making architectural risk analysis. The process has 3 steps:

  1. attack resistance analysis – have as goal to define how the system should behave against known attacks.
  2. ambiguity analysis – have as goal to discover new types of attacks or risks, so it relies heavily on the experience of the persons performing the analysis.
  3. weakness analysis – have as goal to understand end asses the impact of external software dependencies.
Process diagram for architectural risk analysis

Process diagram for architectural risk analysis

Chapter 6: Software Penetration Testing

The chapter starts by presenting how the penetration testing is done today. For the author, the penetration tests are misused and are used as a “feel-good exercise in pretend security”. The main problem is that the penetration tests results cannot guarantee that the system is secured after all the found vulnerabilities had been fixed and the findings are treated as a final list of issues to be fixed.

So, for the author the penetration tests are best suited to probing (live like) configuration problems and other environmental factors that deeply impact software security. Another idea is to use the architectural risk analysis as a driver for  the penetration tests (the risk analysis could point to more weak part(s) of the system, or can give some attack angles). Another idea, is to treat the findings as a representative sample of faults in the system and all the findings should be incorporated back into the development cycle.

Chapter 7: Risk-Based Security Testing

Security testing should start as the feature or component/unit level and (as the penetration testing) should use the items from the architectural risk analysis to identify risks. Also the security testing should continue at system level and should be directed at properties of the integrated software system. Basically all the tests types that exist today (unit tests, integration tests) should also have a security component and a security mindset applied.

The security testing should involve two approaches:

  • functional security testing: testing security mechanism to ensure that their functionality is properly implemented (kind of white hat philosophy).
  • adversarial security testing: tests that are simulating the attacker’s approach (kind of black hat philosophy).

For the author the penetration tests represents a outside->in type of approach, the security testing represents an inside->out approach focusing on the software products “guts”.

Chapter 8: Abuse Case Development

The abuse case development is done in the requirements phase and it is intimately linked to the requirements and use cases. The basic idea is that as we define requirements that suppose to express how the system should behave under a correct usage, we should also define how the system should behave if it’s abused.

This is the process that is proposed by the author to build abuse cases.

Diagram for building abuse cases

Diagram for building abuse cases

The abuse cases are creating using two sources, the anti-requirements (things that you don’t want your software to do) and attack models, which are known attacks or attack types that can apply to your system. Once they are done, the abuse cases can be used as entry point for security testing and especially for the architectural risk analysis.

Chapter 9: Software Security Meets Security Operations

The main idea is that the security operations peoples and software developers should work together and each category can (and should) learn from the other (category).

The security operation peoples have the security mindset and can use this mindset and their experience in some of the touchpoints presented previously; mainly abuse cased, security testing, architectural risk analysis and penetration testing.

Book review: Software Security: Building Security in – Part I: Software Security Fundamentals

This is a review of the first part of the Software Security: Building Security in book.

Chapter 1: Defining a disciplineSecuritySoftwareBookCover

This chapter lands out the landscape for the entire book; the author presents his view on the today challenges in having secure holes free software.
In the today world, the software is everywhere, from microwaves oven to nuclear power-stations, so the “old view” of seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS it’s not valid anymore.

And just to make the problem even harder, the computing systems and the software applications are more and more interconnected must be extensible and have more and more complex features.

The author propose a taxonomy of the security problems that can be affected the software applications:

  • defect: a defect is a problem that may lie dormant in software only to surface in a fielded system with major consequences.
  • bug: an implementation-level software problem; only fairy simple implementations errors. A large panel of tools are capable to detect a range of implementation bugs.
  • flaw: a problem at a deeper level; a flow is something that can be present at the code level but it can be also present or absent at the design level. What is very important to remark is that the automated technologies to detect design-level flows do not yet exist, through manual risk-analysis can identity flows.
  • risk: flaws and bugs lead to risk. Risk capture the chance that a flaw or a bug will impact the purpose of a software.

In order to solve the problem of the software security, the author propose a cultural shift based on three pillars: applied risk management, software security touchpoints and knowledge.

Pillar 1 Applied Risk Management

For the author under the risk management names there 2 different parts; the application of risk analysis at the architectural level (also known as threat modeling or security design analysis or architectural risk analysis) and tracking and mitigating risks as a full life-cycle activity (the author call this approach, the risk management framework – RMF).

Pillar 2 Software security Touchpoints.

Touchpoint it’s just a fancy word for “best practices”. Today there are best practices for design and coding of software system and as the security became a property of a software system, then best practices should also be used to tackle the security problems.Here are the (seven) touch points and where exactly are applied in the development process.

Security Touchpoints

Security Touchpoints

The idea is to introduce as deeply as possible the touch points in the development process. The part 2 of the book is dedicated to the touchpoints.

Pillar 3 Knowledge

For the author the knowledge management and training should play a central role in encapsulation and sharing the security knowledge.The software security knowledge can be organized into seven knowledge catalogs:

  • principles
  • guideline
  • rules
  • vulnerabilities
  • exploits
  • attack patterns
  • historical risks

How to build the security knowledge is treated in the part 3 of the book.

Chapter 2: A risk management framework

This chapter presents in more details a framework to mitigate the risks as a full lifecycle activity; the author calls this framework the RMF (risk Management Framework).

The purpose of the RMF is to allow a consistent and repeatable expert-driven approach to risk management but the main goal is to find, rank, track and understand the software security risks and how these security risks can affect the critical business decisions.

Risk Management Analysis steps

Risk Management Analysis steps

The RMF consists of five steps:

  1. understand the business context The goal of this step is describe the business goals in order to understand the     types of software risks to care about.
  2. identify the business and technical risks. Business risk identification helps to define and steer the use of particular technological methods for measuring and mitigating software risk.The technical risks should be identified and mapped (through business risk) to business goals.
  3. synthesize and rank the risks. The ranking of the risks should take in account which business goals are the most important, which business goals are immediately threatened and how the technical risks will impact the business.
  4. define a risk mitigation strategy. Once the risks have been identified, the mitigation strategy should take into account cost, implementation time, likelihood of success and the impact
  5. carry out required fixes and validate that they are correct. This step represents the execution of the risk mitigation strategy; some metrics should be defined to measure the progress against risks, open risks remaining.

Even if the framework steps are presented sequentially, in practice the steps can overlap and can occur in parallel with standards software development activities. Actually the RMF can be applied at several different level; project level, software lifecycle phase level, requirement analysis, use case analysis level.

(My) CISSP Notes – Security Architecture and Design

Note: This notes were made using the following books: “CISPP Study Guide” and “CISSP for dummies”.

Security Architecture and Design describes fundamental logical hardware, operating system, and software security components, and how to use those components to design, architect, and evaluate secure computer systems.

Security Architecture and Design is a three-part domain. The first part covers the hardware and software required to have a secure computer system. The second part covers the logical models required to keep the system secure, and the third part covers evaluation models that quantify how secure the system really is.

Secure system design concepts

Layering separates hardware and software functionality into modular tiers. A generic list of security architecture layers is as follows:

1. Hardware

2. Kernel and device drivers

3. Operating System

4. Applications

Abstraction hides unnecessary details from the user. Complexity is the enemy of security: the more complex a process is, the less secure it is.

A security domainis the list of objects a subject is allowed to access. Confidential, Secret, and Top Secret are three security domains used by the U.S. Department of Defense (DoD), for example. With respect to kernels, two domains are user mode and kernel mode.

The ring model is a form of CPU hardware layering that separates and protects domains (such as kernel mode and user mode) from each other. Many CPUs, such as the Intel ×86 family, have four rings, ranging from ring 0 (kernel) to ring 3 (user).

The rings are (theoretically) used as follows:

• Ring 0: Kernel

• Ring 1: Other OS components that do not fit into Ring 0

• Ring 2: Device drivers

• Ring 3: User applications

Processes communicate between the rings via system calls, which allow processes to communicate with the kernel and provide a window between the rings.The ring model also provides abstraction: the nitty-gritty details of saving the file are hidden from the user, who simply presses the “save file” button.  A new mode called hypervisor mode (and informally called “ring 1”) allows virtual guests to operate in ring 0, controlled by the hypervisor one ring “below”.

An open system uses open hardware and standards, using standard components from a variety of vendors. An IBM-compatible PC is an open system.

A closed system uses proprietary hardware or software.

Secure hardware architecture

Secure Hardware Architecture focuses on the physical computer hardware required to have a secure system.

The system unit is the computer’s case: it contains all of the internal electronic computer components, including motherboard, internal disk drives, power supply, etc. The motherboard contains hardware including the CPU, memory slots, firmware, and peripheral slots such as PCI (Peripheral Component Interconnect) slots.

A computer bus, is the primary communication channel on a computer system. Communication between the CPU, memory, and input/output devices such as keyboard, mouse, display, etc., occur via the bus. Some computer designs use two buses: a northbridge and southbridge. The northbridge, also called the Memory Controller Hub (MCH), connects the CPU to RAM and video memory. The southbridge, also called the I/O Controller Hub (ICH), connects input/output (I/O) devices, such as disk, keyboard, mouse, CD drive, USB ports, etc. The northbridge is directly connected to the CPU, and is faster than the southbridge.

The “fetch and execute” (also called “Fetch, Decode, Execute,” or FDX) process actually takes four steps: 1. Fetch Instruction 1 2. Decode Instruction 1 3. Execute Instruction 1 4. Write (save) result 1 These four steps take one clock cycle to complete.

Pipelining combines multiple steps into one combined process, allowing simultaneous fetch, decode, execute, and write steps for different instructions.

An interrupt indicates that an asynchronous event has occurred. CPU interrupts are a form of hardware interrupt that cause the CPU to stop processing its current task, save the state, and begin processing a new request. When the new task is complete, the CPU will complete the prior task.

A processis an executable program and its associated data loaded and running in memory. A parent process may spawn additional child processes called threads. A thread is a light weight process (LWP). Threads are able to share memory, resulting in lower overhead compared to heavy weight processes.

Applications run as processes in memory, comprised of executable code and data. Multitasking allows multiple tasks (heavy weight processes) to run simultaneously on one CPU.

Multiprogramming is multiple programs running simultaneously on one CPU; multitasking is multiple tasks (processes) running simultaneously on one CPU, and multithreading is multiple threads (light weight processes) running simultaneously on one CPU.

Multiprocessing has a fundamental difference from multitasking: it runs multiple processes on multiple CPUs.

A watchdog timer is designed to recover a system by rebooting after critical processes hang or crash. The watchdog timer reboots the system when it reaches zero.

CISC (Complex Instruction Set Computer) and RISC(Reduced Instruction Set Computer) are two forms of CPU design. CISC uses a large set of complex machine language instructions, while RISC uses a reduced set of simpler instructions.

Real (or primary) memory, such as RAM, is directly accessible by the CPU and is used to hold instructions and data for currently executing processes. Secondary memory, such as disk-based memory, is not directly accessible.

Cache memoryis the fastest memory on the system, required to keep up with the CPU as it fetches and executes instructions. The fastest portion of the CPU cache is the register file. The next fastest form of cache memory is Level 1 cache, located on the CPU itself. Finally, Level 2 cache is connected to (but outside) the CPU.

RAM is volatile memory used to hold instructions and data of currently running programs.

Static Random Access Memory (SRAM) is expensive and fast memory.

Dynamic Random Access Memory (DRAM) stores bits in small capacitors (like small batteries), and is slower and cheaper than SRAM.

ROM (Read Only Memory) is nonvolatile: data stored in ROM maintains integrity after loss of power.

Addressing modes are CPU-dependent; commonly supported modes include direct, indirect, register direct, and register indirectDirect mode says “Add X to the value stored in memory location #YYYY.” That location stores the number 7, so the CPU adds X + 7. Indirectstarts the same way: “Add X to the value stored in memory location #YYYY.”  The difference is #YYYY stores another memory location (#ZZZZ). The CPU follows to pointer to #ZZZZ, which holds the value 7, and adds X + 7. Register direct addressing is the same as direct addressing, except it references a CPU cache register. Register indirect is also the same as indirect, except the pointer is stored in a register.

Memory protectionprevents one process from affecting the confidentiality, integrity, or availability of another.

Process isolation is a logical control that attempts to prevent one process from interfering with another. This is a common feature among multiuser operating systems such as Linux, UNIX, or recent Microsoft Windows operating systems.

Hardware segmentation takes process isolation one step further by mapping processes to specific memory locations.

Virtual memory provides virtual address mapping between applications and hardware memory.

Swapping uses virtual memory to copy contents in primary memory (RAM) to or from secondary memory (not directly addressable by the CPU, on disk). Swap space is often a dedicated disk partition that is used to extend the amount of available memory. If the kernel attempts to access a page (a fixed-length block of memory) stored in swap space, a page fault occurs (an error that means the page is not located in RAM), and the page is “swapped” from disk to RAM. The terms “swapping” and “paging” are often used interchangeably, but there is a slight difference: paging copies a block of memory to or from disk, while swapping copies an entire process to or from disk.

Firmware stores small programs that do not change frequently, such as a computer’s BIOS (discussed below), or a router’s operating system and saved configuration. Various types of ROM chips may store firmware, including PROM, EPROM, and EEPROM.

Flash memory (such as USB thumb drives) is a specific type of EEPROM, used for small portable disk drives. The difference is any byte of an EEPROM may be written, while flash drives are written by (larger) sectors. This makes flash memory faster than EEPROMs, but still slower than magnetic disks.

The IBM PC-compatible BIOS(Basic Input Output System) contains code in firmware that is executed when a PC is powered on. It first runs the Power-On Self-Test (POST), which performs basic tests, including verifying the integrity of the BIOS itself, testing the memory, identifying system devices, among other tasks. Once the POST process is complete and successful, it locates the boot sector (for systems which boot off disks), which contains the machine code for the operating system kernel. The kernel then loads and executes, and the operating system boots up.

WORM(Write Once Read Many) Storage can be written to once, and read many times. WORM storage helps assure the integrity of the data it contains: there is some assurance that it has not been (and cannot be) altered, short of destroying the media itself. The most common type of WORM media is CD-R (Compact Disc Recordable) and DVD-R (Digital Versatile Disk Recordable). Note that CD-RW and DVD-RW (Read/Write) are not WORM media.

Techniques used to provide process isolation include virtual memory (discussed in the next section), object encapsulation, and time multiplexing.

Secure operating system and software architecture

Secure Operating System and Software Architecture builds upon the secure hardware described in the previous section, providing a secure interface between hardware and the applications (and users) which access the hardware.

Kernels have two basic designs: monolithic and microkernel. A monolithic kernelis compiled into one static executable and the entire kernel runs in supervisor mode. All functionality required by a monolithic kernel must be precompiled in. Microkernelsare modular kernels. A microkernel is usually smaller and has less native functionality than a typical monolithic kernel (hence the term “micro”), but can add functionality via loadable kernel modules. Microkernels may also run kernel modules in user mode (usually ring 3), instead of supervisor mode.  A core function of the kernel is running the reference monitor, which mediates all access between subjects and objects. It enforces the system’s security policy, such as preventing a normal user from writing to a restricted file, such as the system password file.

Microsoft NTFS (New Technology File System) has the following basic file permissions:

• Read

• Write

• Read and execute

• Modify

• Full control (read, write, execute, modify, and delete)

Setuid is a Linux and UNIX file permission that makes an executable run with the permissions of the file’s owner, and not as the running user. Setgid (set group ID) programs run with the permissions of the file’s group. Setuid programs must be carefully scrutinized for security holes: attackers may attempt to trick the passwd command to alter other files.

Virtualization adds a software layer between an operating system and the underlying computer hardware. This allows multiple “guest” operating systems to run simultaneously on one physical “host” computer. There are two basic virtualization types: transparent virtualization (sometimes called full virtualization) and paravirtualization. Transparent virtualization runs stock operating systems, such as Windows 7 or Ubuntu Linux 9.10, as virtual guests. No changes to the guest OS are required. Paravirtualization runs specially modified operating systems, with modified kernel system calls.

Thin clientsare simpler than normal computer systems, with hard drives, full operating systems, locally installed applications, etc. They rely on central servers, which serve applications and store the associated data.Thin client applications normally run on a system with a full operating system, but use a Web browser as a universal client, providing access to robust applications which are downloaded from the thin client server and run in the client’s browser.

A diskless workstation (also called diskless node) contains CPU, memory, and firmware, but no hard drive. Diskless devices include PCs, routers, embedded devices, and others.

System vulnerabilities, threads and countermeasures

System Threats, Vulnerabilities, and Countermeasures describe security architecture and design vulnerabilities, and the corresponding exploits that may compromise system security.

Emanations are energy that escape an electronic system, and which may be remotely monitored under certain circumstances.

A covert channelis any communication that violates security policy. Two specific types of covert channels are storage channels and timing channels. The opposite of as covert channel is an overt channel: authorized communication that complies with security policy. A storage channel example uses shared storage, such as a temporary directory, to allow two subjects to signal each other. A covert timing channel relies on the system clock to infer sensitive information.

Buffer overflows can occur when a programmer fails to perform bounds checking.

Time of Check/Time of Use (TOCTOU) attacks are also called race conditions: an attacker attempts to alter a condition after it has been checked by the operating system, but before it is used. The term race condition comes from the idea of two events or signals that are racing to influence an activity.

A backdoor is a shortcut in a system that allows a user to bypass security checks (such as username/password authentication) to log in.

Malicious Code or Malware is the generic term for any type of software that attacks an application or system.

  • Zero-day exploits are malicious code (a threat) for which there is no vendor-supplied patch (meaning there is an unpatched vulnerability). Zero-day exploits are malicious code (a threat) for which there is no vendor-supplied patch (meaning there is an unpatched vulnerability).
  •  A rootkitis malware which replaces portions of the kernel and/or operating system. A user-mode rootkit operates in ring 3 on most systems, replacing operating system components in “userland.” Commonly rootkitted binaries include the ls or ps commands on Linux/UNIX systems, or dir or tasklist on Microsoft Windows systems. A kernel-mode rootkit replaces the kernel, or loads malicious loadable kernel modules. Kernel-mode rootkits operate in ring 0 on most operating systems.
  • A logic bomb is a malicious program that is triggered when a logical condition is met.
  • Packers provide runtime compression of executables. The original exe is compressed, and a small executable decompresser is prepended to the exe. Upon execution, the decompresser unpacks the compressed executable machine code and runs it.

Server-side attacks

Server-side attacks (also called service-side attacks) are launched directly from an attacker (the client) to a listening service. Server-side attacks exploit vulnerabilities in installed services.

Client-side attacks

Client-side attacks occur when a user downloads malicious content. The flow of data is reversed compared to server-side attacks: client-side attacks initiate from the victim who downloads content from the attacker.

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging security information, including authentication data.

Polyinstantiation allows two different objects to have the same name. The name is based on the Latin roots for multiple (poly) and instances (instantiation).

Database polyinstantiation means two rows may have the same primary key, but different data (!!!????).

Inference and aggregation occur when a user is able to use lower level access to learn restricted information.

Inference requires deduction: clues are available, and a user makes a logical deduction.

Aggregation is similar to inference, but there is a key difference: no deduction is required.

Security Countermeasures

The primary countermeasure to mitigate the attacks described in the previous section is defense in depth: multiple overlapping controls spanning across multiple domains, which enhance and support each other.

System hardening , systems configured according to the following concepts:

  • remove all unnecessary components.
  • remove all unnecessary accounts.
  • close all unnecessary network listening ports.
  • change all default passwords to complex, difficult to guess passwords
  • all necessary programs should be run at the lowest possible privilege.
  • security patches should be install as soon as they are available.

Heterogenous environment  The advantage of heterogenous environment is its variety of systems; for one thing, the various types of systems probably won’t possess common vulnerabilities, which makes them harder to attack.

System resilience The resilience of a system is a measure of its ability to keep running, even under less-than-ideal conditions.

Security models

Security models help us to understand sometimes-complex security mechanisms in information systems. Security models illustrate simple concepts that we can use when analyzing an existing system or designing a new one.

The concepts of reading down and writing upapply to Mandatory Access Control models such as Bell-LaPadula. Reading down occurs when a subject reads an object at a lower sensitivity level, such as a top secret subject reading a secret object. There are instances when a subject has information and passes that information up to an object, which has higher sensitivity than the subject has permission to access. This is called “writing up” because the subject does not see any other information contained within the object. The only difference between reading up and writing down is the direction that information is being passed.

Access Control Models

  • A state machine model is a mathematical model that groups all possible system occurrences, called states. Every possible state of a system is evaluated, showing all possible interactions between subjects and objects. If every state is proven to be secure, the system is proven to be secure.
  • The Bell-LaPadula model was originally developed for the U.S. Department of Defense. It is focused on maintaining the confidentiality of objects.Bell-LaPadula operates by observing two rules: the Simple Security Property and the * Security PropertyThe Simple security property states that there is “no read up:” a subject at a specific classification level cannot read an object at a higher classification level. The * Security Property is “no write down:”a subject at a higher classification level cannot write to a lower classification level. Bell-LaPadula also defines 2 additional properties that will dictate how the system will issue security labels for objects.  The Strong Tranquility Propertystates that security labels will not change while the system is operating.The Weak Tranquility Property states that security labels will not change in a way that conflicts with defined security properties.
  • Take-Grant systems specify the rights that a subject can transfer to a from another subject or object. These rights are defined through four basic operations: create, revoke, take and grant.
  • Biba integrity model (sometimes referred as Bell-LaPadula upside down) was the first formal integrity model.  Biba is the model of choice when integrity protection is vital. The Biba model has two primary rules: the Simple Integrity Axiom and the * Integrity Axiom. The Simple Integrity Axiom is “no read down:”a subject at a specific classification level cannot read data at a lower classification. This protects integrity by preventing bad information from moving up from lower integrity levels.The * Integrity Axiom is “no write up:”a subject at a specific classification level cannot write to data at a higher classification. This protects integrity by preventing bad information from moving up to higher integrity levels.

Biba takes the Bell-LaPadula rules and reverses them, showing how confidentiality and integrity are often at odds. If you understand Bell LaPadula (no read up; no write down), you can extrapolate Biba by reversing the rules: no read down; no write up.

  • Clark-Wilson is a real-world integrity model (this is an informal model) that protects integrity by requiring subjects to access objects via programs. Because the programs have specific limitations to what they can and cannot do to objects, Clark-Wilson effectively limits the capabilities of the subject.Clark-Wilson uses two primary concepts to ensure that security policy is enforced; well-formed transactions and Separation of Duties.
  • The Chinese Wall model is designed to avoid conflicts of interest by prohibiting one person, such as a consultant, from accessing multiple conflict of interest categories (CoIs). The Chinese Wall model requires that CoIs be identified so that once a consultant gains access to one CoI, they cannot read or write to an opposing CoI.
  • The noninterference model ensures that data at different security domains remain separate from one another.

Evaluation methods, certification and accreditation

Evaluation criteria provide a standard for qualifying the security of a computer system or network. These criteria include the Trusted Computer System Evaluation Criteria (TCSEC), Trusted Network Interpretation (TNI), European Information Technology Security Evaluation Criteria (ITSEC) and the Common Criteria.

 Trusted Computer System Evaluation Criteria (TCSEC)

TCSEC commonly known as the Orange Book and it’s the formal implementation of the Bell-LPadula model. The evaluation criteria were developed to achieve the following objectives:

  • Measurement Provides a metric for assessing comparative levels of trust between different computer systems.
  • Guidance Identifies standard security requirements that vendors must build into systems to achieve a given trust level.
  • Acquisition Provides customers a standard for specifying acquisition requirements and identifying systems that meet those requirements.

The Orange Book was the first significant attempt to define differing levels of security and access control implementation within an IT system.

The Orange Book defines four major hierarchical classes of security protection and numbered subclasses (higher numbers indicate higher security) :

  • D: Minimal protection
  • C: Discretionary protection (C1 and C2)
  • B: Mandatory protection (B1, B2 and B3)
  • A: Verified protection (A1)

Trusted Network Interpretation (TNI)

TNI adresses confidentiality and integrity in trusted computer/communications network systems. Within the Rainbow Series, it’s known as the Red Book.

European Information Technology Security Evaluation Criteria (ITSEC)

ITSEC addresses confidentiality, integrity and availability, as well as evaluating an entire system defined as Target of Evaluation (TOE), rather than a single computing platform.

ITSEC evaluates functionality (F, how well the system works) and assurance (E the ability to evaluate the security of  a system).   Assurance correctness ratings range from E0 to E6.

The equivalent ITSEC/TCSEC ratings are:

  • E0:D
  • F-C1,E1:C1
  • F-C2,E2:C2
  • F-B1,E3:B1
  • F-B2,E4:B2
  • F-B3,E5:B3
  • F-B3,E6:A1

Common criteria

The International Common Criteria is an internationally agreed upon standard for describing and testing the security of IT products. It is designed to avoid requirements beyond current state of the art and presents a hierarchy of requirements for a range of classifications and systems.

The common criteria defines eight evaluation assurance levels (EALs): EAL0 through EAL7 in order of increasing level of trust.

System Certification and Accreditation

System certification is a formal methodology for comprehensive testing and documentation of information system security safeguards, both technical and non-technical, in a given environment by using established evaluation criteria (the TCSEC).

Accreditation is an official, written approval for the operation of a specific system in a specific environment, as documented in the certification report.