03/26/2020 | News release | Distributed by Public on 03/26/2020 15:51
A unified cloud infrastructure data model is fundamental for enterprises using multiple cloud vendors. Enterprise customers prefer to use multiple cloud vendors as a way to prevent being locked in and dependent on specific platforms. According to Gartner the top vendors for cloud infrastructure as a service in the years 2017-2018, are Amazon 49.4%, Azure 12.7% and Google with 3.3%. These three vendors have different products, services and logging nomenclatures that makes it difficult for the enterprise to have a unified visibility when managing data from the different cloud providers.
This blurry line is one is just one element of a bigger challenges which include:
Another important element to consider when addressing proper visibility is the distribution of outward facing and inward facing cloud applications in enterprises.
Having the ability to monitor and visualize multiple vendor cloud operations in a unified manner improves the ability of IT and Security analysts to monitor, detect and investigate operational issues as well as security threats. This can be difficult to achieve, especially as main vendors do not cooperate amongst each other and in some cases do not even provide data from their proprietary offerings, but there are ways to approach this challenge.
The Splunk Security Research Team has identified six initial main categories that can group together the three major cloud providers to begin to address visibility across multi-cloud environments. These categories were selected after researching log data from cloud customers use of services from the three major vendors.
As more enterprise organizations continue to move to the cloud using multiple cloud providers, it's important to have visibility into your data across the multiple cloud platforms. The Splunk Security Research Cloud Infrastructure Data Model normalizes and combines cloud generated data from AWS, Azure, and GCP, so you can write analytics that work across all three major vendors.
Features of this Data Model include:
More information on Data Model prerequisites and specifics of the data model can be found here.
The unified cloud infrastructure data model initially covers 4 main areas.
Once the prerequisites and source types are met, the log information is normalized and displayed
In the compute category we group log information related to virtual machines, containers, regions, users, interacting user-agents and compute engine events in general.
In the storage category we group log information about storage centric (Usually buckets) accounts, entities, actions, regions, IP addresses, storage types, path of storage objects, etc.
The traffic category groups network derived events, such as IP addresses sources, destinations, ports, packet stats, cloud traffic rules, TCP/IP protocols, etc.
The authentication category addresses security, authentication and authorization items such as authentication tracking events, roles, assumed or impersonated roles, identity groups, identity providers, multi factor authentication settings, etc.
In the above figure the Cloud Infrastructure Data Model provides information on an specific vendor (AWS) following the flow of authentication and through different identity provider mechanisms within the vendor. Also the Data Model displays if authentication is through AssumeRole which is a very important AWS Security Token service, specially when monitoring cross-across account access.
Once we have vision in these 4 areas, we can utilize this data for detection and investigations of security threats. One way of applying this data focusing on security threats related tactics, techniques and procedures, can be accomplished by using the recently published MITRE Cloud Attack Matrix as reference.
In the following example we will perform a detection using data normalized from the Unified Cloud Infrastructure Data Model. The scenario of MITRE ATT&CK T1525 assumes an user account with enough privileges to manage containers has had their credentials compromised or a service account with such roles has been compromised as well.
This scenario falls within the CI/CD Devops attack surface. The components of this attack surface usually fall under:
We will use Rhino's security Cloud Container Attack Tool, to implant a backdoor in a container.
Once we upload an implanted container to the Container Registry and this container is deployed, we can then detect container implantation by using the following indicators:
The following are searches designed to detect use of 2 user agents by 1 API Token.
We can also search for 'PutImage' which indicates the uploading of a container image to the Elastic Container Registry.
In the case of GCP when container images are pushed into a private container registry using Google Container Registry, the images are stored in a bucket and the transaction will be recorded under an specific bucket, from an specific account and with destination showing the SHA256 digest. We can use the same CCAT tool to explore a public Google Container Registry repository.
| datamodel Cloud_Infrastructure Storage search | search Storage.event_name=storage.objects.create | table Storage.src_user Storage.account Storage.action Storage.bucket_name Storage.event_name Storage.http_user_agent Storage.msg Storage.object_path
Once in the GCR we can also cross reference using the upcoming Kubernetes updates to the Splunk Security Research data model.
Based on the above data there are some items to review to detect implanted containers:
Finally, we can also create alerts when vulnerable containers are uploaded to the container registry. The following is an example of GCR Vulnerability Scanner engine results on our uploaded backdoored/implanted container.
The following is a grouping of alerts by container occurrences and container vulnerability alert from GCR vulnerability scanning. This base search can be used to create alerts.
index=gcp_gcr data.kind=VULNERABILITY 'data.notificationTime'=* 'data.name'=* |table data.kind data.notificationTime data.name | rename data.kind AS 'container_alert', data.notificationTime AS 'notification_time', data.name AS 'container_occurrence'
The Splunk Security Research Team is focused on developing security analytics based on a unified security posture for all major cloud security providers. Please visit our github site or install the ESCU app for the latest security content. You can also reach out to us via email research at splunk.com.
The Splunk Security Research Team is devoted to delivering actionable intelligence to Splunk's customers, in an unceasing effort to safeguard them against modern enterprise risks. Composed of elite researchers, engineers, and consultants who have served in both public and private sector organizations, this innovative team of digital defenders monitors emerging cybercrime trends and techniques, then translates them into practical analytics that Splunk users can operationalize within their environments. Download Splunk Enterprise Security Content Update in Splunkbase to learn more.