Of all the product claims made by software vendors, perhaps no claim is so consistently overblown as that of security. Especially when one stops to consider that not a single product out of thousands of security products does anything by itself to ensure security.

But wait, you say, Bomgar is not a security product per se but we do make a lot of claims about our product’s security and how it’s superior to our competitors.

So what do I mean?

Just this: that there is a great deal of difference between facilitating security and creating security. And products can’t create security. They can, at best, facilitate it. It’s up to people to do the securing.

Let me explain: Think about a security measure as simple as a lock. At first glance, this little invention would seem to epitomize security, but it doesn’t. There are actually many different considerations in the usability of the lock that either facilitate or impede security.

Design of the door and frame
I lived in a former soviet bloc country for a couple of months two years ago. The doors had huge locks that made a satisfying “cha-chunk” whenever you locked them. What’s more, though, the door was built together with the frame so that the steel door was integrated with the steel lock which was integrated with the steel frame, which was built securely into the wall. You would need a jackhammer to get these doors open, not just a swift kick. Our doors in the States usually deadbolt into a flimsy wooden door frame; the lock may be strong, but it’s leaning on something weak.

The Locking Mechanism
Some locks can be opened by anyone from the inside whereas some require a key:

The latch type is convenient, but if you combine it with an exterior door with glass panes, then all someone has to do is break the glass, reach in and flip the latch to gain entry. But before you scoff at all those non-private-key morons, consider who’s going to be using the lock. If you have kids in the house, then “security” may be more broadly defined. If there’s a fire, you don’t want your seven year old to have to find the key before getting out of the house.

Safeguards
Some doors automatically lock when you close the door behind you. Most hotel rooms function like this for obvious reasons. They don’t want people to forget to lock the door, so they make it impossible to forget. On the flip side, some vehicle locks require you to have the keys in your hand before you can lock the door. In other words, they make it impossible for you to lock yourself out of your car.

It should be clear in these examples that no lock or lock configuration actually creates security. All they do is create the conditions in which security can be achieved. Software products are the same way. They create conditions in which security can be achieved, and the best security products make the conditions such that security is easier to achieve than non-security. Seat belts, rearview mirrors, backup cameras, blind spot sensors, airbags, anti-lock breaks, crumple zones, and dozens of other innovations have helped create conditions for safe driving. However, a “safe” car driven off a cliff is not safe.

The remote support market is no different. Remote support is consistently found to be one of the top attack pathways used in data breaches, and it’s usually the older school point-to-point remote control technologies to blame. To counter this, we’ve tried to build our product to create the conditions in which remote support can be secured (as Joel Bomgar mentioned in a recent post). Specifically:

              Architecture
The Bomgar appliance is deployed within your own network. Data is routed and stored centrally over standard ports, making auditing easier. And keeping the appliance in-house prevents third party tampering, limiting your organization’s circle of liability. This architecture also enables secure support of end users both over the internet and within secure closed networks (e.g. DoD SIPRNet).

Authentication
Bomgar integrates with your existing identity management and authentication tools (LDAP, Active Directory, RADIUS, Kerberos, etc.), allowing users to login using secure directory credentials or using smart cards (CAC, etc.). Bomgar administrators can apply permissions and password policies on the group or individual level. This makes logging in in a non-secure way harder.

Access Controls
Support rep permissions can be assigned granularly, enabling administrators to give reps only the privileges they need and no more. And when greater permissions are needed for a particular remote support session, they can be given on a one-off basis by higher-tier reps or administrators. These permissions can be applied to external vendors too. Furthermore, during a Bomgar session, end users have control over the rep’s level of access down to each application viewed and action performed.

Audit
Bomgar keeps detailed logs of session activity, chat transcripts, transferred files and system information, plus video recordings of each session. In addition, Bomgar can track and log administrative activity, enabling multiple levels of managerial oversight.

It’s not perfect, but Bomgar provides a good framework for securing remote support. We make it easy to do things that are secure, and we make it hard to do things that are not secure. And that’s what all good security products are designed to do.

In contrast, if you look at a lot of the older remote control products, they make it difficult to be secure. For instance:

Architecture
A lot of older products are point to point. With nothing in the middle to manage how access is accomplished, it’s hard to keep these products in line. Also, since point-to-point products don’t work through firewalls by default, this architecture encourages administrators to port forward through their firewall and create listening ports that are accessible via the internet. One recent study found that there are over 100,000 systems running PC Anywhere that are exposed in this way.

Authentication
With a lot of the old products, authentication is handled at the client level, meaning that the support rep is logging in with a local password versus a domain password. This encourages the use of shared passwords. Also, many software as a service (SaaS) remote support products don’t integrate with internal directories and offer named-seat licensing (where each license has to be tied to a single person’s name/account), increasing the motivation to create “tech1, tech2” type user names that undermine auditing.

Access Controls
With most of the legacy products, once you’re in, you’re in. They have binary access. Either you have full access to everything on the end system or you don’t have access at all. This is like giving your teenager the keys to a Maserati and telling them to not break any speed limits.

Audit
With many of the old products, audit is non-existent. With nothing in the middle of a point-to-point connection, remote control sessions slip away in the night (or day) without any record that they ever took place. This is very convenient for hackers.

No product (not even the “security” products) can create security, but fortunately, you can do a lot in software to facilitate security. You’re still going to have incidents of people driving “safe” software products off a cliff, but with the right controls, we can make it a lot harder.

By Nathan McNeill