Enterprise Security Architecture

Enterprise Security Architecture
This topic will focus on Security Architectures and various security models.

Introduction The Enterprise Security Architecture domain contains the concepts, principles, structures, and standards used to design, monitor, and secure operating systems, hardware, networks, applications and those controls used to enforce various levels of availability, integrity, and confidentiality.

Introduction The infrastructure includes items such as: Hardware
Software Operating System and all associated functions Applications Utilities Network environment Security awareness and training Information system security supporting policies, procedures, baselines, and standards

Objectives The CISSP should be able to:
Identify the security issues and controls that can be associated with architectures and designs. Describe the principles of common computer and network organization, enterprise architectures, and designs. Define and understand security models. What you are going to review in this module are key principles and concepts that are central to the security architecture of any organization. This module when coupled with the concepts covered in the other modules (particular emphasis on the telecommunications, cryptography and access control modules) will give the CISSP the necessary breadth to be able to address the challenges of developing a security architecture and the insight to be able evaluate the existing or legacy architecture of an organization.

Goals of Information Security
The common thread among good information security objectives is that they address all three core security principles. Availability Confidentiality Prevents unauthorized disclosure of systems and information. Integrity Prevents unauthorized modification of systems and information. Prevents disruption of service and productivity. The cornerstone of information Security.

Definitions Enterprise - Multiple internal networks, internal areas or domains, and various internal devices and systems, applications, and a diverse user presence as a single collective unit. Architecture - The highest level concept of a system in its environment.

Definitions Security Architecture - A high-level design used to satisfy a system’s security requirements as defined in an organization’s security policy Enterprise Security Architecture - Defines the information security strategy that consists of layers of policy, standards, and procedures and the way they are linked across an enterprise

Subtopics Common Computer Architecture
Operating System Central Processing Unit (CPU) Memory Management Input/Output Devices Memory Protection Trusted Computing Base (TCB) Computer Architecture Protection Concepts Security Architecture Protection Concepts Security Architecture Assurance Mechanisms Enterprise Security Architecture Security Models

Section Objectives Describe an operating system
List the requirements for memory management Describe input and output devices Define a Trusted Computing Base Describe the key computer architecture and security architecture protection concepts Describe the key security architecture assurance mechanisms

Common Computer Architecture Operating System Utilities and Software
End User End User Application Programs Utilities Operating System This slide represents the computer system layers. It begins with the end user at the top. The user interacts with data and the network resources through applications. The applications sit on top of the the utilities and operating system. The operating system provides management of the computer hardware resources. Computer Hardware

Common Computer Architecture Operating System
Operating system services include: Program execution Access to Input/Output devices Controlled access to files System access Error detection and response Accounting

Subtopics Common Computer Architecture Operating System
Central Processing Unit (CPU) Memory Management Input/Output Devices Memory Protection Trusted Computing Base (TCB) Computer Architecture Protection Concepts Security Architecture Protection Concepts Security Architecture Assurance Mechanisms Enterprise Security Architecture Security Models

Central Processing Unit (CPU)
This slide gives an overview of a system from the aspect of the CPU ALU (Arithmetic Logic Unit): Performs basic integer arithmetic and comparison functions. Not displayed is the Floating Point Processor which does the same for Floating Point numbers Control Unit: The part of the CPU that accesses the data and instructions in the computer and transfers it to the ALU Instruction: A command that tells a computer how to accomplish a specific task Primary Memory: Consists primarily of RAM (Random Access Memory) and cache. CPUs are much faster than standard RAM so most processors have a fast but small cache to store frequently used data and instructions. Input devices: keyboard, mouse, sound card. Output devices: monitor, printers, sound card Secondary storage: disk, cdrom, tape, floppy, etc. Communications devices: terminals, NIC, channels, etc. Note: As you get further away from the processor data takes longer to fetch. As a lead into the next slide, the CPU runs in 2 states: Supervisor and Program.

CPU States Supervisor State Problem State
Program can access entire system Both privileged and non-privileged instructions Problem State User State or Program State Only non-privileged instructions executed Intended for application programs The Supervisor state is where systems programs execute. To run in Supervisor state, a user needs a userid/password with special privileges, whereas the application programs run in problem (or program) state. Now, the CPU can be either stopped or running...

CPU States (cont.) Process States are: Stopped vs. operating
Wait vs. running Masked/interruptible Example: If masked bit not set, interrupts are disabled (masked off) - known as IRQs in systems Stopped if there are no programs executing. If it's running, it can be either executing instructions or waiting for some input (e.g., from a tape, keyboard, disk, etc.) There are vulnerabilities here that clever threat agents can exploit, and we'll discuss these later. The CPU can have different configurations... Displaying the status of processes: UNIX: ps –ef (or ps –aux on old UNIXes) NT/2000: Use pstat from the NT/2000 Resource Kit. It is freely downloadable Note: A process in wait state is generally waiting on an interrupt, e.g. waiting for user input, disk I/O, or some other process to pass it information IRQ = Interrupt Request Queue

CPU Processes All Applications were originally self-contained independent entities that communicated through the operating system

CPU Process Threads Many, if not most, of today’s programs are comprised of many individual modules, programs or processes that are separately written and work together to fulfill the overall objective of the application. These may be called modules or process threads. The security problems lie in the fact that these independent sections may be written by someone else then they may link dynamically and not be controlled by the Operating System. Threads are the smallest sets of code which can be scheduled for processing by the scheduling service of a processor or multiprocessor system. A thread is defined as ‘pieces of code’. See Bruce Schneir Secrets and Lies for more information.

CPU Processes Threads

CPU Memory This slide is intended to display the types of system memory About the only discussion on this slide should be the relative costs of cache and main memory. These have not been listed as there really are three types of cache. Level-1 is nearly always on the CPU chip. Level 2 may or may not be on the CPU chip. Level 3 is generally off-chip. Not all systems have a level-3 cache. As you move further from the CPU you increase memory latency which makes the CPU wait longer for data & instructions whenever they aren’t in cache.

Memory Management The five requirements for memory management are:
Relocation Protection Sharing Logical Organization Physical Organization Relocation: Programmer does not know where the program will be placed in memory when it is executed. While the program is executing, it may be swapped to disk and returned to main memory at a different location Memory references must be translated in the code to actual physical memory address. Protection: Processes should not be able to reference memory locations in another process without permission. The Operating System is in charge of this and it really is impossible for us to check addresses in programs since the program could be relocated by the operating system itself without us knowing. We have to trust the Operating System in how it does all of this. This is known as ‘process isolation’, which is how the o/s makes sure that processes don’t interfere with each other. Sharing: Allow several processes to access the same portion of memory. The operating system allows each process (person) access to the same copy of the program rather than have their own separate copy. Logical Organization: Programs are written in modules. Different degrees of protection given to modules (read-only, execute-only). Modules are shared. Physical Organization: Memory available for a program plus its data may be insufficient. Overlaying allows various modules to be assigned the same region of memory. Secondary memory is cheaper, larger capacity, and permanent.

