- CPA to Cybersecurity
- Posts
- Let's Demystify Cybersecurity Policies, Standards and Procedures
Let's Demystify Cybersecurity Policies, Standards and Procedures
What are they? Are Policies at the Top or Bottom of the Pyramid? How Many Are Needed?
Steve McMichael
September 12, 2024
Hi,
This outline of Cybersecurity Governance questions is for an upcoming discussion with Study GRC and the broader Simply Cyber community.
Do you have resources to add? 📚️
Opinions? 🗣️
Hot takes?! 🔥
Questions and feedback are welcome! Join the discussion at:
Simply Cyber Discord grc-team-life channel
See you there!
Steve
Contents
1. Why do Policies Matter?
Due diligence is establishing a plan, policy, and processes to protect the interests of the organization.
Due care is practising the individual activities that maintain the due diligence effort.
For example, due diligence is developing a formalized security structure containing a security policy, standards, baselines, guidelines, and procedures. Due care is the continued application of this security structure into the IT infrastructure of an organization.
In today’s business environment, prudence is mandatory. Showing due diligence and due care is the only way to disprove negligence and occurrence of loss. Senior management must show due care and due diligence to reduce their culpability and liability when a loss occurs.
2. đź“ś Definitions: Getting on the Same Song Sheet
2.1 CISSP Official Study Guide
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.
2.2 SANS
Policy Period Component | Definition |
|---|---|
Principle | The highest-level ideas and values that serve as reference points to guide organizational conduct |
Policy | High-level, mandatory statements used to define a course of action to govern enterprise behavior and address specific systems, methods or techniques |
Standard | Medium-level instructions that provide prescribed levels or criteria to follow when applying policies throughout an organization |
Guideline | Lower-level best practices designed to achieve policy objectives where factors may prevent rigid requirements |
Procedure | Individual, discrete steps employees follow when performing duties that are repeatable and operational |
Baseline | Most specific set of instructions or documents that contain configuration requirements |
2.3 GRC Masterclass
Policies
Policy is the will of the organization
Purpose
Scope
Policy content
Compliance
What happens if someone doesn’t comply?
Management support/sign-off
Standards
Standards are values assigned for certain aspects of organizational policy. How many days until passwords need to be changed? How many people allowed in the data center at any time?
An Identity and Access Management standard would include password security requirements for different types of accounts such as:
Length:
Minimum of X characters.
Complexity:
Include a mix of uppercase and lowercase letters, numbers, and special characters.
Ensure the presence of at least one character from each of these categories.
Avoiding Common Passwords:
Implement a denied password list (e.g. the ROCKU database of leaked passwords) to prevent the use of commonly used, weak, or easily guessable passwords.
Password History:
Prevent the reuse of the last 5-10 passwords to minimize the risk of credential stuffing attacks.
Expiration:
Set password expiration to at least every 90 days. However, consider longer periods if strong multi-factor authentication (MFA) is enforced and monitoring is robust.
Lockout Policy:
Implement account lockout after a specified number of failed login attempts (e.g., 5 attempts) to deter brute force attacks.
Define a lockout duration (e.g., 15 minutes) or require manual unlock by an administrator.
Multi-Factor Authentication (MFA):
Require MFA for all users, particularly for accessing sensitive systems or performing high-risk actions.
Use various forms of MFA, such as SMS-based OTP, authenticator apps, or hardware tokens.
Password Storage:
Ensure passwords are stored using strong, salted hash functions (e.g., bcrypt, Argon2).
Avoid reversible encryption for password storage.
Password Change Requirements:
Enforce password changes upon first login and after suspected compromise.
Allow users to change their passwords proactively through a secure self-service process.
Procedures
Procedures are how a process is supposed to be executed by an individual. When processes are done consistently, you can expect timely and quality execution. During incidents time is critical so good processes are important.
A recipe.
Documentation that outlines how a policy will be implemented.
How to do password resets
Admin console
Self-service portal
Help Desk identity verification process
“Hey I’m the CEO, change my password!”
Way more effective to record (e.g. with Loom) procedures than to write static documents that take a lot of effort to maintain - and rarely are maintained in practice.
2.4 NIST
Information Security Policy: Aggregate of directives, regulations, rules, and practices that prescribes how an organization manages, protects, and distributes information.
Security Policy: A set of criteria for the provision of security services. A set of rules that governs all aspects of security-relevant system and system component behavior
2.5 ISACA
ISACA defines an information security policy as a high-level, comprehensive document that outlines an organization's security objectives, rules, and the responsibilities for ensuring information security. Specifically, the COBIT 5 framework and ISACA's CISM Review Manual provide similar definitions:
An information security policy is:
A document that outlines the security management directives of an organization.
It is designed to ensure that information assets are adequately protected from threats and vulnerabilities.
It provides the guiding principles and expectations for managing and protecting information and is generally aligned with the organization's overall objectives.
It is typically approved by senior management and communicated to all relevant stakeholders.
A standard is a set of mandatory requirements or rules that specify the behavior or processes needed to meet a particular policy or objective. In COBIT 5, standards are described as:
Formalized rules or criteria that define what must be done to comply with policies.
Standards ensure uniformity and consistency in applying security measures across the organization.
They provide specific details on how policies are to be implemented and are typically more prescriptive than policies themselves.
2.6 ISO27001
Clause 5.2 requires organizations to establish an information security policy that:
Is appropriate to the organization's purpose.
Includes objectives related to information security.
Provides a framework for setting information security objectives.
Includes commitments to meet applicable requirements and continuous improvement of the ISMS.
Is communicated within the organization and available to relevant interested parties.
3. ▲🔄 Are Policies at the Top of the Pyramid or the Bottom?
3.1 Seven Security Group Says Top
3.2 SANS Agrees
3.3 GRC Masterclass Says Bottom
Policies are at the bottom of the pyramid, providing the base foundation of expected behaviour
Then on top of that foundation, standards and procedures illustrate how the policy should be implemented
3.4 Compliance Forge Agrees
3.5 Bottom-Line Both Pyramids Are Correct
By importance, policies are the bottom of the pyramid
By volume, they are academically the top
More systems, people and processes with standards and procedures
Although, in practice it would be a big time investment to maintain lots of standard and procedure documents
4. 🤔 Which Policies and Standards, and How Many?
4.1 GRC Masterclass Guidance
Generally the number of policies ranges from 1 for a small company to 20 with one per SP800-53 control family
4.2 SANS Guidance
Page 7
Security Awareness at the core, then:
Asset Identification & Classification
Asset Protection
Asset Management
Acceptable Use
Vulnerability Assessment & Management
Threat Assessment & Monitoring
Business Continuity & DRP
Physical Security
1. Asset Identification & Classification
Control Family: PL - Planning and CM - Configuration Management
PL-8: Information Security Architecture refers to the identification of assets and their role in the organization's information security posture.
CM-8: Information System Component Inventory focuses on maintaining an inventory of system assets and ensuring they are classified and tracked.
2. Asset Protection
Control Family: MP - Media Protection and SC - System and Communications Protection
MP-2: Media Access protects the access to organizational assets (information systems, data).
SC-28: Protection of Information at Rest covers the measures taken to protect data in storage and assets across systems.
3. Asset Management
Control Family: CM - Configuration Management and PM - Program Management
CM-8: Information System Component Inventory addresses the management of assets and ensuring they are identified and tracked.
PM-5: Information Security Resources ensures appropriate resources are allocated for managing assets.
4. Acceptable Use
Control Family: AC - Access Control and AT - Awareness and Training
AC-1: Access Control Policy focuses on ensuring users understand the acceptable use of information systems.
AT-2: Security Awareness Training includes educating users on acceptable use policies and their responsibilities.
5. Vulnerability Assessment & Management
Control Family: RA - Risk Assessment and SI - System and Information Integrity
RA-5: Vulnerability Monitoring and Scanning covers processes to identify and assess vulnerabilities.
SI-2: Flaw Remediation addresses vulnerability remediation and continuous system updates.
6. Threat Assessment & Monitoring
Control Family: CA - Security Assessment and Authorization and SI - System and Information Integrity
CA-7: Continuous Monitoring ensures threats are continuously monitored and risk is evaluated.
SI-4: Information System Monitoring handles monitoring system activities to detect and respond to threats.
7. Business Continuity & Disaster Recovery Plan (DRP)
Control Family: CP - Contingency Planning
CP-1: Contingency Planning Policy and Procedures cover the policies that guide business continuity and disaster recovery.
CP-9: System Backup ensures proper backup mechanisms for recovery in case of failure.
8. Physical Security
Control Family: PE - Physical and Environmental Protection
PE-3: Physical Access Control addresses the physical security of facilities and systems.
PE-2: Physical Access Authorizations deals with policies to limit physical access to systems and assets.
4.3 IS5540
4.4 SOC2
Not big on documeted policies as long as you’re performing the controls.
The SOC 2 (System and Organization Controls) Trust Services Criteria are designed to assess the controls an organization has in place regarding security, availability, processing integrity, confidentiality, and privacy. These criteria outline key cybersecurity policies that organizations need to implement. Here are the key policies aligned with the SOC 2 Trust Services Criteria:
1. Information Security Policy
SOC 2 Criteria: Common Criteria (CC1.1), Security (CC6.1)
Purpose: Establishes the overall approach to information security management within the organization.
Content: Defines the organization's security objectives and commitment to protect sensitive data.
2. Access Control Policy
SOC 2 Criteria: CC6.2, CC6.3, CC6.4
Purpose: Controls access to systems and data based on the principle of least privilege.
Content: Outlines authentication methods, authorization levels, and management of user access.
3. Risk Management Policy
SOC 2 Criteria: CC3.1, CC3.2
Purpose: Guides the identification, assessment, and mitigation of risks related to information security.
Content: Describes risk assessment methodologies and how risks are prioritized and treated.
4. Incident Response Policy
SOC 2 Criteria: CC7.4
Purpose: Ensures a structured response to security incidents.
Content: Outlines procedures for detecting, responding to, and recovering from security incidents.
5. Data Encryption Policy (Operational Controls?)
SOC 2 Criteria: CC6.8
Purpose: Defines the use of encryption to protect data in transit and at rest.
Content: Specifies encryption standards and methods for safeguarding sensitive information.
6. Business Continuity and Disaster Recovery Policy
SOC 2 Criteria: CC9.2
Purpose: Ensures that critical business functions can continue during and after a disruptive event.
Content: Describes backup procedures, recovery timelines, and disaster recovery processes.
7. Vendor Management Policy
SOC 2 Criteria: CC3.3, CC9.2
Purpose: Manages third-party risk by ensuring vendors comply with security requirements.
Content: Includes due diligence processes, ongoing monitoring, and contractual security requirements for vendors.
8. Change Management Policy
SOC 2 Criteria: CC8.1
Purpose: Ensures that changes to systems, applications, and processes are controlled and do not negatively impact security.
Content: Describes procedures for requesting, reviewing, approving, and implementing changes.
9. Monitoring and Logging Policy (Operational Controls?)
SOC 2 Criteria: CC7.1, CC7.2
Purpose: Monitors security events and logs system activities for security-related insights.
Content: Outlines logging requirements, retention policies, and procedures for monitoring security threats.
10. Human Resources Security Policy
SOC 2 Criteria: CC5.1, CC5.2
Purpose: Manages security during hiring, employment, and termination.
Content: Includes background checks, security training, and termination procedures to ensure ongoing compliance with security requirements.
11. Data Retention and Disposal Policy
SOC 2 Criteria: CC8.1, CC8.2
Purpose: Ensures that data is stored and destroyed securely according to the organization’s data retention guidelines.
Content: Specifies how long data is retained, where it is stored, and how it is securely destroyed.
12. Confidentiality Policy (Access Control?)
SOC 2 Criteria: Confidentiality (C1.1)
Purpose: Protects sensitive information from unauthorized access or disclosure.
Content: Defines what constitutes confidential information and how it should be handled and stored.
13. Privacy Policy
SOC 2 Criteria: Privacy (P1.1)
Purpose: Establishes guidelines for handling personal data in compliance with privacy regulations.
Content: Describes how personal information is collected, used, and protected, along with user rights to access, correct, and delete their data.
14. System Availability Policy (DR/BC Policy?)
SOC 2 Criteria: Availability (A1.2)
Purpose: Ensures that systems are available to users as per contractual or service level agreements (SLAs).
Content: Includes processes for uptime monitoring, system redundancy, and capacity planning.
15. Password and Authentication Policy (Access Control)
SOC 2 Criteria: CC6.2
Purpose: Protects access to systems through strong password policies and multi-factor authentication.
Content: Defines password complexity, rotation schedules, and authentication methods like multi-factor authentication (MFA).
These policies are essential for aligning with the SOC 2 Trust Services Criteria and ensuring that an organization's information security practices are robust, effective, and trustworthy.
4.5 ISO27001
Requires policies for the control domains, and defines the requirement for establishing and maintaining information security policies, but I don’t think it has a pyramid.
Policy Name | ISO 27001 Clause/Annex A Control |
Information Security Policy | Clause 5.2, Annex A.5 |
Risk Management Policy | Clause 6.1, Annex A.8 |
Access Control Policy | Annex A.9 |
Incident Management Policy | Annex A.16 |
Business Continuity and Disaster Recovery Policy | Clause 6.3, Annex A.17 |
Physical Security Policy | Annex A.11 |
Asset Management Policy | Annex A.8 |
Supplier Security Policy | Annex A.15 |
Cryptographic Controls Policy | Annex A.10 |
Human Resources Security Policy | Annex A.7 |
Acceptable Use Policy | Annex A.9 |
Data Classification and Handling Policy | Annex A.8 |
Compliance Policy | Clause 4.2, Annex A.18 |
Change Management Policy | Annex A.12 |
Network Security Policy | Annex A.13 |
To comply with ISO 27001, an organization needs to establish several key policies that form the foundation of an Information Security Management System (ISMS). These policies guide the implementation, operation, monitoring, and continual improvement of information security. Below are the essential policies required for ISO 27001 certification:
1. Information Security Policy
Purpose: Establishes the overall approach to managing information security.
Content: Includes the organization’s objectives, security goals, and management's commitment to ensuring confidentiality, integrity, and availability of information.
2. Risk Management Policy
Purpose: Guides how the organization identifies, assesses, and mitigates risks.
Content: Specifies risk assessment methodologies, risk appetite, and risk treatment options, ensuring that risks are continuously monitored and managed.
3. Access Control Policy
Purpose: Ensures proper access to information systems and data.
Content: Defines rules for user access management, user responsibilities, and privileged access controls to protect information from unauthorized access.
4. Incident Management Policy
Purpose: Outlines the process for identifying, reporting, and managing security incidents.
Content: Includes procedures for incident detection, response, escalation, and remediation.
5. Business Continuity and Disaster Recovery Policy
Purpose: Ensures that critical business functions are maintained in the event of an incident.
Content: Covers plans for disaster recovery, backup processes, and procedures to resume operations during and after a disruption.
6. Physical Security Policy
Purpose: Protects physical assets such as buildings, hardware, and other infrastructure.
Content: Specifies controls to limit physical access to sensitive areas, use of security guards, surveillance, and protection from environmental risks (fire, floods, etc.).
7. Asset Management Policy
Purpose: Ensures proper management of all company assets (physical and digital).
Content: Covers identification, classification, ownership, and protection of assets, ensuring they are used and managed securely.
8. Supplier Security Policy
Purpose: Ensures that third-party suppliers and partners comply with information security standards.
Content: Specifies the security requirements for suppliers, ensuring their processes align with the organization’s information security policies.
9. Cryptographic Controls Policy
Purpose: Manages the use of cryptographic techniques for data protection.
Content: Defines how encryption should be applied to protect sensitive information, both in transit and at rest.
10. Human Resources Security Policy
Purpose: Manages security during hiring, employment, and termination processes.
Content: Includes procedures for employee background checks, confidentiality agreements, and ongoing security awareness training.
11. Acceptable Use Policy
Purpose: Establishes guidelines for the appropriate use of company resources (like IT systems, networks, etc.).
Content: Defines acceptable and prohibited activities for employees when using the organization’s systems and devices.
12. Data Classification and Handling Policy
Purpose: Ensures that information is appropriately classified and handled based on its sensitivity.
Content: Defines the categories for classifying data (e.g., public, internal, confidential) and the rules for handling, storing, and transmitting each category.
13. Compliance Policy
Purpose: Ensures the organization meets legal, regulatory, and contractual security requirements.
Content: Outlines compliance responsibilities and ensures regular audits to confirm adherence to relevant laws and regulations.
14. Change Management Policy
Purpose: Manages changes to IT systems and processes without compromising security.
Content: Defines procedures for requesting, approving, and documenting changes to the organization's information systems.
15. Network Security Policy
Purpose: Protects the organization’s network infrastructure.
Content: Includes guidelines for managing firewalls, VPNs, and network access controls to ensure network security.
5. đź“ť What are the Best Templates and Examples?
5.1 SANS (Policy Heavy - what about Standards?)
Center for Internet Security Links to SANS
Policy Heavy - What about Standards? Procedures
Policy
Acceptable Encryption Policy
Acceptable Use Policy
Acquisition Assessment Policy
Analog/ISDN Line Security Policy
Artificial Intelligence Policy
Automatically Forwarded Email Policy
Bluetooth Baseline Requirements Policy
Communications Equipment Policy
Data Breach Response Policy
Database Credentials Policy
Dial In Access Policy
Digital Signature Acceptance Policy
Disaster Recovery Plan Policy
DMZ Lab Security Policy
Email Policy
Email Retention Policy
Employee Internet Use Monitoring and Filtering Policy
Ethics Policy
Extranet Policy
Internet DMZ Equipment Policy
Internet Usage Policy
Lab Anti Virus Policy
Lab Security Policy
Mobile Device Encryption Policy
Mobile Employee Endpoint Responsibility Policy
Pandemic Response Planning Policy
Password Protection Policy
Personal Communication Devices and Voicemail Policy
Remote Access Policy
Remote Access Tools Policy
Removable Media Policy
Risk Assessment Policy
Router and Switch Security Policy
Security Response Plan Policy
Server Audit Policy
Server Malware Protection Policy
Server Security Policy
Social Engineering Awareness Policy
Software Installation Policy
Technology Equipment Disposal Policy
Virtual Private Network Policy
Web Application Security Policy
Wireless Communication Policy
Workstation Security (For HIPAA) Policy
Standard
Information Logging Standard
Wireless Communication Standard
Guideline
Anti-Virus Guidelines
Password Construction Guidelines
Procedure
Cyber Security Incident Communication Log
Cyber Security Incident Form Checklist
Cyber Security Incident Initial System Triage
Cyber Security Incident Recovery
End User Encryption Key Protection Plan
Incident Handling - Chain Of Custody Form
Incident Handling Forms - Cyber Security Incident Containment
Incident Handling Forms - Cyber Security Incident Response Contact Details
Incident Handling Forms - Cyber Security Incident Response Incident Summary
Intellectual Property Incident Handling Forms - Incident Communication Log
Intellectual Property Incident Handling Forms - Incident Contact List
Intellectual Property Incident Handling Forms - Incident Containment
Intellectual Property Incident Handling Forms - Incident Form Checklist
Intellectual Property Incident Handling Forms - Incident Identification
Intellectual Property Incident Handling Forms - Incident Recovery
Remote Access Mobile Computing Storage