One of the cool things about the first dot com bubble was the "ebay millionaire". These were people who built businesses around selling goods at auction on ebay.  There has been much written and said about the methods of these people and certainly it was a big attraction to people selling on ebay.  I had an interesting plane ride home today where I met someone and discovered todays equivalent. I call it the StubHub millionaire. It  is a testament to American ingenuity and shows that given the tools, people will find a way to exploit and make money.

Up until fairly recently you bought tickets to sporting events and other entertainment from a box office or ticket agent such as ticketron.  The "after market" in ticket sales or scalping as it was called in NY was often times illegal.  There were though some legal ticket brokers that you could buy tickets from. Now with the advent of StubHub and similar type of ticket reselling outlets on the web though, the infrastructure is in place for anyone to sell tickets on line.  You would think that most of these people selling tickets were people who had either extra tickets to an event or perhaps a season ticket holder looking to unload some tickets to help defray the costs. Not the case!

There is a now a whole class of businessman who buys season tickets to multiple teams, sports and cities and than uses outlets like StubHub and others to sell these tickets.  The guy I spoke to today had season tickets to 6 different NFL teams, 3 major league baseball teams and multiple basketball and hockey teams.  Many of his tickets are sold months and weeks before the event. If any are left within 14 days of the event he puts them on ebay.  His average mark up is about 40 to 50% of face value, but by buying season tickets he pays below face, so his actual margin is closer to 60 to 70%. He keeps a few tickets for him and his family to go to a few games a year. 

This started as a hobby for him with Yankee season tickets, but he has done an analysis and compared to what he would make investing that money in the market, he has come out way, way ahead.  He thinks that on a 12,500 investment, he makes about 40k!  That is not bad.  This year when all is said and done he will make six figure income from the resale of tickets he bought.  Think about it, no office or anything.  Just list your tickets and let people buy them.  Take some of the money and buy more tickets.

So what the heck am I doing trying to show people why it is important that they put good security in place on their computers?  There has got to be a better way.

Base Agent Functions

There is massive variation in the capabilities of different endpoint agents. Even for a single given function, there may be a dozen different approaches, all with varying degrees of success. Also, not all agents contain all features; in fact, most agents lack one or more major areas of functionality.

Agents include four generic layers/features:

1. Content Discovery: Scanning of stored content for policy violations.
2. File System Protection: Monitoring and enforcement of file operations as they occur (as opposed to discovery, which is scanning of content already written to media). Most often, this is used to prevent content from being written to portable media/USB. It’s also where tools hook in for automatic encryption or application of DRM rights.
3. Network Protection: Monitoring and enforcement of network operations. Provides protection similar to gateway DLP when a system is off the corporate network. Since most systems treat printing and faxing as a form of network traffic, this is where most print/fax protection can be enforced (the rest comes from special print/fax hooks).
4. GUI/Kernel Protection: A more generic category to cover data in use scenarios, such as cut/paste, application restrictions, and print screen.

Between these four categories we cover most of the day to day operations a user might perform that places content at risk. It hits our primary drivers from the last post- protecting data from portable storage, protecting systems off the corporate network, and supporting discovery on the endpoint. Most of the tools on the market start with file and (then) networking features before moving on to some of the more complex GUI/kernel functions.

Agent Content Awareness

Even if you have an endpoint with a quad-core processor and 8 GB of RAM, the odds are you don’t want to devote all of that horsepower to enforcing DLP.

Content analysis may be resource intensive, depending on the types of policies you are trying to enforce. Also, different agents have different enforcement capabilities which may or may not match up to their gateway counterparts. At a minimum, most endpoint tools support rules/regular expressions, some degree of partial document matching, and a whole lot of contextual analysis. Others support their entire repertoire of content analysis techniques, but you will likely have to tune policies to run on a more resource constrained endpoint.

Some tools rely on the central management server for aspects content analysis, to offload agent overhead. Rather than performing all analysis locally, they will ship content back to the server, then act on any results. This obviously isn’t ideal, since those policies can’t be enforced when the endpoint is off the enterprise network, and it will suck up a fair bit of bandwidth. But it does allow enforcement of policies that are otherwise totally unrealistic on an endpoint, such as database fingerprinting of a large enterprise DB.

One emerging option are policies that adapt based on endpoint location. For example, when you’re on the enterprise network most policies are enforced at the gateway. Once you access the Internet outside the corporate walls, a different set of policies are enforced. For example, you might use database fingerprinting (exact database matching) of the customer DB at the gateway when the laptop is in the office or on a (non split tunneled) VPN, but drop to a rule/regex for Social Security Numbers (or account numbers) for mobile workers. Sure, you’ll get more false positives, but you’re still able to protect your sensitive information while accounting for performance requirements.

