Cyber Asset Relationships Matter - Analyzing Relationship Mapping
In Cyber Asset Relationships Matter – Part One, we defined what the term "cyber asset relationship" means and explained the importance of modeling those relationships. We'll continue that discussion here, and include a walk-through video of how to use a J1 Relationship Map to explore and discover relationships within complex systems.
Analyze Cyber Assets with Dynamic Relationship Mapping
It's easiest to explain mapping with a simple, video example. Erkang Zheng walks through a basic query for a single person to explore the assets affected by that person. Following the video is a breakdown of the various steps as we expand the graph.
The example starts with finding the relationships between a Developer ("Carter"), his end-user device, the code repo he has opened a pull request to, and which AWS Lambda Function the code defines (or that the code is deployed to).
Query
Find Device
that owns Person with name~='Carter'
that is User
that opened PR
that has CodeRepo
that defines Function
return TREE
Basic Graph
Device and HostAgent
- the host security policy applied to the device, and
- the 360 alerts/findings associated with Carter's device
Person
If you expand on the Person (employee), you can see:
- all the other user accounts that Carter has (what he has access to),
- and other relationships, such as his manager (Phil), training assigned/completed (not in this graph)
Code Repo
Expand on the Code Repo (jupiter-questions-service), and you will see:
- it is part of the "JupiterOne" product/project,
- three other code repos uses it (as a dependency) and it uses (depends on) 12 other repos (because of micro-services architecture), and
- it has 11 code analysis findings (from Snyk), which means the 3 other repos depending on it might also be impacted by these vulnerabilities
Infrastructure
If you expand a few times on the infrastructure side (Lambda function, security groups, API gateway, etc.), you will get:
- what can trigger the function to execute (the API gateway),
- how the API gateway is connected to the Internet (via a Cloudfront Gateway),
- which SSL/TLS certificate is used,
- which DNS record points to the gateway,
- the Web Application Firewall (WAF) rule that protects the internet facing application resource, and
- the IAM roles/policies that allow access to the lambda function.
On the more internal side, you can see the 3 private subnets the lambda function has access to — if you expand further into those subnets, which I did not in this graph, you'll also see what other resources (server instances, database instances, etc) are in those subnets and be able to get an idea that if the lambda function is vulnerable and compromised, what could be the blast radius and downstream impact.
Summary
This was a high level overview of the capabilities for making cyber assets visible through a JupiterOne Relationship Map. As you get more comfortable with the concept, you can trigger alerts and automation on any of the information, graphs, and subgraph changes.
In modern systems, it's impossible to keep track of your assets without an automated tool to discover and document those assets. The simplest solution we have found is to dynamically display those assets in an expandable/contractable graph, giving you full visibility into your cyber assets, with the additional advantage of being able to manage those assets within a single dashboard.
Join the J1 Community (info is below) to get notified as we release more videos in this multi-part series.
