Policy Format and Structure

JupiterOne follows a modular approach in the organization of its policies and procedures. These components are written as "micro-docs" that are decoupled from each other. They are mapped to each other through a JSON configuration, and all policies, procedures, and reference documents are written in Markdown.

info

When creating policies and procedures be sure to reference JupiterOne's Security Policy Builder. All folders and files referenced in this article can be found there.

Structure

Below are examples illustrating how to format both Policies and Procedures within JupiterOne

Policies (templates/policies)

The templates/policies directory contains modular templates for policies. Each policy document follows this structure:

# Policy Title

`revision`

An overview of the policy. It includes a paragraph or two describing the intent and principles of the policy.

## Policy Statements

This section contains high-level requirements specific to the policy. The policy statements are aligned with the organization's operating model and applicable compliance requirements. They describe the "what" but not the "how" and are intended to remain stable over longer periods without frequent updates.

Procedures (templates/procedures)

The templates/procedures directory contains modular templates for controls and procedures. Each procedure is considered a "micro-document" that describes how a specific control is implemented to address the requirements in the policy it belongs to. The structure of a procedure document is as follows:

### Control/Procedure Title

Overview: A few lines describing the control and procedure.

Detailed text.

#### Sub-section as needed

Additional text.

Note that the title of a procedure is a level 3 heading. This is because the policy-builder tool automatically combines both the procedures and policies into a single document for publishing. It inserts a ## Controls and Procedures section heading after the Policy Statements section and before the first control/procedure.

References (templates/ref)

The templates/ref directory contains modular templates for reference documents. These documents are similar to control procedures. During the build/publish process, they are combined and attached to the Addendum and References document by the policy-builder. Assessments (templates/assessments)

The templates/assessments directory provides templates for assessment reports. Currently, the only available report template is for a HIPAA risk assessment. The jupiter-policy-builder CLI tool can utilize this template to automatically generate a self-assessment report based on the adoption of policies and procedures.

Configuration and Mapping

In JupiterOne, the configuration and mapping of security policies and procedures are facilitated through the config.json file and other associated JSON documents. Let's explore the different sections of the configuration and their purpose in the policy management process.

config.json { organization }

The config.json file includes an organization section where variables, such as companyFullName, are defined. These variables are used throughout the template documents, providing a centralized way to configure and maintain the policy set. By modifying the variables in the organization section, organizations can easily adapt the policies to their specific needs. JupiterOne's policy builder, available as both a web app and CLI, utilizes this configuration to generate the final policy set.

config.json { policies }

The policies section of config.json serves as a repository for policy modules. Each policy entry is defined with the following attributes:

Attribute	Description
id	This attribute typically corresponds to the filename of the policy without the extension.
file	It specifies the path to the corresponding Markdown module (without the .tmpl extension).
name	The name of the policy, which typically matches the title in the policy document.
adopted	A boolean flag indicating whether the policy has been adopted by the organization.
procedures	An array that contains the procedure modules responsible for implementing and enforcing the policy.

To ensure modularity and flexibility, the policies and procedures in JupiterOne are written as "micro-docs" that are decoupled from each other. The config.json file establishes the mapping between policies and their associated procedures.

config.json { procedures }

The procedures section in config.json acts as a repository for procedure modules. Each procedure entry includes the following attributes:

Attribute	Description
id	This attribute typically corresponds to the filename of the procedure without the extension.
file	It specifies the path to the corresponding Markdown module (without the .tmpl extension).
name	The name of the procedure, which usually matches the title in the procedure document.
type	It specifies the type of the procedure, such as administrative, technical, operational, physical, or informative.
provider	The name of the control provider associated with the procedure (e.g., "AWS IAM").
summary	This attribute provides guidance specific to the procedure, offering additional context to the document author.
applicable	A boolean indicating whether the procedure is applicable to the organization based on its operational and compliance requirements.
adopted	A boolean flag indicating whether the procedure has been adopted by the organization.

By defining procedures as modular units, JupiterOne enables organizations to address specific aspects of policy implementation while maintaining a clear connection to the overarching policies.

config.json { references }

The references section in config.json serves as a repository for additional documentation related to policies and procedures. Each reference entry is defined with the following attributes:

Attribute	Description
id	This attribute typically corresponds to the filename of the reference document without the extension.
file	It specifies the path to the corresponding Markdown module (without the .tmpl extension).
name	The name of the document, which usually matches the title in the reference document.
applicable	A boolean indicating whether the document is relevant to the organization based on its operational and compliance requirements.
adopted	A boolean flag indicating whether the document has been adopted by the organization.

The inclusion of references provides organizations with the flexibility to attach supplementary documentation that enhances the understanding and implementation of policies and procedures.

Compliance mapping

JupiterOne recognizes the importance of mapping controls and procedures to specific security and compliance frameworks. This mapping is facilitated through the standards/controls-mapping.json file.

The controls-mapping.json document enables the configuration of mappings between procedures and one or more security/compliance frameworks as applicable. By establishing these mappings, organizations can clearly identify the alignment between their procedures and the corresponding requirements of various frameworks.

It's worth noting that the controls mapping is performed at the control/procedure level and not at the policy level. JupiterOne emphasizes the necessity of documented controls and procedures for effectively implementing and enforcing high-level policies. Merely having a written policy without proper implementation and enforcement does not sufficiently address the risks associated with security and compliance requirements.

Internally, JupiterOne leverages the CIS Controls and SOC 2 frameworks for security and compliance purposes. The inclusion of JSON documents for these frameworks in the controls-mapping.json file serves as examples, showcasing their usage within JupiterOne. It's important to ensure that your organization has obtained the necessary end-user licenses for any frameworks used.

By providing a structured and configurable approach to configuration and mapping, JupiterOne simplifies the management of security policies, procedures, and their alignment with various compliance frameworks.