Security Systems

1. Security Systems

2. The Need for Secure Systems • The “good old days” • Computers were usually islands of functionality, with little, if any, interconnectivity • It didn't matter if your application was insecure - the worst you could do was attack yourself - and so long as an application performed its task successfully, most people didn't care about security. • This paradigm is evident in many of the classic best practices books published in the early 1990s.

3. The Need for Secure Systems • Times have changed • As the Internet grows in importance, applications are becoming highly interconnected. • In the Internet era, virtually all computers (servers, desktop PCs, and, more recently, cell phones, pocket-size devices, embedded systems, and other form factor devices) - are interconnected. • This creates incredible opportunities for software developers and businesses, it also means that these interconnected computers can be attacked. • Applications not designed to run in highly connected (and thus potentially harsh) environments often render computer systems susceptible to attack because the application developers simply didn't plan for the applications to be networked and accessible by malicious assailants.

4. The Need for Secure Systems • Why the World Wide Web is often referred to as the Wild Wild Web? • The Internet is a hostile environment, so you must design all code to withstand attack. • Never assume that your application will be run in only a few given environments. • Chances are good it will be used in some other, as yet undefined, setting. • Assume instead that your code will run in the most hostile of environments, and design, write, and test your code accordingly.

5. How to understand security ? • A secure product • A product that protects the confidentiality, integrity, and availability of the customers' information, and the integrity and availability of processing resources, under control of the system's owner or administrator. • A security vulnerability • A flaw in a product that makes it infeasible - even when using the product properly - to prevent an attacker from usurping privileges on the user's system, regulating its operation, compromising data on it, or assuming ungranted trust.

6. Secure Systems Are Quality Systems • Code designed and built with security as a prime feature is more robust than code written with security as an afterthought. • Secure products are also more immune to media criticism, more attractive to users, and less expensive to fix and support. • Because you cannot have quality without security, you must use tact or, in rare cases, subversion to get everyone on your team to be thinking about security.

7. Security, Applications And WWW • Usually, in a matter of days, the computer is discovered, probed, and attacked. • The point is made: attacks happen. • Two types of attackers: white-hats and script kiddies • Security from developers’ perspective • Their job is to create applications that help your users get the most from their computer systems without fear of data loss or invasion of privacy. • Failure to build systems securely leads to more work for them in the long run and a bad reputation, which in turn can lead to the loss of sales as customers switch to a competing product perceived to have better security support.

8. Security, Applications And WWW • End users perspective • They demand applications that work as advertised and the way they expect them to each time they launch them. • Hacked applications do neither. • Applications manipulate, store, and, hopefully, protect confidential user data and corporate data. • Users don't want privacy problems (credit card information posted on the Internet, medical data hacked) and don’t want to have loss of data (if have viruses). • Trustworthy computing is not a marketing gimmick. It is a serious push toward greater security within the ICT industry.

9. The Attackers • White-hats: • They are highly skilled and very clever: • They have deep computer knowledge and ample time on their hands. • They have the time and energy to probe and analyze computer applications for security vulnerabilities. • They are good guys and the best of them work closely with software vendors to discover and remedy serious security issues prior to the vendor issuing a security bulletin prompting users to take mitigating action, such as applying a software fix or changing a setting. • This approach helps prevent the Internet community from being left defenseless if the security fault is first discovered by vandals who mount widespread attacks.

10. The Attackers • Script kiddies: • They are simply foolish vandals. • They have little knowledge of security and can attack insecure systems only by using scripts written by more knowledgeable attackers who find, document, and write exploit code for the security bugs they find. • An exploit (often called a sploit) is a way of breaking into a system.

11. Why You Need a Security Culture? • Secure products are quality products • The media and your competition leap on security issues • It's horrible reading a review of your product that discusses the security weakness in the code you just wrote. • Even worse is reading about a serious security vulnerability in the code you wrote. • People shy away from products that don't work as advertised • Don't be a victim • Security vulnerabilities are expensive to fix

12. Security And Quality • Secure products are quality products • Perfect software is an oxymoron, just like perfect security. • We're talking about software secure enough and good enough for the environment in which it will operate. • A product that is not appropriately secure is inferior to competing products. • Security is a subset of reliability also • That depends on what the user means by security • A solution that protects secret data need not necessarily be reliable. • If the system crashes but does so in a manner that does not reveal the data, it can still be deemed secure.

