1. EN.600.424 Lecture Notes Spring 2016 ASSURANCE AND EVALUATION

2. HARD TOPICS Assurance Whether the system will work Has the system been beat up “enough” Evaluation Convincing other people of assurance Convince who? Clients Boss Juries

3. ASSURANCE Anderson’s definition: “Our estimate of the likelihood that the system will not fail in a particular way.” Note, it’s still about context Can be based on who built it, technical assessments, formal methods, etc BIG FACTOR IN DETERMINING: EXPERIENCE What needs to be assured (focus on the security aspects)? Proper functionality Strength of mechanisms Implementation Usability

4. INCENTIVES What might the average user want? High usability, medium assurance, high strength of mechanisms, simple functionality Why doesn’t the market deliver this? The incentives according to Anderson: Rush to market (low security from the start) Later security designed to lock users in

5. ASSURANCE: SECURITY TESTING White box testing Start by examining the architecture Next look for implementation flaws (buffer overflows, etc.) Finally, the “experience” level flaws: Crypto used the wrong way Poor random-number generators

6. ASSURANCE: BUG ANALYSIS Fault injection: Very important Every system should be tested with introduced bugs Estimating undiscovered bugs based on discovered bugs For every 1 discovered bug, there exists x more undiscovered bugs The value of x depends on the organization (training, quality, experience) If you have a guess for x, you can guess how many bugs you have based on how many are discovered

7. WHY VULNERABILITIES ARE HARD TO STOP Anderson gives an example of a terrorist and a security engineer Terrorist only gest 1000 hours per year on testing Engineer gets source code and effectively 10,000,000 hours of testing Terrorist gets 1 bug a year, Engineer gets 10,000 BUT, the chance the terrorist’s bug was found is only 1%

8. EVALUATION Anderson’s definition: “‘the process of assembling evidence that a system meets, or fails to meet, a prescribed assurance target” This is sometimes confused with testing; although it overlaps, they are different Tension between the implementing and using party Another problem: how long is the evaluation good for? (The attacks get better over time)

9. “ORANGE BOOK” EVALUATIONS C1 – No significant access controls C2 – Well configured commercial systems B1 – MAC B2 – Structured protection, B1 + formal model of security policy B3 – B2 + security domains, minimal TCB A1 – Formal verification proves TCB implements security policy

10. “COMMON CRITERIA” More flexibility than Orange Book Bell Lapadula is not required; instead, a product is evaluated against a protection profile However, this has led to a plethora of protection profiles

11. PROTECTION PROFILE ELEMENTS Security requirements, rationale, EAL (Evaluation assurance level) Security target is a refinement of a protection profile for a given target of evaluation Profile includes standardized naming of certain elements. Catalogs exist of: Threats: T.Load_Mal – “Data loading malfunction” Assumptions: A.Role_Man – “Role management” Organizational policies: P.Crypt_std – “Cryptographic standards” Objectives: O.Flt_Ins – “Fault insertion” Assurance requirements: ADO_DEL.2 – “Detection of modification”

12. HOW GOOD IS “COMMON CRITERIA” Results have been mixed (Oracle claimed “unbreakable” security… until they were broken) Depends almost entirely on the quality of the protection profile When told a product has a common criteria evaluation, ask against what profile

13. WHAT COMMON CRITERIA DON’T DEAL WITH Pretty much all the hard problems: Administrative security matters Crypto algorithms Evaluation methodology Evidence that the protection profile corresponds to the real world Published work on relevant vulnerabilities Criticisms: Focus on technical aspects ignoring critical issues like usability Doesn’t deal well with change Often, CC only evaluate “basic” features

14. FUTURE SOLUTIONS? First, there is no silver bullet. Anderson suggests that some evaluation should be real-world use Obviously, there are risks to the users before the evaluation is complete But we can propose preliminary evaluations based on similar case studies Anderson: The current approach takes a commercial market and puts it in a bureaucratic straight-jacket

15. HOSTILE REVIEWS Example: NASA paid for every bug found in the manned-spaceflight code Example: NSA v Sandia to find bugs in each other’s nuclear control code

16. OPEN-SOURCE SOFTWARE Argument for: Many eyes prevent back-doors, find bugs Argument against: Communities lose interest PGP (open source) bug Sendmail backdoors Incentives are still off: More attention paid to developers than bug finders Also, evolve faster than commercial products

17. MORE INCENTIVES (PATCHING) Vendors prefer no bugs are reported or found Many customers don’t really care Security researcher wants responsible disclosure (reporting after fixing) Intel agencies want bugs, but not patches Hackers (for whatever reason) disclose immediately Faster attacks But also faster fixes Security companies often prefer bugs so that their products have noticeable benefits Large companies and governments don’t like the hassle of emergency updates

18. ASSURANCE AND EVALUATION IN PLAYGROUND So, what did you do to have assurance that your node was safe? Was it enough? Did you know it was not enough at the time? If so, why did you do it? How would you do things differently now?

19. INSTRUCTOR’S PERSONAL LESSON Carefully designed automation is important One reason I got hacked was in a hurried moment, a step I was doing manually was done incorrectly Although it would have taken a little longer to set up, automating certain security-critical steps might have saved me a lot of headache When doing evaluations or determining assurance, identifying mechanisms that force security compliance is important