Modern Threat Vectors and Device-Centricity

At my first job in the mid 1990s, I was given a workstation to use (a DEC Alpha, for those that were also there). When it came time to look for a new job, I remember using that computer in the office to format my resume and apply for new jobs. Since that first experience, each job I had meant I always used my work computer for personal activities, whether it was booking a trip, shopping online, or even just chatting on AIM (which some would argue was the precursor to Slack). Most of us weren’t even thinking about modern threat vectors following us into the home.

Device-centric security and threat vectors

For decades, the line between a work computer and a personal one has been blurred. Accelerated most recently by both the escalation in remote working, increased computing power is available to anyone with a credit card and a place to sit—it used to take a university budget and a warehouse to store a computing system, after all. With this shift, commodity threats that were previously focused on personal computing are now becoming enterprise threats.

Let’s look at following scenario from a security lens (one that is all too real for me). Imagine that a child enjoys video games, and perhaps this child likes your much more powerful current model 16” laptop than the cheap laptop they have been assigned from school. Perhaps this child pesters you constantly about why can’t they use yours because you watch movies on yours already why can’t they game on it because…and eventually, I relent. Wait, I mean hypothetically you relent, and let them use it. Here’s where this can go:

Your child, who is not supposed to be on Discord, gets their friend to send a link to the latest game mod for their favorite game franchise. You know the one that the Twitch streamer was promoting?

The mod is installed. The mod auto updates. The mod replaces a shared lib (perhaps a DLL) that should not have been writable. The mod now has admin access. The mod now tries to impersonate me…and access my enterprise resources.

How did this happen?

Device-centric security versus network-centric security

Here’s where I pivot to explaining why device-centric security is so crucial: historically, the mental model for security has oriented around protecting the network to which devices are attached. This model, designed as a connectivity tool, was once great for sharing files between computers, but bad for containing malware. Over time, security controls were added on top of this model, but as the nature of device usage changed, the security model has lagged behind.

In this example, each step of the way will highlight how network-centric security has become irrelevant, and usually part of the problem, and why Banyan chose instead to develop its product around protecting the devices, not just the network. It’s a bold statement but here’s the logic: relying on the belief that a security system will protect you often leads to riskier behavior, so if the security model is fundamentally flawed, that risky behavior leads to even worse outcomes.

The new security models being adopted today focus more on the network being a “dumb pipe,” there just for connectivity, and independent of the security model being designed. There no longer is a concept of malware “being on the network,” and the focus is on how to stop and contain bad actors in a distributed world.

Step-by-step attack breakdown

Logging in to a device lets someone enter the user space on the operating system for the user; next, they are granted local permissions. Their password is generally matched by the local operating system which is sufficient to give them access to the applications that are already installed. Their identity is typically not validated against a remote identity service at device login time, because devices need to be usable when networking services and connectivity are not available.

Phase 1 – Setup: In this scenario, the parent has logged into the device with just a password, and then permitted the child to work in the user space in their operating system. The extent of the authorization is just the local device. This action brings up questions for standard enterprise security models that may not be obvious at first glance. In the modern enterprise, authorization primarily governs who can access which enterprise resource, and devices are not part of the equation. So a child is now essentially masquerading as the employee on the device, and no security system can tell the difference.

On the device itself, there are usually only two levels of authorization, user and administrator. In the old model where a workstation was always tied to a specific network and personal use became restricted, it was more common for admin privileges to be rationed tightly. But, as laptops have taken over and employees use the workstation for personal needs, this admin right has been more widely granted on the device, while still withholding it on the remote resource or service side.

Often these devices have some degree of management, whether it’s to make sure the devices are patched, having their operating systems up to date, or ensuring that disks are encrypted and local firewalls are on. This management is helpful for limiting the exposure of the operating system itself, but in this scenario would have minimal impact on the outcome.

