Course System Security II

Organizational Issues

Course System Security II Prof. Dr.-Ing. Ahmad-Reza Sadeghi Dipl.-Ing. Biljana Cubaleska Chair for System Security http://www.trust.rub.de Ruhr-University Bochum

November 2, 2009

Sadeghi, Cubaleska @RUB, 2008 - 2009

Course System Security II

Outlines/Organization

1 / 93


Organisatorische Aspekte

Termine ¨ Ubungen: Montags 14.15 - 15.00 Uhr in IC 4/161 Vorlesung: Montags 15.15 pm - 16.00 Uhr in IC 4/161 Sprechstunde: Donnerstags 12.00 - 13.00 Uhr in IC 4/34 (B. Cubaleska)

¨ Wichtig: Die Dauer oder die Reihenfolge der Ubungen und der Vorlesung innerhalb des Zeitfensters 14.15 - 17.00 Uhr kann sich abh¨ angig vom zu behandelnden Stoff ¨ andern Pr¨ ufungsform: Klausur am Ende des Semesters




2 / 93


Bonus Punkte: 15 % m¨oglich

¨ Mitarbeit w¨ ahrend der Vorlesung und Ubungen Hausaufgaben ¨ Drei praktische Ubungen im Labor in der zweiten Semesterh¨ alfte Discretionary Access Control Multilevel Security Role-Based Access Control




3 / 93


¨ Wichtige Informationen zur Vorlesung/Ubung

¨ Ziel der Vorlesung/Ubung Freiwilliges Lernen Gute und ruhige Lernatmosph¨ are

¨ Hausordnung w¨ ahrend der Vorlesung/Ubung Handys ausschalten Laptops ausschalten keine Privatgespr¨ ache mit Kommilitonen kein Essen (auch nicht vegetarisch) keine Versp¨ atung




4 / 93


Wise Words

”With great power comes great responsibility” (deutsch: Aus großer Macht folgt große Verantwortung)

Spider Man (comics)




5 / 93


Security and Privacy Problem




6 / 93


Roadmap of This Course

Introduction Elements of system security, assumptions and trust, security life cycle

Access control models Theory behind access control models Discretionary access control (DAC) Mandatory access control (MAC) Role-based access control (RBAC) Hybrid models

Information flow Confinement problem Security analysis of some real-life IT-systems




7 / 93


Recommended Literature [Bishop] Matt Bishop ”Computer Security: Art and Science” Addison Wesley, 2003, ca. 70 Euro [Benenthar] M. Benanthar ”Access Control Systems: Security, Identity Management and Trust Models” Springer, 2006, ca. 55 Euro [Gollmann] Dieter Gollmann ”Computer Security” John Wiley & Sons, 1999 [Pfleeger] Charles Pfleeger ”Security in Computing” Prentice-Hall International, 2002




8 / 93


Recommended Literature (cntd.) [Smith] Sean Smith and John Marchesini ”The Craft of System Security” Addison Wesley, 2008 [Anderson] Ross Anderson ”Security Engineering: A Guide to Building Dependable Distributed Systems” John Wiley & Sons, 2001 Partly online at http://www.cl.cam.ac.uk/~rja14/book.html

Further literature see the course website http://www.ei.rub.de/studierende/lehrveranstaltungen/265/

Lecture slides and exercises see the course website http://www.ei.rub.de/studierende/lehrveranstaltungen/265/




9 / 93

1.1 Motivation and Basic Notions 1.2 Elements of System Security 1.3 Assumptions, Trust, and Assurance 1.4 Security Life Cycle

Part I Introduction to System Security



1. Introduction to System Security

10 / 93


Notion of Security Security and Privacy Targets Physical Security Security Testing Methods

1

1.1 Motivation and Basic Notions Notion of Security Security and Privacy Targets Physical Security Security Testing Methods

2

1.2 Elements of System Security Secure identity establishment Resource access control Data and message security Resource availability Policies

3

1.3 Assumptions, Trust, and Assurance Assumptions and Trust Assurance Orange Book and Common Criteria

4

1.4 Security Life Cycle




11 / 93



Security Security is about protection of assets You have to know your assets and their values Risk analysis is a part of a comprehensive information security strategy

