Building a Streamlined Cyber Risk Assessment Process using Jira and JupiterOne


Risk assessment is a foundational step to any security governance program. It is a mandatory step by regulations and compliance frameworks like HIPAA and GDPR. Unfortunately, performing a risk assessment is a fairly involved process that happens every year and typically takes days, if not weeks, each time.

Let that sink in ...Weeks.

Finding a Better Way

In today's digital age, is there a way to automate and streamline this repetitive process with high quality assurance on the output? Yes, there is!

My team and I had just completed another round of internal annual risk analysis. After three years of iterative and continuous improvements, I am finally ready to share how we, at LifeOmic and JupiterOne, use tools including Jira and JupiterOne (drinking our own champagne) to complete this entire process in less than a day.

There are various guides, frameworks, and models out there to help you tackle this age-old problem. I'm not going to get into the pros and cons of the different approaches. To simplify it (we like simple and lightweight approaches), it really boils down to doing these three things, and doing them well:

  1. Gather data in order to identify potential risks
  2. Document risks with a workflow to remediate, review, update, etc.
  3. Reporting and continuous monitoring


Gather Data

Data gathering is the first step to identifying potential risks. This is further divided into two parts:

1. Identify and inventory assets


We use JupiterOne (J1) to maintain a complete inventory of our assets. The majority of our assets, users, and devices are auto-discovered from our cloud infrastructure (we are primarily on AWS) and other digital environments and controls we have implemented, including Okta, Bitbucket, Github, Carbon Black, KnowBe4, etc.


We leverage tagging heavily to assign classification, owner, and other key tracking attributes to resources wherever possible. This is mostly achieved via Terraform in our infrastructure code. We use JupiterOne's J1QL query to track and ensure resources are properly tagged.

For example, the following query helps us identify any data store resources in our production environment that are unclassified or without an assigned owner.

Find DataStore with
 tag.AccountName =  'jupiterone-prod-us' and
 (classification = undefined or owner = undefined)

You can't protect what you can't see or what you don't know.

Asset Inventory with JupiterOne


We further enrich our inventory data, when applicable, with additional attributes. For example, we associate the hardware MFA token serial number to each of our AWS account entities in the J1 inventory. We add links to NDA or BAA or other contract documents as attributes to the Vendor entities in the J1 inventory. We also add additional attributes, such as criticality and risk, to resources, as needed.

This is done using simple YAML files, in a code repo (similar to infrastructure-as-code). Here's an example of a Vendor YAML:

- entityKey: Vendor:Zoom
 entityType: zoom
 entityClass: Vendor
   name: Zoom
   displayName: Zoom
   - IT
   description: collaboration- video conferencing
   validated: true
   approved: true
   approvalPRName: security-artifacts/2
   mainContactName: <our Zoom account rep>
   mainContactEmail: <his/her email>
   criticality: 5
   risk: 5
   tag.PHI: false
   tag.PII: false
   tag.PCI: false
   notes: <some additional notes>


Changes are reviewed via our standard pull request (PR) and code review process. When the PR is approved and merged into the master branch, our deploy process automatically pushes the changes to JupiterOne via API.

2. Perform threat modeling / analysis

What are the potential adverse scenarios and the probability and impact of each?

Once we have a full picture of what we are protecting, now we can start to put our heads around what we are up against.

  • Who may potentially target us?
  • What are the attack scenarios?
  • Are there recent business changes that may alter our external risk profile?
  • What resources are exposed?
  • What risks exist based on our configurations?
  • What is the likelihood of each of these scenarios happening? And what would be the impact when it does?
  • What mitigation or control can we put in place, if not already?

As we perform the analysis, we use JupiterOne's graph queries to help further discover unknowns and to visualize potential threats.

For example, we can query our asset graph in J1 for resources connected to the Internet, data stores allowing access publicly to everyone, and easily correlate those to the tags and attributes we've assigned during inventory — classification, owner, criticality, tagging of PHI or PII, etc.

Document Risks

We work as a team to identify risks using an informed, data-driven approach. For each risk item that needs to be captured, we turn to Jira.

In Jira, we created a project for Security and a specific Jira issue type called Risk. We've added specific attributes such as riskProbability, riskImpact, riskLevel, mitigatingControls, residualRisk, threatActor, etc. to the issue type itself. We've modified the workflow for this project and issue type to cover the following status of a risk: reported, in progress, mitigated, accepted, transferred.

