Improving Cloud Security Through Monitoring and Analytics

Part 2 of our series on cloud security

If your organization hasn’t moved their operations to the cloud, it’s likely they will in the near future. Eight-six percent of security leaders say they’re moving their operations into the cloud and 70 percent say their cloud security budget will increase dramatically in the next 3 – 5 years.**

Now more than ever, organizations must utilize cloud-based security solutions to ensure their customer information and data are secure, as well as having expertise on the security and regulatory issues involved.

In part one of this blog series, we discussed some of the challenges of cloud security.

Now let’s examine the specific steps you can take to ensure you’re keeping your cloud deployments secure.

What are the most effective cloud security technologies?

According to the 2018 Cloud Security Report published by Exabeam Exabeam partner Netskope (along with Cybersecurity Insiders and Crowd Research Partners), the most important ways in which you can protect your cloud-based assets are:

• Data encryption
• Network encryption
• Security incident and event management (SIEM)

Other key technologies for protecting the cloud are:

• Cloud access security brokers (CASB)
• Network intrusion protection
• Server protection (for IaaS workloads)
• Single sign-on (SSO) and other identity and access management practices

A robust cloud security program includes technologies for protection, detection, investigation and response. With the exception of SIEMs, the technologies listed above all focus on protection and building “defense in depth.”

In this post we’ll focus mainly on next-gen SIEMs (which encompass monitoring and analytics) to improve detection, investigation, and response. In part three of this series we’ll discuss some of the protection technologies in more detail, looking at specific cloud security monitoring and analysis use cases.

Traditional cloud security

Traditional security operations centers (SOC) apply a similar methodology for cloud security that they use for on-premise security. Typically, this consists of the phases illustrated in
Figure 1.

Figure 1 – Traditional security management process

Let’s take a closer at each step:

1. Collecting cloud logs

The first step is to ingest and normalize logs from cloud-based services. Many providers offer well-defined means for pulling activity logs into third-party systems, such as your SIEM. You can also use a cloud-proxy or cloud access security broker (CASB) product to connect cloud services to the SIEM. In practice, most organizations use a combination of these approaches.

Problem: Cloud logs are “chatty”

A typical enterprise generates billions of unique transactions in cloud services each month such as for every logon, log out, edit, etc. This leads to excessive costs in SIEM products that charge fees based on log volume. Too often the workaround is to engage in selective log ingestion—making educated guesses about which logs will contain the information needed to solve a future, unknown security issue.

But leaving blind spots in a data audit trail can lead to inconclusive investigations; these prompt additional educated guesses when such outcomes might not be acceptable. For example, consider the effect of gathering a limited, random set of clues from a murder site, then hoping detectives can effectively solve the case. Maybe they can, maybe they can’t. So if your organization experiences a breach that needs to be understood, stopped, reported, and disclosed, you need to be able to answer all of the tough questions that will inevitably be asked.

Solution: Use a SIEM product that doesn’t charge based on log volume and ingest all of the logs that are available to you. Leave no stone unturned.

2. Centralizing logs within a SIEM to provide the complete picture

No matter how you ingest your cloud-based log files, there is a big advantage to pulling them all into a central repository. Doing so can provide optimal visibility into everything that’s occurring in your cloud deployments. But the real power comes when you combine your cloud logs with other logs from your on-premise sources, such as users, client computers, servers, smart devices, badging stations, and any other logs you can access.

3. Getting an alert

Alerts are then generated as incidents occur, typically either from a security tool such as FireEye, or from a correlation rule in the SIEM itself.

Problem: Not catching unknown threats

Relying on a collection of static correlation rules alone means you’re attempting to use any number of educated guesses to predict the known threats you’re likely to experience. Most are a vain attempt to stay ahead of the game programmatically. Worse yet, such rules can’t account for those threats that are as yet unknown.

Solution: User and entity behavioral analysis (UEBA) identifies anomalies

