Synapse Glossary

This Glossary provides a quick reference for common terms related to Synapse technical and analytical concepts.

A

Addition, Automatic

See Autoadd.

Addition, Dependent

See Depadd.

Advanced Power-Up

See Power-Up, Advanced.

Admin Tool

See Tool, Admin.

Analytical Model

See Model, Analytical.

Auth Gate

An auth gate (short for “authorization gate”, informally a “gate”) is an object within a Service that may have its own set of permissions.

Both a Layer and a View are common examples of auth gates.

Autoadd

Short for “automatic addition”. Within Synapse, a feature of node creation where any secondary properties that are derived from a node’s primary property are automatically set when the node is created. Because these secondary properties are based on the node’s primary property (which cannot be changed once set), the secondary properties are read-only.

For example, creating the node inet:email=alice@mail.somecompany.org will result in the autoadd of the secondary properties inet:email:user=alice and inet:email:domain=mail.somecompany.org.

See also the related concept Depadd.

Axon

The Axon is a Synapse Service that provides binary / blob (“file”) storage within the Synapse ecosystem. An Axon indexes binaries based on their SHA-256 hash for deduplication. The default Axon implemenation stores the blobs in an LMDB Slab.

B

Base Tag

See Tag, Base.

Binary Unique Identifier

See BUID.

BUID

Short for Binary Unique Identifier. Within Synapse, a BUID is the globally unique (within a Cortex) SHA-256 digest of a node’s msgpack-encoded Ndef.

C

Callable Function

See Function, Callable.

Cell

The Cell is a basic building block of a Synapse Service, including the Cortex. See Synapse Architecture for additional detail.

Column, Embed

In Optic, a column in Tabular display mode that displays a property value from an adjacent or nearby node.

Column, Path Variable

In Optic, a column in Tabular display mode that displays arbitrary data in a column by defining the data as a Variable (a path variable or “path var”) within a Storm query.

Column, Property

In Optic, a column in Tabular display mode that displays a property value from the specified form.

Column, Tag

In Optic, a column in Tabular display mode that displays the timestamps associated with the specified tag. (Technically, Optic displays two columns - one for each of the min / max timestamps, if present).

Column, Tag Glob

In Optic, a column in Tabular display mode that displays any tags that match the specified tag or tag glob pattern.

Comparator

Short for Comparison Operator.

Comparison Operator

A symbol or set of symbols used in the Storm language to evaluate Node property values against one or more specified values. Comparison operators can be grouped into standard and extended operators.

Comparison Operator, Standard

The set of common operator symbols used to evaluate (compare) values in Storm. Standard comparison operators include equal to (=), greater than (>), less than (<), greater than or equal to (>=), and less than or equal to (<=).

Comparison Operator, Extended

