Modified Interoperable Software Development Life Cycle Process

The software development life cycle (see Exhibits 12 and 13) for dispersed and distributed interoperable systems requires that prototyping be done which redefines the requirements definition, provides early identification of interfaces, and shortens the hardware and software development and acceptance phases of the life cycle when combined with real-time testing and anomaly resolution. In order to assure that appropriate controls deployments are considered and incorporated, system designers and developers will need to consider a slightly modified approach in which security-relevant safeguards and protection mechanisms are managed.

Exhibit 12.  Modified System Development Life Cycle

Exhibit 13.  System Development Life Cycle Protection Strategies Deployments

Management must be able to identify a protection strategy that addresses threat manifestations before, after, and during their occurrence(s) as a qualitative “relative timing factor” rather than as a calculated probability of occurrence or frequency, since interoperable systems have a high probability of being exploited. For most systems an attack(s) is a foregone conclusion and simply a matter of “when” rather than “what if” or “will” a threatening event occur.

In Exhibits 13 and 14, consideration is given to the types of controls and associated safeguards and protection mechanisms deployed as countermeasures to threats. Types of controls and safeguards are generally classified as detective, preventative, and recovery controls. Since these control types may have an associated protection strategy and occur in a recursive process throughout each phase of the life cycle, then each safeguard has a unique signature depending upon each of the three types of controls and protection strategy(s) employed, as well as individualized recursive characteristics.

In Exhibit 14, the recursive characteristics and uniqueness of signature are clearly evident. Regardless of the point of origin within the PDR iteration, there is an identification (real or perceived) and a detection (D) of an exposure or risk, an associated recovery (R) strategy, followed by a preventative mechanism (P) or strategy that is for all practical purposes independent of when the threat manifestation actually occurs.

Exhibit 14.  Recursive Characteristics of Protection Controls

If taken in a controlled environment, prevention is normally the first of the recursive steps since there are normally control deployments based upon perceived threats rather than actual manifestations. The uniqueness of the PDR signature (i.e., 1 + 2 + 3 + … n + n+1) is attributed to the combinations of subsequent activities and protection strategies introduced into each iteration of the process. The combination of all safeguards with respect to detection, prevention, or recovery, therefore, provides management with a process and a metric that is relatively independent of time for determining risk accountability and propensity of threat manifestation(s).

Stacey, Helsley, and Baston in their paper, “Risk-Based Management, How To: Identify Your Information Security Threats” arrived at a similar conclusion in determining threat events and their relationship to protection strategies.

They outline a structured approach for the identification of a threat population, correlating threat events and protection control strategies to security concerns. In determining when to protect a system from a threat event (before, during, or after the occurrence of a threat event), they arrived at the conclusion that once a threat event had been identified, one could assign a set of safeguards for each protection strategy (i.e., prevention, detection, and recovery) as an independent point of control.

Integrity Failure Impact Assessments (IFIA)

System availability and robustness often erroneously preempt reliability and integrity concepts. In an interoperable environment comprised of a system(s), management’s confidence in the integrity of the system (level of trustworthiness) is primarily based on whether the “system” is readily accessible for use and possesses the capability of being able to process information, rather than the integrity of what is produced, when it was produced, who used it (or was authorized to used it), or how was the information produced, protected, stored, transmitted, and/or disseminated.

In assessing the level of trustworthiness of a system, processing dependencies and types of controls, threat events, and impacts to its integrity, as well as the associated relationship to an enterprise’s protection strategy (PDR) must be identified.

This relationship is best described as an Integrity Failure Impact Assessment (IFIA), in which deliberate and accidental threat events (including associated actions/reactions and vulnerabilities), primary and secondary impacts, processing dependencies, and protection strategies are evaluated, documented, and preserved as an enterprise-wide baseline supporting the corporate decision-making process. IFIA, which are similar in nature to reliability engineering determinations of mean-time between failure and mean-time to repair, will need to be developed based upon the enterprise’s overall protection strategies.

Once IFIA have documented the frequency of occurrence and the mean-time to restore a system(s) to a known integrity state(s), management can qualitatively ascertain and maintain an acceptable level of confidence in its high-integrity systems and processes based upon sound engineering concepts and practices.

Exhibit 15.  Protection Strategies