One of the greatest challenges in security is that we are starting from behind—security programs, especially in healthcare, only started within the past decade or so. That means that threats, risks and vulnerabilities have accumulated to an overwhelming number. While your organization figures out a way to curtail those numbers, it’s important to stop the hemorrhaging by implementing processes to ensure that new solutions are designed with security in mind—but how do you do that?
What is SSDLC?
If you’ve worked in IT, you’ve probably heard of the software development lifecycle (SDLC). The SDLC is a model that helps organizations understand the requirements for, develop, maintain, alter, and predictably replace software solutions. In theory, the SDLC describes a “cycle” or “process” that continues after a solution is launched and addresses the ongoing needs and interests of the organization. There is an implementation project in common practice, and the SDLC is followed only to the point where the result meets current business needs—at which point the project is done, and the SDLC is forgotten. If security plays any part at all in this process, it is often at the end, just prior to go-live—which leads to otherwise avoidable rework and the discovery of flaws (possibly deep in the design assumptions of the solution) that are difficult to remediate. If we add security (Secure) to SDLC and make it SSDLC, and make the SSDLC “part of how the organization does business”—larger than a single implementation project—we can start to incorporate security into the very nature of all new solutions, so that they are sustainably secure by design. This means that security is considered at each point in the solution lifecycle, and potential flaws are addressed before they can lead to rework or even failure due to unacceptable risk thresholds. A product that followed an SSDLC process can be expected to meet organizational security standards and regulatory requirements upon launch and have the capability to sustain compliance at a minimum of difficulty and cost.
Custom Coding or Off the Shelf?
Each organization is different, and therefore you need to tailor your processes based on your organization’s strategy and current infrastructure. An SSDLC suited for managing bespoke development will significantly differ in scope and stakeholders from one suited for implementing an off-the-shelf app or other solution that is purchased from a vendor. Depending on your organization’s needs, therefore, you may need multiple SSDLC pathways.
Off the Shelf Solutions
Developing SSDLC for off-the-shelf solutions means you work with many different stakeholders from within and outside of your organization to ensure anything you implement follows what you defined as your organization’s SSDLC. It also requires clearly defining ownership of the solution, including maintenance and how to retire the solution and its data upon its end of life. Your process will need to have partners in your accounts payable, compliance, legal, IT, risk management, privacy and operations departments. You will also need to be empowered to be firm with vendors or business owners and to say “no” to solutions that do not meet your requirements. You will also need to set up a monitoring program to ensure that the owners of the solution, internal and external, are following the maintenance processes that were defined in the earlier stages and hold them accountable.
Custom Coded Solutions
To the extent that your organization develops its own internal solutions, you will need to have branches off of your off-the-shelf SSDLC process to ensure your internal developers follow your requirements. For example, if you hold your vendors responsible for maintaining dev and test environments for all of their solutions, you must hold your internal developers to the same standard.
Proper deployment of SSDLC will minimize your risk moving forward as you continue to bring new solutions (or even revamped solutions) through your defined process. You will also need to ensure you continually review the process to address evolving gaps and threats. It may also save your organization money by detecting vulnerabilities earlier in the process and addressing them before the solution becomes too complex or too far down the pike to stop.