Security Engineering

1. Security Engineering Security Computer Science Tripos part 2 Ross Anderson

2. Chosen protocol attack The Mafia demands you sign a random challenge to prove your age for porn sites!

4. Building a Crypto Library is Hard! • Sound defaults: AES GCM for encryption, SHA256 for hashing, PKC with long enough keys • Defend against power analysis fault analysis, timing analysis (cache attacks on AES), and other side-channel attacks. This is nontrivial! • Take great care with key management and interface design • Don’t let keys be reused for more than one purpose (‘leverage’ considered harmful) • My strong advice: do not build a crypto library! If you must, you need specialist (PhD-level) help • But whose can you trust?

5. How Certification Fails • PEDs ‘evaluated under the Common Criteria’ were trivial to tap • GCHQ wouldn’t defend the brand • APACS said (Feb 08) it wasn’t a problem • It sure is now…

6. Cryptographic Engineering 19c • Auguste Kerckhoffs’ six principles, 1883 • The system should be hard to break in practice • It should not be compromised when the opponent learns the method – security must reside in the choice of key • The key should be easy to remember & change • Ciphertext should be transmissible by telegraph • A single person should be able to operate it • The system should not impose mental strain • Many breaches since, such as Tannenberg (1914)

7. What else goes wrong • See ‘Why cryptosystems fail’, my website (1993): • Random errors • Shoulder surfing • Insiders • Protocol stuff, like encryption replacement • Second big wave now (see current papers): • ATM skimmers • Tampered PIN entry devices • Yes cards and other protocol stuff • Watch this space!

8. Security Engineering • No different in essence from any other branch of system engineering • Understand the problem (threat model) • Choose/design a security policy • Build, test and if need be iterate • Failure modes: • Solve wrong problem / adopt wrong policy • Poor technical work • Inability to deal with evolving systems • Inability to deal with conflict over goals

9. A Framework Policy Incentives Mechanism Assurance

10. Economics and Security • Since 2000, we have started to apply economic analysis to IT security and dependability • It often explains failure better! • Electronic banking: UK banks were less liable for fraud, so ended up suffering more internal fraud and more errors • Distributed denial of service: viruses now don’t attack the infected machine so much as using it to attack others • Why is Microsoft software so insecure, despite market dominance?

11. Example – Facebook • From Joe’s guest lecture – clear conflict of interest • Facebook wants to sell user data • Users want feeling of intimacy, small group, social control • Complex access controls – 60+ settings on 7 pages • Privacy almost never salient (deliberately!) • Over 90% of users never change defaults • This lets Facebook blame the customer when things go wrong

12. New Uses of Infosec • Xerox started using authentication in ink cartridges to tie them to the printer – and its competitors soon followed • Carmakers make ‘chipping’ harder, and plan to authenticate major components • DRM: Apple grabs control of music download, MS accused of making a play to control distribution of HD video content

13. IT Economics (1) • The first distinguishing characteristic of many IT product and service markets is network effects • Metcalfe’s law – the value of a network is the square of the number of users • Real networks – phones, fax, email • Virtual networks – PC architecture versus MAC, or Symbian versus WinCE • Network effects tend to lead to dominant firm markets where the winner takes all

14. IT Economics (2) • Second common feature of IT product and service markets is high fixed costs and low marginal costs • Competition can drive down prices to marginal cost of production • This can make it hard to recover capital investment, unless stopped by patent, brand, compatibility … • These effects can also lead to dominant-firm market structures

15. IT Economics (3) • Third common feature of IT markets is that switching from one product or service to another is expensive • E.g. switching from Windows to Linux means retraining staff, rewriting apps • Shapiro-Varian theorem: the net present value of a software company is the total switching costs • So major effort goes into managing switching costs – once you have $3000 worth of songs on a $300 iPod, you’re locked into iPods

16. IT Economics and Security • High fixed/low marginal costs, network effects and switching costs all tend to lead to dominant-firm markets with big first-mover advantage • So time-to-market is critical • Microsoft philosophy of ‘we’ll ship it Tuesday and get it right by version 3’ is not perverse behaviour by Bill Gates but quite rational • Whichever company had won in the PC OS business would have done the same

