Pratum Blog

I don't like VPNs. I take that back. I like them a lot, I just don't trust them. Ever had a friend like that? They're fun to be around, are really helpful, always there when you need them, etc. For the most part you're great friends, but…they can't keep their mouth shut. You always have to watch what you say around them because you know it will be repeated. Probably multiple times to multiple parties. That's the view I have of VPNs.

I've been using some sort of VPN for probably a little more than a decade now. Not just remote access but truly secured communication channels. The goal of a VPN was to make location irrelevant in the computing equation. We've done that. You can login to an application or system remotely from just about any device with a processor and operating system, including mobile phones and PDAs.

We've gotten more secure in how we transport the data but for the most part continue to ignore the endpoint. This is my concern.

I've worked with several organizations which have implemented VPNs either in IPSec or SSL form. They go to great lengths to secure the communication channel but completely ignore the endpoint on the remote end. They rely on things like internet history scrubbers to "erase" the sensitive data from the remote machine. Who are they kidding?

There all sorts of rudimentary ways to defeat this. The easiest is to mirror a read only copy of an OS to a removable drive. Presto…scrubber defeated. Another is an application that places a hook into your video driver and captures screen prints every 10, 15 or 20 seconds then stores it to a file. Combine this with a keystroke logger and you have a pretty easy yet effective way to defeat a history scrubber.

The point is, when you lose control of any part of your communication system, you lose control of your data. I routinely recommend organizations restrict access to their VPN from only devices which they control. This ensures there are other protections, such as malware detection and firewalls, in place which help limit exposure on these devices.

The biggest complaint I hear when I recommend this solution is the cost of providing laptops or mobile devices to employees who will work remotely. I think this argument is very short sighted and usually the entire risk environment is not being evaluated. My suggestion in these cases is to consider the risk of data leakage or security and privacy attacks from VPN usage and then recalculate the ROI. Typically this changes the discussion points. Sometimes even re-evaluating who actually needs remote access can reduce the risk and costs simultaneously.

If nothing else, organizations must understand that once data leaves a system which is completely within their control, they lose control of that data. If this risk has been evaluated and either accepted or mitigated then by all means forge ahead. My concern is with the organizations which haven't considered this risk and therefore have a false sense of security. Anytime risk is unknown, hidden or ignored, catastrophe will be lurking in the shadows.

In my travels as an engineer, executive and now consultant I've seen many organizations of various sizes in a plethora of vertical markets. They all share one common element. Chaos.

In the smaller organizations the chaos is in the big picture. They typically don't know where to begin in developing or managing an information security program. They do little bits here and there but nothing is centralized and rarely does it tie back into business objectives. Audits in these environments typically uncover multiple gaps in risk assessments, documentation and IT controls.

For the larger organizations the chaos is in the details. They've got a great framework for how the security program is supposed to be implemented however it so complex it rarely works. The process and procedures work well for one business unit but may not scale well to the rest of the organization. This usually results in audits uncovering entire units and divisions which aren't following established process because it would kill their business.

Developing an enterprise wide security program is difficult. Trying to find something that works well for and is accepted by everyone isn't for the faint of heart. I know because I've done it at several organizations. My best advice to someone trying to tackle this is to consider picking one of the established frameworks and use it as a model for your program. Notice I said model. These may not fit your organization exactly and need modification or simplification. Unless you're trying to gain ISO certification you can pick and choose what portions of the standard apply to you.

Do some research to see if one of the common frameworks such as ISO 27001, COBIT, NIST or ITIL is commonly accepted in your industry. This will make it easier to find organizations with a similar structure in order to learn from their success or mistakes in adopting a similar program. You might also find it easier to use the same lingo in describing your program to an external auditor or finding new employees in your sector with experience in one program versus another.

Take it slow though. Don't tell yourself you're going to implement ISO 27001 this year. Approach it as a migration. You're going to migrate from complete and utter chaos, to structured chaos, to slight disorganization and finally in about 3-5 years reach a level of maturing that others drool over. Pick part of the framework to implement your first year. Find something that won't be too politically charged for the organization and will allow you a quick win. This will help build momentum and trust in the program which in turn leads to stakeholder buy-in and eventually funding. Starting off too strong is likely to doom your initiative before it ever has a chance to prove its worth.

There is no perfect one size fits all model for implementing a security management program. The models and standards based frameworks each have their own faults. They do however have exponentially more benefits than trying to develop something on your own.

Is anyone going through a current implementation? Which model or framework are you using and why? I'd love to hear what's working well or if there have been struggles. Please share your experiences.

I presented a session at the Nebraska Cert Conference yesterday about working with IT auditors. It was quite funny to watch the facial expressions of people in the room as the session progressed. At the beginning I asked for a show of hands to see if any IT auditors where present. About half a dozen in the crowd of around 30 raised their hand.

The basic premise of my presentation was that IT management needs to be more involved in the IT audit process. As the session progressed I saw lots of smiles and head nods from the auditors. The rest of the group nodded their heads in agreement, but it wasn't the same. It almost looked like a football team that was defeated before they even hit the field. They knew they needed to play the game but had resigned themselves to the inevitable outcome before the first snap.

This tells me something about our current climate. As the frequency and depth of IT audits are increasing due to the ever changing regulatory environment, tensions are running a little high. IT groups know they are under the gun. With every new regulation comes more work and an eventual audit. This can be quite a pressure cooker to operate in on a daily basis.

I place responsibility squarely on IT management to change this culture. My company's name is Integrity. In essence it's about doing the right thing even when nobody's looking. IT managers need to change the culture in their organizations. Not that anyone is doing a bad job but sometimes we let things slide when nobody's looking over our shoulder. Log analysis or documentation get put aside when you've got network outages or development bugs to fix. Then when an audit is announced the tension runs high because everyone knows there are some things that were shelved and never picked back up.

IT management needs to do a better job of making sure their teams are provided ample opportunity to do the job correctly and completely. They should even go so far as to require it. Make it a part of performance reviews if needed. When management takes the details seriously, so will their teams.

My guess is that once we start to sweat the details in IT, audits won't be so stressful. And when audits are so stressful, we might actually begin to appreciate what they tell us about our organizations.

Get our blog posts delivered to your inbox:

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.