Information Security

Friday Summary: April 10, 2009

By Rich

–Rich

Selective Inverse Recency Bias In Security

By Rich

Nate Silver is one of those rare researchers with the uncanny ability to send your brain spinning off on unintended tangents totally unrelated to the work he's actually documenting. His work is fascinating more for its process than its conclusions, and often generates new introspections applicable to our own areas of expertise. Take this article in Esquire where he discusses the concept of recency bias as applied to financial risk assessments.

Recency bias is the tendency to skew data and analysis towards recent events. In the economic example he uses he compares the risk of a market crash in 2008 using data from the past 60 years vs. the past 20. The difference is staggering; from one major downturn every 8 years (using 60 years of data) vs. a downturn every 624 years (using only 20 years of data). As with all algorithms, input selection deeply skews output results, with the potential for cataclysmic conclusions.

In the information security industry I believe we just as frequently suffer from selective inverse recency bias- giving greater credence to historical data over more recent information, while editing out the anomalous events that should drive our analysis more than the steady state. Actually, I take that back, it isn't just information security, but safety and security in general, and it is likely of a deep evolutionary psychological origin. We cut out the bits and pieces we don't like, while pretending the world isn't changing.

Here's what I mean- in security we often tend to assume that what's worked in the past will continue to work in the future, even though the operating environment around us has completely changed. At the same time, we allow recency bias to intrude and selectively edit out our memories of negative incidents after some arbitrary time period. We assume what we've always done will always work, forgetting all those times it didn't work.

From an evolutionary psychology point of view (assuming you go in for that sort of thing) this makes perfect sense. For most of human history what worked for the past 10, 20, or 100 years still worked well for the next 10, 20, or 100 years. It's only relatively recently that the rate of change in society (our operating environment) accelerated to high levels of fluctuation in a single human lifetime. On the opposite side, we've likely evolved to overreact to short term threats over long term risks- I doubt many of our ancestors were the ones contemplating the best reaction to the tiger stalking them in the woods; our ancestors clearly got their asses out of there at least fast enough to procreate at some point.

We tend to ignore long term risks and environmental shifts, then overreact to short term incidents.

This is fairly pronounced in information security where we need to carefully balance historical data with our current environment. Over the long haul we can't forget historical incidents, yet we also can't assume that what worked yesterday will work tomorrow.

It's important to use the right historical data in general, and more recent data in specific. For example, we know major shifts in technology lead to major new security threats. We know that no matter how secure we feel, incidents still occur. We know that human behavior doesn't change, people will make mistakes, and are predictably unpredictable.

On the other hand, firewalls only stop a fraction of the threats we face, application security is now just as important as network security, and successful malware utilizes new distribution channels and propagation vectors.

Security is always a game of balance. We need to account for the past, without assuming its details are useful when defending against specific future threats.

–Rich

After Action Report: What Fortinet Should Do With IPLocks

By Rich

When Fortinet acquired parts of IPLocks it was a bit of a bittersweet moment. When I started my career as an analyst, IPLocks was the first vendor client I worked with. I was tasked with covering database security and spent a fair bit of time walking clients through methods of improving their database monitoring; mostly for security in those days, since auditors hadn't yet invaded the data center. It was all really manual, using things like triggers and stored procedures since native auditing sucked on every platform. After a few months of this I was connected with IPLocks- a small database security vendor with a tool to do exactly what I was trying to figure out how to do manually. They'd been around for a few years, but since everyone at this time thought database security was "encryption", they bounced around the market more than usual.

Over the next few years I watched as the Database Activity Monitoring market started to take off, with more clients and more vendors jumping into the mix. IPLocks always struggled, but I felt it was more business issues than technology issues. Needless to say, they had some leadership issues at the top.

Since I hired Adrian, their CTO until the sale to Fortinet, it isn't appropriate for me to comment on the acquisition itself. Rather, I want to talk about what this means to the DAM/ADMP market.

First up is that according to this press release, Fortinet acquired the vulnerability assessment technology, and is only licensing the activity monitoring technology. As we dig in, this is an important distinction. IPLocks is one of only two companies (the other being Application Security Inc.) with a dedicated database VA product. (Imperva and Guardium have VA capabilities, but not stand-alone commercial products). From that release, it looks like Fortinet has a broad license to use the monitoring technology, but doesn't own that IP.

