Software Assurance: an Overview of Current Industry Best Practices

Home , Authorization, End user, Secure coding

Software Assurance: An Overview of Current Industry Best Practices

February 2008 Executive Summary Software Assurance: An Overview of Current Industry Best Practices

Software underpins the information infrastructure that governments, critical infrastructure providers and businesses worldwide depend upon for daily operations and business processes. These organizations widely and increasingly use commercial off-the- shelf software (“COTS”) to automate processes with information technology. At the same time, cyber attacks are becoming more stealthy and sophisticated, creating a complex and dynamic risk environment for IT-based operations that users are working to better understand and manage. As such, users have become increasingly concerned about the integrity, security and reliability of commercial software.

To address these concerns and meet customer requirements, vendors have undertaken significant efforts to reduce vulnerabilities, improve resistance to attack and protect the integrity of the products they sell. These efforts are often referred to as “software assurance.” Software assurance is especially important for organizations critical to public safety and economic and national security. These users require a high level of confidence that commercial software is as secure as possible, something only achieved when software is created using best practices for secure software development.

This white paper provides an overview of how SAFECode members approach software assurance, and how the use of best practices for software development helps to provide stronger controls and integrity for commercial applications.

Table of Contents

The Challenge of Software Assurance and Security 4

Industry Best Practices for Software Assurance and Security 7

Framework for Software Development 9

Software Security Best Practices 12

Related Roles of Integrators and End Users 16

SAFECode’s Goals 18

Conclusion 18

Questions for Vendors about Product Assurance and Security 19

About SAFECode 20

The Challenge of Software Assurance and Security Software assurance encompasses the development and implementation of methods and processes for ensuring that software functions as intended while mitigating the risks of vulnerabilities, malicious code or defects that could bring harm to the end user. Software assurance is vital to ensuring the security of critical information technology resources. Information and communications technology vendors have a responsibility to address assurance through every stage of application development.

This paper will focus on the software assurance responsibilities of software vendors. SAFECode Software However, integrators, operators and end Assurance Definition: users share some responsibility for en- Confidence that software, suring the security of critical information hardware and services are systems. Because of the rapidly changing free from intentional and nature of the threat environment, even an application with a high level of qual- unintentional vulnerabilities ity assurance will not be impervious from and that the software attack if improperly configured and main- functions as intended. tained. Managing the threats we face to- day in cyberspace requires a layered system of security, with vendors building more secure software, integrators ensuring that the software is installed correctly, operators maintaining the system properly, and end users using the products in a safe and secure manner.

4 5

New Risks and Countermeasures

The dynamic threat environment creates The Changing Technological challenges for all software-related opera- Environment tions. Vectors for attacks that could interrupt or stop critical software functions must be Rapid change and innovation are two of considered in design and development. The the most enduring characteristics of the IT software assurance risks faced by users to- industry. But innovation is not unique to day can be categorized in three areas: vendors. Criminals can and do innovate. In the span of only a few years a complex and 1. Accidental design or imple- lucrative criminal economy capable of sup- mentation errors that lead to porting specialized skill sets for identifying exploitable code vulnerabilities and attacking software has developed.

2. The changing technological The development of this sophisticated crimi- environment, which exposes new nal economy contributes to increasingly tar- vulnerabilities and provides adversar- geted and complex attacks. Vendors commit ies with new tools to exploit them resources to understand emerging threats and use state-of-the-art technologies, tools 3. Malicious insiders who seek to and techniques to develop software, hard- do harm to users or vendors ware and services that can resist attack. The process is one of on-going improvement as Accidental Design or new vulnerabilities are exposed, new threats Implementation Errors are created and new countermeasures de- The prevalence of hackers, viruses, worms veloped and implemented. and other malicious software that attack systems and networks highlights the first risk area when programmers inadvertently create faulty software design or implemen- tations. Developers address this risk through developer training and the use of secure development practices and tools. These processes are discussed in depth in the next section of this paper.

4 5

Malicious Insiders