17. IT Economics and Security (2) • When building a network monopoly, you must appeal to vendors of complementary products • That’s application software developers in the case of PC versus Apple, or of Symbian versus Palm, or of Facebook versus Myspace • Lack of security in earlier versions of Windows made it easier to develop applications • So did the choice of security technologies that dump costs on the user (SSL, not SET) • Once you’ve a monopoly, lock it all down!

18. Why are so many security products ineffective? • Recall from 1b Akerlof’s Nobel-prizewinning paper, ‘The Market for Lemons’ • Suppose a town has 100 used cars for sale: 50 good ones worth $2000 and 50 lemons worth $1000 • What is the equilibrium price of used cars? • If $1500, no good cars will be offered for sale … • Started the study of asymmetric information • Security products are often a ‘lemons market’

19. Products worse then useless • Adverse selection and moral hazard matter (why do Volvo drivers have more accidents?) • Application to trust: Ben Edelman, ‘Adverse selection on online trust certifications’ (WEIS 06) • Websites with a TRUSTe certification are more than twice as likely to be malicious • The top Google ad is about twice as likely as the top free search result to be malicious (other search engines worse …) • Conclusion: ‘Don’t click on ads’

20. Conflict theory • Does the defence of a country or a system depend on the least effort, on the best effort, or on the sum of efforts? • The last is optimal; the first is really awful • Software is a mix: it depends on the worst effort of the least careful programmer, the best effort of the security architect, and the sum of efforts of the testers • Moral: hire fewer better programmers, more testers, top architects

21. Open versus Closed? • Are open-source systems more dependable? It’s easier for the attackers to find vulnerabilities, but also easier for the defenders to find and fix them • Theorem: openness helps both equally if bugs are random and standard dependability model assumptions apply • Statistics: bugs are correlated in a number of real systems (‘Milk or Wine?’) • Trade-off: the gains from this, versus the risks to systems whose owners don’t patch

22. Security metrics • Insurance markets – can be dysfunctional because of correlated risk • Vulnerability markets – in theory can elicit information about cost of attack • In practice: iDefense, Tipping Point, … • Stock markets – can elicit information about costs of compromise. Stock prices drop a few percent after a breach disclosure • Econometrics of wickedness: count the spam, phish, bad websites, … and figure out better responses. E.g. do you filter spam or arrest spammers?

23. How Much to Spend? • How much should the average company spend on information security? • Governments, vendors say: much much more than at present • But they’ve been saying this for 20 years! • Measurements of security return-on-investment suggest about 20% p.a. overall • So the total expenditure may be about right. Are there any better metrics?

24. Skewed Incentives • Why do large companies spend too much on security and small companies too little? • Research shows an adverse selection effect • Corporate security managers tend to be risk-averse people, often from accounting / finance • More risk-loving people may become sales or engineering staff, or small-firm entrepreneurs • There’s also due-diligence, government regulation, and insurance to think of

25. Skewed Incentives (2) • If you are DirNSA and have a nice new hack on XP and Vista, do you tell Bill? • Tell – protect 300m Americans • Don’t tell – be able to hack 400m Europeans, 1000m Chinese,… • If the Chinese hack US systems, they keep quiet. If you hack their systems, you can brag about it to the President • So offence can be favoured over defence

26. Privacy • Most people say they value privacy, but act otherwise. Most privacy ventures failed • Why is there this privacy gap? • Odlyzko – technology makes price discrimination both easier and more attractive • We discussed relevant research in behavioural economics including • Acquisti – people care about privacy when buying clothes, but not cameras (phone viruses worse for image than PC viruses?) • Loewenstein - privacy salience. Do stable privacy preferences even exist at all?

27. Security and Policy • Our ENISA report, ‘Security Economics and the Single Market’, has 15 recommendations: • Security breach disclosure law • EU-wide data on financial fraud • Data on which ISPs host malware • Takedown penalties and putback rights • Networked devices to be secure by default • … • See link from my web page

28. The Research Agenda • The online world and the physical world are merging, and this will cause major dislocation for many years • Security economics gives us some of the tools we need to understand what’s going on • Security psychology is also vital • The research agenda isn’t just about designing better crypto protocols; it’s about understanding dependability in complex socio-technical systems

29. More … • See www.ross-anderson.com for a survey article, our ENISA report, and my security economics resource page • WEIS – Workshop on Economics and Information Security – in Harvard, July 2010 • Workshop on Security and Human Behaviour – in Cambridge in June 2010 • ‘Security Engineering – A Guide to Building Dependable Distributed Systems’