JupiterOne Policies, Standards, and Procedures

Access

2020.1

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.

Policy Statements

Access Control Policy

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.

Access Authorization and Termination

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

Shared Secrets Management

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.

Privileged Access Management

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) Members of the Security team must review direct administrative and/or privileged access to production systems every 60 days to ensure access patterns are kept to a minimum. ACC2

Controls and Procedures

Standards for Access Provisioning

Workforce Clearance

  1. The level of security assigned to a user to the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities.
  2. The principle of “least privilege” applies to the review of all access requests.
  3. JupiterOne maintains a minimum necessary approach for access to Customer data. As such, JupiterOne, including all workforce members, does not readily have access to any data stored on behalf of customers.

Access Authorization

  1. Role based access categories for each JupiterOne system and application are pre-approved by the Security Officer.
  2. JupiterOne utilizes hardware-defined and/or software-defined boundaries to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.

Person or Entity Authentication

  1. Each workforce member has and uses a unique user ID and password (managed by Google G Suite) that identifies them as the user of the information system.
  2. All customer support interactions must be verified before JupiterOne support personnel will satisfy any request having information security implications.
  3. Each Customer and Partner of the JupiterOne application is uniquely identified. They may either:

    • use a unique user ID and password (password auth), or
    • federate authentication through SAML to their configured IdP (SAML auth).

    This authentication is enforced through the use of AWS Cognito.

Unique User Identification

  1. Access to the JupiterOne Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
  2. Passwords requirements mandate strong password controls (see below).
  3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
  4. Default accounts on all production systems and environments, including root, are disabled/locked.
  5. Shared accounts are not allowed within JupiterOne systems or networks.

Automatic Logon and Logoff

  1. 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.
    
  2. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
  3. If supported, endpoint devices are configured to automatically lock after 5 minutes or less of inactivity.
  4. Information systems automatically enter standby or log users off the systems after 30 minutes or less of inactivity.
  5. The Security Officer must pre-approve any exception to automatic log off requirements.

Password Management

  1. User IDs and passwords that are used to control access to JupiterOne systems may not be disclosed to anyone for any reason.
  2. Users may not allow anyone, for any reason, to have access to any information system using another user’s unique user ID and password.
  3. On all production systems and applications in the JupiterOne environment, password configurations are set to require:

    • a minimum length of 12 characters.
    • a mix of upper-case characters, lower-case characters, and numbers or special characters.
    • where supported, a 60-day password expiration for administrative accounts.
    • where supported, account lockout after 5 invalid attempts.
    • where supported, prevention of password reuse using a history of the last 24 passwords.
    • where supported, modifying at least 6 characters when changing passwords.

    !!! 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.
    
  4. Passwords are generally not stored directly in JupiterOne systems. When this is necessary, all system and application passwords must be stored and transmitted securely:

    • Passwords are stored in a hashed format according to NIST recommendations.
    • Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in Data Protection.
    • Transmitted passwords must be encrypted in flight pursuant to the requirements in Data Protection.
  5. Each information system automatically requires users to change passwords at a pre-determined interval as determined by the system owner and/or Security, based on the criticality and sensitivity of the data contained within the network, system, application, and/or database.
  6. Passwords are inactivated immediately upon an employee’s termination (refer to the Employee Termination Procedures in HR policy).
  7. All default system, application, and Vendor/Partner-provided passwords are changed before deployment to production.
  8. Upon initial login, users must change any passwords that were automatically generated for them.
  9. Password change methods must use a confirmation method to correct for user input errors.
  10. No password is ever stored directly in code, including configuration scripts.
  11. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security team via email.
  12. In cases where a user has forgotten their password, password reset procedures provided by Google G Suite shall be followed. The exact process depends on the system or application. If help is needed, users should email Security or request assistance via the Jira ServiceDesk.
  13. 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.

    • The password manager locally encrypts the password vault with the user’s master password before synchronizing to the cloud.
    • The master password must follow the password requirements listed above.
    • MFA must enabled in the password manager configuration.
    • Enrollment of the password manager is configured as an application in Google G Suite.
  14. Google G Suite routinely scans hashed passwords against hashes from known-compromised passwords. In addition, strong password enforcement is configured.

Single Sign On

Multi-factor Authentication

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.

!!! important

**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)

Role Based Access Control (RBAC)

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.

