building security into your software development life cycle

Building Security into Your Software Development Life Cycle

Matt Neely, Tom Eston & Amy Nolan


2 © SecureState 2011

Synopsis

This Whitepaper discusses the necessity and process of building security into your Software Development Life Cycle (SDLC). The steps needed to undertake the process while avoiding any pitfalls are explained in detail. The Whitepaper helps you to look at where security needs to fit in to the Software Development Life Cycle.

Authors

Matt Neely Tom Eston Amy Nolan

Table of Contents

Security and the Software Development Life Cycle ............................................................................................... 3 SDLC Background Information ............................................................................................................................. 3 The Importance of Security in the SDLC .............................................................................................................. 3 Trends SecureState Is Seeing ............................................................................................................................... 4 The SDLC Process: Many Styles, Same Steps .......................................................................................................... 4 What You Need to Do to Make Security an Integral Part of Software Development ............................................ 5 The Waterfall Style of the SDLC Process .............................................................................................................. 5 The Agile Style of the SDLC Process ..................................................................................................................... 9 SecureState’s Web Application Security (WAS) Assessment Expertise ................................................................ 10 Example of a Company Which Is Doing It Right: Taking Steps to Build Security into their SDLC ......................... 11 Conclusion ............................................................................................................................................................ 11



Security and the Software Development Life Cycle

SDLC Background Information The concept of integrating security into the Software Development Life Cycle (SDLC), while generating much popular press recently, is an already-‐familiar concept at SecureState. We have been helping clients to build security into their Software Development Life Cycle (SDLC) for several years, and have honed our expertise in the process. SecureState always recommends clients develop a Software Development Life Cycle (SDLC) program, to ensure that the formal and logical steps taken to develop a software product are imposed in all areas of software development.

Every application needs to go through the same process; there are no shortcuts to integrating security into the Software Development Life Cycle (SDLC). Additionally, if there are any big changes in an application—i.e. code changes—the application must go through the whole SDLC process again; otherwise, vulnerabilities could be introduced via the changes. Much vigilance is required to keep up with secure software development.

Obviously, the recommendations provided to an organization in building security into its SDLC vary according to its needs. An important thing to realize is with an organized, clear-‐cut SDLC, the integration of security into software development is much more attainable. The length of an SDLC, unsurprisingly, also can vary greatly, from one month to several years, depending on the variables present in an organization.

SecureState recommends the use of one, organization-‐wide Software Development Life Cycle (SDLC) in order to ensure that the same high standards are applied to each and every application being developed; and that the same testing is being conducted everywhere in the organization’s development efforts.

We can either help you to build an SDLC from the ground up, or we can perform a comprehensive SDLC Review, if your organization already has an SDLC. In the latter case, we can re-‐design your existing SDLC.

If you are purchasing software from a third party, make certain the third party is following an SDLC with security as an integral part of it.

The Importance of Security in the SDLC

A simple analogy that can be used to express the importance of building security into the Software Development Life Cycle (SDLC), rather than vainly attempting to add it at a later time, is to think of the process of constructing a house. No skilled builder would dream of using plans that did not contain a basement/foundation, doors, or roof trusses, as they are key components needed to keep the house structurally sound and functioning properly over its lifetime. Likewise, a skilled software development team



knows that security must be made an integral part of the Software Development Life Cycle (SDLC) for the software to be secured from vulnerabilities and the organization to be protected from breaches.

Trends SecureState Is Seeing

According to Verizon's 2011 Data Breach Investigations Report, there were 761 data breaches recorded for 2010. This is the highest number ever included in Verizon's 7-‐year-‐old annual report, and almost as high as the 900 breaches recorded in total for the six years from 2004 to 2009. Web applications accounted for 22% of breaches within hacking, and 38% of records; and, although the ‘percentage of breaches’ statistic declined from the previous year, Web applications are just as critical a vector as they were in 2009, according to the Report. In fact, if the hospitality and retail sectors’ statistics were removed from the dataset, web applications would regain their top spot. The telling trend is Web applications are more numerous than ever, according to Verizon’s Report. The lesson to be learned from this: Development and application assessment teams…be ever vigilant. This trend is reflected in SecureState’s day-‐to-‐day experience with clients: SecureState is seeing an increasing number of Web application vulnerabilities, which are precipitating more break-‐ins. Thus, building security into your Software Development Life Cycle (SDLC) is of paramount importance in keeping your organization protected from threats.

