Authors: Raj Mallempati and Mike Raggo
The aftermath of the Solarwinds breach and subsequent impact on thousands of organizations has left organizations scrambling to determine the impact. FireEye, Crowdstrike, and others have provided free tools for detection and incident response and forensics.
As organizations assess the impact, we at CloudKnox wanted to provide additional guidance for fortifying your public cloud, multi-cloud and VMware infrastructures. Therefore, in this four-part series we’ll begin by discussing Azure, and then we’ll publish blogs for VMware, GCP, and AWS.
CloudKnox provides Cloud Infrastructure Permissions Management across Azure, GCP, AWS, and VMware both on-premise and in the cloud. Our patented activity-based monitoring provides deep insights into permissions usage that can be very difficult to decipher using native tools. This is aggregated into a single dashboard with roll-up analytics for your hybrid cloud without the need to login into individual subscriptions or cloud service providers. The identity and access to resources data is used to also automate remediation across your hybrid cloud to proactively and reactively reduce risks stemming from over-permissioned assignments, accidental assignments of high-risk permissions, oversights in terms of permissions assignments and reduce the complexity of clean-up through auto-calculated least privilege policies. Let’s continue by further exploring the Solarwinds risks in the context of the cloud.
One of the largest concerns is once a Microsoft on-prem server environment is breached, how could an attacker leverage that access to pivot to Azure. Previous guidance recommended that organizations look for signs of attackers leveraging Azure Active Directory to pivot to the Azure cloud infrastructure. This can involve lateral movement, privilege escalation and more as outlined in our Forbes article titled “Understanding the Cloud Infrastructure Cyber Kill Chain”.
Microsoft’s recent blog outlined a variety of Azure cloud recommendations. Let’s break these down and outline some approaches to these recommendations:
Monitor for anomalous use of service identities:
Identifying what’s anomalous requires an understanding of the history of each service identity, baselining that activity, and then identifying deviations. CloudKnox leverages machine learning to baseline this activity and spawns built-in anomalous behavior activity alerts.
One example of this would be to monitor for Microsoft.Authorization/roleAssignments/write which can allow additional permissions to be assigned thus providing privilege escalation.
Monitor your sign-ins:
While this is Security 101, adding some context to this makes this very informative. For example, if a dormant or inactive identity suddenly signs in, that absolutely is suspicious. Furthermore, creation of new identities, odd time of the day for a user to login, or new IP address or Geo is also suspicious.
Reduce permissions on active applications and service principals
Reducing permissions for active applications and service principals involves comparing assigned permissions to actual usage for every identity, and furthermore evaluating of those permissions which ones are high-risk. This is a combination of Least Privilege and removing unnecessary high-risk permissions. This is a time-consuming process involving a manual dissection of each application and service principal.
Through automation in CloudKnox, an administrator can remove unused permissions and decipher high-risk permissions in seconds, across all identities, including applications and service principals through CloudKnox automated remediation. This provides a very calculated and repeatable method for ensuring risk is minimized thus vastly reducing your blast radius. With more than 8000 permissions in Azure, automate is a must!
This is not only limited to service principals (service identities), but human identities as well. Considering that the adversaries leveraged SAML tokens to target Azure AD identities, human identities should be right-sized as well to remove unnecessary high-risk permissions and unused excessive permissions.
Reduce surface area by removing/disabling unused or unnecessary applications and service principals.
Removing or disabling unused or unnecessary applications and service principals is actually a very complicated process. This can be determined through usage to identify inactive and low volume use of specific applications and services principals. CloudKnox’s usage analytics can identify these unused and rarely used applications and service principals.
Following NIST’s Cybersecurity framework your organization can apply these to each of the five core functions:
- Identify – High-risks permissions, dormant applications and service principals. Toxic combinations that could lead to lateral movement, privilege escalation, and exfiltration. Remain proactive and diligent.
- Protect – Eliminating unused permissions, especially for non-human identities like applications and service principals minimizes risk and thus the blast radius. CloudKnox’s JEP (Just Enough Privileges) controller enables you to automatically do that. Our “Autopilot” simplifies finding and eliminating unused identities, roles, groups, removing unused permissions etc..
- Detect – Using audit trail, alert triggers, and automated anomaly and outlier detection alerting; CloudKnox can provide alerting and integrates with SOC & SIEM products such as Splunk to alert organizations of the aforementioned threats outlined by Microsoft.
- Respond – CloudKnox APIs and “easy buttons” (automation) make it easy to delete or disable unused permissions. The explorer gives you the 360 degree view to quickly perform forensics on any of identities, actions and resources with a simple search.
- Recover – CloudKnox empowers you to implement a least privilege policy with the click of a button. Our permission on-demand and just in time permission provisioning enables you to maintain that least privilege state on an ongoing basis.
We hope this is a starting ground for fortifying your Azure environment from risks stemming from the Solarwinds compromise. In our next blog we’ll also outline similar risks and countermeasures for AWS, GCP, and VMware. Until next time, “may the force be with you.”
The post Fortifying Your Azure Cloud Infrastructure from Solarwinds Risks appeared first on CloudKnox.