There are multiple meanings of the word compromise. For the purposes of cybersecurity, I would like to focus on two:
com·pro·mise | ‘kämpre,mïz |
verb
[no object] accept standards that are lower than desirable
[with object] bring into disrepute or danger by indiscreet, foollish, or reckless behavior
From a cybersecurity standpoint we have compromises that express as cutting corners, settling for less-than-ideal measures, and “doing the best you can with what you have”. Those cutting corners-type compromises can result in cybersecurity incident compromises—diminished safety, increased vulnerability, or actual exploitation of systems, data, and processes.
While the areas where we are often tempted to compromise are innumerable, there are a few general categories where these types of concessions seem to be most common and often justified as simply the way things are.
Often as technology advances our approach to cybersecurity doesn’t evolve to account for newer needs and newer threats. A provisioning workflow that’s been working great for years may not account for newer privacy regulations or the realities of a more mobile workforce.
Consequently, as a new user is on-boarded following a tried-and-true provisioning workflow optimized for on-prem systems, the attributes and controls that work for legacy access don’t exactly match what more modern cloud assets require. So, you guess or do your best to contort the established attributes and permissions to also support the newer requirements. Every compromise away from exactly what is right is an invitation for bad actors to find and exploit (or compromise) your systems and data.
The lack of a cybersecurity incident often leads to a false sense of security. That is until an incident occurs. Organizations are constantly forced to prioritize their cybersecurity efforts and spending, which inevitably leads to compromise. Which system gets your attention today? And, which systems have you decided to make the calculated compromise to address later (if ever)?
In these cases, the squeaky wheel gets the grease. This often forces a compromise on legacy systems. More than 90% of breaches today exploit legacy Microsoft Active Directory (AD) deployments, even though on-prem AD has been deemphasized by Microsoft for several years. Like AD, many legacy technologies remain vulnerable because attention has shifted to newer and “louder” systems. The lack of incidents on lower-priority legacy systems should be more of a red flag than a security blanket.
Compromise #3: That’s just the way it is
Some systems – for example many operational technologies (OT) – default to weaker security controls forcing organizations to compromise on best practices. Shared accounts, default passwords, standing administrator permissions, and lack of native support for multifactor authentication are all compromises that create significant vulnerabilities.
When these systems are exposed to the internet – as evidenced by recent attacks on US water utilities – the lack of modern and rigorous access controls are an attractive and easy target. The amount of effort required to remediate these vulnerabilities often leads to the compromise of “that’s just the way it is, and we can’t do anything about it.” Neither is true.
One of the major areas of compromise is the concept of over provisioning. In an effort to save time and work down the road, it is common for organizations to grant users all the permissions they might ever need. This is in direct conflict with the concepts of least privilege and zero trust. Since it may be inconvenient to provision access as it is needed, we often compromise. Obviously, over-provisioning a user (or a non-human or agentic identity) only provides one more weakness for bad actors to exploit.
Similar to over provisioning is the temptation to base permissions on a user rather than a role. Imagine a long-time employee that has been with a company for many years fulfilling various jobs and progressing through the ranks to a highly privileged role. When that user retires, it is tempting to compromise and simply grant their replacement the same entitlements that the retiring user held on their last day. The problem is permissions are rarely revoked when an employee moves within an organization. They may still have permissions totally unrelated to the job they had upon retirement. Now the new employee has all those permissions as well. New employees are prime targets for social engineering attacks and latent, hidden permissions are a jackpot for bad actors.
Most identity security tools are designed to remove manual intervention from necessary processes. A single sign-on (SSO) tool eliminates the need to manually logon multiple times. An identity governance and administration (IGA) solution automates the processes surrounding identity lifecycle management tasks, role management, and governance. These solutions can eliminate, or reduce, the delays of waiting for IT to perform a task and they remove human error from the equation.
Unfortunately, SSO and IGA solution rarely cover all necessary resources. For example, these solutions typically leave on-prem legacy systems and OT technologies out of their scope. Consequently, many organizations are forced to compromise and turn to manual processes for some of their most at-risk resources. Human error can open doors you don’t want open. Manual over provisioning (as mentioned above) and delays in de-provisioning result in excessive permissions and orphaned accounts, which can and will be exploited.
The concept of zero trust suggests you should trust no one and verify everything. That’s, much easier said than done particularly for third-party users, and difficult systems such as OT and agentic resources. For systems that must rely on outside consultants, vendors, or contractors for day-to-day management, the temptation (or compromise) is to grant all the permissions they might need to do their jobs and hope for the best.
This can be overcome by issuing access only as needed – a concept called just-in-time (JiT) provisioning—and by granularly assigning permissions with contextual, time-bound, and policy-based access controls. Unfortunately, most at-risk systems don’t natively support these concepts so we are tempted to compromise and trust where it is not warranted. And that’s what bad actors are counting on.
So, what are you to do? It’s a daunting task, but one that cannot be ignored. Here’s a few suggestions:
Backfill zero trust everywhere else. If you have faulty provisioning workflows, begin correcting course. If access controls are too broad, start inserting granularity into them. Start with your most at-risk systems and go from there.