The SDLC Process: Many Styles, Same Steps

There are many different styles of the Software Development Life Cycle (SDLC) process. SecureState does not recommend a specific style of SDLC; we tell organizations where security fits in to the SDLC. And, while there are many styles of the SDLC process for building security into the SDLC, the steps that are needed to achieve this goal are the same in all styles.

No matter which style of SDLC you use, SecureState has the services to build security into your SDLC.

As the Waterfall style of diagram is the classic style of SDLC diagram, this Whitepaper will cover the Waterfall style in greater detail, and will cover another popular style, the Agile SDLC style, in less detail. And, remember: for any SDLC effort, the required steps [services] are the same; only the names of the diagrams [and of its stages] are different.



What You Need to Do to Make Security an Integral Part of Software Development

The Waterfall Style of the SDLC Process

The Waterfall style of the SDLC process is so-‐called because its components cascade down to lower levels. The style is easy to understand and implement. We can take it to most organizations and replicate it easily.

Figure 1: The Waterfall Style Diagram Depicting the Services Needed to Integrate Security into the Software Development Life Cycle (SDLC)



The individual steps of the SDLC depicted in the Waterfall style diagram, and associated services which must be performed in each of those steps, are as follows:

Requirements Definition Threat Modeling – Each organization will undergo different threat modeling, as each organization’s threat landscape is different. The threats a defense contractor faces are different than the threats encountered by a retail chain which accepts credit cards, or those faced by a financial services institution. You must know what threats could adversely affect your organization, in order to build security into your Web application.

Security Requirements Development – SecureState will work with your organization to develop security requirements for the particular software being developed. Before the subsequent steps of the SDLC can be tackled, we must ascertain what exactly is required of the software being developed, and what are the accompanying security requirements. In other words, in light of what the software needs to do, we figure out what security measures need to be taken to protect the software from vulnerabilities. For example, we ensure the application has proper authentication, logging, monitoring, and encryption built into the Security Requirements.

Architecture & Design Web Application Architecture Review – Continuing the house building analogy, this step entails SecureState “studying the blueprints” of the application. Architecture Reviews provide excellent baselines for current and future implementations. During an Architecture Review, SecureState engineers strive to learn the overall architecture, process flows, security practices, hardening techniques, and overall technical and business functions of the environment. For the Web Application Architecture Review, SecureState examines the Web application’s tier architecture, connectivity between these tiers, and the security and controls of the databases used by the application. We ask such questions as: “Are you doing logging correctly?”, “Is authentication being performed correctly?”, and “Is data being stored securely?” We make certain the requirements have been taken into account in the design of the software.

Development Secure Coding Practices Development or Review – SecureState can either develop secure coding practices for your organization, or can review your organization’s existing secure coding practices. Secure coding practices should be implemented to give developers guidelines they can follow to code applications securely. Examples are as follows:

• Make certain SQL queries are parameterized correctly and that input is validated • Ensure developers are performing proper validation to prevent Cross Site Scripting



White Box Web Application Security (WAS) Assessment – SecureState’s White Box WAS Assessment is a comprehensive source code analysis that examines each line of code for vulnerabilities. This gives the reviewer the maximum undestanding of the application, even more so than an attacker normally would have. Business logic is not yet tested at this step in the SDLC. The White Box WAS Assessment does not test business logic; it is a code level review of the Web application.

