Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.zetafence.com/llms.txt

Use this file to discover all available pages before exploring further.

Queries on Hypergraphs are powerful because they allow to unravel the intricate connections between entities faster than a detective solving a mystery using a map made entirely of string and thumbtacks. Zetafence(TM) developed queries on Hypergraphs in-house using Cypher graph query language. Graph queries serve as a natural and efficient mechanism for modeling a variety of use cases such as tracking threat impacts, detecting anomalous behavior, network connectivity analysis, and knowledge graphs. Such queries allow flexible and efficient querying of complex relationships between graph nodes. That said, queries perfofmed on Hypergraphs are entirely different from traditional graph queries. For instance, a Hypergraph query such as finding the largest number of operations allowed from an user to a resource could not be done using regular graphs with just two-vertex associations without a large number of graph traversals. With Hypergraphs, such an operation is trivial, and efficient utilizing Set-theoretic modeling. Figure below illustrates Hypergraphs Query Infrastructure in Zetafence platform. Zetafence Query Queries on Hypergraphs takes into account the unique attributes set on Hypergraph entities, and Hyperedges. Consider the following graphical relationship among VMs on VPC, role, and policies. 
{VM1[:VPC1], VM2[:VPC2], VM3[:VPC3]} -> "is_a_developer" -> {Policy1, Policy2}
This specifically indicates that we want to configure only VMs on VPC1 with policies for a developer. To see if that is the case, one can easily query on Hypergraph as follows: 
MATCH (vm:'VM', vm:'VPC1'} -[d:'is_a_developer']->(Policy) RETURN Policy.Name
Following are similar queries on Hypergraph in the system. List all suspicious domains accessed by user `laughing_franklin 
MATCH (u:yucca_user {id: 'laughing_franklin'}), (d:yucca_suspected_domain)-->(d:yucca_suspected_domain) RETURN u.Name,d.Name
List which cluster roles are bound to which roles 
MATCH (u:k8s_clusterrole),(t:k8s_role)--(t:k8s_role) RETURN u.Id,t.Id