What are the security threats in a wireless environment that don’t exist in a wired environment?
Mark Tauschek, senior research analyst, Info-Tech Research: The data is flying through the air and anybody with the right tools, of which there are many, can intercept it. If it’s not encrypted or if the encryption is weak, such as with WEP, an intruder can see everything flying though the air. I’ve actually intercepted people’s e-mail and read it back to them, so it’s pretty dangerous. But there are ways to mitigate that that are to date unbreakable.
Mike Richard, senior project manager for IT infrastructure, City of Fredericton: You get what’s called the evil twin scenario. There’s where someone can set up another wireless router with the same signature as yours and make up a little Web page that looks like the one the person is going to. Typically that is done on networks you pay for. On our network that’s not a huge threat because don’t pay to use it. The second one could be somebody more easily snooping around trying to figuring what you’re doing. Say you’re at a coffee shop and they know what they’re doing and you don’t, they might be able to connect to your laptop. Then everything wired has (in terms of security issues), wireless has as well.
What are the most important elements of a security policy?
Paul Miller, managing director mobile security, Symantec: The biggest thing is you have to consider all of the end points and treat them equally. At a minimum you need AV and firewall, especially as these data phones begin to connect over wireless LANs, because they can be attacked over an unprotected network. Most operators are good about managing the pipes to some degree, so they try to filter out the spam or malware, but when the phone goes to a Bluetooth or wireless connection, it’s really up to the end point to protect itself. The other big thing is loss. People don’t typically lose laptops. Because these phones are typically linked to the e-mail system they contain an amazing amount of data and you need some sort of a loss mitigation strategy. Not only do you need to secure the end point, but you might need device level encryption. We’ve added an audit log that lets the IT department see what calls were made on or to the device after it was lost. So, for example, say you lost your phone last night at nine, you wake up the next morning and do the pocket pat, you don’t locate it, so you call the IT department. They’ll connect to the device, grab this audit log and execute a remote wipe and kill. The audit log shows what data occurred on the device in the last 48 hours or whatever.
Tauschek: There are lots. I think whatever policy you put in place for wireless security in the enterprise has to be enforceable. You can’t just rely on people to do the right thing, because whether deliberately or inadvertently, they won’t, so the first thing is the policy has to dictate that all users of wireless infrastructure within the enterprise must be authenticated and must use strong encryption, which in the case of a wireless LAN would be AES encryption, which is the gold standard. TKIP (temporal key initiation protocol) can be used — it hasn’t been broken yet — but it’s still based on a flawed encryption algorithm. TKIP is the fix for WEP. WEP can be fairly easily cracked so they came out with WEP 2, which was actually much better, it doesn’t give out weak initialization factors, but it still has a stigma attached to it. Aside from that, there are rules about how you use wireless infrastructure anywhere and to a certain extent where you use it, so you say if you’re going to take the enterprise laptop we own, you’re going to connect at a hotspot and you’re going to be completely vulnerable, you need to have rules. There are tools that allow you to enforce this.
Richard: You’d have a security policy that would include a lot of different things, like a personal firewall must be activated and it must be patched to the current level, both on the antivirus and on the firewall. That’s the main one, and you’d usually manage that through a security appliance. It’s very important that you protect your remote users without them even knowing it.
What are some strategies for dealing with rogue access points?
Miller: One of the things about a rogue access point is it allows someone to connect and listen in on an unmanaged channel. In the mobile space you have something similar called snoopware. Because the device is always with you, it always needs to be managed. What Snoopware does is it remotely activates the microphone on the device; it basically puts a listening device on your hip. Nobody would want to listen to my life 24×7 because it’s pretty boring, but if you were able to consult my calendar, which is also on the device, and able to laser in on some of the more interesting meetings I might be going to, what a great opportunity to glean information. If you inspect a CxO device and you could get into some of those meetings, like a CFO earnings call or a CEO’s acquisition strategy, you begin to not only glean the information, but you really invade a person’s privacy and destroy their integrity, because everything you seem to say to that person gets out in public. The mechanics of the attack against these data phone devices are roughly the same as attacks against PCs, but because they’re always with you, it represents a new opportunity for the bad guys, and I’m not sure everyone’s aware of that yet.
John Masotta, senior product marketing manager, access and consumer solutions, RSA, the security division of EMC: The first strategy is a corporate policy-making sure everyone in the organization knows what the policy is against installing your own wireless LAN devices. The second is a strategy to detect those devices and there are tools that IT organizations can use that are sort of like minesweepers – you can walk around the building with a wand device and it will detect anywhere there is a wireless access point.
Are there special considerations for mobile users in terms of accessing the corporate network?
Miller: The first security for any device that goes outside the protected walls of the company is you need good authentication, you need a good login. But especially with mobile phones, you don’t want to make it so onerous people are rear-ending each other on the freeway. The other thing you want to do is create a tunnel between the device and the backend data. A lot of e-mail push systems will encrypt the data in a tunnel. With some of them, if you take an attachment and save it outside the e-mail environment, it becomes unencrypted.
Richard: You need to have the most up-to-date personal firewall software running on laptops and you need to have up-to-date antivirus. You need a secure, authenticated way to connect to your network, usually through a virtual private network. Typically with BlackBerries, organizations use the BlackBerry enterprise server, and that takes care of everything for you.
Masotta: The users have to have a properly configured access card to work with the legitimate access devices and this is the point where we believe strong authentication should be implemented. The encryption keys and the systems themselves can show (a user) belongs on the wireless access point by the encryption key, but anybody could have that laptop. It doesn’t necessarily authenticate who the user is. So we believe for mobile users a strong authentication technology is advisable. The 802.1x networking environment accommodates extended authentication protocols … and what that allows you to do is require the end user to authenticate themselves.
What precautions should you take if you allow visitors unencrypted courtesy access?
Miller: From a data phone perspective you have to assume you’re all guests on the operator’s network. That’s why the VPN, the AV and firewall are important. One of the interesting things to think about on mobile devices is the way malware and viruses spread, which is typically through the Bluetooth channel because it’s typically the one that is always available. It’s a biological spread like the common cold, so if you’re walking down the street and you don’t have the Bluetooth on your phone configured to only accept paired requests versus broadcast, the phone that’s walking by you will recognize that and ping you and try to deliver its bad payload. Most people don’t think about the threat from a phone so they click no the first time, but if it’s persistent, they click yes. You have to remember these devices are constantly getting bombarded with “visitors,” so you have to make sure the settings are appropriate.Tauschek: The challenge is how to do that securely. The truth is nobody has come up with a really simple way to do that, so they authenticate the user … they say you need to put some authentication credentials in, such as a user password generated by IT or reception, and that’s secure because it’s an SSL-encrypted Web page, but beyond that it’s unencrypted and unsecured. So obviously what enterprises have to do is just direct that traffic out the firewall to the Internet so it’s completely segmented from the internal network and there’s no way to get to it. But the other challenge is that now all of this traffic is unencrypted and there could potentially be some information travelling over that connection, so there are a couple of options. You can mandate that guests or contractors or whoever use a VPN connection of their own. The other way to do it, and probably a better way because you can enforce it, is to say we’re going to authenticate you on an SSL VPN. And we’re going to only allow you access to a very limited set of applications, so likely you can have access to a browser and that’s it, or to a browser and maybe we’ll allow you VPN access to your own corporate network. The only way to enforce it is to allow traffic over Port 500 or Port 1723, or Port 443, so you could say you only have access to these ports and they won’t be able to do anything unless they initiate a VPN session.
Richard: What we recommend and what we do is we don’t allow access to our network. What you do is build a separate network. Put routers on separate switches with a separate structure and then let them deal with their own security issues. I would never have them authenticate on my own corporate network.