The next step in this vector is the downloading of the content that will later turn malicious. In this example, the content is perhaps a mod for a well-known game and comes with an installer. Nothing nefarious belies the initial install package: just put the mod files in the right location, and check the box saying it’s ok to automatically update when new changes are available.

Thinking through this step, the following considerations were made:

• Is there content filtering enabled on the device, and if so, is it independent of the network to which it’s attached? If the corporate internet filter for acceptable use and malware is only available via a VPN connection when accessing corporate resources, then it’s pretty irrelevant in this situation. Even if the filtering is in a modern ‘roaming’ model, this download could be hosted in any number of places: from official app stores and common gaming sites, to social media forums, not to mention obvious cautionary forums like 4Chan. The content policy here would need to be quite broad to catch these categories.
• What about CASB-style content blocking on a URL that catches the download of certain file types, like .pdf’s or executables? Even if the CASB is independent of the network, it is easy enough to have the download be a zip file. Not many organizations will be blocking zip file downloads without seriously impacting productivity. The last aspect is something to inspect the payload as it is downloaded, looking for signature and other sophisticated pattern matching, but again, this download is not bad at this present time.

The mod is now successfully installed and the antivirus has not detected anything malicious, and so the situation stays for some time but the table is set for the intrusion.

Rolling forward: there can be many triggers that activate the attack. The mod creators could be malicious, they could sell it to a bad actor, or they themselves could be the subject of an attack…or their supply chain could become compromised.

Phase 2 – Good Goes Bad: Now an update is made available that downloads the malware. Any number of activities could take place, but let’s explore a vector that leverages an exploit where a dll of an application that runs with admin privileges is accidently set with writable permissions, so the malware overwrites it with a compromised file that now has escalated rights.

Phase 3 – Takeover: There is now a race underway. How long from when this exploit is first leveraged until  EDR has a detection and can enforce it? There is always some lag time, which can be days, months to even years in the worst-case scenario. Once Phase 4 (Detection) happens and EDR does detect the intrusion, how long until the issue is removed and remediated? How quickly can access be revoked to sensitive resources that this device has access to? These are heavily dependent on the processes and tools of the security team.

While the malware is active on the device, there are obviously an endless number of things it can do, but they often fall in either exploiting the resources of the device, or leveraging the device in order to gain access to something with more value. Exploiting the device itself (through ransomware, data exfiltration or crypto mining) is clearly not good. Yet, this often just affects the singular user of the device and their productivity is impacted (or their scope of data is exfiltrated). Let’s not forget that leveraging the device for further exploits can have more significant consequences.

Visual Timeline of Steps

Threat vectors need device-centric security

Looking back to the mental models, the old point of view would declare that malware is now on the network, as anytime the device is on the network the malware is free to make connection attempts to any other resource that it can discover on the network. However, this model of thought is very rigid and leads to greater desire to lock down resources, expanding assertiveness in control on the device, and a reduction in the productivity and effectiveness of the user on the device.

In the new mental model, where the network is just a form of connectivity, there is flexibility in looking at what resource is being accessed and what type of connectivity is being used. When tools are being looked at, whether internet filtering or CASB, tying them to the network a device is on limits their usefulness.

Last, when looking at this attack vector, the number of critical security tools that are directly involved is eye opening. Each one has a specific ‘jurisdiction’ or focus of its security aspect: Identity (IDP), Internet Filtering (SWG), AntiVirus (EDR), remote connectivity (VPN), and Device management (MDM & DeviceTrust). Getting these to work together, in concert, and leave the gaps as small as possible is tricky, which is why having an easy-to-deploy SSE platform is a crucial first step.

The post Modern Threat Vectors and Device-Centricity first appeared on Banyan Security.

*** This is a Security Bloggers Network syndicated blog from Banyan Security authored by Colin Rand. Read the original post at: https://www.banyansecurity.io/blog/threat-vectors-sse/?utm_source=rss&utm_medium=rss&utm_campaign=threat-vectors-sse