Basic Web Application Security (WAS) Training – SecureState can provide your organization with basic Web Application Security (WAS) Training. This introductory level training course provides general coverage of Web Application Security (WAS), and is not language-‐specific. It will provide your developers with the understanding of the OWASP Top 10 security vulnerabilities as well as the knowledge of how to develop secure code. Developer training needs to be conducted to ensure that developers understand how to detect and prevent common application vulnerabilities found in development code. Because many external issues arise from insecure application programming, WAS Training for all in-‐house developers should be implemented. From past experience, developers who undergo this type of training gain a better understanding of the current security vulnerabilities affecting Web applications, which in turn allows them to develop more secure code. This training would be provided to your organization annually.

Secure Coding Training -‐ One way to improve the security of Web applications is to incorporate secure coding practices within the coding of these applications. SecureState has developed a unique course to train developers on Secure Coding Practices without losing functionality. SecureState’s trainers are experts in application development and security. The team will leverage real-‐life examples of vulnerabilities that SecureState has discovered during Web Application Security (WAS) Assessments and demonstrate ways to improve the security within the application code itself. This training is specific to the language of the software product being developed. For example, if an organization has both Java and .NET developers, the organization would need two (2) separate Secure Coding Training classes. This training, which would map back to secure coding practices, would be provided to your organization annually.

Web Application Security QA & Testing Training – This hands-‐on training provides participants with the knowledge of how to test Web applications for security flaws and vulnerabilities. It teaches the methodology to follow when performing testing of Web applications. It is training for an organization’s security team performing the testing, as well as for the organization’s QA group. This training is suited to organizations which want to grow this skill set in-‐house. Otherwise, an organization can contract a third party to perform this testing. [Side note: SecureState is seeing an increasing number of organizations wanting to develop this skill set in-‐house. It is for these organizations that we offer this training.] This training would be provided to your organization annually.



Testing Grey Box Web Application Security (WAS) Assessment – A Grey Box Web Application Security (WAS) Assessment focuses on the Open Web Application Security Project’s (OWASP) Top Ten Flaws of Insecure Software. The OWASP Top Ten is a broad consensus about what the most critical Web application security flaws are and aims to help fight the root cause. SecureState’s Grey Box approach uses a combination of understanding the business logic and flow of the application, as well as user credentials, to assess all aspects of the application for security flaws. This is in contrast to the White Box WAS Assessment in the Development step. The Grey Box can be performed internally if your organization has properly trained QA staff, or by a third party. Organizations traditionally perform functional testing to test for defects in a Web application. Here is what we know: security problems also are defects. Thus an organization’s QA staff is perfectly suited to checking for security problems. SecureState has found this to be a good skill set blend, as accurately performing repeatable tasks is what is needed to detect security problems.

Web Application Security QA & Testing Training – Just as this training is needed in the Development step [See description above], it also is needed in the Testing step. This training would be provided to your organization annually.

Deployment Grey Box Web Application Security (WAS) Assessment – In this step of the SDLC, the Grey Box Assessment should be performed by a third party. There are two reasons for this: It ensures fresh eyes are examining the application at this crucial point in the SDLC. Also, SecureState’s skill set is stronger and deeper than the organization’s skill set in this area, because we perform Web Application Security Testing very frequently.

Maintenance Once a product has been securely put into production, it is important to make certain the product remains secure; thus the importance of the Maintenance step.

Black Box Web Application Security (WAS) Assessment – In the Maintenance step of the SDLC, the Black Box WAS Assessment should be performed quarterly. At this point, we are checking to make sure no vulnerabilities have arisen. The Black Box Web application scan with manual validation of testing is a Web Application Security (WAS) Assessment with no credentials or previous knowledge, which simulates an unauthenticated user.

Grey Box Web Application Security (WAS) Assessment – In the SDLC’s Maintenance step, it is a good idea to perform a Grey Box WAS annually, in order to do a “deep dive” as a further check into the software product.



The Agile Style of the SDLC Process