Next up: more on the technology, followed by best practices for deployment and implementation.

Back in the saddle again. It’s a short week for both sides of the border here in North America. Happy post Canada Day to my brethren and a Happy (and approaching) July 4th to our cousins to the south.

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news…

1. 2600 HOPE conference bringing hacking to New York City (and we’ll see you there) | CNET
2. FBI Investigating Major ATM Hacking Ring | Las Vegas Now
3. Study: Unpatched Web Browsers Prevalent on the Internet | PC World
4. Netherlands man arrested for hacking 50,000 credit cards | Security Pro Portal
5. Vint Cerf Says Government Needs To Encourage Internet Competition | Information Week
6. The Government’s Top Hackers? | Veracode
7. HSBC sites vulnerable to XSS flaws, could aid phishing attacks | ZDNet
8. HMRC goes cap-in-hand to Americans for help with fraud | The Independent

Tags: News, Daily Links, Security Blog, Information Security, Security News

Over the next few posts we’re going to dig into endpoint DLP. I’ll start by discussing how I define it, and why I don’t generally recommend stand-alone endpoint DLP. I’ll talk about key features to look for, then focus on best practices for implementation.

It won’t come as any surprise that these posts are building up into another one of my whitepapers. This is about as transparent a research process as I can think of. And speaking of transparency, like most of my other papers this one is sponsored, but the content is completely objective (sponsors can suggest a topic, if it’s objective, but they don’t have input on the content).

Definition

As always, we need to start with our definition for DLP/CMP:

“Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis”.

Endpoint DLP helps manage all three parts of this problem. The first is protecting data at rest when it’s on the endpoint; or what we call content discovery (and I wrote up in great detail). Our primary goal is keeping track of sensitive data as it proliferates out to laptops, desktops, and even portable media. The second part, and the most difficult problem in DLP, is protecting data in use. This is a catch all term we use to describe DLP monitoring and protection of content as it’s used on a desktop- cut and paste, moving data in and out of applications, and even tying in with encryption and enterprise Document Rights Management (DRM). Finally, endpoint DLP provides data in motion protection for systems outside the purview of network DLP- such as a laptop out in the field.

Endpoint DLP is a little difficult to discuss since it’s one of the fastest changing areas in a rapidly evolving space. I don’t believe any single product has every little piece of functionality I’m going to talk about, so (at least where functionality is concerned) this series will lay out all the recommended options which you can then prioritize to meet your own needs.

Endpoint DLP Drivers

In the beginning of the DLP market we nearly always recommended organizations start with network DLP. A network tool allows you to protect both managed and unmanaged systems (like contractor laptops), and is typically easier to deploy in an enterprise (since you don’t have to muck with every desktop and server). It also has advantages in terms of the number and types of content protection policies you can deploy, how it integrates with email for workflow, and the scope of channels covered. During the DLP market’s the first few years, it was hard to even find a content-aware endpoint agent.

But customer demand for endpoint DLP quickly grew thanks to two major needs- content discovery on the endpoint, and the ability to prevent loss through USB storage devices. We continue to see basic USB blocking tools with absolutely no content awareness brand themselves as DLP. The first batches of endpoint DLP tools focused on exactly these problems- discovery and content-aware portable media/USB device control.

The next major driver for endpoint DLP is supporting network policies when a system is outside the corporate gateway. We all live in an increasingly mobile workforce where we need to support consistent policies no matter where someone is physically located, nor how they connect to the Internet.

Finally, we see some demand for deeper integration of DLP with how a user interacts with their system. In part, this is to support more intensive policies to reduce malicious loss of data. You might, for example, disallow certain content from moving into certain applications, like encryption. Some of these same kinds of hooks are used to limit cut/paste, print screen, and fax, or to enable more advanced security like automatic encryption or application of DRM rights.

The Full Suite Advantage

As we’ve already hinted, there are some limitations to endpoint only DLP solutions. The first is that they only protect managed systems where you can deploy an agent. If you’re worried about contractors on your network or you want protection in case someone tries to use a server to send data outside the walls, you’re out of luck. Also, because some content analysis policies are processor and memory intensive, it is problematic to get them running on resource-constrained endpoints. Finally, there are many discovery situations where you don’t want to deploy a local endpoint agent for your content analysis- e.g. when performing discovery on a major SAN.

