Community
Questions Library
Docs
Blog
Events
Swag
Github
Slack
JupiterOne
Discussions
Release Notes
Contact Us
JupiterOne Data Security - AskJ1 Community
<main> <article class="userContent"> <p>This document describes in detail the data JupiterOne ingests and how your data is protected on our platform.</p> <h2 data-id="data-protection">Data Protection</h2> <h3 data-id="encryption">Encryption</h3> <p>Data is fully encrypted both at rest and in transit. This includes all of your account and user data, as well as operational data imported/ingested into the JupiterOne platform.</p> <p><strong>Data in Transit</strong> is encrypted via TLSv1.2 or later, using SHA-256 with 2048-bit RSA Encryption or equivalent strength cypher.</p> <p><em>Production Domains:</em> <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">*.apps.us.jupiterone.io</code> is the associated production URL that the SSL/TLS certificate has been issued to.</p> <p><strong>Data at Rest</strong> is hosted in our production AWS environments, using the managed RDS/Neptune, DynamoDB, and S3 services. All database instances, tables, and S3 buckets with customer data have server-side encryption enabled, using AWS KMS for key management. KMS encryption keys are scheduled to rotate annually.</p> <p>In addition to encryption, managed backup is enabled for the database clusters. For S3 buckets, cross-account replication is enabled to back up data to a different region for disaster recovery. All backup data is fully encrypted the same way as its source.</p> <h3 data-id="multi-tenancy">Multi-tenancy</h3> <p>JupiterOne is a multi-tenancy, software-as-a-service platform hosted in AWS. Customer data is logically partitioned/segregated by software via a unique <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">accountId</code> associated with every piece of data. Access to data is restricted to within each unique account for users granted proper access to that account. This is a standard pattern used by cloud infrastructure and SaaS providers.</p> <h2 data-id="external-data-ingestion-import">External Data Ingestion/Import</h2> <p>JupiterOne ingests data from external sources and connected environments primarily via the APIs provided by the target environment/service provider. Objects from these external environments and their corresponding metadata, including configuration properties and tags but never the actual data content, are ingested as "entities". The entity properties and tags are used to perform analysis to build out "relationships" among ingested entities. These entities and relationships are the <strong>JupiterOne CORE data model</strong>.</p> <p>JupiterOne then uses this data model to inventory for and provide insight into your digital infrastructure across all of your connected environments.</p> <p>More information on the JupiterOne data model is available <a rel="nofollow" href="https://jupiterone.vanillacommunities.com/kb/articles/846-jupiterone-data-model">here</a>.</p> <p>For more details on data ingested for each managed integration, see their corresponding documentation in the <strong>Integrations</strong> section.</p> <h3 data-id="access-permissions-needed-to-integrated-environments">Access Permissions Needed to Integrated Environments</h3> <p>Access to your environments is needed in order to ingest data, or to enable workflow automation (future capability).</p> <p>In general, JupiterOne only requires read-only, security-auditor-type access permissions to your environments. Additionally, this read-only access only applies to configurations and meta data, not the actual data content. For example, we do <strong>NOT</strong> read S3 objects data from a connected AWS account, or the actual source code of a connected Bitbucket/GitHub account.</p> <p>Additional level of access may be needed for workflow automation. For example, integration with Jira to automatically create an issue when a new Vulnerability finding is added; or to post to a Slack channel/user to send a security alert notification.</p> <p>You are always in control of the actual permissions granted for each integration. More details of the access permissions required for each managed integration can be found in its corresponding documentation listed above.</p> <h3 data-id="custom-data-import">Custom Data Import</h3> <p>Additionally, JupiterOne supports the ability for you to add custom data by</p> <ul><li>Manually adding entities via Web UI in the Asset Inventory app;</li> <li>Adding bulk number of entities via CSV import; or</li> <li>Adding custom entities via custom integrations using the public API.</li> </ul><h2 data-id="data-ownership-and-access">Data Ownership and Access</h2> <p>You retain full ownership of all data that is ingested via integrations, API or manual importing/creation. Data is stored in the JupiterOne production environment in AWS, protected via encryption and replication as specified in the first section.</p> <h3 data-id="infrastructure-and-operational-access">Infrastructure and Operational Access</h3> <p>JupiterOne infrastructure is built on a <strong>Zero Trust</strong> security model, where access to production is <em>highly restricted</em>.</p> <p>The production environment is virtually "air-gapped" such that there is no SSH, "bastion host", or VPN connectivity into the production systems to prevent unintended network access to databases and other production servers. We do not allow internal access to production data by any JupiterOne team member. All necessary operational support and maintenance jobs are performed via automation where the automation code is fully documented, reviewed, and approved, ensuring end-to-end traceability.</p> <p>Our production environment incorporates multiple layers of security monitoring, using JupiterOne itself as well as third party security solutions. Additionally, our software development includes rigorous code analysis and continuous testing practices to ensure we proactively identify any security vulnerability. Our<br> infrastructure-as-code operational model and automated change management process allows us to deploy security patches within minutes of identification and remediation of an issue.</p> <p>You can review the JupiterOne <a rel="nofollow" href="https://jupiterone.vanillacommunities.com/kb/articles/846-jupiterone-data-model">data model</a> and <a rel="nofollow" href="https://psp.jptr.one/">policies and procedures</a> for more details on the JupiterOne operational, infrastructure, and software development security.</p> <h2 data-id="application-access">Application Access</h2> <p>Access to the JupiterOne application and your accounts/data on the platform is enabled over HTTPS, through either the JupiterOne web apps or the public APIs.</p> <p><strong>Note:</strong><br><code class="code codeInline code codeInline" spellcheck="false" tabindex="0">*.us.jupiterone.io</code> is the current production domain.</p> <h3 data-id="user-logins">User Logins</h3> <p>Each user has a unique user login to the JupiterOne platform and apps. Users may be invited to one or multiple organizational accounts on JupiterOne.</p> <h4 data-id="password-policy">Password Policy</h4> <p>Users are required to select a strong password that meets the following password policy requirements to create a login and authenticate to the system:</p> <ul><li>Minimum of 8 characters</li> <li>Must contain an uppercase letter</li> <li>Must contain a lowercase letter</li> <li>Must contain a number</li> <li>Must contain a special character</li> </ul><h4 data-id="single-sign-on-sso">Single Sign-On (SSO)</h4> <p>JupiterOne currently supports single sign-on (SSO) via:</p> <ul><li>Google</li> <li>SAML</li> </ul><h4 data-id="multi-factor-authentication-mfa-two-step-verification-2sv">Multi-Factor Authentication (MFA) / Two-Step Verification (2SV)</h4> <p>Multi-Factor Authentication (MFA) or Two-Step Verification (2SV) is strongly recommended for all users on the JupiterOne platform. This needs to be enabled and configured via your SSO provider (Google or your SAML IdP such as Okta or OneLogin).</p> <h3 data-id="access-control">Access Control</h3> <p>To support potential complex access control use cases, the JupiterOne platform implements Attribute Based Access Control (ABAC).</p> <p>A good general overview of ABAC is sections 1 and 2 of NIST's <a rel="nofollow" href="https://csrc.nist.gov/publications/detail/sp/800-162/final">Guide to Attribute Based Access Control</a>. The absolute basics of ABAC are that you have a subject (e.g. a user) who wants to perform some operation (e.g. download) on an object (e.g. a file) in some environment. The subject, object and environment all have attributes (i.e. key/value pairs), and there are policies that control the privileges (i.e. what operations the subject can perform) given the attributes.</p> <p>Access policies defined in JupiterOne are associated with a <strong>User Group</strong> and <strong>Users</strong> are invited/added as members to one or more groups.</p> <ul><li>A <em>Read-Only</em> access policy is predefined and associated with the default <strong>Users</strong> group.</li> <li>A <em>Full-Access</em> policy is also predefined and associated with the default <strong>Administrators</strong> group.</li> <li>The ability to customize and add granular access control policies is to be released in 1Q2019.</li> </ul><h3 data-id="api-access">API Access</h3> <p>JupiterOne GraphQL API is available at: <a href="https://graphql.us.jupiterone.io/" rel="nofollow">https://graphql.us.jupiterone.io/</a></p> <p>We use <a rel="nofollow" href="https://oauth.net/2/">OAuth 2.0</a> for authorization, which means that to access data a user must authenticate and the requesting app must be authorized. Implicit grant, authorization code, and client credentials flows are<br> supported. Authorization code is recommended for web apps, which involves utilizing both the authorize and token API resources. When using the authorization code grant flow, it is also recommended to use Proof Key for Code Exchange (PCKE) to mitigate authorization code intercept attacks. Contact us if<br> building a native app which can securely perform client credentials flow.</p> <p>Additionally, each user on the platform can create an API key that can be passed along with request to act on behalf of that user.</p> <h3 data-id="support-access-to-your-jupiterone-accounts">Support Access to Your JupiterOne Accounts</h3> <p>A JupiterOne Support User can be added to any account to assist with a proof-of-concept evaluation, help with initial onboarding, or facilitate support and training on using the platform. Any users that have access to your JupiterOne account will show up in Settings under <em>Users and Access</em>.</p> <ul><li>The Security Engineer/Architect designated to your account (support user) will appear as <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">firstname.lastname@jupiterone.com</code>.</li> <li>The support user can be removed by an account administrator at any time, should you determine that ongoing regular support is no longer needed.</li> <li>You have the option and administrative privilege to add the support user back at any time, when support is needed in the future.</li> </ul> </article> </main>
.png)