The second and final style of the SDLC process to be covered in this Whitepaper is the Agile style. The Agile SDLC process is characterized by “sprints,” or short development phases. The style is designed to accommodate rapid development. When new functioning is added to an application, an organization must make certain there still are security requirements within the SDLC, thus the need for Security Requirements Development. For each new feature that is added to the software, an Architecture Review must be performed for that new feature. Similar to the Waterfall SDLC process, White Box Web Application Security (WAS) Testing must be performed as the application is being coded; and Grey Box WAS Assessments must be performed as it is being tested and deployed. Also, as discussed for the Waterfall SDLC process, the Basic Web Application Security (WAS) Training, the Secure Coding Training, and the Web Application Security QA & Testing Training must be conducted as the application is being developed; and the Web Application Security QA & Testing Training is required when the software is being tested.



SecureState’s Web Application Security (WAS) Assessment Expertise

SecureState has been involved in testing Web Application Security (WAS) for over eight years. During that time, we have developed a customized methodology for performing our services. As such, SecureState primarily uses manual techniques to test WAS. When reviewing WAS, the industry accepts three primary methods: Black, Grey, and White (Code) level reviews. SecureState combines the Black and White level reviews to form a “Grey” level. This level allows SecureState to gain an understanding of the application environment, gather supporting documentation, and have access to user credentials. However, SecureState approaches the application as a “hacker” would, attempting to exploit vulnerabilities and misconfigurations, providing the organization with an economical way to demonstrate “Due Diligence” in evaluating WAS.

Figure 2, which follows, shows the percentages of the three types of Web Application Security (WAS) Assessments SecureState performed for clients in calendar year 2010.

Figure 2: Percentages of the Three Types of Web Application Security (WAS) Assessments SecureState Performed for Clients in Calendar Year 2010: Grey Box WAS Assessments (73%), Black Box WAS Assessments (24%), and White Box WAS Assessments (3%).



Example of a Company Which Is Doing It Right: Taking Steps to Build Security into their SDLC Doing it right means taking well thought-‐out steps to integrate security into the Software Development Life Cycle (SDLC). This regional auto insurance provider—and SecureState client—has a unique direct-‐to-‐customer approach that includes its e-‐commerce site. SecureState reviewed the organization’s security requirements to make certain they were built in from the start of the SDLC. SecureState also performed a Web Application Architecture Review on the insurance company’s Web Project in order to protect the company’s Internet facing systems and its good image, and to prevent access to customer data. The purpose of these Reviews was to identify security flaws in the current architecture and verify proper security controls are in place. SecureState found the Web Project was at high risk for loss of confidentiality and integrity of systems and applications. Additionally, the auto insurer was rated below average compared to similar organizations in the area of security. SecureState provided the company with detailed recommendations to improve its state in the short and long term, including design changes recommended to improve its security posture and create an e-‐commerce environment to protect the insurer as its Internet presence increased. Very limited logging had been enabled on the Web application, so one of SecureState’s recommendations involved adding security event logging to the application. Logging is important because logs can be used to detect attacks and investigate intrusions after they occur. With the insurer’s present level of logging it would have been very difficult to perform a thorough investigation of a breach in the company’s Web application. SecureState added items that would be useful in the case of a future fraud investigation as well. SecureState further recommended that these logs be forwarded and stored on a secure central logging system. Specific recommendations on what types of devices and events should be logged also were provided to the client. Another benefit for the client that came out of the engagement was SecureState’s discovery that although the insurer was handling credit cards correctly, it was not handling bank account numbers correctly—which potentially is more damaging to consumers. The organization was not encrypting routing and account numbers in transit and in its database. SecureState put steps in place to make certain the data was encrypted.

Conclusion

The integration of security into the Software Development Life Cycle (SDLC) is critical to keeping the product and the organization secure from threats. The SDLC process can be accomplished in a great many ways, but the steps an organization must take to get there are the same. SecureState has the services, expertise, and experience to guide your organization through the steps that need to be taken to arrive at a securely developed Web application. As your security partner, SecureState will help you, every step of the way: Requirements Definition; Architecture & Design; Development; Testing; Deployment; and Maintenance.

building security into your software development life cycle

Documents