Security Realities in the Age of E-Commerce Bruce Schneier

1. Security Realities in the Age of E-CommerceBruce Schneier Counterpane Internet Security, Inc.3031 Tisch Way, San Jose, CA 95128Phone: (408) 556-2401; Fax: (408) 556-0889schneier@counterpane.comhttp://www.counterpane.com

2. Introduction

3. Digital Security • Security is an enabling technology of the Internet. • Privacy, authentication, integrity, fairness. • Security turns the Internet into a serious tool for both business and personal uses. • The limits of security are the limits of the Internet. • Security has been failing us, again and again, faster and faster. • Why is this so? • Can anything be done about it?

4. Limitations of Cryptography • Cryptography is about mathematics; security is about people. • Most security problems cannot be solved with cryptography: • Denial-of-service attacks. • CGI attacks against Web servers. • Viruses like Melissa. • Some attacks against DNS servers.

5. Cryptography has the property that the defender has an enormous advantage over the attacker. Computer security is more balanced.

6. Problems in Security Products • Bad cryptography: algorithms and protocols. • Bad programming: overflow bugs, CGI scripting errors. • Bad installation: misconfigured firewalls, routers, etc. • Bad users: poor password choices, social engineering. • Bad products: don’t solve the correct problem, don’t scale, etc.

7. It’s Not Just Security Software • On today’s networks, everything has the potential to compromise security. • A Web-based feedback form can compromise your Web server. • Melissa proved that your word processor can compromise your security. • In Windows NT, a rogue printer driver can compromise your security. • In Windows 2000, any program running on your computer can compromise your security.

8. The Future of Products…. • It doesn’t looks good: • Defensive technologies are getting better, but so are attack technologies. • Migration to digital media means that we are depending more on technology. • More people using products means fewer intelligent users. • The future of products is complexity, and complexity is the worst enemy of security.

9. Why Are Complex Products Insecure?

10. Six Reasons 1. More security bugs 2. Modularity 3. Interconnectedness 4. Difficulty of understanding 5. Difficulty of analysis 6. Difficulty of testing

11. 1. Software Security Bugs • Faulty code has been with us since the beginning. • Faulty code has resulted in some spectacular disasters: • Ariene 5 rocket. • NASA Mars missions. • Good software needs to withstand random programming bugs: • Programming Murphy’s computer.

12. Programming Satan’s Computer • Security engineering is different from any other type of engineering. • Most products are useful for what they do. • Security products are useful precisely because of what they do not allow to be done. • Most engineering involves making things work. • Security engineering involves figuring out how to make things not work…and then preventing those failures.

13. Comparison to Safety Engineering • Safety engineering involves making sure things do not fail in the presence of random faults. • Security engineering involves making sure things do not fail in the presence of an intelligent and malicious adversary who forces faults at precisely the wrong time and in precisely the wrong way.

14. Using Errors to Attack Systems • Buffer overflows (e.g. fingerd and Morris Worm). • CGI scripting errors, cross-site scripting, etc. • Bad random number generators weaken cryptographic keys. • Java, JavaScript.

15. Increased Complexity Means Increased Errors • Estimates are between 5 and 15 errors per 1000 lines of code. • More complexity  more code  more errors. • More errors  more security vulnerabilities.

16. 2. Modularity of Modern Software • Old paradigm: large applications on top of small operating system. • New paradigm: • Applications with components, plug-ins, dynamic linked libraries. • Operating systems with components, plug-ins, libraries, modules.

17. Security Problems with Modularity • You can’t assume all the modules are trustworthy. • You can’t assume the modules will work securely in your configuration. • You can’t rely on the operating system to mediate security between modules. • Java sandbox and ActiveX security paradigms have holes.

18. 3. Interconnectedness of Modern Systems • As systems get connected, a security flaw in one can affect the others. • MS Word is now a networked program. • Java applets. • PostScript files can have viruses. • Maintenance ports on routers, printers, etc. • Windows NT has a C2 security rating, but only if it is not connected to a network.

19. Security Implications of Interconnectedness • Using a home computer as an Internet server. • Game machines. • Putting small devices on the Internet. • Reusing protocols for new services. • Connecting phones and palmtops and laptops and computers and servers....

20. Runaway Effects of Interconnectedness • Modern systems are non-linear. • Modern systems are tightly coupled. • We don’t fully understand the interconnectedness of most corporate networks, let alone the Internet.

21. 4 and 5. Understanding and Analysis • Complex systems are harder to understand: • Lack of understanding makes social engineering attacks more dangerous. • Complex systems are harder to analyze: • The threat model. • The protection mechanisms. • The overall design. • Every part of the system is relevant to understanding and analysis.

22. 6. Impracticability of Security Testing • Security is orthogonal to functionality. • Just because a security products functions properly does not mean that it’s secure. • No amount of beta testing can ever uncover a security flaw. • Experienced security testing is required to discover security flaws.

23. The Failure of Testing Security • Imagine a vendor shipping a product without any functional testing. • No in-house testing. • No beta testing. • Just make sure it compiles and then ship it. • A product like this will have hundreds of bugs; the odds of it working properly are negligible. • Now imagine a vendor shipping a security product without any security testing. • The odds of it being secure are negligible.

