Denial: “Dan may be smart, but Tom Ptacek states the obvious that this isn’t a new threat. Maybe a new spin on an old flaw.”

Anger: “Dan didn’t find shit. He read RFC3383 …” and “Dan has brought NOTHING new to the table. Simply made a name for himself by regurgitating the same old problems.”

Bargaining: “… the sky was already falling before Dan opened his mouth, …”, and “This is just another reason why we need DNSSEC”, and “What Should Dan Have Done?”

Depression: “What can we say right now? Dan has the goods.”

Acceptance: “Dan Kaminsky Disqualified from Most Overhyped Bug Pwnie” and “This is absolutely one of the most exceptional research projects I’ve seen. Dan’s reputation will emerge more than intact …”

DNS Vulnerability: Very interesting. Blog Discourse on DNS Vulnerability: Absolutely mesmerizing.  Dan Kaminsky finds a DNS flaw, and half the security research community grieves.

-Adrian

Another off-topic post.

They say when you are frustrated, especially with someone in an email dialog, write-delete-rewrite. That means write the reply that you want to write, chock full of expletives and politically incorrect things you really want to say, and then delete it. Once you are finished with that cleansing process, start from scratch, writing the politically correct version of your reply. This has always been effective for me and kept me out of trouble.

One problem is I never delete anything. Quite the opposite- I save everything. Some of the best stuff I have ever written falls into this write-delete-rewrite category, only with the delete portion omitted. I ran across several examples this evening and some of them are really pretty funny … and completely inappropriate for public consumption. Still, I found a particularly large set of letters dedicated to one individual who was so profoundly dysfunctional and so exceptionally bad at his core set of responsibilities that I created a small tome in his honor. This particular person was “in sales”, despite not really ever having sold anything. And while we expect some degree of friction between sales and development (and I am sure some of you in marketing, product development, & engineering can relate), I have never before or since seen anything this profound. Over 20+ years in this profession, from big companies to small, there is one clear ‘winner’ in the category of utter failure. 

But over time, the more I looked at the body of dysfunction as a whole, the more I realized the practiced magnificence of the art of not-selling that he had mastered. If you view this as a master practicing his craft, you can almost admire his skill in avoiding the basic set of job requirements on the path towards organizational destruction. 

I am starting to wonder if I should turn these into a book on how to not sell because some items are truly special. Sort of an equivalent to Anti-patterns in software development, only as a sales management “do not” list. I have broken down some of the categories into the following chapters:

• “Early Funnel Cheerleading”: how to use a “parade of suspects” as a smokescreen
• “ABB”: always be blaming
• Layering dysfunction behaviors
• “It is OK to NOT sell”: building a culture of failure
• The “Gatling gun of blame”: the art of proactive pre-failure blame dispersal
• 5 traits of a bully and how to use them
• Action phrases, long email, and the illusion of activity
• Name dropping your way to legitimacy
• “Delegate everything”: responsibility avoidance for the modern sales guy
• Process? Process is for losers!
• “Playing it close to the vest”: how to share nothing important about your prospects so embarrassing details never come to light
• “The customer is always right”: feature-commiting your way to commissions
• Engaging in prospect politics: how to become a pariah even before the POC
• Surrounding yourself with losers: elevation through lowering the bar.

Do you think I have enough for a complete book?

-Adrian

If you can tell, with absolute certainty, that systems are vulnerable to an exploit without needing to test the mechanism, what good is served by releasing weaponized attack code immediately after patches are released, but before most enterprises can patch?

Unless you’re the bad guy, that is.

-rich

We’ve covered a lot of ground over the past few posts on endpoint DLP. Our last post finished our discussion of best practices and I’d like to close with a few short fictional use cases based on real deployments.

Endpoint Discovery and File Monitoring for PCI Compliance Support

BuyMore is a large regional home goods and grocery retailer in the southwest United States. In a previous PCI audit, credit card information was discovered on some employee laptops mixed in with loyalty program data and customer demographics. An expensive, manual audit and cleansing was performed within business units handling this content. To avoid similar issues in the future, BuyMore purchased an endpoint DLP solution with discovery and real time file monitoring support.