Platform - Memory Management Addressing
There are three types of memory addresses: Logical - references to a memory location that is independent of the current assignment of data to memory. Requires a translation to the physical address Relative - address expressed as a location relative to a known point Physical - the absolute address or actual location

Virtual Memory Extends memory by using secondary storage for program pages not being executed. Composed of independent numbered segments.

Swapping In a Virtual Memory system, swapping is the act of transferring pages between physical memory and the swap space on the disk Pages are fixed blocks of memory usually 4KBytes or 8KBytes. Swapped Pages are stored on disk Pages are swapped into memory as needed A page fault is taken when a reference is taken to a non-resident Page Swapping and paging can be used interchangeably. Swap Space: A portion of the disk (backing store) reserved for the memory pages that are swapped to disk. Note: The term disk in the 1st bullet above. There are other backing store (swapping) devices besides disks. Page Fault: An exception when accessing VM usually resulting in a page being fetched from disk. A page fault is an exception occurring during the translation of virtual address to a physical address. "Page fault" usually means an access to a page that has been paged out and thus requires fetching from disk before use - (it can also mean invalid page fault or protection fault). Memory Mapping (AKA File Mapping) is the technique used to map a portion of a device to a memory page. When pages need to be paged out, a heuristic is used to select those that will not be needed soon; least recently used (LRU) is frequently used.

Paging Paging involves:
Splitting memory into equal sized, small chunks that are called page frames. Splitting programs (processes) into equal sized small chunks that are called pages. Allocate the required number page frames to a process. Operating System maintains list of free frames. A Virtual Memory system usually deals with memory blocks of fixed size as units for paging. These are known as pages. Pages are generally 4 or 8KBytes in length. The page size is determined by the addressing hardware of the machine (the Memory Management Unit).

Input/Output (I/O) Devices
The I/O controller is responsible for moving data in and out of memory. An element of managing the I/O devices and thus managing memory is through swapping or paging files.

Common Computer Architecture (I/O) Devices - Swapping and Paging
Paging is used to transfer data between the I/O device and main memory Hardware must support paging and segmentation. Operating system must be able to manage the movement of pages and/or segments between secondary memory and main memory.

Memory Protection Protection Benefits
Every reference checked for protection. Different data classes can be assigned different levels of protection. Two or more users can share access to same segment with potentially different access rights. User cannot generate an un-permitted address or gain access to an un-permitted segment.

Trusted Computing Base (TCB)
The Trusted Computing Base is the totality of protection mechanisms within a computer system - including hardware, firmware, software, processes, and some inter-process communications that combined are responsible for enforcing a security policy.

The TCB maintains the confidentiality and integrity of each domain and monitors four basic functions: Process activation Execution domain switching Memory protection Input/Output operation Process Activation: In a multiprogramming environment, activation and deactivation of processes creates the need for a complete change of registers, file access lists, process status information and other pointers, much of which is security sensitive information. Execution Domain Switching: Processes running in one domain often invoke processes in other domains to obtain more sensitive data or services. Memory Protection: Because each domain includes code and data stored in memory, the TCB must monitor memory references to ensure secrecy and integrity for each domain. I/O Operations: In some systems, software is involved in the transfer of characters to the I/O operation. This process connects a user program in the outer most domain with the I/O operation in the inner most. This cross domain connection must be monitored.

Two primary concepts: Subjects – Active entities - includes users, programs, processes, logon identifiers Objects – Passive entities - includes files, programs, data, hardware The definitions of subjects and objects. Programs can be either subjects or objects depending on the context and the role they play. Subjects are usually active entities and objects are usually passive entities.

Objects Requiring Protection
Operating System Table(s) Instructions (especially privileged) Passwords / Authentication Mechanisms Protection Mechanisms Memory File or Data Set Executing Program in Memory Directory of Files Hardware Device Data Structure

Reference Monitor Concept
Abstract machine that must mediate all access of subjects to objects. Features include: Must mediate all access Be protected from modification Be verifiable as correct Always be invoked

Reference Monitor Concept
Audit File Reference Monitor (Policy) Subjects Objects Security Kernel Database

Security Kernel The hardware, firmware, and software elements of a trusted computing base that implement the reference monitor concept.

Reference Monitor / Security Kernel
Complementary goals: Check every access Allow least privilege Verify acceptable usage Appropriate use Authorization Concept

Protection Concepts Subtopics
A computer system can use concepts such as the following for protection: Privilege levels Process Isolation Layering Data Hiding Ring Protection Security Domains Virtual Machines We’ll look at each of these over the next few slides.

Privilege Levels Subjects of higher trust can access more system instructions and operate in privileged mode Subjects with lower trust can only access a smaller portion of system instructions and operate in user mode A system can be operating in several different operation modes depending upon the tasks it is carrying out. For the system to protect itself it has different modes to ensure that rogue processes and applications do not negatively affect critical components. When an application is executing it is only allowed to access a small percentage of system resources and total instruction set, this is called user mode or non-privileged mode. The larger set of system instructions are available to more trusted entities such as the system administrator and processes of higher trust. When a computer is executing these privileged instructions it is operating in supervisor mode or privileged mode.

Process Isolation Preserve object’s integrity and subject’s adherence to access controls Prevents objects from interacting with each other and their resources Actions of one object should not affect the state of other objects

Process Isolation (cont.)
Encapsulation of objects Time multiplexing of shared resources Naming distinctions Virtual mapping Process isolation is the concept of isolating processes so that they don’t interfere with each other. The sub bullets listed are ways to achieve process isolation.

Layering and Data Hiding
Processes operate at different layers within a system and must communicate through interfaces Layers can be divided by functionality or security Data Hiding: If a process does not have an interface to another process at another layer, it cannot have access to its data Systems that meet certain trust levels must supply mechanisms that force processes to work in layers, which means certain functionality takes place in different layers of a system. This requires a structured and hierarchical architecture that has the basic functionality taking place at lower layers and more complex functions at the higher layers. Layering further separates processes and resources and adds modularity to the system. The different layers can communicate, but only through detailed interfaces that uphold the security integrity of the system. In some instances, it is required that processes in different layers do not communicate; therefore, they are not supplied with interfaces to interact with each other. This process is called data hiding in that the data in one layer is hidden because the subjects in another layer do not even know the data exists. If a subject in one layer has no interface to be able to communicate with data at another layer, this data is hidden from that subject.

