Standards, sections, requirements
Standards are, broadly, compliance frameworks, regulations, or industry best practices; standards can be used interchangeably with the synonymous term frameworks.
Examples of standards include: HIPAA, ISO 27001, PCI-DSS, FedRAMP, NIST CSF, CIS Benchmarks, etc.
A standard is a collection of requirements grouped by sections, or a collection of controls grouped by domains.
Sections can be considered as parts or components of a standard.
Examples of sections include: HIPAA Physical Safeguards (§164.310), ISO 27001 Clause 6, PCI-DSS Requirement 8, the Access Control (AC) Family within FedRAMP, CIS Basics 2. Inventory of Software Assets, etc.
A standard has one or more sections; a section has one or more requirements.
Requirements make up sections of a standard. Individual requirements outline the specification that needs to be met.
Examples of requirements include: HIPAA §164.310(a)(1)(i), ISO 27001 6.1.3 a, PCI-DSS 8.4.b, FedRAMP AC-2 (7), utilizing application whitelisting to implement CIS Basics 2.7, etc..
When thinking through different regulatory or compliance standards/frameworks, the idea of a standard having one or more sections, which have one or more requirements is equivalent to a framework having one or more domains, which have one or more controls.
Policies, procedures, controls, control policies/configurations, vendors
You can think of an organization’s policies, procedures, and controls to loosely align to the compliance or regulatory standards, sections, and requirements.
Another way of looking at it would be: policies + procedures reflect you organization's internal view of how to run security, which is demonstrated to external stakeholders via the compliance implementation of standards/sections/requirements or framework/domains/controls.
At JupiterOne, we have an internal framework of controls. How we do security is reflected in our policies + procedures within the Policies app. Policies map to domains, procedures map to controls. Conversely, those same internal JupiterOne policies, procedures, and controls satisfy external regulatory/compliance standards, sections, and requirements in the Compliance app.
Policies are high-level statements of management intent; they are written security documents which frequently satisfy external requirements.
Examples of policies include: access management policies, data protection policies, human resource policies.
Policies are implemented by procedures.
Procedures are written security documents which describe how to implement policies via technology or processes, or a combination of the two; the ‘who’, ‘what’, ‘when’, ‘how’, etc; they can be thought of as control or process descriptions.
Examples of procedures (aka control/process descriptions) include:
- password management
- protecting data at rest
- employee screening
Policies are implemented by procedures; controls implement procedures.
Controls are the technical, administrative, and physical safeguards that enforce the procedures; they can manifest commonly as a process managed by a person/team or as a product/service provided by a vendor.
Examples of controls include:
- user identity management, access control, multi-factor authentication
- data encryption at rest or in transit
- penetration testing, code scanning
- pre-employment background checks.
Configurationenforces or manages a
Control Policies or configurations are the technical settings whereby controls are implemented.
Examples of control policies or configurations include:
- requiring 12+ characters including a number + a symbol for all passwords
- using AES-256 cipher for encryption at rest
- for background checks, specifically include searches for federal, criminal, state, county, city, financial, and education verification
Vendors provide controls.
Vendors are frequently companies, organizations, or people that provide the controls
Examples of vendors include:
- Microsoft (the Vendor) for Active Directory (AD), user authentication, and access control
- Amazon Web Services (AWS, the Vendor) for Key Management Service (KMS)
- Checkr (the Vendor) for background screens
Policies are implemented by procedures; controls implement procedures. A controlPolicy or configuration enforces or manages a control.
Policies are implemented by procedures; controls implement procedures. Vendors provide controls.