Security in Software issues in software.ppt
- 1. Security Ross Anderson Computer Science Tripos part 2 Cambridge University
- 2. Aims • Give you a thorough understanding of information security technology – Policy (what should be protected) – Mechanisms (cryptography, electrical engineering, …) – Attacks (malicious code, protocol failure …) – Assurance – how do we know when we’re done? • How do we make this into a proper engineering discipline?
- 3. Objectives By the end of the course, you should be able to tackle an information protection problem by drawing up a threat model, formulating a security policy, and designing specific protection mechanisms to implement the policy.
- 4. Outline • At least four guest lectures – Nov 4: Steven Murdoch, anonymity – Nov 9: Robert Watson, concurrency – Nov 20: Sergei Skorobogatov, physical security – Nov 23: Joe Bonneau, social networks • Two competitive class exercises – Nov 9: Black hat, Robert Watson – TBA: White hat, Steven Murdoch
- 5. Resources • My book “Security Engineering” – developed from lecture notes • Web page for course • Menezes, van Oorschot and Vanstone “Handbook of Applied Cryptography” (reference) • Stinson: “Cryptography: theory and practice” • Schneier “Applied cryptography” • Gollmann: “Computer Security”
- 6. Resources (2) • History: – David Kahn “The Codebreakers” – Gordon Welchmann “The Hut Six Story” • Specialist: – Biham and Shamir “Differential Cryptanalysis” – Koblitz “Course in number theory and cryptography” • Lab: – Security seminars, typically Tuesdays, 4.15 – Security group meetings, Fridays, 4
- 7. What is Security Engineering? Security engineering is about building systems to remain dependable in the face of malice, error and mischance. As a discipline, it focuses on the tools, processes and methods needed to design, implement and test complete systems, and to adapt existing systems as their environment evolves.
- 8. Design Hierarchy • What are we trying to do? • How? • With what? Policy Protocols … Hardware, crypto, …
- 9. Security vs Dependability • Dependability = reliability + security • Reliability and security are often strongly correlated in practice • But malice is different from error! – Reliability: “Bob will be able to read this file” – Security: “The Chinese Government won’t be able to read this file” • Proving a negative can be much harder …
- 10. Methodology 101 • Sometimes you do a top-down development. In that case you need to get the security spec right in the early stages of the project • More often it’s iterative. Then the problem is that the security requirements get detached • In the safety-critical systems world there are methodologies for maintaining the safety case • In security engineering, the big problem is often maintaining the security requirements, especially as the system – and the environment – evolve
- 11. Clarifying terminology • A system can be: – a product or component (PC, smartcard,…) – some products plus O/S, comms and infrastructure – the above plus applications – the above plus internal staff – the above plus customers / external users • Common failing: policy drawn too narrowly
- 12. Clarifying terminology (2) • A subject is a physical person • A person can also be a legal person (firm) • A principal can be – a person – equipment (PC, smartcard) – a role (the officer of the watch) – a complex role (Alice or Bob, Bob deputising for Alice) • The level of precision is variable – sometimes you need to distinguish ‘Bob’s smartcard representing Bob who’s standing in for Alice’ from ‘Bob using Alice’s card in her absence’. Sometimes you don’t
- 13. Clarifying terminology (3) • Secrecy is a technical term – mechanisms limiting the number of principals who can access information • Privacy means control of your own secrets • Confidentiality is an obligation to protect someone else’s secrets • Thus your medical privacy is protected by your doctors’ obligation of confidentiality
- 14. Clarifying terminology (4) • Anonymity is about restricting access to metadata. It has various flavours, from not being able to identify subjects to not being able to link their actions • An object’s integrity lies in its not having been altered since the last authorised modification • Authenticity has two common meanings – – an object has integrity plus freshness – you’re speaking to the right principal
- 15. Clarifying Terminology (5) • Trust is the hard one! It has several meanings: 1. a warm fuzzy feeling 2. a trusted system or component is one that can break my security policy 3. a trusted system is one I can insure 4. a trusted system won’t get me fired when it breaks • I’m going to use the NSA definition – number 2 above – by default. E.g. an NSA man selling key material to the Chinese is trusted but not trustworthy (assuming his action unauthorised)
- 16. Clarifying Terminology (6) • A security policy is a succinct statement of protection goals – typically less than a page of normal language • A protection profile is a detailed statement of protection goals – typically dozens of pages of semi-formal language • A security target is a detailed statement of protection goals applied to a particular system – and may be hundreds of pages of specification for both functionality and testing
- 17. What often passes as ‘Policy’ 1. This policy is approved by Management. 2. All staff shall obey this security policy. 3. Data shall be available only to those with a ‘need-to-know’. 4. All breaches of this policy shall be reported at once to Security. What’s wrong with this?
- 18. Policy Example – MLS • Multilevel Secure (MLS) systems are widely used in government • Basic idea: a clerk with ‘Secret’ clearance can read documents at ‘Confidential’ and ‘Secret’ but not at ‘Top Secret’ • 60s/70s: problems with early mainframes • First security policy to be worked out in detail following Anderson report (1973) for USAF which recommended keeping security policy and enforcement simple
- 19. Levels of Information • Levels include: – Top Secret: compromise could cost many lives or do exceptionally grave damage to operations. E.g. intelligence sources and methods – Secret: compromise could threaten life directly. E.g. weapon system performance – Confidential: compromise could damage operations – Restricted: compromise might embarrass? • Resources have classifications, people (principals) have clearances. Information flows upwards only
- 21. Formalising the Policy • Initial attempt – WWMCCS – had rule that no process could read a resource at a higher level. Not enough! • Bell-LaPadula (1973): – simple security policy: no read up – *-policy: no write down • With these, one can prove theorems etc. • Ideal: minimise the Trusted Computing Base (set of hardware, software and procedures that can break the security policy) in a reference monitor