BuyMore has a highly distributed infrastructure due to multiple acquisitions and independently managed retail outlets (approximately 150 locations). During initial testing it was determined that database fingerprinting would be the best content analysis technique for the corporate headquarters, regional offices, and retail outlet servers, while rules-based analysis is the best fit for the systems used by store managers. The eventual goal is to transition all locations to database fingerprinting, once a database consolidation and cleansing program is complete.

During Phase 1, endpoint agents were deployed to corporate headquarters laptops for the customer relations and marketing team. An initial content discovery scan was performed, with policy violations reported to managers and the affected employees. For violations, a second scan was performed 30 days later to ensure that the data was removed. In Phase 2, the endpoint agents were switched into real time monitoring mode when the central management server was available (to support the database fingerprinting policy). Systems that leave the corporate network are then scanned monthly when the connect back in, with the tool tuned to only scan files modified since the last scan. All systems are scanned on a rotating quarterly basis, and reports generated and provided to the auditors.

For Phase 3, agents were expanded to the rest of the corporate headquarters team over the course of 6 months, on a business unit by business unit basis.

For the final phase, agents were deployed to retail outlets on a store by store basis. Due to the lower quality of database data in these locations, a rules-based policy for credit cards was used. Policy violations automatically generate an email to the store manager, and are reported to the central policy server for followup by a compliance manager.

At the end of 18 months, corporate headquarters and 78% or retail outlets were covered. BuyMore is planning on adding USB blocking in their next year of deployment, and already completed deployment of network filtering and content discovery for storage repositories.

Endpoint Enforcement for Intellectual Property Protection

EngineeringCo is a small contract engineering firm with 500 employees in the high tech manufacturing industry. They specialize in designing highly competitive mobile phones for major manufacturers. In 2006 they suffered a major theft of their intellectual property when a contractor transferred product description documents and CAD diagrams for a new design onto a USB device and sold them to a competitor in Asia, which beat their client to market by 3 months.

EngineeringCo purchased a full DLP suite in 2007 and completed deployment of partial document matching policies on the network, followed by network-scanning-based content discovery policies for corporate desktops. After 6 months they added network blocking for email, http, and ftp, and violations are at an acceptable level. In the first half of 2008 they began deployment of endpoint agents for engineering laptops (approximately 150 systems).

Because the information involved is so valuable, EngineeringCo decided to deploy full partial document matching policies on their endpoints. Testing determined performance is acceptable on current systems if the analysis signatures are limited to 500 MB in total size. To accommodate this limit, a special directory was established for each major project where managers drop key documents, rather than all project documents (which are still scanned and protected at the network). Engineers can work with documents, but the endpoint agent blocks network transmission except for internal email and file sharing, and any portable storage. The network gateway prevents engineers from emailing documents externally using their corporate email, but since it’s a gateway solution internal emails aren’t scanned.

Engineering teams are typically 5-25 individuals, and agents were deployed on a team by team basis, taking approximately 6 months total.

These are, of course, fictional best practices examples, but they’re drawn from discussions with dozens of DLP clients. The key takeaways are:

1. Start small, with a few simple policies and a limited footprint.
2. Grow deployments as you reduce incidents/violations to keep your incident queue under control and educate employees.
3. Start with monitoring/alerting and employee education, then move on to enforcement.
4. This is risk reduction, not risk elimination. Use the tool to identify and reduce exposure but don’t expect it to magically solve all your data security problems.
5. When you add new policies, test first with a limited audience before rolling them out to the entire scope, even if you are already covering the entire enterprise with other policies.

There is nothing else to say.

(Hoff claims he wrote it in 8 minutes).

I was reading through the NitroSecurity press release last week, thinking about the implications of their RippleTech purchase. This is an interesting move and not one of the Database Activity Monitoring acquisitions I was predicting. So what do we have here? IPS, DAM, SIM, and log management under one umbrella. Some real time solutions, some forensic solutions. They are certainly casting a broad net of offerings for compliance and security.