Ring Protection 0 – O/S Kernel 1 – O/S 2 – Utilities 3 – User Apps 3 2
Note that the next slide provides more information on Ring Protection.

Ring Protection A set of segments in concentric numbered rings.
The ring number determines the access level. Procedure assumes ring number when executing. Procedure may access segment higher than its own. Ring “0” contains kernel functions of the operating system. A program may access only data that resides on the same ring, or a less privileged ring. A program may call services residing on the same, or a more privileged ring.

Security Domains Sometimes referred to as a ‘execution’ or ‘protection’ domain. Includes all objects that a subject has access to. Processes can have a wide range of resources available to them, it is their security domains that specify what resources are actually available. Note Developing and maintaining the execution domain for a process is the responsibility of the kernel

Virtual Machines Virtual machines mimic the architecture of the actual system and on multilevel systems they can run at different security levels. An operating system provides an application a working environment When an application runs on a computer, it thinks it is the only program running and it does not necessarily know that it is sharing resources with several other types of programs, applications, and processes. This simplifies the issues that programmers need to be concerned about when writing an application. Because the application thinks it is the only one executing, it needs to be presented with an environment that reflects this type of reality. This is done through virtual machines and virtual memory. The operating system creates a virtual environment (virtual machine) for the application to work in and allots it a segment of virtual memory. Another application could have its own virtual machine and virtual address segment and the two would not know that each other even existed. This way the two applications do not interact with each other’s data in memory or step on each other’s toes while being executed by the CPU. It is a very orchestrated, controlled, and timed event-oriented atmosphere. Note The actual system is referred to as the “real machine” and created environments as “virtual machines”.

Operating System Protection Subtopics
User Identification and Authentication Discretionary access control Mandatory access control Complete mediation Object reuse protection Audit Audit log reduction Trusted path Intrusion Detection These are the typical characteristics of the design of a Trusted Operating System and associated processes that provide both the features and assurance necessary to ensure implementation of a trusted system. The problem of object reuse is not limited to disks, but can occur in main memory, processor registers and storage and other magnetic media or any other reusable storage medium. Complete Mediation: Clearly for mandatory or discretionary access control to be effective, ALL accesses must be controlled. It is insufficient to control only file access if the attack will require access through memory or an outside port or network.

Operating System Protection
User Identification and Authentication Must authenticate or verify users to the system Discretionary access control All object access control left to owner Mandatory access control Access control decisions jointly controlled by object owner and the system

Complete mediation All accesses must be intercepted and verified Difficult as more paths are created Object reuse protection Memory leakage Magnetic Remanence Audit Security-relevant events Protection of audit logs Object Reuse: the process of re-using objects within the system. What we want is ‘secure’ object reuse which means we want to be able to securely remove any sensitive information from the object before it is re-assigned for reuse to another subject. Leakage: inadvertent availability (failure of an application to clean itself up after usage and before the next process is used.)

Audit log reduction Volume and analysis problem Simplification Correlation Trusted path Protection of critical operations Intrusion Detection Patterns, Analysis, Recognition It is clear that security-relevant events (tied to the individual user creating the event) must be captured to ensure that overall accountability is maintained. These logs must be protected to ensure they are available for later analysis and other forensic purposes. Because the potential volume of events that can be recorded is huge, one may want to simplify the process by reducing the types of events that are recorded. The choice of what is “logged” is one that must be made on the circumstances and environment within which the system operates. Because there are many different logs (even in individual operating systems), the ability to correlate the log content in the time domain is often very important in identifying security relevant events that the information recorded in a single log may not. Even correlation within a single log is important because the attacker may attempt to defeat the system by pacing the attack below what would normally be the threshold for recognition by the system (the low and slow approach). This in effect is making sure that the attack is slow enough to operate below our ‘clipping levels.’ Trusted Path definition (Common Criteria): A trusted path is a means by which a user and a TSF (Target of Evaluation Security Function) can communicate with necessary confidence to support the TSP (Target of Evaluation Security Policy). A better definition of the Trusted Path is the Orange Book definition: A mechanism by which a person at a terminal can communicate directly with the TCB. This mechanism can only be activated by the person or the TCB and cannot be initiated by untrusted software. The communication cannot be intercepted en route.

Assurance, Trust, and Confidence
Audit Log Processing Host audit logs Network device logs Intrusion Detection reports Security Reviews Vulnerability Assessment System and Network Audits Attack and Penetration Tests

Product Evaluation Criteria
Trusted Computer System Evaluation Criteria (TCSEC) - The Orange Book Trusted Network Interpretation (TNI) - The Red Book Information Technology Security Evaluation Criteria (ITSEC) Common Criteria

Common Criteria ISO 15408 Provides a common structure and language for expressing product/system security evaluations and requirements Provides a catalog of standardized security requirement components and packages

Parts of the Common Criteria
Part One: Introduction and General model Part Two: Security Functional Requirements (defines 11 security functional components - Security Functional Requirements) Part Three: Security Assurance Requirements (establishes a set of assurance components - Evaluation Assurance Levels)

Common Criteria Goals Have a single international (common) product and system security criteria. Resolve conceptual and technical differences between the various source criteria. Provide an international mutual recognition of product evaluation. Level international playing field for developers Provide world-wide availability of security-capable products.

Common Criteria Key Terms
Protection Profile (PP) - an implementation-independent set of security functional and assurance requirements for a category of products that meet specific consumer needs. Security Functional Requirements - requirements, that when taken together, specify the security capabilities of a product or system. Security Assurance Requirements – address the confidence in the security capabilities of a product or system.

Common Criteria Key Terms (cont.)
Security Target (ST) - a set of security functional and assurance requirements and specifications to be used as the basis for evaluation of an identified product or system. Target of Evaluation (TOE) - another name for a product or system described in a Protection Profile or Security Target. The TOE is the entity that is subject to security evaluation.

Common Criteria Key Terms (cont.)
Evaluation - assessment of a product or system against defined security functional and assurance criteria, performed by a combination of testing and analytic techniques. Evaluation Assurance Level (EAL) - one of seven increasingly rigorous levels of assurance requirements. An EAL can be considered a level of confidence in the security functions of a product or system.

Common Criteria Security Requirements
The CC defines two types of Security Requirements: Functional Requirements Defining security capabilities of the product or system: Implemented requirements become security functions (what a product does) Assurance Requirements Establishing confidence in Security Functions: Correctness of implementation Effectiveness in satisfying objectives (is the product built well and does it meet the purpose)

