[BreachExchange] Risks associated with third-party access

[Destry Winant]

https://www.csoonline.com/article/3294707/access-control/risks-associated-with-third-party-access.html

We all know that an insider threat is often the biggest challenge an
organization needs to be equipped to deal with.  Some of the most
infamous breaches in recent history have been the result of “trusted”
insiders who have turned to the dark side.

The other, rather obvious threat is from the unknown attackers who are
probing our environment looking for weaknesses and exploiting them for
fame, money, or just because.

These two threats can easily be thought of as good guys against the
bad guys; in fact, I often hear people referring to identity and
access management (IAM) as “keeping the good guys good and the bad
guys out.”  So, is that it?  There are only people inside our networks
and bad actors outside?

Well, there’s a middle ground that we need to remember and that is the
3rd party partner.  This person is neither the trusted insider nor the
external threat but, in my experience, this may be your biggest
challenge yet.

This, again, is not a new concept.  In ancient times people would
create small networks of trusted people simply called a village.  The
people in that village knew who their enemy was and were prepared to
protect themselves against an attack.  However, every now and then a
travelling bard or trader from afar would arrive and typically be let
in to entertain or trade.  This was a necessary evil and while this
outsider was always watched carefully, sometimes the trust of the
village was exploited.  So, what would this look like in your company?
 What threats do these folks present and how do we limit our exposure?
 Let’s take a look at a fairly common scenario and then focus on two
critical measures you should take to protect yourself from being
exploited by these travelling bards.

External partner access to your company can come in many shapes and
forms.  At a company I used to work for we had systems that would
collect theater box-office data from around the country.  There
people, who were not employees, set up to login and upload their
attendance counts from the theater every week.  At the time, we didn’t
use a modern approach to managing this outsider access and the result
was a real mess.  A more common scenario would be an external shipping
company that needs to login and look at your current inventory levels
or an external HVAC vendor that needs to login and download work
orders for the next job.  In all these examples, the vendor has a true
need to connect and get real-time information to do their jobs.  But
are you really, truly sure who these people actually are when they
connect?  This question leads us to our first important security
strategy; home-realm federation.

Federate your partner access

The number of companies I work with that are faced with this challenge
are all too many and most of them manage external vendor access in an
internal LDAP directory, database, or even Active Directory.  This
approach makes sense, eh?  You can create the accounts, track when
they login and manage their passwords and such.  Why not do it this
way?  The easiest example of how this fails is the simple fact that
you cannot truly vouch for the person who is logging in.  Sure,
perhaps “Bob” did work for Acme Shipping and his access to your
environment was legitimate.  But when Bob was fired because Acme
Shipping discovered he was stealing from the company, did they call
you right away?  Did they call you ever?  The truth is, Bob can
connect to your environment days after being let go from Acme Shipping
and wreak havoc on your shipping systems.  To put it bluntly, do not
ever take on the responsibility to vouch for the legitimacy of an
external partner.  Rather, force your vendor to authenticate those
users before they even get to your environment.  This can be done with
simple federation, like SAML or WS-Federation and sometimes OAuth.

Home-realm federation is the term we use to describe the process where
someone who is trying to authenticate is actually redirected back to
their “home-realm” (aka their company’s network) where they login
against the internal directory at the vendor itself.  If that person
was fired today, it’s not likely they will be able to login in their
own home-realm and that is where the access attempt will stop.
However, if the vendor allows the user to sign in, they reply back to
your security layer with an identity token that not only proves this
person is still a trusted partner but one that also contains
attributes about the user like what projects they are working on or
what their roles are.

I know this might not work for you, many vendors simply do not have
the ability to federate their employee access to your environment, but
that simply doesn’t matter.  You must pursue this as a core goal of
your security posture.  Get it done!

Eliminate VPN access!

So now let’s imagine we are back in time again and at a castle as a
trader approaches the wall.  We really don’t know this person, but the
trader is carrying an identity certificate from the next kingdom over
the hill.  Our castle is rather fortified, tall thick walls and
defensive battlements keep all but the most intrepid attacker out.
The trader says he’s got a basket of oranges that he’d like to deliver
in trade for some of our rare coffee.  So, do we let the drawbridge
down and give this trader full run of our castle? Or should we simply
open a “trade portal” where he can pass his oranges through and we can
pass our coffee without allowing him inside our castle?  Creating a
portal where business can be carried out securely and with as little
risk as possible is always the better option. How exactly do we do
this?  Reverse proxy.

If we were to track some of the more famous breaches in our time, many
of them came from this exact attack method, VPNs.  In truth, it wasn’t
always the partner themselves but rather someone else who had attacked
the partner first and then received unfettered access to your network
via the VPN.  Given that most vendor access needs only to be granted
to a web page, or perhaps a REST API endpoint, this is where a reverse
proxy will shine.  The proxy should authenticate your user via their
home realm, calculate risk and access rules. Then simply go behind the
firewall to get the data and “proxy” that information to the partner.
At no point is this partner ever on your network. They won’t be able
to scan vulnerable ports, databases or harvest admin credentials.

It can be done correctly

Earlier I called it a “necessary evil” to allow a third-party access,
and that is quite the proper phrase for it.  We have no choice but to
grant access to our partners. However, it simply cannot be done
blindly. It must be approached with a modern secure process.  The two
methods mentioned above will go a long way in giving you the peace of
mind you need to grant the access that is required, without giving
them the keys to the kingdom.