Thus my bias towards full-suite solutions. Network DLP reduces losses on the enterprise network from both managed and unmanaged systems, and servers and workstations. Content discovery finds and protects stored data throughout the enterprise, while endpoint DLP protects systems that leave the network, and reduces risks across vectors that circumvent the network. It’s the combination of all these layers that provides the best overall risk reduction. All of this is managed through a single policy, workflow, and administration server; rather than forcing you to create different policies; for different channels and products, with different capabilities, workflow, and management.

In our next post we’ll discuss the technology and major features to look for, followed by posts on best practices for implementation.

Ted Morgan, the head of Skyhook, explained in an interview that while GPS is certainly the gold standard, and while it works well in stand-alone devices designed for continuous use and navigation, it's not the right choice by itself for mobile devices. It can take 5 or 10 minutes for a GPS-only device to get an accurate fix on the satellites it needs to give you accurate information. (Various shortcuts can provide less accurate information more quickly.)

"This notion of 'tell a user or consumer to stand outside for 30 seconds before they can search for the nearest pharmacy' is pretty silly," Morgan said. He noted that with all the radios now found in newer mobile devices, using several of them produces a fast and much more accurate result. The iPhone 3G, for instance, sports quad-band 2G, tri-band 3G, Bluetooth, Wi-Fi, and GPS chips.

Morgan said that A-GPS (assisted GPS) already combines cell tower information with GPS. A cell phone can be told approximately where it is, and thus instead of cycling through 24 satellites, start with the two that are most directly overhead. This can reduce the time to gain a location to as little as 20 seconds, Morgan said, although any kind of movement usually lengthens the time to 30 to 60 seconds.

Skyhook's system takes advantage of this aspect of A-GPS. They let a GPS system grab onto two satellites quickly to correct data from their Wi-Fi Position System (WPS). Morgan said that this reduces the WPS error by 35 to 40 percent through "weak fixes."

Within cities' concrete canyons, "you can only get a true GPS fix about 70 percent of the time outdoor, but you get two satellites all the time," Morgan said. "In the entire footprint, we're able to use this hybrid technology, even though GPS is only available 70 percent of the time." Outside of metro areas, cell towers can still be used to improve GPS startup times.

Skyhook has continued to expand its European coverage for WPS; they cover about 8,000 cities in the US and Canada, which is roughly 70 percent of the population; "it looks exactly like a cellular coverage map," Morgan said, and includes "any town with five streets in it."

In Europe, their current big push, partly because of their inclusion in the iPhone, they cover 70 percent of population in the current countries--the UK, France, and Germany--but they're now at 50 percent of the population of the rest of Western Europe. They're working assiduously in Japan, Korea, Hong Kong, and Australia as well, and looking into China and India. India has very little Wi-Fi, so they may rely more on cell towers there.

The company also announced a partnership with wireless chip maker CSR today, which is a major providers of Wi-Fi and Bluetooth chips to computer and handset makers. Nearly a year and a half ago, Skyhook partnered with SiRF, the dominant worldwide chip supplier for stand-alone GPS gear, that's also making a push into mobile devices. Skyhook obviously needs a win with a cell chip maker, like Infineon, Broadcom, or Qualcomm, given the XPS technology, to score a place in tens of millions of cell phones beyond the iPhone.

Skyhook's technology most recently appeared in a soon-to-ship model of the Eye-Fi--the Explore. The $130 Secure Digital card with Wi-Fi built in allows you to take pictures with any camera, and have the Wi-Fi signal space recorded for later lookup when you upload photos. The pictures are geotagged with that information. The card can optionally be used with Wayport's 10,000 strong Wi-Fi network in the U.S for $15 extra per month. David Pogue of The New York Times recently wrote up the Eye-Fi Explore.

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.

Respectfully,

jj

# # #

While NAC tools are often advertised as plug-and-play, GuideWorks found that the NAC setup required a high level of networking expertise. Fortunately, the Inglewood site had plenty of technical expertise because that’s where many of the company’s developers are stationed. In addition, GuideWorks put one of its front-desk employees in charge of setting up new accounts. But because her technical background was limited, the company had to walk her through a learning curve.

Now the company is planning to deploy the system at its Radnor office, which will be a bit more challenging since there’s less technical expertise there, and that office gets a greater number of visitors. So GuideWorks has been on the search for employees to support the NAC system there. The company expects to have NAC up and running there by the end of the summer.

So 2 years after trial they are rolled out in one office and have to hire employees to support the NAC system at the next office. This was a problem with many of the failed NAC companies over the last few years and I think the problem with this Tipping Point solution. Just providing guest access should not be that hard! Yes the StillSecure Safe Access solution would have been much easier and faster to implement, but to be fair, any of the leading NAC solutions would have been up and running easier as well.

