Something’s happening in the realm of cybersecurity: breaches and data leaks are happening everywhere. Here’s a shortlist of the last few months:
These attack vectors are endemic for most organizations today: GitHub repos, 3rd-party services and software, stolen access tokens, unsecured APIs, usage of corporate VPNs, and more.
While all of these breaches were caused by different vectors, we can take a step back from the confusing details to see the unifying factor in all of these preventable breaches: portals.
In this post, we’re using the term “portals” to refer to any gateway that provides a possible entry point for a hacker into your organization’s network infrastructure. This can refer to the above list of attack vectors including internal apps, unsecured endpoints, and more. Anything that grants an attack surface to your infrastructure is a potential portal.
So…what’s going on?
Proliferating Portals
Welcome to 2023, where everything has a portal! From your smartcar to your smartphone to your work computer to your digital accounts — if it’s connected to the internet, it probably has a portal.
These portals are becoming necessary because companies are embracing the rise of remote work and products want to update via the internet. The thinking is simple: if it’s a consumer product like a car, it can be improved via internet updates. If it’s an internal app like Grafana or Kubernetes, it needs a portal so employees can access it.
However, an access point is an access point. These portals come with inherent dangers: what happens when someone with bad intentions accesses the portal? It results in the list of recent breaches you saw above.
This can go poorly in many ways. If it’s a portal for a company’s internal infrastructure or apps, this can result in source code being stolen or ransomware attacks. If it’s a portal for a car with self-driving capabilities, then consumers better hope the hacker doesn’t have malicious intentions. Even innocuous things such as a portal into a toaster can become a costly and destructive fire hazard.
People tend to think they are secure with the tools they use everyday, or at least assume the makers went the extra mile of securing the portals into those tools. In the best case scenario, these portals are secured by highly trained professionals applying the best access control practices to ensure that network infrastructure isn’t easily breached.
But this is often not the case, especially if the portal is poorly secured using antiquated security models (such as perimeter-based security, which even the slow-moving US government is hastily pivoting away from).
This leaves the real threat of being:
One lateral movement away from a hack
One poorly implemented SSO integration away from unauthorized user exploit
One VPN with embedded credentials being stolen and repurposed (compromised credentials cause the most breaches)
The next headline news
Every company breach we see headlining the news previously thought their portals were secure. That’s why so many breaches are happening; but what’s causing such a major mismatch between expectations and reality?
Portals Are Hard to Secure
This is due to the inherent conflict between what portals are for (improving productivity, granting access, enabling remote work, etc.) and the risks that portals bring (breaches, entry points, CVEs, etc.). Security vs productivity, the age-old friction.
Because few engineering cultures budget for security, even famous tech companies are seeing breaches as a result of poorly secured portals. That’s not because they don’t hire the best talent, but increasingly because they’re assigning the task of security to the wrong person.
Many portals are being secured by developers who just aren’t specialized in security. This is NOT a dig at them (as I’m confident these developers are incredibly good at their own specialties), but more of a realistic observation that specialization does exist and produces different results. There are arcane authentication and authorization protocols like OAuth2 or OpenID Connect which even security experts need time to understand. Does a developer’s experience with SAML come up during the hiring interview?
The cybersecurity industry itself has a gigantic skills gap; why would developers who are not cybersecurity professionals be able to make up for the difference just because they read a few posts on authentication vs authorization? No, these developers and software engineers were brought on to create a product or develop a feature. Then when it came time to put a bow on it and ship, the developers were also expected to put the finishing touches on securing the portals to these services.
Securing these portals is just as important as the product itself, and should not be treated as an afterthought by individuals who can’t be expected to specialize in it. Using developers to secure portals always seems like a “temporary solution” — and it works until it doesn’t.
Bridging the Skills and Specialization Gap
We accept that developers have a specialization gap (based on trending results). Organizations are also loathe to hire cybersecurity professionals during a skills gap.
So we released a new Javascript SDK to save developers time implementing authentication and authorization for internal applications, services, and portals. By using this SDK, developers can easily bridge both gaps because Pomerium is handling portal security, giving you peace of mind. This frees up developer teams to be productive developing core business features.
Better yet, it’s open-source so any organization is free to look through the code and see that it does exactly what you need it for: securing your portals.
Solve Access Control with Pomerium
Pomerium is the top choice for companies looking for an open-source context-aware access gateway to manage secure, identity-aware access to applications and services. Our customers depend on us to secure zero trust, clientless access to their web applications everyday.
Check out our open-source Github Repository or give Pomerium a try today!
