Best Practices for Views & Layers

by savage | 2023-06-02

One of Synapse’s most powerful attributes is the Views and Layers architecture, which organizations can leverage to manage data visibility and collaboration among different users and teams. While we designed Synapse to serve as a single platform for use among multiple teams within an organization, there are many instances in which an organization might want to configure separate workspaces for each team, or at least not want all users and teams to possess read/write access to all the data within the Cortex. With Synapse’s Views and Layers feature, organizations have the flexibility to customize their Cortex to manage team and user collaboration spaces and better control what users and teams have access to certain data. Organizations can leverage Views and Layers to stack and manage their data, increasingly restricting access and visibility as needed going up through the stack.

What are Views and Layers?

By default, a Cortex consists of a single Layer and a single View. The Layer is where nodes are stored and permission enforcement takes place. Users access that data through the accompanying View. The image below depicts a user with read/write access to data stored in a Layer, and the View through which the user can interact with that data:

In one of our past webinars, we discussed the fork and merge workflow, in which a user can "fork a View" and create a new private and writable Layer. The user can work out of this new Layer before reviewing their changes and either merging them down into the underlying Layer or discarding them. The graphic below provides an example of this workflow, in which a Senior Intelligence Analyst forked a View (the Blog Ingest View) to create a new private Layer in which to ingest and process data from a blog. The analyst then merges the changes down into the underlying Shared Analysis Layer, to which they, the DFIR lead, SOC Lead, and others have read/write access through the Shared Analysis View.

General Best Practices When Working with Views and Layers

When it comes to working with Views and Layers, there are a few things to keep in mind:

When starting on a new task, fork a View to work out of rather than writing directly to a permanent or production Layer. Working out of a forked View can help protect the data in the underlying View from inadvertent changes, while allowing for easier cleanup should something go awry - if need be, the user can also just delete their fork and create a new one. When working out of a forked View, a user has the opportunity to review changes that they’ve made (and correct any errors found) before merging the data down into the production Layer.

Forked Views for either individual users or specified tasks should be ephemeral and involve frequently reviewing and merging changes to prevent data siloing. By default, a user who forks a View is the only one (with the exception of Global Administrators) with access to the data written to that new Layer. This can raise the risk of data silos in the event that the user maintains that forked View for an extended period of time. While working on a task in a forked View, users should make a habit of frequently reviewing their changes and merging data downwards to prevent creating data silos.

Forked Views for team use or multi-team internal collaboration may be longer-lasting or even permanent and should involve incrementally reviewing and merging changes down to the underlying Layer as appropriate. Although the team(s) using these forked Views may intend to maintain them long term as an internal collaboration space, they should incrementally review and merge changes into the underlying Layer as appropriate to allow for a more manageable review process. Analysts can use the diff command with optional filters to lift and view changes (such as running diff | +syn:tag to view any newly created syn:tag nodes) and can then use the | merge --apply command to merge selected nodes down into the underlying Layer.

Restrict access to Global Administrator roles, particularly if relying on Views and Layers for data privacy and protection. While forked Views are only accessible to the user who created them (and anyone else the user decided to share access with), Global Admins can see and edit everything. Therefore, we advise organizations that are implementing multilayered systems for data protection and privacy purposes to restrict the Global Admin roles to just those users who require them.

Uses for a Multilayered System

Users and organizations may create multiple Layers or forked Views within a Cortex to support a variety of use cases, all of which ultimately relate to the ability to segment data and control visibility and access. These use cases may include:

Testing: Forking a View can provide a scratch space in which to test automation, a Power-Up, or other capability, as well as evaluate a new data source. Users will have visibility into the data in the underlying View, while protecting it from unintentional changes. Using a forked View also allows for an easy way to discard data and changes when the testing has concluded.

Training new users: A user who forks a View has full permissions within that View, which organizations can take advantage of when training new Synapse users. The user can practice modeling and tagging data, as well as using Synapse's other features, all while protecting the data in the underlying Layer. The user can grant teammates access to their View so their colleagues can review their work, and potentially help merge the data down, if appropriate. Organizations can withhold merge permissions from the new user to prevent accidental merges.

Task-based scratch spaces: Organizations can also use the fork and merge workflow to provide users with their own short-term scratch space in which to conduct research for a specific task (rather than needing to write directly to a more permanent, underlying Layer). Users can optionally share access to a forked View with others for collaboration purposes.

Collaboration between specific teams within an organization: Multilayered implementations can also allow for better collaboration between different teams within an organization. For example, an organization may design their Cortex to consist of a long-term, internal, Shared Analysis View forked from the Published Intelligence View, and provide multiple teams access to the View. This would allow the teams to collaborate internally and merge their findings down into the Published Intelligence Layer.

Restricting access to sensitive data: Organizations that wish to restrict access to sensitive data can use a forked View to do so, given that the user who forks a View is the only one (with the exception of Global Admins) with access to that View unless they share it with others. An incident response team working on a sensitive case could therefore fork a View from an internal collaboration View and share it with those users working on the case. The users will be able to add their own data and conduct their own research and analysis, all while benefiting from visibility into existing data within the underlying Layers. At the end of the investigation, the team can selectively merge down the data they are permitted to keep before deleting the View.