Temporary Access to AWS Accounts and Resources

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:

AWS Console Access

AWS CLI/SDK Access

Troubleshooting / Support Access

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.

Dual Control for Root Access

JupiterOne implements a Dual Control / Split Knowledge process to protect Root user access to our AWS accounts. The process works as follows:

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.

Remote Access / VPN

Platform Customer Access to Systems

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.

Access Establishment, Modification and Termination

  1. Requests for access to JupiterOne Platform systems and applications is made formally using the following process:

    1. An access request is created in the internal Jira ServiceDesk through either the new employee onboarding request or a specific access request from a JupiterOne employee.
    2. 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:

      • Google G Suite user in the Everyone group, and additional group based on role such as Development, Sales, Security
      • KnowBe4 account for security awareness training
      • JustWorks accounts for paperwork, benefits management, payroll, expense reporting, etc.
      • Jira ServiceDesk access for submitting support requests
      • Additional role based access (e.g. GitHub, and Jenkins access for a developer)
    3. Standard access may be provisioned at any time by account owners/administrators at any time during or after onboarding with approval of account owners and/or manager.
    4. If additional access is needed in addition to the above, a separate access request Issue (through Jira ServiceDesk) is required and the requester must include a description and justification as part of the access request. This initiates a Pull Request (PR) for review/discussion.
    5. Once the review is completed, the Security team approves or rejects the PR. If the PR is rejected, no further action is taken.
    6. 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.

      • New accounts will be created with a temporary secure password that meets all password requirements, which must be changed on the initial login.
      • All temporary password exchanges must occur over an authenticated channel.
      • For cloud accounts, access grants are provisioned in Google G Suite or using the access control mechanisms built into those services/applications.
      • Account management for non-production systems may be delegated to a JupiterOne employee at the discretion of the Security Officer.
  2. Special access, including access to production environments, is not granted until receipt, review, and approval by the JupiterOne Security Officer.
  3. All access requests are retained in the Jira ServiceDesk for future reference, generating a cryptographically secure audit trail.
  4. Temporary accounts are not used unless absolutely necessary for business purposes.

    • Accounts are reviewed by Security every 60 days to ensure temporary accounts are not left behind unnecessarily. ACC3
    • Accounts that are inactive for over 60 days are removed, unless an exception/extension is requested via the Jira ServiceDesk and approved. ACC3
  5. In the case of non-personal information, such as generic educational content, identification and authentication may not be required.

Access Termination

Security team receives access termination requests in one of the following conditions and processes it accordingly:

Access Reviews

Privileged Access

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:

Service Accounts

Employee Workstation / Endpoints Access and Usage

All workstations at JupiterOne are company owned, using one the following approved hardware vendors and operating systems:

  1. Workstations may not be used to engage in any activity that is illegal or is in violation of JupiterOne’s Acceptable Use Policy (AUP).
  2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through JupiterOne’s systems or services.
  3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to JupiterOne’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
  4. Solicitation of non-company business, or any use of JupiterOne’s information systems/applications for personal gain is prohibited.
  5. Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
  6. Workstation hard drives will be encrypted using FileVault (macOS), BitLocker (Windows) dm-crypt (Linux) or equivalent.
  7. All workstations must have host firewalls enabled to prevent unauthorized access unless explicitly granted.
  8. All workstations must have endpoint security software installed and actively running, if supported by the operating system.

Office Network and Wireless Access

  1. JupiterOne production systems are not accessible directly over wireless channels.
  2. Wireless access is disabled on all production systems.
  3. When accessing production systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.
  4. Wireless networks managed within JupiterOne non-production facilities (offices, etc.) are secured with the following configurations:

    • All data in transit over wireless is encrypted using WPA2 encryption;
    • Passwords are not currently on a rotation schedule because the office environments are considered insecure.
    • Passwords are changed immediately should a suspicious activity or indicator of compromise is detected.
    • Guest wireless access is on a separate SSID configured with different password and traffic VLAN.
    • Wireless access is managed by the Security team.

Production Access and Secrets Management

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.

Production Data Access

The following requirements and controls are in place for accessing production data by internal personnel:

Password Reset and other Helpdesk Requests

JupiterOne employees have the ability to obtain self-service support directly from supported business applications, such as password reset via Google G Suite.

If needed, users may use our internal service desk or email Security to obtain support.

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.