1. PRECIP: Towards Practical and Retrofittable Confidential Information Protection XiaoFeng Wang (IUB), Zhuowei Li (IUB), Ninghui Li (Purdue) and Jong Youl Choi (IUB)

2. How to protect your information from spyware? Prevent it ! Detect it ! However…

3. The last defense line  Contain unauthorized surveillance

4. Spyware containment  Existing access control mechanisms are insufficient  Spyware can watch authorized party’s access to a secret  Alternative: information flow security  Track sensitive data  Prevent them from flowing into unauthorized parties

5. Information flow security  The Bell-LaPadula model sensitive highly sensitive public

6. However, this is insufficient for a modern OS  User input object  keyboard, mouse…  When does it become sensitive?  Other shared object  screen, clipboard …  sensitive? public?  Multitasked subject  Work concurrently on public and sensitive data  Which output is sensitive?

7. Requirements for a usable IF model  Work on a modern OS  Efficient enough for online operation  Instruction-level tracking can be too slow  Retrofittable to legacy systems  Avoid modifying the source code of app, of OS

8. PRECIP A first step towards practical and retrofittable confidential information protection  Track an application’s input/output dependence  Model input object and shared object  Designed for online operations  Retrofittable to legacy applications and OS

9. The model  Subjects and objects  Local objects (files, buffers, keyboard, screen,…)  Remote objects (website…)  User input objects (UIO): objects for transferring inputs (keyboard)  Channels  Connect subject to subject, subject to object, object to subject  A path is composed of multiple channels  Messages  Information on a channel in the form of “messages”  Examples: keyboard events, mouse events, data through a “read” call

10. The model (cont’d)  Dependency relation  Output messages depend on some input messages  An input to the PRECIP model  Sensitivity levels  high: “sensitive”, low: “public”  Trusted and untrusted subjects  Untrusted: unknown dependency relations  Trusted: all dependency relations are known

11. Security objective  Information is sensitive if  it depends (directly or transitively) upon a message from an sensitive object, or sensitive inputs from an UIO  Information leakage happens if  Sensitive info gets into an untrusted subject or a remote public object  Objective: Sensitive information shouldn’t be leaked

12. Policies achieving the objective  Tracing rules  Sensitive msg: either from a sensitive obj or dependent upon a sensitive msg  Obj  sensitive if it receives a sensitive msg  UIO  sensitive iff a path connects it to a sensitive obj  Obj  public if it is cleaned  Control rules  Block sensitive msg to public remote obj and untrusted sub  Sensitive info to a local obj  block the msg or mark the obj sensitive

13. Application of PRECIP to Windows XP

14. Adversary model  Spyware is not inside the kernel when PRECIP is installed  However, our integrity protector can preventspyware to be installed through system calls  PRECIP is not designed for preventing exploit of software vulnerabilities  We use existing tools to do the job

15. Classification and labeling  Trust levels  Classify applications according to dependency rules  Mark an executable using its NTFS file stream  Sensitivity levels  Automatic classification: using a file’s DAC

16. Dependency rules for editing/viewing App Sensitive Public Sensitive Public

17. Dependency rules for web browsers

18. Management of hooks

19. Integrity protection  Prevent unauthorized access of subject’s and object’s labels, contents and PRECIP settings  Regulate calls related to file system, auto-start extensibility points and process  Only allow signed kernel drivers to be loaded  A policy also used in Windows Vista

20. Evaluation  Dependency rules  Test dependency rules on Microsoft office, Adobe Acrobat and Notepad  Quite effective in most cases  Effectiveness  Performance

21. Effectiveness

22. Performance  Performance of hook management  Baseline (no proxy): 691.015 microseconds  PRECIP: 784.809 microseconds  Overhead: 13.57%  Performance of the kernel driver  Evaluated using WorldBench 5.0

23. Limitations  Dependency rules are empirical  Research: automatic analysis of an application to generate rules  Integrity model as a complementary  Model is incomplete  Multiple sensitivity levels  Compartmentalization

24. Related research  Language-based information flow security  For design of a new program  Instruction-level tracking  Hard to use online without hardware support  New systems such as Abestos, IX, Flume,…  Need to modify OS  Sandboxing techniques  Too coarse-grained

25. Conclusions  Propose a new confidentiality model for practical and retrofittable IF protection  Application of the model to Windows XP  Future research  Improve the model  Improve the techniques for enforcing the model