While this article was supposed to serve as reference and case study for the Tipping Point NAC solution, it is far from inspiring. If I were a customer looking into NAC, I don't think this would make run out and look at the Tipping Point solution. Moral of the story is, just because you made a good IPS doesn't mean you have a very good NAC product. When it comes to something like NAC, quality counts and buying a 2nd tier solution can cost you in time to implementation and total cost of ownership.

Products that monitor all activity in a business application and database, identify and audit users and content, and, based on central policies, protect data based on content, context, and/or activity.

Browser Troubles

As we discussed in part 1, one of the biggest problems in web application security is that the very model of the web browsers and the World Wide Web is not conducive to current security needs. Browsers are the ultimate mashup tool- designed to take different bits from different places and seamlessly render them into a coherent whole. The first time I started serious web application programming (around 1995/96)this blew my mind. I was able to embed disparate systems in ways never before possible. And not only can we embed content within a browser, we can embed browsers within other content/applications. The main reason, as a developer, I converted from Netscape to IE was that Microsoft allowed IE to embed in other programs, which allowed us to drop it into our thick VR application. Netscape was stand alone only; seriously limiting it’s deployment potential.

This also makes life a royal pain on the security front where we often need some level of isolation. Sure, we have the same origin policy, but browsers and web programming have bloated well beyond what little security that provides. Same origin isn’t worthless, and is still an important tool, but there are just too many ways around it. Especially now that we all use tabbed browsers with a dozen windows open all the time. Browsers are also stateless by nature, no matter what AJAX trickery we use. XSS and CSRF, never mind some more sophisticated attacks, take full advantage of the weak browser/server trust models that result from these fundamental design issues.

In short, we can’t trust the browser, the browser can’t trust the server, and individual windows/tabs/sessions in the browser can’t trust each other. Fun stuff!

WAF Troubles

I’ve talked about WAFs before, and their very model is also fundamentally flawed. At least how we use WAFs today. The goal of a WAF is, like a firewall, to drop known bad traffic or only allow known good traffic. We’re trying to shield our web applications from known vulnerabilities, just like we use a regular firewall to block ports, protocols, sources, and destinations. Actually, a WAF is closer to IPS than it is to a stateful packet inspection firewall.

But web apps are complex beasts; every single one a custom application, with custom vulnerabilities. There’s no way a WAF knows the ins and outs of the application behind it, even after it’s well tuned. WAFs also only protect against certain categories of attacks- mostly some XSS and SQL injection. They don’t handle logic flaws, CSRF, or even all XSS. I was talking with a reference yesterday of one of the major WAFs, and he had no trouble slicing through it during their eval phase using some standard techniques.

To combat this, we’re seeing some new approaches. f5 and WhiteHat have partnered to feed the WAF specific vulnerability information from the application vulnerability assessment. Imperva just announced a similar approach, with a bunch of different partners.

These advances are great to see, but I think WAFs will also need to evolve in some different ways. I just don’t think the model of managing all this from the outside will work effectively enough.

Enter ADMP

The idea of ADMP is that we build a stack of interconnected security controls from the browser to the database. At all levels we both monitor activity and include enforcement controls. The goal is to start with browser session virtualization connected to a web application gateway/WAF. Then traffic hits the web server and web application server, both with internal instrumentation and anti-exploitation. Finally, transaction drop to the database, where they are again monitored and protected.

All of the components for this model exist today, so it’s not science fiction. We have browser session virtualization, WAFs, SSL-VPNs (that will make sense in a minute), application security services and application activity monitoring, and database activity monitoring. In addition to the pure defensive elements, we’ll also tie in to the applications at the design and code level through security services for adaptive authentication, transaction authentication, and other shared services (happy Dre? :) ). The key is that this will all be managed through a central console via consistent policies.

In my mind, this is the only thing that makes sense. We need to understand the applications and the databases that back them. We have to do something at the browser level since even proper parameterization and server side validation can’t meet all our needs. We have to start looking at transactions, business context and content rather than just packets and individual requests.

Point solutions at any particular layer have limited effectiveness. But if we stop looking at our web applications as pieces, and rather design security that addresses them as a whole, we’ll be in a lot better shape. Not that anything is perfect, but we’re looking at risk reduction, not risk elimination. A web application isn’t just a web server, just some J2EE code, or just a DB- it’s a collection of many elements working together to perform business transactions, and that’s how we need to look at them for effective security.

The Browser and Web Application Gateway

A little while back I wrote about the concept of browser session virtualization. To plagiarize myself and save a little writing time so I can get my behind to happy hour:

