Access to JupiterOne systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, or any other entity. Access is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized access of the organization’s information systems. These safeguards are in keeping with the principle of least privilege and industry best practices.
JupiterOne policy requires that
(a) Access to all computing resources, including servers, end-user computing devices, network equipment, cloud services and applications, must be protected by strong authentication, authorization, and auditing.
(b) Interactive user access must be associated to an account or login unique to each user.
(c) All credentials, including user passwords, service accounts, and access keys, must meet the length, complexity, age, and rotation requirements defined in JupiterOne security standards.
(d) Use of multi-factor authentication (MFA) whenever possible to authenticate to all computing resources (including both devices and applications).
(e) Use of MFA is required to access any critical system or resource, including but not limited to resources in JupiterOne production environments.
(f) Unused accounts, passwords, and access keys must be removed within 30 days.
(g) A unique access key or service account must be used for different application or user access.
(h) Authenticated sessions must time out after a defined period of inactivity.
JupiterOne policy requires that
(a) Access authorization shall be implemented using role-based access control (RBAC) or similar mechanism.
(b) Standard access based on a user’s job role may be pre-provisioned during employee onboarding. All subsequent access requests to computing resources must be approved by the requestor’s manager, prior to granting and provisioning of access.
(c) Access to critical resources, such as production environments, must be approved by the security team in addition to the requestor’s manager.
(d) Access must be reviewed on a regular basis and revoked if no longer needed.
(e) Upon termination of employment, all system access must be revoked and user accounts terminated within 24 hours.
(f) All system access must be reviewed at least annually and whenever a user’s job role changes. ACC1
JupiterOne policy requires that
(a) Use of shared credentials/secrets must be minimized and approved on an exception basis.
(b) If required by business operations, secrets/credentials must be shared securely and stored in encrypted vaults that meet the JupiterOne data encryption standards.
(c) Usage of a shared secret to access a critical system or resource must be supported by a complementing solution to uniquely identify the user.
JupiterOne policy requires that
(a) Users must not log in directly to systems as a privileged user.
(b) Privileged access must only be gained through a proxy, or equivalent, that supports strong authentication (such as MFA) using a unique individual account with full auditing of user activities.
(c) Direct administrative access to production systems must be kept to an absolute minimum, and requires additional “break glass” auditing procedures.
(d) System owners must review direct administrative and/or privileged access to production systems weekly to ensure access patterns are kept to a minimum. ACC2
Each Customer and Partner of the JupiterOne application is uniquely identified. They may either:
This authentication is enforced through the use of AWS Cognito.
Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with JupiterOne workstations or production systems.
!!! check “Exceptions”
Automatic log-on may be permitted for low-risk systems such as conference room PCs connecting to a Zoom Room.
On all production systems and applications in the JupiterOne environment, password configurations are set to require:
!!! check “Exceptions”
Password expiration may be set to a greater interval if an account is always protected by MFA. Currently, Google G Suite SSO password rotation interval is set to 180 days.
Passwords are generally not stored directly in JupiterOne systems. When this is necessary, all system and application passwords must be stored and transmitted securely:
An approved password manager is used to store or share non-critical business application passwords that are not integrated with Google G Suite through SSO.
JupiterOne selected Google G Suite as its primary Identity Provider (IdP) to control user access to systems and business applications.
Single sign-on (SSO) should be used whenever possible instead of local authentication. This centralized approach improves user experience and simplifies access management.
SSO is configured via industry standard SAML protocol between (Google G Suite) and the target application.
JupiterOne will not configure SSO to target applications unless they score a “B” rating or higher on the Qualys SSL Labs benchmark.
Security team is responsible for Google G Suite administration, including user and access provisioning. Security team may delegate administrative privilege to a subset of the system, such as a specific application.
Multi-factor authentication (MFA) is a standard control used by JupiterOne to provide strong access control to critical systems and applications, and should be enabled whenever possible.
JupiterOne implements MFA using Google G Suite.
**Approved MFA methods include:** - Push notification delivered through the Google G Suite mobile app (default and preferred for end-user access) * Hardware MFA token (required for the root user of AWS accounts) * A unique cryptographic certificate tied to a device * Time-based One-Time Password (TOTP) delivered through a mobile app, such as Google Authenticator * One-time passcode delivered through SMS text message (if it is the only supported option)
By default, user access is granted based on the user’s job function / role. For example:
This is defined as user groups in Google G Suite.
Access to sensitive data including production customer data is highly restricted and further defined in its own section.
Access to JupiterOne AWS accounts are permissible through temporary credentials / sessions only. No persistent users, passwords or access keys are allowed in AWS IAM configurations for end-user access, either to the AWS console or AWS CLI. This is achieved with the following processes:
jupiterone-master) in AWS is configured with IAM roles such as
jupiterone-masterand an “AWS SAML App” provisioned in Google G Suite.
jupiterone-masterusing AWS Assume Role capability.
jupiterone-masterby default have highly restricted access. For example, the
Developerrole does not have access to any services and resources in the master account.
The user is required to Assume a Role in a sub-account, connected via
cross-account trust policy defined at account bootstrap or through an approved
change management process. For example, a Developer can assume the
Administrator role in
jupiterone-dev, which is the sandboxed development
environment in a dedicated AWS account. This follows AWS’ documented best
practices for cross-account access.
Developerrole in production which only has access to read CloudWatch logs, XRay system traces/service maps, CloudWatch metrics, resource group inventories, and CloudWatch dashboards.
Auditorrole in production which has the default Auditor IAM policy managed by AWS. This policy allows read-only access to account and resource configurations, but does not allow read access to any data such as S3 objects.
aws-google-authCLI tool is used to obtain temporary credentials (AWS STS access keys) for developers to connect to AWS using the CLI or SDK.
aws-google-authtool, developers are prompted to authenticate to Google G Suite using their Google G Suite credentials and MFA token/app.
Developerrole through AWS console.
In normal operations, troubleshooting is performed via log analysis in AWS CloudWatch, using the Developer role. A separate Support role is created for temporary troubleshooting and support access when log access is insufficient to determine the cause. Support access should be minimized and is designed to involve manual approval and follow a manual provisioning process.
JupiterOne implements a Dual Control / Split Knowledge process to protect Root user access to our AWS accounts. The process works as follows:
Security Officer has access to the root account credentials.
Director of Engineering has access to the Hardware Tokens associated with the root users.
When root access is required for business or operational needs, a Jira ServiceDesk issue is created that requires the Security Officer and Director of Engineering to jointly perform the action. All actions performed while using the Root user are documented in the ticket, along with business justifications.
VPN remote access to non-production and non-privileged environments in AWS are permissible and implemented using Pritunl.
VPN remote access to master and production accounts are prohibited.
JupiterOne does not allow direct system access by customers. Access is only available through the Web UI or API, with valid authentication and authorization detailed in the Product Security, Architecture, and Security pages of the engineering wiki.
Requests for access to JupiterOne Platform systems and applications is made formally using the following process:
The Security team will grant standard access per job role as part of new employee onboarding. A standard set of accounts that are default for all employees are created as part of the onboarding process. This includes:
If the PR is approved, the Security team provisions access, then merges the PR, adding any pertinent notes. This marks the opening Issue as Done.
Temporary accounts are not used unless absolutely necessary for business purposes.
Security team receives access termination requests in one of the following conditions and processes it accordingly:
Privileged users must first access systems using standard, unique user accounts before elevating the privilege or switching to privileged users and performing privileged tasks. Examples include:
Run as Administratorin Windows
Assume rolein AWS
All application-to-application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
Services that are part of JupiterOne platform leverage AWS IAM policy configurations and/or OAuth for authorization.
Generic accounts are not allowed on JupiterOne systems.
Direct system-to-system, system-to-application, and application-to-application authentication and authorization are limited and controlled to restrict access.
In AWS, service accounts are implemented in the form of IAM Roles, and their access defined by the corresponding IAM policies. The creation of these IAM roles and policies is implemented as code, which follows the secure development, review and production change approval process.
An inventory of all Service accounts is maintained by AWS IAM and Terraform and reviewed periodically.
All workstations at JupiterOne are company owned, using one the following approved hardware vendors and operating systems:
dm-crypt(Linux) or equivalent.
Wireless networks managed within JupiterOne non-production facilities (offices, etc.) are secured with the following configurations:
JupiterOne leverages a combination of Jenkins credentials store, credstash, and AWS KMS, Secrets Manager, and SSM Parameter Store services to securely store production secrets. Secrets are always encrypted; access to secrets is always controlled and audited.
Secrets management technical details and usage are documented on the JupiterOne Engineering Wiki.
The following requirements and controls are in place for accessing production data by internal personnel:
There is no pre-provisioned, persisted “internal” access to production data stores. Access such as direct SSH to the production database servers and direct access to data objects in production S3 buckets are prohibited.
Access to customer data is granted on a per-account basis.
Access requests follow the same production access processes. Access must be approved by both the data owner and the security team.
Access to production data is granted only through approved platform with strong centralized access control, with MFA.
An audit list of who has access to which unsanitized customer data is maintained and reviewed monthly by Director of Engineering. Access is revoked when no longer needed. ACC4
JupiterOne employees have the ability to obtain self-service support directly from supported business applications, such as password reset via Google G Suite.
An issue is opened in Jira ServiceDesk for each support request and assigned to the appropriate personnel. The person assigned must verify the identity of the requester and ensure the ticket has appropriate approval before implementing or providing support. The verification step and confirmation of “User identity verified” should be included as a comment in the ticket by the support personnel. Additionally, if a password or security credential has been created or supplied, confirm user has received it via another channel like slack/email/phone/zoom and document receipt in the ticket.