This series has been exploring the security program design process. Here, core elements of the security program will be identified and described.

As previously stated in this series, Security is a lifecycle and not a set-it-and-forget-it or one-and-done program. This comes from the nature of the security threat landscape, which is always changing and always shifting. This means that a security program follows the general flow of a system lifecycle – plan, build, monitor, respond & improve – and will need to remain dynamic as new risks are discovered or as new threats surface.

Program elements will, largely, come from the security risk assessment. In fact, the assessment results are critical and should be kneaded in with the output of the high-level brainstorming (ideation) effort that was completed earlier in the design process. The results of the risk assessment won’t be a direct recipe for the program, but will help focus the design team on the appropriate features, the program elements, to include in the design.

The elements that get built into a security program provide supporting structure for the goals of the program. The people, processes and technologies represented in the list of program elements are where security work begins to get done. Security will take shape and form through these initiatives.

Following is a description of a set of core program elements, laid out according to their major lifecycle phases, that are commonly included in a comprehensive security program design:

Plan

Risk & Vulnerability Assessments:

The process utilized to evaluate the potential security risks presented by a particular organization and the similar evaluation of both logical (cyber, network & systems) and physical vulnerabilities that may exist. Note: “penetration test” is the term that is used for a logical vulnerability assessment.

Policy, Standards and Procedures:

The documentation of what, why and how security will be carried out within a particular program. These terms are frequently used interchangeably, but the distinct differences are important to note in order to correctly authorize, describe and proceduralize a security program.

Build

Security Technology:

A specific and pointed strategy for the determination and coordinated implementation of technologies associated with Security. Technology is so increasingly important to a modern security strategy that an associated program is frequently developed within the larger security program in order to adequately address the need.

Security Awareness Education:

The delivery of multi-faceted content to organizational employees and, potentially, business partners that helps develop knowledge of the role that each individual plays in Security and what their response to risks/threats should be.

Monitor

Security Operations and Intelligence:

The heart of Security operations and monitoring for both internal and external threats, as well as the provider of initial incident response and critical communications.

Asset & Personnel Protection:

The people, processes and technologies that specifically address the security of logical, intellectual, real and physical assets that belong to a given organization.

Respond

Incident Response:

A planned and practiced process for responding to myriad security incident categories, whether logical or physical.

Business Continuity Planning:

A planned and practiced process that follows the incident response process and that works to restore normal business operations.

Crisis Management:

A planned and practiced process that coordinates organizational communications, so company leadership receives consolidated, consistent and timely information during Incident Response and Business Continuity scenarios.

Improve

Capability Maturity Model:

An alternative to legacy metrics that is particularly useful for Security. The model simply measures and reports the level of development of each program element on a scale that ranges from Initial (immature) to Optimized (mature).

Please note that there will likely be differences in the list of security program elements across companies because of the variation of risks being presented, organizational culture differences and/or disparity in jurisdictional requirements, etc. An example of this is that not all companies have requirements to provide Executive Protection services for their organizations.

Next, a look at how to future proof a security program will be provided.