There is a growing concern that global From a development perspective, these con- software development processes could be trols are focused more on “how it was made” exploited by a rogue programmer or an or- than “where they were sitting” during the ganized group of programmers that would coding process. compromise software, hardware or services during the development process. Vendors are extremely protec- CASE STUDY tive of their “soft assets” such EMC Corporation as their code base. The complex A centralized Product Secu- Architecture: Common development process and the rity Office coordinates inter- Security Platform A set series of controls used to pro- related programs for strong of software, standards, specifications and designs for tect the development process security assurance at EMC Corporation. common software security provide powerful management, elements such as authentica- policy and technical controls that Foundation: Product tion, authorization, audit and Security Policy Guides accountability, cryptography reduce these risks. There is no product development teams and key management using single way to manage or control and is a common reference state-of-the art RSA technol- for product organizations to a development process. Rather ogy. An open interface allows benchmark product security integration with customers’ there are proven best practices against market expectations security architectures. that companies use to manage and industry best practices. Metrics score company-wide Incident Response: Prod- their unique development infra- use of the policy. uct Security Response structure and business models. Center Defines and enforces Knowledge: Security EMC’s vulnerability response SAFECode members implement Training Role-based security policy to minimize risk of engineering curriculum trains exposure to customers. processes for vetting employees new and existing engineers and contractors regardless of on job-specific security best External Validation: Secu- practices and how to use rity Certification EMC has their country of residence. How- relevant resources. received extensive govern- ever, far more critical to soft- ment and industry certifica- ware assurance is establishing Process: Security Devel- tions in design, implementa- opment Lifecycle Over- tion and management of its and implementing processes and lays security on standard security processes and solu- controls for checking and verify- development processes for tions – including Common achieving a high degree of Criteria or FIPS 140-2. ing software assurance irrespec- compliance with the above tive of where it was produced. referenced Product Security Policy. ® ®

6 7

Managing Risk Through Software Assurance Best Practices These risks can all be managed through the and implementing practices to produce se- adoption of best practices in software assur- cure code that are better tuned to real-world ance. While a number of international stan- software development processes and result dards and certification regimes for software in higher levels of security. SAFECode’s mis- assurance have been issued, their effective- sion, in part, is to bring these practices to- ness in achieving real-world reduction in vul- gether to share across the community. nerabilities is debatable. Companies on their own have been taking the lead in developing

Industry Best Practices for Software Assurance and Security Software vendors have both a responsibil- Software development processes vary by ity and business incentive to ensure product vendor according to their unique product assurance and security. Customers demand lines, organizational structures and customer that software be secure and reliable. Ven- requirements. Not surprisingly, there is no dors also must produce quality products to single method for driving security and integ- protect and enhance brand names and com- rity into and across the globally distributed pany reputations. These pressures motivate processes that yield technology products vendors to minimize mistakes in coding, and services. Yet regardless of the method reduce the occurrences of post-sale vulner- used, there is a core set of best practices for abilities and related patching, and to protect software assurance and security that apply sensitive data and the operational integrity to diverse development environments. of customer IT systems.

To understand how vendors are earning the trust of customers, it is useful to examine best practices employed by the software industry and how they contribute to enhancing product assurance and security.

6 7

Third-party components and open CASE STUDY source software used in this company’s SYMANTEC CORPORATION products are subjected to additional requirements: Symantec’s product security framework, called Product Security Life • Teams check all code for vulner- Cycle (PSLC) shapes and governs the abilities using standard methodolo- lifespan of products. It has nine steps: gies and tools; engagement and preparation, education and training, security goals and • Providers are required to allow ac- planning, risk assessment, adoption cess to source code and/or that its of best practices, building automated vendor scan the code for common routine verifications, security testing, vulnerabilities; security readiness review and security response. • Teams have a documented, con- tractual service level agreement Implementation of the PSLC includes for security patches; a series of extensive training classes about security awareness, secure • Third-party code is implemented in development and security testing for a way that facilitates independent members of the development and qual- patching. ity assurance teams. This knowledge is applied with state-of-the-art tools for These efforts have earned leadership effective and secure source code con- for this vendor in the certifications figuration management, product build, community. Many of its products are source code analysis, product test and certified by Common Criteria, FIPS defect remediation. Engineers routinely 140-2, ICSA Labs and Checkmark; compile and check code modules and manufacturing and distribution sites the entire system. Security testing is have ISO 9001 certifications. performed by quality assurance teams and a product security team.

8 9