A rough classification of protective measures distinguishes between Prevention: take measures that prevent your assets from being damaged Detection: take measures that allow you to detect when an asset has been damaged, how it has been damaged, and who has caused the damage Reaction: take measures that allow you to recover your assets from a damage In some cases the damage may be irretrievable




12 / 93



Computer Security

Computer security is about protection of information assets We must examine how information assets can be compromised

Definition of computer security [Anderson]: Computer security deals with the prevention and detection of unauthorized actions by users of a computer system Some notes There is no single definition of security When reading a document, be careful which notion/definition of security is used in the document A lot of time is being spent (and wasted) in trying to define unambiguous notations for security




13 / 93



Data vs. Information Computer security is about controlling access to information and resources However, controlling access to information can sometimes be quite elusive and is therefore often replaced by the more straightforward goal of controlling access to data The distinction between data and information is subtle but it is also the root of some of the more difficult problems in security

Data: Physical phenomena chosen by convention to represent certain aspects of our conceptual and real world Data represents information Data is used to transmit information store information, and derive new information by manipulating the data according to formal rules

Information: The meanings we assign to data Information is the subjective interpretation of data Sadeghi, Cubaleska @RUB, 2008 - 2009



14 / 93



Security vs. Reliability and Safety Notions of reliability, safety and security Reliability: Related to (accidental) failures in the system Safety: Related to the impact of system failures on their environment, which also deal with situations where the system has to perform properly in adverse conditions Security: Deals with prevention and detection of unauthorized actions in the system

Depending on the preferred point of view, security is an aspect of reliability or vice versa To escape from this dilemma, the notion of dependability has been introduced as unifying concept Security, reliability, integrity, and availability can be treated as aspects of dependability




15 / 93



Dependability (1) Dependability is a value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her Dependability as applied to a computer system is defined by the IFIP 10.4 Working Group on Dependable Computing and Fault Tolerance as: ”[..] the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers [..]”

An alternative and broader definition of Dependability is provided by IEC IEV 191-02-03: ”dependability is the collective term used to describe the availability performance and its influencing factors: reliability performance, maintainability performance and maintenance support performance”




16 / 93



Dependability (2)

Dependability is the property of a computer system such that reliance can justifiably be placed on the service it delivers [Gollmann] The service delivered by a system is its behavior as it is perceived by its users A user is another system (physical, human) which interacts with the former




17 / 93



Computing System Vulnerabilities




18 / 93



Classical Security Targets Confidentiality (Vertraulichkeit): Prevention of unauthorized disclosure of information Problems: Who determines who is authorized? What extent of disclosure is relevant (one bit?)? Can be enforced by rigorous control of who can access which resources in what way

Integrity (Integrit¨ at): Prevention of unauthorized modification of information Some meanings of integrity are: ”precise”, ”accurate”, ”unmodified”, ”modified only in acceptable ways”, ”modified only by authorized people or processes”, ”consistent”, ”internally consistent”, ”meaningful and correct results” As confidentiality, can be enforced by rigorous control of who can access which resources in what way

Availability (Verf¨ ugbarkeit): Prevention of unauthorized withholding of information or resources Enforcing availability is not trivial and is one of the most serious problems of computer security Sadeghi, Cubaleska @RUB, 2008 - 2009



19 / 93



Relationship between Confidentiality, Integrity, and Availability

These tree qualities are largely independent, but sometimes overlapping They can even be mutually exclusive e.g., strong protection of confidentiality can severely restrict availability




20 / 93



Other Security Targets Authenticity (Authentizit¨ at) Integrity of a message content and origin, and possibly of some other information, such as the time of emission

Accountability (Zurechenbarkeit) Availability and integrity of the identity of the subject who performed an operation Data origin authentication (verifying the source of transmitted data) Entity authentication (verifying the identity of an entity)

Non-repudiation (Verbindlichkeit) Availability and integrity of the identity of the sender of a message (non-repudiation of the origin) or, of the receiver (non-repudiation of reception) Ability to prove this to (honest) third parties




21 / 93