Was this a smart acquisition? Maybe- it all depends on what Fortinet wants to do.

On the surface, the Fortinet/IPLocks deal doesn't make sense. The products are not well aligned, address different business problems, and Fortinet only owns part of the IP, with a license for the rest. But this is also an opportunity for Fortinet to grow their market and align themselves for future security needs. Should they use this as the catalyst to develop an ADMP product line, they will get value out of the acquisition. But if they fail to advance either through further acquisitions or internal development (with significant resources, and assuming their monitoring license allows) they just wasted their money. Sorry guys, now you need a WAF.

In the short term they need to learn the new market they just jumped into and refine/align the product to sell to their existing base. A lot of this will be positioning, sales training, and learning a new buying cycle. Threat management sales folks are generally unsuccessful at selling to the combined buying center focused on database security.

Then they need to build a long term strategy and extend the product into the ADMP space. There is a fair bit in their existing gateway technology base they can leverage as they add additional capabilities, but this is not just another blade on the UTM.

It's all in their hands. This isn't a slam dunk, but is definitely a good opportunity if they handle it right.

–Rich

Best Practices for Endpoint DLP: Part 3

By Rich

In our last post we discussed the core functions of an endpoint DLP tool. Today we're going to talk more about agent deployment, management, policy creation, enforcement workflow, and overall integration.

Agent Management

Agent management consists of two main functions- deployment and maintenance. On the deployment side, most tools today are designed to work with whatever workstation management tools your organization already uses. As with other software tools, you create a deployment package and then distribute it along with any other software updates. If you don't already have a software deployment tool, you'll want to look for an endpoint DLP tool that includes basic deployment capabilities. Since all endpoint DLP tools include central policy management, deployment is fairly straightforward. There's little need to customize packages based on user, group, or other variables beyond the location of the central management server.

The rest of the agent's lifecycle, aside from major updates, is controlled through the central management server. Agents should communicate regularly with the central server to receive policy updates and report incidents/activity. When the central management server is accessible, this should happen in near real time. When the endpoint is off the enterprise network (without VPN/remote access), the DLP tool will store violations locally in a secure repository that's encrypted and inaccessible to the user. The tool will then connect with the management server next time it's accessible, receiving policy updates and reporting activity. The management server should produce aging reports to help you identify endpoints which are out of date and need to be refreshed. Under some circumstances, the endpoint may be able to communicate remote violations through encrypted email or another secure mechanism from outside the corporate firewall.

Aside from content policy updates and activity reporting, there are a few other features that need central management. For content discovery, you'll need to control scanning schedule/frequency, and control bandwidth and performance (e.g., capping CPU usage). For real time monitoring and enforcement you'll also want performance controls, including limits on how much space is used to store policies and the local cache of incident information.

Once you set your base configuration, you shouldn't need to do much endpoint management directly. Things like enforcement actions are handled implicitly as part of policy, thus integrated into the main DLP policy interface.

Policy Creation and Workflow

Policy creation for endpoints should be fully integrated into your central DLP policy framework for consistent enforcement across data in motion, at rest, and in use. Policies are thus content focused, rather than location focused- another advantage of full suites over individual point products. In the policy management interface you first define the content to protect, then pick channels and enforcement actions (all, of course, tied to users/groups and context). For example, you might want to create a policy to protect customer account numbers. You'd start by creating a database fingerprinting policy pulling names and account numbers from the customer database; this is the content definition phase. Assuming you want the policy to apply equally to all employees, you then define network protective actions- e.g., blocking unencrypted emails with account numbers, blocking http and ftp traffic, and alerting on other channels where blocking isn't possible. For content discovery, quarantine any files with more than one account number that are not on a registered server. Then, for endpoints, restrict account numbers from unencrypted files, portable storage, or network communications when the user is off the corporate network, switching to a rules-based (regular expression) policy when access to the policy server isn't available.

In some cases you might need to design these as separate but related policies- for example, the database fingerprinting policy applies when the endpoint is on the network, and a simplified rules-based policy when the endpoint is remote.

Incident management should also be fully integrated into the overall DLP incident handling queue. Incidents appear in a single interface, and can be routed to handlers based on policy violated, user, severity, channel, or other criteria. Remember that DLP is focused on solving the business problem of protecting your information, and thus tends to require a dedicated workflow.