Common Criteria Flow Protection Profile Target of Evaluation Security
Category of Product (i.e., “firewalls”) EAL Levels 1 Functionally Tested 2 Structurally Tested 3 Methodically Tested 4 Methodically Designed, Tested, Reviewed 5 Semiformal testing 6 Semiformal verification 7 Formal verification and testing Target of Evaluation Specific Product (i.e., Checkpoint-1) Vendor claims: Specifications and features Security Target DOMAIN: Architecture This slide is intended to display the relationship among the Common Criteria terms and put them into perspective Certification and Accreditation are the final steps and are based on the actual mode of operations, configurations and interconnections that will exist in the production environment where the system or device will be deployed. Based on production environment Functional Requirements Assurance Requirements Certification TEST plan based on stated requirements Evaluation Accreditation

Quick Quiz What hardware resources are controlled by the operating system? What are the five requirements for memory management? What is the input/output controller responsible for? What is a Trusted Computing Base? Explore: Instructor should use these questions to drive general discussion. Don’t directly give the answers, only curb responses that are clearly incorrect. Try to see what responses the participants can provide. The section summary on the following page answers these questions directly. Use the section summary to highlight any points not clearly driven out during the quiz discussion.

Section Summary Memory, CPU, storage devices, and input/output requests and devices are controlled by the operating system. The five requirements for memory management are relocation, protection, sharing, logical organization, and physical organization. The input/output controller is responsible for moving data in and out of memory. The Trusted Computing Base is the totality of protection mechanisms within a computer system.

Enterprise Security Architecture Security Models

Section Objectives Describe the difference between infrastructure and architecture List the benefits of an enterprise security architecture List the key components of an enterprise security program Define IT security principles

Infrastructure vs. Architecture
Infrastructure refers to the supporting elements needed for functionality Architecture refers to the cohesive design of the elements.

Objectives of an Enterprise Security Architecture
Guidance for decision makers. The resulting business and security decisions will be strategically aligned and consistent across the enterprise. Provides specific security-related guidance to decision makers.

Objectives of an Enterprise Security Architecture (cont.)
Security-related input into IT technology, system and application design. Ensures application of security best practices. Describes security zones, to compartmentalize the enterprise security environment.

The Enterprise Security Architecture…
Strategic – longer life than a blueprint, design specification, topology or configuration Constrained by current or changing circumstances if too specific, Cannot provide good guidance if it is too general, Support long term view of technical direction, not short term technical constraints, Not invalidated by changes in technical direction

The Enterprise Security Architecture… (cont.)
Business centered acceptance and management of risk Allows for multiple implementations depending on requirements Guidance for implementation of security for internal and external organizations Interoperability Integration Ease-of-use Standardization

Benefits of an Enterprise Security Architecture
Consistently manage IT risk across the enterprise while leveraging industry best practices. Reduce the costs of managing IT risk and improve flexibility by implementing common security solutions across the enterprise. Allow decision makers to make better and quicker security-related decisions across the enterprise. Promote interoperability, integration and ease-of-access while effectively managing risk. Provide a reference for guidance to other organizations interacting with the enterprise.

Management’s Expectations
Mitigate risk First need to know what risk is present. Enhance user productivity Security should not get in the way of productivity. Reduce Cost Most security is assumed to be built in. Streamline Application Development/Integration Security must not inhibit applications. In other words: protect the company, make it easy for users, don’t stand in the way of progress and do it as cheaply as possible.

Lack of Enterprise Security Approach Symptoms
Lack of an enterprise security approach is evidenced through many symptoms Unable to quickly, and effectively, support increased user access requirements (regardless of location and type of end-user) while containing and controlling associated costs. Inability to readily identify or understand exposures from the greater number of access points introduced by Portals and Internet-based solutions. Increased consumer complaints about misuse of personal and confidential information. IT and the affected business units do not both fully understand the more stringent regulatory and legal compliance requirements. Difficulty in supporting e-commerce business models while at same time maintaining a legacy infrastructure.

The Challenges Fiduciary responsibilities Data confidentiality
Upstream and downstream liability Legal & Regulatory Different business models Mergers Changing technologies Interfaces with legacy systems End-to-End Security Challenges Greater number of user access points Global Access The variety and location of those that need to interact electronically with the organization is putting major pressure on accepting the risks associated with this new model The legal requirements are also forcing controls on organizations PIPEDA – Personal Information Protection and Electronic Documents Act (Canada) HIPAA – Health Information Portability and Accountability Act (US) B2B – business to business B2C – business to consumer B2G – business to government The impact from the lack of an enterprise security approach is evidenced through many symptoms Unable to quickly, and effectively, support increased user access requirements (regardless of location and type of end-user) while containing and controlling associated costs. Not able to readily identify or understand exposures from the greater number of access points introduced by Portals and Internet-based solutions. Increased consumer complaints about misuse of personal and confidential information. IT and the affected business units do not both fully understand the more stringent regulatory and legal compliance requirements. Difficulty in supporting e-commerce business models while at same time maintaining a legacy infrastructure.

There is Much at Stake Crackers impersonating a major automobile manufacturer’s employees stole credit reports of 13,000 consumers from credit reporting agency Experian (Security Wire Digest, Jun 2002) An employee sabotaged important tests indicating lower performance results that cost $ millions in resources and lost sales; reformatted important computer disks, cut cables, and altered logs - over $1 million spent trying to fix the problem (ABC News, Jun 2002) Viruses and denial of service attacks, illustrated by the recent worms, cost companies billions last year (Information Week, Feb 2002)

Holistic Security Approach
A robust, holistic Enterprise Security program environment allows organizations to Shift from an IT-centric to a business-centric security process to more effectively manage risk. Link organizational, technical, administrative and physical security controls To business drivers, legal requirements, threat scenarios and design. And ensure they are operationally integrated with the overall IT architecture, business processes and business culture.

Enterprise Solution vs Point Solution Approach
An Enterprise Solution Approach Provides executive management support through strategic alignment – resulting in consistent security decisions, planning and investments, Facilitates accountability, authority and responsibility across the organization, Provides an integrated and leveraged set of security solutions with long lasting value, Provides a focal point for eliminating root cause problems and identifying improvement opportunities, and Reduces total-cost-of-ownership by consolidating management and eliminating overhead A Point Solution Approach Lacks executive management support, Results in IT management oversight without appropriate executive management support, Lack of executive management visibility, Allows one-off fixes that are not integrated nor leveraged as long-term investments, Is focused on solving immediate problems which will most likely recur over time, and Results in an increased total-cost-of- ownership and disruption from overhead, redundancies and conflicts Point security solutions only address a thin layer of technical functionality The acceptance of risk needs to be based on a business decision, not the agreement to use a type of technology. There is overall benefit to planning and implementing an architecture.

