Data exfiltration, or data loss, can be a very time-consuming and expensive ordeal causing financial loss, negative brand association, and penalties from privacy focused laws. Take for example, an incident where sensitive smart grid and metering R&D knowledge information from an industrial control system of a North American electric utility was exfiltrated through an attack that was suspected to have originated from inside the network. Unauthorized access to data from a utilities company can result in a compromised smart grid or power outages.
In another example, a security researcher found exposed and unknown (undocumented) API endpoints for Tesla’s Backup Gateway that could have been used to export data or make unauthorized changes. This would have had very real physical consequences had the unauthenticated API endpoint been used by an attacker to damage the battery or the connected electric grid.
Source: Verizon 2020 Data Breach Investigations Report
Both these examples emphasize the importance of considering internal and external threats when thinking about how to protect a network from data exfiltration. An insider threat isn’t necessarily a user willfully causing harm: according to Fortinet’s 2019 Insider Threat Report, from the organizations surveyed 71% were concerned about a careless user causing an accidental breach and 65% were worried about users ignoring policies, but not maliciously. The attacker that successfully carried out the Twitter hack in 2020 to access prominent accounts started with a social engineering attack against the employees. The attacker then pivoted to internal administrative tools to change settings to customer accounts, including posting on their behalf or making modifications to their emails and 2FA.
On the surface it may have looked like just a Bitcoin scam, but the attackers also downloaded and exfiltrated data from seven accounts. If an internal user's account was successfully compromised through a vishing (a form of social engineering attack that uses voice based phishing) attempt, adding in hard keys or implementing granular account permissions to administrative tools could impede the attacker’s reach. Later in Security Week, we explain the Twitter hack from the angle of an account takeover attack and how it could have been mitigated.
Data exfiltration doesn’t require sophisticated techniques or some obscure tool. Phished users combined with over-permissive policies on an endpoint, as opposed to an account, can give an attacker the access needed to exfiltrating data. Blocking malicious domains on your email protection solution is a step many security teams depend on to respond to social engineering attacks. But what if a malicious resource is shared laterally and not from an external source to an internal source? Malicious domains can be shared between employees in chat or through some other form of communication that isn’t email. This leaves gaps that puts security teams at a disadvantage when protecting internal users and data.
We’ve always put an emphasis on a multi-layered approach to prevention and monitoring. For our internal tools, we have role based and risk based access controls. We place our applications behind Access for an added authorization layer on top of authentication. Adding SaaS applications behind Access allows us to securely connect users to what they need whether it is on-premise or in the cloud. With a remote workforce, Access lets us configure policies based on location, device type, device posture, and MFA method. As we move towards a VPN-less environment, Access acts in its place as a secure tunnel. Our detection and response team monitors both Access logs and SaaS application logs for anomalies. Soon we will add Access logging within SaaS applications, which will further enrich and contextualize logs.
Protecting endpoints using Cloudflare also includes a client that is used to enforce policies. Gateway firewall rules can be used with Access to take a more holistic approach at the L4 (network) and L7 layers (HTTP). We use Gateway locations to restrict DNS queries to malicious domains.
With employees working remotely, companies aren’t able to enforce network policies at their corporate office egress points. By using our WARP desktop client along with Gateway on our users endpoints, security teams can have visibility into DNS logs with the ability to enforce policies that were once able to be used at corporate offices while preserving privacy. Gateway functions as the DNS resolver on corporate devices. This not only allows teams to respond to incidents and identify the root cause more efficiently, but helps with prevention by identifying compromised machines that visited malicious domains. WARP ensures that the DNS traffic is encrypted, thus protecting the privacy of users.
Our Browser Isolation tool provides protection at a layer that is the closest to the user and where they probably spend most of their time accessing cloud based applications. It comes in handy for both prevention and responding. It can be used to remove access to certain SaaS apps, prevent users from copy/pasting, restrict printing, and block file downloads. In other words, the data hosted in cloud services can be protected at multiple crucial points that will make it more difficult to exfiltrate. Through policies Browser Isolation can be configured for individual domains, users and or broad categories of websites. Browser Isolation can also enable responders to quickly identify endpoints that may already be compromised by capturing which visited known malicious domains or downloaded certain files through the browser.
This is where a Zero Trust model really comes into play. If you haven’t heard of it before, here is a great introduction. Cloudflare Access is an important part of Cloudflare One’s set of tools that helps organizations implement a Zero Trust model on their network. We use Cloudflare Access to manage a uniform approach to policies for internal resources. As a Security Engineer on the Detection and Response team responding to an incident for which we have to make company-wide access changes, Cloudflare Access and Cloudflare Access for SaaS applications put us in a position to efficiently push out policies and focus on higher priority items without having to worry about application level changes. Managing access at a central point for applications that otherwise would have to be managed individually dramatically improves our time to respond.
Moving to the API layer, Cloudflare’s API Shield acts as the primary point to manage the security controls of APIs. Think about IoT devices that are exposed via numerous APIs, such as Tesla’s Gateway. API Shield provides a multi-layered approach to limit accidental data exposure. For example, schemas can be validated to minimize the likelihood that a downstream system is compromised by unexpected input; requests to the endpoint can be restricted to clients holding valid client SSL/TLS certificates; and noise coming from sources such as Open SOCKS proxies can be filtered out, along with requests coming from devices or regions that the API should not be communicating with. Today’s announcement includes new data obfuscation capabilities and later this week we’ll announce ways to discover “shadow” APIs that your security team may not be aware of, and spot anomalous call activity.
As a Detection and Response engineer, there have been numerous incidents where a security issue would require us to understand how access for these systems works on the spot. Different systems are managed differently and roles are not always uniformly defined. This made it very difficult to respond in the moment and most often than not, requires us to have conversations with the system owners to better understand the access. Using the multi-layered protection that Cloudflare One, Browser Isolation, and API Shield provide, security teams are put in a position where they can focus on prevention rather than reacting.