Introduction
To start from a common understanding, SSDLC is the acronym for Secure Software Development Lifecycle. In today's world, you could use the same acronym to represent "Secure System Development Lifecycle" and "Secure Supply [Chain] Development Lifecycle."
Increasing cybersecurity concerns and business risks associated with insecure software has brought increased attention to the need to integrate security into the development process. An SSDLC process is a model to specify how to perform that integration. Implementing a proper SSDLC is more important than ever in building secure applications.
Why is this important?
A secure SDLC process ensures that security assurance activities, such as design review, architecture analysis, code review, and penetration testing, are an integral part of the development lifecycle. The SSDLC process helps with those topics by "baking in" the appropriate checks and balances along the way. A few of the benefits immediately evident are:
More secure software.
Reducing / preventing damage caused by cyber-attacks.
Early detection of flaws in the system.
Reducing the costs of repairing information security weaknesses in applications.
Significantly decreasing the number of vulnerabilities in the application when it is ready to go live, thereby reducing delays in the go-live process.
Awareness of security considerations by developers and stakeholders.
Overall reduction of inherent business risks for the organization.
Problems with legacy approach
Many organizations trying to implement an SSDLC process fail. The reason lies in that an SSDLC process must be assimilated into the organization, according to each organization's requirements. The fact remains that most organizations do not fit into a neat box –and neither do today's cyber criminals.
Most organizations conduct security testing after they finish developing an application and a short time before going "live." This can result in:
Finding the vulnerabilities late, hence the cost of fixing them is higher.
There not being enough time to fix all vulnerabilities.
Delay in launching the application.
Launching a less secure, i.e., not secure enough, application.
Lack of awareness of security considerations by developers and stakeholders.
Flawed thinking
Many organizations and their responsible officers believe that security is something that is only to be considered in relation to the final product delivered. In reality, organizations are responsible for not only the security of the application being developed, but also the environment and process through which it is developed.
Security is no longer one-off or a specialized department or discipline. Cybersecurity is now much more closely aligned with definition of "security" itself:
The state of being protected or safe from harm, danger, or threat.
Things done to make people or places safe.
The quality or state of being secure.
The safety of a state or organization against criminal activity such as terrorism, theft, or espionage.
Procedures followed or measures taken to ensure the safety of a state or organization.
The state of feeling safe, stable, and free from fear or anxiety.
Security applies not only to firewalls and passwords, but encompasses data governance, an organization's employees, processes followed, and more –in addition to the final released product or application.
Regulations, best practices, and compliance (Oh my!)
Similar to the issues around outdated understanding of security, leaders often also believe that certain regulations and compliance standards are checklists to be met at some point in time prior to release or launch and revisited on a quarterly or annual basis.
Instead, regulations are written and in place to protect both the organizations and their customers. Regulatory bodies require certain checks and balances in order to be "compliant." Those checks and balances are not checklists, though; they are meant to create artifacts to serve as evidence at key points in a larger process –and the process should not be "completing a checklist." Best practices are evolving and constantly updated to provide ongoing guidance of the safest ways in which to implement those controls.
It is best to think of those concepts as intertwined, as they are all related and much easier to accomplish as a full process than to try to address [inadequately] through one-off efforts. Thus, an SSDLC acknowledges the need for security throughout the process and requires ongoing education and training.
Documentation
Part of an SSDLC is to document the process being followed –and the existence of this documentation is similarly an artifact being created. This Wiki is serving as the creation of this documentation and the proposed approach and needs, with each aspect highlighted.
As such, this project was created with a custom process inherited from a basic Agile template. It was specifically designed to incorporate aspects of security, compliance, product planning, governance, audit and tax concerns, and reporting. It supports an optimum, lean enterprise development process.
Tools
While this process and the associated documentation can be accomplished in multiple tools, the one chosen for illustration and implementation in this case is Azure DevOps. The reasoning for this is that it is somewhat one-stop-shopping for all of the functionality needed, most of which is easily configured without custom development to implement. (These points are documented in their current format for visualization and example. This is not intended as a bias but to illustrate the flow.) Again, while the same can be accomplished through multiple tools, each additional tool brings risk, cost, overhead, and loss of efficiency.
Throughout this documentation, those expected capabilities will be noted in the case of a different tooling choice. Each built-in aspect of DevOps will be highlighted and later referenced for similar implementation, where known, for other tools. Azure DevOps' documentation has been imported into this Wiki in an effort to not "reinvent the wheel." However, it IS copied and is contained as its own point-in-time version, as Microsoft updates its documentation regularly and this capture of current state is necessary in this case.
Assumptions
The purpose on which this documentation is somewhat predicated is on an understanding of the need for end-to-end traceability. Azure DevOps' approach to this requirement –which has been the standard in enterprise development for more than a decade with the release of the original Team Foundation Server –in its current iteration of functionality is reprinted for reference, internal to this Wiki, here.
Customizations
This process alone, while gathering the appropriate artifacts, also expects certain customizations to have been made to the workflows and rules in the larger process. The customization of this process template in DevOps is documented here.
Process
The process itself and how it correlates to optimization and the support of both an agile approach and business concerns can be found here.
Recommended reading
While this is our/my approach to an SSDLC, additional context and information can be found in the published practices of Microsoft.
As per their Security Portal, "In today's complex and regulated environment, organizations need to focus on building more secure solutions that deliver value to their customers, partners, and shareholders. Through the Security Engineering Portal, we're sharing what we've learned through our decades of experience implementing and continuously improving security-aware software development, operational management, and threat-mitigation practices that are essential to the strong protection of services and data."
They have similarly established and published the following:
Secure DevOps Development and operations should be tightly integrated to enable fast and continuous delivery of value to users. Secure DevOps (or "DevSecOps") allows for making security principles and practices an integral part of DevOps while maintaining improved efficiency and productivity.
Microsoft Security Development Lifecycle (SDL) With today's complex threat landscape, it is more important than ever to build security into your applications from the ground up. The Security Development Lifecycle (SDL) consists of a set of practices that support security assurance and compliance requirements. The SDL helps developers build more secure software by reducing the number and severity of vulnerabilities in software, while reducing development cost.
Operational Security Assurance (OSA) OSA outlines security engineering practices that organizations should adopt and is a framework used to improve core aspects of operational security of online services. These practices help to establish a scalable process for improving operational security in cloud-based infrastructure.
Open-Source Security Find tools and techniques to help you manage security risks in third-party components.
Build and Test
This Wiki is part of the larger documentation and, as such, is built into an inclusive PDF document upon changes to the underlying repository. Please be cognizant of that fact when making changes and branching, as this is version-controlled and should be treated "as code."
Contribute
Contributions are always welcome and follow the normal code promotion and review process. Again, this is a repository of MD (markdown) files, so traceability and auditing should be inherent. The changes here should be "evergreen" and in line with approved process changes.
Comments