On The Driving Seat of Secure Development1Fundamental Practices and tools to implement a security development lifecycleOn The Driving Seat of Secure DevelopmentCassio GoldschmidtSr. Manager, Product Security*** Notes about the presentation for the organization and translators ***1 ) All Need speakers connected to my computer2) I wont be reading the notes verbatim but Ill try to keep the story as close to them as possible. Read the notes ahead of time to and understand where the story is heading.3) Text in angle brackets () represent my comments. Those are there to help the translators. Same with the parenthesis.4) Bold text represents text terms that are required to know.

*** INTRO ***

Security has been a concern for a very long time in many areas of our lives. One area most of us are very familiar is the security in our roads. There is so much we, security practitioners, can learn from it, yet no one made a meaningful parallel between the history of automotive security and software security. In this presentation Ill attempt to do one while educating everyone on some of the fundamental practices of security development. Due to the time allocated for this presentation, this will be an abridged and somewhat loosely based version of the original Fundamental Practices presentation I co-authored with SAFECode for the paper with the same name.

1

Do You Drive Better than the Average Driver?Yes2NoXWhy Accidents Happen?On The Driving Seat of Secure Development2My information research on automotive security started with friends and family with a simple question: Do you drive better than the average driver?. Anyone who understands a bit of statistics knows the expected result for this questions should be 50% of the population answering yes and the other 50% answering no assuming an unbiased sample of the population. While I fully acknowledge the fact I only worked with friends and most of them were male, my research resulted on 100% of the answers being yes, I drive better than the average driver. Clearly something was incorrect. Likewise, I never heard any developer say he or she write code that is more insecure than the average application that is on the internet. This is true even if the developer never had any security education.So lets take a minute to review what means to be an average driver.2

Every Two MilesThe Average Driver Makes...On The Driving Seat of Secure Development3400 Observations40 Decisions1 Error

Every two miles (approximately 3.21 km) , the average driver makes400 observations40 decisionsAnd 1 error. Examples of errors are:- Failing to look at the mirror before changing lanes- Answering phone calls and texting while drivingFailing to stop completely at a stop signBut errors can get worse3

Every 500 MilesOne of Those Decisions...On The Driving Seat of Secure Development4Results on a Near Collision

Every 500 miles (aprox 804.6 km), one of those decision results on a near collision, also known as a close call in aviation. This is when someone almost get into an accident but luckily escapes.

4Every 61,000 milesOne of those Mistakes Leads to a...On The Driving Seat of Secure Development5

Acidente

Finally, every 61,000 miles (aprox 98,169 km) one of those mistakes results in an5

On The Driving Seat of Secure Development6

CRASH!

Accident In the beginning of last century, car accident and fatalities were almost synonymous. At that time telling someone that a relative was a victim of a car accident on the road was very close to telling today that a relative was involved on a plane accident. While there is a chance of the person may have survived, the chances were very slim and not much hope was left. 6

On The Driving Seat of Secure Development7CRASH!Following the same pattern, computer crashes in the past were often and common and meant at the very minimum that all unsaved work was lost. Personal computers were not ready for the new types of threats of the information age when they were first connected to the internet. Crashes often meant buffer overflow which would present an opportunity for an attacker to take complete control of a machine. 7Analyzing The ProblemOn The Driving Seat of Secure Development8Developers

User8Whenever society is faced with a problem a ritual of self assurance takes place. We disect the event, analyze it and try to find an explanation so that we can rest assured this wont happen again. While analyzing car crashes in the first part of last century, several things were taken into consideration such as whether the car was functioning properly and the road conditions were adequate. The analysis could not find any reasonable flaw on those items and concluded the cause of most accidents was poor education. The culprint was dirver.

Likewise, in technology the culprint of computer crashes and hacks was the the interface between the chair and keyboard, meaning the user and the developer! They had to be educated on secure coding and security awarness to properly operate a machine.

Driving is not a right but a privilege granted to the qualified citizen who is capable of driving responsibly. The solution to the problem was to raise the bar of driving tests making it a lot harder for everyone to get a drivers license. In England the test is so hard people send greeting cards for friends who study and pass the test. Crashes in computer systems at the time also raised the questions of whether professional developers shouldnt be certified too!

Raising the Bar on EducationDriving: A Privileged not a RightOn The Driving Seat of Secure Development9

