Key Words:

• Authoritative Source (AS). This refers to a reliable primary source, based on its widely-recognized authority or authenticity (e.g., law, regulation or industry-recognized framework).

• Distinct Control Statements (DCS). This refers to a cybersecurity or privacy control citation that contains, at a minimum:

  • Control number;

  • Control name;

  • Control statement; and

  • Mapping to authoritative sources.

• Governance, Risk & Compliance (GRC) This refers to a specific function within a cybersecurity and/or privacy program that primarily addresses governance, risk and compliance operations. This is also sometimes referred to as Integrated Risk Management (IRM). GRC can also refer to specialized solutions that help automate process flows and documentation management.

• Minimum Security Requirements (MSR). This refers to a customized set of cybersecurity and privacy controls that addresses the organization’s minimum requirements needed to be both secure and compliant. MSR is defined through a combination of:

  • Minimum Compliance Criteria (MCC) are the absolute minimum requirements that must be addressed to comply with applicable laws, regulations and contracts. MCC focus on compliance requirements; and

  • Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond” MCC, where the organization self-identifies additional cybersecurity and data protection controls to address voluntary industry practices or internal requirements, such as findings from internal audits or risk assessments.

• Secure Controls Framework (SCF). The SCF is a flat-file database (e.g., spreadsheet) that contains a comprehensive listing of over 1,000 cybersecurity and privacy controls that is categorized into thirty-three (33) domains that are mapped to over 100 statutory, regulatory and contractual frameworks. It is also available in JSON Data Format leveraging OSCAL concepts on GitHub for the purpose of automation. The SCF is available at https://www.securecontrolsframework.com under a Creative Commons license.

• Security & Privacy Capability Maturity Model (SP-CMM). This refers to a component of the SCF that establishes an approach to defining increasing levels of process maturity, based on the degree of formality and process definition for both cybersecurity and privacy concerns.

• Security & Privacy Risk Management Model (SP-RMM). This refers to a component of the SCF that establishes an approach to identifying, calculating and managing risk. The SP-RMM contains both a risk catalog and threat catalog.

• Object Owner. This field refers to the owner of the parent object. This field contains the owner and optional email address of the person responsible for management of the object. Delimiters are employed to separate multiple owners.

• Object Owner Role. This field refers to the owner role(s) of the parent object. This field captures the corresponding NIST NICE role. Delimiters are employed to separate multiple roles.

 

Abstract:

The Integrated Controls Management (ICM) Schema is a schema that creates a scalable, hierarchical model to establish both human and machine-readable cybersecurity and privacy-related documentation. The invention provides Governance, Risk and Compliance (GRC) solutions, and similar technologies, with a machine-readable set of comprehensive and hierarchical cybersecurity and privacy documentation for their specialized, commercial applications, geared towards efficiently managing cybersecurity and privacy-related documentation and processes. When a GRC solution, or similar technology, parses this machine-readable content (e.g., XML, JSON, YAML, etc.), it can populate its clients’ GRC instances with human-readable documentation that is uniquely-specific to an organization, while also enabling machine-readable queries to support audit/assessment-related activities.

​

The ICM Schema builds upon the concepts established by:

• Hierarchical Cybersecurity & Privacy Governance, Risk & Compliance (HCP-GRC) Schema;

• Method for Establishing and Managing Cybersecurity and Privacy Controls;

• ComplianceForge’s Hierarchical Cybersecurity Governance Framework™ that provides reference model for mapping between policies, control objectives, standards, guidelines, controls, risks, threats, procedures and metrics, which was first published in 2013 as the “Information Security Documentation Terminology Overview”;

• Secure Controls Framework (SCF) control structure;

• SCF Security & Privacy Capability Maturity Model (SP-CMM);

• SCF Security & Privacy Risk Management Model (SP-RMM); 

• National Institute of Standards and Technology (NIST) Open Security Controls Assessment Language (OSCAL) project, which is as a standardized, controls-centric framework; and

• NIST NICE Workforce Framework for Cybersecurity, which standardizes roles and responsibilities within a cybersecurity program.

 

Problem Statement:

Adherence to cybersecurity and privacy-related laws, regulations and industry-recognized practices is the expectation for organizations throughout the world. Control deficiencies with cybersecurity and privacy requirements hurt not just the organizations in scope for those obligations, but often clients and third-parties, exposing all to legal risk and financial loss. Having a hierarchical, scalable approach to governing policies, control objectives, standards, guidelines, controls, risks, threats, procedures and corresponding metrics is an essential component to both enable secure practices and maintain compliance with applicable cybersecurity and privacy obligations.

 