Each risk item is documented as a Jira issue. Because our engineering team also uses Jira for development and product management, this makes it easy to assign people to take ownership of implementing risk remediation, or link the risk to another Jira issue in a different project / board.

jira sample ticket risk

To the right, you can see an example risk documented in Jira (not our actual risk).

We document risks as identified during our formal annual risk assessment and throughout the year as things change.

These risk items are then automatically pulled in to JupiterOne via the Jira integration for reporting and continuous monitoring. This allows us to create a visually appealing Risk Register dashboard in JupiterOne to share with the rest of our organization, including non-technical team members, senior management, and our auditors.

Example screenshot (not our actual risks):

Report and Monitor

At least once a year, we get together as a team, to formally review all current risk items and open new ones as needed. At the end of the annual risk assessment exercise, we generate a report for executive review and signing.

This is done via another automation using JupiterOne's tooling and data. The security-policy-builder CLI tool has an assess command that generates a HIPAA Risk Assessment report for us using a pre-designed template. The tool itself will populate relevant information into sections of the report, including, among other things:

  • company overview
  • policy procedures mapping
  • results from questions during the assessment run
  • gaps and findings
  • documented risks

Much of the data is pulled from JupiterOne. To get the list of risks is as simple as a few lines of code:

async function getRisksFromRegistry () {
 const query =
   'find Risk with updatedOn > or createdOn >';
 const j1Client = await initializeJ1Client();
 return j1Client.queryV1(query);

As you can see from the above code snippet, it is using the J1 Client to run a simple J1QL query to find the risks created or updated within the past year.

The CLI tool takes all the data and produces an assessment report in Markdown format. We go in and fill in any additional details marked as placeholder, as necessary.

Finally, we use Pandoc and convert it into Word, give it a nice template, and save it as PDF for signing and distribution.

And here's an example of a documented risk from a later section of the report (generated by code in Markdown):

Here's a screenshot of the executive summary portion of the report in final PDF format.

This entire report is 48 pages long, yet the whole process of report generation including formatting takes less than an hour. We can actually do this as often as we need to because it is so lightweight.

In addition to reporting, we have also set up alert rules and compliance control monitoring in JupiterOne. That allows us to receive alert notifications via email or Slack messages. We've also set up certain rules to auto create Jira tickets based on the results of an alert, or trigger remediation via AWS SNS/SQS or Webhook. But that's a topic for another time. Feel free to check them out on our features page though.

To summarize, we use JupiterOne to gather data (discovery, inventory, and analyze all of our digital assets), Jira to document risk and manage the workflow, and JupiterOne again for reporting, visualization, and continuous monitoring.

For us, risk analysis is a continuous process (that is largely automated). Because of that, the formal review and reporting process every year takes our team just a few hours from start to finish.

Erkang Zheng
Erkang Zheng

I founded JupiterOne because I envision a world where decisions are made on facts, not fear; teams are fulfilled, not frustrated; breaches are improbable, not inevitable. Security is a basic right.

We are building a cloud-native software platform at JupiterOne to deliver knowledge, transparency and confidence to every digital operation in every organization, large or small.

I am the Founder and CEO of JupiterOne, and also a cybersecurity practitioner  with 20+ years experience across IAM, pen testing, IR, data, app, and cloud security. An engineer by trade, entrepreneur at heart, I am passionate about technology and solving real-world challenges. Former CISO, security leader at IBM and Fidelity Investments, I hold five patents and multiple industry certifications.

Keep Reading

Why Your Business Needs Cloud Asset Management
April 10, 2024
Why Your Business Needs Cloud Asset Management

Organizations are transitioning to the cloud faster than ever to keep up with the changing consumer and business climate. According to Gartner, by 2023, 40% of all

‘Type and go’ - New JupiterOne search bar enhancements
October 30, 2023
‘Type and go’ - New JupiterOne search bar enhancements

JupiterOne aggregates and normalizes data from hundreds of different sources so you can identify and triage security risks easily.

Identify and eliminate endpoint device security gaps using the new JupiterOne Unified Device Matrix
October 6, 2023
Identify and eliminate endpoint device security gaps using the new JupiterOne Unified Device Matrix

It seems like a simple question. “Are any of our deployed user endpoint devices missing an endpoint detection and response agent?”

15 Mar 2022
One line headline, one line headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud eiut.

15 Mar 2022
One line headline, one line headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud eiut.

15 Mar 2022
One line headline, one line headline

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud eiut.