Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 5 – Designing Trusted Operating Systems  What makes an operating system “secure”? Or “trustworthy?  How are trusted systems designed, and which.

Similar presentations


Presentation on theme: "Chapter 5 – Designing Trusted Operating Systems  What makes an operating system “secure”? Or “trustworthy?  How are trusted systems designed, and which."— Presentation transcript:

1 Chapter 5 – Designing Trusted Operating Systems  What makes an operating system “secure”? Or “trustworthy?  How are trusted systems designed, and which of those design principles carry over naturally to other program development tasks?  How do we develop “assurance” of the correctness of a trusted operating systems?

2 Designing Trusted Operating Systems  Primitive security services Memory protectionMemory protection File protectionFile protection General object access controlGeneral object access control User authenticationUser authentication  OS is trusted if we have confidence that it provides these four services in a consistent and effective way.

3 What is a trusted system? SecureTrusted Either-or: something either is or is not secure Graded: There are degrees of “trustworthiness Property of presenter Property of receiver Asserted based on product characteristics Judged based on evidence and analysis Absolute: not qualified as to how, where, when, or by whom used Relative: viewed in context of use A goal A characteristic

4 What is a trusted system?  Trusted process – process that can affect system security  Trusted product – evaluated and approved product  Trusted software- software portion of system that can be relied upon to enforce security policy  Trusted computing base – set of all protection mechanisms within a computing system that enforce a nified security policy  Trusted system – system that employs sufficient hardware and software integrity measures to allow its use for processing sensitive information

5 Security Policies  security policy – statement of security we expect the system to enforce  Military Security Policy based on protecting classified informationbased on protecting classified information Information access is limited by need- to-know ruleInformation access is limited by need- to-know rule Each piece of classified info is associated with a compartmentEach piece of classified info is associated with a compartment

6 Military Security Policy  Class (classification) -  Class (classification) -  Clearance - indication that person is trusted to access info up to a certain level of sensitivity  Dominance –  s <= O iff rank s <= rank o  and compartments s <= compartments o  Clearance level of subject is at least as high as that of the information  Subject has a need to know about all compartments for which the information is classified.

7 Commercial Security Policies  Data items at any level may have different degrees of sensitivity (public, proprietary, internal)  No formalized notion of clearances  No dominance function for most commercial information access

8 Clark-Wilson Commercial Security Policy  Well-formed transactions – perform steps in order, exactly as listed & authenticating the individuals who perform the steps  Goal – maintain consistency between internal data and external expectations of the data  Process constrained data items by transformation procedures

9 Commercial Security Policy  Separation of duty – division of responsibilities (manual system)  Chinese Wall Security Policy – Confidentiality PolicyConfidentiality Policy Objects (e.g. files)Objects (e.g. files) Company Groups (all objects concerning a particular company)Company Groups (all objects concerning a particular company) Conflict classes (cluster competing companies)Conflict classes (cluster competing companies)

10 Models of Security  Security models are used to Test a particular policy for completeness and consistencyTest a particular policy for completeness and consistency Document a policyDocument a policy Help conceptualize and design an implementationHelp conceptualize and design an implementation Check whether an implementation meets its requirementsCheck whether an implementation meets its requirements

11 Multilevel Security  Want to build a model to represent a range of sensitivities and to reflect need to separate subjects from objects to which they should not have access.  Use the lattice model of security military security model where <= in the model is the relation operator in the lattice (transitive, antisymmetric)military security model where <= in the model is the relation operator in the lattice (transitive, antisymmetric) Commercial security model (public, proprietary, internal)Commercial security model (public, proprietary, internal)