Trust is based on integrity and an organization cannot achieve technology integrity without secure systems, applications and processes. Defining and managing cybersecurity and privacy controls are fundamental requirements for an organization to have secure processes for how people, systems, services and applications store, process and transmit data. A common issue among organizations, regardless of the industry, is obtaining a set of clear, concise cybersecurity and privacy controls that address an organization’s unique statutory, regulatory, contractual and other requirements. Controls serve as the nexus within an organization’s cybersecurity and privacy documentation, where those controls directly tie into and support other forms of documents (e.g., policies, standards, procedures, metrics, etc.).

 

Known Solutions & Drawbacks:

Traditional methods of creating and maintaining documentation components of a cybersecurity and privacy program is to generate the documentation in human-readable format (e.g., Microsoft Word or Excel documents):

• Policies, Control Objectives, Standards & Guidelines - These documents are designed to be centrally-managed and unified in a homogenous document or set of documents (one per policy domain) that contains policies, control objectives, standards and guidelines.

• Procedures - Procedures are decentralized and exist at the individual contributor / team levels, often as a Standardized Operating Procedures (SOP) document.

• Controls - Controls often exist within a stand-alone controls catalog and are represented in human readable documentation form (e.g., NIST SP 800-53, NIST SP 800-171, etc.).

• Assessment Objectives (AOs) – AOs exist within a stand-alone catalog and are represented in human readable documentation form (e.g., NIST SP 800-53A, NIST SP 800-171A, etc.).

• Risks - Risks often exist as a stand-alone risk catalog.

• Threats – Threats often exist as a stand-alone threats catalog.

• Metrics - Metrics often exist as a stand-alone metrics catalog.

 

The drawbacks associated with the traditional manner of generating and maintaining cybersecurity and privacy documentation include:

• Documentation is written only for human consumption (not machine readable); and

• Documentation is not written to be scalable or clearly mapped to other documents (e.g., metrics are not directly mapped to controls, standards are not directly tied to a policy, etc.).

 

Novelty Statement:

The novel solution being proposed is a hierarchical approach to cybersecurity and privacy documentation that provides direct linkages between documentation components in both a human and machine-readable manner. This invention is designed to support advanced data structures to provide greater automation and verification capabilities for cybersecurity and privacy documentation. This invention is not tied to one specific technology, since it leverages the concepts established by NIST OSCAL to support multiple formats (e.g., XML, JSON, YAML, etc.) to provide the greatest flexibility possible.

 

The invention provides GRC solutions, or similar technologies, with a machine-readable set of comprehensive and hierarchical cybersecurity and privacy documentation for their specialized, commercial applications that is geared towards efficiently managing cybersecurity and privacy-related documentation and processes. When a GRC solution, or similar technology, parses this machine-readable documentation (e.g., XML, JSON, YAML, etc.), it can populate its clients’ GRC instances with human-readable documentation that is uniquely-specific to an organization, while also enabling machine-readable queries to support audit/assessment-related activities.

 

The core features that this schema addresses includes cybersecurity and privacy-specific:

• Policies;

• Control objectives;

• Standards;

• Guidelines;

• Controls;

• Assessment Objectives (AOs);

• Evidence Artifacts (EAs);

• Procedures

• Risks;

• Threats; and

• Metrics.

 

Implementation / Process Steps:

What is disclosed is a computer-enabled method for establishing and managing cybersecurity and privacy-related documentation that enable an organization to comply with selected statutory, regulatory and other compliance requirements (based on selected controls), as well as discretionary requirements it deems appropriate to maintain an appropriate security posture.

 

The invention employs a schema (e.g., JSON, XML or YAML schema) that links unique cybersecurity and privacy documentation from policies all the way through metrics, where the controls serve as the nexus. Controls, as defined and described in catalogs, may also be referenced and configured in other documents; thus control information must be composed in a way to make it possible to migrate across different types of documents for different purposes, while maintaining “identity” and referential integrity for traceability. From the NIST OSCAL model, the catalog layer has the most relevance for the ICM Schema , since in the NIST OSCAL model, “A control represents a security requirement, guideline, procedure or activity. A control catalog is an organized collection of controls. The OSCAL catalog layer provides a model to represent a control catalog.” The catalog model in OSCAL refers to any data made available for processing in one of OSCAL’s formats for representing catalog information.

 

