Social Engineering is the Biggest Cyber Threat

We’re living in a pandemic of data breaches. More than 17 billion personal records were exposed last year, and 2024 has begun with a string of several high-profile back-to-back breaches in the first quarter, including data exposure of millions of AT&T account holders.

Big Tech companies are in the crosshairs, too, facing mounting criticism from government officials calling for urgent reform. Even the open-source software supply chain is under threat from social engineering campaigns looking to compromise maintainer projects.

‘Social engineering’ is the key term here because it’s not software vulnerabilities that enterprises should be worried about. Those only make up 5% of breaches, while 68% involve the human element. How can this be? And what should companies do about it?

The doors we open for hackers – and how to close them

Exotic and sophisticated zero-day attacks and vulnerability exploits may garner the bulk of attention from the press, CISOs, and security teams, but the reality is that today’s cybersecurity tools are becoming exceedingly efficient at preventing and remediating these attacks.

Hackers know this. They’re not going after software vulnerabilities. They’re attacking identity because it’s far cheaper and easier to exploit or force human error. So, they target credentials such as passwords, browser cookies, and private API keys.

The data says it all, really: a Verizon report proves these credentials show up in 86% of security breaches related to web-based applications and platforms.

Obtaining these credentials is how attackers do the most damage with minimal ease. Sometimes, these credentials are shared a little too freely. Other times, a shocking amount goes unused. The point is that organizations have lost control of their credentials, and the result is a growing fragmentation of identities across increasingly complex technology stacks. Those stacks are filled with layers that manage security in different ways, from Kubernetes clusters to Linux servers, copious amounts of specialized databases, IoT, cloud APIs, etc.

It gets even more convoluted on a granular level once you’re inside a cloud account. If you have three Windows servers and seven Linux servers, each of those also governs its own login credentials. If you’ve got a multi-cloud setup with both AWS and Azure, those companies also track identity in different ways.

In the quest for greater efficiency, DevOps engineers are even splitting cloud-native applications into smaller micro-services, each needing its own identity.

Each of these layers opens yet another door for attackers to enter. If you’re an enterprise operating with more DevOps and cloud infrastructure, you’re inevitably going to add even more layers to the stack. More layers mean more doors.

In other words, the mere presence of secrets, such as private keys, API keys, passwords, or even browser cookies, should be seen as a vulnerability waiting to be exploited in an identity attack.

Stop using secrets for access purposes

The problem isn’t the technology itself, though, but human behavior. Any time you create more doors, you’re increasing the probability of human error.

So, how do you fix these data breaches? The first step is to consolidate all identities. All identities - including people and machines like servers, laptops, bots, databases, microservices, etc. – must be united into an inventory that provides a single source of truth.

The second step is to make these identities impossible to impersonate or “steal”, effectively making the infrastructure security immune to human mistakes. To do this, minimize or eliminate the reliance on secrets for authentication purposes.

As a rule, your identity should also never ever be presented as information. The only way to prevent data theft on a catastrophic scale is to remove all static credentials and standing privileges and instead deploy strong authentication with cryptographic identity. In practice, this means basing identity on three-point criteria that include 1) a user’s specific device, 2) a biometric marker, and 3) a personal identification number (PIN).

In theory, this is exactly how the iPhone works: the biometric marker is facial recognition, the personal identification number is your PIN code, and the Trusted Platform Module (TPM) chip inside the phone is what governs the ‘machine identity.’

But credentials – or doors, if you will – are just half the story.

Observability isn’t enough

The thing about human error is that it’s blind to the quality of your cybersecurity and observability tools. It only takes one human to make a mistake by granting access to the wrong people.

This already happens. As we learned earlier this year, Google Kubernetes Engine admins are not immune to misunderstanding the significance and scope of default user groups and assigning dangerous permissions to them.

The cybersecurity industry has spent a disproportionate amount of time and money on observability. Companies are acquiring and maintaining tools to respond to threats rather than fix enforcement to proactively protect infrastructure.

One reason companies tend to be put off by fixing enforcement is the aforementioned complexity of modern technology stacks. The natural assumption is you need competent teams who can configure every single layer with its own authentication, its own authorization, its own encryption, and its own audit.

The smarter solution here would be for the cybersecurity industry to embrace a new paradigm for modernizing secure access to infrastructure. This paradigm has to be built on embracing mechanisms that unify all access within a single control point for authentication and authorization. Most enterprises sorely need (and yet lack) this mechanism as a front-end to all of their disparate infrastructure.

Access should only ever be granted based on tasks, and only the minimum required privileges should ever be granted. These should then be de-provisioned immediately afterward. This concept of on-demand least-privileged access then needs to be applied to both human and non-human machine and service accounts.

In other words, every company should be able to easily enforce the policy that developers should never have access to production data. However, without unified access controls, this will remain a sci-fi concept for many cybersecurity professionals.

Unifying access controls isn’t just helpful in the proactive sense. If a data breach does eventually occur, a centralized view of all the access relationships attributed to a user or resource is essential for purposes like quickly revoking unwanted access or auditing. This is how enforcement and observability can be combined for agility.

And if you’ve already assigned cryptographic identity beforehand to each individual user or resource, you’ve now associated the actual human user with each action. This means assigning the right permissions to the right people becomes a much easier task.

Defend against human behavior

There are, of course, positive signs of technology leaders in the industry taking data breaches very seriously. Microsoft has pledged to shore cloud vulnerabilities, prevent credentials from being stolen, and automatically enforce multi-factor authentication for employees. Any efforts to embrace stronger authentication and cryptographic measures should be commended.

If cybersecurity is going to ‘win,’ though, enterprises have to understand that stopping data breaches isn’t about defending against viruses or ultra-sophisticated hacking techniques. It’s about defending against human behavior that exposes infrastructure to data leaks. That’s the mindset that needs to change. Unified access control, paired with zero trust, must be the foundation for modernizing secure access.