Driving is not a right but a privilege granted to the qualified citizen who is capable of driving responsibly. The solution to the problem was to raise the bar of driving tests making it a lot harder for everyone to get a drivers license. In England the test is so hard people send greeting cards for friends who study and pass the test. Crashes in computer systems at the time also raised the questions of whether professional developers shouldnt be certified too!

9Resolving the Problem with EducationOn The Driving Seat of Secure Development10

End of the 90s until mid 2000: golden area of virus - Educate the user, - Use AV - Dont open email2001: CISSP2001: OWASP was founded2002: Bill Gates Email to the entire company about secure coding (Writting secure code became a mandatory reading at Microsoft)2007: Mary Ann Davidson wrote a letter to all major US universities urging them to teach about computer security.

10 - Common Weakness Enumeration

11

CWE Top 25Every security practitioner will agree education is a vital part of a successful security initiative. Fortunately there are a number of great tools out there to help you jumpstart your initiative. In the next few slides Ill talk about some of my favorite tools, starting with education.

The 2011 CWE/SANS Top 25 Most Dangerous Software Errors is a list of the most widespread and critical errors that can lead to serious vulnerabilities in software. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all. The Top 25 list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped. Software customers can use the same list to help them to ask for more secure software.

The 2010 CWE Top 25 has become practically a crash course or "crash resource" in secure programming.

1112EducationOWASP Tools - WebGoat

12WebGoat is a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application. For example, in one of the lessons the user must use SQL injection to steal fake credit card numbers. The application is a realistic teaching environment, providing users with hints and code to further explain the lesson.

EducationOWASP tools - LiveCD

13The OWASP Live CD is a bootable CD that contains tons of must have tools for anyone performing penetration test. OWASP Live CD provides the best, freely distributable application security tools in an easy to use package. All tools are configured and, when applicable, integrated wit other tools such as web browsers. This is a great tool to use in classes as it avoids all the time to setup and provides the entire class with an identical environment without requiring to install software on their machines. In addition, OWASP Live CD is a great tool to use whenever you want to test a tool without installing in your machine.

13

SAFECode Publications14

I highly recommend reading SAFECodes paper Fundamental Practices for Secure Software Development. This paper provides provide a foundational set of secure development practices that have been effective in improving software security in real-world implementations by SAFECode members across their diverse development environments. It is important to note that these are the practiced practices employed by SAFECode members, which we identified through an ongoing analysis of our members individual software security efforts. Wherever possible, SAFECode has included methods and tools that can be used to verify whether a practice was applied. This characteristic makes this paper distinct from other publications such as the Microsoft SDL book.

Framework for Software Supply Chain IntegrityFirst industry-driven framework for analyzing and describing the efforts of software suppliers to mitigate the potential that software could be intentionally compromised during its sourcing, development or distribution.

Security Engineering TrainingA Framework for Corporate Training Programs on the Principles of Secure Software Development

Software Assurance: An Overview of Current Industry Best Practices The report outlines the secure development methods and integrity controls currently used by SAFECode members to deliver high-assurance systems to government and commercial customers. (executive summary)

14What is SAFECode.org?15SAFECodes Mission

Increase trust in information and communications technology products and services through the advancement of proven software assurance methods.

ABOUT SAFECode

The Software Assurance Forum for Excellence in Code (SAFECode) is a non-profit organization exclusively dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods. SAFECode is a global, industry-led effort to identify and promote best practices for developing and delivering more secure and reliable software, hardware and services. Its members include Adobe Systems Incorporated, EMC Corporation, Juniper Networks, Inc., Microsoft Corp., Nokia, SAP AG and Symantec Corp.15On The Driving Seat of Secure Development16

CRASH!Raising the bar on education surely had positive results and the number of car accidents declined over time. Unfortunately further analysis showed that the percentage of fatal accidents remained the same. In other words, the solution only helped to partially address the problem. Car accidents continued to be synonymous of fatality.16Eye on the Ball!Focus TestOn The Driving Seat of Secure Development17How Many Times Does the White Team Pass the Ball?Video created by Daniel Simons, a professor of psychology at HarvardMuch like software development, driving is a complex activity that require a lot of attention. Id like to take a minute now and perform a attention test with you. The following video will show two team playing with two balls. Id like you to focus on the team wearing the white shirt and tell me how many times the team passes the ball.

Ready? Ill start the video now

So, how many times the team passed the ball? 14, 15, 16 times? Okay, now how many of you saw a GORILLA crossing the court?