This hierarchical method of utilizing the ICM Schema is achieved by:

1. Determining and filtering an organization's Minimum Security Requirements (MSR) to comply with multiple, overlapping sources of requirements (e.g., statutory, regulatory and contractual obligations) by making associations between applicable Authoritative Source (AS) requirements. The MSR includes identifying and including:

   1. Minimum Compliance Criteria (MCC) that equate to “must have” cybersecurity and privacy requirements to comply with applicable statutory, regulatory and contractual requirements.

   2. Discretionary Security Requirements (DSR) that equate to “nice to have” cybersecurity and privacy requirements that an organization deems necessary to address in order to achieve its stated risk tolerance.

2. Assessment Objectives (AOs) provide an objective set of one or more criteria that can be used to evaluate if there is appropriate evidence to support a conclusion that related control is sufficiently designed, scoped and operational.

3. The MSR links to the appropriate policies, control objectives, standards, guidelines, risks, threats, AOs, procedures and metrics.

4. The schema is supported by identifying associated risks and metrics associated with the actual implementation or gaps associated with the MSR through the mapped risk and threat catalogs.

 

This invention is comprised of ten (10) unique types of documentation, each with its own specific components:

1. Policies;

2. Control Objectives;

3. Standards;

4. Guidelines;

5. Controls;

6. AOs;

7. Procedures;

8. Risks;

9. Threats; and

10. Metrics.

 

Policies.

Definition: Policies are high-level statements of management intent from an organization's executive leadership that are designed to influence decisions and guide the organization to achieve the desired outcomes.

 

Process Flow: Policies define high-level expectations and provide evidence of due diligence to address applicable requirements (internal and external). One policy maps to many control objectives.

• Policies generally have many Standards associated with it (one-to-many).

• Policies are enforced by Standards and further implemented by Procedures to establish actionable and accountable requirements.

• Policies are a business decision, not a technical one. Technology determines how policies are implemented. Policies usually exist to satisfy an external requirement (e.g., law, regulation and/or contract).

 

Components:

• Policy Domain [text]

• Policy # [text]

• Policy Name [text]

• Policy [text]

• Policy Owner [text]

• Policy Owner Role [text]

 

Control Objectives

Definition: Control Objectives are targets or desired conditions to be met. These are statements describing what is to be achieved as a result of the organization implementing a control, which is what a Standard is intended to address.

 

Process Flow: Control Objectives support Policies and provide scoping for Standards, based on industry-recognized secure practices.

• One Control Objective maps to one Standard (one-to-one).

• Where applicable, Control Objectives are directly linked to an industry-recognized secure practice to align cybersecurity and privacy with accepted practices. The intent is to establish sufficient evidence of due diligence and due care to withstand scrutiny.

 

Components:

• Control Objective # [text]

• Control Objective Name [text]

• Control Objective [text]

• Control Objective Owner [text]

• Control Objective Owner Role [text]

 

Standards

Definition: Standards are mandatory requirements in regard to processes, actions, and configurations that are designed to satisfy Control Objectives.

 

Process Flow: Standards operationalize Policies by providing organization-specific requirements that must be met.

• While one Standard should map to one Control, it is feasible that a Standard can map to multiple Controls (one-to-many).

• Standards are intended to be granular and prescriptive to establish Minimum Security Requirements (MSR) that ensure systems, applications and processes are designed and operated to include appropriate cybersecurity and privacy protections.

 

Components:

• Standard # [text]

• Standard Name [text]

• Standard [text]

• Standard Owner [text]

• Standard Owner Role [text]

 

Guidelines

Definition: Guidelines are recommended practices that are based on industry-recognized secure practices. Guidelines help augment Standards when discretion is permissible.

 

Process Flow: Guidelines provide useful guidance that provides additional content to help operationalize Standards.

• One guideline maps to one Standard (one-to-one).

• Unlike Standards, Guidelines allow users to apply discretion or leeway in their interpretation, implementation, or use.

 

Components:

• Guideline # [text]

• Guideline Name [text]

• Guideline [text]

 

Controls

Definition: Controls are technical, administrative or physical safeguards. Controls are the nexus used to manage risks through preventing, detecting or lessening the ability of a particular threat from negatively impacting business processes.

 

Process Flow: Controls are assigned to stakeholders to assign responsibilities in enforcing Standards. Controls serve as the nexus of the documentation ecosystem and map to multiple other documents.

• While one Control should map to one Standard, it is feasible that a Control can map to multiple Standards (one-to-many).