Will the unified product provide greater customer value? Difficult to say at this point. Conceptually I like the combination of network and agent based data collectors working together, I like what is possible with integrated IPS and DAM, and I am personally rather fond of offering real-time monitoring alongside forensic analysis audits. And those who know me are aware I tend to bash IPS as lacking enough application ‘context’ to make meaningful inspections of business transactions. A combined solution may help rectify this deficiency. Still, there is probably considerable distance between reality and the ideal. Rich and I were talking about this the other day, and I think he captured the essence very succinctly: “DAM isn’t necessarily a good match to integrate into intrusion prevention systems- they meet different business requirements, they are usually sold to a different buying center, and it’s not a problem you can solve on the network alone.”

I do not know a lot about NitroSecurity and I have not really been paying them much attention as they have been outside the scope of firms I typically follow. I know that they offer an intrusion prevention appliance, and that they have marketed it for compliance, security and systems management. They also have a SIM/SEM product as well, which should have some overlapping capabilities with RippleTech’s log management solution.

RippleTech I have been paying attention to since the Incache LLC acquisition back in 2006. I had seen Incache’s DBProbe and later DBProbeSec, but I did not perceive much value to the consumer over and above the raw data acquisition and generic reports for the purpose of database security. It really seem to have evolved little from its roots as a performance monitoring tool and was missing much in the way of policies, reporting and workflow integration needed for security and compliance.

I was interested in seeing which technology RippleTech chose to grow- the network sniffer or the agent- for several reasons. First, we were watching a major change in the Database Activity Monitoring (DAM) space at that time from security to compliance as the primary sales driver. Second, the pure network solutions missed some of the critical need for console based activity and controls, and we saw most of the pure network vendors move to a hybrid model for data collection. I guessed that the agent would become their primary data collector as it fit well with a SEM architecture and addressed the console activity issue. It appears that I guessed wrong, as RippleTech seems to offer primarily a network collector with Informant, their database activity monitoring product. I am unsure if LogCaster actually collects database audit logs, but if memory serves it does not. Someone in the know, please correct me if I am wrong on this one. Regardless, if I read the thrust of this press release correctly, NitroSecurity bought RippleTech primarily for the DAM offering.

Getting back to Rich’s point, it appears that some good pieces are in place. It will come down to how they stitch all of these together, and what features are offered to which buyers. If they remain loosely coupled data collectors with basic reporting, then this is security mish-mash. If all of the real time database analystics are coming from network data, they will miss many of the market requirements. Still, this could be very interesting depending upon where they are heading, so NitroSecurity is clearly on my radar from this point forward.

-Adrian

I ended a recent post with “I start to wonder if the corporations and public entities of the world have already effectively wiped out personal privacy.” It was just a thowaway idea that had popped into my head, but the more I thought about it over the next couple of days, the more it bothered me. It is probably because that idea was germinating while reading a series of news events during the past couple of weeks made me grasp the sheer momentum of privacy erosion that is going on. It is happening now, with little incentive for the parties involved to change their behavior, and there is seemingly little we can do about it.

A Business Perspective

Rich posted a blog entry on “YouTube, Viacom, And Why You Should Fear Google More Than The Government” on this topic as well. Technically I disagree with Rich in one regard, that being to have a degree of fear for all parties involved as Viacom, Google and the US government are in essence deriving value at the expense of individual privacy. I think this really ties in as companies like Google have strong financial incentives to store as much data on people- both at the aggregate and the personal level- as they can.

And it’s not just Google, but most Internet companies. Think about Amazon’s business model and their use of statistics and behavior profiling to alter the shopping experience (and pricing) for each visitor to their web site. My takeaway from Rich’s post was “The government has a plethora of mechanisms to track our activity”, and it is starting to look as if the biggest is the records created and maintained by corporations. Corporate entities are now the third party data harvester, and government entities act as the aggregator. While we like to think that we don’t live in a world that does such things, there are reasons to believe that this form of data management had a deciding factor in the 2000 presidential election with Database Technologies/Choicepoint. We already know that domestic spying is a reality.

