Defensive Security Handbook

Chapter 4. Standards and Procedures

Standards and procedures are two sets of documentation that support the policies and bring them to life. In this chapter we will learn what standards and procedures are, how they relate to policies, and what they should contain.

If we consider the policies of an organization to be the “what” we are trying to achieve, standards and procedures form the “how.” As with policies, standards and procedures bring with them many advantages:

Consistency

Worries about the nuances of the implementation of policies at a technology level are removed and thus consistency applied. By having a written set of standards and procedures, the rules outlined in the policies can be applied equally across the organization.

Distribution of knowledge

As with policies, it is all well and good for you to know how to implement a policy in practice; however, if those elsewhere in the organization are unaware, then it is not providing much benefit. Standards and procedures disseminate this information for others to consume.

Setting expectations

Policies have already set the rules and boundaries. However, they do not provide the detail required to consistently achieve those goals in the same way every time. Standards and procedures do this.

Regulatory compliance

Many industries are regulated or pseudoregulated. A criterion common amongst nearly every regulatory compliance scheme is the existence of standards and procedures to accompany the policies. By having a set of standards and procedures, you have already ticked a box on the regulatory compliance checklist.

Management endorsement

A management-endorsed set of standards and procedures, as with policies, lends credibility to both the documentation set itself, and by extension the security team.

Standards

Standards provide the “how” portion to a policy at a technology viewpoint without specific procedural detail. For example, many policy statements include the requirement that access be authenticated by use of a password.

A standard that provides more detail as to what constitutes a password should accompany this policy statement. For example, it will most likely cover topics such as complexity requirements, the process for changing a password, storage requirements, ability to reuse passwords or otherwise, or any other related detail.

Separating this into two documents—three once we talk about procedures—provides several advantages:

Documents are easier to consume

A lightweight policy document is easier to navigate and less daunting to read than an all-encompassing policy document the size of a telephone directory.

Lack of repetition

Using the password example mentioned earlier, having to repeat the need to use complex passwords on each mention of password authentication in ancillary policies will become repetitive and leaves plenty of scope to introduce errors. This way the high-level policies can be read easily, and if further clarification is needed the reader can refer to the appropriate accompanying standard.

Ease of maintenance

Lack of repetition means that a change in the standard need only be applied in one place for consistent application across the organization. If standards were rolled into the policy documentation, changes would need to take into account all instances of the affected statements. Missing one of these statements could be catastrophic.

Language

As with policies, the language used within standards documentation should be fairly simple, clear, and use words like “do,” “will,” “must,” and “shall.” They should not be ambiguous or use words and phrases such as “should,” “try,” or “mostly.”

Unlike policies, however, standards can be more specific and detailed in their guidance. Although being specific about technologies in use, standards remain free of specific procedural detail such as commands. This will be explained when we get to procedures.

For example, in Chapter 3 we used the example:

A unique User ID shall be assigned to a user.

The accompanying standards documentation would typically include statements such as:

A User ID is created in the format <first 6 chars of surname><first 2 chars of firstname>, unless this User ID is already in use, in which case...

A User ID shall only be created after HR approval

A User ID shall only be created after Line Manager approval

HR must review and approve user access rights, ensuring that they align with the user’s role prior to the User ID being provisioned.

A record of User ID creation and associated sign-off will be kept in...

A one-way hash function shall be used for the storage of user passwords. Acceptable hashing algorithms are...

These statements enhance, support, and provide more detail to the associated policy statement.

Documents should be designed to be read. There is no need to fill documents with excessively wordy statements. Each policy statement can be only a few sentences, often only one, in a bullet point format.

Procedures

Procedures take the step made from policies to standards and makes another similarly sized step further along the same trajectory. 

Procedures take the detail from standards, which in turn offer guidance based on policies, and provide specific steps in order to achieve those standards at a technology level. This time, the documentation is not intended to describe what we, as an organization, are trying to achieve, but how this is to be implemented at a technology-specific level.

Language

Language is important once more, as ensuring that the desired configuration changes are applied consistently is the ultimate goal. Unlike policies and standards, however, the level of detail will probably depend on corporate culture. For example, it is more appropriate in some organizations to provide an almost keypress-by-keypress level of detail. In others, prescribing which configuration options to make is more appropriate and the administrators are trusted to make a judgment call on which editor they use to make such changes. In most environments the latter is typically sufficient.

Let’s revisit the last statement from the standards example, which was:

A one-way hash function shall be used for the storage of user passwords. Acceptable hashing algorithms are...

The procedure documentation should explain how this is achieved on a specific platform. Because technology platforms differ and procedures are technology-specific, it is entirely likely that there will need to be platform-specific documents created to account for differences between technologies.

For example, to implement platform-specific documentation about FreeBSD on a FreeBSD system, the procedures statement could be something like:

In order to configure system passwords to use the SHA512 hashing algorithm, edit /etc/login.conf, and amend the passwd_format field to read:

:passwd_format=sha512:\

Whereas on a Linux platform the guidance would be:

In order to configure system passwords to use the SHA512 hashing algorithm, execute the following command with root privileges:

authconfig --passalgo=sha512 --update

Both are systems that have a Unix heritage, and both routes ultimately achieve the same goal. However, the precise method at which the goal is reached is clearly articulated to ensure consistency of application across platforms and teams.

Document Contents

As with policies, documentation for standards and procedures should contain a few key features:

Revision control

At the very least, this should include a version number and an effective date for the document. This allows a user in possession of two versions of a document to quickly establish which version is current and which is out of date and no longer applicable.

Owner/Approver

Being clear as to who owns and approves any particular document is useful not only for demonstrating that it has been accepted and agreed upon by the appropriate level of management, but it also serves to facilitate feedback and suggestions for updates in future revisions.

Purpose/Overview

This provides a brief overview as to what the policy document covers. This is typically only a paragraph and is intended to allow the readers to gauge if they are looking at the correct policy document before they get to the point of reading every policy statement.

Scope

In all likelihood, the scope section will only be a couple of sentences and will be the same for most policy documents. This explains who the policy document applies to; for example, “This policy applies to all <Company Name> employees and affiliates.” Of course there could be policies that only apply to a particular subset of readers for some reason.

Policy statements

As discussed earlier, these are the guts of the document—the policies themselves.

Consistent naming convention

Consistent naming conventions not only for the documents themselves, but also for artifacts they reference, ensure that they are easy to understand and can be applied consistently across the organization.

Related documents

Cross references to other relevant documents such as standards, policies, and processes allow the reader to quickly locate related information.

For ease of reference during an audit, it is prudent to also include references to sections of any relevant regulatory compliance, standards, and legal requirements.

Conclusion

As a whole, policies, standards, and procedures offer a high-level administrative overview down to the specific technology and step-by-step implementation. While each has its own functions, they all must be written with the skill level of the reader in mind. A clear and concise set of documentation makes a huge difference in creating a standardized and well-understood environment.