Research

Websense announced today that they are being acquired by Vista Equity Partners and will be going private when the transaction closes. From the press release: Under the terms of the agreement, Websense stockholders will receive $24.75 in cash for each share of Websense common stock they hold, representing a premium of approximately 29 percent over Websense’s closing price on May 17, 2013 and a 53 percent premium to Websense’s average closing price over the past 60 days. The Websense board of directors unanimously recommends that the company’s stockholders tender their shares in the tender offer. Let’s be honest – Websense needed to do something, and John McCormack was elevated to the CEO position to get some sort of deal done. They have been languishing for the last few years under serious execution failures, predominantly in sales, and their channel strategy. The competition basically wrote them off, and has spent the last few years looting the Websense installed base. But unlike most companies which end up needing rescue from a private equity firm, Websense still has a decent product and technology. I have heard from multiple competitors over the past couple years that they have been surprised Websense hasn’t been more of a challenge given the capability of their rebuilt product line. TRITON is a good platform, combining email and web security with DLP – available on-premise, in the cloud, or as a hybrid deployment. That cloud piece holds the potential to save this from being a total train wreck for Vista. The on-premise web filtering market is being subsumed by multiple perimeter security vendors. Email security has substantially moved to the cloud, and is a mature market with highly competitive products from larger competitors. DLP isn’t enough to support a standalone company. Even combining these three pieces isn’t enough when the UTM guys advertise it all on one box for the mid-market, particularly because large enterprises look for best-of-breed components rather than for bundles. We assume Vista wants to break out the standard private equity playbook, focusing on sales execution and rebuilding distribution channels to generate cash by leveraging the installed base. Then they can sell Websense off in 2-3 years to a strategic acquirer. Thoma Bravo has proven a few times that if you can execute on the PE playbook in the security market, it’s great for the investors and remaining management, who walk away with a big economic win. TRITON has the potential to drive a positive exit, but only because of the cloud piece. On-premise they won’t be able to compete with the broader UTM and NGFW boxes. But Security as a Service bundles for email, web, and DLP are a growing market – especially in the mid-market, and even some enterprises are moving that way. Think ZScaler, not Check Point. Unlike the box pushers Websense is already a legitimate SecaaS player. We are not fortune tellers but if Vista expects a return similar to the SonicWALL deal, that is a stretch. Acquiring Websense is certainly one place to start in the security market, and there is a reasonable chance they won’t lose money – especially when they recapitalize the debt in a few quarters and take a distribution to cover their equity investment. The PE guys aren’t dumb. But in order to create a big win they need to inject some serious vision, rebuild the product teams, and streamline around TRITON with an emphasis on the cloud and hybrid options, all while stopping the bleed-off of the installed base. We hope internally they have a sense of urgency and excitement, as they step away from the scrutiny of the public market – not one of relief that they can hide for a few more years. As far as existing customers, it’s hard to see a downside unless Vista decides to focus on sales and channels while totally neglecting product and technology. They would be idiots to take that approach, though, so odds are good for the product continuing to improve and remaining competitive. Websense isn’t dead in the water by any means – if anything this deal gives them a chance to make the required changes without worrying about quarterly sales goals. But there will be nothing easy about turning Websense around. Vista and Websense have a lot of work in front of them. Photo credit: “Private” originally uploaded by Richard Holt Share:

