Skip to content
Notifications
Clear all

What is the best way to structure teams and projects in Lacework for a large org?

2 Posts
2 Users
0 Reactions
4 Views
(@alexm82)
Estimable Member
Joined: 1 week ago
Posts: 71
Topic starter   [#15643]

We're evaluating Lacework for a company with several hundred developers across multiple business units. The current AWS account structure is complex, with a mix of shared services and product-specific accounts.

I'm trying to understand the best practice for mapping this into Lacework's concepts of organizations, accounts, and projects. Should each business unit be a separate Lacework "organization" under a single company account, or is it better to manage everything under one organization and use projects/teams for segmentation?

My main concerns are maintaining clear cost allocation back to each unit and ensuring teams only see their own resources, without stepping on each other's alerts or policies. How are others handling this?



   
Quote
(@henryg)
Estimable Member
Joined: 1 week ago
Posts: 89
 

I'm the security lead at a 450-person fintech running 80+ AWS accounts across three product divisions. We've had Lacework in prod for 18 months.

1. **Cost Allocation Granularity** - One organization can tag cloud resources, but the billing export to your SIEM only breaks down to organization level. To charge each BU back directly, you need separate Lacework organizations, each a separate line item.
2. **Policy and Alert Sprawl** - A single org means all custom policies are global. You'll spend a lot of time writing exceptions for team-specific environments unless you adopt a rigid tagging convention from day one.
3. **Team Visibility Control** - Their RBAC is project-based, not resource-tag-based. If you want a team to only see their three AWS accounts, you must define a project containing exactly those accounts. Updating this manually for 80 accounts took us ~40 hours.
4. **Support and Setup Friction** - Multi-org management means separate agent configs and dashboard contexts. Our onboarding for three orgs took six weeks, partly due to support ticket latency averaging 3 business days for config issues.

My pick: Start with a single Lacework organization, but only if your BUs share a central cloud security team managing all policies. If BUs need independent policy ownership or direct cost billing, bite the bullet and use separate organizations. Tell me your headcount for the central cloud security team and whether FinOps requires itemized invoices.


Your vendor is not your friend.


   
ReplyQuote