Creating Secure Software Sebastian Lopienski CERN Deputy Computer Security Officer

1. Creating Secure Software Sebastian Lopienski CERN Deputy Computer Security Officer Openlab/summer student lectures 2013

2. Is this OK? intset_non_root_uid(unsigned intuid) { // making sure that uid is not 0 == root if (uid == 0) { return 1; } setuid(uid); return 0; }

3. Outline • Some recent cyber-security stories • What is computer security • How much security • Threat modeling and risk assessment • Protection, detection, reaction • Security through obscurity? • Social engineering

4. We are living in dangerous times

5. Everything can get hacked

6. What is (computer) security? • Security is enforcing a policy that describes rules for accessing resources* • resource is data, devices, the system itself (i.e. its availability) • Security is a system property, not a feature • Security is part of reliability * Building Secure Software J. Viega, G. McGraw

7. Safety vs. security • Safety is about protecting from accidental risks • road safety • air travel safety • Security is about mitigating risks of dangers caused by intentional, malicious actions • homeland security • airport and aircraft security • information and computer security

8. Security needs / objectives Elements of common understanding of security: • confidentiality (risk of disclosure) • integrity (data altered  data worthless) • availability (service is available as desired and designed) Also: • authentication (who is the person, server, software etc.) • authorization (what is that person allowed to do) • privacy (controlling one’s personal information) • anonymity (remaining unidentified to others) • non-repudiation (user can’t deny having taken an action) • audit (having traces of actions in separate systems/places)

9. Why security is difficult to achieve? • A system is as secure as its weakest element • like in a chain • Defender needs to protect against all possible attacks(currently known, and those yet to be discovered) • Attacker chooses the time, place, method

10. Why security is difficult to achieve? • Security in computer systems – even harder: • great complexity • dependency on the Operating System, File System, network, physical access etc. • Software/system security is difficult to measure • function a() is 30% more secure than function b() ? • there are no security metrics • How to test security? • Deadline pressure • Clients don’t demand security • … and can’t sue a vendor

11. Things to avoid Security measures that get disabled with time, when new features are installed Security is a process

12. Software vs. Civil Engineering Millennia vs. decades • Civil Engineering started with first civilizations • Software Engineering is a very young domain • Secure Software Engineering is in its infancy! Software engineers have to foresee the future • skyscraper has to withstand predictable weather conditions • software has to survive any attack/malicious conditions Software systems are very fragile • remove few bricks from a building, it will be fine • remove few lines of code from OS kernel, it will break

13. Is security an issue for you? • A software engineer? System administrator? User? • HEP laboratories are (more) at danger: • known organizations = a tempting target for attackers, vandals etc. • large clusters with high bandwidth – a good place to launch further attacks • risks are big and serious: we control accelerators with software; collect, filter and analyze experimental data etc. • the potential damage could cost a lot • The answer is: YES • so, where to start?

14. Threat Modeling and Risk Assessment • Threat modeling: what threats will the system face? • what could go wrong? • how could the system be attacked and by whom? • Risk assessment: how much to worry about them? • calculate or estimate potential loss and its likelihood • risk management – reduce both probability and consequences of a security breach risk = probability * impact impact probability

15. Threat Modeling and Risk Assessment • Secure against what and from whom? • who will be using the application? • what does the user (and the admin) care about? • where will the application run?(on a local system as Administrator/root? An intranet application? As a web service available to the public? On a mobile phone?) • what are you trying to protect and against whom? • Steps to take • Evaluate threats, risks and consequences • Address the threats and mitigate the risks

16. Things to avoid Security solutions that do not cover the whole exposure area

17. How to get secure? • Protection, detection, reaction • Know your enemy: types of attacks, typical tricks, commonly exploited vulnerabilities • Attackers don’t create security holes and vulnerabilities • they exploit existing ones • Software security: • Two main sources of software security holes: architectural flaws and implementation bugs • Think about security in all phases of software development • Follow standard software development procedures

18. Protection, detection, reaction An ounce of prevention is worth a pound of cure • better to protect that to recover Detection is necessary because total prevention is impossible to achieve Without some kind of reaction, detection is useless • like a burglar alarm that no-one listens and responds to

19. Protection, detection, reaction • Each and every of the three elements is very important • Security solutions focus too often on prevention only • (Network/Host) Intrusion Detection Systems – tools for detecting network and system level attacks • For some threats, detection (and therefore reaction) is not possible, so strong protection is crucial • example: eavesdropping on Internet transmission

20. Things to avoid Incomplete protection measures that become “temporary” forever

21. How much security? • Total security is unachievable • A trade-off: more security often means • higher cost • less convenience / productivity / functionality • Security measures should be as invisible as possible • cannot irritate users or slow down the software (too much) • example: forcing a password change everyday • users will find a workaround, or just stop using it • Choose security level relevant to your needs

22. Is a particular security measure good? (Questions proposed by Bruce Schneier) • What problem does it solve? • whether it really solves the problem you have • How well does it solve the problem? • will it work as expected? • What new problems does it add? • it adds some for sure • What are the economic and social costs? • cost of implementation, lost functionality or productivity • Given the above, is it worth the costs? More at http://www.schneier.com/crypto-gram-0204.html#1

23. Security measures

24. Security through obscurity … ? • Security through obscurity – hiding design or implementation details to gain security: • keeping secret not the key, but the encryption algorithm, • hiding a DB server under a name different from “db”, etc. • The idea doesn’t work • it’s difficult to keep secrets (e.g. source code gets stolen) • if security of a system depends on one secret, then, once it’s no longer a secret, the whole system is compromised • secret algorithms, protocols etc. will not get reviewed flaws won’t be spotted and fixed  less security • Systems should be secure by design, not by obfuscation • Security AND obscurity

25. Cryptography • Cryptography is a great security tool • …but it cannot solve many security problems • e.g. buffer overflows bugs, users choosing bad passwords • Don’t invent or implement cryptographic algorithms • Protect private keys • Use longer keys (e.g. RSA 4096 rather than 1024) • Avoid weak algorithms (e.g. SHA2 rather than SHA1,MD5) • Use hash functions for simple signing textsignature = sha1(secret+text)

26. Further reading Bruce Schneier Secrets and Lies: Digital Security in a Networked World

27. Human – the weakest link Fun addition to the SANS Top 20 Vulnerabilities list: H1. HumansH1.1 Description: The species Homo sapiens supports a wide range of intellectual capabilities such as speech, emotion, rational thinking etc. Many of these components are enabled by default - though to differing degrees of success. […] Vulnerabilities in these components are the most common avenues for exploitation. The human brain is both locally and remotely exploitable through techniques such as unhealthy self-talk, low self-esteem, government propaganda, commercial marketing, sales representatives, phishing, social engineering, and magic tricks. For most of these vulnerabilities, exploit code is publicly available. Attacks exploiting these vulnerabilities have been seen in the wild. […] (full text at http://rwanner.blogspot.com/2005/11/human-side-of-security.html)

28. Social engineering threats • Exploiting human nature: tendency to trust, fear etc. • Human is the weakest element of most security systems • Goal: to gain unauthorized access to systems or information • Deceiving, manipulating, influencing people, abusing their trust so that they do something they wouldn’t normally do • Most common: phishing, hoaxes, fake URLs and web sites • Also: cheating over a phone, gaining physical access • example: requesting e-mail password change by calling technical support (pretending to be an angry boss) • Often using (semi-)public information to gain more knowledge: • employees’ names, who’s on a leave, what’s the hierarchy, projects • people get easily persuaded to give out more information • everyone knows valuable pieces of information, not only the management

29. Social engineering – reducing risks • Clear, understandable security policies and procedures • Education, training, awareness raising • Who to trust? Who not to trust? How to distinguish? • Not all non-secret information should be public • Software shouldn’t let people do stupid things: • Warn when necessary, but not more often • Avoid ambiguity • Don’t expect users to take right security decisions • Think as user, see how people use your software • Software engineers think different than users • Request an external audit?

30. Social engineering – rouge URLs Which links point to eBay? • secure-ebay.com • www.ebay.com\cgi-bin\login?ds=1%204324@%31%32%34.%3 • 1%33%36%2e%31%30%2e%32%30%33/p?uh3f223d • www.ebaỵ.com/ws/eBayISAPI.dll?SignIn • scgi.ebay.com/ws/eBayISAPI.dll?RegisterEnterInfo&siteid=0&co_partnerid=2&usage=0&ru=http%3A%2F%2Fwww.ebay.com&rafId=0&encRafId=default • …

31. Social engineering – a positive aspect (Dec 2005) A child pornographer turned himself in to the police after receiving a virus e-mail saying “An investigation is underway…” Unfortunately, that’s the only happy-end story about social engineering that I know of.

32. Further reading Kevin D. Mitnick The Art of Deception: Controlling the Human Element of Security

33. From leifpeng.com Being paranoid • It is not that bad to be paranoid (sometimes) • example: the idea of SETI virus (“Alien radio signals could pose a security risk, and should be ‘decontaminated’ before being analyzed”)http://home.fnal.gov/~carrigan/SETI/SETI_Hacker.htm OK, maybe this is too paranoid…

34. Messages • Security is a process, not a product * • threat modeling, risk assessment, security policies, security measures etc. • Protection, detection, reaction • Security thru obscurity will not work • Threats (and solutions) are not only technical • social engineering * B. Schneier

35. Security in Different Phases of Software Development

36. Outline • Requirements • System architecture • Code design • Implementation • Deployment • Testing

37. Software is vulnerable Secunia security advisories from a single day

38. When to start? • Security should be foreseen as part of the system from the very beginning, not added as a layer at the end • the latter solution produces insecure code (tricky patches instead of neat solutions) • it may limit functionality • and will cost much more • You can’t add security in version 2.0

39. Software development life-cycle This isn’t new… requirements The message is:security is an issue in each phase! design implementation testing Hopefully it is obvious as well  deployment maintenance

40. Requirements Results of threat modeling and risk assessment: • what data and what resources should be protected • against what • and from whom should appear in system requirements.

41. Architecture • Modularity: divide program into semi-independent parts • small, well-defined interfaces to each module/function • Isolation: each part should work correctly even if others fail (return wrong results, send requests with invalid arguments) • Defense in depth: build multiple layers of defense • Simplicity (complex => insecure) • Define and respect chain of trust • Think globally about the whole system

42. Things to avoid Situations that can turn very wrong very quickly

43. Multiple layers of defense XIII century XXI century

44. System calls in Apache Complexity

45. System calls in IIS Complexity

46. Design – (some) golden rules • Make security-sensitive parts of your code small • Least privilege principle • program should run on the least privileged account possible • same for accessing databases, files etc. • revoke a privilege when it is not needed anymore • Choose safe defaults • Deny by default • Limit resource consumption • Fail gracefully and securely • Question again your assumptions, decisions etc.

47. Deny by default def isAllowed(user): allowed = true try: if (!listedInFile(user, "admins.xml")): allowed = false except IOError: allowed = false except: pass return allowed def isAllowed(user): allowed = false try: if (listedInFile(user, "admins.xml")): allowed = true except: pass return allowed No! What if XMLError is thrown instead? Yes

48. Further reading Ross AndersonSecurity Engineering: A Guide to Building Dependable Distributed Systems (the book is freely available at http://www.cl.cam.ac.uk/~rja14/book.html)

49. Implementation • Bugs appear in code, because to err is human • Some bugs can become vulnerabilities • Attackers might discover an exploit for a vulnerability What to do? • Read and follow guidelines for your programming language and software type • Think of security implications • Reuse trusted code (libraries, modules etc.) • Write good-quality, readable and maintainable code(bad code won’t ever be secure)

50. Things to avoid Procedures or docs that are impossible to follow;code impossible to maintain