Does Your CAASM Tool Capture Transitive Risk? It Really Should.

You are likely familiar with the cybersecurity adage: “You can’t protect what you don’t know about.” It’s common-sense enough wisdom, but if we’re being honest, we recognize that common sense does not equate to common practice.

Your first task as a security-conscious organization, then, is to get serious about asset inventory. You simply must know what you’re defending so you can analyze and reduce risks to your assets.

Your initial, naive attempts at such an inventory are likely to resemble lists or spreadsheets. Once you start such an effort, however, the scope of the task can seem to inflate like a balloon, and progress marches away from you as quickly as you seem to cover ground.

It’s not enough to have a partial asset inventory (or worse, multiple partial asset inventories), you must have a single, complete inventory that covers all the asset classes outlined in Sounil Yu’s Cyber Defense Matrix: Devices, Applications, Networks, Data, and Users.

All of those assets undergo various rates of flux and change, so the best time to have collected your asset inventory is always: five seconds ago.

Despite your attempts to extract an inventory that is complete, accurate, and very recent, it’s still likely not enough to actually help you with analysis and risk reduction (which is always your real goal!)


“Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.”
– John Lambert


To analyze risk to your assets, you must be able to identify asset relationships to one another. John Lambert, Distinguished Engineer at Microsoft Threat Intelligence Center, has a Six Degrees of Mallory example that illustrates how attackers take advantage of graph thinking to plan their attacks and targets. Lambert highlights that “For a High Value Asset (HVA) to be protected, all the dependent elements must be protected as thoroughly as the HVA—forming an equivalence class.” In other words, asset risk is transitive and must always be evaluated in the full context of related assets.

Transitive risk is a term for relationship-driven risk. It’s a type of risk exposure created from interconnected relationships between cyber assets. Transitive risk can occur if, for example, Asset A inherits risk from its relationship to Asset B. Asset B’s risk is then passed on to all of Asset A’s first, second, and third degree relationships.

CAASM_Transitive_Risk @4x


Level-Up your Defense Game with the JupiterOne Graph

The following J1QL queries highlight this risk analysis capability of the JupiterOne platform:

J1QL Query Example 1: Endpoint Blast Radius

Find Finding with severity='Critical'
(that (has|identified) HostAgent)?
that (has|protects) user_endpoint
that (owns|has) Person
that is User that (has|assigned) (Account|AccessRole|AccessKey|Application)
return tree


Here, we select all endpoints affected by a critical security finding, and ask for the graph that answers the question: What do the user accounts that belong to the owner of that insecure device allow access to?

The results might look similar to this (names have been randomized):


In the graph above, we see that the device owned by “Eugenia” has multiple critical hostagent alerts, and “Eugenia” has federated access through Okta to multiple applications (some of which may be sensitive). This graph likely represents real risk to the company.


J1QL Query Example 2: Data Exfiltration Risk Analysis

My colleague George Tang wrote this query to help analyze and spot targets of data exfiltration risk:

Find Internet
that allows Firewall
that protects (Function|WorkLoad|Application)
that assigned AccessRole
that assigned AccessPolicy
that allows as a DataStore with classification != 'public'
that has Finding with hasSensitiveData=true
where a.actions ~= 'GetObject'
return TREE


In this example, we want a graph that answers the question: What application workloads have read access to datastores that demonstrably contain sensitive information, that are also within a Firewall that does NOT perform egress filtering?

Those results might look like this:


It looks like the jupiter-foo-service-sensitive-data-writer Lambda function has read access to an S3 bucket containing sensitive PII data (with AWS Macie findings) in a development account, but the security group does not perform egress filtering.

This Lambda function, if compromised, could exfiltrate sensitive data. There is enough transitive risk here from the lack of egress filtering and access to sensitive data with findings, that this situation should really be addressed before the jupiter-foo-service-sensitive-data-writer is considered production-worthy.

Importantly, you can’t reach these conclusions based on piecemeal scanning or analysis of individual components.


Questions to Ask Your Vendor

As you evaluate tools in the burgeoning CAASM space, ask:

  • Does this tool allow me to reason accurately about blast radius and lateral movement options?
  • Does the tool cover all of the asset classes as outlined in the Cyber Defense Matrix?
  • How will this tool help mitigate transitive risk?

Does your CAASM tool do all this? It really should.


Posted By Erich Smith

Erich is the Principal Security Engineer at JupiterOne. An industry veteran of 20+ years, his background includes roles in software development, security, devops, systems administration, and compliance automation.

To hear more from Erich, get our newsletter. No spam, just the good stuff once or twice a month. Sign up below.