Elements

Elements are the building blocks of a Lantern project. They represent the components, actors, data stores, boundaries, and connections that make up the modeled system.

Elements belong to the project rather than to an individual diagram. Diagrams reuse project elements to visualize different parts of the system.

Because elements are project-wide:

• The same element can appear in multiple diagrams.
• An element should not be duplicated simply because it appears in another diagram.
• Changes to an element apply everywhere it is used.
• Assets and threats remain linked to the same element across diagrams.

Element metadata

Elements can include additional metadata that describes their implementation or operating context.

Examples include:

• Deployment context
• Transport mechanism
• Encryption
• Protocol
• Hosting environment
• Etc

Metadata provides additional context for automatic threat suggestions, assessment, and reporting.

Out-of-scope elements

An element can be marked as out of scope.

Out-of-scope elements remain part of the project so they can provide context and preserve relationships, but they are excluded from the current security assessment.

For example, a third-party service may be included because the product communicates with it, even though the internal design of that service is outside the scope of the project.

An out-of-scope element can still:

• Appear in diagrams
• Connect to other elements
• Participate in flows
• Provide context for threats affecting in-scope elements

Element types

Boundary

A boundary groups elements that share a deployment, ownership, network, security, or trust context.

A boundary can contain:

• Processes
• Entities
• Stores
• Other boundaries

Because boundaries can contain other boundaries, they can represent hierarchical environments.

For example:

• A cloud environment can contain a virtual network boundary.
• A virtual network can contain application and database boundaries.

Flows can cross boundaries. A flow crossing a boundary may represent a change in trust, ownership, network context, or applied security controls.

Boundaries group elements but do not process, send, receive, or store data themselves.

Flow

A flow represents communication or data movement between two elements. It always has a source and a destination. It describes the direction in which data, commands, events, or other information moves through the system.

A flow can appear in multiple diagrams when those diagrams show the same underlying relationship.

Assets can be linked to flows to show how they travel through the system.

Contextual flows

A flow can be marked as contextual. A contextual flow exists only for visualization purposes. It helps explain a diagram but does not represent an actual data transfer in the underlying security model.

Contextual flows can be used to:

• Show a relationship that makes a diagram easier to understand
• Connect elements visually in a simplified overview
• Provide orientation without modeling an actual transfer

A contextual flow can also be marked as bidirectional, indicating that the connection goes both ways.

A contextual flow should not be interpreted as evidence that data or assets move between its source and destination.

Process

A process represents a component that performs work or transforms data.

Processes can represent:

• Applications
• Services
• APIs
• Functions
• Background workers
• Business processes
• Devices that process information

A process receives data through incoming flows and sends data through outgoing flows.

Processes can:

• Connect to entities, stores, and other processes through flows
• Be contained by boundaries
• Process or transform assets
• Have threats linked to them
• Appear in multiple diagrams

The same process should be reused across diagrams when it represents the same underlying component.

Entity

An entity represents a person, role, organization, device, or external system that interacts with the modeled system.

Entities can represent:

• Users
• Administrators
• External services
• Partner systems
• Third-party providers
• External devices

An entity communicates with other elements through flows.

Entities can:

• Send data to a process
• Receive data from a process
• Be contained by a boundary
• Have assets associated with their interactions
• Have threats linked to them
• Appear in multiple diagrams

Store

A store represents a location where data is retained.

Stores can represent:

• Databases
• Object storage
• File systems
• Caches
• Message queues
• Browser storage
• Configuration stores
• Physical records

Stores receive and provide data through flows.

Stores can:

• Connect to processes through incoming and outgoing flows
• Be contained by boundaries
• Retain assets
• Have threats linked to them
• Appear in multiple diagrams

Linking assets to stores makes it possible to identify where important information is retained throughout the project.