Ill pass the video a second time

When developers have to worry about writing functional, maintainable, high performance code delivered on time and oh, dont forget to make it secure too! This is what happens! Developers may be aware of the problem but even when people are aware of a problem they still make mistakes.

17To Err is HumanOn The Driving Seat of Secure Development18

The fact is that humans are error prone. Pleople will make mistakes no matter what. This is part of our nature! The car industry was worrying too much about what happened before and not enough time worrying about what happened during an accident. The fact is that the interaction between cars and humans was very unfriendly at that time!18William Haddon

On The Driving Seat of Secure Development19

1960 1970: A New Approach to Traffic SafetyMedical Doctor By trainingWouldnt eat mayonnaise afraid of contaminationTook a scientific approach to solve the problem.Concluded that driver education was not the problemThe problem was the interaction between humans and machinesIn the middle part of the last century, a man named William Haddon changed forever the way Americans think about car accidents. Haddon was, by training, a medical doctor and an epidemiologist and, by temperament, a New Englander--tall and reed-thin, with a crewcut, a starched white shirt, and a bow tie. He was exacting and cerebral, and so sensitive to criticism that it was said of him that he could be "blistered by moonbeams." He would not eat mayonnaise, or anything else subject to bacterial contamination. He hated lawyers, which was ironic, because it was lawyers who became his biggest disciples.19Human-Machine InteractionOn The Driving Seat of Secure Development20

VS.WINNER!

William noted the fundamental flaw in the human-machine interaction the society failed to noticed. At a car accident where a human chest would collide with the steering wheel , the steering wheel would survive while the bones on the persons chest would break and perforate the lungs (because the material used in the steering wheel was tougher than the chest bones). 20Human-Machine InteractionOn The Driving Seat of Secure Development21

During a frontal collision, the car engine would move inwards crashing the drivers legs. Car engineering needed to desperately change. The expected behavior in the years to come is that the engine would fall down. 21Human-Machine InteractionOn The Driving Seat of Secure Development22

A car revolution started and cars became crash friendly. Whenever a crash happened the car would to the provide all safety mechanisms available to save the persons life while absorbing the impact as much as possible even it that meant total loss of the vehicle. This slide shows some of the most well known security mechanisms in use today such as ABS, seat belts and airbags. Most of this mechanisms became standard features (requirements) in many countries such as the US.22Human-Machine InteractionOn The Driving Seat of Secure Development23

The industry evolved and top of the line vehicles have a lot more security features as you can see in this slide 23Security Mechanisms in Modern Compilers (C++)

strcpy, strcat, strlenstrncpy, strncatsprintf, wsprintf, swprintf...gets, _gettsstrtok, _tcstokmakepath, splitpathscanf, sscanf_itoa, _itowchartoOem, OEMtoCharalloca, _alloca... /GS /DYNAMICBASE /NXCOMPAT /SafeSEH /Analyze -fstack-protector -WI, -pie -D_FORTIFY_SOURCE=2Ms Visual C++ Flags and OptionsBanned Functions (banned.h)Flags no gccFollowing the same pattern the technology industry started to provide security mechanisms for developers where the code was able to defect against some types of attacks. I will not talk about security mechanisms for users but Im sure you are all well aware of tools such as phishing detection just to mention an example.

1997: StackGuard was released for GCC by Crispin Cowan (Microsoft introduces the /GS flag in Visual C++ in 2003)2003: Fortify was foundedLate 2002: Coverity was founded2000: SPI Dynamics was founded

/GS stack based buffer overrun (-fstack-protector) /DYNAMICBASE image and stack randomization (-WI, -pie) /NXCOMPAT CPU-level no-execute support (NX) support /Analyze pre-fast (-D_FORTIFY_SOURCE=2)

What about n functions? They are too hard to use correctly. (Example: strncpy and strncat lack paralelism.)

The industry also started to build software differently. Consider for example the way a developer does input validation on a web application. A terrible application does no validation, a bad application does the validation on the client side. A good application does the validation on the server and an excellent application does the validation BOTH on the client and server side AND logs the results whenever the code in the server code side is exercised because that is likely an attack attempt.

24SandboxingDefense in depthLeast privilegeEncouraged for applications that are:Installed on a large number of systems (> 1 million)Process untrusted dataParse complex dataExamples: Norton AntivirusInternet ExplorerAdobe AcrobatMicrosoft Office25