Privacy Targets Privacy confidentiality with respect to personal data, which can be either ”information” or ”meta-information” (identity of a user who performed a particular operation, sent a particular message, received the message, etc.)

Anonymity (Anonymit¨ at) Confidentiality of the identity of the person, for instance, who invoked an operation Alternatively: the state of being not identifiable within a set of subjects

Untraceability (Nicht-R¨ uckverfolgbarkeit) Related to anonymity

Unlinkability (Unverkn¨ upfbarkeit) Different transactions are not linkable

Unobservalibity (Unbeobachtbarkeit) the state of items of interest (IOI), e.g., subjects, messages, events, being indistinguishable from any IOI (of the same type) at all Sadeghi, Cubaleska @RUB, 2008 - 2009



22 / 93



The Dimensions of Computer Security

Figure: Figure: Main dimensions for the design space for computer security

Horizontal axis represents the focus of the security policy Vertical axis represents the layer of the computer system where a protection mechanism is implemented Sadeghi, Cubaleska @RUB, 2008 - 2009



23 / 93



Horizontal Axis: Subjects and Objects

The term ”subject” generally refers to an active entity It is used to identify a running process (a program in execution) Each subject assumes the identity and the privileges of a single principal A principal may launch several processes within a single login session and thus be associated with multiple subjects, each of which inherits the identity of the login session

The term ”object” generally refers to a passive entity (file or a record in a database) However, object may indicate an active device from the systems resource pool (network printer or a programmable service that is managed as a resource)




24 / 93



Vertical Axis: Layers of the Computer System

System security concerns security aspects at different abstract levels




25 / 93



Security Measures

Technical measures (with synergies & overlaps) Cryptography System security

Organizational (including personal) Physical




26 / 93



Physical Security Traditional use of the term ”physical security” to describe protection of material assets from fire, water damage, theft, theft or similar perils

Ongoing concerns in computer security have caused ”physical security” to take on a new meaning ”Physical security” involves technologies used to safeguard information against physical attack In this new sense, physical security is a barrier placed around a computer system to deter unauthorized physical access to the computing system itself This concept is complementary to the logical security, i.e., the mechanisms by which operating systems and other software prevent unauthorized access to data

Both physical and logical security are complementary to environmental security Environmental security: The protection that the system receives by virtue of location such as guards, cameras, badge readers, access policies, etc. Sadeghi, Cubaleska @RUB, 2008 - 2009



27 / 93



Increasing Importance of Physical Security

Physical security is becoming more important because The nature of assets being protected has changed In the past the assets to be protected were nominally physical items (cash, jewelry, bounds, etc.) Now the assets are often information, which can be stolen without being physically removed from where they are

Computer systems have moved out of environmentally secure computer rooms into less environmentally secure offices and homes At the same time, the value of data on these computing systems is increasing as centralization decreases Logical security has also been improved so that a physical attack may become more easily performed than a logical attack




28 / 93



Effective Physical Security For physical security to be effective, the following criteria must be met In the event of an attack, there should be a low probability of success, and A high probability of detection either during the attack, or subsequent to penetration

Physical security technology is a relatively recent addition to computing system design A number of physical security methods are currently in use Tamper resistant systems Tamper responding systems Tamper evident systems




29 / 93



Tamper-Resistant Systems Tamper-resistant systems take the ”bank vault” approach: Thick steel or other robust materials are utilized to slow down the attack by requiring powerful tools and great effort to breach the system Example: Design of an automated teller machine (ATM) Tamper resistant physical security is usually the easiest to apply

Weight and bulk of the system can be a problem or benefit, depending on the application Complexity or size can be another variety of tamper resistance Single chip implementations of secure devices have a certain level of physical security due to the small size of the features and the complexity of determining which part of the circuit performs which function




30 / 93



Tamper-Responding Systems Tamper-responding systems use the burglar alarm approach: The defense is the detection of the intrusion, followed by a response to protect the asset In the case of attended systems, the response may consists of sounding an alarm

Tamper-responding systems do not depend on robust construction or weight to guard an asset Therefore they are good for portable systems or other systems where size and bulk are a disadvantage

Erasure or destruction of secret data is sometimes employed to prevent theft in the case of isolated systems which cannot depend on outside response




