Visual families represent relationships between entities in a security event
and help identify key actors and the flow of a security incident.
Additionally, visual families define which entity types can be involved in the event.
When you map event fields to entities, the allowable entity types are predetermined
by the visual family assigned to that event type.
Visual families are applied to events from a specific type or product, and are
dynamically aggregated with other events to create a visual entity graph for the entire alert and case.
You can view this graph from the
Event configuration > visualization page or the
Case explorer.
Google Security Operations provides a collection of predefined visual families
that cater to many common alert types. The default visual family includes all entity
types and fundamental relationships.
Each visual family consists of multiple rules. Each rule contains up to four
sources, up to four destinations, and a connection type. Both sources and destinations
represent entity types relevant to the alert, and connections between them are
either Linked or Typed.
Typed connections link the primary entities (actors) within an alert. They typically represent
represent an action performed by one entity on another (or itself)
and are displayed as an arrowed line.
Each visual family must contain a single typed connection rule.
Linked connections connect two or more logically related entities,
such as a hostname and IP address, or an email and username. They are represented
by a dotted line, signifying this logical relationship.
Define a visual family
Identify the event requiring a visual family.
Classify and map the fields
to their respective entity types. For this example, use the following
Suspicious Connection event.
Classify event fields to specific entity types as follows:
Field
Entity Type
hostname
SourceHostName
process_name
SourceProcessName
process_sha256
FileHash
destination_domain
DestinationDomain
destination_ip_address
DestinationAddress
Go to Settings > Ontology > Visual Families.
Select
add
Add and enter a name and description.
Define the mandatory typed connection rule by identifying the primary action. In this example, because a process created a connection to a domain, the process entity is the source and the domain entity is the destination.
Define logically related entities with linked connection rules.
Using the same event example, you can observe several relations:
`SourceProcessName` was executed on the `SourceHostName`.
The `SourceProcessName` hash is the `FileHash` entity
`DestinationDomain` and `DestinationAddress` represent the process destination.
Save the visual family. Once saved, you can optionally add an image that represents the
visual family in the Settings > Ontology > Visual Families table.
Completing these steps creates a graphical visualization that shows the
relationships and connections between entities.
Floating entities
A floating entity is one that appears in a graph visualization without any connections to other entities. This can happen for a few key reasons, and understanding why is crucial for effective data analysis and visualization:
Missing a connection rule in the visual family: The visual family, which defines how events are displayed, might not have a rule to link the floating entity type to an existing entity type within the event. For example, a User entity might be defined, but there's no rule specifying that it should be connected to a File entity in a "File Access" event.
Incomplete Event Data: The event data itself may be missing the information needed to create a link. For example, an event for a network connection might lack a destination IP address, preventing it from being connected to a Host entity.
Isolated Entities: An entity might be created but never referenced by any other event, making it "isolated". For example, a new user account is created but hasn't performed any actions yet that would generate events to link to it.
To address floating entities, you can do the following actions:
Review the Visual Family: Check if the visual family has the necessary rules to connect the entity types. If not, you may need to create a new rule to establish the relationship.
Inspect the raw event data: Examine the raw data of the event to see if the required fields for mapping (for example, source IP, destination port, user ID) are present.
Adjust the field mapping: If the data exists but isn't being mapped correctly, adjust the field mapping to ensure the right event fields are populating the entity properties
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eVisual families define relationships between entities and protagonists from third-party applications within Google SecOps SOAR.\u003c/p\u003e\n"],["\u003cp\u003eVisual families are configured in the Event Configuration > Visualization screen and displayed in the Explore Cases screen to show entity interactions.\u003c/p\u003e\n"],["\u003cp\u003eYou can create new visual families or clone existing ones via Settings > Ontology > Visual Families and then define family rules in the Family Rules screen.\u003c/p\u003e\n"],["\u003cp\u003eWhen defining family rules, you specify the source of information, the destination within Google Security Operations, and the relation type, which can be either an action or a connection.\u003c/p\u003e\n"],["\u003cp\u003eVisual Families can be exported and imported as a zip file, containing the details in a JSON file.\u003c/p\u003e\n"]]],[],null,["Map security event relationships with visual families \nSupported in: \nGoogle secops [SOAR](/chronicle/docs/secops/google-secops-soar-toc) \n*Visual families* represent relationships between entities in a security event\nand help identify key actors and the flow of a security incident.\nAdditionally, visual families define which entity types can be involved in the event. When you map event fields to entities, the allowable entity types are predetermined by the visual family assigned to that event type.\n\nVisual families are applied to events from a specific type or product, and are\ndynamically aggregated with other events to create a visual entity graph for the entire alert and case.\nYou can view this graph from the [Event configuration \\\u003e visualization](/chronicle/docs/soar/admin-tasks/ontology/configure-mapping-and-assign-visual-families) page or the\n[Case explorer](/chronicle/docs/soar/investigate/working-with-cases/explore-entities-and-alerts-investigation).\n\nGoogle Security Operations provides a collection of predefined visual families\nthat cater to many common alert types. The default visual family includes all entity\ntypes and fundamental relationships.\n\nEach visual family consists of multiple rules. Each rule contains up to four\nsources, up to four destinations, and a connection type. Both sources and destinations\nrepresent entity types relevant to the alert, and connections between them are\neither *Linked* or *Typed*.\n\n- **Typed** connections link the primary entities (actors) within an alert. They typically represent represent an action performed by one entity on another (or itself) and are displayed as an arrowed line. Each visual family must contain a single typed connection rule.\n- **Linked** connections connect two or more logically related entities, such as a hostname and IP address, or an email and username. They are represented by a dotted line, signifying this logical relationship.\n\nDefine a visual family **Note:** Changes to ontology (visual families or mappings) apply only to cases ingested *after* the definition is saved, not retroactively to existing alerts.\n\n1. Identify the event requiring a visual family.\n2. Classify and map the fields to their respective entity types. For this example, use the following **Suspicious Connection** event. \n\n ```\n {\n \"name\": \"Suspicious Connection\", \n \"product\": \"SecOps\", \n \"event_type\": \"Suspicious connection\", \n \"hostname\": \"USER_PC\", \n \"process_sha256\": \"6857fee8812490499164bb7efb7f457d038e82140bb1fa0adbd0dc018e404f84\", \n \"process_name\": \"notepad.exe\", \n \"destination_domain\": \"google.com\",\n \"destination_ip_address\": \"8.8.8.8\" \n }\n \n ```\n3. Classify event fields to specific entity types as follows:\n\n |------------------------|--------------------|\n | **Field** | **Entity Type** |\n | hostname | SourceHostName |\n | process_name | SourceProcessName |\n | process_sha256 | FileHash |\n | destination_domain | DestinationDomain |\n | destination_ip_address | DestinationAddress |\n\n4. Go to **Settings \\\u003e Ontology \\\u003e Visual Families**.\n5. Select add **Add** and enter a name and description.\n6. Define the mandatory typed connection rule by identifying the primary action. In this example, because a process created a connection to a domain, the `process` entity is the source and the `domain` entity is the destination.\n7. Define logically related entities with linked connection rules. Using the same event example, you can observe several relations:\n - \\`SourceProcessName\\` was executed on the \\`SourceHostName\\`.\n - The \\`SourceProcessName\\` hash is the \\`FileHash\\` entity\n - \\`DestinationDomain\\` and \\`DestinationAddress\\` represent the process destination.\n8. Save the visual family. Once saved, you can optionally add an image that represents the visual family in the **Settings \\\u003e Ontology \\\u003e Visual Families** table.\n9. Completing these steps creates a graphical visualization that shows the relationships and connections between entities.\n\nFloating entities\n\nA *floating entity* is one that appears in a graph visualization without any connections to other entities. This can happen for a few key reasons, and understanding why is crucial for effective data analysis and visualization:\n\n- **Missing a connection rule in the visual family**: The visual family, which defines how events are displayed, might not have a rule to link the floating entity type to an existing entity type within the event. For example, a User entity might be defined, but there's no rule specifying that it should be connected to a File entity in a \"File Access\" event.\n- **Incomplete Event Data**: The event data itself may be missing the information needed to create a link. For example, an event for a network connection might lack a destination IP address, preventing it from being connected to a Host entity.\n- **Isolated Entities**: An entity might be created but never referenced by any other event, making it \"isolated\". For example, a new user account is created but hasn't performed any actions yet that would generate events to link to it.\n\nTo address floating entities, you can do the following actions:\n\n- **Review the Visual Family**: Check if the visual family has the necessary rules to connect the entity types. If not, you may need to create a new rule to establish the relationship.\n- **Inspect the raw event data**: Examine the raw data of the event to see if the required fields for mapping (for example, source IP, destination port, user ID) are present.\n- **Adjust the field mapping**: If the data exists but isn't being mapped correctly, adjust the field mapping to ensure the right event fields are populating the entity properties\n.\n\nLearn more about how to [create entities, mapping and modeling](/chronicle/docs/soar/admin-tasks/ontology/create-entities-mapping--modeling) and [configure events](/chronicle/docs/soar/admin-tasks/ontology/configure-mapping-and-assign-visual-families).\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]