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:
- Gather data in order to identify potential risks
- Document risks with a workflow to remediate, review, update, etc.
- 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
Discovery
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.
Tagging
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.
Enrichment
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
properties:
name: Zoom
displayName: Zoom
category:
- IT
description: collaboration- video conferencing
validated: true
approved: true
approvalPRLink: https://bitbucket.org/lifeomic/security-artifacts/pull-requests/2
approvalPRName: security-artifacts/2
website: https://www.zoom.us
mainContactName: <our Zoom account rep>
mainContactEmail: <his/her email>
linkToBAA: https://lifeomic.sharepoint.com/Shared%20Documents/Security,%20Privacy%20and%20Compliance/NDA%20and%20BAA%20Documents/LifeOmic_Zoom_BAA-SIGNED.pdf
statusPage: https://status.zoom.us/
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.
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 > date.now-1yr or createdOn > date.now-1yr';
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.