UEBA provides a baseline of all normal user and asset behavior, with its algorithms analyzing your data before threats occur. For example, how often does a given user access their web email, and how big is one of their average attachments? Or, which users are connecting to a database and what are their normal access privileges?

When you have a baseline of every user, every asset, and every device, you’re able to immediately know when questionable behaviors are out of range of whatever comprises your organization’s normal cloud usage activity.

The good news is that UEBA removes the overhead baggage associated with building and maintaining countless correlation rules. It returns meaningful results without the avalanche of false positives that cripple SOC efforts to assess real threats that may be occurring.

4. Gathering evidence

The next step is to investigate and review relevant raw data underlying the incident.

Problem: Manual data gathering

Traditional investigation methods involve examining your cloud logs, querying and pivoting within your SIEM. But there’s a lot of incomplete information that must be correlated across disparate devices and logs. Such activities consume huge amounts of your analysts’ time, and most SOCs don’t have extra analyst hours to spare.

Solution: Automatically gather and pre-process data

Some SIEMs collect IT and security logs that automatically combine sequence, behavior, identity, and scope into pre-processed objects that can be instantly retrieved whenever they’re required for threat hunting. Analysts can also augment or replace querying with a threat hunting tool that lets them use plain language searches and drop-down menus to further refine searches. Such easy access is a boon for junior analysts who may have just joined your security team.

5. Building a timeline

Once analysts gather enough evidence, they can build it into a timeline. At this point the team has an idea as to what is going on, which systems and users have been impacted, and what they should do to further threat mitigation.

Problem: Manual investigation and timelining is expensive and slow

For example, at some point you might need to assess which user logged into a machine assigned a certain IP address during a session. You might have to look at four or five separate log files to track down that information; even then you’ll likely only have a partial picture of the activity you’re investigating. You’ll need to repeat activities like this many times to ultimately build a timeline a non-technical audience can understand.

Solution: Combine cloud and on-prem activity into session timelines

Combining cloud and on-prem activity into session timelines that span both domains provides the best way to investigate abnormal behavior. Such timelines are automatically built as sessions begin; they track users and devices as they connect to services and other devices, move data from place to place—and possibly elevate their privileges.

Figure 2 – Prebuilt timelines combine sequence, behavior, identity, and scope into a security information model

Session timelines can have risk scores attached to any event that slips out of the range of normal behavior. When a risk score total during a session exceeds a predetermined value, the SIEM can send an alert, initiate an automated response, and perform other actions as configured during its deployment.

6. Responding to an incident

Only after your SOC team has completed steps 1 – 5 can they effectively mount a threat response. Using traditional tools, such a response might not be ready for days or weeks after a threat event has occurred. Critical data might already have vanished.

Problem: Consistently applying correct responses

Even in best case scenarios, where data hasn’t yet been exfiltrated or systems haven’t been compromised, your response can be complicated by events that span both on-prem and cloud resources. Add to this the varying skill levels of your staff members working across multiple locations, multiple time zones, and possibly following procedures with uneven consistency.

Solution: Playbooks enable you to respond to entire incidents, including cloud events

Today’s attacks often have multiple phases. They can start, traverse, or end in a cloud-based asset, or can take place entirely in the cloud.

A playbook can address each phase of an attack. For example, a phishing playbook can defend against an attack to a cloud-based email system, followed by a malware playbook to scrub whatever may have been installed, either in the cloud or on-premise. Next, a data exfiltration playbook could identify or stop potential data theft the malware tried to initiate.

Security orchestration and automated response completes the picture

Some SIEM products have automated playbooks that function using security orchestration. This combination is referred to as security orchestration and automated response (SOAR). Through prebuilt connectors, playbooks can pull data or run actions across the full range of your secured IT devices. They can run in fully- or semi-automated modes to perform consistent investigations, containment, or response across your entire networking landscape.

Stay tuned for the next blog in our series, as we review use cases to improve cloud cybersecurity.

For more information, watch Exabeam’s webinar on Cloud Security Monitoring and Analytics.

**Security Intelligence