Framework for Software Development While there are several different develop- explicit, detailed description of product ment methodologies, they all share the fol- functionality. The level of detail in this lowing common elements: phase will adequately enable production of near-final drafts of documentation to Concept The initial phase of every software coincide with final release of the product. development lifecycle is to define what the software is supposed to do, how us- Programming This phase is where pro- ers will interact with the product, and grammers translate the design and how it will relate to other products within specification into actual code. Effective the IT infrastructure. This is when prod- coding requires implementers to enforce uct development managers assemble the consistent coding practices and stan- team to develop the product. dards throughout all aspects of producing the application. Best practices for Requirements This phase translates the coding ensure that all programmers will conceptual aspect of a product into a set implement similar functions in a similar of measurable, observable and testable manner. Programmers require appropri- requirements. Developers phrase these ate training to ensure implementation of requirements as “the product shall…” these standards. and specify exactly what functions will be provided, including related degrees Testing, Integration and Internal of reliability, availability, maintainability Evaluation This function verifies and and interoperability. It is crucial for the validates coding at each stage of the de- requirements phase to explicitly define velopment process. It ensures that the functionality as this will affect subsequent concept is complete, that requirements programming, testing and management are well-specified, measurable, and that resources expended in the development test plans and documentation are com- process. prehensive and consistently applied to all modules, subsystems, and integrated Design and Documentation Efficient pro- with the final product. Verification and gramming requires systematic specifica- validation occurs at each stage of de- tions of each requirement for a software velopment to ensure consistency of the application. This phase is more than an application. Complex projects require

8 9

testing and validation methodologies that anticipate potentially far-fetched CASE STUDY circumstances. That testing simulates Juniper Networks the kind of duress that an attacker Juniper Networks implements a TL might apply to break an application. 9000 certified process for managing product development. This process is Release This phase makes the application audited regularly and protects the in- available for general use by custom- tegrity of our products while provid- ing accountability and predictability. ers. Before releasing the application, a software provider must ensure that Projects are managed from concept to end of life (EOL) via a 7 the application meets product criteria, phase process that includes: identify delivery channels, train the sales organization to match target • Concept and Feasibility • Plan and Specifications buyers with the product’s functional- • Design, Implementation and Prototype ity, and fulfill orders. The applica- • System Test Beta Test and Pilot Build tion’s vendor support team must be • • Production able to respond to customer queries • End of Life at production volumes worldwide. Concept and Feasibility Requirements are defined, tracked, Maintenance, Sustaining Engineer- and managed via a database in this ing and Incident Response These phase of the process. If the require- processes support released products. ment originated from a customer, then the customer must approve the require- Applications must be updated with bug ments document to ensure the design fixes, user interface enhancements, or is what the customer really wanted.

other modifications meant to improve Plan and Specifications the usability and performance of the The development and delivery sched- product. Defects fixed in this phase ule is identified in this phase. The engineering team is defined, including of the product lifecycle are merged software engineering, a scoping team into the subsequent version of code, leader, and a product manager. A manufacturing plan, as well as a diagnos- and analysis is conducted to mitigate tic test plan is defined in this phase. the possibility of their recurrence in future versions or other products. Continued....

10 11

Beta Test and Pilot Build CASE STUDY After a successful internal system test, the Juniper Networks product moves into beta testing. Any ap- Continued from page 10 plicable regulatory testing is performed. Any software changes are coded, documented, Design, Implementation and Prototype reviewed, and checked into the main line of A software manager is assigned at this point code via the SCM tool. The logistics sparing and a scoping team leader manages the team plan, the training plan, and all documenta- that documents the functional design speci- tion are completed during this stage. fication and the system test plan. A release target is identified and a software engineer Production is assigned. Code reviews are conducted in The product is reviewed again by the team this phase and a member of Juniper’s se- before being committed to a specific re- curity research team is included in the pro- lease of software. After internal system test cess. External auditors may be engaged at and beta testing are successful, the prod- this point as necessary for certification pro- uct enters regression testing before being cesses such as FIPS or Common Criteria. made available for release. Common Criteria and/or FIPS verification testing is sched- All source code is derived from a single train uled at this point if appropriate. End-of-life of code, checked in and out of the mainline via timeframe for the product is predicted. a source code management system (SCM) to track changes, and any changes made must Product bugs or vulnerabilities during produc- be documented and peer reviewed. Juniper tion are reported, assigned a number, and utilizes a company-wide bug tracking sys- tracked in a bug tracking system. Resulting tem that is integrated with our SCM, and all code changes are tracked within SCM, the bugs are assigned a bug tracking number. same as initial code design. The code changes are again peer reviewed and code scanning System Test may be employed if appropriate. After verifica- Hardware and software unit testing is per- tion of code, the product is regression tested formed and the reports are reviewed in this and scheduled into a maintenance release. phase. Products are evaluated by an internal team made up of system test, software End of Life engineering, the software manager, hard- The product end of life is formally an- ware engineering, and technical publications. nounced and the notice is posted to Code reviews and code scanning tools are our customer service website. employed to minimize mistakes and vulnerabilities. If penetration testing is appropriate it is conducted at this point. Beta plans are defined, and training plans are then created. Prototypes are built during this phase.

