Fight social engineering attacks with zero trust principles
When people talk about zero trust, the first thing that comes to mind is the network, the infrastructure, or the architecture of the enterprise. That is a good starting point, but IT organizations only start to reconsider policies and procedures to support the new concepts during implementation. At this point, IT pros really start to understand what a true zero trust transformation entails.
It entails everything.
To get a handle on it, start with the industry-standard source for zero trust architecture: The National Institute of Standards and Technology. Its NIST 800-207 special publication on zero trust focuses on IT infrastructure, introducing the policy enforcement point (PEP) as not only a centralized application access and authorization point but also a mechanism for stopping malware and other cyber attacks. Gartner and many vendors call it secure services edge (SSE). The idea of funneling all application traffic through a PEP should allow enterprises to regain control of their security posture in this age of ransomware and cloud adoption.
That said, recent high-profile attacks have shown that, even if there was a PEP in place, social engineering attacks would have rendered it ineffective. Policies and procedures play a major part in any organization's information security, but when those procedures are broken through bad decision-making by humans, the results can be disastrous. Case in point: a $33B company was knocked completely offline after a “10-minute conversation” allowing a threat actor to fraudulently access an employee’s user account.
Changing policies and procedures for employees to support a zero trust architecture is not enough. These need to be enforced to reduce the risks caused by bad decision-making.
Today. I’ll explore the concept of a “Human” or a “Decision-based” PEP.
Creating policy enforcement points for people
Think of all the ways poor human decisions put their organizations at risk: A help desk employee is convinced through social engineering to reset an employee's account credentials over the phone. A smishing (fraudulent texting) attempt to impersonate the CEO causes an employee in finance to wire a large sum of money. Even a rogue executive wiring money to himself after becoming disillusioned with his career at the company.
Those events are made possible because when procedures are not enforced, employees can easily bypass or ignore them, or there are simply no official procedures on the books.
Ad hoc tasks are completed at the whim of the employees.
Workflow automation platforms exist today to formalize procedures, streamline approvals, and document actions, amongst other things, but these platforms are also a critical tool in a zero trust architecture implementation.
If the tools and services used to perform business-impacting actions are directly accessible, employees operate at their own discretion and the process is open to abuse. If the tools are not accessible, and the specific actions are gated behind the workflow automation, the process compliance rate will be much higher, reducing risk to the enterprise.
Take the help desk employee scenario, for example. That employee should not have direct access to “Active Directory User and Computers'' for that password reset. Instead, a workflow automation tool that absolutely confirms the verification requirements should perform the password reset via API. The same concept should apply to resetting or bypassing MFA.
By taking discretion out of everyday tasks and applying zero trust principles (i.e., never trust, always verify) to employees performing those tasks, we can reduce risk and eliminate attack vectors targeting the enterprise. This is especially important since many enterprises outsource these functions to low-cost third parties.
Enterprises can do much of this now, but, as always, it takes effort and resources already in short supply at many IT shops.
Social engineering attacks are getting more sophisticated, especially with the emergence of AI tools for cloning voices and generating deepfakes, and simply gating actions behind workflows or educating employees on what to look out for will not be enough.
But rather than just informing employees of a process that needs to be followed, what if the workflow tool performed the identity verification? The help desk employee would not need direct access to the password reset or MFA tools. That verification could include multiple sources, like the IDP, MDM, EDR, telephony, etc. Wrap all those up together to calculate a certainty score, and your organization is suddenly much more secure (IMHO) than with the help desk asking a couple of simple questions.
Why have a human in the mix at all?
Now consider the employee in the finance example. What if the finance staff had limited access to banking systems, did not know bank account numbers, and all transactions had to go through the PEP? AI or traditional RPA could automate the entire invoice/PO process, so why involve humans at all beyond performing approvals or checking suspect requests? This is happening today within some large enterprises, but with AI tools becoming a commodity and cloud services maturing, these capabilities will soon be widely available.
An IT organization’s role today is to enable the business while keeping it secure. While this includes introducing new capabilities to promote growth and competitive advantages, it also means constantly upgrading existing capabilities to reduce risk. And this does not mean just patching infrastructure but improving processes and policies to accommodate environmental changes.
With the advancing social engineering threats, we must work to take human discretion out of the picture or continue to suffer the consequences. Enterprises will encounter a constant arms race to fight AI-influenced threats. That day may already be here.
What to read next