13. Security Vulnerabilities Are Expensive to Fix • The cost of the fix coordination. Someone has to create a plan to get the fix completed. • The cost of developers finding the vulnerable code. • The cost of developers fixing the code. • The cost of testers testing the fix. • The cost of testing the setup of the fix. • The cost of creating and testing international versions. • The cost of digitally signing the fix if you support signed code, such as Authenticode. • The cost to post the fix to your Web site. • The cost of writing the supporting documentation.

14. Security Vulnerabilities Are Expensive to Fix • The cost of handling bad public relations. • Bandwidth and download costs if you pay an ISP to host fixes for you. • The cost of lost productivity. Chances are good that everyone involved in this process should be working on new code instead. Working on the fix is time lost. • The cost to your customers to apply the fix. They might need to run the fix on a nonproduction server to verify that it works as planned. Once again, the people testing and applying the fix would normally be working on something productive! • The potential cost of lost revenue, from likely clients deciding to either postpone or stop using your product.

15. Instilling Security Culture • “Security is a top priority” needs to be a corporate dictum: • The need to ship secure software is greater than ever. • Users demand that you build secure applications - they see such systems as a right, not a privilege. • Competitor's sales force will whisper to your potential customers that your code is risky and unsafe.

16. Instilling Security Culture • The best place to instilling security culture in our company is at the top, which can be hard work: • We'll need to show a bottom-line impact to your company, and security is generally considered something that “gets in the way” and costs money while offering little or no financial return. • Selling the idea of building secure products to management requires tact and sometimes requires subversion. • Two ideas: • Get the boss to send an e-mail • Nominate a security evangelist

17. Boss Sends an E-Mail • Boss sends an e-mail or memo to the appropriate team members explaining why security is a prime focus of the company. • The e-mail shall be focused and difficult to misunderstand. • Its message must be simple: security is a high priority. • Wonderful things can happen when this kind of message comes from the top. • Of course, it doesn't mean no security bugs will end up in the product.

18. Security Evangelist • These are people who understand that computer security is important for company and for clients. • These people will be the focal point for all security-related issues. • The main goals of the security evangelist or evangelists are to: • Stay abreast of security issues in the industry. • Interview people to build a competent security team. • Provide ongoing security education. • Hand out awards for the most secure code or the best fix of a security bug. • Provide security bug triaging.

19. The Defender's Dilemma • The point is made: attacks happen. • Once software is installed on a computer, especially an Internet-facing system, it is in a state of defense • This situation is incredibly problematic for all users of computer systems. • It's also challenging for software manufacturers because they produce software that is potentially a point of attack.

20. The Defender's Dilemma • Software developers are always on the back foot: • Principle #1: • The defender must defend all points; the attacker can choose the weakest point. • Principle #2: • The defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities. • Principle #3: • The defender must be constantly vigilant; the attacker can strike at will. • Principle #4: • The defender must play by the rules; the attacker can play dirty.

21. How build secure applications? • The solution has 4 part: • The design • The coding • The testing • The documentation • All of these aspects are important for delivering secure systems, and it's imperative that professionals adopt a disciplined process that incorporates these aspects. • Simply adding some “good ideas” or a handful of “best practices” and checklists to a poor development process will result in only marginally more secure products.

22. The Proactive Security Development Process • Why people choose not to build secure systems? • Security is boring. • Security is often seen as a functionality disabler, as something that gets in the way. • Security is difficult to measure. • Security is usually not the primary skill or interest of the designers and developers creating the product. • Security means not doing something exciting and new.

23. The Proactive Security Development Process • The more features included in the product, the more potential security holes in it. • Attackers use features too, and a richer feature set gives them more to work with. • New functions are inherently more risky than proven, widely used, more mature functionality, but the creativity (and productivity) of many developers is sparked by new challenges and new functions or new ways to do old functions.

24. The Role of Education • Main subjects are : • What should teach new IT specialists? • Resistance to mandatory training • Ongoing training • Advancing the science of security • Education proves the more eyes fallacy • There are two aspects to security training: • The first is to teach people about security issues so that they can look over their current product and find and fix security bugs. • However, the ultimate and by far the most important goal of security education is to teach people not to introduce security flaws into the product in the first place! • A handful of knowledgeable people is more effective than an army of fools.

25. Resistance to mandatory training • We are worried that mandatory training would have negative connotations and be poorly received. We are wrong ! • Most software development organizations are full of geeks, and geeks like learning new things. If you give a geek an opportunity to learn about a hot topic such as security, she or he will actively embrace it. • Most geeks are passionate about what they do and like to hold competitions to see who can write the fastest, tightest, and smallest code.

