Presentation is loading. Please wait.

Presentation is loading. Please wait.

Secure Operating Systems Lesson 0x11h: Systems Assurance.

Similar presentations


Presentation on theme: "Secure Operating Systems Lesson 0x11h: Systems Assurance."— Presentation transcript:

1 Secure Operating Systems Lesson 0x11h: Systems Assurance

2 Where are we?  Really, we’re now just looking at the loose ends of OS Security  But there’s one question we don’t have an answer to: how do we KNOW an OS has particular properties?

3 Verification  The aim is to verify that a system enforces a desired set of security goals  Example: are two sets of users separated? Are the mechanisms (e.g. reference monitor) and policies (e.g. MLS) appropriate to enforce the goal? Are these ideas implemented correctly?  Assurance concerns itself with what and how

4 Building secure things is HARD  Three Steps: Define the security goals (clearly!) Design for verification (ideally, using formal methods) Build so that the system can be mapped back to the verified design

5 Assurance Standards  Historically, Orange Book (part of TCSEC)  Now, The Common Criteria  We will take a look at both approaches

6 Orange Book A-D  D: Minimal Protection  C: Discretionary Protection C1 – discretionary security protection C2 – Controlled access protection  B: Mandatory Protection Labeled Security Protection, Structured Protection, Security Domains (B1, B2, B3)  A: Verified Protection A1 – Verified design Beyond A1 – speaks to physical root of trust etc.

7 D: Minimal Protection  Government-speak for “evaluated but failed to meet the requirements of anything higher” (!)  Rule of thumb: D is probably not very helpful (what does it actually tell you?)

8 C1: Discretionary Sec. Protection  DAC: Permissions of named users to named objects  System actions are performed by hardware- protected domains  No obvious ways to bypass controls  Basic documentation required

9 C2: Controlled Access Protection  Rights must be specifiable at the level of the single user  Authentication based on a secret that is protected from others  Audit of particular events in a protected log  Object reuse checked – new objects do not “leak” data from previous uses  C2 is our “day to day” security level

10 B1: Labeled Security Protection  C2 plus MAC  Named objects must be associated with a sensitivity label, corresponding to an MLS policy  Security mechanisms must work as claimed in the documentation (how to verify?)  B1 requires proof of detailed testing – few OS are in this level

11 B2: Structured Protection  Adds protection/enforcement to all objects  Requires covert channel protection  Authentication requires a “trusted path”  The Trusted Computing Base must be “relatively resistant to penetration”

12 B3: Security Domains  Extends the TCB to cover the “reference monitor” concept  TCB is “highly resistant to penetration”

13 A1: Verified Design  A formal model of the security policy, plus a mathematical proof that the model is consistent with the policy  A Formal Top Level Specification (FTLS) of the functions the TCB performs  The FTLS of the TCB must be shown to be consistent with the formal model of the policy  The TCB implementation must be consistent with the FTLS  Formal analysis must be used to identify and analyze covert channels

14 Beyond A1  A1 allows informal verification if no formal tool exists  This class was left open to allow for a system that can be verified more precisely

15 Formal Methods  It’s possible to apply formal methods to computing problems Essentially, prove mathematically that a system functions a certain way  The needs for formal methods are huge: most modern systems are really computers with moving parts  To get 10 -7 failure rates, we cannot rely on visual analysis Exhaustive testing is impossible due to state space explosion

16 Testing?  Debugging requires either examining a crash, or choosing the right test cases  Good coverage is impossible for real systems  Formal methods cover all behaviors, and is certain to find the bugs… provided the model, environment and properties are correct However, all problems are NP-hard, and most are superexponential or even undecidable

17 Common Criteria LevelRequirements EAL1Functionally tested EAL2 (C1)Structurally tested EAL3 (C2/BA)Methodically tested and checked EAL4 (C2/B1)Methodically designed, tested and reviewed EAL5 (B2)Semiformally designed and tested EAL6 (B3)Semiformally verified design and tested EAL7 (A1)Formally verified design and tested

18 Aside: ITSEC and AV  Anti-malware provides some really interesting challenges to all this… let’s discuss

19 Questions & Comments  What do you want to know?


Download ppt "Secure Operating Systems Lesson 0x11h: Systems Assurance."

Similar presentations


Ads by Google