10 11

Software Security Best Practices In each stage of the software development definition stage. Security requirements lifecycle defined above, there are best prac- must go in tandem with product devel- tices for instilling security in a software ap- opment and therefore address architec- plication. Across SAFECode’s membership, ture and design, product development the following security best practices and and programming best practices, and controls are well established: requirements for assurance, testing and serviceability. Security requirements set Security Training A prerequisite to at the outset of a product development developing secure software is for the cycle may include specific security met- development team to be well-versed rics and goals for each major phase of in information security – including development. Some teams measure the security and privacy issues that may effectiveness of design security reviews affect people who use the product. or code audits as well as security test- Some vendors use external trainers ing goals. These requirements are set to deliver security training to their at the beginning of the project and then product developers. Other vendors checked during the development cycle. have established in-house trainers and Quality Assurance teams will set their online educational content to customize security testing goals during this phase. the training to their specific technologies and applications. Training topics Secure Design The early design phase include a wide range of issues such as must identify and address potential how to do threat modeling, role-based threats to the application and ways security engineering, avoiding unsafe to reduce the associated risks to a library function calls and preventing negligible level. These objectives may cross-site scripting errors. Trainers be accomplished with threat modeling leverage the available published ma- and mitigation planning, which includes terials from industry and academia. analyzing the system, and potential vulnerabilities and attack vectors from Defining Security Requirements Se- an adversary’s perspective. Some curity requirements must be defined vendors formalize their attack vec- during the early stages of product de- tor analysis through threat modeling. velopment, especially the requirements Security experts can be brought in to

12 13

help facilitate this process of identify- intentional or unintentional unauthor- ing potential threats and developing ized modification. Design and code designs that mitigate those threats. reviews are also conducted as a way of preventing malicious insertion of code. Secure Coding The product development team must implement secure Security Testing Security testing is programming practices. This is where specialized validation that ensures programmers exercise the secure that the security requirements were coding skills they learned during met and the secure design and coding their training. These require inspec- guidelines were followed. Testing may tion of an application’s source code include vulnerability analysis, penetra- to identify vulnerabilities induced by tion testing, or use of security testing coding errors, and implement secure techniques such as “fuzzing” or varying programming practices that reduce external inputs to identify potential the frequency and severity of those buffer overflows and other errors. Some errors. Examples of secure coding vendors not only do internal testing, but practices include source code review also submit their products to external using a combination of manual analysis testing or certification. Penetration and/or automated analysis tools for testing by independent teams can identifying potential security defects. uncover vulnerabilities that would not be detectable using other means. Secure Source Code Handling Security best practices include careful han- Security Documentation Software dling of source code, including tight product documentation must include change management and tracking explicit treatment of security issues to and confidentiality protection of code help customers understand how to op- such that only authorized persons timally configure security controls, and are permitted to view or modify its how configuration options may or may contents in order to prevent malicious not expose potential security vulner- insiders from introducing vulnerabili- abilities. Examples include creating ties. Systems that process or handle a Security Configuration Guide as a source code must be protected from standard part of product documentation. unauthorized access inside or outside the developing company, and from

12 13