31 / 93



Tamper-Evident Systems Tamper-evident systems are designed to ensure that if a break occurs, evidence of the break-in is left behind This is usually accomplished by chemical or mechanical means, such as a white paint that ”bleeds” red when cut or scratched, or tape or seals that show evidence of removal Frangible (brittle, breakable) covers or seals are other methods available using current technology

Tamper-evident systems are not designed to prevent an attack or to respond to the indication that one is in progress Their job is to ensure that the fact of a break-in will remain known and can be ascertained in a later time

An audit policy must exist, and be adhered to, for a tamper-evident system to be effective Otherwise it may not be known if, or when, the system was breached If no one looks for the evidence of tampering, that evidence will never be found Sadeghi, Cubaleska @RUB, 2008 - 2009



32 / 93



Security Testing Methods

There are different methods of testing a piece of hardware or software: Black-box testing White-box testing Gray-box testing




33 / 93



Black-box Testing

Black-box testing testing technique in which the tester does not know the internal workings of the item being tested

The tester only knows the inputs and the outputs, but doesn’t know how the system will arrive at those outputs The tester does not examine the software code itself The tester does not examine the internal system structure




34 / 93



Black-box Testing Advantages and Disadvantages Black-box testing advantages Unbiased because the designer and the tester are independent of each other Tester does not need knowledge of any specific programming languages Test is done from the point of view of the user, not the designer Test cases can be designed as soon as the specifications are complete

Black-box testing disadvantages Test can be redundant if the designer has already run a test case Test cases are difficult to design Testing every possible input stream is unrealisticbecause it would take an inordinate amount of time; therefore many input-output behaviour cases will go untested




35 / 93



White-box Testing

White-box testing testing technique in which the tester has explicite knowledge of the internal workings of the item being tested also known as open-box testing

The white-box tester is able to select the test data The testing can only be meaningful if the person carraing out the testing knows what the software or the hardware is supposed to do This is often much more difficult than it sounds




36 / 93



Gray-box Testing

Gray-box testing testing technique in which the tester has some knowledge of the internal workings of the item being tested, but does not know the whole system

Combination of black-box and white-box testing methods The tester is not hindered by the limitations of the particular testing method

Example: Running a target program within a debugger and then supplying particular sets of inputs to the programm In this way, the programm is exercised while the debugger is used to detect any failures or faulty behavior




37 / 93


Secure identity establishment Resource access control Data and message security Resource availability Policies

1


2


3


4





38 / 93



Elements of System Security




39 / 93



Elements of System Security

Secure identity establishment Resource access control Confining actions of an established identity to its designated entitlements for services and computing resources

Data and message security Data integrity, confidentiality, origin authenticity, and non-repudiation

Resource availability Refers to ability to use the desired resources desired

Policies Statements of what is and what is not allowed in the system




40 / 93



Secure Identity Establishment




41 / 93



The Notion of Identity

Identity is simply a computers representation of an entity An identity specifies a principle A principal is a unique entity

Identities are used for several purposes. The two main ones are for Accountability: It requires an identity that tracks principles across actions and changes of other identities, so that the principal taking any action can be unambiguously identified Access control: It requires an identity that the access control mechanisms can be used to determine if a specific access should be allowed




42 / 93



Files and Objects

The identity of a file or other entity (objects) can depend on a system that contains that entity Local systems identify objects by assigning names for a human use (such as a file name) a process use (such as a file descriptor or handle), or for a kernel use (such as a file allocation table entry)

For an object residing on a different system, the name must encode the location of the object E.g., a URL (uniform resource locator) identifies an object by specifying its location and the protocol needed to access it




43 / 93



Entities and Identifiers Relationship

The same principal may have many different identities Typically, each identity serves a particular function

The ”entity” may be a set of entities referred to by a single identifier The members of the set must be distinguishable, but the set may have an identity separate from any of its elements ”Entity” can be single user, group of users, an entire organization, a host system, some networking device

Many systems allow principals to build sets called groups Groups are essentially a shorthand tool for assigning rights to a set of principals simultaneously




44 / 93



Secure Identity Establishment