For endpoint DLP you'll need some additional information beyond network or non-endpoint discovery policies. Since some violations will occur when the system is off the network and unable to communicate with the central management server, "delayed notification" violations need to be appropriately stamped and prioritized in the management interface. You'd hate to miss the loss of your entire customer database because it showed up as a week-old incident when the sales laptop finally reconnected.

Otherwise, workflow is fully integrated into your main DLP solution, and any endpoint-specific actions are handled through the same mechanisms as discovery or network activity.

Integration

If you're running an endpoint only solution, an integrated user interface obviously isn't an issue. For full suite solutions, as we just discussed, policy creation, management, and incident workflow should be completely integrated with network and discovery policies.

Other endpoint management is typically a separate tab in the main interface, alongside management areas for discovery/storage management and network integration/management. While you want an integrated management interface, you don't want it so integrated that it becomes confusing or unwieldy to use.

In most DLP tools, content discovery is managed separately to define repositories and manage scanning schedules and performance. Endpoint DLP discovery should be included here, and allow you to specify device and user groups instead of having to manage endpoints individually.

That's about it for the technology side; in our next posts we'll look at best practices for deployment and management, and present a few generic use cases.

I realize I'm pretty biased towards full-suite solutions, and this is your chance to call me on it. If you disagree, please let me know in the comments...

–Rich

The Future Of Application And Database Security: Part 2, Browser To WAF/Gateway

By Rich

Since Friday is usually "trash" day (when you dump articles you don't expect anyone to read) I don't usually post anything major. But thanks to some unexpected work that hit yesterday, I wasn't able to get part 2 of this series out when I wanted to. If you can tear yourself away from those LOLCatz long enough, we're going to talk about web browsers, WAFs, and web application gateways. These are the first two components of Application and Database Monitoring and Protection (ADMP), which I define as:

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 be embedded in other programs, which allowed us to drop it into our thick VR application. Netscape was stand alone only; seriously limiting its 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 can know all 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, transactions 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 much 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 any, we can monitor activity from the browser through to the application and work within the isolated session. It both improves our ability to control what's being sent to the browser, and gives us a higher degree of confidence that what's coming from the browser is safe. 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 more ability to detect and block "bad" transactions like SQL injection from the user.

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 its 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 choke point and offload some of the monitoring and processing that could hurt application performance. Let's be honest- maybe WAFs will eventually go away, but 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 our other layers, instead of naievely assuming that an external black box will magically 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 applications behind them and the browsers 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 into the application and database. We'll talk about application instrumentation, anti-exploitation, DAM, trusted transaction paths, and shared security services.

–Rich

The Future Of Application And Database Security: Part 1, Setting The Stage

By Rich

I've been spending the past few weeks wandering around the country for various shows, speaking to some of the best and brightest in the world of application and database security. Heck, I even hired one of them. During some of my presentations I laid out my vision for where I believe application (especially web application) and database security are headed. I've hinted at it here on the blog, discussing the concepts of ADMP, the information-centric security lifecycle, and DAM, but it's long past time I detailed the big picture.

I'm not going to mess around and write these posts so they are accessible to the non-geeks out there. If you don't know what secure SDLC, DAM, SSL-VPN, WAF, and connection pooling mean, this isn't the series for you. That's not an insult, it's just that this would drag out to 20+ pages if I didn't assume a technical audience.

Will all of this play out exactly as I describe? No way in hell. If everything I predict is 100% correct I'm just predicting common knowledge. I'm shooting for a base level of 80% accuracy, with hopes I'm closer to 90%. But rather than issuing some proclamation from the mount, I'll detail why I think things are going where they are. You can make your own decisions as to my assumptions and the accuracy of the predictions that stem from them.

Also, apologies to Dre's friends and family. I know this will make his head explode, but that's a cost I'm willing to pay. Special thanks to Chris Hoff and the work we've been doing on disruptive innovation, since that model drives most of what I'm about to describe. Finally, this is just my personal opinion as to where things will go. Adrian is also doing some research on the concept of ADMP, and may not agree with everything I say. Yes, we're both Securosis, but when you're predicting uncertain futures no one can speak with absolute authority. (And, as Hoff says, no one can tell you you're wrong today).

