The Security Development Life Cycle
The world of IT changes quickly, and products that are very useful today may be totally obsolete in just a few years. Accepting this as an unfortunate, if necessary, cost of the increasing benefits that we realize from IT has led to the creation of the System Development Life Cycle (SDLC) methodology. This has even been formalized in standards like ISO 17799 and NIST's 800-42, so it's now part of the accepted way in which IT systems are managed.
The SDLC, as defined in SP 800-42, has five phases. These are shown below in Figure 1. The first phase involves defining the requirements for a new acquisition. Once the requirements are known, you either build a system in-house that fulfills these requirements or buy a product that does. Next, you deploy your solution and support it over its useful life. Eventually, this technology becomes obsolete and you need to start the cycle again, returning again to the first step.
Although the traditional SDLC is generally a useful model for the life cycle of any IT system, a slightly different version may be more appropriate for information security products. These seem to have slightly different phases in their life cycle that other products do. These phases are shown below in Figure 2.
Figure 2: Security Development Life Cycle (SDLC).
We will also by refer to this model as the Security Development Life Cycle (SDLC), possibly causing some confusion, but also satisfying the requirements for overloaded acronyms and abbreviations that accompany many government contracts. This model, although it seems to reflect the experiences of many businesses, has yet to be recognized by any standards organization.
In the SDLC, the first step is denial. An organization in this phase might do its best to ignore the fact that a recently-purchased security product doesn't perform as well as was hoped. Or in this phase, your security department might actually believe that they will be able to make that new PKI product usable, and that they will eventually be able to get its TCO down to a reasonable level.
The second step is anger. In this phase, the consumer of an IT security product realizes that some of the claims made by the vendor's sales force were somewhat less than truthful and carefully omitted a few critical issues that cause serious headaches once the technology is deployed. Because the vendors who sold you the troublesome products are often nowhere to be found at this point, this often leaves cursing the absent vendor the only alternative available to your security department. Security professionals tend to be intelligent and innovative, so in this phase you can expect to hear your vendors described in colorful terms that you, or anyone else, may never have heard before.
The third stage of the SDLC is defined by bargaining. In this phase, your security managers may try to work with their auditors to get their approval of the incomplete functionality that their deployed security products provide. In some cases, some decision makers may even spend time in this phase negotiating the terms of their continuing employment.
The fourth stage of the SDLC is characterized by depression. In this phase, some of your security staff may be saddened to realize that if they quit and come back to work for you as a consultant, they'll be supporting the technology that they just deployed. Others may realize that they will one day be stuck admitting that they were involved in actually using some dodgy technologies. On the bright side, the loud and colorful language that characterized the "anger" phase will now be gone, making the workplace relatively calm and quiet again.
The final stage of the SDLC is acceptance. In this phase, your security department becomes resigned to their fate of supporting the newly-deployed security products despite the many challenges that will accompany this. The turmoil of the previous phases disappears, and work returns to normal. But because new security technologies are continuously being developed, it’s also inevitable that your security department will be eventually called upon to support another project in the future. At this point, the SDLC will begin again at its first stage, completing the cycle.