Audit, Security Evaluation , Information Assurance

1. Audit, Security Evaluation,Information Assurance Nicolas T. Courtois - University College London

2. Audit Nicolas T. Courtois, December 2009

3. Audit Major source of jobs Audit – several different types: • Quality audits… • In project management: advancement audits, • In accounting: Audit checks the accounts • and compliance to certain rules such as nobody is claiming 200 % of his time, • Internal Audit: • compliance to the internal rules of an organization, • External Audit: • an authority checks compliance to laws, and regulations, Nicolas T. Courtois, December 2009

4. IT and Audit In IT: Certified Information Systems Auditor (CISA) – scope is the whole of IT, not only security… In Information Security: Audit = analysis of past events in order to see if the security breaches have occurred or have been attempted. Offline, after the facts… About security. Nicolas T. Courtois, December 2009

5. Residual Risk = def what remains after defences are in place… Nicolas T. Courtois, December 2009

6. Audit is Needed because of this residual risk. Things are going to happen. Sometimes it is a part of the whole system of defenses. Certain security violations will be detected ONLY at a much later time. That’s all right if we can • trace the culprit, • cancel certain transactions, • revoke certain keys, • etc… Nicolas T. Courtois, December 2009

7. Audit Logs Example: In access control we do record: • subject requesting • object of the request • operation requested • time and date • location / IP address of the request • status of the request: • granted / denied, • physical resources used (like CPU time)... Nicolas T. Courtois, December 2009

8. Why Not More? Choices are specific to each application. If memory is critical, it is very important to log only the minimum, example: in bank cards. Otherwise nowadays space if getting cheaper and cheaper… But even then • legal or contractual obligations • (e.g. credit card merchants are NOT allowed to store the CVC) • or privacy-friendly design considerations • “proportionality principles” will prevent us from logging too much information… Nicolas T. Courtois, December 2009

9. Intrusion Detection Nicolas T. Courtois, December 2009

10. Intrusion Detection Audit: • usually offline, after the facts Intrusion detection: • usually active, real time, online. • otherwise we speak about “passive intrusion detection”… Nicolas T. Courtois, December 2009

11. Types of Intrusion Detection • Threshold-based • Anomaly-based, • Rule-based, • State transition-based, Nicolas T. Courtois, December 2009

12. Most Basic Intrusion Detection Notion of “security events” Nicolas T. Courtois, December 2009

13. Very Basic Example Alarms Nicolas T. Courtois, December 2009

14. Types of Intrusion Detection • Threshold-based = detect abnormal use. Examples: • try 4 different PINs in an ATM, • the card will stop working forever • high CPU load, a lot of data sent out… Cons: false positives. (for other methods too…) Nicolas T. Courtois, December 2009

15. Types of Intrusion Detection (2) • Anomaly-based: Defines profiles: what is the normal behavior in terms of • key security events • CPU/memory usage by a user • their timing • How to Measure the deviation? • Each profile will define acceptable intervals, otherwise an alarm will be raised. • Example: an employee of the bank is expected to do between 10 and 40 credit history checks per day in office, with time intervals of at least 10 minutes. • Can also use the time series model: • events occurring in circumstances where the historical probability is VERY low (say a credit check during the lunch break in a big French bank) will raise an alert. Nicolas T. Courtois, December 2009

16. Key Latency Control • Powerful mechanism to detect anomalies in behavior of employees and to detect malware. Nicolas T. Courtois, December 2009

17. Types of Intrusion Detection (2,3) • Anomaly-based • Doesn’t require a lot of technical knowledge, • it is just doing stats on apples and bananas… • Rule-based, can be based on: • past experience of intrusions / breaches • Known system vulnerabilities / attacks Cons: require a lot of expert knowledge… Nicolas T. Courtois, December 2009

18. Rule Based - Example Information Flow Control • Can be applied where BLP model is applicable. • the key point is that maybe we don’t need to enforce a very strict policy, just create administrative alerts when it is violated.. Nicolas T. Courtois, December 2009

