There’s a reason for all this. Most security processes are designed by engineers with a background in developing technology products. They approach security as a technical challenge. Users are just another action into the system, no different than software and hardware that can be programmed to perform predictable functions. The goal is to contain actions based on a predefined template of what inputs are suitable, so that the outcomes become predictable. None of this is premised on what the user needs, but instead reflects a programming agenda set out in advance.

Examples of this can be found in the security functions programmed into much of today’s software. Take email apps, some of which allow users to check an incoming email’s source header, an important layer of information that can reveal a sender’s identity, while others don’t. Or take mobile browsers, where, again, some allow users to check the SSL certificate quality while others don’t, even though users have the same needs across browsers. It’s not like someone needs to verify SSL or the source header only when they’re on a specific app. What these differences reflect is each programming group’s distinct view of how their product should be used by the user — a product-first mentality.

Users purchase, install, or comply with security requirements believing that the developers of different security technologies deliver what they promise — which is why some users are even more cavalier in their online actions while using such technologies.

Time for a User-First Security Approach

It’s imperative that we invert the security paradigm — put users first, and then build defense around them. This is not only because we must protect people but also because, by fostering a false sense of protection, we’re fomenting risk and making them more vulnerable. Organizations also need this to control costs. Even as the economies of the world have teetered from pandemics and wars, organizational security spending in the past decade has increased geometrically.

User-first security must begin with an understanding of how people use computing technology. We have to ask: What is it that makes users vulnerable to hacking via email, messaging, social media, browsing, file sharing?

We have to disentangle the basis for risk and locate its behavioral, cerebral, and technical roots. This has been the information that developers have long ignored as they built their security products, which is why even the most security-minded companies still get breached.

Pay Attention to Online Behavior

Many of these questions have already been answered. The science of security has explained what makes users vulnerable to social engineering. Because social engineering targets a variety of online actions, the knowledge can be applied to explain a wide swath of behaviors.

Among the factors identified are cyber-risk beliefs — ideas users hold in their mind about the risk of online actions, and cognitive processing strategies — how users cognitively address information, which dictates the amount of focused attention users pay to information when online. Another set of factors are media habits and ritualsthat are partly influenced by the types of devices and partly by organizational norms. Together, beliefs, processing styles, and habits influence whether a piece of online communication — email, message, webpage, text — triggers suspicion.

Photo by Dex Ezekiel on Unsplash

Train, Measure, and Track User Suspicions

Suspicion is that unease when encountering something, the sense that something is off. It almost always leads to information seeking and, if a person is armed with the right types of knowledge or experience, leads to deception-detection and correction. By measuring suspicion along with the cognitive and behavioral factors leading to phishing vulnerability, organizations can diagnose what made users vulnerable. This information can be quantified and converted into a risk index which they can use to identify those most at risk — the weakest links — and protect them better.

By capturing these factors, we can track how users get co-opted through various attacks, understand why they get deceived, and develop solutions to mitigate it. We can craft solutions around the problem as experienced by end users. We can do away with security mandates, and replace them with solutions that are relevant to users.

After billions spent putting security technology in front of users, we remain just as vulnerable to cyberattacks that emerged in the AOL network in the 1990s. It’s time we changed this — and built security around users.