Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chap5: Designing Trusted Operating Systems.  What makes an operating system “secure”? Or “trustworthy”?  How are trusted systems designed, and which.

Similar presentations


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

1 Chap5: Designing Trusted Operating Systems

2  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 system? SE571 Security in Computing Dr. Ogara 2

3  Prime providers of security in computing systems.  They support many programming capabilities, sharing of resources, and enforce restrictions on program and user behavior  Often are targets for attack SE571 Security in Computing Dr. Ogara 3

4  Four requirements from designers perspective Security policy  a set of rules that lay out what is to be secured and why  a statement of the security we expect the system to enforce  Several security policies needed SE571 Security in Computing Dr. Ogara 4

5 Model  Construct model for environment to be secured  Model represents policy to be enforced  Models helps to analyze different ways of enforcing given security policies Design  How do you implement the security policy?  Several choices to choose from SE571 Security in Computing Dr. Ogara 5

6 Trust  Assurance from users that OS meets security expectation  OS will enforce security correctly SE571 Security in Computing Dr. Ogara 6

7  Military security policy Based on protecting classified information Information is ranked at different sensitivity level, e.g.  Unclassified  Restricted  Confidential  Secret  Top secret SE571 Security in Computing Dr. Ogara 7

8  Military security policy Information access based on need-to-know rule  Access given to those who information to perform their jobs Each piece of classified information may be associated with one or more projects, called compartments A compartment may include information at only one or several sensitivity levels SE571 Security in Computing Dr. Ogara 8

9 Figure 5-1 Hierarchy of Sensitivities. Least Sensitive SE571 Security in Computing Dr. Ogara 9

10 Figure 5-2 Compartments and Sensitivity Levels. SE571 Security in Computing Dr. Ogara 10

11  Why study models of computer security? To determining the policies a secure system should enforce To understand the properties of protection systems  Models are essential in the design of security policies SE571 Security in Computing Dr. Ogara 11

12  Multilevel Security Lattice Model of Access Security Bell–La Padula Confidentiality Model Biba Integrity Model SE571 Security in Computing Dr. Ogara 12

13  Models Proving Theoretical Limitations of Security Systems Graham–Denning Model Harrison–Ruzzo–Ullman Results Take–Grant Systems SE571 Security in Computing Dr. Ogara 13

14  Design principles for good security Least privilege. Users and programs should use the fewest privileges possible to minimize malicious attack Economy of mechanism. The protection system should be small, simple, and straightforward Open design. The protection mechanism should be public, depending on secrecy of relatively few key items, such as a password table SE571 Security in Computing Dr. Ogara 14

15  Design principles for good security Complete mediation. Every access attempt must be checked Permission based. The default condition should be denial of access Separation of privilege. Access to objects should depend on more than one condition, e.g. authentication plus a cryptographic key SE571 Security in Computing Dr. Ogara 15

16  Design principles for good security Least common mechanism. Shared objects provide potential channels for information flow. Systems employing physical or logical separation reduce the risk from sharing Ease of use. If a protection mechanism is easy to use, it is unlikely to be avoided SE571 Security in Computing Dr. Ogara 16

17  Regular OS – addresses features only  Trusted OS – addresses features and assurance (Figure 5-11) SE571 Security in Computing Dr. Ogara 17

18  User identification and authentication  Mandatory access control  Discretionary access control  Object reuse protection  Complete mediation SE571 Security in Computing Dr. Ogara 18

19  Trusted path  Audit  Audit log reduction  Intrusion detection SE571 Security in Computing Dr. Ogara 19

20  User identification and authentication Know who is requesting access and verify identity  Mandatory access control Access control policy decisions are beyond the control of the individual Central authority determines access, and the user cannot change access rights SE571 Security in Computing Dr. Ogara 20

21  Discretionary access control Leaves a certain amount of access control to the discretion of the object’s owner /anyone authorized to control object’s access Owner determines who should have access rights to an object and what those rights should be SE571 Security in Computing Dr. Ogara 21

22  Object reuse protection Ability to control reusable resources from serious vulnerability Prevents object reuse leakage by overwriting on all space to be reassigned before allowing the next user to have access to it  Complete mediation All access are controlled SE571 Security in Computing Dr. Ogara 22

23  Trusted path Allow users to supply protected information only to a legitimate receivers  Accountability and audit Create audit log – list events and people responsible for addition, deletion and change Audit log must be protected from outsiders. SE571 Security in Computing Dr. Ogara 23

24  Audit log reduction Audit log may be too difficult to handle, owing to volume and analysis Problem is simplified by an audit of only the opening (first access to) and closing of (last access to) files or similar objects Objects such as individual memory locations, hardware registers, and instructions are not audited SE571 Security in Computing Dr. Ogara 24

25  Intrusion detection software Builds patterns of normal system usage and triggers an alarm when usage seems abnormal SE571 Security in Computing Dr. Ogara 25

26 Figure 5-11 Security Functions of a Trusted Operating System. SE571 Security in Computing Dr. Ogara 26

27  Virtualization The operating system emulates or simulates a collection of a computer system’s resources (processor, storage, and some I/O devices) Allows users to access complex objects in a carefully controlled manner SE571 Security in Computing Dr. Ogara 27

28  virtual machine Collection of real or simulated hardware facilities A virtual machine gives the user a full set of hardware features/complete machine that may be substantially different from the real machine Virtual memory gives the user a memory space that is logically separated from real memory and may be larger than real memory SE571 Security in Computing Dr. Ogara 28

29 Figure 5-18 Conventional Operating System. SE571 Security in Computing Dr. Ogara 29

30 Figure 5-19 Virtual Machine. SE571 Security in Computing Dr. Ogara 30

31  Assurance methods - ways of convincing others that a model, design, and implementation are correct Testing  widely accepted assurance technique  Conclusion based on actual product tested SE571 Security in Computing Dr. Ogara 31

32  Assurance methods Penetrating testing  Also called tiger team analysis, or ethical hacking  Experts crack the system being tested  Popular with the commercial community who think skilled hackers will test (attack) a site SE571 Security in Computing Dr. Ogara 32

33  Assurance methods Formal verification  most rigorous method of analyzing security  confirms whether the operating system provides the security features it should and nothing else. SE571 Security in Computing Dr. Ogara 33

34  Desirable Qualities Extensibility – Can the evaluation be extended as the product is enhanced? Granularity – Does the evaluation look at the product at the right level of detail? Speed – Can the evaluation be done quickly enough to allow the product to compete in the marketplace? SE571 Security in Computing Dr. Ogara 34

35  Desirable Qualities Thoroughness - Does the evaluation look at all relevant aspects of the product? Objectivity – Is the evaluation independent of the reviewer's opinions? Portability – Does the evaluation apply to the product no matter what platform the product runs on? SE571 Security in Computing Dr. Ogara 35

36  Desirable Qualities Consistency – Do similar products receive similar ratings? Compatibility – Could a product be evaluated similarly under different criteria? Exportability – Could an evaluation under one scheme be accepted as meeting all or certain requirements of another scheme SE571 Security in Computing Dr. Ogara 36


Download ppt "Chap5: Designing Trusted Operating Systems.  What makes an operating system “secure”? Or “trustworthy”?  How are trusted systems designed, and which."

Similar presentations


Ads by Google