So is it time to kill IE? France and Germany think so. Me, I’m not so sure. The latest versions are solid, support most of the key Internet standards and run in limited user mode, with minimal access to the core OS and the file system.
I do agree with them on one thing, though. There’s really no excuse for still running IE6. After all, IE 7 has been out for nearly 40 months, and IE 8 for most of a year. That’s more than long enough for your developers or your software vendors to have updated the code of any intranet applications. You don’t have to have updated the underlying OS, either, as both run happily on Windows XP as well as Vista. If you’re relying on ActiveX controls for performance and security, then Silverlight gives you all the features (and browser integration) that you want, with the added benefit of a .NET sandbox and a modern JIT compiler for added speed.
One view of the IE 6 problem comes from the Adobe folk we overheard on a bus during the MAX conference. The problem with enterprises who haven’t yet moved off IE 6, they said to each other as they compared notes on customers they’d come across, isn’t the IE 6 front end; it’s that if you’re still on IE 6 now for a line of business app, it’s because you wrote it before you understood Web database programming properly and you have a badly written back end with millions of rows of badly stored but crucial data in that you don’t know how to get out. That means you’re dependant not on IE 6 but on the connectors you wrote between your IE 6 front end and your bodge-tape-and-string backend – and you can’t really blame Microsoft for that.
So should you consider removing IE 7 and IE 8 from your network, then? Not really. They’ve benefitted from Microsoft’s security reset and the resulting development of a well thought out security development lifecycle and the tools needed to support the development of secure code. But no browser developer can cover all the bases, and you really should be thinking about how you manage your perimeter and how you handle contextual security.
Network access policies are now relatively easy to implement and deploy. Untrusted PCs and laptops should be quarantined as soon as they touch a network, and held in a separate VLAN until they’ve been tested to ensure they meet and match your current security policies. Group policies that require the use of anti-malware software need to be mandatory (and if budget is a problem, the free Microsoft Security Essentials is at heart the enterprise Forefront AV product, without the central management tools). Tools like Windows Update Services will push security updates to hardware, and can be configured to automatically update machines as soon as they connect to a quarantine VLAN. You’ll also need to push updates for common pieces of software, like Acrobat Reader and Flash, that have become a backdoor route in to PCs and networks for malware authors.
That’s only part of the story. Most common malware comes into networks through well-known channels, in email and in the web. Good perimeter security tools can ensure that most of that, blocking known malware vector sites and spam sources. It’s a good idea to sign up to one of the many real time block lists, especially services like SpamHaus, which track not just the IP addresses of spam servers, but also monitor the always fluctuating addresses used by active botnets. They won’t protect you from everything, but they will keep out most of the threats. You can use a perimeter security appliance to run the blocks – or just fill in the details in Exchange. It’s surprisingly easy to use Exchange’s anti-spam tools, and they’re also surprisingly powerful.
There are other simple techniques that can be used, for example blocking all mail that is sent to a secondary MX while the primary is in action. It turns out that this is a well-known spammer technique to try and get mail to appear to be coming from a trusted source. Web filtering on known malware sources works well too – and both Microsoft and Google have lists of sites that carry malware, as do appliance vendors like Barracuda. Upgrading to a recent version of Office can also have an effect, as newer versions of Outlook don’t use the Internet Explorer HTML engine and are less likely to randomly run scripts that download malware or connect PCs to insecure sites and services.
Of course you’re unlikely to catch everything, so having a mitigation and detection strategy is also important. Tripwire tools can catch modified files and data, and data loss prevention tools can control what leaves your network (as can using mandatory encryption). There’s also scope for using network monitoring tools to detect and block unusual traffic – after all, it’s easier to unblock a new application than inform your shareholders of data loss…
Hardening your client machines is also important. You don’t know what networks a laptop will be connecting to, so make sure that all machines that leave your network are both up to date and are running effective local firewalls and security tools. The built in tools in Windows (at least from XP SP2 onwards) are good enough for most day-to-day use, but third party tools can give you an extra edge.
Trust is key to effective security. Tools like Windows 7’s AppLocker control which applications can run on a managed PC. If you only allow tested and trusted code to run on your PCs, then you’re likely to prevent random malware from infecting your network. It’s like vaccination, protecting one PC reduces the risk of the rest of the network being infected. Protect them all, and you’re significantly reducing your risk of exposure.
Get rid of IE? No. Just run a secure network, with up to date tools and technologies, and you’re likely to be safe from most attacks. Just be sure who you trust, and how well you trust them. A trusted partner or PC is more likely to be an attack vector than a random web page. The less you trust a PC, the less access it should have – and the same rules need to apply to business-to-business connections and VPNs. They may be trusted connections, but you don’t know what’s using them…