Attachment_4_-_Secure_Software_Development.docx

Secure Software Development

BEST PRACTICES

October 2015

Table of Contents

BACKGROUND

Judiciary software development teams strive to create applications that meet the functional and security requirements of all stakeholders. To avoid creating code that is vulnerable to the rising threat of today’s sophisticated attacks, development teams should incorporate security best practices into all phases of the software development process.

SCOPE

This document is an introduction to basic principles of secure software development, rather than a comprehensive examination of all aspects of software security or software development. This document also identifies resources for a deeper understanding of particular aspects of this topic; however, expertise in this broad topic area is best achieved through dedicated training courses and experience. Hence, the intent is not to teach the reader to develop secure code, but to raise awareness of how security is woven into the various phases of software development and to encourage further exploration of this topic so that the concepts contained herein become an integral part of every judiciary development. It is tailored for use by all judiciary organizations operating under the auspices of the Judicial Conference of the United States. However, the decision to implement the best practices, either partially or completely is a local judiciary organization decision.

INTRODUCTION

Secure software development begins before the first line of code is written or the first requirement is documented. Software security starts with well-informed and knowledgeable development staff.

Secure software development extends throughout the software development life-cycle (SDLC). These best practices will help judiciary organizations build in security from project inception rather than bolt on security at the end of development. The goal of implementing these best practices is to develop software that is more secure in a timely and cost-effective fashion. There are many sources of security training and awareness available to the judiciary and the general public. Some examples of these sources are listed in Appendix A.

BEST PRACTICES

Secure software development concepts should be integrated into a judiciary organization’s existing development strategy. This document uses a sample SDLC process with 5 phases: requirements, design, implementation/coding, verification/validation, and deployment. This SDLC is intentionally simplified to support its adaptation across the variety of software development processes already in use by judiciary developers.

1. PHASE 1 – REQUIREMENTS

1.1. Security Categorization

Building security into any software application starts with a categorization of the risk associated with the information processed by the system. Risk is defined as the likelihood of a risk occurring multiplied by the impact the event would have on the judiciary organization or the judiciary as a whole (Risk = Likelihood x Impact). Within the judiciary, risk is categorized as High, Moderate, or Low. The Guide to Implementing the Judiciary Information Security Framework (Framework Guide) provides step-by-step instructions for the overall security categorization of the application.

1.2. Minimum Security Requirements

The software’s planned functionality should be thoroughly evaluated by knowledgeable IT staff as well as the developers to ensure that all necessary security features are incorporated.

Based on potential risk, identify minimum security requirements for key aspects of the software, such as access control and authorization, logging and audits, availability), configuration management, authentication, and encryption and integrity.[footnoteRef:1] As a starting point, the judiciary organization’s leadership, in concert with the software development and quality assurance teams, should consider these security objectives categories and their associated risk:[footnoteRef:2] [1: The Judiciary Recommended Security Safeguards (Appendix B of the Framework Guide) are grouped into 18 families. Appendix B of the Framework Guide contains a complete list of Judiciary Recommended Security Safeguards to be considered.] [2: The Security Objectives categorization provided here is primarily derived from Open Web Application Security Project’s (OWASP’s) Threat Risk Modeling.]

· Identity: Controlling access and ensuring users must provide adequate proof of identity;

· Financial: Protecting the organization from financial loss;

· Reputation: Protecting the organization’s reputation (from losses due to misuse or successful attack);