Forces and Assumptions

Based on the work I've been doing with Hoff, I've started to model future predictions by analyzing current trends and disruptive innovations. Those innovations that force change, rather than ones that merely nudge us to steer slightly around some new curves. In the security world, these forces (disruptions) come from three angles- business innovation, threat innovation, and efficiency innovation. The businesses we support are innovating for competitive advantage, as are the bad guys. For both of them, it's all about increasing the top line. The last category is more internal- efficiency innovation to increase the bottom line. Here's how I see the forces we're dealing with today, in no particular order:

1. Web browsers are inherently insecure. The very model of the world wide web is to pull different bits from different places, and render them all in a single view through the browser. Images from over here, text from over here, and, using iframes, entire sites from yet someplace else. It's a powerful tool, and I'm not criticizing this model; it just is what it is. From a security standpoint, this makes our life more than a little difficult. Even with a strictly enforced same origin policy, it's impossible to completely prevent cross-site issues, especially when people keep multiple sessions to multiple sites open all at the same time. That's why we have XSS, CSRF, and related attacks. We are trying to build a trust model where one end can never be fully trusted.
2. We have a massive repository of insecure code that grows daily. I'm not placing the blame on bad programmers; many of the current vulnerabilities weren't well understood when much of this code was written. Even today, some of these issues are complex and not always easy to remediate. We are also discovering new vulnerability classes on a regular basis, requiring review and remediation on any existing code. We're talking millions of applications, never mind many millions of lines of code. Even the coding frameworks and tools themselves have vulnerabilities, as we just saw with the latest Ruby issues.
3. The volume of sensitive data that's accessible online grows daily. The Internet and web applications are powerful business tools. It only makes sense that we connect more of our business operations online, and thus more of our sensitive data and business operations are Internet accessible.
4. The bad guys know technology. Just as it took time for us to learn and adopt new technologies, the bad guys had to get up to speed. That window is closed, and we have knowledgeable attackers.
5. The bad guys have an economic infrastructure. Not only can they steal things, but they have a market to convert the bits to bucks. Pure economics give them viable business models that depend on generating losses for us.
6. Bad guys attack us to steal or assets (information) or hijack them to use against others (e.g., to launch a big XSS attack). They also sometimes attack us just to destroy our assets, but not often (less economic incentive, even for DoS blackmail).
7. Current security tools are not oriented to the right attack vectors. Even WAFs offer limited effectiveness since they are more tied to our network security models than our data/information-centric models.
8. We do not have the resources to clean up all existing code, and we can't guarantee future code, even using a secure SDLC, won't be vulnerable. This is probably my most contentious assumption, but most of the clients I work with just don't have the resources to completely clean what they do have, and even the best programmers will still make mistakes that slip through to production.
9. Code scanning tools and vulnerability analysis tools can't catch everything, and can't eliminate all false positives. They'll never catch logic flaws, and even if we had a perfect tool, the second a new vulnerability appeared we'd have to go back and fix everything we'd built up to that point.
10. We're relying on more and more code and web services developed by others. From machine-generated web applications, to frameworks and off-the-shelf web apps we customize, to mashups where we directly pass content generated by someone else to our users.
11. "Web applications" is a misnomer- we mean the entire stack: web servers, web application servers, the databases behind them, and all the various interconnected n tiers. Many of these are internally accessible, creating an additional vector for attack.

To rephrase these a bit:

1. Bad guys are focused on our web applications, and are intelligent and motivated.
2. We have a lot of insecure code, keep generating more, and can't rely on secure development to fix it all.
3. WAFs and code scanning help, but aren't enough.
4. We need to protect a big, complex stack including content and services outside our control.

Following these forces, I'm drawing some assumptions about what any solution needs to look like:

1. We need to include browser elements, but can't trust the browser.
2. We need to monitor and enforce at the transaction level, both for audibility and for logic flaws and other security issues.
3. Such monitoring and enforcement needs to run from the browser to the database.
4. Any solution needs to understand the application and database, not just layer over it.
5. We need to filter anything we pass on to the user.
6. We need to focus on protecting the information.

I'm not totally thrilled with how I've laid this out, but I think it's reasonably understandable. Tomorrow I'll walk through how I think the technology will develop, and where today's tools fit in. I suspect Adrian will start chiming in, once he gets off the road, with his own interpretations.

