Community
Questions Library
Docs
Blog
Events
Swag
Github
Slack
JupiterOne
Discussions
Release Notes
JupiterOne Security Policies Format and Structure - AskJ1 Community
<main> <article class="userContent"> <p>Similar to the concept of "micro-services", the JupiterOne policies and procedures are written in "micro-docs" that are decoupled from the policies. They are mapped to each other via a JSON configuration.</p> <ul><li>All policies, procedures and reference documents are written in <strong>Markdown</strong>.</li> <li>All configuration files are in <strong>JSON</strong> format, including mapping between policies and procedures, and between procedures and compliance standards.</li> </ul><p>Policies and procedures are part of JupiterOne's Governance, Risk, and Compliance (GRC) <a rel="nofollow" href="https://jupiterone.vanillacommunities.com/kb/articles/814-jupiterone-data-model-for-governance-risk-and-compliance-grc">graph data model</a>.</p> <h2 data-id="structure">Structure</h2> <p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">templates/policies</code></p> <ul><li>This directory contains the modular templates for policies.</li> <li><p>Each policy document is written in the following structure:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0"># Policy Title `revision` Overview of the policy. A paragraph or two to describe the intent and principals of the policy. ## Policy Statements This section contains the high level requirements specific to the policy. Policy statements are aligned to the organization's operating model and applicable compliance requirements. These statements describe the "what" but not the "how". They are meant to be stable over longer periods of time without needing frequent updates. </pre></li> </ul><p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">templates/procedures</code></p> <ul><li>This directory contains the modular templates for controls and procedures.</li> <li>Each procedure is considered a "micro-document" that describes how a specific control is implemented to address the requirements in the policy that it implements.</li> <li><p>Each procedure document is written in the following structure:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">### Control/Procedure Title Overview. A few lines to describe the control and procedure. Detailed text. #### Sub-section as needed More text. </pre></li> </ul><blockquote class="UserQuote blockquote"><div class="QuoteText blockquote-content"> <p class="blockquote-line">Note that the <strong>Title</strong> is a <em>level 3 heading</em>. This is because the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">policy-builder</code> tool will automatically combine the procedures and policies they each implement to a single document for publishing, and it will insert a <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">## Controls and Procedures</code> section heading after the <strong>Policy Statements</strong> section and before the first control/procedure.</p> </div></blockquote> <p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">templates/ref</code></p> <ul><li>This directory contains the modular templates for reference documents.</li> <li>The reference documents are similar to control procedures. At build/publish time, they will be combined and attached to the <strong>Addendum and References</strong> document by the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">policy-builder</code></li> </ul><p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">templates/assessments</code></p> <ul><li>This directory contains templates for assessment reports.</li> <li>The only available report template at the moment is for a HIPAA risk assessment.</li> <li>The <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">jupiter-policy-builder</code> CLI tool can leverage this template to auto-generate a self assessment report based on the adoption of policies and procedures.</li> </ul><h2 data-id="configuration-and-mapping">Configuration and Mapping</h2> <p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">config.json { organization }</code></p> <p>There are variables (e.g. <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">companyFullName</code>) defined throughout the template documents. These variables make it easy to adopt and maintain the policy set by configuring the variables at one place -- in the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">organization</code> section of <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">config.json</code>.</p> <p>JupiterOne's policy builder (both the web app and CLI) makes use of this configuration to build the final policy set.</p> <p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">config.json { policies }</code></p> <p>The <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">policies</code> section is a repository of the policy modules. Each entry is defined with the following:</p> <ul><li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">id</code> - typically matches the filename of the policy without the extension</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">file</code> - path to the markdown module (without the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">.tmpl</code> extension)</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">name</code> - policy name, which typically matches the title in the policy doc</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">adopted</code> - a <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">boolean</code> flag to indicate if the policy has been adopted by the organization</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">procedures</code> - an array that contains the procedure modules that implement/enforce this policy.</li> </ul><p>Similar to the concept of "micro-services", the policies and procedures are written in "micro-docs" that are decoupled from the policies. They are mapped to each other via the above configuration.</p> <p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">config.json { procedures }</code></p> <p>The <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">procedures</code> section is a repository of the procedure modules. Each entry is defined with the following:</p> <ul><li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">id</code> - typically matches the filename of the procedures without the extension</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">file</code> - path to the markdown module (without the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">.tmpl</code> extension)</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">name</code> - procedure name, which typically matches the title in the procedure doc</li> <li><p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">type</code> - specifies one of the following procedure types:</p> <ul><li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">administrative</code></li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">technical</code></li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">operational</code></li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">physical</code></li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">informative</code></li> </ul></li> <li><p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">provider</code> - name of the control provider (e.g. "AWS IAM")</p></li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">summary</code> - provides guidance to the document author specific to that procedure</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">applicable</code> - a <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">boolean</code> that specifies whether the procedure is applicable to the organization based on its operational and compliance requirements</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">adopted</code> - a <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">boolean</code> flag to indicate if the policy has been adopted by the organization</li> </ul><p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">config.json { references }</code></p> <p>Similar to procedures, the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">references</code> section is a repository of additional documentation. Each entry is defined with the following:</p> <ul><li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">id</code> - typically matches the filename of the procedures without the extension</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">file</code> - path to the markdown module (without the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">.tmpl</code> extension)</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">name</code> - document name, which typically matches the title in the procedure doc</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">applicable</code> - a <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">boolean</code> that specifies whether the document is applicable to the organization based on its operational and compliance requirements</li> <li><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">adopted</code> - a <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">boolean</code> flag to indicate if the policy has been adopted by the organization</li> </ul><h3 data-id="compliance-mapping">Compliance Mapping</h3> <p><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">standards/controls-mapping.json</code></p> <p>The <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">controls-mapping.json</code> document configures a mapping of each procedure to one or more security/compliance frameworks, as applicable.</p> <p>Note that the controls mapping is only between a control/procedure document to the requirement, not at the policy level. This is because we strongly believe that you must have documented controls and procedures to implement and enforce a high-level written policy. Having a written policy by itself without <br> implementation or enforcement does not address the risk of any security or compliance requirement.</p> <p>Internally at JupiterOne, we leverage CIS Controls and SOC 2.</p> <p>The JSON documents for those four frameworks are included strictly because of our internal usage and shown as examples. Using those requires that you have obtained necessary end-user license for the framework for your own organization.</p> </article> </main>
.png)