Resource groups and data access: An improved approach to filtering and sorting Lacework alerts

Any digital security team that needs to scale requires the ability to assign teams a data-scoped view of ownership. On top of that, the admin teams within an organization (i.e. the SOC, Configuration and Management team, or CISO) must be able to easily filter across the platform based on these data-scoped views and gauge the risk and responsibilities in each team. 

To support these requirements, Lacework just launched a series of usability updates that make it far easier for scaled teams to filter, assign, and sort through data. The extensive updates support filtering and pre-filtering across every area in the product including compliance and vulnerabilities.

Updates are centered around three core areas and provide distinct benefits to security teams:

• Resource groups have been upgraded to offer unparalleled customization. Now you can tailor your resource groups to fit your unique needs with greater precision and flexibility with improved filters, complex expressions, multiple conditions, and nesting. 
• Role-based access control, or RBAC, has been built to leverage these new and improved resource groups. This means you can define data access for each of your teams using Lacework, only giving respective users access to the resource data they are scoped to across the platform.
• Cross platform filtering of resource groups has been deployed to allow teams to reduce the data view based on specific areas of interest.
  

Let’s take a look at how these updates could be deployed across a fictional company called Pixel’s Pet Shop. 

Pixel’s Pet Shop’s security situation  

Pixel’s Pet Shop has four distinct security teams with different requirements:

1. Configuration/Operations team: This team is in charge of onboarding onto the Lacework platform and generally is responsible for all resources and integrations within the company. That includes tasks like setting up RBAC in Lacework as well as handling aspects such as initial resource configuration or authentication.
   
   How would this team leverage resource groups and data access?
   This team is responsible for setting up the resource groups based on certain criteria within the organization. For example, Pixel’s Pet Shop relies heavily on resource tagging in order to organize resources. Therefore this team would create a spectrum of resource groups based on tags or labels.
   
   What is this team’s data scope?
   This team would most likely have an admin permission and their data scope would include all resources.

2. SOC team: At Pixel’s Pet Shop, this team is focused on all threat data produced by Lacework. Typically this team would have this data sent to particular notification channels based on alert rules.

How would this team leverage resource groups and data access?
This team would most likely only leverage resource groups as a criteria in alert rules. For example, if there are particular high importance applications, the SOC team would create specific rules for those applications using the filtering of resource groups in alert rules.

What is this team’s data scope? This team would have access to all data and only use resource groups for filtering purposes.

3. Vulnerability team: This team has a dedicated set of resources and is in charge of fixing vulnerabilities based on Lacework data.

How would this team leverage resource groups and data access?
This team would be assigned to a user group that is only given vulnerability access permissions and has a limited data scope view based on resource groups. For example, the configuration team would have set up a resource group (or a set of resource groups) that consist of resources owned by this team. This team would then only have access to data produced from those resources in both the UI and API.

What is this team’s data scope?
This team would have a limited data access view based on the resource groups they are granted. For example, resource groups 1-3.

4. Compliance team: Similar to the Vulnerability team, this group has a dedicated set of resources and is in charge of correcting compliance violations based on Lacework data.

How would this team leverage resource groups and data access?
This team would be assigned to a user group that is only given access permissions to compliance and has a limited data scope view based on resource groups. This team would then only have access to data produced from those resources in both the UI and API.

What is this team’s data scope?
This team would have a limited data access view based on the resource groups they were granted. For example, resource groups 5 and 6.

The concluding team structure would look something like this: 

While the Vulnerability and Compliance teams will have limited data views, they can still filter across the platform within their domains. For example, if the Vuln team wanted to only see information for resource group 2, it would be possible to do that. 

In addition, if the SOC or Configuration team wanted to see how the Vulnerability and Compliance teams were addressing risks, they could build scheduled reports based on those teams in order to see the progress. 

This set of improvements expands teams’ ability to operate in their functional areas within Lacework and contains workloads and visibilities to the appropriate groups, limiting overall risk to the organization. New features and methods that even better support this team structure across the platform are also in the roadmap and will continue to build on this initial foundation.

Categories

• Blog
• Cloud Security
• Product Updates