19. Types of Intrusion Detection (4) • State transition-based:Require a sort of “security model” where: • Each state is characterized by assertions evaluating whether certain conditions are verified in the system. • For example, check if a user has the right privileges for a given object. Nicolas T. Courtois, December 2009

20. Integrity Control • Can be applied where Biba model with a dynamically changing levels, for example one of the low watermark policies is applicable. • it will be a state transition based intrusion detection mechanism. Nicolas T. Courtois, December 2009

21. Information Assurance Nicolas T. Courtois, December 2009

22. Security  Safety intentional damages... Nicolas T. Courtois, December 2009

23. Scope 4 Today Both: Safety and Security! Nicolas T. Courtois, December 2009

24. Who to Trust ? • pejorative: “Commercial security”; works if you believe it. Imagine a banker who wants to buy a product which is “secure”. How can he know it is secure? Security usually cannot be seen… Only the opposite is visible… Nicolas T. Courtois, December 2009

25. What Makes That a Product is Safe? • Inherent to the technology: • trains and lifts are inherently MUCH safer than cars… • bad news: computers + networks are by nature a security nightmare… • Market regulation: • example: make an airbag a legal obligation. • no legal obligations for computers yet… • “nobody is in charge”… Nicolas T. Courtois, December 2009

26. Open Source vs. Closed Source Can be much easier to attack! will many people looking at source code will find the bugs? • bugs are VERY HARD to find, • people rarely get paid for that… much less hours spent… • security problems can be a result of a combination of: • code+compiler (e.g. buffer overflow) • code+hardware (side channel attacks on crypto) • good programmers + poor security background (prevalent) Nicolas T. Courtois, December 2009

27. Boeing vs. Airbus Airbus: [factories wide open to visitors] 60 recorded crashes for 12 million flights. Boeing: [their factories are closed, security!] 194 crashed for 35 million flights. Almost the same rate: 1 crash out of 0.2 M flights. Beware of statistical manipulation: how many crashes per mile? Per hour of flight? Deaths per hour*passenger? Etc… Cars vs. planes: similar rate of 1.5 death / 100 million miles traveled… Nicolas T. Courtois, December 2009

28. **Which Model is Better? Open and closed security are as more or less equivalent, more or less as secure: • opening the system helps both the attackers and the defenders. Ross Anderson: Open and Closed Systems are Equivalent (that is, in an ideal world). In Perspectives on Free and Open Source Software, MIT Press 2005, pp. 127-142. Nicolas T. Courtois, December 2009

29. Airlines: What they Do “High Assurance” industry, obsessed with safety since ever… What is Assurance? • Building confidence that systems meet the security criteria, based on application of “assurance” techniques: • design methodology • expert design analysis • assessment/testing • Estimate the likelihood that bad things will happen… Nicolas T. Courtois, December 2009

30. Aviation vs. Computer Software vs. have just changed, new threats… fast: ship it now, get it right for next release… should work 99% of the time upgrades: not done, bad users… failures: tolerated goals: mostly clear from the start slow speed: carefully designed, 10 years time to market, high quality testing: exhaustive tests maintenance: scheduled, certified technicians, pilots need a licence failures: EVERYTHING done to prevent ever happening again… + separation of duty Nicolas T. Courtois, December 2009

31. Aviation: Possibly an example to follow? Maybe? Maybe not? Not clear. Assurance: Key ideas: • design a trusted engineering process: • classical “industrial” view: engineer the whole process of design+implem.+testing • even more modern version: create the right incentives for private business to solve all the problems for you… • codify best practices, • train engineers [e.g. at university] • train users of systems… Nicolas T. Courtois, December 2009

32. Following the Idea.. What is Information Assurance? The Same. • Building confidence that systems meet the security criteria, based on application of “assurance” techniques: • design methodology • expert design analysis • assessment/testing • Estimate the likelihood that bad things will happen… Nicolas T. Courtois, December 2009

33. Evidence-based Assurance Sullivan: there should be sufficient credible evidence that the system meets the requirements… Nicolas T. Courtois, December 2009