Management Processes –
Key Components Management Processes – Leveraging Foundational Designs, business management processes are refined and calibrated to efficiently integrate security standards and expertise throughout the system development lifecycle and day-to-day operations – evolutionary integration of security across the enterprise Architectures Architectures – Standards-based, business driven security blueprints are used to develop and implement an enterprise-level security program, architecture and operating model – core security program and architecture established Management Processes Processes & Methods Roles & Responsibilities Tools / Enablers Awareness Solution Implementation Compliance / Monitoring The Enterprise security program has a repeatable life cycle of which one of the important elements is the security architecture. Compliance / Monitoring – Monitoring solutions are established to allow mid-level and senior management to monitor and report security performance effectiveness by measuring key performance indicators – is everything ok? Solution Implementation – Security for Business Applications and Architectures is defined, developed and deployed consistent with the organization’s desired risk profile and Foundational Designs – end-to-end transaction integrity achieved

Typical IT Security Architecture
This should be the “end game”, not the starting point The typical representation of a security architecture tends to be technical representing computer and network facilities. Many times, this is what is presented as the product/deliverable of the security architecture. This type of diagram can be generated using the security architecture as a base. However, the resulting ‘network’ should be a product of the architecture needs and not the starting point.

Process Framework The business and technology trends as well as the external competitions derives the business drivers. The business drivers determine business needs and security concerns, which further defines the security requirements. To establish the security solution, the security strategies depict the security principles and the concept of operations. Understand and articulate all of these steps These provide a firm foundation ‘model’ in Security Architecture block – rules that we have to follow. ‘organization’ in Security Architecture block – how the components are organized together. The security architecture defines the solution components that support the overall security strategies.

Security Pathing Security Capability Evolution Assurance
Security Organizational Structure Enterprise Security Controls Documented Strategy, Principles and Policy Security Metrics Security Capability Initiate Stakeholder Security Program Compliance and Certification Security Architecture Security Technical Framework The security architecture is only one stage of the IT security journey An effective organization will complete each of the steps on the chart at some time Assurance Auditing, monitoring, and reporting processes and controls in place to ensure they are meeting standards and are effective Security Metrics Measure the efficiency, effectiveness, value and continuous performance improvement of the individual security process Compliance and Certification Establish compliance measurement and reporting system Security Technical Framework Establishment of methods and technologies to support stakeholder interaction Security Architecture Architecture principles and policies in place to define core security functions Initiate Stakeholder Security Program Stakeholder sponsored program with responsibilities assigned Documented Strategy, Principles and Policy Clearly defined set of technology-independent policies developed from the business strategy Security Organizational Structure Individuals and organizations assigned responsibility, accountability and authority to support the infrastructure Enterprise Security Controls Security controls defined to establish a consistent basis for managing risk Evolution

Enterprise Security Architecture Key Security Decision Areas
Key security decisions provide the basis for consistency across the architecture: Security Zones The recognition and definition of the various relationships and boundaries between the organization and business partners A framework to support the criteria for a consistent approach to managing risk and supporting security policy Information Classification Recognition and consistent definition of the various levels of security sensitivity attached to information. Definition of the requirements and treatment of information according to its classification of security sensitivity These two decisions provide an important basis for the architecture objectives and decisions. Security zones provide a way of anchoring security decisions – especially when transiting from one zone to another. The policy on information classification must be consistent throughout the enterprise to be able to use the policy as the base for decisions. Good decisions will not be possible if the meaning of the classifications of data is different.

Enterprise Security Architecture Zones Based on Trust
Effective network security is established by understanding network “access points and vulnerabilities” and developing countermeasures for “end-to-end” information protection General Internet Connection Zone Proxy Servers Mail Relay Servers Forwarding DNS Web Caching Servers VPN Connection Zone Internet Ingress Private Network VPN Ingress Authentication, Authorization, Administration Services E-Business Hosting Zone Web Servers Internet Applications Servers Authoritative DNS User LAN Zone Desktop Computers Laptop Computers Kiosks Printers Data Center Zone Intranet Applications Extranet Applications Internal Applications File and Print Servers Mainframe, Database Directory Services Dial-up Connectivity Zone Remote Access Servers Terminal Services Wireless Connectivity Zone Access Points WAN Connectivity Zone WAN Routers controlling: Suppliers Partners Remote Offices, Branches Other third-parties

Architecture Definition Process
Security Principles The IT Security Principles reflect current business and security decisions. Define the security architecture principles and strategy. Define the detailed Security Architecture with increasing levels of elaboration. The Technical Framework provides the specific technical criteria for implementation. Security Architecture Principles Detailed Security Architecture This is a typical process that we would follow to generate a security architecture. The architecture establishes three levels of elaboration (conceptual, functional and operational). What problem am I going to solve? (Conceptual) Basically this is “what security functionality do I need to support the security policy decisions that I have made (Functional)? How am I going to deliver the required functions?(Operational). Technical Framework

IT Security Principles
Are fundamental statements of value, operation or belief that defines the overall approach to IT security, Define the philosophy of the organization that directs the definition of the security policies, Will require formal commitment from the executives to be relied upon for guidance, and Often are challenging to define. May require assistance with scope definition and management, issue validation, and the definition of the resulting Security Principles. Need IT Security Principles as the basis for security decision. These are the laws that you do not violate.

Enterprise Security Architecture
The security architecture must address all components of the enterprise security program not just the technical components: Strategic alignment Process enhancement Business Enablement Security Foundation Aligned with best practices Shows inter-relationships The architecture should guide the blueprints We will discuss each of these sections over the next few slides. See the next slide for a graphic description of this concept

Strategic Alignment KEY COMPONENTS Executive Level Sponsorship
C level executives Current Profile Threat orientation Current state assessment Risk tolerance Change readiness assessment Security Strategy Business drivers and IT strategies Business and regulatory drivers “To Be” security framework 3 year operating model Security Foundation Key Components Need executive level sponsorship for the architecture, it has to be enterprise wide and mandatory in order to have an enterprise wide approach to risk A current status of the enterprise approach to IT risk will provide the “IT Security Culture” to gauge what the architecture has to be to be effective and how it will be received. How ready is the organization to adapt to change. Is the architecture going to be a significant change from where they are today. How much has the corporate approach to IT Security been considered. What are the business issues, and strategies that are defined that require an organized approach to IT security? The more the architecture requirements can be directly tied to the business the better. Is there legislation or regulations that are pushing the organization tin a certain direction?

