Software Can’t Fix Your Security Problems

October 27, 2014//Ellen Neveux

Last Updated: May 30, 2018

By Jeff Swearingen, Co-founder and CEO of SecureLink

If you gave me a $10,000 commercial-grade oven, could I make an awesome cake? Nope. Why would anyone think that buying software would accomplish what it promises in the demo?

In last week’s NY Times blog, Brad Maiorino told of removing his badge and surfing though the endless sea of vendors on the exhibit floor at RSA. If you don’t recognize the name of the guy with one of the toughest jobs on Earth, Brad is Target’s new CISO and an admitted glutton for punishment.

The analogy that comes to mind is baking a cake. Lots of ways to get there, but a professional baker and well-tested recipe are absolute requirements. You can have the oven, buy a $2,000 flour sifter and the digital whisk in Gartner’s magic quadrant, but if your chef and recipe suck, so will your cake.

Successful network security, or any other business function start with a solid understanding of the issues, business requirements, stakeholders, risks and technical components. Software helps you bring these things together; it doesn’t do it for you.

SecureLink may be the best software in the world for managing third-party vendor remote access. That alone means absolutely nothing. In a bake-off between our software (poorly deployed) and a good policy (well deployed), we’d lose every time.

The methodology I’d recommend follows the steps below. I am using (perhaps over-using) the cake analogy and examples of how a hospital manages remote access for vendors. If you’re not familiar with the vendor remote access problem, see the article I wrote in 2003 (yes, during the middle of George Bush’s first administration) on tech support’s dirty little secret.

Step 1 – What kind of cake do we need to make?

There’s no such thing as a network security cake. The world is too complex for that. Our specialty cake helps enterprise customers manage remote network access for third-party software vendors. A hospital, for example will have 100 or more third-party technology vendors that require remote access to their network. If you read the report on the Target breach (and also Goodwill, Jimmy John’s and Dairy Queen), you’ll learn that a compromised third-party vendor credential’s compromise was the attack vector used by the hackers.

It’s important to be mindful of the business requirements here. A hospital can’t just shut off vendor remote access; it has to be enabled in a way that supports the needs of the business and the vendors while maintaining the organization’s security standards.

Step 2 – How are we making it today?

Whether it’s BYOD, cloud security or third-party vendor remote access, there’s a chance you can’t answer this question very well. Having a solid understanding of current methodologies helps frame the issue and avoid buying even more software when you’ve already unsuccessfully deployed something else to accomplish the same objective.

Using a typical hospital as an example, a close examination would divide vendors into two primary groups:

Group 1 – those vendors that have a login on your VPN, and

Group 2 – those vendors that are sneaking into your network with WebEx or something like it.

Step 3 – Is the existing cake bad for us?

If you’ve already purchased some software or hired a consultant to help you solve an issue that still exists, there’s a good chance that the problem is internal, not technical. Buying more software is like buying a new exercise treadmill when the rowing machine you bought last January is collecting dust.

In the healthcare example, the problems boil down to security and accountability.

If you research the breaches at Target, Dairy Queen, Goodwill and Jimmy John’s, all resulted from a stolen credential granted to a third-party technology vendor. These credentials are dangerous because the logins get shared among multiple users and have elevated (admin) credentials. Said another way, you know when an employee leaves, so they can’t login and read email. When a support technician leaves the vendor, they still can login and copy your database. This example mostly applies to the “group 1” vendors that are accessing your systems via your VPN.

For the “group 2” vendors, the problem is more related to accountability. While WebEx and other desktop sharing services are excellent for supporting end-user desktops, they’re likely the wrong tool for supporting enterprise technology. Frequently, a technician will ask someone to click on a link, surrender control of the server, or their personal machine so they can deliver support. These ghost users are difficult, if not impossible to detect, let alone manage and audit. Someone rebooted the production EMR system in the middle of the day? Wasn’t us. Really.

Step 4 – Who is cooking and who is eating?

Networks are complicated, integrated and evolving. Heavy-handed edicts from a CISO are rarely effective when they don’t consider the needs of all stakeholders. At SecureLink, we’ve spent more than 11 years listening to the needs of software vendors and the customers they support. After uncovering the existing system (or lack thereof) in place at our example hospital, the right solution would include discussion with the application owners, network / security team, the compliance department and the vendors themselves.

Last step – What advice or equipment is needed?

No organization can be expected to have all the knowledge and tools necessary to bake every cake.

If you need help with a policy and process for third-party vendor remote access, SecureLink can help. You may not even need our software if you have an existing process and platform to authenticate, restrict, manage and audit activity from the vendors that support your operations.

The next time you’re salivating over a delicious demo and the sweet promises of an eager software sales rep, make sure you have a recipe for success before issuing the purchase order.

Watch these videos to discover how you can have your cake, and eat it.

Subscribe to the SecureLink Blog.
close close