Secure Operating Systems Lesson 0x11h: Systems Assurance

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?

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

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

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

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.

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?)

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

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

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

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”

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

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

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

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 failure rates, we cannot rely on visual analysis Exhaustive testing is impossible due to state space explosion

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

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

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

Questions & Comments  What do you want to know?