Lacework’s CIEM is likely new to you, but for those of us that have used CIEM-like solutions elsewhere, you will immediately note ways to accelerate the march toward Zero Trust and Least Privilege absent those other solutions.
Operationalizing CIEM
How often is the first step of operationalizing something to “do nothing, sit back and enjoy.” That is where I like to start discussions of CIEM. Why? Once CIEM is enabled (did you have your CSM, PS, or SE enable it in your GUI with your tenant’s unique organizational GUID?). Thats it ! Lacework automatically moves through configuration and log data to profile all your resources and ownership including net-effective permissions (say goodbye to those spreadsheets). Then, Lacework relies upon an automatic composite alert to fire. These provide high efficacy context signals of privilege escalation and enumeration of anomalies. Why do I start here? Because, most customer risk and IAM managers say they already have Identity and access handled by vendor X (they may be wrong; but they are typically emphatic that they have their Cloud identities handled in SSO). So to please these teams we wait for a composite alert to fire. I could look for exposed keys, late key rotation, or worse C2 (command and control) activities to trigger. In proof of concepts, the prospect will often ask for Lacework to fire off some scripts to generate these alerts. The triage reveals the greater work to be done organizationally. We then take them on that journey.
The Alert Triage Journey
Every alert event from Lacework will have a Who(m)/ user or service account associated. Usually that user has taken on an assumed role. AWS over the last few years has locked down most root-level-service access (back doors) and forced organizations to create roles for all administrative operations. Great in theory, but developers spin-up environments without defining fine-grain roles/permissions all the time - leaving the organization vulnerable for identity-based attacks (over-privileging). The most innocuous attack vector often overlooked starts by making use of an API call that enumerates resources (many of which will be vulnerable to exploit as) they haven’t yet been patched. It is for a lateral threat actor using compromised credentials to find the weakest link and elevate a privilege from there to create more authoritative users (In Lacework videos Scout Suite is flagged as a tool signature found).
The alert windows can and typically flag a vulnerable “who” so the incident response team can use the Lacework Entitlements Explorer to review which privileges that user had (potential blast radius).
In this view we understand both the permissions associated with the role and its usage relative to those permissions. The team can use the Lacework Entitlements Explorer to recommend and right size permissions for this role. At the least, this will reduce the risk of Its abuse in the future. All access roles are marked with risks. Those of concern are flagged in red as high risk ; those with two or more risk categories can be sorted for prioritization. Obviously unused privileges that have never been used should just be removed. There is a way (remediation tab) to just open a JIRA ticket and remove them from the policy statement - click on that link (the JSON is exposed in the IAC) and the recommendation snippet becomes part of the ticket to be tracked.
Polygraph in Time Exploit
Oops - bad IPs detected and a hardcoded key found, same procedure. When in a polygraph view of CloudTrail or on a host, just filter on “assume role” system calls by IAM users that are suspected to be surveilling a network. They do this to see which other roles may be ripe for compromise. Most hackers look for lateral access once in and a potentially compromised host alert (with hardcoded keys) is a choice place to look for a breach . Using identity privilege elevation, they will systematically search for the “crown jewels” like a s3 bucket, domain controller or database to further exploit.
Prioritizing Threats
Lacework attack paths can be used to help both right size, permission, and remediate high risk vulnerabilities within their Cloud organization. CIEM identity is now exposed here in this view (did you get your CSM, PS, or SE to enable Attackpath in your GUI with your unique organization GUID?) The identity view in attack path views shows high risk resource exposure allowance, secrets, excessive reading, writing, admin and notably Lacework flags for risk across many categories. The risk contains the history of usage and a link to the policy state over time, giving just enough context to work through a remediation. To do this, as above, they can use the Lacework Entitlement remediation capability to detach the policy that provides the excessive rights from this role. Maybe, just removing an assumed role permission to a database would suffice. Attack Path gives the top 5 exposures where identity could be exploited. It is a good place to start.
CIEM Standalone interface
Thus far I have described where CIEM telemetry binds with other parts of the Lacework product set. IaC and code repos are also worthy of some remediation tasks, however the CIEM interface is valuable by itself to just reveal risky users and unused permissions. A DevOps engineer or IAM specialist would recognize the roles, service accounts and users where they could claw-back access. They key here is not to automate the remediation (although possible) because this is where Governance vendors (IGA) will often break production cloud applications through revocation of privilege indiscriminately. Clouds need more care-and-structure to a governance and entitlements program. Auto-remediation is a promise for another day.
Agent
N/A
Platform
Using Lacework/Operationalizing
Cloud
N/A