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.

Throughout my career, I have worked for organizations that have purchased and integrated 4 companies.  The acquired companies ranged from an organization with revenues of less than $3 million per year to a publicly traded company with annualized revenues of almost $1 billion.  While the acquisitions all carried their own set of challenges, they remain among the highlights of my career.

When I pictured corporate acquisitions, I always envisioned purchasing the next big startup or buying out your leading competitor.  I didn’t realize that a majority of corporate acquisitions are an attempt to leverage existing infrastructure and shared services to turn a failing company into a profitable organization.  When I was informed that my company was about to purchase another organization, I instantly realized I was going to be working with a lot of old hardware, disgruntled employees and vulnerable systems.  Fortunately, I was able to leverage HoneyPoint to address several the aforementioned challenges.

Completing an acquisition can be overwhelming at times.  It’s important to take a step back and look at systems from a bird’s-eye view.  I always found it extremely helpful to deploy HoneyPoint Agent at the start of an acquisition.  I worked diligently to create an Agent deployment that mimicked the infrastructure of the acquired company.  This allowed me to have a centralized view of their network from one HoneyPoint console.  On more than one occasion, HoneyPoint Agent helped me to identify infected machines on the network of a recently acquired company.

Having worked for a company that has been acquired on two separate occasions, I always empathize with the employees of an acquired organization.  While it can be a scary time, it can also be looked at as an opportunity to demonstrate your talent to a new company.  I have met several talented IT Professionals throughout the 4 acquisitions that I have had the privilege of completing.  I was frequently amazed at their ability keep a critical infrastructure running on a nonexistent budget.  Unfortunately, for every talented and cooperative professional, I have encountered a few disgruntled employees.

HoneyPoint has several great features that can help identify a disgruntled employee.  For example, I was able to place documents throughout our network that would log an alert to my HoneyPoint console each time they were opened.  This would have allowed me to easily identify any disgruntled employee that was searching a file server for confidential information.  Deploying these trojanized documents throughout our network taught me a valuable lesson about HoneyPoint…it should be considered a good thing when a deployment does not generate any alerts.  In this instance, it meant that I did not identify any employees that were digging through our file shares for confidential information.

Unfortunately, I have been a part of acquisitions where the IT staff of the acquired organization were not retained.  While it was purely a business decision, the layoffs posed a serious risk of creating disgruntled employees.  This could lead an employee of the acquired company to attempt to cause harm to systems owned and operated by the acquiring organization.  During each acquisition, I deployed HoneyPoint Agents that mimicked the Infrastructure of my company.  This allowed me to identify any instance of an individual attempting to scan systems that were owned by the parent organization.  While I did not catch any individuals in the act, I was able to rest assured knowing that I had the capability to do so.

I highly recommend leveraging HoneyPoint during your next M&A.  It will help you address several of the challenges that are associated with the M&A process.  If you have any questions about HoneyPoint and how it can help your organization, please contact us at info <at> microsolved.com.