Cybersecurity Policies Made Easy
People often ask for advice regarding information security or cybersecurity policies. For the remainder of this article, I will use cybersecurity and information security interchangeably. Nearly always it is a loaded question, exactly what do they mean by policy? Cybersecurity documentation for organizations comes in many levels and is influenced by a number of internal and external sources. Within an organization, there may be four levels of cybersecurity documentation. I use the word documentation to encompass all four levels of documentation within an organization that direct staff, contractors, and others on approved activities.
Cybersecurity documentation can be confusing. What adds to the confusion is the inconsistent use of terminology and different synonymous terms for policies between organizations. To help dispel the confusion, I would like to divide internal information security documentation into four groups and define each group to help aid in eliminating much of the confusion that exists. I want to start with internal documentation and conclude with external documentation that may influence the content of cybersecurity documentation.
I should note that as an auditor, I look to see that certain practices are documented and that the documentation is at a level of authority appropriate to it. You can divide documentation into smaller polices or have one large policy. You can call them administrative directives, policies, SOP, procedures, standards, practices, or something else. This is an organizational preference and many organization like to be creative in everything from job titles to labeling documentation. No matter how they are arranged or divided, certain things should be documented, communicated to staff, and most importantly easy to find by staff.
Policy, Standard, Guideline, Procedure
Policies
At the highest level, policies are documented instructions for staff to follow and endorsed by senior management. Typically, these are written at a high level and succinct. That is, they are broad, brief, and clear. They should be viewed by staff as mandatory without exception. They contain high-level statements that influence more detailed documents, or step-by-step, for lower level documents. Some may feel that policies are too broad and unspecific, but that is by design. Management needs to have broad policy statements that can be applied to different scenarios, systems, situations, and technologies within the organization.
Of course, this means that if an organization is smaller the breadth of scenarios, systems, situations, and technologies within the organization may also be smaller and require less documentation than that of a larger enterprise-level organization. Yes, that does mean that policies are not one-size-fits-all and need to be tailored to the individual organization.
There are at least three subdivisions of policies that align with the now-retired National Institute of Standards and Technology, Special Publication (NIST SP) 800-14, enterprise information security policies, issue-specific security policies, system-specific security policies. These subdivisions should be self-explanatory, but it is worth it to review them. Enterprise information security policies are organization-wide policies. This policy would be the most general and broadest of all the policies. Next, the issue-specific policies would include documentation, such as an incident response policy, business continuity policy, and breach disclosure policy. The names of the policies give away the specific issues they cover. Finally, system-specific policies would include policies for a specific system.
One note on the term system or information system as used in NIST documentation. The Committee on National Security Systems (CNSS) Instruction No. 4009 defines an Information System as “Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information.” As you can see from the definition it is an extremely broad definition encompassing people, processes, and technology. In this definition, a typing pool, file cabinet, satellite, and supercomputer are all information systems under this definition.
Internal Standards
The next level below policies is standards. Standards are more detailed statements that support and expand the policy statements. Generally, these should be viewed as compulsory for staff. Standard will be detailed requirements for staff that are in alignment and compliance with the policies of the organization. Whereas a policy may state that an organization will have “strong authentication mechanisms” the standard would require that “users shall use a complex password consisting of 8 alpha-numeric characters, at least one special character, one number, one lower case letter and one upper case letter.”
Internal Guidelines
The next level below a standard is a guideline. The idea of a guideline is that it is nonmandatory. In other words, it is a good idea to follow the practice, but it is not compulsory for staff to follow. View them as recommendations. In the same example, a guideline might recommend “users can use a sentence with special characters to make a complex password but should not use a pet’s name in the password.”
Now you might be wondering if it is more efficient to combine guidelines and standards into one document. I often see alongside the standards statements that are noncompulsory recommendations. This makes it easy for staff to navigate and find the information they need in order to perform their job functions. In fact, most organizations combine the two without really differentiating standards from guidelines. They have recommendations scattered throughout their documentation.
Some may argue that it is not necessary to have recommendations or guidelines and simply stick with policies and standards. However, this is shortsighted and will hinder ingenuity and the organization’s ability to adapt to changing situations. It makes the organization more rigid and less dynamic. Without the ability to change as needed the organization may not be able to adapt quickly enough for the organization to complete its mission. Often ridged organizations lose sight of their mission, the why of their existence, become bureaucratic, and blindly follow rules that, over time, have become opposed to the organization's mission and objectives.
Procedures
At the lowest level are the procedures. Procedures, simply put, are the step-by-step instructions for staff. Procedures will change regularly. As systems change the step necessary to complete a function will change resulting in a procedure that no longer works. This should prompt a change.
It goes without saying that the more detailed and granular the procedure the more often it may need to be changed. Especially if the procedure tells a user to “checkbox A on tab Y” and a recent software upgrade changed “box A” to a “drop down on tab X”.
The goal of the procedure is to have consistent processes. Processes that are known to produce desired outcomes. From the viewpoint of quality assurance, it is one of the controls that help reduce the risk of misconfiguration.
Typical implementation
As an auditor for local governments, I find that most organizations have policies or procedures and incorporate standards and guidelines into the policies or procedures. Many of them only have policies with limited procedures. An organization does not need to have the four levels and sublevels I outlined, however, they should have equivalent documentation.
External Influences
There are a number of external factors and sources that will influence some organization’s policies, standards, guidelines, and procedures. For example, an organization may have external influences that will drive the requirements for cybersecurity documentation such as risk assessments, threats, laws, regulations, directives, contractual requirements, industry standards, industry guidelines, and industry best practices.
For government, and especially the Federal government, other levels of government may have directives that apply to an organization. It is important to document all the external requirements to ensure the organization is covering all aspects required. For Federal Agencies external requirements are required to be documented in a system’s System Security Plan (SSP). NIST SP 800-18 is a guideline for SSPs. The purpose of a SSP is to document proposed and implemented controls on a given system. It also documents system responsibilities, data classification, and external requirements.
One note on industry standards and guidelines, or collectively, industry best practices. Often organizations view them as optional, but in reality, they are the minimum bar for organizations. Due care and due diligence requires organizations to be in step with industry best practices. Consider this, if you were to sit on the witness stand in court, how would you explain why you did not do X that leads to a data breach when the rest of the world is doing X? If you don’t have a strong answer or one that will sway a jury or judge, it is advisable to be in alignment with industry best practices such as those outlined by NIST, International Standards Organization (ISO), or other industry organization.
In a previous post I gave an example of a generally high-level bare-bones cybersecurity policy, and in a future post, I will give a list of required items to cover in your policies. In the example policy (in a previous post), you will notice the policy points to NIST Special Publication for the organization's standards and guidelines. This help reduces the work of reinventing the wheel. Use industry standards and guidelines as the organization’s internal standards and guidelines. You will ensure due diligence and reduce the cost of cybersecurity activities.
