I don't like surprises. I wish projects wouldn't get launched without the sponsors seeking my advice on security measures first. If you read this column regularly, you've heard me say all of this before. I try to keep an eye on everything, but companies are complex organizations, and it's inevitable that something will sneak by.
A case in point: A couple of weeks ago, I noticed that a lot of people were using Apple iPads in our conference rooms. We haven't bought any iPads. I wanted to know whether they were being used on our internal network. Oh, yes, the users assured me; it was no problem. Well, I thought, it should be a problem; it should be impossible, in fact.
To remedy this situation, I needed to find out why it was so easy for users to attach personal devices to our network and how that came to pass. I started digging.
What I learned was that the seeds of the problem were planted last year, when we were deciding how phones would synchronize with Microsoft ActiveSync. We realized that users would have faster syncs through our company's guest wireless network rather than a phone's 3G network. All well and good; after all, our guest wireless access can't be used to access our internal network.
In the course of testing this configuration, the network team discovered a serious glitch. On occasion, when they lost the connection to the wireless access points, some phones didn't switch back to their 3G networks. Users wouldn't notice that they were unconnected until the lack of e-mail on their phones became obvious.
To get around that, a couple of network administrators worked with the Windows Server team to issue certificates to users that were tied to Active Directory. With certificates, by creating a new service set identifier, users could connect to the guest access point without even entering a password. If a phone lost its wireless connection, it could reconnect seamlessly using the certificate for authentication. Pretty cool, right? For the users, yes, but not for me.
Such certificates can be exportable or nonexportable. Nonexportable would be my choice, because exportable certificates can be used multiple times. But I wasn't asked, and because of complexities and costs, exportable certificates were created.
We have another set of access points designed to give company-owned laptops access to our internal network. These connections are also done through a captive portal, but instead of a password, employees must use their SecureID tokens. But word got out that certificates were available for wireless authentication, and unknown to me, the internal access points were reconfigured to allow certificates for authentication.
That may have been OK for company-owned devices, but with exportable certificates, any user with a certificate could link it to an unlimited number of devices. As a result, employees were attaching unauthorized iPads, personal laptops and other rogue devices to our network.
I can't vouch for the integrity of any device that a user brings in. In many cases, these are machines that an employee's kids have used to play games, chat on Facebook and download who knows what. Since they aren't corporate resources, we have no control over what software, antivirus protection or security patches are installed. And then there are legal issues to consider, since we can't control a personal asset.
So now I have a new task at hand that will more than likely cause me a lot of grief: to pull back the current certificates, re-architect and reissue nonexportable certificates, and restrict them to the guest wireless access.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.