CA Technologies Secure Software Development Lifecycle (SSDLC)
CA Technologies Secure Software Development Lifecycle (SSDLC)
The CA Secure Software Development Lifecycle (SSDLC) and security-related best practices described in this document are designed to help our developers build more secure software and address security requirements throughout the product development cycle. Key aspects described below include education, architectural risk assessment, code analysis, penetration testing, and continuous tracking of known vulnerabilities and attack vectors.
CA Technologies Secure Development Best Practices
CA product development operates under a detailed internal Product Security Procedure which provides guidelines and objectives for secure development of our products. The procedure identifies requirements for security standards and provides strategies and tactics for implementing security during each phase of a product’s development lifecycle.
Responsibility for managing product security is not limited to the product teams. The CA Securability Center of Excellence (Securability CoE) and the Product Vulnerability Response Team (VRT) work with product development on the identification, reporting and remediation of vulnerabilities associated with our products. In addition, the Securability CoE, in collaboration with CA Education and the CA Council for Technical Excellence, offers numerous educational courses and other resources to assist CA developers with secure coding.
How We Strengthen Security at Each Phase in the Development Lifecycle
CA is a Charter Member of SAFECode, the Software Assurance Forum for Excellence in Code, a non-profit organization dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods. In its “Principles for Software Assurance Assessment,” SAFECode states that “software assurance assessment should primarily focus on the secure software development process and its application to the product being assessed, while taking into consideration the context of a product’s intended operating environment. There is no single practice, tool, or checklist that acts as a silver bullet and guarantees better software assurance. Rather, the efficacy and efficiency of software security practices and tools varies based on how they are applied and whether they are implemented as part of a holistic software development process within each unique organization.”
In other words, efficient software assurance cannot be achieved by a single practice, tool or checklist; rather it is the result of a comprehensive secure software engineering process that spans all parts of development from early planning through end of life. It is also important to realize that, even within a single company and associated SSDLC, there is no one-size-fits-all approach. The SSDLC must be firm in its approach to security but flexible enough in its application to accommodate variations in a number of factors, including different technologies in use and the risk profile of the applications in question.
In simplest terms, a product’s lifecycle can be divided into the seven phases of Plan, Code, Build, Test, Release, Deploy and Operate:
Over the course of its lifecycle, a product will often repeatedly move through each of these phases. In an agile environment, each sprint typically includes aspects of all or most of these steps compressed into a shortened cycle where product development doesn’t follow a straight flow. Rather, the sprint contains frequent iterations of parts of this flow on a weekly or even daily basis. However, this lifecycle flow is still a good model to which Security related activities can be anchored.
Underlying these phases are basic foundational, cross organizational services.
A successful security program requires a strong internal security support organization that manages and provides a foundation for the SSDLC, including collecting and sharing knowledge and experiences across the organization. The Building Security In Maturity Model (BSIMM) calls this team the “Software Security Group (SSG)”. At CA, this role is played by the Securability CoE which sets the internal standards for security and assists product teams during the SSDLC. The team also works closely with CA Support, the Vulnerability Response Team and SaaS Operations Team to better ensure we have comprehensive coverage available throughout the product lifecycle.
The Securability CoE is staffed with software security experts with experience gained from a large number of security assessment projects and certifications, such as a Certified Information Systems Security Professional (CISSP); Certified Ethical Hacker (C|EH); EC Council Certified Security Analyst (ECSA); and EC Council Licensed Penetration Tester (LPT). The Securability CoE team defines the SSDLC for CA and is independent from the product teams. CoE responsibilities include maintaining procedures, tools, and services to support the SSDLC, and acting as an independent body to help validate the security of CA products.
CA’s internal development procedures include guidelines and requirements on what, when and how security activities should take place. These include activities for all phases described below, and speak to items such as Training, Coding Guidelines, Architectural Risk Analysis, Code Analysis, Penetration Testing, as well as Vulnerability Response. When applicable, they also include examples and template artifacts that the product teams can use to assist in their development activities. The Securability CoE actively participates in and/or closely monitors a variety of standards, industry groups and industry best practices (e.g., ISO27034, SAFECode, OWASP, BSIMM) to better understand how we can enhance our secure coding practices.
While the Securability CoE plays an important role as independent internal consultants and to help verify a product’s security, it is critical that everyone involved in product development is engaged in, and has appropriate knowledge of, secure development practices, and shares information to enhance the process. The Securability CoE team updates our internal guidance, training and best practices to continuously enhance the information provided to the development organization. To simplify this process, the CoE has created a CA Internal Security Portal where current information can be found, and set up office hours where anybody in CA is welcome to share security related information or ask questions. The CoE also established a dedicated group of Security Adjuncts across the development organization. These adjuncts are part of the product teams and work closely with the Securability CoE to help ensure that their product(s) are going through appropriate SSDLC steps. As a virtual security special interest group, they also share information on their experiences with complex issues and how the process can be further enhanced.
CA strongly believes that by focusing on security from the beginning, and appropriately planning and designing the solution with security in mind, we can develop products that are more secure and we can bring them to market more quickly. This includes ensuring that all teams have access to appropriate security training, such as mandatory Security Awareness training, as well as comprehensive programs of role-based, instructor-led and web-based training spanning various areas, technologies, risks and tools.
During the planning phase, product teams often create an initial mapping of privacy and security requirements applicable to a given solution. Considerations include the type of data that will be handled by the solution, how and where the solution will be implemented, and industry requirements. Having checklists and central guidance from the Securability CoE helps in planning and implementing appropriate levels of controls for data protection.
Based on the risk profile, the target market, and the development stage of the product, an Architectural Risk Analysis (also called Threat Modelling) can help identify design level issues or threats in advance of implementation to help address flaws before coding begins.
Finally, this is also the appropriate time to register third-party components that are planned to be used, which helps ensure legal licensing compliance and provides an opportunity for a risk based assessment of the components.
During the Code phase, developers can take advantage of static application security testing tools (SAST) which focus on detecting security issues while the code is being written. This includes deprecated/unsafe functions as well as more complex issues that may require analyzing Data Flow, Semantic, Control Flow, Configuration and Structural issues. By identifying many types of issues including OWASP Top 10 vulnerabilities and CWE/SANS-Top25 Programming Errors during coding, the developer can more quickly address the issue, learn from the findings, and better understand how to write secure code and/or identify the need for additional training.
Depending on the product’s risk profile, we may also perform Peer Code Review where another senior developer, familiar with the code, secure coding practices and the expected functionality of the solution, reviews the code.
Finally, the product teams are notified whenever vulnerabilities are identified in a third-party component so they can assess their solution to determine if the product is affected. If the product team chooses to upgrade or substitute the component, the bill of materials is adjusted and the new component or version is included in regular and ongoing vulnerability tracking.
A formal system build is created on a regular basis, and the code base typically undergoes an audit using the same static application security testing tools used on the developer’s workstation during the CODE phase. This helps ensure that we catch issues, and provides us with another level of verification.
During the build process, we have procedures to initiate code integrity tracking which creates unique fingerprints for the build, and links it to the source code, the bill of materials and the system that was used to create the build. This allows us to better ensure that the code hasn’t been tampered with after the build, and provides further confirmation that we know exactly what went into the build.
When the various builds are ready to be integrated into a solution, a more complete system test is initiated. This system test can be repeated on a regular basis throughout the development lifecycle. The product team is able to work with the Securability CoE team to assess potential attack surfaces and to set up automatic Penetration Testing that can be scheduled to regularly scan the application for weaknesses.
In addition to the tool based approach, the System Test team can leverage the experience and the training they received during the planning phase to set up automatic and manual testing for the solution. These test plans depend on a variety of factors, and may include tests derived from both CA’s Internal Foundational Requirement procedures and industry best practices such as SAFECode Fundamental Practices, OWASP Testing Guide, etc. This can include low level details such as testing of edge cases and boundary conditions based on the architecture in use as well as higher level Foundation requirements such as proper encryption of Personally Identifiable Information at rest and in transit, using least privilege, etc. Test cases are often a combination of verification of expected behavior as well as negative requirements where carefully selected data can be used to help verify how the application handles edge cases.
Before a product is released, its risk profile is assessed, and, based on this assessment, high risk products may receive more advanced penetration testing, which is a combination of automatic and manual tests performed by an experienced and seasoned team of experts that are independent from the product team. These tests are performed in an environment built using the planned template architecture and configured according to documented best practices. The tests may include multiple weeks of testing various security aspects of the solution, interviews with developers and architects, manual penetration testing, scans by penetration testing tools, fuzz testing, as well as automated scans of the infrastructure and known/common vulnerabilities in third-party components and their configuration.
Identified vulnerabilities are tracked in the central CA defect tracking system together with an associated risk rating (Critical/High/Medium/Low + CVSS score), and are not approved as remediated until the Securability CoE has performed a Post Fix validation.
Finally, before any product is released, Antivirus/Antimalware scanning is performed on the final master media.
For traditional distributed or mainframe on-premise solutions, the DEPLOY phase is typically performed by the client or professional services. However, for SaaS solutions, this step is usually performed by CA.
During this phase for SaaS, a test environment is generally scripted to be identical to the planned deployed solution, and a final set of Application Penetration Tests as well as Infrastructure and Configuration Management Tests can be performed to help ensure nothing has changed and that previously identified vulnerabilities are resolved.
Through the remainder of the product’s lifecycle until it is no longer supported, the product team works with a number of central functions to help ensure that it is properly managed from a security perspective. This can include continuous scanning for vulnerabilities in our native code and in third-party components. This can also include managing and remediation of vulnerabilities reported to us by clients or security researchers, issues identified by CA development after the release, or by a dedicated team that is proactively looking for vulnerability reports concerning third-party components.
CA has a set of comprehensive incident response and vulnerability handling policies and works closely with leading vulnerability research entities to actively monitor a large number of sources for vulnerability information, including vendor sites, public mailing lists, and security-related websites.
To assist us in addressing vulnerability information, we have a set of policies and procedures contained within CA’s ISO 9001 certified Quality Management System, including comprehensive internal vulnerability handling procedures. In accordance with those procedures, we have a dedicated team of vulnerability experts who focus on complex vulnerability issues, and work with CA Technical Support, Sustaining Engineering, Development and Product Management to help ensure that each vulnerability issue is properly resolved. To address validated vulnerability issues, we post security notices, patches, and remediation information on the CA Support website. Additionally, we may disseminate security notices and advisories to public mailing lists (mentioned above), and to various vulnerability-related organizations such as CERT and Mitre CVE.