Hey. I heard a rumor that a large retailer was breached. And that a significant contributor to that breach was the access that an attacker was able to get through one of the retailer’s vendors.
Okay, maybe it is not just a rumor. But does it make you wonder about your own vendors? Do you wonder if you have exercised reasonable control over them?
To be perfectly honest, I have not seen a ton of breaches through vendor relationships (in comparison to other sources). But, I have seen a few. Probably the biggest one I ever saw is an old one. A large electronics retailer (let’s call them ABC) was outsourcing some development and IT responsibilities to an overseas company (VENDOR).
oVENDOR was given the capability to push code into the ABC environment, and migrate it through a reasonable development management process – development, unit test, integration test, full test, final staging and production. ABC and VENDOR had worked out a pretty rigorous process to help ensure that development was planned effectively and that only truly functional code rolled to development. Their “errors in production” dropped to near zero, so by all reasonable measures the relationship was considered a success.
At least until mysterious user IDs started appearing throughout the ABC environment.
ABC was doing some ad-hoc auditing of their environments and pretty much stumbled on unauthorized user IDs, some of which had elevated privileges and access to data that VENDOR did not need. It only took ABC a matter of minutes to isolate the “new” user IDs to VENDOR access, but VENDOR vehemently denied creating the user IDs or accessing any of the proprietary data.
VENDOR and ABC spent a significant amount of time investigating, and eventually found out what was going on. VENDOR also supported XYZ, who was also a large electronics retailer, and a direct competitor of ABC. To summarize the ending of the story, ABC was being attacked by XYZ through their common VENDOR, and at the time they called it a “substantial breach.” I never did hear if the attacks originated from outside of XYZ, or if they were determined to be from overzealous resources within XYZ, but the main point was that the victim company (ABC) was attacked through their vendor (VENDOR).
True Vendor Management is not Just About Managing Vendors
Vendor management can be a complex issue. There are careers, software solutions and, indeed, entire companies built around helping to successfully manage vendors. But when it comes to the security responsibilities of those vendors, answers are still often behind where they need to be.
Depending on your exact context or security regulation, you can think about vendors as third-party service providers, outsourcers, business associates, as well as a variety of other names. You name it, and someone probably outsources it. I once dealt with a client who had given their coffee delivery company external network access so that the company could run remote diagnostics of their super-espresso machine. Was that a good idea?
Vendor Security is a Regulatory Requirement
Standards groups recognize that organizational security actually extends to the third-party. PCI-DSS states pretty emphatically that if you outsource any responsibility for your PCI data to a third party, then that third party either has to go through their own PCI assessment, or they are included in yours. That is pretty succinct guidance. They are included. Period.
HIPAA and HITECH use a lot more words to say the same thing, and more. According to HIPAA and HITECH, an organization which maintains and processes protected health information for a covered entity (CE) is a business associate (BA), whether or not they have been formally named a BA (simplified definition), and whether or not they have a BA contract. Further, if you are a BA, you are just as responsible to meet all of the requirements of HIPAA and HITECH as is a covered entity (CE), whether those restrictions are listed in a contract or not. Even better, a CE is liable for actions taken by the BA – again, whether the CE has formally named them as a BA or not (that is not to say that the BA is NOT responsible – just that saying “it’s the BA’s fault” is not an option). Some of these rules will go completely into effect as late as 9/22/2014, so get ready to rewrite your BA agreements.
So, How YOU Doin’?
What are some things to think about in the way you manage your security with your vendors? You might note the way I ask that question, since the security of your vendor relationship is your responsibility.
1. Do you need that vendor?
I hope you agree that granting network access to the coffee vendor was a little gratuitous. But, outsourcing is a popular way to try to get work done by using external resources. If a vendor can do something cheaper, or faster, or better, or if you have made some reasonable business decision that says you are outsourcing, by all means, outsource. But before you do, think about it for a minute and first decide if it really is worth it. Second, decide if that vendor really does need any external access. If you don’t need them to have access, don’t give it to them. Worst case, if you ever need to give them access in the future, only grant them access when they need it.
2. Has the vendor performed a risk assessment?
Get a copy of that report. Or do your own risk assessment, or hire out a third-party assessment to be performed on the vendor on your behalf (with the vendor’s permission and assistance of course). Under the HIPAA Omnibus Rule, if you are a CE, you are required to get proof from the BA that the BA is taking appropriate action to protect health information. Proving compliance (that, for instance, the organization’s security program is based on a risk-based security assessment) is actually a requirement.
Even without that requirement, before you connect anyone to your network, you want to make sure they have reasonable control over their own environment. There was once a state government that connected to a local provider for outsourced IT services WITHOUT first fully vetting the provider. Within a couple weeks it was discovered that vendor staff, government staff and unauthorized outsiders were playing an X-rated version of DOOM on government servers. Oops.
3. Does the vendor have secure access?
Like VPN access with strong authentication? If your own users connect with an encrypted VPN and use a token to authenticate, you should have at least that much control over the connection an outside vendor uses. This means “encryption” AND “strong authentication,” so is not just a “pick one.”
If you are not providing secure access, then you are providing unsecure access. A couple years back a vendor was selling and installing their own PoS system, and part of the install process did not involve changing default passwords. The original goal was to allow vendor access so they could perform remote maintenance, but imagine the chaos once criminals discovered the default settings. Oy.
I was personally involved in an incident where a vendor supported their disk management and mirroring system through a telnet connection. The customer service group at the vendor found they had been attacked as part of an internal intrusion, and that attackers had accessed their customer service database. Telnet user IDs and passwords were easy to use, and highly portable. Unfortunately, at the time, not a single one of their clients was doing any logging on telnet, so they had no idea if any of the clients had “extra” logins. Fortunately, it only took them a few hours to reset user IDs and passwords, or get clients to turn off telnet. Ultimately, they were hopeful because they were fast, but they really did not know if any of their clients were compromised.
4. Do you segregate your vendors?
As in, segregate them into controlled environments that are physically and logically isolated from other areas of the network. Is there a good reason for an elevator control system with remote access to be on the same network as a corporate database? Is there a good reason for an espresso maker with remote access to be on the same network as the corporate R&D servers? Segregate external and internal networks physically when you can, and logically when you must. Control access between networks with air gaps, firewalls, routers and all of the other devices and controls you would put between your internal network and the Internet.
I once visited a hospital that maintained two completely separate physical networks. One network provided visitor wireless support, and provided Internet access and public email access to hospital staff. All clinical systems and internal email (with different email addresses) was supported through a second physical network (which was further divided into multiple logical subnets). They had two completely different set of cables running around the building. Their internal systems did not even allow external email or Internet access. And it worked.
This is clearly the most difficult of the bunch, because, depending on what you need that vendor for, it may not be practical to truly segregate their access. But, if it is…
5. Do you monitor your vendors?
Yeah. This is pretty much “Do you spy on everything they do?” Be “big brother.” Be the NSA. Because you are ultimately responsible for what happens on your networks and in your environments, and despite any protests you simply do not have the same level of control over your vendors as you do over your own employees. Do not be afraid to crank up the logging so that you watch exactly when a vendor account is logged onto your environment, and exactly what they are doing.
In the example for number 3 above, not a single client of the customer service group from the disk management vendor could have told you when the vendor had even logged in last, or what any of those user IDs had done while they were on the client networks. For that matter, the vendor could not tell you how much anyone had accessed using those user IDs either.
These are not the only “vendor security” questions you should ask, but they are a good five with which to start. Number 1 is clearly the most important, and should drive all of your other decisions. If they don’t need it, they don’t get it.
And, for reference, from my first example, ABC Company violated every single one of these. So, the fact that they declared the breach as “substantial” should be no surprise. If you are interested, I can also tell you that “substantial” meant at least six zeros in the dollar cost of that particular breach.
