Security Procedures – How Do They Fit Into My Overall Security Documentation Library?

I’ve written previously about the importance of security policies and provided some basic principles for developing solid security policies. This blog post builds upon the foundation of security policies and discusses the importance of security procedures and how they fit into your overall security documentation library. Below are a few principles to keep in mind of when drafting (or reviewing existing) security procedures.

What are Security Procedures?

Security procedures are detailed step-by-step instructions on how to implement, enable, or enforce security controls as enumerated from your organization’s security policies. Security procedures should cover the multitude of hardware and software components supporting your business processes as well as any security related business processes themselves (e.g. onboarding of a new employee and assignment of access privileges).

The Purpose of Security Procedures & Why They’re Needed in an Organization

The purpose of security procedures is to ensure consistency in the implementation of a security control or execution of a security relevant business process. They are to be followed each time the control needs to be implemented or the security relevant business process followed. Here is an analogy. As part of every aircraft flight, the pilot will follow a pre-flight checklist. Why do they do this? Simply put, they do it to ensure that the aircraft is ready to fly and to do everything possible to ensure a safe flight. Although pilots may have flown thousands of hours, they still follow the checklist. Following the checklist ensures consistency of behavior each and every time. Even though they may have executed the checklist hundreds of times, there is risk in relying on memory to execute the checklist as there could be some distraction that causes them to forget or overlook a critical step.

Much like pre-flight checklists, security procedures guide the individual executing the procedure to an expected outcome. One example is server hardening. Even though a system administrator has built and hardened hundreds of servers, the procedure to harden the server still needs to be followed to ensure the server is hardened correctly and to a level that still allows operability with the system of which it is a part. If the hardening procedure is not followed, the system administrator could leave out a step that results in an unacceptable exposure of the server or data (e.g., leaving unneeded ports open on the server or the permissions on a directory open to unauthorized users). The best option would be to automate the hardening procedure through scripts or other automation tools (e.g. Puppet or Chef). This will ensure the consistent execution of the hardening “procedure.”

What is the Relationship Between Security Policies and Security Procedures?

1. Security procedures build upon your organization’s security policies. Your organization’s security policies are the foundation of its security program. An important principle of security policies is that they focus on guiding behavior. Like security policies, security procedures also focus on guiding behavior. While security policies address the who, what, and why, security procedures inform individuals in your organization of the when (e.g. daily, monthly, upon a certain trigger), where, and how relating to security. To help focus the security procedures within your organization, standards and baselines should also be defined. Standards and baselines are directed at the technology implemented in an organization, whereas policies and procedures focus on guiding behaviors. As depicted below, think of the relationship between policies, standards, baselines, and procedures like a triangle with security policies as the base or foundation:

The following is an example of how security procedures build upon or enable security policy. Your organization has defined a policy (who, what, and why) regarding the creation of backups for critical information. The supporting security procedure should define when the backups are executed, to what location and medium the backups are written, and how the individual steps to execute the backup are performed. Whether dealing with specific technology or a security-relevant business process, write a procedure for all areas where repeatable and consistent application or enforcement of controls is needed. Remember, procedures are meant to guide an individual’s behavior to obtain a certain and desired end result.

2. Security Procedures should contain sufficient detail to be executable. Security policies outline security needs in a general or high-level fashion. Security procedures, on the other hand, must provide sufficient detail that an individual who is not familiar (or mildly familiar) with the process or technology can successfully reach the desired outcome for the procedure. Many organizations have those one or two superstar tech geniuses who know how to do everything. While it is good to have such talent on your staff, it ultimately represents a risk to your organization if security procedures are not put in place. What would be the response if your superstar is out on vacation when his or her knowledge of how to do something is suddenly needed? Avoid such circumstances by developing security procedures to define the how, where and when things get accomplished. Beware to avoid developing procedures that rely on expert knowledge as a foundation to execute the procedure, doing so often results in gaps in the procedure. A good test for the level of detail for your procedure is to have some of your more junior staff execute the procedure. If they can do it cleanly, then there is likely sufficient detail to your procedure. If not, provide additional detail to your procedure. Also, make sure everyone who may execute the procedure has the proper access/permissions.

Why Is It Important To Keep Security Procedures Current?

Just as security policies should be reviewed and updated on a regular basis, security procedures need the same care and feeding. For those procedures that are executed on a regular basis (e.g. daily or monthly), the review should occur as part of the execution of the procedure. Just make sure any updates are made in a timely manner. For procedures that are executed on a less frequent basis (e.g. on a specific trigger like a disaster or incident) these procedures need to be reviewed and exercised at a minimum of once per year or as part of the “post-mortem” activities of an actual disaster or incident. Technological changes in your organization will drive the need to update your procedures, and new procedures should be created as part of the overall implementation plan for the new technology. Maintaining current security procedures will ensure safeguard your organization against inadvertent actions or other errors regarding the implementation of security controls, especially in stressful situations or time crunches.

Summary

Security policies and procedures are a critical component of an organization’s overall security program. With defined security policies, individuals will understand the who, what, and why regarding their organization’s security program, but without the accompanying security procedures, the actual implementation or consistent application of the security policies will suffer. Linford and Company has extensive experience writing security policies and procedures. If you would like to learn more about how Linford and Company can assist your organization in defining security policies and procedures or other services such as FedRAMP, HITRUST, SOC 1 or SOC 2 audits, please contact us.