In the sad but true files, the industry has become focused on advanced malware, state-sponsored attackers, and 0-day attacks, to the exclusion of everything else. Any stroll around a trade show floor makes that obvious. Which is curious because these ‘advanced’ attackers are not a factor for the large majority of companies. It also masks the fact that many compromises start with attacks against poorly-coded brittle web sites. Sure many high-profile attacks target unsophisticated employees with crafty phishing messages, but we can neither minimize nor forget that if an attacker has the ability to gain presence via a website, they’ll take it. Why would they burn a good phishing message, 0-day malware, or other sophisticated attack when they can pop your web server with a XSS attack and then systematically run roughshod over your environment to achieve their mission? We wrote about the challenges of deploying and managing WAF products and services at enterprise scale last year. But we kind of jumped to Step 2, and didn’t spend any time on simpler approaches to an initial solution for protecting websites. Even today, strange as it sounds, far too many website have no protection at all. They are built with vulnerable technologies and without a thought for security, and then let loose into a very hostile world. These sites are sitting ducks for script kiddies and organized crime alike. So we are taking a step back to write a new series about protecting websites using Security as a Service (SECaaS). We will use our Quick Wins structure to keep focus on how web protection services can make a difference in protecting web properties, and can be deployed quickly without fuss. To be clear, you can achieve these goals using on-premise equipment, and we will discuss the pros & cons of that approach vis-a-vis web protection services. But Mr. Market tells us every day that the advantages of an always-on, simple-to-deploy and secure-enough service win out over yet another complex device to manage in the network perimeter. Before we get going we would like to thank to Akamai for agreeing to potentially license this content on completion, but as with all our research we will write the series objectively and independently, guided by our Totally Transparent Research Methodology. That allows us to write what needs to be written and stay focused on end user requirements. Website Attack Vectors Although the industry has made strides toward a more secure web experience it rarely takes long for reasonably capable attackers to find holes in any organization’s web properties. Whether due to poor coding practices, a poorly configured or architected technology stack, or change control issues, there is usually a way to defeat an application without proper protections in place. But even when proper security protections make it hard to compromise an application directly, attackers just resort to knocking down the site using a denial of service (DoS) attack. Let’s dig into these attack vectors and why we haven’t made much progress addressing them. SDLC what? The seeming inability of most developers to understand even simplistic secure coding requirements continues to plague security professionals, and leaves websites unprepared to handle simple attacks. But if we are honest that may not be fair. It is more an issue of developer apathy than inability. Developers still lack incentives to adopt secure coding practices – they are evaluated on their ability to ship code on time … not necessarily secure code. For “A Day in the Life of a CISO”, Mike wrote poems (in pseudo iambic pentameter, no less!). One was about application security: Urgent. The VP of Dev calls you in. A shiny new app. Full of epic win. Customers will love it. Everyone clap. We launch tomorrow. Dr. Dre will rap. It’s in the cloud. Using AJAX and Flash. No time for pen test. What’s password hash? Kind of funny, eh? It would be if it weren’t so true. Addressing this issue requires you to look at it creatively two perspectives. First you must be realistic and accept that you aren’t going to fundamentally change developer behavior overnight. So you need a solution to protect the website without rebuilding the code or changing developer behavior. You need to be able to stop SQL injection and XSS today, which is actually two days late. Why? Look no further than the truth explain by Josh Corman when introducing HD Moore’s Law. If your site can be compromised by anyone with an Internet connection, so long as they have 15 minutes to download and install Metasploit, you will have very long days as a security professional. Over time the right answer is to use a secure software development lifecycle (SDLC) to build all your code. We have written extensive about this Web app security program so we won’t rehash the details here. Suffice it to say that without proper incentives, a mandate from the top to develop and launch secure code, and a process to ensure it, you are unlikely to make much strategic progress. Brittle infrastructure It is amazing how many high profile websites are deployed on unpatched components. We understand the challenge of operational discipline, the issues of managing downtime & maintenance windows, and the complexity of today’s interlinked technology stacks. That understanding and $4 will buy you a latte at the local coffee shop. Attackers don’t care about your operational challenges. They constantly search for vulnerable versions of technology components, such as Apache, MySQL, Tomcat, Java, and hundreds of other common website components. Keeping everything patched and up to date is harder than endpoint patching, given the issues around downtime and the sheer variety of components used by web developers. Everyone talks about how great websites and SaaS are because the users are no longer subjected to patching and updates. Alas, server components still need to be updated – but you get to take care of them so end users don’t need to. Now you are. And if you don’t do it correctly – especially with open source components – you leave low-hanging fruit for attackers, who can easily weaponize exploits and search for vulnerable sites

The Washington Post says US Officials claimed Chinese hackers breached Google to determine who the US wanted Google to spy on. In essence the 2010 Aurora attack was a counter-counter-espionage effort to determine who the US government was monitoring. From the Post’s post: Chinese hackers who breached Google’s servers several years ago gained access to a sensitive database with years’ worth of information about U.S. surveillance targets, according to current and former government officials. The breach appears to have been aimed at unearthing the identities of Chinese intelligence operatives in the United States who may have been under surveillance by American law enforcement agencies. … and … Last month, a senior Microsoft official suggested that Chinese hackers had targeted the company’s servers about the same time Google’s system was compromised. The official said Microsoft concluded that whoever was behind the breach was seeking to identify accounts that had been tagged for surveillance by U.S. national security and law enforcement agencies. Wow. Like it or not, the US government ensnared US companies to spy on their customers and users. If the Chinese motivation is as claimed, Google was targeted because it was known to be collecting data on suspected spies. It will be interesting to see whether this announcement generates some pushback, either by companies refusing to cooperate, or – as many companies have done – by removing infrastructure that tracks specific users. Paining a target on your back and placing yourself in a situation where your servers could be seized is a risk most firms can’t afford. Share: