Software Security - The Bigger Picture Rudolph Araujo – Principal Software Security Consultant Foundstone Professional Services, A Division of McAfee

1 Abstract Through our experience having worked with a Developers are often blamed for software number of organizations to augment their security mishaps and punished through losses in lifecycles we have wages or embarrassed on walls of shame1! At discovered how such activities can help produce Foundstone, we believe developers, for the higher quality and secure applications that most part, don't write insecure code make everyone happy especially developers intentionally or because they are negligent, who keep their reputation, jobs and hard- they do so because they haven't been taught earned pay checks! any better and don't receive adequate help and guidance from other stakeholders. Essentially, when dealing with software security, it is often 2 Introduction a common fallacy to focus all together too The security community and industry has much on the development phase of the evolved tremendously since the late 80s when software development lifecycle and not enough the first "security attack" was perpetrated in on the others. This paper therefore focuses on the form of the Morris Worm. This led to the three key support activities that could help creation of the Computer Emergency Response tremendously in improving the security of Team or CERT as it is popularly known. For the projects churned out by your development next decade or so the focus on the industry was teams: on securing the network and to a lesser extent on securing the host. As a result of this, the Security - As major security technologies of that era were the with software quality in general, the devices and software we almost take for lack of security requirements leads to granted today - the firewalls, intrusion insecure software. detection systems and virus scanners. However, Security - Quality as the Internet exploded and the World Wide assurance teams specialize in testing Web went from being an academic network of software yet rarely test for security. computers to a platform upon which business And no, we don't mean penetration was done, the threats also evolved. Now the testing! attackers began to attack not just the Knowledge Management - and the host but the applications that sat on When a security incident occurs can we top of these. In many ways these applications ensure lessons are learned across the represented the crown jewels - the confidential organization? data, the precious intellectual property and

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 1 business intelligence that organizations and this great solution and this secure indeed consumers did not want to lose. coding standard! Increasingly, organizations succeeded in getting their “ducks in a row" on the network and host side as tried and tested solutions became 3 Holistic Software Security available. However, development teams were Unfortunately it appears that as a community struggling with dealing with securing the we the software security folks have not learned application. Enter vulnerabilities such as the as much as we should have from the decades of , SQL injection, and cross site research into software engineering. If you treat scripting; the list could go on. a security vulnerability as a bug first and a security issue second, you can quickly adapt So how have we dealt with this problem over many of the lessons that have been learned the last few years? As one would expect, the with regards to improving the security of first attempt at dealing with problems was to software applications. not deal with them at all. The approach was to release software, hope for the best and then fix Software security must be viewed holistically. It issues as they were publicly reported. Next is achieved through the combination of came the phase of penetration testing a few effective people, process and technology with weeks or days before going into production. none of these three on their own capable of This again provided little time to effectively fix fully replacing the other two. This also means the issues discovered. As an industry, we that just like software quality in general, continued to evolve and the next phase was to software security requires that we focus on go hunting through code for the common security throughout the application's life cycle - classes of vulnerabilities that were in the news or from cradle to grave as some like to say. – whether this was buffer overflows in the 90s Unfortunately thus far, most of the effort has or common web application vulnerabilities focused on activities such as application more recently. The more strategic of the penetration testing, security code reviews and organizations at this point invested in software to a lesser extent on modeling. security training and building policies such as language specific coding standards to aid their While all of the aforementioned activities are developers to deal with the problem and to critical to improving the security of your prevent the introduction of vulnerabilities in the applications, they are by no means the only future. The focus from the beginning has been ones. Unfortunately, both as a community at on developers and the development phase for large and as individuals looking to tackle the the most part and only rarely touching on some software security problem in our development of the secure design elements. As a teams we have tended to ignore the non- consequence of this focus, it almost became developer focused activities. In this paper we instinctive to blame developers and hold them present three of these activities. We share the responsible for vulnerabilities in the application. experiences we have gained in effectively If something went wrong, it must have been the implementing these activities for large developer's fault - especially now that we have development teams as well as the value they

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 2 bring to improving the security of the or dictionary based guessing attacks also fall applications developed by these teams. within the realm of this category.

3.1The Foundstone Security Frame2 : The types of issues that are Before we dig into the specifics of each of the considered under this category include three activities that are the focus of this paper, those dealing with appropriate mechanisms it helps to define a common frame of reference to enforce on protected to view software security problems and resources in the system. Authorization flaws solutions. Defining such a frame has helped to could result in either horizontal or vertical both be better prepared going into a software . development project as well as to perform better root cause analysis when faced with User & Session Management: This category vulnerabilities. In the context of this paper, we is concerned with how a user’s account and will use this security frame in each of the three session is managed within the application. activities to help us be more efficient, effective The quality of session identifiers and the and thorough within each domain. mechanism for maintaining sessions are some of the considerations here. Similarly, Configuration Management: As part of this user management issues such as user category we consider all issues surrounding provisioning and de-provisioning, password the security of configuration information management and policies are also covered and deployment. For instance, any as part of this category. and / or authorization rules embedded in configuration files or how the Data Validation: This is the category framework and application deal with error responsible for the most well known bugs messages. and flaws including buffer overflows, SQL injection and cross site scripting. Length, Data Protection in Storage & Transit: The range, format and type checking for inputs nature of issues included in this category and outputs are considerations here. cover the handling of sensitive information such as social security numbers, user Error Handling & Exception Management: credentials or credit card information. It is This category is responsible for ensuring also covers the quality of cryptographic that all failure conditions such as errors and primitives being used, required / minimum exceptions are dealt with in a secure key lengths, entropy and usage vis-à-vis manner. The nature of issues covered in this industry standards and best practices. category range from detailed error messages, which lead to information Authentication: We consider here the usage disclosure, to how user friendly security of strong protocols to validate the identity error messages are. of a user or component. Further, issues such as the possibility or potential for Auditing and Logging: This category of authentication attacks such as brute-force issues is concerned with how information is logged for debugging and auditing purposes. The security of the logging This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 3

mechanism itself, the need and presence of work with are used to thinking solely about an audit trail and information disclosure functional requirements – requirements that through log files are all important aspects. the system and business analysts writing them can put their arms around. What different 3.2 Security Requirements Engineering widgets should the application have? How One of the most ignored parts of a security should it respond to the click of a button in the enhanced software development life cycle is the top right corner and so on? The non-functional security requirements engineering process. One requirements on the other hand are often of the prime reasons for this oversight is that marked as “N/A”. Our findings have been that security is assumed to be a technical issue and this is not necessarily because they are therefore best handled during architecture and considered unimportant, but because they are design or better still during implementation. assumed to be de facto requirements – “the Since software requirements are often written developers should know better than to build a by business analysts who are non-technical, this slow or insecure or unreliable system”. The is a common conclusion. assumption always seems to be that these The problem with this approach, as any requirements would be obvious and hence experienced software professional would tell don’t need to be documented. you, is that software which does not have its On examining this problem a little bit further, requirements elicited, enumerated and well we discovered that the problem to a large documented will most likely be lacking in extent was a lack of awareness and knowledge quality. This is because developers do not have of the people writing the requirements. The a specific target with regards to embodying non-functional requirements can be very security into the design and implementation. technical –consider specification of the Further, quality assurance folks have no algorithm, cipher mode, key lengths to validate the software against, and rotation parameters. Defining requirements and traceability - a key software engineering around all of those would typically require a attribute - is unachievable. In fact it is hard to detailed understanding of the mechanisms even build a good threat model without a clear around cryptography - not something that is idea of the security requirements. typically found in the job description of a This is a well understood concept in the general business analyst. field of software engineering. A lot of research3 As a solution to this issue we present a has been performed on how to effectively elicit, template driven approach which is designed validate and document software requirements. specifically to help the non-technical Further, most modern SDLC support tools stakeholder to define very technical security already provide some mechanism for requirements. While this approach does involve documenting requirements4. Hence, it should some amount of prior effort to create the not be too difficult to extend these systems and templates, we have seen it to be tremendously the process itself to include security effective in both ensuring that security requirements. The challenge however as requirements are documented (and not just mentioned above is that most organizations we with “N/A”!) and then implemented and tested.

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 4

The first step in this approach is for an to an industry such as financial services. organization or team (depending on the size This category in our classification is also and variety of applications involved) to identify setup to include standards bodies such as all the relevant drivers for security ISO and the norms they define. Examples requirements that would, could and should include: influence development. In our experience, most o often you will see a lot of commonality among ISO 17799 o FFIEC Information Technology the various applications developed within the 6 Examination Handbook organization or team and hence we attempt to o SCADA Security7 leverage that commonality and thus gain o OWASP Standards8 efficiencies across multiple projects o OASIS9

In our experience it is best to think about these Company Policies: Most organizations that drivers along the following categories. As we work with have a slew of internal mentioned above, most of these drivers will policies that should and could affect the influence many, if not all, of the applications development of an application. Among the churned out within an organization. most common ones here are: o Privacy Policies Regulatory Compliance5 – This involves o Coding Standards specific requirements that would be o Patching Policies mandated by various governmental o Data Classification Policies agencies. Depending on the legal o Policies environment within which the organization o Acceptable Use Policies operates and the application’s scope, a o Export Control number of regulations could be relevant. o Open Source Usage Some of these include:

o Sarbanes-Oxley, Section 404 Security Features: Finally, most applications o Health Insurance Portability and will have some form of security feature. For Accountability Act instance, authentication and authorization o Payment Card Industry Data Security models that replicate real world role based Standard access control. Similarly, administrative o Gramm-Leachy Bliley Act interfaces that will be used for user o SB 1386 and other State Notification Laws management including provisioning and de- o BASEL II provisioning. o Federal Information Security Management Act For some of the above axes it is best to work o EU Data Protection Directive with the legal department and internal audit to o Children's Online Privacy Protection Act arrive at the list of relevant regulations. Once o Local Key Escrow Laws that superset has been defined, the next step is to examine each of these regulations through Industry Regulations and Standards: These the eyes of both someone who speaks legalese include typically standards that are specific and a software development expert. The aim This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 5 here is to convert the list of legal requirements change very often or with each application which would guarantee compliance to a set of release. This is primarily because applications core technical requirements for software that is tend to evolve very slowly with regards to the impacted by these regulations. The Foundstone drivers mentioned above. Further, as Security Frame can come in extremely handy mentioned above there is much opportunity to here. For each of the relevant drivers from leverage commonality across applications as above consider the various categories in the well since it is not atypical for many of the security frame and how they might be applications to be operating within a similar impacted. For instance, if your organization is driver environment. regulated by Gramm-Leach-Bliley Act (GLBA), privacy of personally identifiable information Having now defined this universal set of (PII) is absolutely critical. This in turn can have requirements a priori, as each application implications across multiple Security Frame release is defined; the specific set of categories not the least of which being Data requirements for that release can be drawn out Protection in Storage & Transit. The outcome of of this set. As part of this process, the data this step should essentially be a set of specific classification and privacy policy can help to requirements along the various security frame identify which data elements handled by the categories that would satisfy each of the drivers application are impacted by the drivers. defined above. It is vital at this stage to also Additionally, it is also important to consider rationalize the various requirements obtained which features being added in this release above getting rid of overlapping or redundant would be impacted as well. Based on these requirements. pieces of input and the universal set of requirements a subset of those requirements A parallel step in this requirements process is to will be obtained that are relevant for this classify the applications as being impacted by specific release of this specific application. The the drivers. In our experience this is best done person formulating these requirements now by creating a large matrix with the various need not be an expert in security or any of the drivers above forming the columns and the security frame categories but can simply check application set forming the rows. Classification the appropriate boxes to obtain a set of then is the task of checking the appropriate requirements. In fact this last per application boxes depending on whether, based on legal step can be easily automated through a and other opinions an application is impacted template or lightweight application which by a specific driver. references all the relevant policies, the universal set of requirements, considers the As a result of the two parallel steps mentioned data elements in use and provides a set of above, the team should now have a specific set technical requirements that may leverage of technical requirements for each application encryption, access control and other security based on its driver environment. mechanisms. These can then literally be copy- All of the above effort is intended to be pasted into the master requirements list. performed once and then revisited periodically. In our experience, it is very rare that these

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 6

To wrap-up this section let us consider an tester or developer. Both traditional software illustrative example. Take for instance, an testers and security testers attempt to break online loan processing application. Such an down software, however, the former typically application will obviously make extensive use of approach this problem by attempting to look personally identifiable information and is for failures to meet a specific set of determined to be impacted by the Gramm- requirements and features. For instance, a Leachy Bliley Act driver. This in turn defines classical software tester is concerned with specific requirements around the whether the login feature works i.e. when they confidentiality, integrity, availability and access type in a valid user name and password that the to data as well as audit trails that monitor and specific user is logged on. Further, they will also report on such access. Now consider that a new test to make sure that if an incorrect username feature is being added that emails the result of and password are entered the user is not the loan decision to the customer. When a logged in. A security tester on the other is not business analyst is defining the requirements so much concerned with the login feature but around this new feature, he / she would need with getting access to the application in an to consider all of the different data elements unauthorized manner. Hence, he / she are that would be part of this email, the transport going to attempt brute forcing or SQL injection mechanism used by the email and to access the account. Similarly, he / she will be authentication around it. Based on business paying special attention to the error messages need and security, it can then be decided to displayed on a failed login. You can see a clear avoid certain data elements or perhaps use a difference in the two approaches and similar secure email solution. examples can be drawn from all of the various features of the application. Hence, the first step 3.3 Security Acceptance Testing in embodying within the usual As touched upon in the introduction to this testing phases in a software development paper, traditional security tests have focused on lifecycle is to work on developing the right penetration testing. However, in most software mindset. This is primarily an issue of training development life cycles we have a specific and exposure. Using training tools such as the quality assurance (QA) phase. Moreover, very Hacme Series10 from Foundstone, software commonly now we see unit tests and build testers can learn about the various types of verification tests in addition to the QA phase. vulnerabilities as well as the simple mechanisms Unfortunately, penetration testing is often used to test for the presence of such performed too late in the life cycle - after the vulnerabilities. entire system has been built and deployed. It would be remiss for us to not leverage these The next step is to determine the level of effort earlier testing opportunities to catch as many of security testing that should be embodied problems as early as possible. within the development cycle. Most QA folks are used to estimating testing effort based on However, incorporating security into these the number of features and methodologies is non-trivial. Part of the requirements. They do this by being intimately reason is that the typical security tester’s involved in the functional and design reviews. mindset is different from a quality assurance

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 7

Along similar lines it is important to involve In our experience the most effective manner to these stakeholders in the threat modeling build such security unit test cases is to create an process. This helps to not only identify security attack library11 with commonly used attack risks but can also help prioritize those risks patterns and then running through this library based on business impact and thus help identify enumerating attacks against the API being the list of test areas. Once this has been done, it tested. The results in turn can be compared is useful to simply integrate the relevant test against a known good value to determine if the cases into test plans that exercise those areas attack was successful. It is often best if the unit during a regular testing schedule. test cases are defined within a peer development group. Thus, one developer Testing can then be split into a number of defines the unit test cases and attack libraries phases. In our experience, different parts of the for code written by a different developer. security frame lend themselves better to some phases rather than others. Build verification testing is another area that could provide opportunities to test the security is typically performed by the of an application. A number of security testing developers themselves and is often used as the tools such as source code analyzers and web exit criteria from the development phase to a application penetration testing tools provide formal testing phase. Testers here are looking both the ability to integrate into build scripts as for both coverage and pass percentages. A well as scripting interfaces that allow their core number of frameworks have been developed to engines to be adapted to fit into existing testing help with this process and to essentially provide processes. Further, these tools also often have the infrastructure to make developers more rules engines that can be modified and efficient and effective. One such framework is extended to create custom rule sets based on provided within Visual Studio 2005. The risk and relevance. Organizations that have framework can auto-generate unit test cases successfully deployed such tools will often based on the APIs and functions exposed by define criteria for build acceptance that specify your code. This is therefore an effective place to along with other more traditional QA test data validation code. By resorting to parameters, the number and type of security -style techniques which provide random data bugs that maybe present in a build that is (“fuzz”) to the inputs of an application, exposed provided to the QA teams for rigorous testing. interfaces can be tested to observe how they react to different data elements both valid and One of the key lessons we have learned over invalid. It is possible to test here for issues such the years having worked with QA teams is that as buffer overflows, SQL injection and cross site they are very accepting of new testing scripting as well as other types of injection techniques and methodologies. However, it is attacks. Unit testing can also be useful in testing important to not cause any upheaval of the method level authorization rules wherein the actual QA process. It is therefore vital that all called method checks the authentication state security testing ultimately ties into the existing and permissions of the caller. and often times tried and testing quality practices. One critical area this becomes relevant is in the bug reporting area. We have

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 8 seen most success when security bugs prior to Finally, it is also helpful to classify security release are treated just like other software issues into four categories while entering them quality issues. This implies that firstly, all into the bug tracking system or while security issues are entered into the same bug commenting on the fix: tracking system and follow the same lifecycle. For instance, a number of organizations are Security Flaws: A security flaw is an issue used to thinking about bugs based on their that has come about due to an severity and priority. It is therefore vital to inappropriate design decision or convert the risk rating that is usually associated implementation choice. They are generally with security bugs into a severity and priority. architectural or design problems and have These can vary based on the business risk that global implications. An example of a flaw these bugs pose but as a general rule of thumb would be a user authentication system that all high risk issues can be considered to have does not adequately protect passwords in the highest severity and priority, medium risk to the data store. Moreover this class of have medium severity but high priority and all problems often stem from the fact that the low risk issues to have low severity and medium design specification was itself incomplete or priority. It is however not atypical to see didn’t address the issue specifically. Thus, it business rules that mandate all security issues is quite possible that a flaw might exist in an be treated as highest priority. Once the security application even though the developers issues have been entered into the bug tracking have implemented the design specification system they should follow the same path other completely and correctly. bugs do in being assigned to a developer, fixed, assigned back to the tester verification and Security Bugs: A security bug is a code level being closed and potentially added to problem. Often semantic in nature, they are cycles. It is however usually the result of a coding error or bad recommended to tag security bugs under a implementation of a design decision. An separate SECURITY category in order to example of a bug is a buffer overflow. These facilitate obtaining an aggregate view. Secondly issues typically tend to be language specific. this can also help to ensure that a security trained developer is assigned to work on these Commendations: A commendation is a note bugs rather than any developer. Doing this will of good security. Our experience is that this improve the chances of a correct solution free is as important to note the positive security from recurrent bugs. Further, given that most attributes as it is the negative. Positive bug tracking systems allow for their schema to enforcement encourages repetition of good be extended it is also helpful to further classify practices and can also help to highlight best security bugs based on the security frame. As practices that may have been implemented mentioned above, performing statistical unbeknownst of their security value. analysis across bugs or after a release can thus help identify root causes as well as techniques Recommendations: There are many ways of and tools to prevent such bugs from designing software. These findings list some manifesting themselves again. considerations for future revisions that

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 9

would facilitate enhanced or improved In our experience, the medium that lends itself security. This category of issues is also used best to this form of information sharing is a to convey any insight into better software software security portal. Such a portal would development practices that the application provide a number of key functions such as: developers can adopt. For instance, specific software or architecture design patterns Document repository to house all of the might be recommended. policies, methodologies, process documents, guidelines and best practices This classification like the security frame developed as part of the security enhanced classification can provide valuable results that SDLC process. help measure the effectiveness and merit of performing security testing earlier rather than Threat modeling artifact storage so that later in the lifecycle. They can also help incremental threat modeling can be easily reemphasize the need and value of activities performed after the initial effort of building such as threat modeling and peer code reviews. the first threat model. Moreover, this is especially significant since it is not 3.4 Security Knowledge Management uncommon that a number of the Of all the activities in the software development applications within an organization or group life cycle, this is probably the one that may not are architecturally similar in nature and seem very important. Unfortunately as technology and hence share a similar attack members of the security community we have all surface. Thus the threat model for one such too often seen organizations fall victim to issues application can serve as an excellent that were fixed in other parts of the building block for the others. organization - sometimes even within the same team! While this is embarrassing, it is easily a Metrics reporting to provide the symptom of the lack of effective knowledge stakeholders with measurements to justify management. Valuable lessons can be learned the return on security investment. These from the experiences and mistakes of others can include statistics from actual both within the same organization and measurements within the organization on externally. However, most development teams effectiveness of the S-SDLC process, have no way of drawing these lessons and it is improvements in productivity, decrease in therefore vital to share this information security vulnerabilities, and other data through an appropriate channel. While training points of interest. is certainly an important aspect in improving overall security consciousness among In addition, another tremendously effective tool developers, it is also important that developers is an organization wide knowledge sharing Wiki. have access to a central repository and portal Through its support for effective content for providing them with guidance on a day to management and quick refactoring, Wiki12 day basis. This is especially important in large technology is an excellent model for development organizations. collaboration between large numbers of individuals. One has to only look at the success

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 10 of wikipedia.org at building a collaborative must only be considered after the issues in online encyclopedia to understand the potential question have been fixed and tested in contained within this technology. Having been production applications. This will mitigate any in the field working with development teams it risk of the issue being exploited. Special care is quite common to observe that a number of must be taken when the vulnerability affects groups and development teams are already other applications or if it exists in a product or using Wikis within their teams to document library that maybe shared. The bottom line is design and architecture as well as lessons the risk of disclosing the vulnerability too soon learned from prior bugs and testing efforts. and before affected applications have been When this is the case extending such a Wiki to thoroughly patched must be weighed against encompass the software security drive is not the benefits to be gained by the knowledge hard. Further, there are a number of free and sharing. Secondly, for each issue it is important useful Wiki solutions available such as the very to sufficiently anonymize specific data. The aim popular MediaWiki13. behind doing this is to avoid any kind of finger pointing that could have a negative impact on A software security Wiki would be a central morale. On the other hand all such sharing must repository providing readers with a single and be performed with a positive outlook of common location where they can find learning from past mistakes rather than information covering aspects such as: focusing on the person or team that made the security architectures that are in use within mistake. Finally, it is also vital that not just the other groups issue be shared but also if possible the thoroughly reviewed and tested code mechanism used to discover that issue, the snippets for commonly used tasks design and architectural changes and thought links to additional information about process that went into fixing the issue, the fix software security on the Internet as well as, itself as well as root cause analysis covering why lessons learned from previous security the issue was introduced, why it was not caught issues identified in applications during earlier in the lifecycle and if and how the internal testing or third party reviews. software development lifecycle process and mechanisms will be tweaked to prevent such We strongly believe that by encouraging such issues from making their way undetected into sharing, development teams and organizations applications. It is off course vital to make sure can recognize tremendous gains by the wide that any code shared thus be thoroughly distribution of best practices, prevention of the reviewed and be free from security bugs and repetition of similar mistakes, improved flaws itself. productivity through code and knowledge sharing, and overall better software quality. Another aspect of knowledge sharing deals with the handling of third party components. A Especially when considering the disclosure of number of software development projects information about vulnerabilities onto such a these days leverage third party components knowledge sharing platform, some (both open source and otherwise) and ship considerations are vital. Firstly, such sharing these with their applications. Perhaps the

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 11 biggest case in point is libraries such as OpenSSL aspects such as reliability issues with the 14and zlib15. While as much as possible it is patches that may affect the decision about recommended to use existing tried and tested whether to deploy the updated components. solutions, it is also important to track updates and changes to those solutions. Because In our experience without such a mechanism it components such as these are used so often is all too common to see applications that are they are extensively tested both by the teams free from vulnerabilities themselves but are that produce them as well as by the security exposed to highly critical problems in third researcher community1617. This in turn implies party components. A knowledge management that security updates and patches are being scheme as mentioned above not only can help constantly released. If development teams are prevent this by defining the appropriate roles not tracking these updates it is quite likely that and responsibilities but can also help share that they would be distributing an old and possibly information across the development team and vulnerable version of these shared, third party organization to prevent others from falling libraries. On the other hand, the typical victim to it as well. developer may not have the wherewithal to be constantly scouring the Internet and security 4 Conclusion mailing lists to keep track of the latest security This paper has covered three of the activities vulnerabilities and patches. It is therefore vital that we believe should exist as part of a security that as a team or an organization a process be enhanced software development life cycle for it created to deal with this issue. to be successful in improving the security of