12 Bell-La Padula Confidentiality Model  Formal description of allowable paths of information flow in a secure system Simple Security Property. A subject s may have read access to an object o only if C(o) <= C(s)Simple Security Property. A subject s may have read access to an object o only if C(o) <= C(s) *-Property – A subject s who has read access to an object o may have write access to an object p only if C(o) <= C(p)*-Property – A subject s who has read access to an object o may have write access to an object p only if C(o) <= C(p)  The *-property is used to prevent write-down (subject with access to high-level data transfers that data by writing it to a low-level object.

13 Bibb Integrity Model  Simple Integrity Property. Subject s can modify (have write access to) object o only if I(s) >= I(o)  Integrity *-Property. If subject s has read access to object o with integrity level I(o), s can have write access to object p only if I(o) >= I(p)

14 Models Proving Theoretical Limitations of Security Systems  Graham-Denning Model – introduced concept of a formal system of protection rules; constructs a model having generic protection properties  Harrison-Ruzzo-Ullman Model – uses commands involving conditions and primitive operations where a protection system is a set of subjects, objects, rights, and commands

15 Take-Grant Systems  Four operations performed by subjects on objects with rights Create(o,r) subject creates an object with certain rightsCreate(o,r) subject creates an object with certain rights Revoke(o,r) subject removes rights from objectRevoke(o,r) subject removes rights from object Grant(o,p,r) subject grants to o access rights on pGrant(o,p,r) subject grants to o access rights on p Take (o,p,r) subject removes from o access rights on pTake (o,p,r) subject removes from o access rights on p

16 Trusted System Design Elements  Least privilege  Economy of mechanism  Open design  Complete mediation  Permission based  Separation of privilege  Least common mechanism  Ease of use

17 Security Features of Ordinary Operating Systems  Authentication of users  Protection of memory  File and I/O device access control  Allocation and access control to general objects  Enforcement of sharing  Guarantee of fair service  Interprocess communications and synchronization  Protection of operating system protection data

18 Security Features of Trusted Operating Systems  Trusted systems incorporate technology to address both features and assurance  Objects are accompanied (surrounded) by an access control mechanism  Memory is separated by user, and data and program libraries have controlled sharing and separation

19 Security Features of Trusted Operating Systems  Identification and Authentication Require secure id of individuals, each individual must be uniquely identifiedRequire secure id of individuals, each individual must be uniquely identified  Mandatory and Discretionary Access Control MAC – access control policy decisions are made beyond the control of the individual owner of the objectMAC – access control policy decisions are made beyond the control of the individual owner of the object DAC – leaves access control to the discretion of the object’s ownerDAC – leaves access control to the discretion of the object’s owner MAC has precedence over DACMAC has precedence over DAC

20 Security Features of Trusted Operating Systems  Object Reuse Protection Prevent object reuse leakagePrevent object reuse leakage OS clears (overwrites) all space to be reassignedOS clears (overwrites) all space to be reassigned Problem of magnetic remanenceProblem of magnetic remanence  Complete Mediation All accesses must be controledAll accesses must be controled  Trusted Path For critical operations (setting password, etc.), users want unmistakable communicationsFor critical operations (setting password, etc.), users want unmistakable communications

21 Security Features of Trusted Operating Systems  Accountability and Audit Maintain a log of security relevant eventsMaintain a log of security relevant events Audit log must be protected from outsidersAudit log must be protected from outsiders  Audit Log Reduction Audit only open and close of files/objectsAudit only open and close of files/objects  Intrusion detection Build patterns of normal system usage, triggering an alarm any time usage seems abnormalBuild patterns of normal system usage, triggering an alarm any time usage seems abnormal Intrusion preventionIntrusion prevention

22 Kernelized Design  Kernel – part of OS that performs lowest-level functions Synchronization, interprocess communications, message passing, interrupt handlingSynchronization, interprocess communications, message passing, interrupt handling Security kernel – responsible for enforcing security mechanism for entire OS; provides interface among the hardware, OS, and other parts of computer systemSecurity kernel – responsible for enforcing security mechanism for entire OS; provides interface among the hardware, OS, and other parts of computer system


Download ppt "Chapter 5 – Designing Trusted Operating Systems  What makes an operating system “secure”? Or “trustworthy?  How are trusted systems designed, and which."

Similar presentations


Ads by Google