Over the weekend I was catching up on some reading, going over some articles about how the government has provided immunity to telecom companies for providing data to the government. If that is not an incentive to continue data collection without regard for confidentiality, a “get out of jail free” card if you will, I don’t know what is.

I also got a chance to watch the Supernova video on Privacy and Security in the Network Age. Bruce Schneier’s comments in the first 10 minutes are pretty powerful. He has been evolving this line of thought over many years and he has really honed the content into a very compelling story. His example about facial recognition software, storage essentially being free, and with ubiquitous cameras is fairly startling when you realize everything you do in a public place could be recorded. Can you imagine having your entire four years at high school filmed, like it or not, and stored forever? Or if someone harvested your worst 5 minutes of driving on film over the last decade? Bruce is exactly right that this conversation is not about our security, but the entire effort is about control and policy enforcement. And it is not the government that is operating the cameras; it is businesses and institutions that make money with the collected data. With business that harvest data now seemingly immune to prosecution for privacy rights violations, there are no “checks and balances” to keep them from pursing this- rather they are financially motivated to do so. From cameras on the freeway to Google, there are always people willing to pay for surveillance data. They are not financially incentivized to care about privacy per se; unless it becomes a major PR nightmare and affects their core business, it is not going to happen.

My intention with the post was not to get all political, but rather to point out that businesses which collect data need some incentive to keep that consumer information confidential. I don’t think there is a legitimate business motivator right now. CA1386 and associated legislation is not a deterrent. Businesses make their money by collecting information, analyzing it, and then presenting new information based upon what they have previously collected. Many companies’ entire business models are predicated upon successfully doing this. The collection of sensitive and personally identifiable information is part of daily operation. Leakage is part of the business risk. But other than a competitive advantage, do they have any motivation to keep the data safe or to protect privacy? We have seen billions of records stolen, leaked or willfully provided, and yet there is little change in corporate activity in regards to privacy.

So I guess what scares me the most about all this is that I see little incentive for firms to protect individual privacy, and that lack of privacy is supported- and taken advantage of- backed by government. Our government is not only going to approve of the collection of personal data, it is going to benefit from it. This is why I see the problem accelerating. The US government has basically found a way to outsource the costs and risks of surveillance. They are not going to complain about mis-use of your sensitive data as they are saving billions of dollars by using data collected by corporations.

There are a couple of other angles to this I want to cover, but I will get to those in another post.

-Adrian

New Zealand is absolutely my favorite place on the face of the planet. I’ve made it down there twice, once for a month before I met my wife, and once for just under 3 weeks with her as we drove thousands of kilometers exploring as much of both islands as we could. As much as I love it, I don’t think I’d want to live there full time (I kind of like the US, despite our current administration).

But the latest news from New Zealand does give me a bit of an itch to head back down and “experiment” with the law. Seems a young fellow made about $31K giving some bad guys software they used to rake in something like $20M. Bad stuff-

Mr Walker was detained in the North Island city of Hamilton last November as part of an investigation with US and Dutch police into global networks of hijacked PCs, known as botnets

He’s 18, so odds are jail time, right? Like serious jail time?

Nope.

Judge Judith Potter dismissed the charges, relating to a 2006 attack on a computer system at a US university, saying a conviction could jeopardise a potentially bright career.

Nice. Hey, I think I might want to be a security guard at a convenience store, okay if we drop that little assault and robbery thing? I made way less than $31K? Heck, I didn’t steal the cash, I just drove the car, gave someone the gun and ski mask, and…

In our last post we talked about prepping for deployment- setting expectations, prioritizing, integrating with the infrastructure, and defining workflow. Now it’s time to get out of the lab and get our hands dirty.

Today we’re going to move beyond planning into deployment.