–Rich

When To Layer Encryption

By Rich

Sorry for the general lack of updates the past few days, but I managed to get sick while down in Mexico for a friend's wedding. No, not that kind of sick, just some flu I picked up from one of the many children running around. Aside from setting me back at work, it makes me a bit sad since my copy of Wii Fit showed up while we were gone and I've been too out of it to start my Nintendo-inspired workout regimen. Yeah, I'm just that geeky.

Enough of my personal life, let's talk encryption.

I used to joke about the client who once told me their management mandated "double encryption" on all financial information after a breach. In their case, they were encrypting their database and backup tapes. Not that there isn't a valid reason to encrypt databases and backup tapes, but the way they were implementing provided no additional security. Once those card numbers were encrypted in the DB, re-encrypting at the tape level added no value (this wasn't a case where they were encrypting the tapes to protect information not already encrypted).

But if we go back to the Three Laws of Encryption, there are circumstances where you might consider multiple layers. The most common case is encrypting for media protection, and simultaneously for separation of duties.

Full disk encryption is your best bet to protect yourself from information loss due to a lost or stolen laptop, but there are situations where FDE is not enough. It doesn't protect content from multiple users on a system- say the sensitive financials on the CFO's laptop from the lowly system administrator; nor does it protect content as it moves- say to a USB drive. File level encryption allows more granular control and protection in a wider range of circumstances. But since users are unreliable, and there are places (like virtual memory) where sensitive data can hide, file encryption doesn't obviate the need for FDE (or an FDE equivalent).

Thus file encryption is complementary to full drive encryption; each solves a different part of the data protection puzzle. With file encryption you can protect content as you move it off the laptop, protect it from other users (especially administrative users) on the same system, and encrypt data that's shared across a team using group keys.

Long term, file encryption will become more interesting as it combines with DLP. We are starting to see products that encrypt files based on their content, managed by central policies. Have something with a credit card number in it? It's automatically encrypted using a corporate key. While FDE doesn't need to pick and choose what to protect, over the long term file encryption (and DRM) will need to use content and context awareness to reduce the burden on users, comply with corporate policies, and improve the practicality of encryption.

–Rich

Information-Centric Security Tip: Know Your Users and Infrastructure

By Rich

I was on a client reference today learning about someone's DLP deployment, and it highlighted one of the biggest issues we often face when moving to an information-centric model. No, it's not a failure of content analysis techniques, data classification, or over-hyped tools, it's that we often don't even know who owns what, who's supposed to have access to what, or our own infrastructure.

I often start my data security/information-centric rants by mentioning you need to have good identity management in place, but I don't normally spend a whole lot of time talking about the details.

The truth is, this comes up all the time when I'm talking with end users who are implementing this stuff. Oftenthey don't have a good directory infrastructure, or one that reflects the org chart, and thus they can't do everything they want with their DLP, DAM, or other tools. Sometimes they don't even know where all their assets/servers are, or how to access them for scanning.

Thus the tip- if you have a good directory infrastructure that accurately reflects your organizational structure, you'll be in much better shape for any of these projects. Many of these tools can directly integrate with AD/LDAP, allowing you to build role-based policies.

You can't inform someone's manager they're sending customer lists home or running weird DB queries if you don't know who they work for.

–Rich

React Faster, And Better, With The A B Cs

By Rich

I've had a bit of a weird week. As I mentioned on Monday, I was driving to physical therapy (physio for my Australian and European friends) when there was an accident in front of me and I stopped to help out. Wednesday night I was coming home from PT and there was another accident right as I was going through the intersection.

This one was far more serious. As soon as I heard the smash and saw the impact out of the corner of my eye, I pulled into the median, hit my hazard lights, and called 9-1-1. One of the advantages of working in the field for so long is that you learn an economy of words to describe a complex situation in just a sentence or two of the crucial information. My first call was:

I'm on-scene of an injury accident at the corner of [x and y]. Two vehicles, with an unconscious unresponsive patient with a compromised airway. Patient is entrapped in the passenger side of the vehicle with access through the driver's side door. I'm a former paramedic and need to go manage her airway

