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
ASSURANCE AND ACCOUNTABILITY
▸ 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
▸ 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
Bob Evil
What might be a better policy than “ACME trusts Bob => Bob can access file”? How can you enforce it? = trusts
ASSURANCE AND ACCOUNTABILITY
▸ 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
▸ 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
▸ 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
▸ 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
ASSURANCE AND ACCOUNTABILITY
ASSURANCE AND ACCOUNTABILITY
▸ 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
Design Cycle
Haskell Prototype
Design
Formal Executable Spec High-Performance C Implementation User Programs Hardware Simulator
Proof Manual Implementation
+
ASSURANCE AND ACCOUNTABILITY
Abstract Specification Executable Specification High-Performance C Implementation Haskell Prototype Isabelle/HOL Automatic Translation Refinement Proof
ASSURANCE AND ACCOUNTABILITY
*** TLS
X.509
HTTPS RSA SHA
ECDH
Network buffers Untrusted network (TCP, UDP, …)
Crypto Algorithms
4Q
ASN.1
Certification Authority
▸ Goals: ▸ A fully verified
HTTPS stack
▸ High-performance ▸ Standards-compliant
https://www.microsoft.com/en-us/research/project/project-everest-verified-secure-implementations-https-ecosystem/
ASSURANCE AND ACCOUNTABILITY
▸ Current status: ▸ Low-level verified programming toolchain based on F* ▸ Partially verified TLS-1.3 ▸ Several verified cryptographic algorithms
ASSURANCE AND ACCOUNTABILITY
▸ 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
▸ Restricting communications with the outside world
ASSURANCE AND ACCOUNTABILITY
▸ Example: Virtual machines ▸ Execute system as if running on an isolated computer ▸ Can emulate real hardware or something higher level
ASSURANCE AND ACCOUNTABILITY
▸ Example: Sandboxes
▸ Hides or duplicates resources, mediates access to host system
ASSURANCE AND ACCOUNTABILITY
▸ Example: Processes ▸ Operating system mediates access to shared resources
ASSURANCE AND ACCOUNTABILITY
▸ 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
Facebook Google Maps 3rd Party App: “FriendMap” Alice
Alice’s friend Bob
ASSURANCE AND ACCOUNTABILITY
runs FriendMap
pins for nearby friends
Facebook Google Maps
Alice 1 2 4 3
ASSURANCE AND ACCOUNTABILITY
malicious code!
want locations shared.
execute FriendMap?
Facebook Google Maps
Alice 1 2 4 3
ASSURANCE AND ACCOUNTABILITY
(potentially malicious) mobile code
Facebook Google Maps Bob’s location
Deny access to secret data Restrict communication
Sandbox
ASSURANCE AND ACCOUNTABILITY
▸ Monitor interfaces to system and halt before violations
ASSURANCE AND ACCOUNTABILITY
▸ 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
▸ 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
▸ 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
▸ 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
▸ 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
▸ 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
ASSURANCE AND ACCOUNTABILITY
▸ Reverse the damaging effects of attacks
ASSURANCE AND ACCOUNTABILITY
▸ 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
ASSURANCE AND ACCOUNTABILITY
▸ Some attacks cannot be reversed: ▸ Secrets cannot be un-leaked ▸ Missiles cannot be un-fired
ASSURANCE AND ACCOUNTABILITY
▸ 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
ASSURANCE AND ACCOUNTABILITY
▸ Successful attacks are inevitable ▸ Attackers need only one vulnerability, but defenders lose unless
they prevent all attacks
▸ In the real world, defenses are not the only deterrents to attack:
security cameras, police, and the legal system
▸ Accountability: ▸ Hold people legally responsible for actions they instigate by
capturing and preserving association between that person and the action performed.
ASSURANCE AND ACCOUNTABILITY
▸ Authentication ▸ Associates a principal with actions and communications ▸ Authorization ▸ Decides whether an action is allowed to proceed ▸ Audit ▸ Records system activity and attributes actions to
responsible principals
ASSURANCE AND ACCOUNTABILITY
▸ Devising good authentication methods is challenging
because they must be
▸ Hard enough to guess or counterfeit that a determined
attacker cannot impersonate
▸ Easy enough to remember or use that a casual user can
use them correctly
ASSURANCE AND ACCOUNTABILITY
▸ Categories of authentication methods: ▸ Something you know. Demonstrate knowledge of a
secret an impersonator is unlikely to know.
▸ Something you have. Demonstrate possession of an
▸ Something you are. Permit some distinguishing
physical characteristic to be measured.
▸ Combining multiple mechanisms increases confidence
▸ Security is undermined, however, when mechanisms aren’t
independent
ASSURANCE AND ACCOUNTABILITY