24. Complexity Makes Security Testing Harder • Imagine a system with ten different settings, each with two possible choices: • 1024 different combinations altogether. • Imagine a system with 20 different settings, each with two possible choices: • One million different combinations. • 30 different settings = • a billion different combinations.

25. Products are Getting More Complex

26. Size of Operating Systems • Windows 3.1 (1992) 3 million lines of code • Windows NT (1992) 4 million l.o.c. • Windows 95 (1995) 15 million l.o.c. • Windows NT 4.0 (1996) 16.5 million l.o.c. • Windows 98 (1998) 18 million l.o.c. • Windows 2000 (2000) 35–50 million l.o.c. • Windows XP (2001) >45 million l.o.c.

27. Number of System Calls in Operating Systems • UNIX 1ed (1971) 33 • UNIX 2ed (1979) 47 • SunOS 4.1 (1989) 171 • 4.3 BSD Net 2 (1991) 136 • Sun OS 4.5 (1992) 219 • HP UX 9.05 (1994) 163 • Linux 1.2 (1996) 211 • Sun OS 5.6 (1997) 190 • Linux 2.0 (1998) 229 • Windows NT 4.0 SP3 (1999) 3433

28. Certificate Complexity • X.509 Version 1 20 lines ASN.1 • X.509 Version 3 600 lines ASN.1 • SET 3000 lines ASN.1

29. Complexity is Creeping into Everything • Sun’s “Home Gateway”. • Video game machines. • The Internet. • Network security devices (firewalls).

30. There are Two Alternatives.... 1. Slow down, simplify, add security. • “FDA” approval for Internet devices and services. • Reverse trend toward convergence. • Limit usefulness of Internet. 2. Embrace the insecurity of products. • Accept that security vulnerabilities are inevitable. • Put processes in place to deal with those vulnerabilities. • “Risk management” and not “threat avoidance.”

31. Security Processes

32. The Need for Security Processes • If the products will not provide adequate security, we need to develop processes to bridge the gap. • We need to recognize that no product serves as “magic security dust.” • Security is a process, not a product.

33. Preventive Countermeasures • Computer security is sold as a preventive technology: • Firewalls prevent unauthorized network access. • Encryption prevents eavesdropping. • PKI prevents impersonations. • This model doesn’t work in the real world: • Door locks. • Safes.

34. Prevention, Detection, and Response • When you install a preventive countermeasure, you are buying two things: • A barrier to overcome. • The time it takes to overcome that barrier. • Without detection and response, the preventive countermeasure is only of limited value.

35. Prevention • Against some attacks, no detection or response is possible. • For example, eavesdropping. • In those circumstances, prevention needs to be perfect. • For example, cryptography.

36. Limitations of Prevention • Most of the time, though, prevention is not perfect. • Most of the time, detection and response is more effective, and more cost-effective.

37. Detect Attacks • It’s a myth that we prevent crime in this society. • Detection is the first step toward catching the bad guys. • Real-time detection is the best; it makes recovery a lot easier.

38. Respond to Attacks • Detection without response is useless. • Response is dependent on circumstance. • Immediate response: make the attacker go away. • Longer-term response: prosecute.

39. Be Vigilant • Detection/response only works 24x7. • Notice you never see: “Please restrict all hacking attempts to between the hours of 9:00 AM and 5:00 PM, Pacific Time, Monday through Friday.”

40. Watch the Watchers • Detection/response should be administered in layers. • Security personnel are in an ideal position to commit crimes. • Internal audit watches the processes; external audit watches the internal audit.

41. Counterattack • It’s easier to catch criminals than it is to secure everything. • A benign environment tacitly accepts that attacks are normal.

42. Insure • Security risks need to be managed: • Reduce • Accept • Insure

43. Outsource • Vigilance, • Aggregation of expertise. • Economies of scale. • Large network visibility. • Security is complex, important, and distasteful.

44. Conclusions

45. Will We Ever Learn • Buffer overflows were first identified in the 1960s. • They were first used to attack networked computers in the 1970s. • The Morris Worm used buffer overflows to attack the Internet in 1989. • Today, buffer overflows are the most common way to attack systems. • Two-thirds of all CERT advisories are about buffer overflows.

46. Will We Ever Learn, Part II • There’s a particular bug in Microsoft Internet Information Server. • It was fixed in July 1998. • Another warning was published by Microsoft in July 1999. • In January 2000, the bug was exploited to steal credit card numbers from several Web sites.

47. The Limits of Perception • The problem with bad security is that it looks just like good security. • Almost all security products on the market today are insecure. • Processes are the only way to survive in today’s interconnected world.

48. The Limits of Requirements • Adequate security today is better than perfect security tomorrow (i.e., never). • Security doesn’t have to be perfect; but the risks have to be manageable. • Most systems permit some level of fraud. • “A secure computer is one that has been insured.”

49. The Limits of Technology • Security technologies are tools. They are essential for a secure system, but they do not automatically make a system secure. • The social problems are much harder than the technology. • If you think technologies can solve your security problems, then you don’t understand your security problems and you don’t understand the technologies.