Archer Sets Its Sights On IT GRC Rival, Acquires Brabeion

Top contenders in the IT governance, risk, and compliance market merged on Tuesday as Archer Technologies announced it is acquiring Brabeion Software. Forrester projected consolidation as a key GRC market trend for 2009, and we explored the issue further for IT GRC vendors in our report, "Consolidation Looms for the IT GRC Market."

This was a strong move for Archer, as other, larger vendors are closely eying the IT GRC space for acquisition potential. Along with the acquisition of Paisley by Thomson Reuters last month in the Enterprise GRC space, this is just the beginning of what’s to come over the next 12-18 months. The GRC market as a whole is extremely broad and ripe for growth, but it is also crowded with niche vendors. Market leaders and enormous outsiders will be eager to scoop up as much of the pie as possible, which means more deals are on the way.

Stay tuned.

Beyond the Heartland Incident: Is It Time to Re-Visit Old Security Models?

As just about anybody reading the security trades knows, last week Heartland Payment Systems reported that it had suffered a serious security breach. As I understand it from public reports, a malicious party planted a piece of designer malware on a key server, and was then able to "sniff" credit card numbers as they passed through. Estimates vary widely about the extent of the breach. Certainly, SB 1386 and other disclosure laws will ensure that something resembling the truth will emerge sooner or later.

Clearly, this particular incident is a serious one. Various observers have used this incident to take issue with Heartland, the PCI DSS, their auditors and more generally the process for certifying QSAs. That is all well and good, but the non-stop parade of toxic data spills makes me wonder whether we, as an industry, aren't missing a few fairly obvious points.

The first point is this: attackers are changing their targets. It is clear that payment processors, in general and Heartland in particular, was a huge and tempting target for the attackers. Why bother knocking over a lone merchant when you can go after the processing network that it, and thousands of other merchants, send all their cardholder details to? In this respect, the attack on Heartland Payment Systems (a back-end payment processor) is an improvement on the "normal" techniques for filching card data: compromising a merchant's website or 0wning a consumer's PC.

In my experience, back-end providers sometimes rely on the relative obscurity of their businesses to stay off of the front pages of the newspapers. But they no longer have that luxury. Remember the 2003 Ohio/First Energy power outage? It acquainted the general public with hitherto-obscure acronyms like SCADA and NERC. In the same way, 2009 will focus a laser-beam on payment processors, and on their central role in our credit-card driven economy. That means we'll be hearing more about what Paymentech, First Data, Alliance Data Systems et al are doing to keep cardholder data secure -- or not doing.

The second point relates to economic incentives. As I mentioned, the affected party in this case is a back-end service provider (Heartland) that most ordinary people have never heard of. Consumers don't have a choice in who their merchants use to process their payments, and they can't "vote with their wallets" to use another payment processor if they want to. Merchants, on the other hand, are motivated primarily by price. So they will select select the payment processor that costs them the least as long as they are "compliant." The incentive, clearly, is for payment processors to do the absolute minimum required to pass their PCI audits, and no more. These incentives are not aligned with the concerns of the parties with the most skin in the game: the merchants and card issuers who share responsibility for losses, and secondarily consumers affected by breaches.

This brings me to the third point: it's time to dust off an old technology. It's one that operates on the simple principle that attackers can't steal sensitive data that isn't there. Seasoned industry observers, especially the Better Living Through Cryptography crowd, will remember a stillborn payment card industry initiative called Secure Electronic Transactions. SET certainly had its problems, but the objective was noble: to prevent the need for merchants to retain cardholder data at all. It did this using double-blinded cryptography that allowed both parties (cardholder and merchant) to authenticate transactions without actually needing to transmit cardholder information.

With payment processing networks now under attack, it's time to dust off SET. How about "Son of SET?." But instead of trying to keep just merchants clean, the focus should be on removing the need for all intermediate parties to transmit, hold or process cardholder data. Ideally, only two parties should need to know the card number: the end-user and the card issuer ("the bank"). Everybody else is just a target waiting to be discovered.

Can we get there? Not anytime soon. But until we figure out how to remove toxic cardholder information from the transaction flow, headlines about hacks on merchants and payment processors will keep coming fast and furious -- PCI DSS or no PCI DSS.

With the Sana acquisition by AVG, the HIPS era ended today

Today, AVG announced the acquisition of Sana Security, a longtime host-intrusion prevention software vendor. I have particular affection for Sana because they were a former client of mine at a previous job. Back in the summer of 2007, when security startup venture money was still flowing freely, like a rose-scented fountain at a Vegas casino, I remember giving a speech for Sana at their San Jose Grand Prix event. Don Listwin, their then-CEO, was a serious car racing enthusiast. He had conspired with the city of San Jose to shut down the city center so they could run race cars down the middle of it. It was pretty wild stuff -- speaking as someone who comes from Boston, where all of the roads seem to be derived from old horse-trails or giant spiderweb patterns.

Host intrusion prevention software has always been a fascinating subsegment of client security, not least because of the fact that what HIPS vendors try to do is actually pretty hard stuff. In concept, the idea sounds simple: monitor processes in memory for suspicious activity, and block them when they try to do something naughty. For example, an ActiveX control executing in the context of a website should not be allowed to open a command shell and then initiate an outbound connection to somewhere else. Simple, right?