The set of Storm-specific operator symbols or expressions used to evaluate (compare) values in Storm based on custom or Storm-specific criteria. Extended comparison operators include regular expression (~=), time/interval (@=), set membership (*in=), tag (#), and so on.

Composite Form

See Form, Composite.

Console Tool

See Tool, Console.

Constant

In Storm, a constant is a value that cannot be altered during normal execution, i.e., the value is constant.

Contrast with Variable. See also Runtsafe and Non-Runtsafe.

Constructor

Within Synapse, a constructor is code that defines how a Property value of a given Type can be constructed to ensure that the value is well-formed for its type. Also known as a Ctor for short. Constructors support Type Normalization and Type Enforcement.

Cortex

A Cortex is a Synapse Service that implements Synapse’s primary data store (as an individual Hypergraph). Cortex features include scalability, key/value-based node properties, and a Data Model which facilitates normalization.

Cron

Within Synapse, cron jobs are used to create scheduled tasks, similar to the Linux/Unix “cron” utility. The task to be executed by the cron job is specified using the Storm query language.

See the Storm command reference for the cron command and the Storm Reference - Automation document for additional detail.

Ctor

Pronounced “see-tore”. Short for Constructor.

D

Daemon

Similar to a traditional Linux or Unix daemon, a Synapse daemon (“dmon”) is a long-running or recurring query or process that runs continuously in the background. A dmon is typically implemented by a Storm Service and may be used for tasks such as processing elements from a Queue. A dmon allows for non-blocking background processing of non-critical tasks. Dmons are persistent and will restart if they exit.

Data Emitter Function

See Function, Data Emitter.

Data Model

See Model, Data.

Data Model Explorer

In Optic, the Data Model Explorer (found in the Help Tool) documents and cross-references the current forms and lightweight edges in the Synapse Data Model.

Deconflictable

Within Synapse, a term typically used with respect to Node creation. A node is deconflictable if, upon node creation, Synapse can determine whether the node already exists within a Cortex (i.e., the node creation attempt is deconflicted against existing nodes). For example, on attempting to create the node inet:fqdn=woot.com Synapse can deconflict the node by checking whether a node of the same form with the same primary property already exists.

Most primary properties are sufficiently unique to be readily deconflictable. GUID forms (see Form, GUID) require additional considerations for deconfliction. See the guid section of the Storm Reference - Type-Specific Storm Behavior document for additional detail.

Depadd

Short for “dependent addition”. Within Synapse, when a node’s secondary property is set, if that secondary property is of a type that is also a form, Synapse will automatically create the node with the corresponding primary property value if it does not already exist. (You can look at this as the secondary property value being “dependent on” the existence of the node with the corresponding primary property value.)

For example, creating the node inet:email=alice@mail.somecompany.org will set (via Autoadd) the secondary property inet:email:domain=mail.somecompany.org. Synapse will automatically create the node inet:fqdn=mail.somecompany.org as a dependent addition if it does not exist.

(Note that limited recursion will occur between dependent additions (depadds) and automatic additions (autoadds). When inet:fqdn=mail.somecompany.org is created via depadd, Synapse will set (via autoadd) inet:fqdn:domain=somecompany.org, which will result in the creation (via depadd) of the node inet:fqdn=somecompany.org if it does not exist, etc.)

See also the related concept Autoadd.

Derived Property

See Property, Derived.

Directed Edge

See Edge, Directed.

Directed Graph

See Graph, Directed.

Display Mode

In Optic, a means of visualizing data using the Research Tool. Optic supports the following display modes:

• Tabular mode, which displays data and tags in tables (rows of results with configurable columns).

• Force Graph mode, which projects data into a directed graph-like view of nodes and their interconnections.

• Statistics (stats) mode, which automatically summarizes data using histogram (bar) and sunburst charts.

• Geospatial mode, which can be used to plot geolocation data on a map projection.

• Tree Graph mode, which displays nodes as a series of vertical “cards” and their property-based links to other nodes.

• Timeline mode, which displays nodes with a time property in time sequence order.

Dmon

Short for Daemon.

E

Easy Permissions

In Synapse, easy permissions (“easy perms” for short) are a simplified means to grant common sets of permissions for a particular object to users or roles. Easy perms specify four levels of access, each with a corresponding integer value:

• Deny = 0

• Read = 1

• Edit = 2

• Admin = 3

As an example, the $lib.macro.grant(name, scope, iden, level) Storm library can be used to assign easy perms to a Macro. Contrast with Permission.

Edge

In a traditional Graph, an edge is used to connect exactly two nodes (vertexes). Compare with Hyperedge.

Edge, Directed

In a Directed Graph, a directed edge is used to connect exactly two nodes (vertexes) in a one-way (directional) relationship. Compare with Hyperedge.

Edge, Lightweight (Light)

In Synapse, a lightweight (light) edge is a mechanism that links two arbitrary forms via a user-defined verb that describes the linking relationship. Light edges are not forms and so do not support secondary properties or tags. They are meant to simplify performance, representation of data, and Synapse hypergraph navigation for many use cases. Contrast with Form, Edge.

Embed Column

See Column, Embed.

Entity Resolution

Entity resolution is the process of determining whether different records or sets of data refer to the same real-world entity.

A number of data model elements in Synapse are designed to support entity resolution. For example:

• A ps:contact node can capture “a set of observed contact data” for a person (ps:person) or organization (ou:org). You can link sets of contact data that you assess represent “the same” entity via their ps:contact:person or ps:contact:org properties.

• A risk:threat node can capture “a set of reported data about a threat”. If you assess that multiple sources are reporting on “the same” threat, you can link them to an authoritative threat organization via their risk:threat:org property.

• An ou:industryname node can capture a term used to refer to a commercial industry. You can link variations of a name (e.g., “finance”, “financial”, “financial services”, “banking and finance”) to a single ou:industry via the ou:industry:name and ou:industry:names properties.

Extended Comparison Operator

See Comparison Operator, Extended.

Extended Form

See Form, Extended.

Extended Property

See Property, Extended.

F

Feed

A feed is an ingest API consisting of a set of ingest formats (e.g., file formats, record formats) used to parse records directly into nodes. Feeds are typically used for bulk node creation, such as ingesting data from an external source or system.

Filter

Within Synapse, one of the primary methods for interacting with data in a Cortex. A filter operation downselects a subset of nodes from a set of results. Compare with Lift, Pivot, and Traverse.

See Storm Reference - Filtering for additional detail.

Filter, Subquery

Within Synapse, a subquery filter is a filter that consists of a Storm expression.

See Subquery Filters for additional detail.

Fork

Within Synapse, fork may refer to the process of forking a View, or to the forked view itself.

When you fork a view, you create a new, empty, writable Layer on top of the fork’s original view. The writable layer from the original view becomes read-only with respect to the fork. Any changes made within a forked view are made within the new writable layer. These changes can optionally be merged back into the original view (in whole or in part), or discarded. (Note that any view-specific automation, such as triggers, dmons, or cron jobs, are not copied to the forked view. However, depending on the automation, it may be activated if / when data is merged down into the original view.

Form

A form is the definition of an object in the Synapse data model. A form acts as a “template” that specifies how to create an object (Node) within a Cortex. A form consists of (at minimum) a Primary Property and its associated Type. Depending on the form, it may also have various secondary properties with associated types.

See the Form section in the Data Model Objects document for additional detail.

Form, Composite

A category of form whose primary property is an ordered set of two or more comma-separated typed values. Examples include DNS A records (inet:dns:a) and web-based accounts (inet:web:acct).

See also Form, Edge.

Form, Edge

A specialized composite form (Form, Composite) whose primary property consists of two Ndef values. Edge forms can be used to link two arbitrary forms via a generic relationship where additional information needs to be captured about that relationship (i.e., via secondary properties and/or tags). Contrast with Edge, Lightweight (Light).

Form, Extended

A custom form added outside of the base Synapse Data Model to represent specialized data. Extended forms can be added with the $lib.model.ext libraries. Note that whenever possible, it is preferable to expand the base Synapse data model to account for novel use cases instead of creating specialized extended forms.

Form, GUID

In the Synpase Data Model, a specialized case of a Simple Form whose primary property is a GUID. The GUID can be either arbitrary or constructed from a specified set of values. GUID forms have additional considerations as to whether or not they are Deconflictable in Synapse. Examples of GUID forms include file execution data (e.g., inet:file:exec:read) or articles (media:news).

Form, Simple

In the Synapse Data Model, a category of form whose primary property is a single typed value. Examples include domains (inet:fqdn) or hashes (e.g., hash:md5).

Function, Callable

In Storm, a callable function is a “regular” function that is invoked (called) and returns exactly one value. A callable function must include a return() statement and must not include the emit keyword.

Function, Data Emitter

In Storm, a data emitter function emits data. The function returns a generator object that can be iterated over. A data emitter function must include the emit keyword and must not include a return() statement.

Function, Node Yielder

In Storm, a node yielder function yields nodes. The function returns a generator object that can be iterated over. A node yielder function must not include either the emit keyword or a return() statement.

Fused Knowledge

See Knowledge, Fused.

G

Gate

See Auth Gate.

Global Default Workspace

See Workspace, Global Default.

Globally Unique Identifier

See GUID.

Graph

A graph is a mathematical structure used to model pairwise relations between objects. Graphs consist of vertices (or nodes) that represent objects and edges that connect exactly two vertices in some type of relationship. Nodes and edges in a graph are typically represented by dots or circles connected by lines.

See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.

Graph, Directed

A directed graph is a Graph where the edges representing relationships between nodes have a “direction”. Given node X and node Y connected by edge E, the relationship is valid for X -> E -> Y but not Y -> E -> X. For example, the relationship “Fred owns bank account #01234567” is valid, but “bank account #01234567 owns Fred” is not. Nodes and edges in a directed graph are typically represented by dots or circles connected by arrows.

See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.

GUID

Short for Globally Unique Identifier. Within Synapse, a GUID is a Type specified as a 128-bit value that is unique within a given Cortex. GUIDs are used as primary properties for forms that cannot be uniquely represented by a specific value or set of values.

GUID Form

See Form, GUID.

H

Help Tool

See Tool, Help.

Hive

The Hive is a key/value storage mechanism which is used to persist various data structures required for operating a Synapse Cell.

Hyperedge

A hyperedge is an edge within a Hypergraph that can join any number of nodes (vs. a Graph or Directed Graph where an edge joins exactly two nodes). A hyperedge joining an arbitrary number of nodes can be difficult to visualize in flat, two-dimensional space; for this reason hyperedges are often represented as a line or “boundary” encircling a set of nodes, thus “joining” those nodes into a related group.

See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.

Hypergraph

A hypergraph is a generalization of a Graph in which an edge can join any number of nodes. If a Directed Graph where edges join exactly two nodes is two-dimensional, then a hypergraph where a Hyperedge can join any number (n-number) of nodes is n-dimensional.

See Graphs and Hypergraphs for additional detail on graphs and hypergraphs.

I

Iden

Short for Identifier. Within Synapse, the hexadecimal representation of a unique identifier (e.g., for a node, a task, a trigger, etc.) The term “identifier” / “iden” is used regardless of how the specific identifier is generated.

Identifier

See Iden.

Ingest Tool

See Tool, Ingest.

Interface

In Synapse, an interface is a data model element that defines a set of secondary properties that are common to a set of related forms. Forms that should have these secondary properties can be defined so as to “inherit” the interface and its properties, as opposed to explicitly declaring each property on each form.

See the Interface section of the the Data Model Objects document for additional detail.

Instance Knowledge

See Knowledge, Instance.

K

Knowledge, Fused

If a form within the Synapse data model has a “range” of time elements (i.e., an interval such as “first seen”/”last seen”), the form typically represents fused knowledge – a period of time during which an object, relationship, or event was known to exist. Forms representing fused knowledge can be thought of as combining n number of instance knowledge observations. inet:dns:query, inet:dns:a, and inet:whois:email forms are examples of fused knowledge.

See Instance Knowledge vs. Fused Knowledge for a more detailed discussion.

Knowledge, Instance

If a form within the Synapse data model has a specific time element (i.e., a single date/time value), the form typically represents instance knowledge – a single instance or occurrence of an object, relationship, or event. inet:dns:request and inet:whois:rec forms are examples of instance knowledge.

See Instance Knowledge vs. Fused Knowledge for a more detailed discussion.

L

Layer

Within Synapse, a layer is the substrate that contains node data and where permissions enforcement occurs. Viewed another way, a layer is a storage and write permission boundary.

By default, a Cortex has a single layer and a single View, meaning that by default all nodes are stored in one layer and all changes are written to that layer. However, multiple layers can be created for various purposes such as:

• separating data from different data sources (e.g., a read-only layer consisting of third-party data and associated tags can be created underneath a “working” layer, so that the third-party data is visible but cannot be modified);

• providing users with a personal “scratch space” where they can make changes in their layer without affecting the underlying main Cortex layer; or

• segregating data sets that should be visible/accessible to some users but not others.

Layers are closely related to views (see View). The order in which layers are instantiated within a view matters; in a multi-layer view, typically only the topmost layer is writeable by that view’s users, with subsequent (lower) layers read-only. Explicit actions can push upper-layer writes downward (merge) into lower layers.

Leaf Tag

See Tag, Leaf.

Lift

Within Synapse, one of the primary methods for interacting with data in a Cortex. A lift is a read operation that selects a set of nodes from the Cortex. Compare with Pivot, Filter, and Traverse.

See Storm Reference - Lifting for additional detail.

Lightweight (Light) Edge

See Edge, Lightweight (Light).

M

Macro

A macro is a stored Storm query. Macros support the full range of Storm syntax and features.

See the Storm command reference for the macro command and the Storm Reference - Automation for additional detail.

Merge

Within Synapse, merge refers to the process of copying changes made within a forked (see Fork) View into the original view.

Model

Within Synapse, a system or systems used to represent data and/or assertions in a structured manner. A well-designed model allows efficient and meaningful exploration of the data to identify both known and potentially arbitrary or discoverable relationships.

Model, Analytical

Within Synapse, the set of tags (Tag) representing analytical assessments or assertions that can be applied to objects in a Cortex.

Model, Data

Within Synapse, the set of forms (Form) that define the objects that can be represented in a Cortex.

N

Ndef

Pronounced “en-deff”. Short for node definition. A node’s Form and associated value (i.e., <form> = <valu> ) represented as comma-separated elements enclosed in parentheses: (<form>,<valu>).

Node

A node is a unique object within a Cortex. Where a Form is a template that defines the charateristics of a given object, a node is a specific instance of that type of object. For example, inet:fqdn is a form; inet:fqdn=woot.com is a node.

See Node in the Data Model Objects document for additional detail.

Node Action

In Optic, a saved, named Storm query or command (action) that can be executed via a right-click context menu option for specified forms (nodes).

Node Data

Node data is a named set of structured metadata that may optionally be stored on a node in Synapse. Node data may be used for a variety of purposes. For example, a Power-Up may use node data to cache results returned by a third-party API along with the timestamp when the data was retrieved. If the same API is queried again for the same node within a specific time period, the Power-Up can use the cached node data instead of re-querying the API (helping to prevent using up any API query limits by re-querying the same data).

Node data can be accessed using the node:data type.

Node Definition

See Ndef.

Node, Runt

Short for “runtime node”. A runt node is a node that does not persist within a Cortex but is created at runtime when a Cortex is initiated. Runt nodes are commonly used to represent metadata associated with Synapse, such as data model elements like forms (syn:form) and properties (syn:prop) or automation elements like triggers (syn:trigger) or cron jobs (syn:cron).

Node, Storage

A storage node (“sode”) is a collection of data for a given node (i.e., the node’s primary property, secondary / universal properties, tags, etc.) that is present in a specific Layer.

Node Yielder Function

See Function, Node Yielder.

Non-Runtime Safe

See Non-Runtsafe.

Non-Runtsafe

Short for “non-runtime safe”. Non-runtsafe refers to the use of variables within Storm. A variable that is non-runtsafe has a value that may change based on the specific node passing through the Storm pipeline. A variable whose value is set to a node property, such as $fqdn = :fqdn is an example of a non-runtsafe variable (i.e., the value of the secondary property :fqdn may be different for different nodes, so the value of the variable will be different based on the specific node being operated on).

Contrast with Runtsafe.

O

Optic

The Synapse user interface (UI), available as part of the commercial Synapse offering.

P

Package

A package is a set of commands and library code used to implement a Storm Service. When a new Storm service is loaded into a Cortex, the Cortex verifies that the service is legitimate and then requests the service’s packages in order to load any extended Storm commands associated with the service and any library code used to implement the service.

Path Variable Column

See Column, Path Variable.

Permission

Within Synapse, a permission is a string (such as node.add) used to control access. A permission is assigned (granted or revoked) using a Rule.

Access to some objects in Synapse may be controlled by Easy Permissions.

Pivot

Within Synapse, one of the primary methods for interacting with data in a Cortex. A pivot moves from a set of nodes with one or more properties with specified value(s) to a set of nodes with a property having the same value(s). Compare with Lift, Filter, and Traverse.

See Storm Reference - Pivoting for additional detail.

Power-Up

Power-Ups provide specific add-on capabilities to Synapse. For example, Power-Ups may provide connectivity to external databases or third-party data sources, or enable functionality such as the ability to manage YARA rules, scans, and matches.

The term Power-Up is most commonly used to refer to Vertex-developed packages and services that are available as part of the commercial Synapse offering (only a few Power-Ups are available with open-source Synapse). However, many organizations write their own custom packages and services that may also be referred to as Power-Ups.

Vertex distinguishes between an Advanced Power-Up and a Rapid Power-Up.

Power-Up, Advanced

Advanced Power-Ups are implemented as Storm services (see Service, Storm). Vertex-developed Advanced Power-Ups are implemented as Docker containers and may require DevOps support and additional resources to deploy.

Power-Up, Rapid

Rapid Power-Ups are implemented as Storm packages (see Package). Rapid Power-Ups are written entirely in Storm and can be loaded directly into a Cortex.

Power-Ups Tool

See Tool, Power-Ups.

Primary Property

See Property, Primary.

Property

Within Synapse, properties are individual elements that define a Form or (along with their specific values) that comprise a Node. Every property in Synapse must have a defined Type.

See the Property section in the Data Model Objects document for additional detail.

Property Column

See Column, Property.

Property, Derived

Within Synapse, a derived property is a secondary property that can be extracted (derived) from a node’s primary property. For example, the domain inet:fqdn=www.google.com can be used to derive inet:fqdn:domain=google.com and inet:fqdn:host=www; the DNS A record inet:dns:a=(woot.com, 1.2.3.4) can be used to derive inet:dns:a:fqdn=woot.com and inet:dns:a:ipv4=1.2.3.4.

Synapse will automatically set (Autoadd) any secondary properties that can be derived from a node’s primary property. Because derived properties are based on primary property values, derived secondary properties are always read-only (i.e., cannot be modified once set).

Property, Extended

Within Synapse, an extended property is a custom property added to an existing form to capture specialized data. For example, extended properties may be added to the data model by a Power-Up in order to record vendor-specific data (such as a “risk” score).

Extended properties can be added with the $lib.model.ext libraries. Note that we strongly recommend that any extended properties be added within a custom namespace; specifically, that property names begin with an underscore and include a vendor or source name (if appropriate) as the first namespace element.

An example of an extended property is the :_virustotal:reputation score added to some forms to account for VirusTotal-specific data returned by that Power-Up (e.g., inet:fqdn:_virustotal:reputation).

Property, Primary

Within Synapse, a primary property is the property that defines a given Form in the data model. The primary property of a form must be defined such that the value of that property is unique across all possible instances of that form. Primary properties are always read-only (i.e., cannot be modified once set).

Property, Relative

Within Synapse, a relative property is a Secondary Property referenced using only the portion of the property’s namespace that is relative to the form’s Primary Property. For example, inet:dns:a:fqdn is the full name of the “domain” secondary property of a DNS A record form (inet:dns:a). :fqdn is the relative property / relative property name for that same property.

Property, Secondary

Within Synapse, secondary properties are optional properties that provide additional detail about a Form. Within the data model, secondary properties may be defined with optional constraints, such as:

• Whether the property is read-only once set.

• Any normalization (outside of type-specific normalization) that should occur for the property (such as converting a string to all lowercase).

Property, Universal

Within Synapse, a universal property is a Secondary Property that is applicable to all forms and may optionally be set for any form where the property is applicable. For example, .created is a universal property whose value is the date/time when the associated node was created in a Cortex.

Q

Queue

Within Synapse, a queue is a basic first-in, first-out (FIFO) data structure used to store and serve objects in a classic pub/sub (publish/subscribe) manner. Any primitive (such as a node iden) can be placed into a queue and then consumed from it. Queues can be used (for example) to support out-of-band processing by allowing non-critical tasks to be executed in the background. Queues are persistent; i.e., if a Cortex is restarted, the queue and any objects in the queue are retained.

R

Rapid Power-Up

See Power-Up, Rapid.

Relative Property

See Property, Relative.

Repr

Short for “representation”. The repr of a Property defines how the property should be displayed in cases where the display format differs from the storage format. For example, date/time values in Synapse are stored in epoch milliseconds but are displayed in human-friendly “yyyy/mm/dd hh:mm:ss.mmm” format.

Research Tool

See Tool, Research.

Role

In Synapse, a role is used to group users with similar authorization needs. You can assign a set of rules (see Rule) to a role, and grant the role to users who need to perform those actions.

Root Tag

See Tag, Root.

Rule

Within Synapse, a rule is a structure used to assign (grant or prohibit) a specific Permission (e.g., node.tag or !view.del). A rule is assigned to a User or a Role.

Runt Node

See Node, Runt.

Runtime Safe

See Runtsafe.

Runtsafe

Short for “runtime safe”. Runtsafe refers to the use of variables within Storm. A variable that is runtsafe has a value that will not change based on the specific node passing through the Storm pipeline. A variable whose value is explicitly set, such as $fqdn = woot.com is an example of a runtsafe varaible.

Contrast with Non-Runtsafe.

S

Secondary Property

See Property, Secondary.

Service

Synapse is designed as a modular set of services. Broadly speaking, a service can be thought of as a container used to run an application. We may informally differentiate between a Synapse Service and a Storm Service.

Service, Storm

A Storm service is a registerable remote component that can provide packages (Package) and additional APIs to Storm and Storm commands. A service resides on a Telepath API endpoint outside of the Cortex.

When the Cortex is connected to a service, the Cortex queries the endpoint to determine if the service is legitimate and, if so, loads the associated package to implement the service.

An advantage of Storm services (over, say, additional Python modules) is that services can be restarted to reload their service definitions and packages while a Cortex is still running – thus allowing a service to be updated without having to restart the entire Cortex.

Service, Synapse

Synapse services make up the core Synapse architecture and include the Cortex (data store), Axon (file storage), and the commercial Optic UI. Synapse services are built on the Cell object.

Simple Form

See Form, Simple.

Slab

A Slab is a core Synapse component which is used for persisting data on disk into a LMDB backed database. The Slab interface offers an asyncio friendly interface to LMDB objects, while allowing users to largely avoid having to handle native transactions themselves.

Sode

Short for “storage node”. See Node, Storage.

Splice

A splice is an atomic change made to data within a Cortex, such as node creation or deletion, adding or removing a tag, or setting, modifying, or removing a property. All changes within a Cortex may be retrieved as individual splices within the Cortex’s splice log.

Spotlight Tool

See Tool, Spotlight.

Standard Comparison Operator

See Comparison Operator, Standard.

Storage Node

See Node, Storage.

Stories Tool

See Tool, Stories.

Storm

Storm is the custom query language analysts use to interact with data in Synapse.

Storm can also be used as a programming language by advanced users and developers, though this level of expertise is not required for normal use. Many of Synapse’s Power-Ups (see Power-Up) are written in Storm.

See Storm Reference - Introduction for additional detail.

Storm Editor

Also “Storm Editor Tool”. See Tool, Storm Editor.

Storm Service

See Service, Storm.

Subquery

Within Synapse, a subquery is a Storm query that is executed inside of another Storm query.

See Storm Reference - Subqueries for additional detail.

Subquery Filter

See Filter, Subquery.

Synapse Service

See Service, Synapse.

T

Tag

Within Synapse, a tag is a label applied to a node that provides additional context about the node. Tags typically represent assessments or judgements about the data represented by the node.

See the Tag section in the Data Model Objects document for additional detail.

Tag, Base

Within Synapse, the lowest (rightmost) tag element in a tag hierarchy. For example, for the tag #foo.bar.baz, baz is the base tag.

Tag, Leaf

The full tag path / longest tag in a given tag hierarchy. For example, for the tag #foo.bar.baz, foo.bar.baz is the leaf tag.

Tag, Root

Within Synapse, the highest (leftmost) tag element in a tag hierarchy. For example, for the tag #foo.bar.baz, foo is the root tag.

Tag Column

See Column, Tag.

Tag Explorer

In Optic, the Tag Explorer (found in the Help Tool) provides an expandable, tree-based listing of all tags in your Synapse Cortex, along with their definitions (if present).

Tag Glob Column

See Column, Tag Glob.

Taxonomy

In Synapse, a taxonomy is a user-defined set of hierarchical categories that can optionally be used to further classify particular objects (forms). Taxonomies use a dotted namespace (similar to tags). Forms that support a taxonomy will have a secondary property whose Type is the taxonomy for that form (e.g., an ou:industry form has a :type secondary property whose type is ou:industry:type:taxonomy).

Telepath

Telepath is a lightweight remote procedure call (RPC) protocol used in Synapse. See Telepath RPC in the Synapse Architecture guide for additional detail.

Tool, Admin

In Optic, the Admin Tool provides a unified interface to perform basic management of users, roles, and permissions; views and layers; and triggers and cron jobs.

Tool, Console

In Optic, the Console Tool provides a CLI-like interface to Synapse. It can be used to run Storm queries in a manner similar to the Storm CLI (in the community version of Synapse). In Optic the Console Tool is more commonly used to display status, error, warning, and debug messages, or to view help for built-in Storm commands (see Storm Reference - Storm Commands) and / or Storm commands installed by Power-Ups.

Tool, Help

In Optic, the central repository for Synapse documentation and assistance. The Help Tool includes the Data Model Explorer, Tag Explorer, documentation for any installed Power-Ups (see Power-Up), links to the public Synapse, Storm, and Optic documents, and version / changelog information.

Tool, Ingest

In Optic, the primary tool used to load structured data in CSV, JSON, or JSONL format into Synapse using Storm. The Ingest Tool can also be used to prototype and test more formal ingest code.

Tool, Power-Ups

In Optic, the tool used to view, install, update, and remove Power-Ups (see Power-Up).

Tool, Research

In Optic, the primary tool used to ingest, enrich, explore, visualize, and annotate Synapse data.

Tool, Spotlight

Also known as simply “Spotlight”. In Optic, a tool used to load and display PDF or HTML content, create an associated media:news node, and easily extract and link relevant indicators or other nodes.

Tool, Stories

Also known as simply “Stories”. In Optic, a tool used to create, collaborate on, review, and publish finished reports. Stories allows you to integrate data directly from the Research Tool into your report (“Story”).

Tool, Storm Editor

Also known as simply “Storm Editor”. In Optic, a tool used to compose, test, and store Storm queries (including macros - see Macro). Storm Editor includes a number of integrated development environment (IDE) features, including syntax highlighting, auto-indenting, and auto-completion for the names of forms, properties, tags, and libraries.

Tool, Workflows

In Optic, the tool used to access and work with Workflows (see Workflow).

Tool, Workspaces

In Optic, the tool used to configure and manage a user’s Workspaces (see Workspace).

Traverse

Within Synapse, one of the primary methods for interacting with data in a Cortex. Traversal refers to navigating the data by crossing (“walking”) a lighweight (light) edge (Edge, Lightweight (Light)) betweeen nodes. Compare with Lift, Pivot, and Filter.

See Traversal Operations for additional detail.

Trigger

Within Synapse, a trigger is a Storm query that is executed automatically upon the occurrence of a specified event within a Cortex (such as adding a node or applying a tag). “Trigger” refers collectively to the event and the query fired (“triggered”) by the event.

See the Storm command reference for the trigger command and the Storm Reference - Automation for additional detail.

Type

Within Synapse, a type is the definition of a data element within the data model. A type describes what the element is and enforces how it should look, including how it should be normalized.

See the Type section in the Data Model Objects document for additional detail.

Type, Base

Within Synapse, base types include standard types such as integers and strings, as well as common types defined within or specific to Synapse, including globally unique identifiers (guid), date/time values (time), time intervals (ival), and tags (syn:tag). Many forms within the Synapse data model are built upon (extensions of) a subset of common types.

Type, Model-Specific

Within Synapse, knowledge-domain-specific forms may themselves be specialized types. For example, an IPv4 address (inet:ipv4) is its own specialized type. While an IPv4 address is ultimately stored as an integer, the type has additional constraints, e.g., IPv4 values must fall within the allowable IPv4 address space.

Type Awareness

Type awareness is the feature of the Storm query language that facilitates and simplifies navigation through the Hypergraph when pivoting across nodes. Storm leverages knowledge of the Synapse Data Model (specifically knowledge of the type of each node property) to allow pivoting between primary and secondary properties of the same type across different nodes without the need to explicitly specify the properties involved in the pivot.

Type Enforcement

Within Synapse, the process by which property values are required to conform to value and format constraints defined for that Type within the data model before they can be set. Type enforcement helps to limit bad data being entered in to a Cortex by ensuring values entered make sense for the specified data type (e.g., that an IP address cannot be set as the value of a property defined as a domain (inet:fqdn) type, and that the integer value of the IP falls within the allowable set of values for IP address space).

Type Normalization

Within Synapse, the process by which properties of a particular type are standardized and formatted in order to ensure consistency in the data model. Normalization may include processes such as converting user-friendly input into a different format for storage (e.g., converting an IP address entered in dotted-decimal notation to an integer), converting certain string-based values to all lowercase, and so on.

U

Universal Property

See Property, Universal.

User

In Synapse, a user is represented by an account in the Cortex. An account is required to authenticate (log in) to the Cortex and is used for authorization (permissions) to access services and perform operations.

V

Variable

In Storm, a variable is an identifier with a value that can be defined and/or changed during normal execution, i.e., the value is variable.

Contrast with Constant. See also Runtsafe and Non-Runtsafe.

See Storm Reference - Advanced - Variables for a more detailed discussion of variables.

Vault

In Synapse, a vault is a protected storage mechanism that allows you to store secret values (such as API keys) and any associated configuration settings. Vaults support permissions and can be shared with other users or roles. Granting ‘read’ access to a vault allows someone to use the vault contents without allowing them to see the vault’s secret values.

View

Within Synapse, a view is a ordered set of layers (see Layer) and associated permissions that are used to synthesize nodes from the Cortex, determining both the nodes that are visible to users via that view and where (i.e., in what layer) any changes made by a view’s users are recorded. A default Cortex consists of a single layer and a single view, meaning that by default all nodes are stored in one layer, all changes are written to that layer, and all users have the same visibility (view) into Synapse’s data.

In multi-layer systems, a view consists of the set of layers that should be visible to users of that view, and the order in which the layers should be instantiated for that view. Order matters because typically only the topmost layer is writeable by that view’s users, with subsequent (lower) layers read-only. Explicit actions can push upper-layer writes downward (merge) into lower layers.

W

Workflow

In Optic, a Workflow is a customized set of UI elements that provides an intuitive way to perform particular tasks. Workflows may be installed by Synapse Power-Ups (see Power-Up) and give users a more tailored means (compared to the Research Tool or Storm query bar) to work with Power-Up Storm commands or associated analysis tasks.

Workflows Tool

See Tool, Workflows.

Workspace

In Optic, a Workspace is a customizable user environment. Users may configure one or more Workspaces; different Workspaces may be designed to support different analysis tasks.

Workspace, Global Default

In Optic, a Workspace that has been pre-configured with various custom settings and distributed for use. A Global Default Workspace can be used to share a set of baseline Workspace customizations with a particular group or team.

Workspaces Tool

See Tool, Workspaces.