26. Security in Design Phase • Security questions during interviews • Define the product security goals • Security is a product feature • Making time for security • Threat modeling leads to secure design • Without threat models, you cannot build secure systems, because securing systems requires you to understand your threats. • Build end-of-life plans for insecure features • "Software never dies; it just becomes insecure." • Setting the bug bar • Security team review

27. Define the Product Security Goals • Security requirements and controls should reflect the business value of the information assets involved, and the potential business damage, which might result from a failure or absence of security. • Does this security feature or addition help mitigate any threats that concern one of our personas? • Who is the application's audience? • What does security mean to the audience? Does it differ for different members of the audience? Are the security requirements different for different customers? • Where will the application run? On the Internet? Behind a firewall? On a cell phone? • What are you attempting to protect?

28. Define the Product Security Goals • Security requirements and controls should reflect the business value of the information assets involved, and the potential business damage, which might result from a failure or absence of security. • What are the implications to the users if the objects you are protecting are compromised? • Who will manage the application? The user or a corporate IT administrator? • What are the communication needs of the product? Is the product internal to the organization or external, or both? • What security infrastructure services do the operating system and the environment already provide that you can leverage? • How does the user need to be protected from his own actions?

29. Security Is a Product Feature • Security is a feature, just like any other feature in the product. • Do not treat security as some nebulous aspect of product development. • Do not treat security as a background task, only added when it's convenient to do so. • Design security into every aspect of application. • All product functional specifications should include a section outlining the security implications of each feature.

30. Security Is a Product Feature Example: • Adding security later is wrapping security around existing features, rather than designing features with security in mind. • Adding any feature, including security, as an afterthought is expensive. • Adding security might change the way you've implemented features. This too can be expensive. • Adding security might change the application interface, which might break the code that has come to rely on the current interface.

31. Security Is a Product Feature • You have to be realistic and pragmatic when determining which bugs to fix and which not to fix prior to shipping. • In the perfect world, all issues, including security issues, would be fixed before you release the product to customers. • In the real world, it's not that simple. • Security is one part, albeit a very important part, of the trade-offs that go into the design and development of an application. • Many other criteria must be evaluated when deciding how to remedy a flaw. • Other issues include, but are not limited to, regression impact, accessibility to people with disabilities, deployment issues, globalization, performance, stability and reliability, scalability, backward compatibility, and supportability.

32. Security Is a Product Feature • You can never ship flawless software, unless you want to charge millions of dollars for your product. • If you shipped flawless software, it would take you so long to develop the software that it would probably be outdated before it hit the shelves. • However, the software you ship should be software that does what you programmed it to do and only that. This doesn't mean that the software suffers no failures; it means that it exhibits no behavior that could render the system open to attack.

33. Security Is a Product Feature • You must fix bugs that make sense to fix. • Some ones you can fix in the current version, but some ones you might fix it in the next version so that you could give your clients notice of the impending change. • You must set your tolerance for defects early in the process. • Set your expectations high and your defect tolerance low. • You cannot know all future threats ahead of time, so you must follow certain best practices • Reducing your attack surface will reduce the number of bugs that can lead to serious security issues • You cannot ship perfect software, but you can easily raise the bug bar dramatically with some process improvements .

34. Security in Development Phase • Be hardcore about who can check in new code • Security peer review of new code • Define secure coding guidelines • Review old defects • External security review • Security push • Be mindful of your bug counts • Keep track of bug metrics

35. Security Push • The goals of these security pushes included the following: • Raise the security awareness of everyone on the team. • Find and fix issues in the code and, in some instances, the design of the product. • Get rid of some bad habits. • Build a critical mass of security people across the team. • The best practices • Perform threat modeling first. • Keep the information flowing. • Set up a core security team that meets each day to go over bugs and issues and that looks for patterns of vulnerability. • The same team should have a mailing list or some sort of electronic discussion mechanism to allow all team members to ask security questions. • Present prizes for best bugs, most bugs found, and so on.

36. Security in Test Phase • Security testing is so important. • Like all other team members pursuing secure development, testers must be taught how attackers operate and they must learn the same security techniques as developers. • Testing is often incorrectly seen as a way of “testing in” security. • The role of security testing is to verify that the system design and code can withstand attack. • Determining that features work as advertised is still a critically important part of the process, but a secure product exhibits no other “features” that could lead to security vulnerabilities. • A good security tester looks for and exploits these extra capabilities.

