- CPA to Cybersecurity
- Posts
- Policies, Standards and Procedures
Policies, Standards and Procedures
A Cybersecurity Primer with Examples
Steve McMichael
May 19, 2024
Policies, standards, and procedures are the foundation of any good cybersecurity program. But the terminology can be confusing, and it's not always clear how they fit together in practice. In this post, I'll explain what each of these things are, and how to use them effectively. I like to start with the CISSP body of knowledge definitions to get everyone on the same page.
Table of Contents
Policies: Setting the Tone
A security policy is a document that defines the scope of security needed by the organization and discusses the assets that require protection and the extent to which security solutions should to to provide necessary protection.
The security policy is used to assign responsibilities, define roles, specify audit requirements, outline enforcement processes, indicate compliance requirements, and define acceptable risk levels.
Policies are the foundation of any cybersecurity program and set tone at the top. They define the scope of security needed by the organization, discuss the assets that require protection, and outline the extent to which security solutions should go to provide that protection.
A well-crafted security policy assigns responsibilities, defines roles, specifies audit requirements, outlines enforcement processes, indicates compliance requirements, and defines acceptable risk levels. In plain language, policies answer the question: what are the cybersecurity-related expectations for employees?
For example, a policy might state that accounts exposed to the Internet must have Multi-Factor Authentication, not just passwords. Or that strictly confidential data, such as patient records, must be encrypted when exposed to the Internet.
Ideally, policies are clear on expectations, using "must" instead of "should." They need to be followed consistently to avoid being perceived as toothless. If a Security Operations Center (SOC) detects a risky, unauthorized activity by an employee, unclear policies with too much wiggle room can result in the SOC Analyst being accused of causing undue security friction.
It's also important to note that security policies shouldn't be aspirational. This creates the same wiggle room problem if interpreted as applying to some systems or teams and not others. It also causes audit deficiencies at compliance assessment time if you're found to not be doing what you say you do in the policy.
A balancing point here as we strive to both protect and enable the business, is to not make policies too heavy handed. I think the free SANS templates recommended by the Center for Internet Security do a great job at this. They’re also great at explaining to employees why they exist and are important, e.g. “not to impose restrictions that are contrary to <Company Name>’s established culture of openness, trust and integrity. <Company Name> is committed to protecting employees, partners and the company from illegal or damaging actions by individuals, either knowingly or unknowingly.”
Another great reference to study is the publicly available policies over at GitLab:
Standards: Defining the Requirements
Standards define compulsory requirements for the homogenous use of hardware, software, technology and security controls. They provide a course of action by which technology and procedures are uniformly implemented throughout an organization.
The example SANS Information Logging Standard below specifies that “systems shall ensure integrity to support enterprise-level analysis and reporting.” A common way to achieve this is to have an independent Security Information and Event Management (SIEM) system with least privilege access that is tamper-proof, so even if a hacker has compromised a system, they can't access SIEM logs to cover their tracks.
The Wireless Communication Standard template here is a other good example, listing specific, vendor agnostic requirements to harden their configurations to reduce attack surface and vulnerability to being compromised.
Procedures: The Step-by-Step Guide
Procedures are the final element of the formalized security policy structure. A procedure or standard operating procedure (SOP) is a detailed, step-by-step how-to document that describes the exact actions necessary to implement a specific security mechanism, control or solution.
Procedures are the lowest level. They're basically step-by-step instructions for implementing a specific control or solution. If a standard says that event logs have to be centralized, the procedure would explain exactly how to set that up on your systems.
One thing to consider with procedures is that you may want to record a screencast instead of writing out every detail. A screencast can be easier to follow, and quicker to create. Whichever format you choose, the key is to make the procedure detailed enough that anyone can follow it, even if they're not an expert.
Bottom-Line
So in summary: policies are high-level and set by executives, standards are more technical and detailed, and procedures are step-by-step instructions. You need all three to have an effective security program.
It's important to get these right, because they're the foundation everything else is built on. If you have clear, practical policies and standards, and detailed procedures for implementing them, you'll be well on your way to having a strong security posture. But if these things are unclear, inconsistent, or not well thought out, then your security program probably won't be very effective, no matter what else you do.
One final point: remember that all of these are living documents. You need to review and update them regularly as your organization and the threats you face evolve. Having a great policy doesn't help much if it's 10 years out of date and no longer reflects reality. But if you can keep them current, and make sure everyone understands and follows them, you'll be in good shape to protect and enable the business.