What we ideally need is a way to completely isolate our content in the browser. One way to do this is session virtualization, pioneered by GreenBorder, who was later acquired by Google (the GreenBorder site is just in support mode now). When a user connects to our site, we push down some code to create a virtual environment in the browser that we strictly control. We wall off that session, which could just be an isolated iFrame in a page, so that it only accesses content we send it. Basically, we break the normal browser model and hijack what we need. This would, for example, help stop CSRF since other browser elements won’t be able to trigger a connection to our application. Done right, it limits man in the middle attacks, even if the user authorizes a bad digital certificate.

To work properly, this needs to be tied to a gateway that controls the session. While we could do it from the web/app server itself, I suspect we’ll see this as a web application firewall feature, just as we see similar features from SSL-VPNs. I think isolated WAFs have a very limited lifespan, but this is exactly the kind of feature that will extend their value. Better yet, we can tie this in to our Application and Database Monitoring and Protection to build a browser-to-database protected path. We can completely track a transaction or piece of content from the database server to the browser and back.

We could even use this to isolate out potentially “bad” content in an in-browser sandbox. For example, it could be a way to enable all those social networking widgets in a more controlled way but locking in potentially bad content instead of known good.

Will this protect us from keystroke sniffers or a completely compromised host? Nope, but it will definitely help with a large number of our current browser security issues. If we combine it with full ADMP and additional methods like transaction authentication, I think we can regain a bit of control of the web application security mess.

Thus we see one migration path for a WAF. A user goes to connect to the application and hits the WAF, which is now more of a Web Application Gateway. The gateway, like an SSL-VPN sends the session virtualization code down to the browser. We do this outside of the web application for performance reasons. The secure, virtual session is established and the gateway then allows communications with the application behind it.

For things like retail and financial sites that include only limited third party content (if at all), we can monitor activity from the browser through to the application and work within the isolated session. It improves our ability to control both what’s being sent to the browser, and gives us a higher degree of assertion that what’s coming from the browser is safer. We still validate everything, but since we’re tied to the application itself we can validate in the browser and at the gateway before we even hit the app (and further validate there). Since, in a controlled environment, we know what transactions should be allowed or not we have greater ability to detect and block “bad” transactions from the user, like SQL injection.

In less controlled environments, thing MySpace or Gmail and everything in between, the gateway also becomes a filter for third party content. Like Checkpoint’s new ForceField. The gateway filters out, to the best of its ability, harmful third party content coming from third party sites. Basically, it becomes an SSL-VPN for secure browsing.

This is obviously not viable for all sites due to bandwidth considerations, and in those circumstances we’ll drop this part and stick to the rest of the ADMP stack, or only virtualize our pieces of content knowing the user is at risk for the third party stuff we’re still linking them to.

Future of the WAF, Option 2

I’ve just described a scenario where the WAF extends into a Secure Web Application Gateway that adds virtualization, encryption, and content filtering. That doesn’t mean WAFs won’t also still exist in non-virtualized situations, since that will still be a massive volume of sites out there.

For these sites the WAF continues to progress with deeper application integration and application understanding, and works with the elements I’ll describe later that will be embedded into the applications and databases. Rather than hanging around outside the application with barely any idea what’s going on behind it, the WAF will take it’s cues from the app, help manage sessions, and monitor activity outside the app to block the few things we know we can pick up at that layer.

Why use the WAF at all? To give us a chokepoint and offload some of the monitoring and processing that could hurt application performance. Let’s be honest, maybe it will eventually go away, but a performance problems alone will probably keep next-gen WAFs viable for a while. There are also plenty of things we can now block before they ever hit the application controls, which, by nature of being integrated at the app level, will be more complex and delicate.

But again, by tightly integrating with out other layers, instead of expecting that an external black box can solve our problems, we get a much higher level of functionality. Feeding in vulnerability data as we’re just starting to do is a good beginning, but once we plug in deeper to the application and database servers we’ll get entirely new levels of functionality.

Part 2 Conclusions

What I’ve described today is how we can build a (more) trusted path from the browser to the face of the application. WAFs will add gateway capabilities, both protecting the application behind them and the browser in front of them. SInce this won’t be the right approach in all circumstances, WAFs will also evolve with tighter integration to the application and other ADMP stack components.

Again, this might sound like little more than the usual analyst fiction, but all the components are here today. Also, I don’t expect my predictions to be totally accurate. I’m roughly guessing I’m at 85% or so.

Next week I’ll start digging in to the application and database. We’ll talk about application instrumentation, anti-exploitation, DAM, trusted transaction paths, and shared security services.