On The Driving Seat of Secure Developmentsandboxis a security mechanism for separating running programs. It is often used to execute untested code, oruntrustedprograms from unverified third-parties, suppliers and untrusted users.The sandbox typically provides a tightly-controlled set of resources for guest programs to run in, such asscratch spaceon disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted. In this sense, sandboxes are a specific example ofvirtualization.

25Static Source Code AnalysisThe spell checker of developersEveryone should use itTools that integrate with build environment leads to faster resolutionNot a replacement for code-base analysisClean run = free from some well-known and well-understood patterns Can be used with limited source code accessMay lead to false negativesGreat when new types of weaknesses are discoveredRules can do the initial triage

26On The Driving Seat of Secure DevelopmentTools that integrate with development environments are usually considered easier to use and often lead to faster bug resolution; they also help get developers used to identifying security defects as they develop code and before they checking-in.

Using static analysis tools that are integrated with development environments does not replace the need for codebase-wide analysis.

Developers may have a modified view of the current code base (e.g., on a dedicated maintenance branch) or may only be dealing with a limited set of source code (e.g., one module or application tier). Both scenarios can result in false negatives resulting from limited data flow and control flow analysis and other problems that full-codebase and/or main branch analysis (at product build time) would otherwise Find.

Ideally, static code analysis tools should be site licensed to the entire development team, including QA, making this tool as commonly used by the development team as spell checkers that are built in to modern word processors. Both experienced and inexperience developers can greatly benefit from analysis tools much like all writers take advantage of spell checkers. Because many vulnerabilities are hard to spot but simple to solve, its not unreasonable to expect most vulnerabilities to be fixed immediately after a routine scan completes.

First time static analysis tools users should expect some up-front investment to get the greatest benefit from the tools. Before running a static analysis tool for the first time, it is recommended to clean the code from compiling warnings. Still, an initial run will result in a significant list of findings. Depending on the project size, management should consider dedicating team resources to do the initial triage.

First time static analysis tools users should expect some up-front investment to get the greatest benefit from the tools. Before running a static analysis tool for the first time, it is recommended to clean the code from compiling warnings. Still, an initial run will result in a significant list of findings. Depending on the project size, management should consider dedicating team resources to do the initial triage.

Maintaining a dedicated team of security-savvy developers to review static analysis results may be helpful for resource-constrained Maintaining a dedicated team of security-savvy developers to review static analysis results may be helpful for resource-constrained.

Development teams often create a separate build system with static analysis tools running continuously. This practice minimizes the impact on the time it takes to generate a new build.

Several static code analysis tools are capable of generating results even if the codebase is incomplete or does not compile.

Its also important to understand that static code analysis tools are a complement to manual code review, not a substitute. A clean run does not guarantee the code is perfect. It merely indicates the code is free of well-known and well-understood patterns.

Its also important to understand that static code analysis tools are a complement to manual code review, not a substitute. A clean run does not guarantee the code is perfect. It merely indicates the code is free of well-known and well-understood patterns.

Regardless of the tool and the type of technology employed, no one tool today finds all faults. In fact, all SAFECode companies employ multiple tools throughout the development lifecycle. Furthermore, neither static nor dynamic analysis can recognize sophisticated attack patterns or business logic flaws, so they should not be considered a replacement for code reviews. While tools can reliably identify vulnerability types, automated severity metrics cannot be taken for granted as they dont factor business risk such as asset value, cost of down time, potential for law suits and impact of brand reputation.

26Static Source Code AnalysisTipsFirst time usersClear all warnings firstExpect a significant list of findingsConsider creating a team to clean the codeDisassemble the clean up team afterUse of multiple tools is recommendedContinuous buildTrack findings?Change in rules = change in metrics = complains from dev teams

27On The Driving Seat of Secure DevelopmentMaintaining a dedicated team of security-savvy developers to review static analysis results may be helpful for resource-constrained Maintaining a dedicated team of security-savvy developers to review static analysis results may be helpful for resource-constrained.

Development teams often create a separate build system with static analysis tools running continuously. This practice minimizes the impact on the time it takes to generate a new build.

Several static code analysis tools are capable of generating results even if the codebase is incomplete or does not compile.

Its also important to understand that static code analysis tools are a complement to manual code review, not a substitute. A clean run does not guarantee the code is perfect. It merely indicates the code is free of well-known and well-understood patterns.