Identity establishment (IE) is concerned with the methods by which a principal is unambiguously associated with an identity is the means of concluding that indeed the identity in use corresponds to the principal that it claims to be and thus is said to be authentic

Authentication is the secure identification of principals in which a proof of possessing an identity is verified (e.g., a key) Authentication binds a principal to a representation of identity internal to the computer




45 / 93



Importance of Secure Id. Establishment Secure IE is the fundamental prerequisite for the integrity and soundness of any access control or other security mechanisms The lack of enforcement for secure IE makes all attempts to enforce an access policy useless




46 / 93



Auditing

Auditing is the process of analyzing systems to determine what actions took place and who performed them Auditing consists of logging events (past, real-time or nearly real-time), analyzing them for potential breaches, and notifying concerned parties accordingly




47 / 93



Access Control




48 / 93



Notions of ”Subject” and ”Object”

The term ”subject” generally refers to an active entity It is used to identify a running process (a program in execution) Each subject assumes the identity and the privileges of a single principal A principal may launch several processes within a single login session and thus be associated with multiple subjects, each of which inherits the identity of the login session

The term ”object” generally refers to a passive entity (file or a record in a database) However, object may indicate an active device from the systems resource pool (network printer or a programmable service that is managed as a resource)




49 / 93



Resource Access Control (1)

Access Control (AC) Enforces a predefined access policy Goal of AC: To confine the actions of an entity only to the services and resources that it is entitled to Requires secure identity establishment AC is also referred to as access authorization or simply authorization

Access Policy (AP) AP: Predefined set of rules regulating which subject is allowed to access an object A safe AP prevents access of unauthorized users directly or indirectly in any state of the underlying computer system




50 / 93



Resource Access Control (2)

Secure Associations To prevent an access policy from subversion, the controls that enforce it should be foremost capable of binding computing activities to authenticated identities at any level of computation These bindings are known as secure associations (SA)




51 / 93



Data and Message Security




52 / 93



Data and Message Security

Notions ”Data Security” and ”Message Security” ”Data Security” is a generic term, concerned with Modification detection Origin authenticity Confidentiality of data

that is being processed in-memory or while residing on a storage medium ”Message Security” is a generic term, concerned with Modification detection Origin authenticity Confidentiality of data

during transmission over a computer network




53 / 93



Role of the Cryptography

Data / message confidentiality ⇒ e.g., by encryption algorithms Data / message integrity ⇒ e.g., by message authentication codes, digital signatures Origin authentication ⇒ e.g., by digital signatures Data integrity is usually combined with some form of origin authenticity, ensuring that an integrity check is indeed generated by a legitimate entity, the original source of data.




54 / 93



Non-repudiation

Non-repudiation of action: The process by which an entity is prevented from denying participation in a transaction either as an initiating/sending end (entities generating information) or as a receiving end (entities receiving information)

Legally binding non-repudiation can be very hard to realize Denial may always take one form or another Producing audit and transaction trails in a secure and controllable fashion is not enough




55 / 93



Resource Availability




56 / 93



Availability

Availability refers to the ability to use the resource desired addresses the issue of disrupting access to computing resources and services Type of disruption may range from compromising the functions of a particular service or a system, to completely denying access to it

Availability applies both to data and to service (access to computing resource) Attempts to block availability are called Denial of Service (DoS) attacks




57 / 93



Expectations and Goals of Availability

Different expectations of availability include presence of object or service in usable form capacity to meet service needs progress: bounded waiting time adequate time/timeliness of service

Goals of availability are timely response fair allocation fault tolerance utility or usability controlled concurrency: support of simultaneous access, deadlock management, and exclusive access, as required




58 / 93



Priority of Availability

Protecting computing resources from extreme degradation of performance or from deliberate DoS takes priority over the enforcement of any access control policy When authorized users are not able to send requests or reach a service, it becomes a secondary concern to have that service enforce an access-control policy




59 / 93



Notion ”Denial of Service” (DoS)

DoS attack: Attempt to block availability Goal: To keep legitimate users of the service from using it by exhausting computational resources, or exhausting the number of allowed connections

Consequence The attack may bring the service to its threshold capacity, leaving it dedicated to handling malicious requests instead of legitimate ones

