Security and Risk Management Strategies Blog

bioLock: Shameless use of “DLP”

As an analyst, I get a truckload of vendor email trying to convince me how great various security products are. The DELETE key often serves me well, but today I got a message that caught my interest:

“Ultimate Data Loss Prevention for SAP: www.DLP4SAP.com”

Having recently done a fair amount of data leakage prevention research, I thought to myself, “There’s a DLP tool for SAP?”

Looking more closely, it turns out the technology in question is a biometric authenticator. Basically, they’re claiming that better authentication will thwart leakage.

NO, NO, NO!

Talking with clients, the number one concern with leakage is employees inadvertently (or intentionally, in some cases) causing data to go to the wrong place. This is information the employees work with each and every day. In other words, these are authorized users either doing bad things or just making mistakes. But in either case, they’ve already been vetted, authenticated, authorized, etc. The problem isn’t to do a better job of figuring out who they are, but controlling how they use the information. Authentication has nothing to do with it.

I refuse to believe that bioLock doesn’t understand this. Which means they are blatantly (mis)using the DLP tag to get attention for their solution.

That really annoys me!

(By the way, I’ll freely admit that lots of vendors do this – bioLock just happened to catch my attention today.)

The Open Source Path to Security Products

Blogger: Eric Maiwald

Yesterday, Rapid7 announced the acquisition of Metasploit. Two other examples of an open source project being transformed into a commercial enterprise in the area of vulnerabilities, exploits, and detection signatures (all of them are closely related) come to mind – the other two that I’m thinking of Nessus/Tenable and Snort/Sourcefire. The model seems makes sense for technologies around security vulnerabilities.

In all three cases, a technology was created and a community was formed (worldwide in all three cases). The community contributed their knowledge to the project. While some of this knowledge went to the development of the software, much more went into the development of the vulnerability (or signature or exploit) libraries. Beyond the initial creation of the libraries, the community continued to contribute. Thousands of people (perhaps even larger but I don’t think anyone really knows) were continually on the lookout for security vulnerabilities or new exploits. These same people then either notified the community about the issue or they created a vulnerability check, signature, or exploit and contributed it to the project. For the commercialized products, there still must be a QA/QC testing process to make sure the check/exploit/signatures works and does not cause problems when it is deployed.

Now compare that model to a really smart person (or team of people) that starts a commercial company in this same area. In order to get things going, the team must build the software and do all of the research needed to create the vulnerability checks, signatures, or exploits. That is a lot of work and given the number of products already on the market, there is a lot of catch up to do. Once the initial work has been done, the company will need to maintain an expert research team to keep creating the vulnerability checks, signatures, or exploits. The really good teams are not small – they will need people with expertise in a number of different areas – and they are not cheap. An interesting point is that many teams maintain contact with the open source communities and trade information. There are certainly examples of companies that have successfully created a product and maintained a world class team. However, there are also examples of companies trying to get started and failing.

It is hard to beat a large community when it comes to identifying potential problems (even if additional help is needed to commercialize what has been identified) so perhaps the area of vulnerabilities, exploits, and signatures is well served by the open source model. What do you think?

Clouds, Malware, and Quibbling about Free Stuff

"Internet public health crisis.” That’s a phrase we security analysts came up with a couple of years ago to describe the dramatic upswing in damaging malware across the net. When we think about increased reliance on the public Internet for all manner of business, malware is not merely an annoying occasional productivity drain: it’s an epidemiological disaster! A move to cloud computing models is contingent on sound Internet infrastructure in order to work. But with continuous targeted attacks, massive botnets, denial-of-service strikes, and general mayhem so common, there’s considerable risk in relying on the Internet to deliver cloud services.

Ubiquitous home broadband plus dodgy consumer security practices are part of the problem. That’s what makes malware a public health issue. Bruce Schneier talked about this years ago when Microsoft was deliberating limiting Windows XP updates to verified copies. If millions of home users are unprotected from emerging badware, their infected machines affect us all. It’s comparable to human vaccination: every person walking around without inoculation is a potential infection vector for others. Not only home computing users are culpable, either. A recent Network World article, “Cheapskate SMBs dodge buying security software,” points out that small businesses may also be part of the problem.