Strategic Alignment (cont.)
KEY CONSIDERATIONS Active executive participation Owner, custodian, stakeholder alignment Assigned responsibility, accountability and authority Security Life Cycle Business and IT alignment Security process and management fundamentals/foundations/baseline versus with ‘wants’ All Stakeholders speaking the ‘same language’ Key Considerations The architecture also must have an identified owner Who is responsible for defining, reviewing, approving, enforcing? How will the architecture fit into the IT Security Lifecycle (TRA, policies, implementation admin etc.) The business requirements and IT requirements must be aligned and inter-related The architecture should be an obvious progression from the business requirements and justifiable as such. It should not be based on the current “wants” that is more typical with technology selection. Many security architectures are arrived at by surprise based on installed technology rather than considered thought or planning. The vendors will try to make the organization “Want” technology without the business reason “why”.

Business Enablement - End-to-end transaction integrity
KEY COMPONENTS Security Solution Diagnostic Policy and Standards Organizational Alignment Technical Control Architecture Process Alignment Awareness and Training Compliance and Assurance Security Solution Methodologies Information Security Risk Assessment System Analysis and Design Solution Specific Templates Next component is ‘business enablement’, which is made of the listed components and considerations.

Business Enablement - End-to-end transaction integrity
KEY CONSIDERATIONS People, process and technology driven requirements Consistent application of solution models Zone analysis for end-to-end transaction integrity Security Plans practically applied to all aspects of a business’ operation – network, applications, processes, etc.

Process Enhancement - Evolutionary integration and consistent execution of security across the enterprise KEY COMPONENTS Security Criteria Philosophy/ Models Core Enterprise Processes Architecture, Engineering Project & Risk Management IT Operations Management Security Champions Subject Matter Experts Awareness & Training Security Communication Portal Self Service Knowledge Management Next component is process enhancement.

Process Enhancement - Evolutionary integration and consistent execution of security across the enterprise KEY CONSIDERATIONS Key security standards, model and criteria proactively championed through existing enterprise-wide management processes Center of Excellence (COE) approach Breadth of coverage – end-to-end transaction Depth – subject experts Facilitator roles versus owner Incentive concept to promote security staff as enablers versus roadblocks Roles and responsibilities clearly defined and championed

Security Foundation - Core security program and architecture established
KEY COMPONENTS Security Management Plan Program, Organization, Administration Business Continuity Management Plan Infrastructure Security Plan Physical and Environmental Systems & Network Infrastructure Logging, Monitoring & Reporting Application Integrity Plan Identity Management Plan Privacy Plan Next is ‘security foundation’.

Security Foundation - Core security program and architecture established
KEY CONSIDERATIONS Active executive participation Owner, custodian, stakeholder alignment Assigned responsibility, accountability and authority Security Life Cycle Business and IT alignment Security process and management fundamentals/foundations/baseline versus ‘wants’

Security Effectiveness
KEY COMPONENTS Key Performance Indicators High Risk Elements Critical Resources Core Management Processes Customer Satisfaction Information Structure Presentation and Reporting Metrics Source Data Compliance Monitoring Internal and External Audit Plans Regulatory IT Scanning / Self-Assessments Next component: security effectiveness, which is really addressing the ‘assurance’ part of the security solution, ‘how do we know that the solution is actually working properly?’

Security Effectiveness
KEY CONSIDERATIONS Focus on a few critical objective indicators that truly enhance visibility Internal audit alignment Communication of successes/failures Service Level Agreements (SLA) for customer satisfaction IT Return on Investment (ROI) Critical vendor maintenance contracts Metrics for day-to-day operations Reporting timelines Existing balanced scorecard system

Enterprise Security Architecture Components
Established common architecture language? Principles including motivation and implications Established architecture model? Used for iterative levels of architecture elaboration Provides guidance to multiple levels in the organization The Zachman Framework is a popular choice to defining an Enterprise Architecture provides a two dimensional classification scheme for descriptive representations of an Enterprise. The needed components of any enterprise security architecture. They are: A common architecture language, which addresses and ensures you can deal with your security principles, A architecture model, which allows you to build nested architectures (all addressing the needs and goals of the organization) as well as guidance to all levels of the organization. The Zachman model is a popular choice today for enterprise architectures, because it’s a two-dimensional representation of the needed components of any architecture. The Zachman Framework has gained wide acceptance in the industry. It will be shown over the next couple of slides.

Zachman Architecture Framework Rows
The rows represent six “levels” of architectures or views with increasing levels of detail *Note – Security Architecture is not a view but rather provides components and supports many other “views” Intent The Zachman Framework is influenced by principles of classical architecture that establish a common vocabulary and set of perspectives for describing complex enterprise systems. This influence is reflected in the set of rules that govern an ordered set of relationships that are balanced and orthogonal. By designing a system according to these rules, the architect can be assured of a design that is clean, easy to understand, balanced, and complete in itself. Zachman's Framework provides the blueprint, or architecture, for an organization's information infrastructure. Scope The Zachman Framework describes a holistic model of an enterprise's information infrastructure from six perspectives: planner (ballpark view), owner, architect, designer, builder, and the working system. There is no guidance on sequence, process, or implementation of the framework. The focus is on ensuring that all aspects of an enterprise are well-organized and exhibit clear relationships that will ensure a complete system regardless of the order in which they are established. Principles By defining clear architectural design principles, Zachman ensures that any tailored or extended implementation will be equally well built as long as the designer and builder continue to follow the rules. The major principles that guide the application of the Zachman Framework include: A complete system can be modeled by depicting answers to the questions why, who, what, how, where, and when. The six perspectives capture all the critical models required for system development. The constraints for each perspective are additive; those of a lower row are added to those of the rows above to provide a growing number of restrictions. The columns represent different abstractions in an effort to reduce the complexity of any single model that is built. The columns have no order. The model in each column must be unique. Each row represents a unique perspective. Each cell is unique. The inherent logic is recursive. Structure The Zachman Framework is a simple concept with powerful implications. By understanding any particular aspect of a system at any point in its development, system designers construct a tool that can be very useful in making decisions about changes or extensions. The framework contains 6 rows and 6 columns yielding 36 unique cells or aspects. This can be seen in the framework diagram. The rows are separated as follows: The Zachman Framework Scope( ballpark view). Corresponds to an executive summary for a planner who wants an estimate of the size, cost, and functionality of the system. Business model (owner’s view). Shows all the business entities and processes and how they interact. System model (architect’s view). Used by a systems analyst who must determine the data elements and software functions that represent the business model. Technology model (designer’s view). Considers the constraints of tools, technology, and materials. Components (builder’s view). Represent individual, independent modules that can be allocated to contractors for implementation. Working system (function system). Depicts the operational system. The columns are separated as follows: Who. Represents the people relationships within the enterprise. The design of the enterprise organization has to do with the allocation of work and the structure of authority and responsibility. The vertical dimension represents delegation of authority, and the horizontal represents the assignment of responsibility. When. Represents time, or the event relationships that establish performance criteria and quantitative levels for enterprise resources. This is useful for designing the master schedule, the processing architecture, control architecture, and timing devices. Why. Describes the motivations of the enterprise. This reveals the enterprise goals and objectives, business plan, knowledge architecture, and knowledge design. What. Describes the entities involved in each perspective of the enterprise. Examples include business objects, system data, relational tables, or field definitions. How. Shows the functions within each perspective. Examples include business processes, software application function, computer hardware function, and language control loop. Where. Shows locations and interconnections within the enterprise. This includes major business geographical locations, separate sections within a logistics network, allocation of system nodes, or even memory addresses within the system. Cont’d on next slide…….