Manifestation of the attack May range from slow response times to complete inhibition of service and ultimately a shutdown due to exhaustion of runtime resources (e.g., storage or network sockets)




60 / 93



Locations of Disruptions leading to DoS In the environment of the service The service is prevented from obtaining resources needed for its proper execution The attacker focuses on exhausting computing resources of the system in which the service is hosted

In the environment of the client The target service is diverted from responding to legitimate requesters and dealing with useful communications by way of attempting to respond to a massive flood of random client messages instead

Along the path between the clients and the server The attacker intercepts and then discards useful requests to the service




61 / 93



Detection and Prevention of DoS

DoS Attacks have emerged as among the leading security issues can be the most difficult to detect hard to prevent but it depends on the underlying protocol

Idea for Prevention of DoS: Any attempt of a client to establish a connection results either in allocation of connection or use some computational work to decide that the attempt is invalid




62 / 93



Policies




63 / 93



Security Policy and Mechanism

Reminder: A security policy is a statement of what is, and what is not, allowed in the system A security mechanism is a method, tool, or procedure for enforcing a security policy Mechanisms can be technical or non-technical

Policies often require some procedural mechanisms that technology cannot enforce




64 / 93



Representation of Policies In practice, policies are expressed in words Examples: Each stuff member should lock the door when leaving its office Stuff members should not install any software on their PCs All outgoing e-mails should be digitally signed Students should not copy the homework from another student

The ambiguity inherent in such a description leads to states that are not classified as ”allowed” or ”disallowed” In IT-Systems, policies may be represented mathematically, as a list of allowed (secure) and disallowed (insecure) states Any given policy provides axiomatic description of secure states and insecure states




65 / 93



Mutual Security Policies

When different sites communicate or corporate, the entity they compose has a security policy based on the security policies of the involved entities Inconsistency often manifests itself a security breach Complexity grows when third party, such as an Internet Service Provider, is involved




66 / 93


Assumptions and Trust Assurance Orange Book and Common Criteria

1


2


3


4





67 / 93



Trust Issues and Vocabulary

Trust Complicated notion studied and debated in different areas (social sciences, philosophy, psychology, computer science,...) Notion relating to belief in honesty, truthfulness, competence, reliability etc. of the trusted entity Social trust - belief in the safety or goodness of something because of reputation, association, recommendation, perceived benefit

Meanings (an attempt) Secure: system or component will not fail with respect to protection goals Trusted: system or component whose failure can break the (security) policy (Trusted Computing Base (TCB)) Trustworthy: the degree to which the behavior of the component or system is demonstrably compliant with its stated functionality

Trusted Computing Group (TCG) defines a system as trusted ”[...] if it always behaves in the expected manner for the intended purpose.”




68 / 93



Assumptions

Security and trust rest on assumptions Assumptions are specific to the type of security required and the environment in which it is to be employed

Example Opening a door requires a key Assumption: the lock is secure against lock picking This assumption is treated as an axiom and is made because most people would require a key to open the door lock The good lock picker, however, can open a lock without a key Hence, in an environment with a skilled untrustworthy lock picker, the assumption is wrong and the consequence invalid If the lock picker is trustworthy, the assumption is valid




69 / 93



Assumptions Concerning Policies

Some assumptions for policy design 1

2

The policy correctly and unambiguously partitions the set of system states into ”secure” and ”not secure” states (This assumption asserts that the policy is a correct description of what constitutes a secure system) The security mechanisms prevent the system from entering an ”insecure” state (This assumption asserts that the security policy can be enforced by the security mechanisms)

If either assumption is erroneous, the system will be insecure




70 / 93



Assumptions Concerning Security Mechanisms

Trusting that the security mechanisms work requires several assumptions 1

2

3 4

Each mechanism is designed to implement one or more parts of the security policy The union of the mechanisms implements all aspects of the security policy The mechanisms are implemented correctly The mechanisms are installed and administrated correctly




71 / 93



Role of Trust and Assumptions

Trust and assumptions have a crucial role in the system security! Make sure how the trust model look like Very complex relations are possible Trust cannot be quantified precisely Be clear about all assumptions made Check if assumptions hold Minimize the number of assumptions!