So I personally welcomed Microsoft’s free entrant to the software security wars, Security Essentials (MSE). By all accounts, it’s a solid if modest way for home users to enhance their protection. Most importantly, it’s cost-effective (namely, free). Perhaps it’s also a lower level of effort compared to other free—and admittedly good—third party options, which also spurs adoption. And by vaccinating themselves, consumers help us all.

Predictably, both Trend Micro and Symantec (and probably others that I don’t know about) have called MSE basic or poor or otherwise unfit for duty. Clearly, they aren’t in this game for charity, and MSE could take a bite out of revenues. Also, from the perspective of identity fraud and personal security threats, these vendors have a point: consumers should seek security tools that best protect them against life-derailing harm—like a drained bank account due to password theft. However, when it comes to Internet epidemiology, MSE may be just what the doctor ordered. A basic level of protection, offered to consumers for free, which keeps the lid on the most egregious attacks, can only be a good thing for network health. And in an era of increased Internet reliance, free is better than nothing. Let’s stop quibbling about it.

Examining the Data Leakage Prevention (DLP) Market

Data leakage prevention (DLP) continues to be a big topic of interest with Burton Group clients. We just released a “Market Insight” study on the DLP market that describes how vendors are answering the four major use cases:

• Protection of data in motion
• Discovery and protection of data at rest
• Discovery and protection of data in use at user endpoints
• Improving user awareness and training of usage policies for sensitive data

Eric Maiwald and Trent Henry recorded a free BrightTalk webinar to summarize our findings. Here it is:

Open Question from McAfee Focus 09 Security Conference

Blogger: Dan Blum

At the McAfee Focus 09 Security Conference last week in Las Vegas, CEO Dave DeWalt stood under the bright lights on a theater-in-the-round stage, and kicked off proceedings with the pro forma scary characterization of a dangerous threat landscape and McAfee’s strategy on the defense.

Dave highlighted the need for “multilayer defense,” “multilayer correlation,” and “situation awareness.” He said that despite the breadth of McAfee’s product line and its ongoing strategy to build its Security Innovation Alliance through partnerships that enhance the strong, integrated management capabilities of ePolicy Orchestrator (ePO), “we can’t do it alone.” DeWalt appealed to his audience of end users and partners to share their ideas of how the community can be more effectively coordinate multi-vendor products on the defense.

Later that morning, Dave arrived to answer questions from the press and analyst community. At some point as he introduced the session, or perhaps it had been during the keynote itself, DeWalt mentioned that the numbers of McAfee’s alliance partners were growing, Symantec was taking notice and might start something similar, but McAfee had better tools and application program interfaces (APIs) for effective partner coordination. That’s when I decided to ask a question.

After a brief delay while paparazzi snapping innumerable photos blocked my view, the paparazzi sat down, I raised my hand and was acknowledged. My question: “Mr. DeWalt, I’m glad to hear you emphasize the need to coordinate multiple security vendors and products. We hear that from our customers all the time. It’s great to see your partner alliance growing in numbers. But I think it has to be more than a vendor ecosystem and some APIs. If McAfee has an alliance, Symantec has one, and Microsoft has one who knows at the end of the day if all the products will talk to each other? I think there’s a strong need for standards. You spoke about situation awareness; I’d like to call your attention to the Common Event Expression (CEE) work on log standards which would relate to your security information management product line. But more generally, what standards does your Security Innovation Alliance (SIA) plan to promote?”

Paraphrasing Dave’s reply from memory: “We have all kinds of IT standards, but no standards for security. We’ll promote standards but we’ll put our own stamp on it. We’re looking in the areas of a common service bus and a common policy language. But it’s not just technical standards that are needed; it’s also standards for governance.”

A reasonable general sort of answer. But while writing this I looked at the web pages promoting the Security Innovation Alliance, and there’s nothing about standards there now. If standards will be emphasized in the future, the site needs set forth a vision, define objectives, milestones, and progress.

I didn’t really expect a CEO to respond on the spot to something as technical as CEE log standards. Although these standards could in time greatly enhance both real time situation awareness and deeper event log correlation among multiple vendors, they are fairly obscure. That’s why I worded my question to let Dave address standards in a general way. But I did hope to plant a CEE seed in McAfee land. More likely my seed blew away in the wind of a busy week, but perhaps McAfee will see this blog entry and consider what I say. Their comments are welcome here.