Default assumption: Browsers are insecure. If we had a dollar for every flaw we've seen exploited--repeatedly--that let malware overrun our networks, we might have enough to cover cleanup efforts. Last year, 51 exploits targeted poorly designed ActiveX controls alone, according to Symantec. That's up from just 15 in 2005. Yes, ActiveX is off in Internet Explorer 7 by default, but if your end users need Adobe Reader or Flash functionality, you're back in the line of fire.
And users want every scrap of functionality. Information workers have made Web browsers the workhorse for knowledge exchange. Gartner estimates that demand for software as a service will grow more than 20 percent every year through 2010, and in our own recent SOA/Web services reader poll, nearly 80 percent of respondents said their enterprises currently use Web services--yet fewer than half secure both internal- and external-facing services (for more on SaaS, see our cover story).
Can IT resolve this dichotomy?
As with liberty, the price of Web browser security is eternal vigilance ... and a risk-management strategy, and attention to advances in security capabilities, and end user education, and strong centralized management.
Fortunately, vendors are stepping up, both collectively and individually. The Anti-Phishing Working Group (APWG), for example, unites more than 100 vendors--it's heartening to see the normally competitive software sector put aside differences and operate in an open and constructive way to address the alarming criminalization of cyberspace. We're also cautiously encouraged by EV (Extended Validation) Certificates that confirm sites are legitimate. The EV SSL vetting process as defined by the CA/Browser Forum requires thorough independent audits, and these certs go beyond standard x.509 certificates by color-coding the address bar in some browsers.
On an individual basis, newer browsers--IE7 and Mozilla Firefox 2.0 in particular--focus on active fraud prevention and personal-information protection. An improved ability to scrub history and cache files, for example, benefits users and admins alike, as do antifraud measures, internationalized domain name (IDN) support, address-bar visibility and easier control over ActiveX component integration. And vendors are thinking outside the box--as evinced by Microsoft's Strider HoneyMonkey exploit-detection project, used by its Internet Safety Enforcement Team to track spammers and phishers.
The common thread: Proactively identify suspicious sites instead of waiting for users to stumble onto them.
The risk-management question that matters: How can damage to my network be minimized or prevented, despite an insecure Web browser? The answer requires multidimensional risk-mitigation strategies that go beyond network design to include physical security, corporate-use policy, vendor relationships, information-access security policies, new-software-approval processes, user training and, often, data-privacy management and information-access restrictions.
Even the smallest shops must abide by basic ground rules. Hopefully you've limited browser use to legitimate business and installed a content filter. But what about automatic updates from Microsoft's update service?
Fixing browser vulnerabilities is the responsibility of the software vendor. Cleaning up after these fixes? That's your job. Software updates are notorious for changing browser functionality just enough to break critical business apps, meaning "routine" updates regularly kick-start a wearisome cycle of events: Test the updated version for compatibility with existing apps; deploy the update; and all too often, spring into action with a workaround and rollback plan because an obscure problem was missed.
If you allow for automatic updates, revisit this policy in light of Microsoft's auto IE7 deployment, which bypassed many enterprises' testing processes and broke many apps. Granted, Microsoft told us well in advance that IE7 would be deployed using the automatic-update service and provided auto-update blocking and directions on reverting to version 6. But that didn't help many IT groups that burned daylight rolling back installations.
The company is between a rock and a hard place: We chastise Microsoft for its abundance of browser vulnerabilities, but complain when it takes measures to update its browser automatically to a more secure version. The lesson here: Auto-updates allow for rapid response fixes to security threats; But they also highlight the need to stay on top of these changes, and to have active centralized management. To that end, here are some steps to take now.
» GET SET FOR RAPID RESPONSE BY PUTTING MANAGEMENT IN PLACE: In this era of zero-day exploits and far-flung networks, it's outrageous that only two browsers--IE and, to a lesser extent, Firefox--let you rapidly deploy and configure software from a central admin server to all networked machines, restrict features through group policies and provide granular installation controls.
Microsoft's free IE Administration Kit is the standout here. IEAK has been around for a few IE incarnations, and we've seen the kit's functionality change with each major release. If you're managing IE, IEAK should be in your toolbox. In fact, in today's world of skinny IT budgets and barely adequate manpower, IEAK has been key in keeping IE dominant on the corporate desktop despite antitrust settlements, unbundling, security woes and periods of stagnated development.
IEAK aids in establishing and delivering user profiles, version control of browsers across the network, and customization of just about every setting using policies.
The only other browser that can boast a network-installation utility to set control by policy is Firefox, and that's only because of open-source project FirefoxADM. This project has been stagnant for a couple of years, unfortunately, and lacks the dedicated vendor support it should be getting. The result is a product that doesn't fully support all versions of Firefox, including the latest release.
Let's face it: Firefox isn't competitive with IE when it comes to enterprise deployments. While we applaud SourceForge for recognizing the importance of such a tool and the effort that's gone into making it available, we question the logic in spending a whole lot of time and money forcing Microsoft to decouple IE7 from the OS so there's a level playing field, if the tools to deploy and control rival browsers on the network aren't there.
The ability to tightly manage distributed browsers is basic to keeping them secure. Until Firefox, Netscape and Opera supporters step up to the plate and get their administrative acts together, IE will maintain its overwhelming market share.
» KNOW THINE ENEMY BY KEEPING ABREAST OF ATTACK VECTORS AND TRENDS: With phishing and related criminal activity producing 11,000 new illicit sites per month, according to the APWG, browser business as usual is courting disaster. The APWG membership includes not only security vendors, like Internet Security Systems, McAfee, Kaspersky Lab and Symantec, but also Adobe Systems, Cisco Systems, Microsoft and Trend Micro. In a rare display of collaboration, over a year ago the group began to address the problem of criminal activity targeting browsers. APWG provides a phishing reporting tool, a meeting calendar and e-crime trend numbers on its Web site to keep IT informed of security hotspots.
Although each browser vendor has its own way of detecting phishing sites, collected data is tracked by APWG. The aggregate data can help to identify criminal trends and warn vendors and IT of new attack methods, hopefully before they cause significant harm.
Some attack vectors use foreign characters. Support for IDNs has been present in Mozilla and Opera for some time, and Microsoft is playing catch-up with IE7. The IDN standard allows domain names that contain non-ASCII characters to be converted into ASCII representations using a known algorithm. Its purpose is to let domains that use European diacritics or non-Latin languages be retrofitted into the existing domain name space.
What does this have to do with security? Some attackers have made use of non-ASCII characters. In addition, IDNs cause problems with look-alike domains because of their conversion algorithms. Nonstandard encodings of normal ASCII characters could result in a look-alike domain--take "paypal.com," for example. The "a" could be an internationalized character, but the domain name would look identical to the legitimate site. Combining IDN with antiphishing browser capabilities may not completely stop this type of attack, but it should allow significant numbers of Web sites that try to exploit non-ASCII characters to be identified and blocked.
Finally, require every browser window to display an address bar. This will target pop-ups that use cross-domain redirection to mask their origins.=
» KEEP AN EYE ON EV SSL CERTIFICATES, BUT DON'T BET THE FARM ON THEM: EV Certificate support is being touted as helping to prevent phishing attacks against end users. The EV Certificate is designed to identify the owner of a Web site and pinpoint the business' physical location. The plan is for the CA (certificate authority) to verify the site owner's business prior to issuing the EV Certificate, providing a higher level of confidence in the legitimacy of the business.
As of October 2006, the CA/Browser Forum listed 20 CAs (PDF). They agree to perform due diligence before issuing an EV Certificate. VeriSign's EV Certificate practice, for example, is spelled out in some detail at verisign.com/repository/CPS.
EV Certificates are standard x.509 certificates with the certificate-policies-extension field completed. Each issuer has a unique object identifier that will allow the browser to match it against the CA record; if they match and the CA record is current, the enhanced validation information is passed to the browser for use.
Although the x.509 certificate is accepted by all current browsers, IE7 is the first to be billed as EV-ready, and the first to clearly flag this type of certificate by color-coding the address bar; other browsers are expected to follow suit. Unfortunately, Stanford researchers have released a study (usablesecurity.org/papers/jackson.pdf) showing that use of these high-assurance certificates doesn't necessarily help users identify phishing attempts. Picture-in-picture user interface spoofing attacks still succeed, and the certificates can sometimes provide a false sense of security.
» CONTROL YOUR PLUG-INS: Component plug-ins such as Acrobat Reader and Flash Player are common in many environments. Legitimate utilities enhance business, but rogue plug-ins have long been both an admin and a user nightmare. It's been all too easy for an inexperienced user to inadvertently load a malicious control into his Web browser and thereby compromise system security.
The latest browsers are helping to overcome this. They let IT specify--through policy or control of the build process--which add-ons can be loaded. They also let end users see which add-ons are loaded by the browser so they may easily disable the add-on locally if desired. Both approaches represent significant advances in letting the browser be quickly returned to a secure state should a compromise to an add-in program occur.
Browsers also are cleaning up after themselves more effectively. Recognizing that there's a significant installed base of public computers in production, users can easily delete their browsing histories and clear cache content. In fact, newer browsers may routinely clear both without prompting. This will prevent the next person in line from being able to see where others have browsed to or recall information retained (cookies, for instance) and mine for passwords, account numbers and the like.
Browser Management Conundrum
The alternative to a dedicated browser-management tool is to deploy an installation package using the existing policy tools for the OS. The drawback to this is the need to build an image specifically for deployment, ensure that any add-ins or restrictions are built into the image, and then package it for distribution to workstations.
If there's a need for two or more configurations, that's just more work for the administrator. For Windows systems, there's guidance provided for building Microsoft Installer-style deployment packages for Firefox at wiki. mozilla. org/ Firefox: 2.0_ Institutional_ Deployment. The article is specific to Firefox, but the procedure can be generalized to allow any browser to be built as an image and deployed across the network. Be aware it's a long process and not practicable in anything but small networks.
Managing The Risk
Serious about browser security? Limit who can access the Internet--it sounds draconian, but it's good security practice. Use layers of security. Set browsers to accept only "safe" sites, then lock the firewall policy down for Port 80, and other in-use ports, to the identified "safe" sites. Other steps to take:
>MONITOR Web traffic, and let everyone know you're watching. This is a tried-and-true method to discourage inappropriate browsing. If your policy is to monitor Web site access, for example, monitoring can range from simple--parsing firewall logs with an automated scanner--up to employing a comprehensive outsourced monitoring service. Remember: Policy that is not automatically enforced will be ignored.
>MANDATE use of the security features that ship with the browser, and supplement them with additional tools, like Exploit Prevention Labs' LinkScanner, the Google toolbar, McAfee's SiteAdvisor and Netcraft's Anti-Phishing Toolbar, to name a few.
>LOCK DOWN the browser using policies to prevent software add-ons or active components from loading, wherever possible.
>RUN Web applications and browsers in the lowest permission level possible, ideally unprivileged or restricted account.
>STAY CURRENT with security advisories for the Web browser(s) that are in use within your organization.
>EDUCATE users on safe surfing habits and useful skills like recognizing EV Certificates. Check out The SANS Institute's security newsletter--aka "SANS Ouch!"-- and disseminate the information to your end users. The bulletin provides phishing and hoax alerts, and every issue highlights the "security screw-up of the month." In February it was the loss by the IRS of 26 computer tapes containing information about an undisclosed number of taxpayers. Ouch, indeed.
Roger Beall is a certified senior network systems engineer at Entre Solutions, specializing in cutting-edge technologies, compliance auditing, network security and systems design for SMBs, banking and government. Write to him at [email protected].