Regardless of the tool and the type of technology employed, no one tool today finds all faults. In fact, all SAFECode companies employ multiple tools throughout the development lifecycle. Furthermore, neither static nor dynamic analysis can recognize sophisticated attack patterns or business logic flaws, so they should not be considered a replacement for code reviews. While tools can reliably identify vulnerability types, automated severity metrics cannot be taken for granted as they dont factor business risk such as asset value, cost of down time, potential for law suits and impact of brand reputation.

27

28Traffic AnalysisBurp Suite28On The Driving Seat of Secure DevelopmentSpeaking of tools that can help you find vulnerabilities, Burp is a free tool I really like. This tool is a web proxy and can be used to analyze the traffic from a web browser and the web server. In this screenshot the tool is analyzing the traffic of a SSL site, which is a very handy feature.

Secure Driving is a ProcessOn The Driving Seat of Secure Development29

Most of the technology industry today think tools is the end of the story and not much more is needed to develop secure code. Truth to be told, security is a process and it starts way before any code is written.

Take the example of drivers in our roads. Even if an individual was trained and has a car that is crash friendly there are a lot more questions that need to be asked. For example, how is the tire pressure? Are the car lights working? How are the road conditions? Is there a storm out there? Is the driver sober or under the influence or emotionally impacted by an event?

29Secure Development is a ProcessPLANNINGDEVTESTSUPPORTCONCEPT30

Security is built in the development lifecycle and not an afterthought.

There are corresponding security practices for each activity in the software development lifecycle that can improve software security and are applicable across diverse environments

30One Slide SummaryPLANNINGDEVTESTSUPPORTCONCEPT31

TrainingAwareness ProgramsThreat ModelingToolsCode ReviewsTools for Security TestPenetration TestVulnerability Management3rd party component alertsThreat modeling: Defining a set of possible attacks to consider. Vulnerability Management: the process of resolving security vulnerabilities quickly and carefully. This team is responsible for managing the entire Security Advisory process.31The Entire Supply Chain Needs to Be SecureOn The Driving Seat of Secure Development32Even if a sound SDL process is followed there are a lot more things that an organization should worry about. In fact, only doing what I presented so far will results on a supply chain where there is a padlock in the development phase and a shoelace in other parts that could be equally damaging if vulnerable. For example, while we took care of the development process and the technology in use, little has been said about the people factor. Who develops software and matters and who works in an organization matters too. 32Open Source Use Must be ControledOn The Driving Seat of Secure DevelopmentToday its impossible to develop software alone. We all rely on code developed by third party, the people who develop application libraries (or APIs) or the compiler we use of the database and webserver. Open source is used by a number of development shops without worrying about who is behind the initiative, how much these people care about security and how often the open source components are updated in the project. Leaving old open source components with known vulnerabilities in a project drastically lowers the bar for attackers who want to exploit a system.33Third Party Components and Cloud ComputingOrganizations must certify contractually that a secure development process has been followed. Vendors-R-Us.ComPen Testers(External)Clouds-R-Us.ComUsesTestsOn The Driving Seat of Secure DevelopmentSince we cannot ensure partners who develop 3rd party components are indeed following a SDL program, contracts become a requirement to enforce quality. As software complexity increases, these contracts are becoming harder to write: today software components are often developed by a company, hosted on the web by another company and tested by a 3rd company. Companies need to ensure all parts of the equation achieve the desired level of quality. 34Security Is a JourneyOn The Driving Seat of Secure Development35In conclusion, software security is not a destiny but a journey and no single activity (or even a set of activities) will guarantee the safety of an application. The goal is not to achieve an application that is unbreakable as there is no such thing but rather to raise the cost of exploiting an application to a level that is so costly that attackers will look somewhere else.35On The Driving Seat of Secure Development36Cassio Goldschmidtcassio@cassiogoldschmidt.comhttp://www.cassiogoldschmidt.comThank you!Copyright 2010 Symantec Corporation. All rights reserved.Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice.Thank you!36Links & ReferencesWrong Turn, Malcom Gladwell, The New Yorker June 11, 2001www.safecode.orgwww.owasp.orghttp://cwe.mitre.org/top25/http://portswigger.net/burp/The invisible Gorilla, Daniel J. Simons & Christopher Charbis, http://www.theinvisiblegorilla.com/videos.htmlOn The Driving Seat of Secure Development3737