Zachman Architecture Framework Columns
The columns represent a different area of interest for each view using the six “abstractions”. These define the independent variables that form a comprehensive depiction of the subject or object being described. Guidance Most of the prescriptive guidance is given through consulting services contracted through the Zachman Institute. Although no architectural development process is described in publications, there are several observations that can help organizations use the framework more effectively. The perspectives or rows are very abstract and incomplete near the top but become progressively more detailed and specific moving toward the bottom until an implementation emerges on the last row. This implies that the perspectives can be mapped to a product development life cycle where the top rows are used early on while the bottom rows become more important during the latter phases. The top two rows are intensively business-oriented and can be expressed in business-oriented vocabularies, while the bottom four rows are in the technical domain. Although Zachman's models are explicitly procedural, there is no reason why the representation applied to each square in the framework could not be object-oriented. Business concepts from the top row must be embedded into business objects and components in the bottom rows. The business concepts can be refined over time, but their relationships should not be changed. Generic software objects and components, along with those from a specific domain repository, can be selected to populate the foundation of the system, but specific application-oriented objects must be designed and integrated to implement the system under development. Because the order of the columns has no prescribed meaning, they could be rearranged to more closely follow the order of object-oriented design. The requirements are captured in the why column, and the actors are associated with the who column. Because it is generally recommended that service identification precede objects, then the how and what columns can follow. Regardless of the chosen order, note that the columns are related as in the software: the data represent inputs and outputs of the services. The when column can precede the where column if that precedence is more meaningful to a particular software development process, but the point being made is that the order of the columns can be used to facilitate discussion during object-oriented development. Frameworks can be used recursively to manage the complexity of specifying an EA. In this case, the top framework instance represents enterprise modeling of the entire business, the middle framework instance represents enterprise modeling of an independent division in another instance, and the bottom framework instance represents enterprise modeling of independent workstations. This is only an example of how a complex problem can be partitioned into simpler pieces, while each piece can be modeled in it own right with the Zachman Framework. One framework can be used to develop the technical architecture at a level that will apply to all divisions in the business. Another framework can be used to develop departmental networks, which must conform to all constraints specified at the enterprise level. Yet another framework can be used to develop and manage the configuration of an independent workstation, which conforms to all constraints developed at the division or departmental level.

Quick Quiz What is the difference between infrastructure and architecture? What are some of the benefits of an enterprise security architecture? What are the key components of an enterprise security program? Explore: Instructor should use these questions to drive general discussion. Don’t directly give the answers, only curb responses that are clearly incorrect. Try to see what responses the participants can provide. The section summary on the following page answers these questions directly. Use the section summary to highlight any points not clearly driven out during the quiz discussion.

Section Summary Infrastructure refers to the supporting elements needed for functionality, while architecture refers to the cohesive design of the elements. An enterprise security architecture allows an organization to consistently manage IT risk across the enterprise while leveraging industry best practices. The key components of an enterprise security program are architecture, management processes, solution implementation, and compliance/monitoring. Explain: Note that there are multiple benefits to an enterprise security architecture. In the event that the participants did not touch on most of the benefits, refer to the list below. -Reduce the costs of managing IT risk and improve flexibility by implementing common security solutions across the enterprise. -Allow decision makers to make better and quicker security-related decisions across the enterprise. -Promote interoperability, integration and ease-of-access while effectively managing risk. -Provide a reference for guidance to other organizations interacting with the enterprise.

Security Models Common Computer Architecture
Enterprise Security Architecture Security Models Bell-LaPadula Confidentiality Model Biba Integrity Model Clark and Wilson Integrity Model Access Control Matrix Information Flow Model Brewer and Nash Model Other Models Models are often used, both in security and in other areas, to describe, study, or analyze a particular case. In security, models are used to: - Test a particular policy for completeness and consistency - Document a policy - Help conceptualize and design an implementation - Check whether an implementation meets its requirements There are two purposes to studying models of computer security. First, models are important in determining the policies a secure system should enforce. Second, abstract models can lead to an understanding of the properties of a protection system. These characteristics are important for the designer or architect of a system or network to know.

Section Objectives List the key security models
Describe the Bell-LaPadula Confidentiality Model Describe the Biba Integrity Model Describe the Clark and Wilson Integrity Model Describe the Brewer and Nash Model

Bell-LaPadula Confidentiality Model
Formal treatment of information confidentiality issues. Defines notion (concept) of secure state. Secure state – access is only permitted in accordance with specific security policy. Secure state is when rules are security-preserving. The authors are David Bell and Leonard LaPadula.

Bell-LaPadula Confidentiality Model (cont.)
Defines fundamental modes of access. Read only, write only, or read and write. Rules for giving subjects access to objects. Dominance Relation Clearances of subjects to classifications of objects. Discretionary Security Property Specific subject authorized for particular mode of access.

Bell-LaPadula introduced the following concepts: Simple security property Subject cannot read object of higher sensitivity. Star property (* property) Subject cannot write to object of lower sensitivity. Strong Star property (Strong * property) Subject cannot read/write to object of higher/lower sensitivity.

Layer of Higher Secrecy Reading Secrets Reading Secrets X X READ WRITE READ/WRITE Divulging Secrets Divulging Secrets X X Layer of Lower Secrecy This is a diagram to help explain the Bell-LaPadula model. Let’s assume there are 3 layers of secrecy or sensitivity regarding our data - the layer our data resides in, a layer of higher secrecy, and a layer of lower secrecy. 1. The Simple Security Property says that if you have Read capability, you can read data at your level of secrecy, you can read data at a lower layer of secrecy, but you must not read data at a higher layer of secrecy. Otherwise, you would be reading secrets you are not entitled to read. 2. The Star Property says that if you have Write capability, you can write data at your level of secrecy, you can write your secret data to a higher layer of secrecy without compromising its value, but you must not write your secret data to a lower layer of secrecy. Otherwise, you would be divulging your secrets to others who are not entitled to see it. 3. The Strong Star Property says that if you have both Read and Write capabilities, you can read and write your data to your level of secrecy, but you cannot read and write to levels of higher secrecy or lower secrecy. Otherwise, you would have the problems experienced by the previous 2 properties. To help you remember this model, call the model the “Read Down - Write Up” model. Simple Security Property Strong Star Property Star Property

