I came across this excellent post by Brian Freas on the semantics of the word “implement” in Luke’s Facebook group. The argument is about if security is “implemented” in the initiation phase or stage in terms of the SDLC.

SDLC: System or Software?

At which phase of the software development life cycle (SDLC) should security be implemented first? (Luke’s Question #20)

Luke’s question #20 in his book, “How To Think Like A Manager for the CISSP Exam,” uses “software development life cycle (SDLC)” and comes with four options from the NIST “system development life cycle (SDLC).” As software is just part of a system and has a different scope, I suggest the term “software” be revised to align with the NIST SDLC terminology, “system.”

What Is Security?

The definition of security varies in different contexts. In this post, I refer to security as information security and treat information security and cybersecurity as synonyms because they share the same objectives (the CIA triad) as defined in the FISMA and the US Presidential Cybersecurity Policy, NSPD-54/HSPD-23.

Generally speaking, security is about protecting assets by “implementing” controls to reach “the state of being free from danger or threat (Google Dictionary),” specifically, to achieve the objectives of confidentiality, integrity, and availability.

Objectives, Risk, and Security

Given that objectives drive all activities, risk may occur in any activity and affect the achievement of those objectives. In information security, we apply controls to handle risk to ensure the realization of security objectives: confidentiality, integrity, and availability.

Engineering, Projects and Operations

The SDLC is the core concept of engineering, during which risk is managed. As engineering starts with an engineering project and turns its results into operations, controls can be applied in projects and operations. A project is a one-time endeavor (a limited period); its results are transferred into day-to-day operations to create value persistently.

When Should Security Be Implemented First?

For me, “security is implemented” means “controls are implemented to mitigate risk and achieve security objectives.” If we agree that risk may happen anytime or across the SDLC, it makes sense to substantially “implement” controls to mitigate risk in the initiation phase. Planning and considering controls won’t mitigate risk while implementing controls does. If we plan and consider a lot but “implement” nothing in the initiation phase, it implies we have our projects expose to risk in that phase.

The following are scenarios that implement controls in the initiation phase:

Inherited Common Controls

“Common controls” are not developed from scratch. They are inherited from the organization or the system’s operating environment and take effect from the beginning (or in the initiation phase).

For example, an administrative control may require you to develop a policy and procedures for the effective implementation of other security controls. The endeavor of developing the policy and procedures is an implementation of the administrative control; it’s different from the execution or enforcement of the policy itself. Implementing administrative controls are common in the initiation phase.

assurance-related Controls

A trustworthy information system is evaluated not only in terms of its security controls (e.g., security functions, features, mechanisms, and architecture) but also assurance-related controls (e.g., the processes, practices, policies, and procedures).

The initiation phase in the NIST SDLC comprises “Initiating” and “Planning” processes from the PMI’s perspective on project management. Identifying and analyzing stakeholders, preparing the business case, evaluating the cost/benefit of alternatives, and chartering to officially initiate a project are the most significant activities in the initiation phase.

The legacy NIST SDLC identifies some activities of the initiation phase:

• Initiate Security Planning
• Categorize the Information System
• Assess Business Impact
• Assess Privacy Impact
• Ensure Use of Secure Information System Development Processes

NIST SP 800-53 R4 specifies the SA-3 control to ensure the use of secure information system development processes:

Conclusion

• Risk is ubiquitous, so we consider and plan for controls and implement them to mitigate risk, even as early as in the initiation phase.
• Planning and considering won’t mitigate risk. If we don’t substantially implement controls in the initiation phase, we are exposed to risk in that phase.
• It’s not uncommon to “implement” administrative controls, common controls, and assurance-related controls in the initiation phase.
• The idea of implementing controls is different from implementing security functions. Some controls are implemented to ensure the effectiveness of security functions or other controls.