72 / 93



Assurance

System specification, design and implementation can provide a basis for determining ”how much” to trust a system This aspect of trust is called assurance Assurance as quantifier of trust (how much one can trust a system)




73 / 93



Realizing Assurance

Establishing some level of assurance in a security system is a desirable goal Question: How one arrives at determining a measure of that assurance? Three methods can be used Trust the vendor Perform own testing Rely on a third party (e.g., evaluations)




74 / 93



Value of Assurance

Assurance techniques do not guarantee correctness or security But they provide a firm basis for assessing what one must trust in order to believe that a system is secure Their value is in eliminating possible and common sources of error and forcing designers to define precisely what the system is to do




75 / 93



The Orange Book US Defence Department Sponsored much of the early research in computer security Tried to put together the security aspects in form of a standard Result: A series of documents Each document had a different collor cover and become known by that cover The full set was known as the Rainbow Series

The Orange Book presented the main criteria for trusted computer systems [DoD 85] Title: ”Trusted Computer System Evaluation Criteria” Online at http://csrc.nist.gov/ publications/history/dod85.pdf Sadeghi, Cubaleska @RUB, 2008 - 2009



76 / 93



The Orange Book (cntd.)

Idea of the Orange Book: Evaluate the security of the systems using two independent axes (types of requirements) Functionality (what functionality the system must have), and Assurance (what degree of assurance we require it to have)




77 / 93



Orange Book Goals

Specifies features the system should have Enumerates techniques to help answer the question of why one should believe that the system does in fact work Trusted facility management Trusted distribution Testing Documentation Formal top-level specification




78 / 93



Orange Book Divisions The Orange Book yardstick consists of four divisions (A, B, C, D), and then various classes within each division Divisions get more secure as the letters go down toward A Classes get more secure as the numbers go up away from 1

As we move along the classes and divisions, we require more functionality and more assurance Meanings of the Orange Book divisions D: ”minimal protection” C: ”discretionary protection” B: ”mandatory protection” A: ”verified protection” Sadeghi, Cubaleska @RUB, 2008 - 2009



79 / 93



Common Criteria Shortcommings of the Orange Book The Orange Book defined targets for security features and assurance, but the linking of features and assurance became cumberstone A detailed formal assurance may be performed for systems that do not provide all of the features in B3

The Orange Book divisions and classes were not enough flexible The market may determine combinations of security features that do not neatly fit into one of these classes

Out of the desire for a more flexible assurance approach, the Common Criteria emerged In the early 1990’s, independent approaches for system assurance were developed in Europe and Canada The ITSEC (Information Technology Security Evaluation Criteria) was released in 1991 as a joint standard of Germany, Netherlandes, France and UK The CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) was released in 1993 Inspired of the facets of each of these evaluation approaches, the Common Criteria Approach was developed Sadeghi, Cubaleska @RUB, 2008 - 2009



80 / 93



Common Criteria Evaluation Assurance Levels Common Criteria separates the assurance effort from the security features being assured The amount of evaluation effort determines a confidence level in the target of evaluation, called Evaluation Assurance Level (EAL) Evaluation Assurance Levels range from EAL1 (lowest) to EAL7 (highest) EAL1: EAL2: EAL3: EAL4: EAL5: EAL6: EAL7:

functionally tested structurally tested methodically tested and checked methodically designed, tested and reviewed semiformally designed and tested semiformally verified design and tested formally verified design and tested




81 / 93


1


2


3


4





82 / 93


Threats The security life cycle starts with threats analysis A threat is a potential violation of security A violation need not actually occur for there to be a threat The fact that the violation might occur means that those actions that could cause it to occur must be guarded against (or prepared for) Those actions are called attacks Those entities executing such actions or cause them to be executed, are called attackers or adversaries




83 / 93


From Threats to Policies Based on the threats, the security policies can be defined Risk analysis To determine whether an asset should be protected, and to what level, requires analysis of the potential threats against that asset The level of protection is a function of the probability of an attack occurring and the effects of the attack

Cost-benefit analysis Any useful policy and mechanism must balance the benefits of the protection against the cost of designing, implementing and using the mechanism