Biba Integrity Model First to address integrity in computer systems.
Based on hierarchical lattice of integrity levels. Elements Set of subjects (Active, information processing) Set of objects (Passive, information repository) Addresses first goal of integrity Prevent unauthorized users from making modifications. Mathematical dual of confidentiality policy Access tuple: subject & object Biba’s model was published in 1977 and only addresses external integrity threats because Biba was convinced that external integrity was the only issue. He argued that internal integrity threats could be adequately dealt with through testing. The mathematical dual of confidentiality policy is a reference to the fact that Biba described the model in a form of predicate calculus, a first order logic, which so precisely defines the relationships between subjects and objects that the policies defining the relationships are virtually mathematical.

Biba Integrity Model (cont.)
Strict integrity policy: Simple integrity condition Subject cannot read objects of lesser integrity. Integrity star * property Subject cannot write to objects of higher integrity. Invocation property Subject cannot send messages (logical request for service) to subjects of higher integrity. Invocation is a logical request for service from one subject to another. Since the control state of the invoked subject is a function of the fact that the subject was invoked, invocation is a special case of modification. Therefore, this rule follows directly from the Integrity *-property.

Biba Integrity Model (cont.)
Layer of higher accuracy Contamination X READ WRITE Get Contaminated X Layer of lower accuracy This is a diagram to help explain the Biba model. Let’s assume there are 3 layers of accuracy or integrity regarding our data - the layer our data resides in, a layer of higher accuracy, and a layer of lower accuracy. 1. The Simple Integrity Property says that if you have Read capability, you can read in data at your level of accuracy, you can read in data from a higher layer of accuracy, but you must not read in data from a lower layer of accuracy. Otherwise, you would risk contaminating the accuracy of your data. 2. The Integrity Star Property says that if you have Write capability, you can write data at your level of accuracy, you can write your accurate data to a lower layer of accuracy without compromising the accuracy at that layer, but you must not write your accurate data to a higher layer of accuracy. Otherwise, you would risk contaminating the data at that higher layer. You’ll notice that this diagram is almost the exact opposite of the Bell-LaPadula model. To help you remember this model, call it the “Read Up - Write Down” model. Simple Integrity Property Integrity Star Property

Clark and Wilson Integrity Model
Addresses all three integrity goals. Preventing unauthorized users from making modifications. Preventing authorized users from making improper modifications. Maintaining internal and external consistency. Well-formed transaction Preserve/ensure internal consistency. User can manipulate data only in ways that ensure internal consistency. Published in 1987, the Clark Wilson model adds a focus on authorized user’s unauthorized acts and internal integrity threats, both of which were missing from Biba’s model. A major internal integrity issue is does the software do what it is supposed to do.

Clark and Wilson Integrity Model (cont.)
Separation of Duty Attempts ensure external consistency and second goal Operation divided into sub parts Different person executes each part Ensures external consistency (data represents real world) Prevents authorized users from unauthorized modifications You use separation of duties to force collusion. We don’t want an individual to be in a position to be able to do something wrong by themselves. Then we use rotation of duties, in part, to break up collusion.

Clark and Wilson Integrity Model (cont.)
Access Triple Subject – Program – Object Enforced by subject (user)-to-program & program-to-object (data) binding. Implements first integrity goal & separation of duties. A subject’s access is controlled by the authorization to execute the program (well formed transaction). Therefore, unauthorized users cannot execute program (first integrity rule) and authorized users could each access different programs that allow each to make specific, unique changes (separation of duties).

Access Control Matrix State machine model specifying modes of access
Subject-subject or subject-object One row per subject One column per subject and object Access control matrix can be used for both confidentiality and integrity. Confidentiality by controlling “read” operations and integrity by controlling “write” operations.

Access Control Matrix (cont.)
User Axis & Resource Axis Object

Information Flow Model
Variation of access control matrix. An information flow model is based on object security levels. Object-object information flow is constrained in accordance with object's security attributes. Covert channel analysis is simplified. The Flow model is based on object security levels - information can flow to the same or higher level. Covert channel analysis is simplified because you are now able to track data from start to finish.

Information Flow Model
Object Axis Object Axis

Brewer and Nash Model – Chinese Wall Security Policy
Published in 1989 to ensure fair competition Mathematical theory used to implement dynamically changing access permissions. Defines a wall and develops a set of rules that ensure that no subject accesses objects on the other side of the wall. Individuals are only allowed to access data that is not in conflict with data they accessed previously.

Brewer and Nash Model (cont.)
It allows controls to be put into place to ensure that there is no conflict of interest. If a user accesses one company’s data, the competitor’s data can automatically be deemed “off limits”. Way of separating competitors’ data within the same integrated database. Tries to ensure that users do not make fraudulent modifications to objects.

Brewer and Nash Model Wall Organization X Organization Y Data Data
Conflict of Interest – Off Limits

Other Security Models Non-interference model - ways to prevent subjects operating in one domain from affecting each other in violation of security policy. State machine model - abstract math model where state variables represent the system state. The transition functions define system moves between states. Graham-Denning Model - Formal system of protection rules. Graham-Denning Model – introduces a formal concept of protection rules which operate on primitive rights listed below. Formal system of protection rules Primitive rights: Create Object Create subject, delete object, delete subject Grant access rights Delete access rights Transfer access rights

Other Security Models Harrison-Ruzzo-Ullman Result - variation on Graham-Denning model. In a model system, where commands are restricted to a single operation each, it is possible to decide whether a given subject can ever obtain a particular right to a given object. If commands are not restricted to one operation each, it is not always decidable whether a given protection system can confer a given right. More granular Graham Denning model

Quick Quiz What are the key concepts that the Bell-LaPadula confidentiality model introduced? What was the first security model to address integrity in computer systems? Does the Clark and Wilson Integrity Model address all three integrity goals?

Section Summary The Bell-LaPadula Confidentiality Model introduced the simple security property, star property, and the strong star property concepts. The Biba Integrity Model was the first to address integrity in computer systems. The Clark and Wilson Integrity Model addresses all three integrity goals.

Questions?

Enterprise Security Architecture

Similar presentations

Presentation on theme: "Enterprise Security Architecture"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Enterprise Security Architecture

Similar presentations

Presentation on theme: "Enterprise Security Architecture"— Presentation transcript:

Similar presentations

About project

Feedback