Cybersecurity professionals commonly blame the end user for being the top area of risk in securing the organization. In many ways, this is understandable. Systems and software are in our control; but end users are unpredictable. They expand our threat surface to each geographically dispersed user, personal device, and their potential for making errors that impact our security.
Obviously, threat actors target our users with real-world bad outcomes. But what is also obvious is that we cannot train our way out of this problem. Fortune 100 companies pour significant investments into annual user security awareness training, and still, they suffer breaches. So, focusing primarily on securing the end user isn’t an effective strategy.
Fact: your users are a major risk factor: according to Verizon’s 2022 Data Breach and Investigations Report, 35% of ransomware infections began with a phishing email. Fact: This is despite aggressively increasing investments in security awareness training over many years, which is expected to continue– The cybersecurity awareness training market is projected to grow from USD $1,854.9 million in 2022 to USD $12,140.0 million by 2027 and a CAGR of 45.6% from 2022 to 2027. Fact: Despite all these investments, ransomware (just as one attack type example) is also expected to grow aggressively, despite many organizational efforts including training end users. Sad, unavoidable fact: our users are still going to make mistakes—we are all human, after all. A survey conducted to prove the need for more security training, in my view, proved its inability to stop the cyber crisis: four out of five surveyed had received security awareness training; between 26-44% (based on age demographic) continued to click on links and attachments from unknown senders anyway. From these facts, we should conclude that organizational security must not rely heavily on securing the end user, and in fact, should assume they will be breached and begin securing systems with this assumption in mind. “Train and pray” just isn’t working. And, in the end, even if an end user is breached, the amount of systemic damage that is done by that compromise should not be possible if proper security measures are employed and orchestrated correctly.
Should we be training our end users? Absolutely, emphatically, yes. Strong security requires a layered approach, and that means fortifying your security by working to secure every doorway to your organizational systems. We would likely see even more large breaches without this training. But we must start looking at our security in a way that helps remove end user risk from the equation without a reliance on them to do the heavy lifting. For many organizations, this requires some difficult choices and significant leadership endorsement of these choices.
How Can We Reduce User Risk?
Organizations must work to block access and orchestrate security controls. Systems are too open by default; we must make them closed by default, evaluate each for risk, and then allow them with full intentionality. Users can’t click or open what they don’t have access to, and in the organizations we assess or remediate post breach, we see employees and systems having far greater access and risk exposure than is necessary in the course of work. Companies should layer on stronger security orchestration across their people, process, and technology so that, should a threat actor gain access through an improper click anyway (or via any other vector), there are controls designed to stop lateral movement of the threat actor and the harvesting/escalation of credentials. Here are some specific things organizations can do to remove end user risk:
Block access to personal email accounts: Users should not be allowed to access their personal email or social media sites from work devices. Personal email is not protected by corporate email filters but is heavily targeted by threat actors; social media is another unnecessary risk factor that should be closed by default.
Filter HTTPS traffic with deep packet inspection: More than 80% of the internet and 90% of command and control is encrypted; if an organization is not deep packet inspecting HTTPS outbound traffic (and most aren’t), then they are missing most of the internet and most threat actor activity—thus, the firewalls and web filters are basically doing nothing!
Block all outbound ports aside of HTTP (80) and HTTPS (443) on user subnets/VLANs by default: Users shouldn’t be able to get to the internet on any ports other than those required for browsing. Obviously, there are some organizational applications that require other ports to the internet besides ports 80 and 443; however, these ports should be opened by exception only with source, port, and destination scopes—where possible, intensively inspected by the perimeter control.
Block internet access to non-user subnets/VLANs by default: Servers and management/administrative and printer networks, as examples, should not have access to the internet on any ports or protocols. These networks should only be able to get to the internet outbound on the specific ports required for the applications running on them. All ports and protocols should be blocked by default and selectively allowed only as necessary for application functions.
Require all user traffic to be inspected and filtered all the time—no matter the location of the endpoint: Often, users’ traffic is not inspected with the same level of intensity when the user is working from home (or a coffee shop). Thus, the organization must implement controls to force all user traffic through the same filters and inspections—no matter where it roams.
Applications should not be accessible from unapproved devices by known good credentials and without MFA—no matter the network: Users should not be able to access organization-provided applications without being on organization-approved devices with correct credentials and MFA. Users should be required to present credentials and MFA, internally and externally, no less than every day—i.e., session tokens should expire no less than daily (preferably daily).
Disallow all but IT-approved filesharing systems and password vaults: Threat actors often use common filesharing systems to exfiltrate data, and cloud-based password vaults are a treasure-trove for hackers. IT should choose security-vetted, approved systems and disallow all others. This should become an operating paradigm of the organization: “Pick a tool and block all others.”
Start enabling security features (don’t assume default settings will keep you secure): Security tools and platforms like firewalls and endpoint detection and response (EDR) come with many security features that are not turned on (or are too open) in their default settings. As an example, many modern firewalls can prevent many of the methods used by threat actors; however, the features of the firewall are rarely all turned on. They often allow ALL TCP/UDP ports outbound by default; however, most users only need ports TCP 80 (HTTP) and TCP 443 (HTTPS). Threat actors use this to their advantage—this is another example where each system must be evaluated and selectively, intentionally blocked or allowed based on need.
EDR tools also offer strong protection capabilities; however, organizations often do not turn on all the features of these applications to get the most from the investment. Additionally, they often don’t complement these solutions with other stacked controls despite being advised by these companies’ own documentation to do so.
The Barriers to This Approach
There are several reasons why the level of blocking and orchestrating isn’t being done at the level required today, and instead, users are bearing the brunt of the responsibility for breaches. First, it can be unpopular by users (and leadership)—blocking access to personal sites, limiting access to favored platforms and slower access to systems incurred by filtering/inspection can cause a user dissatisfaction. Additionally, leadership anticipates and fears this user dissatisfaction. Some of the tools needed are also costly. But this is an educational exercise, which requires buy-in at the executive level of the organization.
IT needs to express both problems and solutions in terms leaders can both hear and understand. They must be able to present the very real risks and the results of failure to their C-level and boards, so that proper controls and associated costs can be allocated. Users can then be educated on why these controls are necessary from the top down; thus, security awareness education can shift to the next evolution from “don’t click and here’s why” to “We block most things by default, and here’s why.” Or, if after being educated leaders still choose to opt out of making more aggressive investments in tools and process, they now have skin in the game, personally assuming the level of risk they are choosing to accept for the organization.
Often, IT teams are also short on staff, overworked, and focused on the daily operations of the business. They can’t mitigate risks they can’t see; educate on threats they don’t know; or enable tools on which they aren’t trained. They don’t always have the data, cyber-specific skills, or influence to block, orchestrate, or gain the buy in necessary to fully safeguard the business. Nor are they in the midst of breaches daily as we incident responders are—viewing the carnage. Teams without this visibility should consider in-depth assessments of their controls, configurations, and orchestration from qualified, expert firms (such as Athena7). In some cases, organizations should consider leveraging external, qualified managed security firms, like Grypho5, to implement, orchestrate, manage, monitor, and report on specific controls—like backups, firewalls, and endpoints.
One thing is certain: no matter how much training we provide, users will always make mistakes. We cannot and must not let one click continue to put organizations so considerably at risk. It’s essential to minimize users’ options to click in the first place, and then ensure that, when they do, there are many layered controls in place to disrupt the progression of the attack chain.