34. Ross Anderson: “Fundamentally, assurance comes down to the question of whether capable, motivated people have beat up on the system enough. • But how do you define enough? • And how do you define the system? • How do you deal with people who protect the wrong thing, … out of date or plain wrong? … • allow for human failures?” Nicolas T. Courtois, December 2009

35. Failures Nicolas T. Courtois, December 2009

36. Attacks Target attacker vulnerabilities threat potential attack scenario attack system target • defences • controls • countermeasures expectations, goals properties security policy=what is allowed/not (protection goals) if there is one Nicolas T. Courtois, December 2009

37. Security Failures vulnerability • defences: • controls • countermeasures + attacker threat potential attack scenario security target:a more detailed specification of a set of means/protections to achieve the goals and a yardstick to evaluate if designers / implementers did a good job ActualAttack scenario security policy: what is allowed/not, protection goals protection profile: what needs to be protected … allowing comparison of very different products famous for omissions Nicolas T. Courtois, December 2009

38. Types of Failures [Sullivan] • Failure in design • omissions/mistakes in the spec • bad engineering /faulty design • Failure in implementation • hardware/software • Failure in operation • operator errors • willful misuse • random failures • hardware or comm/network malfunction • natural causes: “Acts of God” • failure in upgrade / maintenance Design Assurance Implementation Assurance Operational Assurance Nicolas T. Courtois, December 2009

39. Design Assurance requirements should determine the security policy, or security model == the space of possible security policies Nicolas T. Courtois, December 2009

40. Policy Assurance Evidence that the set of security requirements is: • Complete: • Every situation is either “safe” or “unsafe”. • Ambitious. Are we sure we need this one? • Consistent: • Free of (formal) contradiction... We want it! • Technically Sound: • The policy captures what we wanted, • not like to Biba policy where all subjects are downgraded immediately, and everybody is secure by name… but not in meaningful way. Nicolas T. Courtois, December 2009

41. Design Assurance Show that the policy requirements will be met… Nicolas T. Courtois, December 2009

42. Implementation Assurance Considerations • implemented correctly • Using tools and best practices used to avoid introducing extra implementation vulnerabilities (e.g. side channels, backdoors, etc…) • testing • proof of correctness? Hard. • document the product well! Nicolas T. Courtois, December 2009

43. Operational Assurance • system should sustain the security policy requirements during • installation/configuration, • day-to-day operation • usability testing is needed to • upgrades/maintenance Nicolas T. Courtois, December 2009

44. Following the Idea.. What is Information Assurance? It is also basically a method to “argument”. • can I convince myself it is secure? Nicolas T. Courtois, December 2009

45. Forwards and Backwards Nicolas T. Courtois, December 2009

46. ***Life Cycle Assurance • Conception • focus on policy and requirements • Building • select mechanisms to enforce policies • give evidence that are appropriate • Deployment • provide mechanisms for delivery that assures integrity, • initial setup and key management • appropriate configuration • Fielded Product Life • update and patch mechanism • customer support • product decommissioning and end of life Nicolas T. Courtois, December 2009

47. Orange Book, CC Nicolas T. Courtois, December 2009

48. History: 1983-1999 • Orange Book = Trusted Computer System Evaluation Criteria = TCSEC • designed for OS mostly… emphasis on confidentiality… 1998-present • Common Criteria = ITSEC = ISO 15408 • designed for “everything” Both deeply rooted in the military circles… DoD, NSA, GCHQ, etc… Both give a single linear scale – right answer: Nicolas T. Courtois, December 2009

49. Orange Book DC Division D: Minimal Protection Division C: Discretionary Protection C1 - DAC, Identification and Authentication, protected from external tampering, … C2 – Controls access to objects, object reuse, has auditing, more security testing Nicolas T. Courtois, December 2009

50. Orange Book B Division B: Mandatory Protection B1 - labeled security, MAC for named objects, informal security policy B2 - structured protection: consistent formal security policy/model; MAC for all objects, labeling; trusted path; least privilege; covert channel analysis, admin tools, configuration management, pen-tested B3 - structured design, security domains, full reference monitor, increases trusted path requirements, constrains code development, real-time monitoring, good documentation, Nicolas T. Courtois, December 2009