Research

Well, they’ve finally done it. Microsoft announced they will be dropping OneCare and start providing antivirus for free to all Windows users late next year in a product called Morro. I consider this an extremely positive development, and no surprise at all. Back when Microsoft first acquired an AV company I told clients and reporters that Microsoft would first offer a commercial service, then eventually include it in Windows. Antivirus and other malware protections are really something that should be included as an option in the operating system, but due to past indiscretions (antitrust) Microsoft is extremely careful about adding major functionality that competes with third party products. The move to free AV for all Windows users helps on two fronts. First, it’s a good way to navigate the antitrust allegations that will likely surface from the consumer AV companies. By not including AV with the default installation of Windows, it keeps the competitive environment open and provides Microsoft a good defense for monopoly allegations. Second, I suspect this will only be available to legitimate, activated copies of Windows, which provides additional incentive to purchase a legal copy and stem a small part of the home piracy market. This won’t matter to the street vendors in China, but will encourage friends and family to buy their own damn copy of Windows. The major AV companies have long expected this move. Both McAfee and Symantec have been buffering themselves through diversification and acquisition for the past few years. My personal belief was that Symantec acquired Veritas in large part to prepare for the eventual dissolution of the consumer AV market when Microsoft eventually builds it into the OS. Will this hurt? Absolutely, but they probably won’t see any market erosion at all for 2 years, and the real pain will likely only start to hit in around 3 years. This gives them enough time to avoid suddenly losing 40% (don’t quote me on that, I’m on an airplane and just guessing) of profits over 12 months. The real losers will be the consumer-only AV companies with portfolio diversification or a larger enterprise base. I don’t expect to see material erosion of the enterprise AV market anytime soon. Major vendors like Symantec, McAfee, and Trend are including growing functionality in their endpoint products, and improving central management. These additional features will likely protect their enterprise client base, although there may be some price erosion. Any consumer oriented AV product will need to seriously innovate to survive once Morro is released. Users won’t be willing to pay the $70-$99 a year AV tax once a viable, easy to download and use, product appears. Microsoft already includes a good firewall in the OS, the Malicious Software Removal Tool, anti-phishing, and other security controls. Vista is much more secure than previous versions of the OS, and it sounds like Windows 7 will actually be usable. This combination means that any consumer “AV” company will need to either protect against new threats not covered by Windows, or offer materially better security than the built in tools. Both situations rely heavily on the threat environment, making accurate predictions difficult. My rough guess is that within 5-7 years most consumer-level Windows users won’t need third party desktop security. I’m not sure if it will be in WIndows 7, but it’s also clear that it’s inevitable that AV will be included in WIndows. In summary, this is good for users, will really hurt any consumer-only AV company, will only moderately hurt enterprise and diversified AV companies, and is an extremely positive step. Unless, of course, they screw it up or the product is crap. Those are always options. The flight attendant is giving me a nasty look, so it’s time to upload this and turn off my laptop… Share:

I realize this might shock our fair readers, but once upon a time I used to get my hands dirty with a little hands on web application development. Back in the heady early days of the mid-1990’s Internet I accidentally transitioned from a systems and network administrator to a web application developer and DBA at the University of Colorado’s Graduate School of Business. It all started when I made the mistake of making an incredibly ugly home page for the school, complete with a tiled background of my Photoslop-embossed version of the CU logo (but, thankfully, no BLINK tag). The University took note, and I slowly migrated out of keeping the network running into developing database driven web applications for a few thousand users. Eventually I ran my own department before setting off into the big bad world of private consulting. To this day I’m still proud of our online education tools that could totally kick Blackboard’s ass, but I think I developed my last application around 2001. I’ll be the first to admit that my skills are beyond stale, and the tools and techniques now available to web application developers are simply astounding. When I first started out in Boulder, Colorado I’d say the majority of web site developers I met were more focused on graphics skills than database design and proper user authentication. Today’s web application developers need a background in everything from structured programming, to application design, to a working knowledge of multiple frameworks and programming languages. Current web applications exist in an environment that is markedly different from the early days of businesses entering the Internet. They’ve become essential business tools interconnecting organizations in ways never anticipated when the first web browsers were designed. These changes have occurred so rapidly that, in many ways, we’ve failed to adapt our operational processes to meet current needs. This is especially apparent with web application security, where although most organizations have some security controls in place, few organizations have a comprehensive web application security program. This is a concern for two reasons. First, the lack of a complete program materially increases the chance of failure resulting in a loss-bearing security breach. Second, the lack of a coordinated program is likely to increase overall costs- not just losses from a breach, but the long term costs of maintaining an adequate security level (adequate being defined as meeting all compliance obligations and reducing losses to an acceptable level). This series of posts will show you how to build a pragmatic web application security program that constrains costs while still providing effective security. Rather than digging into the specific details of any particular technology, we’ll show you all the basic pieces and how to put them together. We’ll start with some background on how web applications are different than traditional enterprise applications or commercial off-the-shelf products. We’ll provide basic business justifications for investments in web application security you can use to gain management support (although we’ll be covering these in more depth in future research). The bulk of this series will then focus of the particular security needs of web applications, before delving into details on the major security components and how to pull them together into a complete program. Eventually we plan on releasing this as a white paper, and we already have one sponsor lined up (sponsors can redistribute the content and are acknowledged in the paper, but have no influence on content- it’s just an advertising spot within the larger paper). As with all of our research we rely on you, our readers, to keep us honest and accurate as we develop the research. Technically all analysts do that, but we actually admit it and prefer to engage you directly out in the open- so please comment away as we post. Since I’ve already wasted a ton of space setting up the series, today we’ll just cover the web application security problem. Our next post will provide business justifications for investing in a web application security program, and guidance on building a structured program. The Web Application Security Problem Enterprise web applications evolved in such a way that they’ve created a bit of a conundrum for security. Although we’ve always been aware of them, we initially treated them as low-risk endeavors almost fully under the control of the developers creating them. But before we knew it, they transitioned from experimental programs to critical business applications. Ask any web application developer and they can tell you the story of their small internal project that became an essential business application once they made the mistake of showing it off to a business unit or the outside world. We can break this general evolution down into some key trends creating the current security situation: Before web applications, few businesses exposed their internal transactional systems to the outside world. Even those businesses which did expose systems to business partners on a restricted basis rarely exposed them directly to customers. Web applications grew organically- starting from informational websites that were little more than online catalogs, through basic services, to robust online applications connected to back end systems. In many cases, this transition was the classic “frog in a frying pan” problem. Drop a frog into a hot frying pan, and it will hop right out. Slowly increase the heat, and it will fry to death without noticing or trying to escape. Our applications developed slowly over time, with increased functionality, leading to increased reliance, often without the oversight they might have gotten had they been scoped as massive projects from the beginning. Web application protocols were designed to be lightweight and flexible, and lacked privacy, integrity, and security checks. Web application development tools and techniques evolve rapidly, but we still rely on massive amounts of legacy code. Both internal and external systems, once deployed, are nearly impossible to simply shut down and migrate to new systems. Web application threats evolve as quickly as our applications, and apply to everything we’ve done in the past.