37. Security in Maintenance Phases • How do you know when you're done? • You are done when you have no known security vulnerabilities that compromise the security goals determined during the design phase. • As you get closer to shipping, it becomes harder to fix issues of any kind without compromising the schedule. • If you find a serious security issue, you might have to reset the schedule to accommodate the issue. • Consider adding a list of known security issues in a readme file, but keep in mind that people often do not read readme files.

38. Security in Maintenance Phases • Response process • It's a simple fact that security flaws will be found in your code after you ship. • You'll discover some flaws internally, and external entities will discover others. • Once you find a flaw, you should put it through a standard triage mechanism during which you determine what the flaw's severity is, how best to fix the flaw, and how to ship the fix to customers. • If you do not look for related issues, you'll not only have more to fix when the other issues are found but also be doing a disservice to your customers. • Do the right thing and fix all the related issues, not just the singleton bug.

39. SD3 • Secure by Design • If a system is secure by design, it means you have taken appropriate steps to make sure the overall design of the product is sound from the outset. • Secure by Default • The goal of secure by default is to ship a product that is secure enough out of the box. • Secure in Deployment • Secure in deployment means the system is maintainable once your users install the product.

40. Secure by Design • The steps: • Assign a “go-to person” for your security issues. • This is the person who signs off on the product being secure. • Require training for all personnel. • Make sure threat models are in place by the time the design phase is complete. • Adhere to design and coding guidelines. • Fix all bugs that deviate from the guidelines as soon as possible. • If the code has a flaw, it is flawed, regardless of the code's age: attackers do not care if the code is old or new.

41. Secure by Design • The steps: • Make sure the guidelines evolve. • Security threats are not static; you should update the guidelines documents as you learn new vulnerabilities and learn new best practices for mitigating them. • Develop regression tests for all previously fixed vulnerabilities. • This is an example of learning from past mistakes. • Simplify the code, and simplify your security model. • Perform penetration analysis before you ship.

42. Secure by Default • Do not install all features and capabilities by default. • Apply only those features used by most of your users, and provide an easy mechanism to enable other features. • Allow least privilege in your application; • Don't require your code be used by members of the local or domain administrators group when it does not require such elevated capabilities. • Apply appropriate protection for resources. • Sensitive data and critical resources should be protected from attack.

43. Secure in Deployment • Make sure the application offers a way to administer its security functionality. • This includes the ability to know what level of patching the system is at. • Create good quality security patches as soon as feasible. • If a security vulnerability is found in your code, you must turn around the fix as soon as possible—but not too fast. • Provide information to the user so that she can understand how to use the system in a secure manner. • This could be through online help, documentation, or cues on-screen.

44. Security Principles • Security is a discipline that every software designer, developer, and tester has to know about. • Security is not something that can be isolated in a certain area of the code. • It is similar to performance, scalability, manageability, and code readability • If you keep the design security principles sacrosanct and employ a sound development process, you can indeed build secure systems.

45. The Design Security Principles • Learn from mistakes • Minimize your attack surface • Use defense in depth • Use least privilege • Employ secure defaults • Remember that backward compatibility will always give you grief • Assume external systems are insecure

46. The Design Security Principles • Plan on failure • Fail to a secure mode • Remember that security features != secure features • Never depend on security through obscurity alone • Don't mix code and data • Fix security issues correctly • Numerous other words of wisdom could be included.

47. Learn from Mistakes • In the world of security many people do not learn from mistakes readily. • Approach every bug as a learning opportunity. • Unfortunately, in the rush to get products to market, development teams tend to overlook this important step, and so we see the same security blunders occur repeatedly. • Failure to learn from a mistake increases the probability that you will make the same costly mistake again.

48. Learn from Mistakes • Ask questions like these: • How did the security error occur? • Is the same error replicated in other areas of the code? • How could we have prevented this error from occurring? • How do we make sure this kind of error does not happen in the future? • Do we need to update education or analysis tools?

49. Learn from Mistakes • A postmortem phase for security bugs fixed • The process starts by filling out a document, which our group analyzes to determine what can be learned. • The document includes the following fields: • Product name • Product version • Contact person/people • Bug database numbers • Description of vulnerability • Implication of the vulnerability • Whether the issue exists in the default installation of the product • What could designers, developers, or testers have done to prevent this flaw? • Fix details, including code diffs, if appropriate

50. Minimize Your Attack Surface • When you install more code and listen on more network-based protocols, you quickly realize that attackers have more potential points of entry. • It's important that you keep these points of entry to a minimum and allow your users to enable functionality as they need it.