· Regulation: Meeting regulatory requirements (e.g., Payment Card Industry Data Security Standard (PCI DSS), Health Insurance Portability and Accountability Act (HIPAA); and

· Availability Guarantees: Ensuring the availability of the system (based on acceptable downtime of the system, as a whole, or of critical capabilities).

Security requirements developed during this initial phase should not focus on specific technologies or practices. Instead, they should look at what needs to be done, rather than how it will be implemented. This reduces the risk of requiring security that is too onerous (and consequently harder to develop) or security that does not adequately protect the system, the system’s information, or its users. The specifics of security-related design occur in the next phase.

2. PHASE 2 – DESIGN

2.1. Threat Risk Modeling

Threat risk modeling allows the developers to determine and focus on the correct controls and to produce effective countermeasures within budget. For example, there is little point in spending excessive time and money to protect against fraud on an application that has negligible fraud risk. The Open Web Application Security Project (OWASP) Web site provides extensive threat risk modeling guidance[footnoteRef:3] and training[footnoteRef:4] material. [3: OWASP, Threat Risk Modeling] [4: OWASP, Threat Risk Modeling Training]

Threat risk modeling may result in a re-evaluation of the security requirements developed during Phase 1. If new threats are identified, security requirements may need to be added. Conversely, if a threat is determined to be negligible, the security requirements related to that threat may be relaxed.

2.2. Design Requirements

Design and functional documentation should be created prior to beginning the coding process. For example, if one of the security requirements indicates that the application must support strong authentication, then the design process needs to identify the supported authentication techniques. The design documentation should describe how users will interact with the authentication mechanism and how those mechanisms will securely integrate with the rest of the application to prevent unauthorized access.

Design specifications should describe the security features to be incorporated in the software application and how they will be implemented. More holistically, any feature being added to the software (and its corresponding design specification) should be analyzed for its security impact. Attack surface reduction[footnoteRef:5] seeks to replace features with inherently weak or flawed security designs with more robust alternatives. [5: OWASP, Minimize Attack Surface Area]

2.3. Security Architecture Review

At the conclusion of the design phase, projects should conduct a formal security architecture review that includes the software developer(s), the court-unit Information Technology Security Officer (ISO) or program office Information System Security Officer (ISSO), and someone capable of providing an understanding of the security provided by the system on which the application will be running (e.g., a representative from the DCN operations/management group). In short, if a person can provide a unique, informed evaluation of IT security, their perspective should be considered. The review should assess the security requirements to ensure that they are adequate and to ensure that the proposed design for each of the security features will meet the requirements before coding begins.

It is a generally accepted principle of all software development that the cost to fix defects increases significantly as the software gets closer to deployment. Post-deployment fixes are more expensive still. One important purpose of the security architecture review is to clarify the design and minimize the number of fixes that are required due to inadequate understanding of the software security design.

3. PHASE 3 – IMPLEMENTATION/CODING

3.1. Tools and Techniques

The specific tools and techniques used for secure software development will vary depending on the language being used for development, the methodology being followed (e.g., waterfall[footnoteRef:6] or Agile[footnoteRef:7]), the purpose of the software, the threat risk models identified for the software, and so on. However, there are several general techniques that are applicable to a wide variety of developed software. These techniques are identified below. [6: Waterfall Model Wiki] [7: Agile Software Development Wiki]

· Develop applications in a non-production environment

· Use secure development tools (e.g., Microsoft Security Development Lifecycle Tools)

· Avoid using unsafe functions (e.g., Microsoft Banned Function Calls)

· Avoid known “common errors” (e.g., validate input from all untrusted data sources)

· Perform static analysis of code Links to more information on these tools and techniques can be found in Appendix B.

None of these tools and techniques completely eliminates the risk of software security defects. In order to be effective, they must be used throughout the development process, rather than being evaluated or applied at a single point.

3.1.1 Automated and Manual Static Analysis

At a minimum, perform automated static analysis of software to identify and help remediate software coding vulnerabilities and deficiencies. This is faster, less labor intensive, and requires less skill than manual static analysis. However, a manual code review by an expert would return fewer false negatives and false positives and, most importantly, could test for security design flaws (which automated tools do not).

3.2. Checking Requirements During Coding

Developers may discover in the course of their coding that the security-related requirements are incomplete and support multiple interpretations. The developer may prefer to choose an interpretation to allow coding to continue, but it is helpful to reconvene the set of stakeholders identified in the security architecture review and come to an agreement on the chosen interpretation. This reduces the risk that the software will reach the final security review in Phase 5 and have to be reworked. Any incomplete requirements also should be noted so that they are not repeated in requirements development of future software projects.

4. PHASE 4 – VERIFICATION/VALIDATION

Application testing should be conducted in a non-production environment.[footnoteRef:8] Verification and validation can begin when significant portions of the software have been coded and are stable. Verification is the process of determining that the software conforms to the requirements that were developed and designed against, while validation is the process of determining that the software can carry out its intended purpose. From the perspective of secure software development, verification and validation is performed against functional code, or dynamic analysis. [8: The AO’s IT Security Office offers security testing services to national system program offices and to courts that develop applications for multiple court use.]

4.1. Dynamic Analysis

Whereas static analysis is performed on the code, dynamic analysis is performed on the functioning application. Dynamic analysis tools simulate the actions of an attacker trying to exploit an application and also test for a variety of known application vulnerabilities to see if they are present in the system. One notable form of dynamic analysis is fuzz testing[footnoteRef:9], which is used to induce program failure by intentionally introducing bad input or unexpected actions. [9: OWASP, Fuzz Testing]

4.2. Penetration Testing

Unlike black-box[footnoteRef:10] penetration testing where the application design and source code are unknown to the tester, the best practice for enhanced secure SDLC penetration testing is a white-box[footnoteRef:11] approach where the application source code is provided to the tester to assist in their review. By having knowledge of nested conditional statements and internal workings of the application, it is easier for the penetration tester to discover vulnerabilities that might be missed by other blind testing methods. [10: Wikipedia, Black-Box Testing ] [11: Wikipedia, White-Box Testing ]

5. PHASE 5 – DEPLOYMENT

5.1. Incident Response Plan

Just because software is free of known vulnerabilities at the time of its release does not mean it won’t be subject to emerging threats over time or impacted by newly discovered vulnerabilities. It is important for judiciary organizations to have a response plan that helps them react effectively in the event of a security incident. Judiciary organizations should update their Incident Response Plan as appropriate prior to deploying the new software to production. An IT Security Incident Response Resource Packet has been developed to help judiciary organizations construct and maintain their Incident Response Plan.

5.2. Final Security Review

Before deployment, a final security review is conducted in which the judiciary organization’s IT staff verifies that the application meets its security requirements and ensures that all security items identified in the previous phases have been addressed. It is also a best practice for the security review team to include personnel who weren’t involved in earlier stages of the project. Discrepancies should be documented for the appropriate official to accept their risk in writing. Successful completion of the final security review should be a prerequisite for deployment of the code to production.

5.3. Release/Archive

When possible, personnel other than development staff should be tasked with the actual deployment of the software to production. Depending upon the size of the judiciary organization and available personnel, separation of duties[footnoteRef:12] may be difficult to achieve. Judiciary organizations benefit from creating a pre-deployment check list, scoped for the organization, and tailored to the specific software, which can be used to confirm that the deployment team has received official acceptance of all residual risk. Finally, the judiciary organization should ensure that all pertinent information, specifications, source code, binaries, threat risk models, documentation, emergency response plans (e.g., Continuity of Operations Plan, IT Disaster Recovery Plan, Incident Response Plan), and development data are archived for future support of the software. [12: AC-5, Separation of Duties]

INFORMATION

Questions or comments concerning this Resource Packet may be directed to the IT Security Office (ITSO) at (202) 502-2350. Correspondence may be mailed to:

IT Security Office Department of Technology Services Administrative Office of the U.S. Courts One Columbus Circle, NE Washington, DC 20544 BEST PRACTICES: Secure Software Development Publication Date: October 2015

Secure Software Development Training and Awareness Resources FedVTE – Federal Virtual Training Environment, an online, on-demand training center that provides Federal cybersecurity and IT professionals with training courses and hands-on labs.

DTS - IT Security Office – Secure Software Development Standards Connections Community, to distribute information and facilitate discussions towards developing more secure software across the judiciary.

DTS - IT Security Office – IT Security Training Providers (for IT Staff), establishing a baseline for security knowledge.

DTS - IT Security Office – IT Security Best Practices, Resource Packets, and Guidelines, a wide variety of relevant security guidelines and best practices.

DTS - IT Security Office – Information Technology Security Engineering, "building security in" to your IT infrastructure.

OWASP – Secure Coding Practices - Quick Reference Guide, a high-level review of some common secure coding requirements, as well as a glossary of common terms.

OWASP – Open Web Application Security Project, worldwide organization focused on improving the security of software.

Page B-1 of 1 Coding/Implementation Resources Secure development tools CERT – Secure Coding Tools, a selection of free tools for use during coding and verification/validation of software.

DTS - IT Security Office – Foundstone Vulnerability Manager, a software tool used to scan systems to identify and prioritize vulnerabilities.

Microsoft – Microsoft Security Development Lifecycle Tools, a collection of tools for use across Microsoft’s security development lifecycle (which corresponds closely to the sample SDLC used in this document).

McAfee – Free Software Development Tools, an assortment of free McAfee tools to assist with secure software development.

SAFECode – Fundamental Practices for Secure Software Development, a guide to effective secure development practices.

OWASP – Application Security Verification Standard Project, provides a basis for testing web application technical security controls.

Unsafe functions Microsoft – Banned Function Calls (C/C++), a quick reference of the unsafe functions commonly used with C and C++ code, along with recommended replacements.

GNU – POSIX Safety Concepts, additional background on C library functions which may be unsafe in common use.

Known common errors CERT – Top 10 Secure Coding Practices, language-independent recommendations.

Mitre – CWE/SANS Top 25 Most Dangerous Software Errors, provides a list of the most widespread and critical errors that can lead to serious vulnerabilities in software.

OWASP – Top 10 Web Application Security Risks, represents a broad consensus regarding the most critical web application security flaws. These flaws are also applicable to many non-web applications.

OWASP – SQL Injection, description, tools, examples, and tests materials.

OWASP – Cross-site Scripting (XSS), description, tools, examples, and tests materials.

SANS – Securing Web Application Technologies (SWAT) Checklist, provides an easy-to-reference set of best practices that raise awareness and help development teams create more secure applications.

Static code analysis tools OWASP – Static Code Analysis Tools, a short listing of static analysis tools. In addition to the free/open-source tools, many of the commercial tools also provide a trial version or limited-functionality version which may be sufficient for small-scale applications.

image4.png image2.png image3.png image1.png