Febuary 2015 IT Business Consulting Newsletter

Who Is Talking To Your Systems… and Who Are Your Systems Talking To???

By Tom K

These well funded companies were sure their environments were locked down. One got hacked through their HVAC system, another through a soda vending machine, and another via a lifted vendor's account that had admin level access.

All those "smart" devices connected to your network that "call home" present potential security holes. Many companies don't even know this access to their networks exists. Do you track all the high level accounts you've provided to your vendors and limit their access to your systems?

In this month's newsletter, I review these threats and discuss Best Practices to protect your environment.


Vendor Access

Every company has vendors that require access to their systems. Many of these vendors require Admin level access, and many require remote access. When you give a vendor either, it presents a potential security risk. While you may have to provide this access for the vendor to deliver their services, there are methods to mitigate the dangers.

Provide the minimum level of access required. If a vendor requests Admin access, make sure they really need Admin access.

Ensure the password used for the vendor account is a secure password, and the password is unique for your environment (make sure the vendor doesn't use the same password for multiple client accounts).

If a vendor accesses your networks remotely, ensure they connect using a VPN (Virtual Private Network) or via a known IP address that is granted access via your firewall. (See "Virtual Private Networks (VPNs) – a key Business Enabler" for a VPN primer).

Disable all vendor accounts in Active Directory. When a vendor requires access, it is a simple matter to enable the account while they are working in your network, and disable it when they are done. Do the same with external access through your Firewall and/or your VPNs.

Keep track of (document!) all vendor accounts, the level of access provided, if the vendor has been granted remote access, and how they are allowed into your networks.

Pay attention to your vendor contracts. Many contracts will include clauses with specific requirements that the vendor be granted admin level access to your systems, as well as full remote access. If you see such a clause, review the business case for the access, and ensure you have the right to enable and disable their access as needed.


Vendor Managed Devices

Most companies utilize devices that are integrated into their networks and are managed by, or communicate with, vendors. Typical examples are phone and voice mail servers, high end multi-function printers, video monitoring systems, and postage machines. These devices are integrated into the business network (via wired or wireless connections) and the vendors can either remote into them or the devices can communicate directly with the vendors via the Internet.

We can't isolate these devices from the business network, since they provide business services on the network. We can, however, reduce or eliminate access to/from the outside world.

The first step is to discover which vendor managed network devices your vendors can remotely access. Does each vendor really need remote access to each device and, if so, does the vendor require immediate "anytime" access to each device? Examine the business case for access to each device and provide access on a case by case basis. As noted above with general vendor remote access, you should be able to easily enable remote access to a specific device (or for a specific vendor) when needed, and disable access when they are done.

Be wary of any network device on which a vendor has installed a remote access application, as these apps provide full access to the device with you having NO control whatsoever. See "Hacked via Remote Access!" for more info concerning the danger of these apps.

The next step is to discover the vendor managed devices on your network that initiate communications to the outside world... those that "call home". Is the communication one way (the printer only sends stats), or does the contact initiate a bi-directional session (invites a tech into your network to access the device)? Again, you need to examine the business case for each device on a case by case basis. If you determine that you don't want the device initiating outside communication, the typical solution is to have the vendor shut down this functionality within the device. If necessary, you can block all external communication from this device at your Firewall.

As with vendor contracts, review the licensing agreements associated with these devices. Many of these agreements provide the vendor with the right to communicate with their device... If you power up their device, you must provide it with a path to the Internet. If there is no business case for this access, have the clause removed.


Smart Devices

These are the most troublesome security concerns... the devices that sneak in under the radar. These include the vending machine and the HVAC system mentioned in the intro. They are not providing business network services, so YOU don't need or want them on your business network. But they are installed into your network by the vendor, for the convenience of the vendor, often without your knowledge. You need to prevent this!

How do you know if any rogue devices are attached to your business network? The simplest way is to look for Ethernet cables attached to what should be non-network devices. Another is to review your DHCP (dynamic IP addressing) tables for unknown/unauthorized devices.

Most of the Smart devices I've seen have wireless capability, and this is often their preferred connection method. If you provide wireless access to your business network, do NOT give the business WiFi security code to a vendor unless they have a very specific need for it (that business case again). As an aside, if you do provide wireless access to your business network, you may want to re-consider this HUGE security concern. See "Provide Wireless Access to Business Systems???" which highlights my concerns.

Again, make sure you review the paperwork you sign when you order that new AC or when they deliver that soda machine. It may require you to provide the device with Internet access if you sign blindly.

In most of my client's environments, we provide public WiFi access to the Internet that is completely isolated from the business network. I usually set the public WiFi up on a dedicated Internet circuit so this traffic can't impact business Internet use. This is an excellent mechanism to provide non-business network devices with Internet access. See "Securely Implement Public WiFi, version 2015" for details.


Security Policy

Your company should have a published Security Policy in place. If you take credit cards and need to be PCI-DSS compliant, a Security Policy can be a requirement. Every employee should annually sign a statement that they have read, and understand, and agree to comply with all facets of the Company Security Policy.

Any vendor that has admin level access, has remote access to your systems, remote access to their systems on your business network, or has a device that communicates outside your network should be required to annually sign your Company Security Policy as well. This will ensure they are aware of, and comply with, your security requirements. Additionally, if you have a security breach caused by a vendor or vendor provided device, and the breach was due in part or in full to a violation of your Company Security Policy, your company's liability in the results of the breach can be greatly reduced.

I'll discuss Security Policies in greater detail in a near-future newsletter.


If you have any questions about any of the info in this article, or if there is anything I can do to help you improve your company's security position, please don’t hesitate to contact me at TomK@TomKConsulting.com, or via my cell 443.310.5110.


Next month I’ll revisit Securely Implementing Public WiFi in your environment, updated for 2015.