In practice, though HIPS isn't so simple. Some early vendors -- like Cisco's CSA, née Okena; or Entercept, acquired by McAfee -- relied on rules to enumerate behaviors that would be allowed or blocked. That worked, but only after lots of tuning. And re-tuning. And even more re-tuning. Anybody who's every written declarative security policies (firewall rules, Java security policies) knows how tough this is to get right from an engineering perspective -- the rule language needs to be precise, but flexible at the same time. These early generations -- since improved -- went through significant growing pains to be useful. (Hmm: activity monitoring driven by rules that require lots of tuning... reminds me of DLP today!)

Second generation HIPS vendors, like Sana and Prevx, relied less on rules and more on something akin to fuzzy logic. An activity received weighted scores based on the context of the process, what it's doing, its code "pedigree" and other factors. Activities that seemed "suspicious enough" got blocked. This cut down on the need to create lots of rules, and made second-generation products less prone to get in users' faces. Sana, in particular, sought to make their tool relatively "noiseless" -- an important consideration in the consumer market.

Getting the technology right was hard enough. But recall also that malware authors have become much more professional and clever in their techniques. The increased sophistication of attackers is a fact of life: see rootkit.com, the Metasploit project, or the Uninformed journal for some examples. Today, it is an arms race. HIPS program want to burrow as deep into the Windows kernel as possible, to provide the best protection. Malware wants to burrow even deeper to avoid detection! Users therefore face the prospect of security programs and malware both fighting each other to get the deepest into the kernel, sort of like two dogs digging for a bone. Of course, kernel hooking falls entirely into the realm of undocumented voodoo, so instability is often the net result of this sort of alpha-dog antics. This was precisely the reason why Microsoft shut down (or tried to) access to the kernel in 64-bit versions of Vista.

As an analyst, Sana was always a hard company for me to evaluate. Most of their customers are consumers, so it is difficult to get credible information about how well the product actually worked. That said, the head of a large anti-virus company's engineering group (not AVG) told me about a year ago that they admired their technology very much. But they haven't been generating any buzz for quite a while. Their website is badly out of date. Sana has been shopped around for over a year, drawing interest from the Usual Suspects in Silicon Valley. I suspect the prospective acquirers I heard about last year concluded that Sana's HIPS features weren't tons better than what they already had, or at least no so dramatically better that they would justify the price of the acquisition and follow-on integration efforts.

With this deal, I think we can safely declare the era of stand-alone HIPS to be over. HIPS functionality is pretty well integrated into mainstream security suites now, as I and many other analysts have predicted it would be. Symantec and McAfee bought their own HIPS products several years ago, and have moved HIPS features into the core. Panda and Sophos have developed their own indigenous HIPS features. This is a good thing, of course -- but it shows how, in retrospect, HIPS was always meant to be a "feature" and not a "product."

Farewell, HIPS. It's been fun.

Analysts Evolve, Data-Centric Security Devolves

I am pleased to announce that this is my inaugural post on the Forrester SRM blog. Not only that, it's the day that my first research report went live on the Forrester site.

About me: I am a long-time Forrester fan. My first exposure to Forrester came back in 1994, when I was a lowly systems analyst figuring out how to build IT systems to manage trucks and warehouses. I always loved the Forrester writing style: interesting data, strong prose and solid recommendations -- written by people utterly unafraid to take tough positions. And now 15 years later, here I am trying to do the same. I'm pleased to be here, working with such a talented team of professionals!

My first report, called Data-Centric Security Requires Devolution, Not a Revolution, begins by talking about how securing enterprise data has become a top priority for enterprise CISOs. By "data" we mean structured and unstructured bits of information sprinkled all over the landscape: in databases, documents and e-mails, residing on servers, laptops, desktops and mobile devices.

All of the enterprise's data must be secured... that is obvious. Enterprises have been trying to do this for years with e-mail filtering, hard disk encryption, data leak prevention (DLP) and other technologies. Every few years, another hot technology emerges. But what's less obvious is that the accepted way of tacking the problem -- making IT Security the primary responsible party -- isn't necessarily the most effective way to do it.

In the report, I take the position that devolution of responsibilities from IT Security to business units is the most important success factor. I'd urge you to read the report for yourself. But in short: as long as data security is just "an IT thing," it's virtually certain that the most accountable parties (BUs) will be able to wash their hands of any responsibility. Depending on the organization, the centralized approach tends to lead to two scenarios:

(1) IT throws up its hands, saying "it's too hard!" -- guaranteeing that data security problems breed like rabbits
(2) IT dials up the data controls so tight that end-users and business units rebel against or subvert the controls -- leading to even worse problems

What's worse? No controls, or too many? The truth lies somewhere in between, and results vary widely depending on who's accountable: the boss you already know and have a relationship with, or an amorphous cost center whose workers don't know what you do all day. Your boss knows what work products are appropriate to protect, and what aren't. IT Security's role should be supply the tools to enforce the businesses' wishes, not operate them themselves.

Want to secure enterprise data? Stop trying so hard, and devolve!