BreachExchange mailing list archives
Risks associated with third-party access
From: Destry Winant <destry () riskbasedsecurity com>
Date: Mon, 6 Aug 2018 03:29:30 -0500
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. _______________________________________________ BreachExchange mailing list sponsored by Risk Based Security BreachExchange () lists riskbasedsecurity com If you wish to Edit your membership or Unsubscribe you can do so at the following link: https://lists.riskbasedsecurity.com/listinfo/breachexchange
Current thread:
- Risks associated with third-party access Destry Winant (Aug 06)