Security Readiness Just before releas- Integrity Verification Some products ing a product, the application developer offer customers methods such as signed must evaluate, document and assess code for verifying that the software risks posed by potential security gaps they have acquired is indeed from in the product. This risk manage- their trusted vendor. Using public key ment best practice enables a product technology to sign code is an example development organization to evalu- of enabling integrity verification. Some ate the security posture of a product software companies also build in in- and whether it is safe to proceed with tegrity checks on an on-going basis to its release to general availability. For assure that the components in the solu- some vendors, this phase is where a tion are indeed bona-fide components. final check is done to ensure that all of the security requirements set in the Security Research Developers learn requirements phase have been met. to adapt new technologies to provide greater customer capability and Security Response Any security vulner- value. Along with this investigation abilities (exploited or not) reported comes research into new threat vec- against the deployed product are tors and mechanisms to mitigate handled through incident response them. Similarly, as new attack vec- and relayed to the product develop- tors against existing technologies ment or sustaining teams to mitigate become known, developers implement the vulnerability. Communication with mechanisms to defend against them. the discoverers and the customers is important to ensure that proper ac- Security Evangelism Leaders in the tions are taken to mitigate the risk. area of software assurance promote In some cases, this may mean the the use of best practices by discuss- vendor will issue a patch to the prod- ing their practices and findings in uct. Some vendors have developed open forums, articles, papers and technologies that enable customers to books. SAFECode is a central forum receive security patches automatically for promoting the use of best prac- to minimize their exposure to risks. tices to those who need guidance.

14 15

CASE STUDY SAP

At SAP, the software development process is reporting framework that allows it to track governed by an overall process framework the performance of different product groups called “Product Innovation Lifecycle” (PIL). PIL regarding software security. Most SAP ap- consists of process standards which describe plications are based on a secure framework the different development phases such as in- (SAP NetWeaver) with standardized security vention, product definition, development, and features, freeing application developers from testing up to continuous improvement, as well security development tasks. Security coaching as product standards which cover cross-prod- is also available for application developers. uct aspects like accessibility, total cost of own- ership, legal requirements, or globalization. The fact that SAP knows every single one of its customers allows for a highly efficient Security is a product standard within PIL. The security management. Security issues can standard has evolved from a number of sourc- be communicated privately to customers via es, including SAP development experience, “Hot News”, eliminating the need for pub- know-how contributed by renowned security lic announcements. However, the research specialists, market trends, customer feedback, community has been showing a growing legal requirements, SAP strategy, and research interest in SAP software. To provide first- findings. It consists of a security planning hand information and create transparency, framework with best practices for address- SAP maintains security forums and publishes ing common security issues, and a security newsletters. Customers and researchers report that reflects the status of the imple- can also contact the SAP Security Response mentations defined in the security plan after Team directly via [email protected]. development. In addition, it includes test case descriptions for a number of requirements. In addition, the SAP Security Optimization Service can be used to check a customer’s The security standard represents the core of security status, and a staff of highly-qualified secure software delivery at SAP. It is comple- security consultants is available for remote mented by security training for developers and or on-site support in security questions. testers, in-house security tests, white-box and black-box security hacking by external partners on selected top-priority components, as well as a global product security

14 15

Related Roles of Integrators and End Users The best practices described above are aimed squarely at software vendors and their global supply chain of developers. Software assurance, however, does not end with the vendor. It is a continuous process. The broader ecosystem of software integrators, operators and end users who buy and deploy the applications all contribute to the overall assurance of a product or a system.

• Integrators: As applications are scaled to very large environments and integrated with other products and legacy systems, new vulnerabilities that did not exist in the stand-alone product may be intro- duced. Integrators must work in partnership with software vendors to find and mitigate these vulnerabilities.

• Operators: Operators must ensure that systems remain properly configured. Automated patching should be enabled to speed the remediation of vulnerabilities. Operators must also deploy standard layered defense measures for security, such as firewalls, antivirus, anti-malware, anti-phishing, intrusion detection and prevention, virtual private networks, strong authentication and identity management.

• End users: End users must take the responsibility to report potential bugs or vulnerabilities and must not introduce software from untrusted sources into systems. Responsible use of software is an important ongoing requirement for assurance and security.

16 17

