All modern information infrastructure tends to be an amalgam of stuff you built, other people’s stuff you know you use, and hidden stuff that you are unwittingly dependent on ( yours or someone else’s).

This blog entry is about part of that middle ground – on-premise services that you pay for and are integral to your operation but are in fact built and managed by a third party with whom you have a contractual relationship.

It’s based on my actual experience of late.

Here’s the nut: Any vendor who has a presence within your infrastructure that they manage may have connectivity into that infrastructure that you are unaware of.

The vendor’s infrastructure and yours may effectively be one thing.

The example:

The company knew that the vendor had used the provided contractor VPN access at one time.  They had used it to set up their equipment initially.  What they did not know was that part of that set-up routinely involved the establishment of outbound site-to-site VPN tunnels from the vendor’s equipment to the vendor’s datacenter.  Those connections were built at boot time and maintained.  Vendor staff used that VPN access to get to their equipment and, if needed, from their equipment to the company equipment that they provided services for.  There was no company-accessible audit trail.  No log.

Under these conditions, the vendor and the company infrastructure are effectively one.  A compromise of the vendor is a compromise of the company.

What to do?

• doveryai no proveryai:   It’s an old saw at this point, but always true.   “Trust, but verify”.  That trust may not just be of the vendor.  It may be of your own upper management who engineered the deal.  That can be a tough,  particularly if you are calling into question arrangements that have already been made.   But you didn’t choose this career because it was easy.   Read the doc, ask the questions, get the answers in writing.
• Egress Filtering: You should control what traffic leaves your enterprise. Strict egress filtering rules would have denied that outbound VPN connection described above.  A daily report of such denies would alert staff to the attempt – and start the necessary round of questions.
• Monitor your outbound traffic:  Know what’s normal.  You should be generating daily reports from your network logs and from all other intermediary devices (e.g. proxies) about outbound communication sessions – particularly ones of long duration and consistent external IP address targets.  Know what radiates out!
• Watch your VPN logs:  The vendor stopped using company VPN once it was no longer needed.  VPN access logs would have recorded that cessation. That was an anomaly that should have been called out.  The implication is the company VPN logs were not being analyzed and reported on.  You need to know what normal traffic is for your front door.

Finally: There was nothing intentionally malicious about the vendor’s actions in the example cited.  The vendor techs were just doing their job.

It’s your job to question theirs.