Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CSCD27 Protection

ThierrySans
November 10, 2016
470

CSCD27 Protection

ThierrySans

November 10, 2016
Tweet

Transcript

  1. Protecting Programs How to lower the risk of a program

    security flaw resulting from a bug? 1. Build better programs 2. Build better operating systems
  2. Why are we still vulnerable to buffer overflows? Why code

    written in assembly code or C are subject to buffer overflow attacks? ➡ Because C has primitives to manipulate the memory directly (pointers ect ...)
  3. Choosing a better programming language Some languages are type-safe (i.e

    memory safe) ➡ Pure Lisp, pure Java, ADA, ML … Some languages isolate potentially unsafe code ➡ Modula-3, Java with native methods, C# … Some languages are hopeless ➡ Assembly languages, C …
  4. ➡ Cannot access arbitrary memory addresses ➡ Cannot corrupt their

    own memory ✓ Do not crash Type-Safe Programs
  5. So why are we still using unsafe programming languages? If

    other programming languages are “memory safe”, why are we not using them instead? ➡ Because C and assembly code are used when a program requires high performances (audio, vide, calculus …) 
 or when dealing with hardware directly (OS, drivers ….)
  6. Can we write better programs with unsafe programming languages? Defensive

    Programming Approach 1. Adopting good programming practices 2. Being security aware programmer Proactive Approach 3. Using security libraries 4. Performing penetration testing Formal Approach 5. Using formal methods to verify a program 6. Using formal methods to generate a program
  7. 2. Adopting good programming practices Modularity ➡ Have separate modules

    for separate functionalities ✓ Easier to find security flaws when components are independent Encapsulation ➡ Limit the interaction between the components ✓ Avoid wrong usage of the components Information hiding ➡ Hide the implementation ๏ Black box model does not improve security
  8. 2. Being security aware programmer ✓ Check the inputs, even

    between components that belongs to the same application (mutual suspicion) ✓ Be “fault tolerant” by having a consistent policy to handle failure (managing exceptions) ✓ Reuse known and widely used code by using design patterns and existing libraries
  9. 3. Using security libraries - stack smashing protection Check that

    the stack has not been altered when a function returns ➡ If it has been altered, the program exits with a segmentation fault ✓ Verification embedded into the program by the compiler
  10. 3. Using security libraries - examples ✓ Libsafe ✓ StackGuard

    ✓ ProPolice (gcc patches) ✓ Microsoft's Data Execution Prevention
  11. 4. Testing and Penetration Testing Testing the functionalities ✓ Unit

    test, Integration test, Performance test and so on …
 Testing the security ✓ Penetration tests ➡ Try to make the software fail by pushing the limits of a “normal” usage i.e test what the program is not supposed to do
  12. 5. Using formal methods to verify a program Static analysis

    - analyzing the code to detect security flaws • Control flow - analyzing the sequence of instructions • Data flow - analyzing how the date are accessed • Data structure - analyzing how data are organized ➡ Abstract interpretation [Cousot] ✓ Verification of critical embedded software in Airbus aircrafts
  13. 6. Using formal methods to generate a program Mathematical description

    of the problem Proof of correctness Executable code
 or hardware design Refinement 
 steps
  14. 6. Using formal methods to generate a program Hardware design

    (VHDL, Verilog) ✓ Used by semi-conductor companies such as Intel Critical embedded software (B/Z, Lustre/Esterel) ✓ Urban Transportation 
 (METEOR Metro Line 14 in Paris by Alstom) ✓ Rail transportation (Eurostar) ✓ Aeronautic (Airbus, Eurocopter, Dassault) ✓ Nuclear plants (Schneider Electric)
  15. Pros and cons of using formal methods ✓ Nothing better

    than a mathematical proof ➡ A code “proven safe” is safe ๏ Development is time and effort (and so money) consuming ➡ Should be motivated by the risk analysis ๏ Do not prevent from specification bugs ➡ Example of network protocols
  16. Memory and address protection • Programs (and data) used the

    same address space • They should not access memory addresses that has not been allocated to them • When a program tries to access to an authorized memory address, an exception is raised ➡ The well known “segmentation fault”
  17. Basic (but inefficient) protection - segmentation ➡ Cutting the program

    into pieces (segments) that can be located dynamically wherever in the memory (useful for caching) ✓ A program can access a segment only if it appears in the segment table ๏ But Shellcode are located in the same segment table
  18. Tagged Architecture ➡ Tagging memory cells as data or instructions

    during execution ✓ Data in a buffer cannot be turned into a instructions like in buffer overflow attacks • Processors implementing this technique
 Intel XD (EDB) or AMD64 NX (EVP) • Operating Systems using it
 OpenBSD and OSX
  19. Return Address Protection ➡ Encrypt the return address on stack

    by XORing 
 with a random string ✓ Attacker will not know what address to use in his string • Operating System using this technique
 Windows Vista
  20. Address Space Layout Randomization (ASLR) ➡ Randomize the return address

    on the stack dynamically ✓ Attacker cannot guess the return address as it expires rapidly • Operating Systems using this technique • OpenBSD • Linux (since 2.6.12) • Windows (since Vista) • Mac OSX (fully supported since 10.7 Lion) • iOS (since 4.3) • Android (since 4.0 Ice Cream Sandwich)
  21. Confined execution environment - Sandbox A sandbox is tightly-controlled set

    of resources for untrusted programs to run in ➡ Sandboxing servers - virtual machines ➡ Sandboxing programs • Chroot and AppArmor in Linux • Sandbox in MacOS Lion • Metro App Sandboxing in Windows 8 ➡ Sandboxing applets - Java and Flash in web browsers
  22. Intrusion Detection/Prevention Systems • Host-based Intrusion Detection Systems (IDS) •

    Host-based Intrusion Prevention systems (IPS) ✓ Based on signatures (well known programs) ✓ Based on behaviors (unknown programs) ➡ Example : Syslog and Systrace on Linux ๏ Vulnerable to malicious programs residing in the 
 kernel called “rootkits”
  23. Os security features • Ubuntu Linux
 https://wiki.ubuntu.com/Security/Features • Windows 7


    http://resources.infosecinstitute.com/windows-7-security- features/ • OS X
 https://www.apple.com/osx/what-is/security.html
  24. Why this lecture about “assurance”? In my experience, Security Assurance

    is a boring part … 
 ... but you may get a job just because you know what it is!
  25. What is security assurance? I ask your company to create

    a piece of software for me … 
 … as a non-security expert, what kind of assurance can you give me about the security of your product?
  26. Why and how to evaluate security? Why do we care

    about security assurance? ➡ If you think we should not care about security you have been sitting in the wrong class for half a semester How to evaluate the security of a product/system? ➡ evaluate the person making the product ➡ or evaluate the product itself
  27. Standards and certifications How do we agree on evaluation criteria?

    ➡ Certifications based on Standards Who should run the evaluation? 
 Who delivers the certification? ➡ A certification authority (trusted third-party) called a registrar
  28. Outline Evaluate and certify an organization • ISO/IEC 27000 series

    Evaluate and certify a product or a system • TCSEC (“The Orange Book”) (1983-1999)
 was the American standard • ITSEC (1991-2001)
 was the European standard • ISO/IEC 15408 (“The Common Criteria”) (since 1998)
 is the actual international standard
  29. ISO/IEC 27k - Security Assurance Objective - provide the best

    practice recommendations on information security management, risks and controls ➡ equivalent to the ISO/IEC-9000series (quality assurance)
  30. ISO/IEC 27k in action How to get certified? 1. The

    organization submit an evaluation plan to the registrar 2. The registrar runs the first audit and grant the certification 3. The registrar keeps on auditing the organization to guarantee the certification
  31. What is inside the ISO/IEC 27k The code of practice

    (ISO/IEC 27002) ➡ List of 133 candidate control objectives and controls ➡ Each control must be addressed one by one in the evaluation plan (extras can be added)
  32. Governing principles Based on an iterative problem-solving process ➡ Deming's

    Wheel (PDCA) run a risk analysis 
 and define the security policy design and build 
 security solutions 
 (called controls) improve 
 the security assurance measure 
 the security solutions
  33. These controls about ... • Risk assessment (how to drive

    the risk analysis) • Security policy • Organization of information security (governance) • Asset management (inventory and classification of information assets) • Human resources protection (security aspects for employees joining, moving and leaving an organization) • Physical and environmental security (protection of computer facilities)
  34. ... and more • Communications and operations management (infrastructure supporting

    the activity) • Access Control (restrictions of access rights) • Information systems acquisition, development and maintenance (result of the activity) • Information security incident management (CERT) • Compliance (ensuring conformance with security policies, standards, laws and regulations)
  35. Objective and methods Objective - provide an evaluation methodology •

    Defining the set of security functionalities • Defining a set of assurance requirements • Determining whether the product or system meet the assurance requirements • Determining a measure of the evaluation results 
 Evaluation Assurance Level (EAL) ➡ Technical Evaluation based on security assurance methods • Testing and penetration testing • Formal development and/or formal verification
  36. TCSEC - “The Orange Book” (1983-1999) Objective - evaluate and

    classify computer systems (i.e. OS) regarding the storage, retrieving and processing of sensitive data ➡ Initiated by the US DOD in the 70's photo from Wikipedia
  37. Governing principles Introduce the concept of policy • It must

    be explicit and enforceable by a computer system • Two kind of policies are considered DAC and MAC Introduce the concept of accountability • Users must be identified and authenticated • Each access must be logged
  38. TCSEC - security assurance classes (1991-2001) Class D - minimal

    protection ➡ No security requirements Class C - discretionary security protection ➡ Multi-user environment and data with different sensitivity levels Class B - mandatory security protection ➡ Object labels, user clearance levels and multilevel security policy Class A - verified protection ➡ Formal design and verification
  39. The Common Criteria (since 1998) Protection Profile - the functionalities

    and the security requirements of the product/system ➡ Written by the system consumer Security Target - identifies the security properties ➡ Written by the software designer in response to the protection profile Let’s look at some protection profiles on
 http://www.commoncriteriaportal.org/pps/
  40. Evaluation Assurance Levels (EAL) EAL 1 - Functionally Tested ➡

    Requires a documentation of the security functions vouching for a minimum confidence regarding their correction but threats are not considered as serious EAL 2 - Structurally Tested ➡ Requires the delivery of test procedures and test results EAL 3 - Methodically Tested and Checked ➡ Requires the developers to be aware of good software engineering practices
  41. Evaluation Assurance Levels (EAL) EAL 4 - Methodically Designed, Tested

    and Reviewed ➡ Requires good commercial developments methods to ensure good software engineering practices EAL 5 - Semi-formally Designed and Tested ➡ Requires rigorous commercial development practices supported by a security expert
  42. Evaluation Assurance Levels (EAL) EAL 6 - Semi-formally Verified Design

    and Tested ➡ Requires a rigorous development environment EAL 7 - Formally Verified and Tested ➡ Requires a rigorous security-oriented development environment Let's see some certified products on 
 http://www.commoncriteriaportal.org/products/
  43. Drawbacks of product evaluation 1. Preparing the documentation for evaluation

    is a long time effort ➡ The product is obsolete once certified 2. Going through such an evaluation is a costly process ➡ The return on investment is not necessarily a more secure product 3. The evaluation is performed on the documentation and not on the product itself ➡ A good EAL does not prevent from security flaws
  44. What are the related jobs You can become • an

    auditor evaluating an organization or a product and delivering the certification • a consultant helping to write the documents needed to pass the certification What do you need to know/do? • CS and IT systems in general • the standards • get certified as an auditor or a consultant
 and get hired by a registrar