84 / 93


Specification Specification is a statement of the desired functioning of a system The statement can be formal, highly mathematical, using some language designed for that purpose The statement can be informal, using, for example, the English language to describe what the system should do under certain conditions

Specifications are used not merely in security E.g., safety systems such as traffic control medical devices, etc. A major part of specifications is determination of the set of requirements relevant to the systems planned use Sadeghi, Cubaleska @RUB, 2008 - 2009



85 / 93


Design

The design of the system translates the specifications into components that will implement them The design is said to satisfy the specifications if, under all relevant circumstances, the design will not permit the system to violate those specifications

Problem with poor specifications Arguments are half-hearted and unconvincing or provide only partial coverage The design depends on assumptions about what the specification mean This leads to vulnerabilities




86 / 93


Implementation Given a design, the implementation creates a system that satisfies that design If the design satisfies the specifications, then, by transitivity, the implementation will also specify the specifications The difficulty is the complexity of proving that a program correctly implements the design and, in turn, the specifications

A program is correct if its implementation performs as specified Formal verification of correctness is very complex Widespread is an a posteriori verification technique known as testing




87 / 93


Operational Issues Operational environments always introduce unexpected problems or difficulties Role of assurance phase If the assurance (specification, design, implementation, and testing/proof) is done properly, the extra problems and difficulties are minimal If it has been omitted or done poorly, the problems may require a complete reevaluation of the system

Feedback from operation is critical and has impact on all other stages! Tools used for the feedback include auditing, in which the operation of the system is recorded and analyzed so that the analyst can determine what the problems are Sadeghi, Cubaleska @RUB, 2008 - 2009



88 / 93


Human Issues

Implementing security controls is complex The heart of any security system are people Designers, implementers, and maintainers of security controls are essential to the correct operation of those controls Non-technical considerations affect the implementations and use of technical controls ⇒ violation of security

Human issues pervade each stage of the cycle!




89 / 93


Human Issues (cntd.)

Organizational problems Chains of responsibility for security in a system (e.g., an enterprise) If configured or used incorrectly, even the best security control is useless ⇒ staff training required

People problems Attacks by insiders Attacks by outsiders Social engineering Problem of misconfiguration (aggravated by the complexity of many security-related configurations) ”Administrator problem”




90 / 93


Security Live Cycle: The Correlations

Each stage of the cycle feeds back to the preceding stage Each stage of the cycle feeds with input the next stage Feedback from operation and maintenance is critical and has impact on all stages Human issues pervade each stage of the cycle!




91 / 93


Literature I Ross Anderson. Security Engineering - A Guide to Building Dependable Distributed Systems. Wiley and Sons, 2001. Matt Bishop. Computer Security - Art and Science. Addison Wesley, 2002. Charles P. Pfleeger. Security in Computing. Prentice-Hall International, 1997. Sean Smith and John Marchesini. The Craft of System Security. Addison Wesley, 2008. Sadeghi, Cubaleska @RUB, 2008 - 2009



92 / 93

Course System Security II

Course System Security II

Suggest Documents

Course ”Operating System Security”

Level-II Online Course

Drawing II Course Syllabus

Course I Course II - Adam Merkel Restaurants

Course I Course II - Adam Merkel Restaurants

Course Syllabus - Offensive Security

Routing Security Training Course

Topic Security course:

An Information System Security Course for the Undergraduate ...

System Security

Security System

B.Ed OPTIONAL COURSE GEOGRAPHY - II

Cloud Security Training Crash Course

Course Syllabus: Operating System

COURSE: DATABASE MANAGEMENT SYSTEM

Course Registration System - IT122

Climate & food security~II

Fe(II) SYSTEM IN

CHEM 1312 General Chemistry II COURSE SYLLABUS COURSE ...

1. Name of Course/Module Bioinformatics Algorithms II 2. Course ...

Course name: Supply Chain Management Course code: II 502 ...

Course Code :TDE 192 Course Title : TURKISH LANGUAGE II Level ...

T. Y. B. Sc. Laboratory Course II Semester II

ENGLISH COURSE Architecture and Urban Planning II/II ... - Poznań