your applications. These activities are non- An effective way of doing this is to create a traditional in the sense that they do not merely listing of all the open source and shared third go after the development phase of the lifecycle. party components in use across the However in our experience, having helped a organization along with a matrix that tracks number of large organizations implement a which applications use which components. secure development lifecycle, we believe that Alongside this listing, it is also important to without getting these parts of the puzzle correct maintain a link to the mailing list maintained by your team will not achieve the best possible the vendor through which it notifies about results from any investment into software security updates and patches. All of this security. It is also important to note that we information can in fact be maintained on the cover only three such activities in this paper in software security portal and wiki mentioned order to provide them the justice they deserve. above. Beyond this however, it is important to However, they are by no means the only assign a point person to each component whose activities. A truly effective security enhanced responsibility it would be to track such mailing software development lifecycle has many parts lists for their specific component. As soon as to it and while they can be built over time, true they learn of an update they can then notify the Zen is achieved only when all the parts are in other teams using that component based on place. In getting there though, each additional the matrix described above. Further it is also important that the point person also track

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 12 part will result in a marked improvement in the domain of web service security, survivability, security quality of your applications. and reliability.

Rudolph has diverse experience in a number of areas of software development and security. He 5 About the Author has worked with both independent software Rudolph serves as a Principal Software Security vendors as well as large corporate IT Consultant and Trainer at Foundstone organizations. Because of this, he has a unique Professional Services, A Division of McAfee. perspective on the challenges of building real- Rudolph is responsible for creating and world secure applications. delivering the threat modeling, security code review and secure software engineering service 5.2 Notable Accomplishments lines. He is also responsible for content creation Rudolph is an experienced C / C++ and C#/.NET and training delivery for Foundstone's Building developer and the author of a number of Secure Software and Writing Secure Code - Foundstone's software security auditing tools ASP.NET and C++ classes. At Foundstone, including The .NET Security Toolkit, SSLDigger, Rudolph has had the opportunity to work with and Hacme Bank tools. Rudolph is also a regular some of the biggest financial institutions, contributor to MSDN's webcast series. Rudolph technology and telecom companies as well as has been honored with the Microsoft Visual with the open source community. Developer Security MVP Award in recognition of his thought leadership and contributions to the 5.1 Experience and developer Rudolph has a solid background in computer communities. science fundamentals and many years of software development experience on UNIX and Rudolph is also a contributor to multiple online Windows at all levels of the application stack. and print journals such as MSDN, IEEE Security Prior to joining Foundstone, Rudolph led the & Privacy and Software Magazine, where he checks development team for BindView's (now writes a column on writing secure code. He has Symantec) bv-Control for , a also written the foreword for the Microsoft vulnerability assessment product. In his role as Patterns and Practices Group's Web Services lead developer, Rudolph collaborated with a Security Guide. global team in creating updates to the product, which scanned for the presence of 5.3 Professional Education vulnerabilities as they were released. Rudolph earned an MS from Carnegie Mellon University specializing in Information Security Rudolph has also worked as a software and a BS in Computer Engineering from Goa developer at Morgan Stanley, where he was University in India. responsible for creating Microsoft Office based solutions for the Equity Research group. Most recently, Rudolph was a researcher at Carnegie Mellon University's CYLAB, investigating virus and worm threats, especially over peer-to-peer networks. His research interests also span the This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 13

1 http://news.zdnet.co.uk/software/developer/0,39020387,39228663,00.htm 2 http://www.codesecurely.org/wiki/ 3 http://en.wikipedia.org/wiki/Requirements_analysis 4 http://msdn2.microsoft.com/en-us/teamsystem/default.aspx 5 http://msdn2.microsoft.com/en-us/library/aa480484.aspx 6 http://www.ffiec.gov/ffiecinfobase/index.html 7 http://www.sandia.gov/scada/standards_and_outreach.htm 8 http://www.owasp.org/index.php/Category:OWASP_Guide_Project 9 http://www.oasis-open.org/ 10 http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/s3i_tools.htm 11 http://www.cs.umd.edu/ugrad/current/Research/Reilly&Marshall.pdf 12 http://en.wikipedia.org/wiki/Wiki 13 http://www.mediawiki.org/ 14 http://www.openssl.org/ 15 http://www.zlib.net/ 16 http://osvdb.org/searchdb.php?action=search_title&vuln_title=openssl 17 http://osvdb.org/searchdb.php?action=search_title&vuln_title=zlib

This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ Page 14