ASSURANCE AND ACCOUNTABILITY ASSURANCE AND ACCOUNTABILITY GENERAL - PowerPoint PPT Presentation

ADVANCED COMPUTER SECURITY ASSURANCE AND ACCOUNTABILITY

ASSURANCE AND ACCOUNTABILITY GENERAL INFO / ANNOUNCEMENTS ▸ Reminder : read and post response to “Enforceable Security Policies” by tomorrow afternoon. ▸ Please send me your talk preferences, and consider next week’s papers ▸ Check website for presentation assignments ▸ If you sent me preferences and don’t see your name, let me know. ▸ Slides from Friday are up, these will be soon too

ASSURANCE AND ACCOUNTABILITY TRUST VS TRUSTWORTHY ▸ A perspective on trust : an assumption that something behaves as it was intended to behave. ▸ Being trusted is not the same as being trustworthy ▸ By trustworthy, we mean something that actually behaves as intended. ▸ Trust can be misplaced

ASSURANCE AND ACCOUNTABILITY MISPLACED TRUST What might be a better policy than “ACME trusts Bob => Bob can access file”? Evil Bob ACME How can you enforce it? = trusts

ASSURANCE AND ACCOUNTABILITY TRUSTED COMPUTING BASE ▸ The set of mechanisms required to function correctly for the system to behave as expected. ▸ Examples: ▸ CPU logic (e.g., 2 + 2 = 4) ▸ Language runtime (JVM, C libraries, etc.) ▸ Memory safety (e.g., no buffer overflows)

ASSURANCE AND ACCOUNTABILITY ASSURANCE AND THE TCB ▸ Plenty of trusted computing bases have relatively low assurance of trustworthiness. ▸ The smaller the TCB, the easier it is to: ▸ Audit ▸ Verify ▸ Understand ▸ Minimizing the TCB is a crucial part of good designs

ASSURANCE AND ACCOUNTABILITY HIGH ASSURANCE TRUSTED CODE BASES ▸ Verifying the security of pre-existing TCBs is very difficult. ▸ Relatively innocuous aspects of a system design may significantly complicate proofs ▸ Recently, there has been significant progress building large, verified systems from scratch ▸ “We can now achieve degree of trustworthiness of formal, machine-checked proof that far surpasses the confidence levels we rely on in engineering or mathematics for our daily survival” — Klein et. al, SOSP’09 (sel4 authors)

ASSURANCE AND ACCOUNTABILITY COMPCERT ▸ Verified compiler (in Coq) for C programming language ▸ Supports “almost all” of ISO C99 standard ▸ Decent performance, but not as optimized as GCC ▸ Designed as a series of code transformations, each of which is proven formally correct. ▸ ~37k lines of Coq code (~6.4k lines for compiler itself) ▸ ~2 person-years of development http://compcert.inria.fr

ASSURANCE AND ACCOUNTABILITY COMPCERT COMPILATION PROCESS

ASSURANCE AND ACCOUNTABILITY COMPCERT PERFORMANCE

ASSURANCE AND ACCOUNTABILITY SEL4 ▸ First general-purpose OS kernel with proof of correctness ▸ 8.7k lines of C + 600 lines of assembly ▸ 200k lines of Isabelle/HOL proof script ▸ ~2.2 person-years of OS development ▸ ~20 person-years of proof, but estimate only ~6 for a similar project ▸ Performance comparable to other L4-family kernels Klein et. al, “seL4: Formal Verification of an OS Kernel.” SOSP’09

ASSURANCE SEL4 DESIGN PROCESS Design Cycle Design Hardware Haskell + Formal Executable Spec Simulator Prototype Manual Proof Implementation User Programs High-Performance C Implementation

ASSURANCE AND ACCOUNTABILITY SEL4 PROOF APPROACH Isabelle/HOL Abstract Specification Executable Specification Haskell Prototype Automatic Translation High-Performance C Implementation Refinement Proof

ASSURANCE AND ACCOUNTABILITY PROJECT EVEREST HTTPS ▸ Goals: Certification ASN.1 X.509 Authority ▸ A fully verified TLS HTTPS stack *** RSA SHA ▸ High-performance ECDH 4Q Crypto Algorithms ▸ Standards-compliant Network buffers Untrusted network (TCP, UDP, …) https://www.microsoft.com/en-us/research/project/project-everest-verified-secure-implementations-https-ecosystem/

ASSURANCE AND ACCOUNTABILITY PROJECT EVEREST ▸ Current status: ▸ Low-level verified programming toolchain based on F* ▸ Partially verified TLS-1.3 ▸ Several verified cryptographic algorithms

ASSURANCE AND ACCOUNTABILITY ENFORCEMENT MECHANISMS ▸ An attack causes instructions to be executed that result in a violation of some security property ▸ An enforcement mechanism either prevents that execution or recovers from its effects ▸ Ideally we want enforcement mechanisms that support a broad range of policies