Rotating large sets of data in and out: Organizations with large amounts of time-bound data that they want to regularly cycle in and out of their Cortex can do so by placing that data in its own read-only Layer beneath the internal collaboration Layer. The organization can then remove that Layer entirely when it is time to "age out" that data, and replace it with a Layer containing the new data.

Preventing changes to certain data sets: Organizations can implement a multilayered configuration to prevent users from making changes to certain data sets. For example, an organization may have a separate, read-only Layer containing published or third-party data that sits beneath the read/write Layer, so that users will have visibility into that data but cannot alter it.

Designing a Multilayered Configuration

There are many ways that organizations can design a multilayered configuration for their Synapse instance depending on their separate use cases. In this section, we'll walk through an example configuration that an organization may use.

The Base Layer

We’ll start with the Cortex’s base Layer. As the foundational Layer within this multilayer configuration, the base Layer will contain nodes that will be visible up through any other Views and Layers making up the rest of the configuration (unless the organization chooses to create another stand-alone View with and designate a different Layer as that View’s base Layer). The organization may decide to limit what teams or users are able to write to the base Layer, depending on which teams have access to the Cortex and their various missions and use cases. Some teams will be able to push data and changes down into the base Layer, while others will have visibility into the information in the base Layer, but be restricted from writing any changes.

An organization might use the base Layer as a Published Intelligence Layer containing all data that the organization has published or otherwise pushed to production, such as detections, alerts, and block lists. Visibility into the contents of the Published Intelligence Layer would help inform the work of the organization’s other Synapse users, some of whom could selectively add to the Layer as they push more data to production. The image below depicts a Published Intelligence Layer that is accessible through the Published Intelligence View. Users with the Publication Reviewers role have read/write access to the data within this Layer, while all others have read-only access to protect the data from accidental changes.

Building up from the Base

Depending on its use case, the organization may decide to have one or multiple Views forked off of the base Layer. One such forked View could belong to a team with read-only access to the base Layer (such as a marketing team), and therefore no ability to merge changes downwards. The other forked View might serve as an internal analysis layer where multiple teams could collaborate and selectively merge data downwards into the base production Layer when appropriate. This set-up, shown in the image below, would effectively divide the Cortex from the base Layer upwards into two separate stacks, unless the teams using the Shared Analysis forked View and the read-only, Team: Marketing forked View decided to grant each other permission to access their separate Views.

Upwards through the Stack(s)

The marketing team, which has read-only access to the base Layer, could then use the Team: Marketing Layer to store and analyze their team-specific data. Rather than writing to their team Layer directly, members of the marketing team could fork Views to use as temporary scratch spaces for specific tasks. This would give them the opportunity to review changes and correct any errors before incrementally merging data down into their team Layer.

Other teams within the organization, such as those responsible for threat intelligence, security operations, incident response, and trust and safety could have their own team-specific Views forked off of the Shared Analysis View. This would allow each of the teams to maintain their own research and analysis spaces, where they can benefit from visibility into data in the base Published Intelligence Layer and selectively merge data down into the Shared Analysis View to collaborate with the other teams, before selectively merging down again to the base Published Intelligence Layer. Individual Synapse users within each team could also fork Views off of their team’s View so as to have a temporary scratch space in which to work on a task, before reviewing and merging their changes down into the team View. An example of such a configuration is shown in the image below:

Users can share access to a forked View so that multiple team members can collaborate on a task. In the example below, a Senior Intel Analyst, Junior Intel Analyst, and Reverse Engineer are working together on a research project in the Task: Threat X Research View, which was forked from the Team: Threat Intel View, and also sits above the Shared Analysis View and Published Intelligence Layer.

The Multilayered Configuration

In total, our example organization's multilayered Synapse configuration would look like this:

In this configuration, all of the data that the organization’s Synapse users have either published or pushed to production exists within the base Published Intelligence Layer, where it is visible to all users assigned to the Views above it. From there, the configuration splits into two stacks: one designed for a team (marketing) that only needs the ability to see, but not alter, the data within the base Layer, while the other stack houses an internal collaboration space and individual Views for other teams within the organization who will be merging some of their data down into the base Layer. With this configuration, the organization is able to use Synapse to coordinate among multiple teams, allowing for visibility into data that all teams need to be able to see and for collaboration between certain teams, while also establishing separate workspaces and restricting access to sensitive data as needed.

Views and Layers in Synapse

The Views and Layers feature within Synapse is a powerful way for organizations to manage collaboration and shared data visibility among different teams and users, while also protecting data from unintentional changes and restricting access to sensitive data when necessary. In this blog, we walked through some examples of ways that organizations can use Views and Layers, as well as how an example organization might implement a multilayered configuration of Synapse appropriate for its specific use case. To learn more about Synapse and its different capabilities and use cases, join our Slack community, check out our videos on YouTube, and follow us on Twitter.