Centuries ago, Sun Tzu said—and I am paraphrasing—that he who holds the high ground has the advantage. At Red Canary we are seeing our customers move more business-critical services to the cloud. Reasons an organization might consider moving on-prem architecture and services to the cloud include cost, availability, reliability, and ease of management. Many companies cite security as a barrier to moving to the cloud, but what if cloud migration actually made your data more secure?
As we have worked to enhance our managed detection and response (MDR) for cloud offering, we have picked up on some unique and interesting benefits for defenders that we don’t see on the endpoint. Cloud migration has caused us to rethink how we do threat detection. This is because the visibility we have in cloud environments is fundamentally different from what we have for endpoints.
Before we dive into the specifics, however, we need to first make sure we understand how we gain visibility into both endpoints and the cloud.
Anti-clickbait note
Both endpoint and cloud can be horribly insecure if misconfigured. All the concepts covered here are assuming a sensible security configuration for both environments.
How endpoint security works
Endpoint security has been around for a long time, with some of the earliest antivirus (AV) products appearing in the 1980s. Antivirus products generally worked by installing software on an endpoint with known signatures (a means of identifying a specific piece of malware) that would look for malware on a system and try to either isolate or remove it. The signatures would be developed by researchers and antivirus companies as they analyzed known samples of viruses and malware.
This worked well for a while, but it was not scalable; malware authors could make minor changes in their code that could easily evade known signatures. AV also was entirely ineffective at detecting new types of malware.
To combat this, defenders worked to develop behavioral-based detection products such as endpoint detection and response (EDR). These products looked for patterns of behavior in the malware. This made it harder for malware authors to avoid detection since EDR could identify common techniques across different families of malware instead of just a single signature. EDR could also potentially identify an unknown piece of malware if it leveraged a known technique.
To detect behavior, EDR products generally work by gathering and then sending telemetry such as process events, network events, and other activity happening on the system to the EDR vendor or the customer using the product. These events are then analyzed to try and determine patterns of behavior. If a known malicious pattern of behavior is identified, an alert is generated.
For more on the history of EDR and how the solution has evolved in the last few years, check out our new EDR evaluation guide.
How cloud security works
Now let’s talk about how defenders have visibility into cloud environments. Cloud security is fundamentally different from endpoint security. Generally speaking, “the cloud” is made up of a collection of services. The services offered are varied and differ depending on the cloud service provider (CSP) you are using, but generally CSPs will offer services such as compute instances, object storage, and serverless products, to name just a few. We’ll scope this article to the “big three” CSPs: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
From the Cirrus cloud view, cloud security begins with an identity. An identity might be a user or a service. The identity will be assigned one or more roles, each of which have a set of permissions. Each time the identity wants to access or create a resource such as a compute instance or a bucket, its permissions are evaluated to determine if it should be allowed to perform that action. These actions can then be logged and reviewed using audit logs generated by the CSP. The identities may also leverage authorization technologies such as OAuth2 scopes to limit what they can access.
Defenders need to avoid the trap of assuming endpoint detection is the same as cloud detection.
Defenders looking to gain visibility into cloud environments primarily rely on logs generated by the CSPs. Typically there are a default set of logs that cannot be disabled or deleted. There is also more detailed logging that can be enabled as well. The logs will provide information about events happening in the cloud environment. For example, if a user creates a new storage bucket, there will be a log generated that will give some context as to who created the bucket, the name of the bucket, when it was created, where in your environment it was created, and much more. Based on logs like this, defenders can build analytics and detectors to attempt to identify malicious behavior in a cloud environment.
Rising to new heights
Now that we understand at a high level how endpoint and cloud security work, let’s dive into how they differ. Defenders need to avoid the trap of assuming endpoint detection is the same as cloud detection. You may be able to get some level of detection coverage in the cloud with an endpoint mindset, but without adopting a cloud-first approach, you will likely not achieve the results you are hoping for.
How malware gets in the way of EDR telemetry collection
One major disadvantage that endpoints have over cloud is the fact that the EDR software that collects telemetry runs alongside the malware. This opens up a nearly endless set of possibilities for the malware to affect the EDR’s ability to collect and offload logs. Let’s examine a few.
Disabling the logs
Because malware can run alongside security products on an endpoint, the malware could tamper with or disable the data collection capabilities of the security product.
Preventing offloading
Because malware can directly affect the same machine the EDR is running on, it could potentially disrupt the EDR solution’s ability to offload data for collection.
Modifying the log data
Malware running on the same machine as the EDR software has the potential to affect the log data being sent for collection, either by modifying files on disk, modifying the memory of the EDR process, or potentially altering the network data as it is leaving the machine.
All three of the methods mentioned above are not possible with malware running in a cloud environment. This is because cloud audit logs are guaranteed to be generated and stored free of charge. This provides a strong advantage to cloud defenders as they are guaranteed to always have a certain level of visibility into their environment.
Well-defined choke points
Endpoint computers were not originally designed with security in mind. Any given adversary technique can be implemented in myriad ways. Cloud environments, however, have well-defined choke points (i.e., avenues through which activity can be centrally observed). Most operations you want to perform for a given service in the cloud are executed through a finite set of application programming interfaces (API). Defenders can monitor these APIs to determine the who, what, where, when, and how behind a suspicious operation. If you identify an adversarial technique or behavior in the cloud, it is relatively easy to land on a single choke point to monitor.
Another advantage this offers is that, in general, you will need fewer detectors in the cloud than in the endpoint to cover a given technique. Since choke points are better defined, you can rely on fewer detection analytics to cover a given technique so long as you can accurately identify an effective choke point for that technique.
In general, you will need fewer detectors in the cloud than in the endpoint to cover a given technique.
Better isolation
CSPs have done a good job at designing security into their products from the beginning. A large part of the security model in the cloud is isolation. In many modern cloud services, the services themselves are isolated from each other by default. The identities that access those services also tend to be isolated and only given the permissions needed to accomplish their task. Because of this, even if a public-facing service or an identity is compromised, their scope of attack is limited.
On endpoints, we do not typically find this level of separation. Operating systems were designed long before security was as big a concern as it is today, and therefore lack some of those fundamental boundaries we see in cloud architectures.
The current “disadvantage” of moving to the cloud
An undeniable disadvantage that moving to the cloud brings to the table is a lack of experienced security professionals. Endpoint security has been around for decades, with a wealth of information and best practices that have been established by companies and security professionals who know what works. “The cloud,” however, is a relatively new paradigm. AWS was one of the first major players that started offering object storage back in 2006. Cloud usage in general has only recently spiked in the last decade or so, before that being somewhat niche and obscure. This does pose a problem, as there are many security professionals who are playing catchup to understand how to secure a cloud environment. This is compounded by the recent adoption of multicloud strategies that require security professionals to understand multiple CSPs.
This, however, will not always be the case. CSPs have been very proactive at offering training and certifications for cloud security. Businesses, researchers, and cloud providers are developing best practices that are slowly getting implemented as sensible defaults to many services that are offered. There is a knowledge base that is growing each day in the form of blog posts, conference talks, online training, podcasts, books, and many other learning mediums.
Ascend to the clouds
So what can defenders who are trying to learn cloud security do? Here are a few ideas to get you started:
- Read up on one or more of the major cloud providers. There are tons of articles, YouTube cloud security videos, and other material out there, including our AWS visibility guide.
- Get your feet wet. Try to come up with a simple project that allows you to learn one or two of the services that a CSP has to offer. For example, you can build a simple
hello world!
serverless function. Or maybe you can host a simple static website using bucket storage. Or maybe you want to try and SSH into a compute instance you created. Many services can be easily stood up without prior knowledge or experience. - Look into certifications and training. There are many websites and training companies that will offer certificates for cloud-based education. Many of the major CSPs have certificates related to their services you can earn. These can be a great way to get some guided instruction and a deep dive into a set of services.
- Attend a conference. Nowadays there are many cloud conferences that focus on one or more CSPs. They will often have different tracks for different experience levels. Conferences can be a great way to network with others working in the cloud and also to learn from those who have extensive knowledge and experience.
Learning together
While in many ways cloud defenders have a distinct advantage over endpoint defenders, this doesn’t mean that running a service in the cloud is inherently safer than on an endpoint. Rather, infrastructure running in the cloud inherently has a more defensible architecture than an endpoint system, by the nature of it having more observable choke points that are less susceptible to adversary defensive evasion. There are many features offered by cloud providers that can make the job of a defender much easier and the job of an adversary much harder.
Cloud security still requires more learning and practice though, as cloud technologies are still relatively new and evolving rapidly. But with the growing number of companies moving more of their resources into the cloud, the industry will, by necessity, build a larger base of knowledge, experience and best practices to help ensure that defenders are well prepared to protect their assets.