This is the second part of a multi-part series on security program design. The previous article provided a snapshot of security event statistics from various industry sources, which clearly indicate the need for an intentional approach to security. This edition seeks to describe the initial process for designing a security program.

We know from Business 101 class that operational activities like HR, Accounting, IT, Sales and others all work to support, but do not define, a company, its’ mission or its’ strategy. One or more of these activities may be central to the company mission (IT, for example, may provide significant competitive advantage), but the mission statement, marketing strategy and other basic building blocks define the purpose of the business.

Similarly, the operational activities commonly associated with Security (both Physical Security and Cyber/Information Security) support the mission of Security, but they do not define the mission. An appropriate security program must be defined and a strategy put into place, in order for associated operational activities to have purpose and a common direction.

Security is a lifecycle, not a set-it-and-forget-it or one-and-done program.This comes from the nature of the global security threat landscape, which is always changing and always shifting.The optimal security program will take the fluidity of the threat landscape into account and will, itself, be able to change as necessary.This points to an intentional design effort in which appropriate stakeholders come together to develop the goals of the security program.

People involved in managing security risk should be involved in the design of the security program.This should include not just security practitioners, but owners of business processes where security risk exists like HR, Accounting, Finance, Supply Chain and others.

Remember, the role that Security plays is to work as subject matter experts to enable the organization to manage security risk. Some of the stakeholders involved in the design process may not report to Security, but are, nevertheless, involved in managing security risk.

The tendency will be for the security design team to include the collection of security “things” – people, processes and technologies – that are currently in place.Resist this urge.Instead, focus security design on the program mission and goals.The “HOW” (the tools, etc) of the program will fall into place at the right time.

Examples of brainstorming (ideation) statements that might go into the design of the security program include:

  • The security program must enable the management of security risk across our organization.
  • We want to establish a security culture within our company.
  • Our security program should be future-proof.
  • The security program must pursue continuous improvement.
  • The security program should be transformational for our business.

Once the security design team has developed the basic goals and tenets for the program, each individual design statement can then be broken down into smaller components for further development. This is where the HOW comes into place and questions associated with the people, processes and technologies that will be needed can begin to be asked. (Note: this is also the point at which existing security capabilities can begin to be worked into the design.) A suggested approach to this is to take each program design statement, one at a time, and ask what is needed in order to bring that statement into being. Here are just some of the possibilities of what will be needed to implement the security design:

  • Training for both Security and non-Security people.
  • Business process improvement projects.
  • Projects for new, updated or reconfigured (security and non-security) technologies.
  • Development of collaborative internal and external relationships.
  • Development of policies, standards and procedures.

The security design effort must be considered to be a project and should be managed accordingly. Resources, timelines, status reports and other aspects of good project management should be fully observed to help ensure project success.

A well-designed security program will further enable the respective organization through the entire lifecycle of security risk management – identification, classification, treatment and reporting. Additionally, Security by Design:

  • Helps ensure a comprehensive strategy.
  • Addresses appropriate security implementation through people, process & technology.
  • Prevents overhead associated with unnecessary, siloed and out-of-focus program elements.

The fundamental benefit of Security by Design, however, is that Security will be by design.

Next time, we will look deeper into the various stakeholder groups that own security risk and how their role in Security is developed.