1. Integrate with your infrastructure: Endpoint DLP tools require integration with a few different infrastructure elements. First, if you are using a full DLP suite, figure out if you need to perform any extra integration before moving to endpoint deployments. Some suites OEM the endpoint agent and you may need some additional components to get up and running. In other cases, you’ll need to plan capacity and possibly deploy additional servers to handle the endpoint load. Next, integrate with your directory infrastructure if you haven’t already. Determine if you need any additional information to tie users to devices (in most cases, this is built into the tool and its directory integration components).
2. Integrate on the endpoint: In your preparatory steps you should have performed testing to be comfortable that the agent is compatible with your standard images and other workstation configurations. Now you need to add the agent to the production images and prepare deployment packages. Don’t forget to configure the agent before deployment, especially the home server location and how much space and resources to use on the endpoint. Depending on your tool, this may be managed after initial deployment by your management server.
3. Deploy agents to initial workgroups: You’ll want to start with a limited deployment before rolling out to the larger enterprise. Pick a workgroup where you can test your initial policies.
4. Build initial policies: For your first deployment, you should start with a small subset of policies, or even a single policy, in alert or content classification/discovery mode (where the tool reports on sensitive data, but doesn’t generate policy violations).
5. Baseline, then expand deployment: Deploy your initial policies to the starting workgroup. Try to roll the policies out one monitoring/enforcement mode at a time, e.g., start with endpoint discovery, then move to USB blocking, then add network alerting, then blocking, and so on. Once you have a good feel for the effectiveness of the policies, performance, and enterprise integration, you can expand into a wider deployment, covering more of the enterprise. After the first few you’ll have a good understanding of how quickly, and how widely, you can roll out new policies.
6. Tune policies: Even stable policies may require tuning over time. In some cases it’s to improve effectiveness, in others to reduce false positives, and in still other cases to adapt to evolving business needs. You’ll want to initially tune policies during baselining, but continue to tune them as the deployment expands. Most DLP clients report that they don’t spend much time tuning policies after baselining, but it’s always a good idea to keep your policies current with enterprise needs.
7. Add enforcement/protection: By this point you should understand the effectiveness of your policies, and have educated users where you’ve found policy violations. You can now start switching to enforcement or protective actions, such as blocking, network filtering, or encryption of files. It’s important to notify users of enforcement actions as they occur, otherwise you might frustrate them unnecessarily. If you’re making a major change to established business process, consider scaling out enforcement options on a business unit by business unit basis (e.g., restricting access to a common content type to meet a new compliance need).

Deploying endpoint DLP isn’t really very difficult; the most common mistake enterprises make is deploying agents and policies too widely, too quickly. When you combine a new endpoint agent with intrusive enforcement actions that interfere (positively or negatively) with people’s work habits, you risk grumpy employees and political backlash. Most organizations find that a staged rollout of agents, followed by first deploying monitoring policies before moving into enforcement, then a staged rollout of policies, is the most effective approach.

On July 29th I’ll be giving a webcast entitled Using Data Leakage Prevention and Database Activity Monitoring for Data Protection. It’s a mix of my content on DLP, DAM and Information Centric security, designed to show you how to piece these technologies together.

It’s sponsored by Tizor, and you can register here (the content, as always, is my independent stuff). Here’s the description:

When it comes to data security, few things are certain, but there is one thing that very few security experts will dispute. Enterprises need a new way of thinking about data security, because traditional data security methods are just not working.

Data Leakage Prevention (DLP) and Database Activity Monitoring (DAM) are two fundamental components of the new security landscape. Predicated on the need to “know” what is actually happening with sensitive data, DLP and DAM address pressing security issues. But despite the value that these two technologies offer, there is a great deal of confusion about what these technologies actually do and how they should be implemented.

At this webinar, Rich Mogull, one of today’s most well respected security experts, will clear up the confusion about DLP and DAM.

Rich will discuss:

* The business problems created by a lack of data centric security

* How these problems relate to today’s threats and technologies

* What DLP and DAM do and how they fit into the enterprise security environment

* Best practices for creating a data centric security model for your organization

- Rich