Presentation on theme: "Enterprise Security Architecture"— Presentation transcript:
1 Enterprise Security Architecture This topic will focus on Security Architectures and various security models.
2 IntroductionThe 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.
3 Introduction The infrastructure includes items such as: Hardware SoftwareOperating System and all associated functionsApplicationsUtilitiesNetwork environmentSecurity awareness and trainingInformation system security supporting policies, procedures, baselines, and standards
4 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.
5 Goals of Information Security The common thread among good information security objectives is that they address all three core security principles.AvailabilityConfidentialityPrevents unauthorized disclosure of systems and information.IntegrityPrevents unauthorized modification of systems and information.Prevents disruption of service and productivity.The cornerstone of information Security.
6 DefinitionsEnterprise - 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.
7 DefinitionsSecurity Architecture - A high-level design used to satisfy a system’s security requirements as defined in an organization’s security policyEnterprise 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
8 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
9 Section Objectives Describe an operating system List the requirements for memory managementDescribe input and output devicesDefine a Trusted Computing BaseDescribe the key computer architecture and security architecture protection conceptsDescribe the key security architecture assurance mechanisms
10 Common Computer Architecture Operating System Utilities and Software EndUserEndUserApplication ProgramsUtilitiesOperating SystemThis 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
11 Common Computer Architecture Operating System Operating system services include:Program executionAccess to Input/Output devicesControlled access to filesSystem accessError detection and responseAccounting
12 Subtopics Common Computer Architecture Operating System Central Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
13 Central Processing Unit (CPU) This slide gives an overview of a system from the aspect of the CPUALU (Arithmetic Logic Unit): Performs basic integer arithmetic and comparison functions. Not displayed is the Floating Point Processor which does the same for Floating Point numbersControl Unit: The part of the CPU that accesses the data and instructions in the computer and transfers it to the ALUInstruction: A command that tells a computer how to accomplish a specific taskPrimary 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 cardSecondary 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.
14 CPU States Supervisor State Problem State Program can access entire systemBoth privileged and non-privileged instructionsProblem StateUser State or Program StateOnly non-privileged instructions executedIntended for application programsThe 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...
15 CPU States (cont.) Process States are: Stopped vs. operating Wait vs. runningMasked/interruptibleExample: If masked bit not set, interrupts are disabled (masked off) - known as IRQs in systemsStopped 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 downloadableNote: 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 informationIRQ = Interrupt Request Queue
16 CPU ProcessesAll Applications were originally self-contained independent entities that communicated through the operating system
17 CPU Process ThreadsMany, 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.
19 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
20 CPU MemoryThis slide is intended to display the types of system memoryAbout 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.
21 Memory Management The five requirements for memory management are: RelocationProtectionSharingLogical OrganizationPhysical OrganizationRelocation: 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 locationMemory 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.
22 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 addressRelative - address expressed as a location relative to a known pointPhysical - the absolute address or actual location
23 Virtual MemoryExtends memory by using secondary storage for program pages not being executed.Composed of independent numbered segments.
24 SwappingIn a Virtual Memory system, swapping is the act of transferring pages between physical memory and the swap space on the diskPages are fixed blocks of memory usually 4KBytes or 8KBytes.Swapped Pages are stored on diskPages are swapped into memory as neededA page fault is taken when a reference is taken to a non-resident PageSwapping 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.
25 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).
26 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
27 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.
28 Common Computer Architecture (I/O) Devices - Swapping and Paging Paging is used to transfer data between the I/O device and main memoryHardware 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.
29 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
30 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.
31 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
32 Trusted Computing Base (TCB) The Trusted Computing Base is the totality of protection mechanisms within a computer system - includinghardware,firmware,software,processes, andsome inter-process communicationsthat combined are responsible for enforcing a security policy.
33 Trusted Computing Base (TCB) The TCB maintains the confidentiality and integrity of each domain and monitors four basic functions:Process activationExecution domain switchingMemory protectionInput/Output operationProcess 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.
34 Trusted Computing Base (TCB) Two primary concepts:Subjects – Active entities - includes users, programs, processes, logon identifiersObjects – Passive entities - includes files, programs, data, hardwareThe 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.
35 Objects Requiring Protection Operating System Table(s)Instructions (especially privileged)Passwords / Authentication MechanismsProtection MechanismsMemoryFile or Data SetExecuting Program in MemoryDirectory of FilesHardware DeviceData Structure
36 Reference Monitor Concept Abstract machine that must mediate all access of subjects to objects.Features include:Must mediate all accessBe protected from modificationBe verifiable as correctAlways be invoked
38 Security KernelThe hardware, firmware, and software elements of a trusted computing base that implement the reference monitor concept.
39 Reference Monitor / Security Kernel Complementary goals:Check every accessAllow least privilegeVerify acceptable usageAppropriate useAuthorization Concept
40 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
41 Protection Concepts Subtopics A computer system can use concepts such as the following for protection:Privilege levelsProcess IsolationLayeringData HidingRing ProtectionSecurity DomainsVirtual MachinesWe’ll look at each of these over the next few slides.
42 Privilege LevelsSubjects of higher trust can access more system instructions and operate in privileged modeSubjects with lower trust can only access a smaller portion of system instructions and operate in user modeA 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.
43 Process IsolationPreserve object’s integrity and subject’s adherence to access controlsPrevents objects from interacting with each other and their resourcesActions of one object should not affect the state of other objects
44 Process Isolation (cont.) Encapsulation of objectsTime multiplexing of shared resourcesNaming distinctionsVirtual mappingProcess 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.
45 Layering and Data Hiding Processes operate at different layers within a system and must communicate through interfacesLayers can be divided by functionality or securityData Hiding:If a process does not have an interface to another process at another layer, it cannot have access to its dataSystems 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.
46 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.
47 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.
48 Security DomainsSometimes 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.NoteDeveloping and maintaining the execution domain for a process is the responsibility of the kernel
49 Virtual MachinesVirtual 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 environmentWhen 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.NoteThe actual system is referred to as the “real machine” and created environments as “virtual machines”.
50 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
51 Operating System Protection Subtopics User Identification and AuthenticationDiscretionary access controlMandatory access controlComplete mediationObject reuse protectionAuditAudit log reductionTrusted pathIntrusion DetectionThese 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.
52 Operating System Protection User Identification and AuthenticationMust authenticate or verify users to the systemDiscretionary access controlAll object access control left to ownerMandatory access controlAccess control decisions jointly controlled by object owner and the system
53 Operating System Protection Complete mediationAll accesses must be intercepted and verifiedDifficult as more paths are createdObject reuse protectionMemory leakageMagnetic RemanenceAuditSecurity-relevant eventsProtection of audit logsObject 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.)
54 Operating System Protection Audit log reductionVolume and analysis problemSimplificationCorrelationTrusted pathProtection of critical operationsIntrusion DetectionPatterns, Analysis, RecognitionIt 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.
55 Subtopics Common Computer Architecture Operating SystemCentral Processing Unit (CPU)Memory ManagementInput/Output DevicesMemory ProtectionTrusted Computing Base (TCB)Computer Architecture Protection ConceptsSecurity Architecture Protection ConceptsSecurity Architecture Assurance MechanismsEnterprise Security ArchitectureSecurity Models
56 Assurance, Trust, and Confidence Audit Log ProcessingHost audit logsNetwork device logsIntrusion Detection reportsSecurity ReviewsVulnerability AssessmentSystem and Network AuditsAttack and Penetration Tests
57 Product Evaluation Criteria Trusted Computer System Evaluation Criteria (TCSEC) - The Orange BookTrusted Network Interpretation (TNI) - The Red BookInformation Technology Security Evaluation Criteria (ITSEC)Common Criteria
58 Common CriteriaISO 15408Provides a common structure and language for expressing product/system security evaluations and requirementsProvides a catalog of standardized security requirement components and packages
59 Parts of the Common Criteria Part One: Introduction and General modelPart 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)
60 Common Criteria GoalsHave 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 developersProvide world-wide availability of security-capable products.
61 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.
62 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.
63 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.
64 Common Criteria Security Requirements The CC defines two types of Security Requirements:Functional RequirementsDefining security capabilities of the product or system:Implemented requirements become security functions(what a product does)Assurance RequirementsEstablishing confidence in Security Functions:Correctness of implementationEffectiveness in satisfying objectives(is the product built welland does it meet the purpose)
65 Common Criteria Flow Protection Profile Target of Evaluation Security Category of Product (i.e., “firewalls”)EAL Levels1 Functionally Tested2 Structurally Tested3 Methodically Tested4 Methodically Designed, Tested, Reviewed5 Semiformal testing6 Semiformal verification7 Formal verification and testingTarget ofEvaluationSpecific Product (i.e., Checkpoint-1)Vendor claims: Specifications and featuresSecurityTargetDOMAIN: ArchitectureThis slide is intended to display the relationship among the Common Criteria terms and put them into perspectiveCertification 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 environmentFunctionalRequirementsAssuranceRequirementsCertificationTEST plan based on stated requirementsEvaluationAccreditation
66 Quick QuizWhat 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.
67 Section SummaryMemory, 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.
68 Subtopics Common Computer Architecture Enterprise Security ArchitectureSecurity Models
69 Section ObjectivesDescribe the difference between infrastructure and architectureList the benefits of an enterprise security architectureList the key components of an enterprise security programDefine IT security principles
70 Infrastructure vs. Architecture Infrastructure refers to the supporting elements needed for functionalityArchitecture refers to the cohesive design of the elements.
71 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.
72 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.
73 The Enterprise Security Architecture… Strategic – longer life than a blueprint, design specification, topology or configurationConstrained 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
74 The Enterprise Security Architecture… (cont.) Business centered acceptance and management of riskAllows for multiple implementations depending on requirementsGuidance for implementation of security for internal and external organizationsInteroperabilityIntegrationEase-of-useStandardization
75 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.
76 Management’s Expectations Mitigate riskFirst need to know what risk is present.Enhance user productivitySecurity should not get in the way of productivity.Reduce CostMost security is assumed to be built in.Streamline Application Development/IntegrationSecurity 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.
77 Lack of Enterprise Security Approach Symptoms Lack of an enterprise security approach is evidenced through many symptomsUnable 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.
78 The Challenges Fiduciary responsibilities Data confidentiality Upstream and downstream liabilityLegal & RegulatoryDifferent business modelsMergersChanging technologiesInterfaces with legacy systemsEnd-to-End SecurityChallengesGreater number of user access pointsGlobal AccessThe 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 modelThe legal requirements are also forcing controls on organizationsPIPEDA – Personal Information Protection and Electronic Documents Act (Canada)HIPAA – Health Information Portability and Accountability Act (US)B2B – business to businessB2C – business to consumerB2G – business to governmentThe impact from the lack of an enterprise security approach is evidenced through many symptomsUnable 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.
79 There is Much at StakeCrackers 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)
80 Holistic Security Approach A robust, holistic Enterprise Security program environment allows organizations toShift from an IT-centric to a business-centric security process to more effectively manage risk.Link organizational, technical, administrative and physical security controlsTo business drivers, legal requirements, threat scenarios and design.And ensure they are operationally integrated with the overall IT architecture, business processes and business culture.
81 Enterprise Solution vs Point Solution Approach An Enterprise Solution ApproachProvides 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, andReduces total-cost-of-ownership by consolidating management and eliminating overheadA Point Solution ApproachLacks 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, andResults in an increased total-cost-of- ownership and disruption from overhead, redundancies and conflictsPoint security solutions only address a thin layer of technical functionalityThe 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.
82 Management Processes – Key ComponentsManagement 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 enterpriseArchitecturesArchitectures – 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 establishedManagement ProcessesProcesses & MethodsRoles & ResponsibilitiesTools / EnablersAwarenessSolution ImplementationCompliance / MonitoringThe 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
83 Typical IT Security Architecture This should be the “end game”, not the starting pointThe 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.
84 Process FrameworkThe 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 stepsThese 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.
85 Security Pathing Security Capability Evolution Assurance Security Organizational StructureEnterprise Security ControlsDocumented Strategy, Principles and PolicySecurity MetricsSecurity CapabilityInitiateStakeholderSecurityProgramCompliance and CertificationSecurity ArchitectureSecurity Technical FrameworkThe security architecture is only one stage of the IT security journeyAn effective organization will complete each of the steps on the chart at some timeAssuranceAuditing, monitoring, and reporting processes and controls in place to ensure they are meeting standards and are effectiveSecurity MetricsMeasure the efficiency, effectiveness, value and continuous performance improvement of the individual security processCompliance and CertificationEstablish compliance measurement and reporting systemSecurity Technical FrameworkEstablishment of methods and technologies to support stakeholder interactionSecurity ArchitectureArchitecture principles and policies in place to define core security functionsInitiate Stakeholder Security ProgramStakeholder sponsored program with responsibilities assignedDocumented Strategy, Principles and PolicyClearly defined set of technology-independent policies developed from the business strategySecurity Organizational StructureIndividuals and organizations assigned responsibility, accountability and authority to support the infrastructureEnterprise Security ControlsSecurity controls defined to establish a consistent basis for managing riskEvolution
86 Enterprise Security Architecture Key Security Decision Areas Key security decisions provide the basis for consistency across the architecture:Security ZonesThe recognition and definition of the various relationships and boundaries between the organization and business partnersA framework to support the criteria for a consistent approach to managing risk and supporting security policyInformation ClassificationRecognition 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 sensitivityThese 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.
87 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 protectionGeneral Internet Connection ZoneProxy ServersMail Relay ServersForwarding DNSWeb Caching ServersVPN Connection ZoneInternet IngressPrivate Network VPN IngressAuthentication, Authorization, Administration ServicesE-Business Hosting ZoneWeb ServersInternet Applications ServersAuthoritative DNSUser LAN ZoneDesktop ComputersLaptop ComputersKiosksPrintersData Center ZoneIntranet ApplicationsExtranet ApplicationsInternal ApplicationsFile and Print ServersMainframe, DatabaseDirectory ServicesDial-up Connectivity ZoneRemote Access ServersTerminal ServicesWireless Connectivity ZoneAccess PointsWAN Connectivity ZoneWAN Routers controlling:SuppliersPartnersRemote Offices, BranchesOther third-parties
88 Architecture Definition Process SecurityPrinciplesThe 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.SecurityArchitecturePrinciplesDetailedSecurityArchitectureThis 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).TechnicalFramework
89 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, andOften 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.
90 Enterprise Security Architecture The security architecture must address all components of the enterprise security program not just the technical components:Strategic alignmentProcess enhancementBusiness EnablementSecurity FoundationAligned with best practicesShows inter-relationshipsThe architecture should guide the blueprintsWe will discuss each of these sections over the next few slides.See the next slide for a graphicdescription of this concept
92 Strategic Alignment KEY COMPONENTS Executive Level Sponsorship C level executivesCurrent ProfileThreat orientationCurrent state assessmentRisk toleranceChange readiness assessmentSecurity StrategyBusiness drivers and IT strategiesBusiness and regulatory drivers“To Be” security framework3 year operating modelSecurity FoundationKey ComponentsNeed executive level sponsorship for the architecture, it has to be enterprise wide and mandatory in order to have an enterprise wide approach to riskA 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?
93 Strategic Alignment (cont.) KEY CONSIDERATIONSActive executive participationOwner, custodian, stakeholder alignmentAssigned responsibility, accountability and authoritySecurity Life CycleBusiness and IT alignmentSecurity process and management fundamentals/foundations/baseline versus with ‘wants’All Stakeholders speaking the ‘same language’Key ConsiderationsThe architecture also must have an identified ownerWho 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-relatedThe 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”.
94 Business Enablement - End-to-end transaction integrity KEY COMPONENTSSecurity Solution DiagnosticPolicy and StandardsOrganizational AlignmentTechnical Control ArchitectureProcess AlignmentAwareness and TrainingCompliance and AssuranceSecurity Solution MethodologiesInformation Security Risk AssessmentSystem Analysis and DesignSolution Specific TemplatesNext component is ‘business enablement’, which is made of the listed components and considerations.
95 Business Enablement - End-to-end transaction integrity KEY CONSIDERATIONSPeople, process and technology driven requirementsConsistent application of solution modelsZone analysis for end-to-end transaction integritySecurity Plans practically applied to all aspects of a business’ operation – network, applications, processes, etc.
96 Process Enhancement - Evolutionary integration and consistent execution of security across the enterpriseKEY COMPONENTSSecurity CriteriaPhilosophy/ ModelsCore Enterprise ProcessesArchitecture, EngineeringProject & Risk ManagementIT Operations ManagementSecurity ChampionsSubject Matter ExpertsAwareness & TrainingSecurity Communication PortalSelf ServiceKnowledge ManagementNext component is process enhancement.
97 Process Enhancement - Evolutionary integration and consistent execution of security across the enterpriseKEY CONSIDERATIONSKey security standards, model and criteria proactively championed through existing enterprise-wide management processesCenter of Excellence (COE) approachBreadth of coverage – end-to-end transactionDepth – subject expertsFacilitator roles versus ownerIncentive concept to promote security staff as enablers versus roadblocksRoles and responsibilities clearly defined and championed
98 Security Foundation - Core security program and architecture established KEY COMPONENTSSecurity Management PlanProgram, Organization, AdministrationBusiness Continuity Management PlanInfrastructure Security PlanPhysical and EnvironmentalSystems & Network InfrastructureLogging, Monitoring & ReportingApplication Integrity PlanIdentity Management PlanPrivacy PlanNext is ‘security foundation’.
99 Security Foundation - Core security program and architecture established KEY CONSIDERATIONSActive executive participationOwner, custodian, stakeholder alignmentAssigned responsibility, accountability and authoritySecurity Life CycleBusiness and IT alignmentSecurity process and management fundamentals/foundations/baseline versus ‘wants’
100 Security Effectiveness KEY COMPONENTSKey Performance IndicatorsHigh Risk ElementsCritical ResourcesCore Management ProcessesCustomer SatisfactionInformation StructurePresentation and ReportingMetricsSource DataCompliance MonitoringInternal and External Audit PlansRegulatoryIT Scanning / Self-AssessmentsNext 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?’
101 Security Effectiveness KEY CONSIDERATIONSFocus on a few critical objective indicators that truly enhance visibilityInternal audit alignmentCommunication of successes/failuresService Level Agreements (SLA) for customer satisfactionIT Return on Investment (ROI)Critical vendor maintenance contractsMetrics for day-to-day operationsReporting timelinesExisting balanced scorecard system
102 Enterprise Security Architecture Components Established common architecture language?Principles including motivation and implicationsEstablished architecture model?Used for iterative levels of architecture elaborationProvides guidance to multiple levels in the organizationThe Zachman Framework is a popular choice to defining an Enterprise Architectureprovides 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.
103 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”IntentThe 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.ScopeThe 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.PrinciplesBy 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.StructureThe 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 FrameworkScope( 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…….
104 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.GuidanceMost 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.
105 Quick QuizWhat 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.
106 Section SummaryInfrastructure 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.
107 Security Models Common Computer Architecture Enterprise Security ArchitectureSecurity ModelsBell-LaPadula Confidentiality ModelBiba Integrity ModelClark and Wilson Integrity ModelAccess Control MatrixInformation Flow ModelBrewer and Nash ModelOther ModelsModels 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 requirementsThere 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.
108 Section Objectives List the key security models Describe the Bell-LaPadula Confidentiality ModelDescribe the Biba Integrity ModelDescribe the Clark and Wilson Integrity ModelDescribe the Brewer and Nash Model
109 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.
110 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 RelationClearances of subjects to classifications of objects.Discretionary Security PropertySpecific subject authorized for particular mode of access.
111 Bell-LaPadula Confidentiality Model (cont.) Bell-LaPadula introduced the following concepts:Simple security propertySubject 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.
112 Bell-LaPadula Confidentiality Model (cont.) Layer ofHigher SecrecyReadingSecretsReadingSecretsXXREADWRITEREAD/WRITEDivulgingSecretsDivulgingSecretsXXLayer ofLower SecrecyThis 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.SimpleSecurityPropertyStrongStarPropertyStarProperty
113 Biba Integrity Model First to address integrity in computer systems. Based on hierarchical lattice of integrity levels.ElementsSet of subjects (Active, information processing)Set of objects (Passive, information repository)Addresses first goal of integrityPrevent unauthorized users from making modifications.Mathematical dual of confidentiality policyAccess tuple: subject & objectBiba’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.
114 Biba Integrity Model (cont.) Strict integrity policy:Simple integrity conditionSubject cannot read objects of lesser integrity.Integrity star * propertySubject cannot write to objects of higher integrity.Invocation propertySubject 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.
115 Biba Integrity Model (cont.) Layer ofhigher accuracyContaminationXREADWRITEGetContaminatedXLayer oflower accuracyThis 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.SimpleIntegrityPropertyIntegrityStarProperty
116 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 transactionPreserve/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.
117 Clark and Wilson Integrity Model (cont.) Separation of DutyAttempts ensure external consistency and second goalOperation divided into sub partsDifferent person executes each partEnsures external consistency (data represents real world)Prevents authorized users from unauthorized modificationsYou 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.
118 Clark and Wilson Integrity Model (cont.) Access TripleSubject – Program – ObjectEnforced 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).
119 Access Control Matrix State machine model specifying modes of access Subject-subject or subject-objectOne row per subjectOne column per subject and objectAccess control matrix can be used for both confidentiality and integrity. Confidentiality by controlling “read” operations and integrity by controlling “write” operations.
120 Access Control Matrix (cont.) User Axis & Resource AxisObject
121 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.
123 Brewer and Nash Model – Chinese Wall Security Policy Published in 1989 to ensure fair competitionMathematical 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.
124 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.
125 Brewer and Nash Model Wall Organization X Organization Y Data Data Conflict ofInterest – Off Limits
126 Other Security ModelsNon-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 rulesPrimitive rights:Create ObjectCreate subject, delete object, delete subjectGrant access rightsDelete access rightsTransfer access rights
127 Other Security ModelsHarrison-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
128 Quick QuizWhat 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?
129 Section SummaryThe 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.