Cloud Security Security Bloggers Network

Home » Cybersecurity » Cloud Security » Rethinking Defensive Strategy at the Edge, Part 2: Risk Signals as Security Controls

Rethinking Defensive Strategy at the Edge, Part 2: Risk Signals as Security Controls

by Or Katz on September 16, 2020

In the first post in our blog series Rethinking Defensive Strategy at the Edge, we began to outline why a new defensive edge strategy is needed for today’s enterprise. As previously mentioned, the strategy enhances those in place and introduces another layer of defense that includes the following three components: data and indicators, risk-based signals and entities, and protective actions. This post explores user entities as well as risk-based signals that can be leveraged to improve this updated defensive strategy.

As previously mentioned, enterprises’ perimeters and connectivity locations are constantly changing, and as a result, users’ hygiene and browsing habits are as well. The lack of clear network perimeters leads to the unavoidable conclusion that remotely connected entities must be at the center of the defensive strategy. These entities should include all connected device types from users, such as desktops, laptops, mobile phones, and tablets, as well as any connected applications, servers, and services. It is critical that when trying to establish defensive strategy in the context of remote connectivity, a signal-based mechanism representing the risk score of the connected device is used.

Once moving to a risk-based approach, we acknowledge that the chosen defensive strategy is not deterministic and that the objective is to reduce risk that is associated with the possibility of a compromised device or user. A risk-based approach leads us to be able to include more risk and threat signals that are not traditionally being used by security controls, and therefore add another layer of defense on top of other essential enterprise defensive strategies. Three key signal types should be considered when determining risk score: device, users, and threat alerts.

Devices

The security posture of the device being connected enables us to evaluate the risk that is associated with the remotely connected device and user. Here are some examples for indicators from the device that should be used:

OS and browser patching status — representing tolerance to risk of known vulnerabilities to the device OS and browser version being used. For example, if a new OS version was released that contains patching of known vulnerabilities, and that version was not installed on the connected device, that may represent a risk of that device becoming compromised.

Availability of security services — representing active security service on the device, for example, validating device firewall and disk encryption are active and running. If some of those services are not activated, that might represent a risk of those devices being or becoming compromised.

Users

Although the actual device is critical to making security scoring decisions, every device has at least one user attached to it, and the behavior of that user is also a critical risk factor. Since one of the top concerns for enterprises is the potential exposure of a data breach, the ability to detect abnormal user activity — which may be the direct result of a compromised device or insider threat — is an important threat signal. Excessive and abnormal access to an enterprise’s proprietary data needs to be incorporated into your incident response process.

User behavioral signals that may be an indication that a device, or a user, has been compromised, may include but are not limited to:

Abnormal change in geographical location — for example, stolen credentials being used from a location that is not the user’s usual location
Abnormal access to files — excessive downloads of files and data from a corporate cloud might indicate a data breach or insider threat
Abnormal access to enterprise applications — compromised devices that scan for enterprise applications will create abnormal behavior that differs from the normal usage and access to enterprise applications by the connected user

An example of enterprise users’ access to apps in a given hour

As this graph shows us, based on data collected from a single remotely connected enterprise, the majority of users in that monitored enterprise will use one to five enterprise applications per hour. At the same time, there is also a long tail of users that will use more applications — some will even reach 25 applications per hour. User behavior can be an important indicator of a threat, particularly looking at the long tail of application usage above as an example. Users that show excessive access, or access to 25 apps per hour, could be an indicator of malicious behavior. However, this needs to be compared to their normal behavior to determine whether or not it is a deviation. If it is outside of normal user behavior, this might represent a compromised device or user that is scanning and abusing the applications’ access interfaces.

Threat Alerts

The third set of signals that should be considered for usage as security controls are those that indicate a connected device may have been exposed to malicious code. These signals from security services that are already part of enterprise defensive systems — such as endpoint detection and response (EDR), web application firewall (WAF), and secure web gateway (SWG) — should be used to evaluate the risk associated with the connected device and user. For example, access to domains that are known to be used for command and control (C2) communication or Structured Query Language (SQL) injection attacks, if sent from a device to an enterprise application, can indicate the device is compromised and is being used to steal and/or leak sensitive corporate information.

Signal Correlation

Some of the signals suggested above might be considered as weak signals, meaning they are prone to false positives. For example, a geographic location anomaly can be the result of stolen credentials, but it can also be the result of legitimate behavior of a traveling agent that looks abnormal.

Therefore, correlation of signals with tools such as security information and event management (SIEM) should be considered to allow more accurate decision making. For example, signals such as change in geographic location, access to websites associated with malware activity, and a device with an old and unpatched OS version, each on its own might be considered as low risk and insufficient information to warrant taking action. However, when considered together and incorporated into a signal-based risk score, these signals may determine that taking protective action is needed.

Our third and final blog in the series will focus on how to apply this new strategy of security at the edge, incorporating risk-based signals and entities as well as data and indicators, to take protective action. The objective is to reduce risk while minimizing the potential effect on usability as a result of false detection, as well as remove some of the burden from the security and help desk team by enabling self-remediation and mitigation.