2022.1
JupiterOne makes every effort to assure all third party organizations are compliant and do not compromise the integrity, security, and privacy of JupiterOne or JupiterOne Customer data. Third Parties include Vendors, Customers, Partners, Subcontractors, and Contracted Developers.
JupiterOne policy requires that:
(a) A list of approved vendors/partners must be maintained and reviewed annually. VEND1
(b) Approval from management, procurement and security must be in place prior to onboarding any new vendor or contractor. Additionally, all changes to existing contract agreements must be reviewed and approved prior to implementation.
(c) For any technology solution that needs to be integrated with JupiterOne production environment or operations, a Vendor Technology Risk Review (VTRR) must be performed by the Security Team to understand and approve the risk. Periodic compliance assessment and SLA review may be required.
(d) JupiterOne Customers or Partners should not be allowed access outside of their own environment, meaning they cannot access, modify, or delete any data belonging to other 3rd parties.
JupiterOne security policy requires a risk review of vendor technology, prior to any technology being integrated to JupiterOne operations and/or infrastructure. Employees are required to engage security team to conduct such review. The request may be submitted by opening a Jira ServiceDesk issue through the JupiterOne internal help desk. Such requests will be reviewed within 2 business weeks, with some exceptions made for business reasons by the CISO and/or CEO.
The type of data being accessed will determine which department is responsible for conducting the review. For example, any tool that touches customer data requires review from the Security Team. Tools touching marketing data, requires review from the Marketing Team. The security team is responsible for delegating review of a prospective vendor to the respective department.
Vendor risk reviews will be conducted via evaluations of vendor artifacts such as audit reports and isolation architecture diagrams, to ensure the vendor’s security controls are commensurate with risks and demonstrate risk mitigation to an acceptable level.
If the reviewer is not satisfied with the artifacts, they should re-engage the internal stakeholder who initiated the vendor review to discuss alternative solutions to their use case or compensating controls.
If applicable, the reviewer should note the vendor’s approval status as an artifact in the JIRA SEC Project,
and ensure that this approval is reflected in the appropriate Vendor entity in the JupiterOne Platform.
GDPR. If the vendor processes data for customers from in the European Economic Area, United Kingdom or Switzerland (the “Designated Countries”), the vendor must be GDPR compliant and a Data Processing Agreement (DPA) is required.
SLA for Service Providers. For network and infrastructure service providers that support production and/or critical operations at JupiterOne, a Service Level Agreement (SLA) is defined and included in the service contract.
As appropriate, the executed agreement(s) are linked or attached to their
corresponding Vendor entity properties in the JupiterOne Platform.
Vendor contracts are reviewed either annually or according to the signed contract duration. VEND2
Based on the risk level and the sensitivity/criticality of data the vendor has access to, the vendor review may include an updated risk analysis performed by the security team in addition to legal and business review of contract terms.
If the vendor is a service provider, the Development Team monitors the service status of the provider according to its SLA. This is done by either manually reviewing the posted service status on the vendor’s status pages at least quarterly, or by setting up alarms for service interruption using automation. VEND3
The below scoring is used to help understand Vendor risks and business criticality better. By using a scoring method such as 1-3-6-9 we can reliably understand which of our vendors are more risky and which vendors we rely heavily on. This can help teams reduce reliance on single vendors, as well as implement solutions to reduce dependency and implement controls on high-risk vendors.
| Risk Scoring | Description |
|---|---|
| 1 | Vendor hosts no sensitive data and has no critical findings in a vendor review. |
| 3 | Vendor hosts 1 of the three sensitive data tag (PHI, PII, PCI), or has no sensitive data but does have a critical finding in a vendor review. |
| 6 | Vendor hosts 2 of the three sensitive data tag (PHI, PII, PCI), or hosts 1 sensitive data tags and has a critical finding. |
| 9 | Vendor hosts 3 of the three sensitive data tag (PHI, PII, PCI), or hosts 2 sensitive data tags and has a critical finding. |
| Criticality Score | Description |
|---|---|
| 1 | JupiterOne considers this to be a ‘quality of life’ vendor. If we had to stop using this vendor no noticeable impact would occur. |
| 3 | JupiterOne uses this vendor in it’s daily operations, but could find a replacement quickly and without disruptions to customers or SLA’s. |
| 6 | JupiterOne would be challenged to perform basic functionality without this vendor. Any changes in operations with this vendor will require strict review by the Security Team. |
| 9 | JupiterOne Cannot operate without this vendor. If this vendor went out of business tomorrow we would follow suit soon after. |
JupiterOne Security Team maintains an inventories of pre-approved business software and vendors in the JupiterOne Platform.
If additional commercial software, hardware system, or cloud services are needed, a request should be submitted through the Jira ServiceDesk. This will trigger the review / approval by the Security Team and any necessary procurement processes.
As applicable, JupiterOne Security Team may conduct a risk analysis on the software or system to ensure it complies with JupiterOne security, compliance and legal requirements and does not interfere with the existing security controls. If a risk is identified, additional controls should be identified and implemented (or planned) prior to acquisition. An alternative product may be considered as a result of the risk analysis.