• Control testing leverages AOs as a means to define the desired outcome for the assessment of a cybersecurity control, privacy control or control enhancement.

 

Components:

• Control # [text]

• Control Name [text]

• Control [text]

• Control Question [text]

• Authoritative Source [text]

• Authoritative Source Version [text]

• Authoritative Source Reference [url]

• Functional Group [text]

• Relative Control Weight [integer]

• Assessment Objective(s) [text]

• SP-CMM Level 0 criteria [text]

• SP-CMM Level 1 criteria [text]

• SP-CMM Level 2 criteria [text]

• SP-CMM Level 3 criteria [text]

• SP-CMM Level 4 criteria [text]

• SP-CMM Level 5 criteria [text]

• Control Owner [text]

• Control Owner Role [text]

• Artifact [reference]

 

Assessment Objectives (AOs)

Definition: AOs a set of determination statements that expresses the desired outcome for the assessment of a cybersecurity control, privacy control, or control enhancement.

 

Process Flow: AOs are a set of determination statements that express the desired outcome for the assessment of a Control. AOs are the authoritative source of guidance for assessing controls to generate evidence to support the assertion that the underlying Control has been satisfied.

 

Components:

• Assessment Objective # [text]

 

Evidence Artifacts (EAs)

Definition: EAs are artifacts used to demonstrate control implementation.

 

Process Flow: EAs are created in the process of running a cybersecurity program in order to demonstrate the implementation of a control. EAs can be associated with one or multiple controls.

 

Components:

• Evidence Artifact # [text]

• Evidence Artifact Name [text]

• Evidence Artifact Description [text]

• Evidence Artifact Location [url]

• Evidence Artifact Owner [text]

• Evidence Artifact Role [text]

• Evidence Artifact Collection Date [date]

• Evidence Artifact Review Date [date]

 

Procedures

Definition: Procedures are a documented set of steps necessary to perform a specific task or process in conformance with an applicable standard.

 

Process Flow: The output of Procedures is evidence of due care to demonstrate that requirements are enforced.

• One Procedure maps to one Control (one-to-one).

• The result of a Procedure is intended to satisfy a specific Control. Procedures are also commonly referred to as "control activities."

• Procedures help address the question of how the organization actually operationalizes a policy, standard or control.

 

Components:

• Procedure # [text]

• Procedure Name [text]

• Procedure [text]

• Procedure Owner [text]

• Procedure Owner Role [text]

 

Risks

Definition: Risks represent a situation where someone or something valued is exposed to danger, harm or loss (noun) or to expose someone or something valued to danger, harm or loss (verb).

 

Process Flow: It is necessary to develop a risk catalog that identifies the possible risk(s) that affect the entity. The use case for the risk catalog is to identify the applicable risk(s) associated with a control deficiency (e.g., if the control fails, what risk(s) is the organization exposed to?).

• One Control can map to multiple Risks (one-to-many).

• Structuring controls as questions in a questionnaire format is often used to evaluate the implementation of a control (e.g., implemented, partially implemented, not implemented, not applicable or alternative approach).

 

Components:

• Risk # [text]

• Risk Name [text]

• Risk [text]

• Compensating Control [text]

• Risk Owner [text]

• Risk Owner Role [text]

 

Threats

Definition: Threats represent a person or thing likely to cause damage or danger (noun) or to indicate impending damage or danger (verb).

 

Process Flow: It is necessary to develop a threat catalog that identifies possible natural and man-made threats that affect the entity's security & privacy controls. The use case for the threat catalog is to identify applicable natural and man-made threats that affect control execution (e.g., if the threat materializes, will the control function as expected?).

• One Control can map to multiple Threats (one-to-many).

 

Components:

• Threat # [text]

• Threat Name [text]

• Threat [text]

 

Metrics

Definition: Metrics provide a "point in time" view of specific, discrete measurements, unlike trending and analytics that are derived by comparing a baseline of two or more measurements taken over a period of time. Analytics are generated from the analysis of metrics.

 

Process Flow: Metrics provide evidence of an oversight function for the cybersecurity and privacy program by measuring criteria to determine performance.

• While one Metric should map to one Control, it is feasible that a metric can map to multiple controls (one-to-many)

• Analytics are designed to facilitate decision-making, evaluate performance and improve accountability through the collection, analysis and reporting of relevant performance-related data.

 

Components:

• Metric # [text]

• Metric [text]

• Metric Owner [text]

• Metric Owner Role [text]

• Primary Metric [integer]