• Verification: As the product enters CASE STUDY beta testing, the security team con- MICROSOFT CORPORATION ducts additional testing at a deeper level than during the Implementation Microsoft supplemented its existing soft- phase. In-house penetration testing ware development framework with security resources are often supplemented by and privacy requirements with dual goals external design review and penetra- of reducing vulnerabilities and reduction testing contractors. Attack surface ing the severity of any vulnerabilities not analysis and fuzz-testing is performed found during the development process. during verification. These process improvements, called the Security Development Lifecycle (SDL), • Release: At this point, an assessment include well-defined education and aware- is made of the overall SDL adherence ness, checkpoints, tools, deliverables and by looking at security test results, de- communication plans that augmented the fenses, mitigations, tools use and sta- existing development process. Security is tus of bug resolution. Finally, security incorporated into all phases of Microsoft’s response plans are put in place. development lifecycle: • Support and Servicing: A central • Requirements: Determine security security response team handles ex- certification requirements and list of ternally reported vulnerabilities. The processes and tools that must be used central security team works closely in development process. with the security response team and uses information about newly reported • Design: The product team defines vulnerabilities to update tools, educa- the product’s security architecture and tion materials, coding standards, and design guidelines, calculates how much potentially the security development of the product is exposed to untrusted process to minimize vulnerabilities in users (called the attack surface), con- future product versions. ducts threat modeling to uncover “at- risk” components, and defines criteria Microsoft is active in the certifications com- for shipment to minimize vulnerabilities. munity and regularly pursues FIPS 140 and Common Criteria evaluations of vari- • Implementation: The product team ous software products and components. creates the product and threats are Microsoft addresses feature requirements mitigated through updated libraries, for certification during the Requirements secure coding standards, security test- phase of development. ing and use of code analysis tools, and many defense-in-depth methods must also be employed.

16 17

SAFECode’s Goals SAFECode will drive stronger software secu- Consistent Evaluation, Metrics and Certi- rity and integrity across the IT ecosystem fication: The quality of code can be judged by producing a series of products that build based on both the inputs (strength of the on this first white paper. Each product will development processes and training and tangibly advance software security and in- education of developers) and the outputs tegrity over the next five years. The papers (reductions in downtime, vulnerabilities and will address five key goals: new malicious code).

A Comprehensive Knowledge Base: De- Effective Response Processes: Processes velopers are trained and educated in secure for identifying and remediating newly dis- coding practices and certification programs covered vulnerabilities are routinized across are well developed. Customers and develop- the software ecosystem. ers understand the importance of software as- Rigorous R&D: The most important soft- surance and realize the return on investment. ware assurance R&D needs are identified and Strong Development Processes: Develop- supported with the appropriate resources. ers implement processes that are demonstrated to be effective at improving security and have a clear roadmap for beginning the process of building robust software assurance programs.

Conclusion The global software industry is making great by every software developer and vendor. The strides at improving software assurance and result of efforts like these will be a higher security by applying best practices described level of confidence for end users in the quality in this white paper. Vendors who have imple- and safety of software that underpins critical mented best practices are already seeing a operations in governments, critical infrastruc- dramatic improvement in software product as- ture and businesses worldwide. surance and security. These are practices that should be considered, tailored and adopted

18 19

Questions for Vendors about Product Assurance and Security SAFECode invites your organization to study how vendors use these best practices as part of the product procurement process. The following are questions you might pose to determine the assurance and security of a proposed product procurement or vendor engagement.

• What are your best practices for software assurance?

• What are your best practices for software security?

• Who in your company is responsible for software assurance and security and how do they manage the processes?

• How are these best practices implemented by contractors and other members of your global supply chain?

• How does your company assure the quality and security of publicly available software modules and libraries used within your products?

• How does your company assure that implementation of standards-based protocols for networking functionality is robust and safe?

• How much has use of these best practices decreased defects and vulnerabilities in your software products?

• How does your procedure for patching facilitate non- disruptive operation of your software applications?

18 19

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 proven software assurance methods. Founded by EMC Corporation, Juniper Networks, Inc., Microsoft Corporation, SAP AG and Symantec Corp., SAFE- Code works to identify and promote best practices for developing and delivering more secure and reliable software, hardware and services. For more information, please visit www.safecode.org.

SAFECode (p) 703. 812 .919 9 2101 Wilson Boulevard (f) 703.812.9350 Suite 1000 (email) [email protected] Arlington, VA 22201 www.safecode.org