There was a bit more jargon, but not much. The patient was unrestrained in the car with the airbag deployed, which probably meant she hit her head on the passenger window or strut since it was a side impact. There were a bunch of other bystanders and one came out and identified himself as a flight nurse. Her head was slumped over, which caused her difficulty breathing. The nurse jumped in the back of the car, we tilted her head to a normal position and stabilized her neck (one of the few times you're allowed to move the neck after an accident). Her breathing got better, and she slowly started waking up, but clearly had a head injury, which we reported to 9-1-1. The fire department showed up a few minutes later, we got out of the way, and she was being loaded into the chopper as I drove off.

That might be one of the only times I've stopped to help at an accident where my assistance may have mattered. Truth is, unless you're on the ambulance or have advanced equipment with you, the most useful thing you can do is calm the patient and make sure there isn't any more damage. The kinds of injuries you sustain in a major accident are rarely something even a highly trained bystander can help with. I didn't even bother evaluating anything more than her breathing, since nothing else mattered. All you EMTs can skip that full survey if you're helping as a bystander in an urban area.

In this case her head position was keeping her from breathing well, making the situation worse. Just moving it so she could breathe more normally might have oxygenated her noggin a bit more and helped her wake up.

Why the heck am I talking about this on a security geek blog?

Because it's one of those times where there are direct lessons we can apply to our world, and often forget.

I'm a big fan of Rothman's philosophy of REACT FASTER. The idea is that it's more about how you respond to an incident than having the incident in the first place. Truth is in IT, as in life, bad stuff will happen no matter what you do. Systems will crash, hard drives will die, and hackers will break in. David Mortman is one of the other major proponents of this philosophy- incident response is just as important, if not more important, than incident prevention. That's why I'm adding REACT BETTER.

Emergency services are just like programming- a series of algorithms in a structured program flow. It all comes down to the A B Cs- Airway, Breathing, Circulation- in meat-space. Patient have any airway? Nope? Then nothing else matters until you fix that. Breathing? Check. Circulation okay? Then move on to spinal immobilization. It's a recognition that you can't jump from A to C and expect success. It's exactly what we did to help that girl in the car, rather than focusing on the blood or other distractions.

Don't just react- have a response plan with specific steps you don't jump over until they're complete. Take the most critical thing first, fix it, move to the next, and so on until you're done. Evaluate, prioritize, contain, fix, and clean. (You OODA fans should love this).

And always remember the loudest patient is rarely the most important. If they're screaming their head off, their airway is fine. It's the quiet ones you have to watch out for.

–Rich

Best Practices For DLP Content Discovery: Part 3

By Rich

In Part 3 of our series we finished our review of the technical architecture and selection; now we're going to delve into best practices for deployment. We will focus on setting expectations, prioritization, and defining your internal processes. The main obstacle to successful deployments isn't a technology weakness, but rather the failure of the enterprise to understand what to protect, decide how to protect it, and recognize what's reasonable in a real-world environment.

Setting Expectations

The single most important factor for any successful DLP deployment -- content discovery or otherwise -- is properly setting expectations at the start of the project. DLP tools are powerful, but far from a magic bullet or black box that makes all data completely secure. When setting expectations you need to pull key stakeholders together in a single room and define what's achievable with your solution. All discussion at this point assumes you've already selected a tool. Some of these practices deliberately overlap steps during the selection process since at this point you'll have a much clearer understanding of the capabilities of your chosen tool.

In this phase, you discuss and define the following:

1. What kinds of content you can protect, based on the content analysis capabilities of your tool.
2. Expected accuracy rates for those different kinds of content; for example, you'll have a much higher false positive rate with statistical/conceptual techniques than partial document or database matching.
3. Protection options: Can you encrypt? Move files? Change access controls?
4. Performance, based on scanning techniques.
5. How much of the infrastructure you'd like to cover (which servers, endpoints, and other storage repositories).
6. Scanning frequency (days? hours? near continuous?).
7. Reporting and workflow capabilities.

It's extremely important to start defining a phased implementation. It's completely unrealistic to expect to monitor every nook and cranny of your infrastructure with your initial rollout. Nearly every organization finds they are more successful with a controlled, staged rollout that slowly expands breadth of infrastructure coverage and types of content to protect.

Prioritization

If you haven't already prioritized your information during the selection process, you need to pull all major stakeholders together (business units, legal, compliance, security, IT, HR, etc.) and determine which kinds of information are more important, and which to protect first. I recommend you first rank major information types (e.g., customer PII, employee PII, engineering plans, corporate financials), then re-order them based on priority for monitoring/protecting within your DLP content discovery tool.

In an ideal world your prioritization should directly align with the order of protection, but while some data might be more important to the organization (engineering plans) other data may need to be protected first due to exposure or regulatory requirements (PII). You'll also need to tweak the order based on the capabilities of your tool.

After your prioritize information types to protect, run through and determine approximate timelines for deploying content policies for each type. Be realistic, and understand that you'll need to both tune new policies and leave time for the organizational to become comfortable with any required business changes.

We'll look further at how to roll out policies and what to expect in terms of deployment times later in this series.

Define Process

DLP tools are, by their very nature, intrusive. Not in terms of breaking things, but intrusive in terms of the depth and breadth of what they find. Organizations are strongly advised to define their business processes for dealing with DLP policy creation and violations before turning on the tools. Here's a sample of a process for defining new policies:

1. Business unit requests policy from DLP team to protect content type.
2. DLP team meets with business unit to determine goals and protection requirements.
3. DLP team engages with legal/compliance to determine any legal or contractual requirements or limitations.
4. DLP team defines draft policy.
5. Draft policy tested in monitoring (alert only) mode without full workflow and tuned to acceptable accuracy.
6. DLP team defines workflow for selected policy.
7. DLP team reviews final policy and workflow with business unit to confirm needs have been met.
8. Appropriate business units notified of new policy and any required changes in business processes.
9. Policy deployed in production environment in monitoring mode, but will full workflow enabled.
10. Protection certified as stable.
11. Protection/enforcement actions enabled.

And here's one for policy violations:

1. Violation detected; appears in incident handling queue.
2. Incident handler confirms incident and severity.
3. If action required, incident handler escalates and opens investigation.
4. Business unit contact for triggered policy notified.
5. Incident evaluated.
6. Protective actions taken.
7. If file moved/protected, notify user and drop placeholder file with contact information.
8. Notify employee manager and HR if corrective actions required.
9. Perform required employee education.
10. Close incident.

These are, of course, just rough samples in text form, but they should give you a good idea of where to start.

–Rich

Data Classification Is Dead

By Rich

I know what's running through your head right now.

"WTF?!? Mogull's totally lost it. Isn't he that data/information-centric security dude?"

Yes I am (the info-centric guy, not the insane bit), and here's the thing:

The concept that you can run around, analyze, and tag your data throughout the enterprise, then keep it current through changing business contexts and requirements, is totally ridiculous. Sure, we have tools today that can scan our environment and tag files based on policies, but that just applies a static classification in a dynamic environment. I have yet to talk with a customer that really does enterprise-wide data classification successfully except for a few, discrete bits of data (like credit card numbers). The truth is that's data identification, not data classification.

Enterprise content is just too volatile for static tags to really represent its value.

Even those of you in defense/intelligence don't really do granular data classification. You just hit things with a big sledgehammer. "Is it Top Secret? Then we keep it totally isolated. What, this bit isn't Top Secret but it's on a Top Secret server? Frack it, we'll just make it all Top Secret and be done with it. Need to pull it out? Go fill out this form."

This post was inspired by a conversation yesterday where another information-centric wonk criticized the idea that data can be self-describing in any meaningful way, part of my principles of information centric security. While he caught the first point, he missed my meaning in the second point (policies and controls must account for business context) which means that the data self describes in such a way that business context can then be applied to determine value in that situation. I know it sounds like science fiction, but we're starting to see real-world scenarios, and I'll be the first to admit this is going to be a big area of advance over the next few years.

Now there is one piece of data classification that isn't dead (I like sensational headlines just like the next person). That's the business process of prioritizing information. That's where you sit down with business executives and determine what information is more valuable than other information for your organization. It will drive all the protective strategies and dynamic protections we talk about when applying information-centric security. That's absolutely vital to successful information security.

Thus we prioritize and identify information, but this is different than data classification, which is the concept that after these two steps, we can apply static labels as a way of protecting information.

That, my friend, is not only dead, it was never really alive.

–Rich