Analysis: Browser Security Part I By Roger Beall
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 .
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.
Manage Risk
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.
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 .
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.
Manage Risk
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.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home