In the digital age, cyber attacks are inevitable. At JupiterOne, we are taking a “zero trust”, “minimal infrastructure” approach to managing risk and information security.
This document describes our guiding principles and aspirations in managing risk and the building blocks of our security model.
JupiterOne policy requires that:
(a) JupiterOne’s security program and operations should be designed and implemented with the following objectives and best practices in mind:
(b) Security shall remain a top priority in all aspects of JupiterOne’s business operations and product development.
“Zero Trust” is a data-centric security design that puts micro-perimeters around specific data or assets so that more granular rules can be enforced. It remedies the deficiencies with perimeter-centric strategies and the legacy devices and technologies used to implement them. It does this by promoting “never trust, always verify” as its guiding principle. This differs substantially from conventional security models which operate on the basis of “trust but verify.”
In particular, with Zero Trust there is no default trust for any entity — including users, devices, applications, and packets—regardless of what it is and its location on or relative to the corporate network. In addition, verifying that authorized entities are always doing only what they’re allowed to do is no longer optional; it’s now mandatory.
* No internal network. (Almost) 100% cloud. * Fully segregated with Granular policy enforcements. * Individually secured devices. No production access by default.
We extend the zero-trust security model with a “Minimal Infrastructure” approach, where we use “Anything-as-a-Service” whenever possible, to harness the full power of the cloud. Cloud services allow us to contain and control access at a much more granular level, compared to operating on-premise infrastructure. Using the extensive APIs provided by our adopted cloud services, we are able to more easily integrate and automate security operations. Additionally, minimizing infrastructure significantly reduces always-on attack surfaces. Services that are not used are turned off, instead of being idly available which opens itself up to attacks. Together with Zero Trust, this security model and architecture enables a high degree of flexibility for end-user computing while maintaining the highest level of security assurance for our data in the cloud.
* No direct administrative or broad network connectivity into production. * Processes are short-lived and killed after use. * Minimal persistent attack surfaces make compromise quite difficult.
Cyber attacks are inevitable. When it comes to preparing for potential attacks, JupiterOne security operations take the approach that assumes a compromise can happen at any time, to any device, with little to no indicators. This is also an extension of the “Zero Trust” model. When building security operations we carefully perform risk analysis and threat modeling to identify potential single-points-of-compromise and to avoid giving away the “keys to the kingdom”.
In other words, compromise of any single system or user or credential, should not easily lead to a broad or full compromise of the entire infrastructure or operations. For example, if an attacker gains access to an admin credential it should not directly lead to the compromise of all systems and data in the environment.
* Need-based access control for both employees and computing services. * Access to critical systems and resources are closed by default, granted on demand. * Protected by strong multi-factor authentication. * No “keys to the kingdom”; no single-points-of-compromise. * "Secrets" (such as API tokens) must remain secret at all times.
The JupiterOne platform leverages a micro-services architecture. This means that the system has been decomposed into numerous small components that can be built and deployed individually. Before these components get deployed to our production environments, we thoroughly test and validate the changes in our lower environments which are completely isolated from production. This allows us to test upcoming changes while ensuring there is no impact to our customers.
As a particular build of a component progresses through our environments, it is important that the build does not change, thus we ensure that each build is immutable. Once an immutable build has been validated in our lower (non-production) environments, we then deploy it to our production environment where the change will be available to JupiterOne customers and end-users.
Changes to our infrastructure (database schema changes, storage buckets, load balancers, DNS entries, etc.) are also described in our source code and deployed to our environments just like the applications. This architectural approach to managing infrastructure is referred to as “Infrastructure as Code (IaC)” and is a key requirement for fully automated deployments with minimal human touch.
* IaC with active protection. * Automated security scans and full traceability from code commit to production. * “Hands-free” deployment ensures each build is free from human error or malicious contamination.
It is of the utmost importance that JupiterOne provides for confidentiality (privacy), integrity and availability of its customer’s data. Customer data is protected with end-to-end encryption, combined with strong access controls and key management. We also prohibit our internal employees from accessing customer data directly in production. Customer data remains safe and private at all times–JupiterOne will never use or share customer data without their prior consent.
* Data is safe both at rest and in transit, using strong encryption, access control and key management. * No internal user access is allowed to customer data in production.
We all know by now that “Passw0rd” makes a terrible password. Access control is so important we must get it right. That’s why we leverage tried-and-true technology such as SAML, OAuth, multi-factor authentication, and fine-grained authorization to provide strong yet intuitive access options, both for our internal staff to access business resources and for our customers to access the JupiterOne platform and services.
* OAuth 2.0, OpenID Connect, SAML for customer authentication and single sign-on (SSO). * Multi-factor authentication. * Fine-grain attribute-based or role-based authorization.
You can’t protect what you can’t see.
As the famous strategist, Sun Tzu, once said, “Know thy self, know thy enemy. A thousand battles, a thousand victories.” It all starts with knowing ourselves. This applies to the infrastructure, environments, operations, users, systems, resources, and most importantly, data. It is important to inventory all assets, document all operations, identify all weaknesses, and visualize/understand all events.
This includes conducting various risk analyses, threat modeling exercises, vulnerability assessments, application scans, and penetration tests. Not only that, this requires security operations to keep an eye on everything, and someone should also “watch the watchers”.
At first, this would require significant manual effort and may seem impossible to keep up to date. Our goal is to automate security operations, so that this can be achieved programmatically as our operations evolve to become more complex.
Additionally, JupiterOne security team will actively monitor threat intelligence in the community, with feeds and information sharing platforms such as US-CERT to stay abreast of attacker activities and methodologies.
* All environments are monitored; All events are logged; All alerts are analyzed; All assets are tracked. * No privileged access without prior approval or full auditing. * We deploy monitoring redundancy to “watch the watchers”.
As much as possible, JupiterOne Security will translate policy and compliance requirements into reusable code for easy implementation and maintenance. This allows us to enforce policy and compliance in a fast and scalable way, rather than relying solely on written policies and intermittent manual audits. For example, end-point device policies may be translated into Netflix Stethoscope-app configuration, and compliance may be enforced through the agent. Access Control policies for production environments are translated into AWS IAM JSON policies and implemented via Terraform code.
Automation makes it truly possible to centralize security operations, including not only event aggregation and correlation, but also the orchestration and management of previously siloed security controls and remediation efforts.
* API-driven cloud-native security fabric that * centrally monitors security events, * visualizes risk management, * automates compliance audits, and * orchestrates near real-time remediation.
Security benefits from transparency, and should operate as an open-book. This allows the entire organization to take responsibility for–and accountability of–adopting security best practices. Similar to code reviews and pull requests in the development process, JupiterOne security team makes security standards and practices available to all employees for feedback prior to adoption.
We emphasize the usability and practicality of security. A security solution or process is not effective if it is not being used–no matter how good it may be. Having impractical security would only generate noise, provide a false sense of security, and incur unnecessary cost. Nothing is perfect, but we embrace an agile mindset to test and try and to continuously improve.
* All employees receive security awareness training not annually, but monthly. * Simple policies, processes, and procedures. * No “Shadow IT”. * DevSecOps with common goals and an integrated team. * Processes that encourage self-management and reward good behavior.
Security != Compliance. We cannot have one without the other.
* SOC2 Compliant. * Independently assessed and certified. * Hacker-verified.
JupiterOne developed a security architecture on top of its three main infrastructure environments - Cloud (AWS), DevOps, and workforce collaboration / end-user computing.
High-level architecture diagrams may be found in the Engineering Wiki.
Detailed architecture diagrams of the in-scope networks, endpoints, applications as well as the security operations are developed and maintained by JupiterOne.
JupiterOne strives to leverage functions as the primary building blocks for our platform because:
A set of metrics / KPIs have been defined to meausre, report, and optimize the security program and the existing controls.
A security scorecard is produced every quarter with updates to key metrics of the JupiterOne information security program, to measure its adoption and effectiveness.
The reports and scorecards are maintained by JupiterOne and can be accessed at https://apps.us.jupiterone.io/insights.
JupiterOne strives to provide a high quality of service to all of its customers. This is accomplished through a security architecture that encompasses all of JupiterOne’s operations and provides a high degree of data confidentiality, integrity, and availability.
JupiterOne uses a highly scalable cloud architecture to provide system quality at all times.
All systems are monitored and measured in real time as described in Application Service Event Recovery.
JupiterOne uses DevOps methodology as described in Software Development Process to ensure a smooth delivery process of all systems and applications.
Status for external-facing, customer applications and systems is posted to JupiterOne Community Slack: #status channel.