Why JupiterOne security redefined the vendor security risk assessment process

Several months ago, our JupiterOne security team decided to slightly redefine our approach to vendor security assessments. While our policy for Third Party Security and Vendor Risk Management has not changed significantly, we made some changes to our procedures. After several years of increasingly prominent and destructive supply chain security attacks, there is a need for security practitioners to think about third-party risk critically. 

The state of third-party risk definitely influenced our decision to redefine our approach to vendor risk assessments, but it was also influenced by the fact that literally no one likes doing these assessments. Even the types of security compliance professionals who love checklists at a cellular level loathe vendor security risk assessments. Most of us have historically disliked these activities because they are boring, but also because they feel really ineffective. How much peace-of-mind can a SOC 2 report and a self-attested questionnaire really offer? 

‍

Luckily, I am pleased to say our redefined process has made JupiterOne security’s vendor assessments significantly more enjoyable, effective, and streamlined. I hope our lessons learned help you strengthen your third-party security risk posture. Here’s what we did:

#1: We created a tiering system for vendors and aligned it with SRE

Not all vendors present equal security risk; there is a lot more riding on the security of a cloud hosting provider than a smaller vendor who doesn't host any sensitive data. We created a tiering system to determine vendor risk, with consideration to both operational importance and data privacy. We also aligned this tiering system with our site reliability engineering (SRE) team’s vendor service tiers.I spend a lot of time thinking about how security teams are moving much closer to site reliability engineering and DevOps teams, and the countless implications of this process. I imagine a future where organizations have fully-unified systems for responding to security and DevOps incidents, and unified standards for root cause analysis (RCA) post-incident. Creating a shared, organizational system for vendor tiering is not the solution we’ll need in this imagined future, but it feels like a step in the right direction.

‍

After we created vendor security and privacy tiers to align with our site reliability engineering’s tiers, we made updates to our internal documentation on approved vendors to include our best guesses at vendor’s tiers. We did not assign vendor tiers because JupiterOne’s security team is omniscient. Instead, we made these updates and shared them via Slack to spark dialogue in the spirit of Cunningham’s law. It was effective!

#2: We refined existing requirements for a vendor risk assessment

JupiterOne had already been using Jira Service Desk to track employee requests for a vendor security assessment, so we already had a pretty stellar template and workflow. We did choose to refine two requirements in our internal documentation (and Jira ticket templates) to make sure they were clear to our colleagues:

• We added a new, optional workflow component in the Jira service desk to include an Approve/Denied disposition for security vendor risk reviews. This allows us to  report on vendor risk assessment outcomes in JupiterOne Insights.
• We emphasized the fact that we need a use case to properly perform a vendor risk assessment and provided examples in our internal documentation. 

#3: We turbocharged the artifacts we require from prospective system owners

Previously, JupiterOne security had worked to make sure we understood the use case and plan for system administrators when doing a security assessment on a vendor. We still do this, however, we started requiring a few more things from our colleagues who make vendor security assessment requests. We now ask our colleagues to provide:

• The name of the system owner and system admins
• Their access review plan and proposed access review frequency
• A brief system monitoring plan 

‍

Ask More Questions During Tier 1 and Tier 2 Assessments

If you are facing a request for a new Tier 1 subprocessor, politely remind your coworker about the fact you’ll need to do a subprocessor notification as early in the process as possible. 

‍

I also strongly recommend asking for a brief system monitoring plan during any Tier 1 or Tier 2 vendor assessments. I cannot dictate what a ‘good monitoring plan’ would look like from a potential system owner at your organization, since it very much depends on the vendor and the use case. A potential system owner of a critical technology should, however, be able to explain how they plan to create alerts, who will receive those alerts, and who is responsible for logging into the system to fix issues after receiving an alert. Plus, it should be defined how quickly alerts must be resolved.  

Shared security responsibility is awesome, and it can reduce your operational overhead for third-party risk management!

#4: We stepped up the security documents we request from vendors

‍

JupiterOne security elected to start getting more documentation from potential vendors, particularly Tier 1, 2, and 3 vendors (or, vendors of critical, high, or medium importance). But, we also made this choice as the byproduct of numerous discussions about how to do better vendor security assessments. The documents we ask for should not create a burden on vendor security teams. Instead, they should give us meaningful visibility into a vendor’s security posture. Self-attestation on customer questionnaires is fine and dandy, but it does not give us a feeling of assurance. As a result, we chose to start requesting isolation architecture documentation for visibility into tenant isolation and software-bill-of-materials. 

‍

Approach Vendor Risk Like an Activist

Vendor security risk assessments are a lot more enjoyable when you approach the process with a security activist’s mindset. Borrow some tactics from your favorite activist investors, and simply scale them to your role as someone who makes security decisions about vendors. Security teams have a unique opportunity to influence their vendor’s security practices for the better, which can only benefit all of us. Consider updating your own process to reflect new types of documentation or a focus on diversity, equity, and inclusion. 

#5. We evolved our recurring vendor review requirements 

Annual vendor risk reviews can be even less fun than reviewing a new vendor. I do not have any easy solutions here. Frequent, open dialogue is important with your system owners to remind them to request a new risk review if their use case for a vendor changes. I suggest providing frequent reminders in Slack and Security Town Hall meetings, along with examples of the types of use case changes that should spark a new vendor security risk review.  I also recommend maintaining visibility into as many systems as possible using JupiterOne Insights and Alerts.

‍

That said, I strongly encourage you to adopt a tiering system like the example I shared above, and use it to influence your internal process for recurring vendor reviews to drive a culture of more effective third-party risk management in your organization.

‍

‍

Step #6: Update github so approved vendors are ingested into JupiterOne as a vendor entity

‍

JupiterOne maintains a public GitHub repository of common vendors and useful properties about these vendors, including a brief description of the vendor’s product, a link to their information security policy, privacy policy, and data processing agreements. This GitHub repository enables JupiterOne’s security team and our customers to ingest data about vendors into their JupiterOne instance as part of our data model for organizations, accounts, and vendor management.

Part of our vendor security risk assessment process involves checking this GitHub repository to ensure that a vendor is on the list, or submitting a pull request (PR) to add the vendor if they are not already there. Anyone can submit their vendors to this repository using a PR and the simple YAML template shown below for our friends and integration partners over at Snipe IT:

{
 "name": "Snipe-IT",
 "category": "Asset Inventory",
 "description": "IT asset management.",
 "privacyPolicy": "https://snipeitapp.com/privacy",
 "statusPage": "https://status.snipeitapp.com/",
 "webLink": "https://snipeitapp.com",
 "website": "https://snipeitapp.com",
 "_type": "snipeit",
 "aliases": []
}

We also choose to align our vendor approval process with our finance operations team, and update shared vendor lists in our internal Wiki (Confluence), and you may choose to do the same. 

Imagining a world where vendor security risk assessments are manageable

JupiterOne’s security team has seen significant improvements in the efficiency and peace-of-mind associated with our vendor security risk assessment since making these changes. While the process is not fully-automated, it’s significantly more consistent and has taken some steps in the right direction. Compliance should be a byproduct of effective security, and that involves greater and more consistent visibility into your vendor’s security posture. 

‍

‍