ASSURANCE AND ACCOUNTABILITY ISOLATION ▸ Restricting communications with the outside world

ASSURANCE AND ACCOUNTABILITY ISOLATION ▸ Example: Virtual machines ▸ Execute system as if running on an isolated computer ▸ Can emulate real hardware or something higher level

ASSURANCE AND ACCOUNTABILITY ISOLATION ▸ Example: Sandboxes ▸ Hides or duplicates resources, mediates access to host system

ASSURANCE AND ACCOUNTABILITY ISOLATION ▸ Example: Processes ▸ Operating system mediates access to shared resources

ASSURANCE AND ACCOUNTABILITY CHALLENGES OF ISOLATION ▸ For assurance of security, want to restrict communication as much as possible ▸ For functionality , need to support many kinds of communication ▸ Sometimes, you get neither: ▸ The same origin policy provides little security, but limits the kind of web applications one can easily build

ASSURANCE AND ACCOUNTABILITY EXAMPLE: A MOBILE MASH-UP APP Facebook 3rd Party App: “FriendMap” Alice Alice’s friend Bob Google Maps

ASSURANCE AND ACCOUNTABILITY FRIENDMAP 1. Alice downloads and 2 runs FriendMap 4 2. Fetch friends’ locations Facebook 3. Get a map and place 3 Alice pins for nearby friends 4. Post to network 1 Google Maps

ASSURANCE AND ACCOUNTABILITY FRIENDMAP ? 2 • FriendMap may be malicious code! 4 Facebook • Alice’s friends may not want locations shared. 3 Alice • How can Alice safely execute FriendMap? 1 Google Maps

ASSURANCE AND ACCOUNTABILITY LIMITS OF (BLACKBOX) OF ISOLATION Bob’s location Deny access to secret data Facebook (potentially malicious) Restrict mobile code communication Sandbox Google Maps

ASSURANCE AND ACCOUNTABILITY MONITORING ▸ Monitor interfaces to system and halt before violations

ASSURANCE AND ACCOUNTABILITY MONITORING ▸ Monitor the interfaces of a system and halt before violations occur ▸ Security policy: acceptable sequences of operations ▸ Reference monitor: checks operations as they are requested ▸ Kill switch: some way of stopping the system before damage occurs

ASSURANCE AND ACCOUNTABILITY SECURITY POLICIES ▸ Monitoring is useful for enforcing policies expressed in terms of principals and their privileges ▸ Each principal is assigned a set of privileges ▸ Each operation requires a set of privileges to execute ▸ If a principal requests an operation without the necessary privileges, execution is halted ▸ Access control lists and capabilities are examples

ASSURANCE AND ACCOUNTABILITY DESIGN PRINCIPLES ▸ Complete mediation: The reference monitor should intercept every access to every object . ▸ Usually overkill, but encourages justification for exceptions ▸ Ensures an opportunity for enforcement, but doesn’t prescribe what the correct action is.

ASSURANCE AND ACCOUNTABILITY DESIGN PRINCIPLES ▸ Least privilege: A principal should only be granted the minimum privilege necessary to complete a task. ▸ Minimizes damage in event of an attack. ▸ For example: a web server (typically) only needs read access to the files it serves. Running as root risks complete compromise of the system if the server is hacked.

ASSURANCE AND ACCOUNTABILITY DESIGN PRINCIPLES ▸ Separation of privilege Different kinds of operations should require different privileges. ▸ More separation yields finer-grained policies ▸ Enables least-privilege policies ▸ Potentially difficult to manage as # of privileges increases

ASSURANCE AND ACCOUNTABILITY DESIGN PRINCIPLES ▸ Failsafe defaults Use the presence of privilege rather than absence of prohibition to determine access. ▸ Access denials when necessary privileges are omitted are preferable to security violations ▸ Also more future-proof: easier to add new privileges or operations safely

ASSURANCE AND ACCOUNTABILITY RECOVERY ▸ Reverse the damaging effects of attacks

ASSURANCE AND ACCOUNTABILITY RECOVERY ▸ Most effective at reversing corruption or malicious modifications made by an attacker. ▸ Examples: ▸ Running browser in a VM to avoid malware ▸ Reverting to known-good backups after a compromise ▸ Transactional processing of concurrent sequences operations (revert on conflicts)

ASSURANCE AND ACCOUNTABILITY RECOVERY ▸ Some attacks cannot be reversed: ▸ Secrets cannot be un-leaked ▸ Missiles cannot be un-fired

ASSURANCE AND ACCOUNTABILITY DEFENSE IN DEPTH ▸ Use multiple mechanisms to increase resistance to attacks ▸ Mechanisms should not be redundant: ▸ An attack on one shouldn’t affect the others ▸ Mechanisms should “overlap” so that all mechanisms must be successfully attacked for a violation to succeed ▸ Examples: ▸ Two-factor authentication: password + device