InfoSec Can Be Taxing, So Here’s a Taxonomy

Information Security can sometimes feel like death by documentation, like a bunch of red tape just to keep regulators and auditors at bay. Throw in differences in lexicon, and seeing how all the many pieces fit together can be quite difficult.

Getting everyone, practitioner and leadership alike, on the same page when it comes to terminology in the information security space is key. If everyone can speak the same language, a well-understood and well-orchestrated information security governance structure won’t be far off.

As the information security approach is formulated, there is a taxonomy of terms such as program, framework, policy, standard, plan, procedure, control, and guideline – that are used primarily when speaking of required components to support the different levels in the structure. But how do these terms interrelate? Can the same term be used in different contexts, for instance a program within a program? Let’s begin to dissect the different uses in which this taxonomy of terms exists and provide clarity for their interrelation.

Program

Program is at the highest level of the taxonomy. The program describes the overarching governance, approach, and structure of a specific context. Within the larger security context is the information security program, which lays out the strategy and holistic structure for how an organization will ensure the confidentiality, integrity, and availability of their assets. Within the smaller context, a program can be specific to a capability within the information security program, such as a risk management program, awareness and training program, incident response program, and business continuity program. These smaller, topic-specific “sub-programs” detail out the approach, processes, roles/responsibilities, communication mechanisms, and metrics for how the organization will manage those topic specific capabilities in support of the larger information security program. These given examples of program illustrate that smaller programs can live within a larger program.

Framework

The next layer in the taxonomy is framework. Frameworks provide a guided structure typically built from established standards and vetted best practices as a ready-to-use, accelerated solution for a specific problem space, such as information security, enterprise architecture or software development. Frameworks in the information security context can be at the entire security program level with standards organization frameworks such as NIST’s Cyber Security Framework or ISO/IEC’s 27000 Series, or at the sub-program level, with frameworks like risk management or incident response. The alternate to using standards organization frameworks is a slang term called “rolling your own”, where the components used in the framework are either built internally by the organization and may miss the included benefit of vetted standards and best practices or can be a framework of frameworks where multiple standards organization frameworks are weaved together to form a single hybrid framework. Impact Makers believes that a successful information security program starts with an openly available, workgroup or standards organization backed framework, where standards and best practices are at the core.

Policy

In many cases, when information security is talked about, it’s the policy that gets all the attention. This is because the policy at the highest level is considered “the what” required by management to operate an information security program. A policy is a formally established requirement that helps provide overall guidance and limits to achieve intended outcomes, all typically enforced using standards. The policy that is written is then put into action by implementing “the how”, or the plans, standards, and procedures required to operate the information security program. An example of a policy statement would be “we will properly maintain assets across all technology environments”.

Plan

For every program that exists there will be an accompanying plan. The plan is where all the magic happens, taking the higher-level governance components of program and policy and building a plan that includes tools, templates, and procedures to address the specific controls for the program it’s meant to support. Taking the previously given examples for program, this means there will be an information security plan representing the overall security program, a risk management plan, an awareness and training plan, an incident response plan (IRP), and a business continuity plan (BCP), which should also be accompanied by a disaster recovery plan (DRP). The information security plan details the program management controls and organization-defined common controls that can be used by each system. Beyond the security program and sub-program plans, at the smallest context for a plan, is system security plan. The system security plan provides an overview of the security requirements of each system and describes the management, operational, and technical controls that are in place or are planned to be in place for meeting the security requirements. It should be viewed as the documentation for the structured process of planning adequate, cost-effective security protection for the system.

[click the above image to expand]

Standard

A standard is a formally-established, widely used rule or quantifiable specification across processes, actions, and configurations that must be adhered to. For the information security context, most standards have been developed by either international, national, industry, or government-backed groups for voluntary use, while some standards such as the HIPAA Security Rule and PCI Data Security Standard become mandatory based on the type of information being protected. Use of well-vetted standards can help accelerate an information security program, given their widely accepted use.

Control

Controls are the detailed safeguards designed to protect the confidentiality, integrity, and availability of information assets and to satisfy a set of defined security requirements. The defined security requirements are typically provided from sources such as the organizationalal business needs, laws, regulations, standards, and contractual obligations. The overall information security plan, the sub-program plans, and the individual system security plans together provide complete coverage for all security controls employed within the organization.

Procedure

Procedure is where all the higher-level designed taxonomy items culminate into actions being performed in support of the information security program. Procedures explain the required actions needed to support the plan and controls. Procedures, also called standard operating procedures (SOPs), are a comprehensive, repeatable, ordered series of actions for performing a task. This is where the true test of a security program’s effectiveness is determined. A security program can adopt the best framework, build well-scoped policies, and accurately identify risks, but if the actual procedures don’t exist or are not performed as required to support the program, to keep a known security posture, then incidents can begin to appear, which is the feedback loop for a weakened security program. That is why procedures also need to come with training: so that those responsible for performing the procedure can do so effectively, and that procedures are tested to validate their accuracy and ongoing effectiveness. An example of a procedure would be, “Development environments will be patched the first Sunday of each month, with staging environments patched the second Sunday, and production environments patched the third Sunday by the configuration management team with support from the system administration team”.

Guideline

Guidelines are a derivative of a standard and can sometimes be confused as a standard. Both standards and guidelines provide guidance, but guidelines lack the level of wide use and formality associated with standards. Guidelines are more generalized recommended practices for where a standard may not exist and allows use of one’s own judgement for interpreted implementation. Guidelines are recommended guidance but not mandatory like that of a standard. Guidelines work well in organizations if work is to be done by decentralized autonomous groups who cannot be compelled to comply with an enterprise standard. An example of a guideline would be “all passwords should be stored in a password manager to protect their confidentiality”.

Conclusion

Though the information security program landscape seems vast and deep with what needs to be accomplished, the term taxonomy isn’t all that complicated if you can see the interdependencies among the components that make the program run.

If you are interested in building or enhancing your information security program, then we are here to help you reach your goal.