It's a cracking read and one I'd recommend to all insomniacs with an penchant for such topics, but I have to say, I'm actually pretty encouraged by what I read... ]]> Thu, 03 Jul 2008 14:00:00 +0000 hannigan report information security world government departments steps notably recommend insomniacs pan-emea special Why I welcome the Hannigan Report http://securityratty.com/article/bc45579c427facc15615cd04edd57ec7 http://securityratty.com/article/bc45579c427facc15615cd04edd57ec7 I’ve talked to some of the local crew, and we’ve decided to hold a special pre-BH/DefCon SunSec on July 31st (location TBD).

We’re going to take a bit of a different approach on this one. A while back, Vinnie, Andre, myself, and a couple of others sat around a table trying to think of how to jazz up SunSec a bit. As much as we enjoy hanging out and having beers, we recognize the Valley of the Sun is pretty darn big, and some of you need a little more than just alcohol to get you out of the house on a Wednesday of Thursday night.

We came up with the idea of the Phoenix Security Slam (PiSS for short). We’ll move to a venue where we can get a little private space, bring a projector, and have a little presentation free for all. Anyone who presents is limited to 10 minutes, followed by Q&A. Fast, to the point, and anything goes.

For this first run we’ll be a little less formal. I’ll bring my DefCon content, and Vinnie has some other materials to preview. I may also have some other good info about what’s going down in Vegas the next week, and I’ll share what I can. We’ll limit any formal presentation time to an hour, and make sure the bar is open before I blather.

If you’re in Phoenix, let me know what you think. If you’re also presenting at BH/DC and want to preview your content, let me know.

Also, we could use ideas for a location. Some restaurant where we can take over a back room is ideal.

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.

First off, GCN, come into the modern Web 2.0 era by letting people comment on your articles or at least allow trackbacks.  Having said that, let’s look at some of Mr Jackson’s points:

• NIST Special Publications: They’re good.  They’re free.  The only problem is that they’re burying us in them.  And oh yeah, SP 800-53A is finally final.
• Security and Vendors/Contractors:  It’s much harder than you might think.  If there’s interest, I’ll put out some presentations on it in my “copious amounts of free time”.  In the meantime, check out what I’ve said so far about outsourcing.
• Documentation and Paperwork:  Sadly, this is a fact of life for the Government.  The primary problem is the layers of oversight that the system owner and ISSO have.  When you are as heavily audited as the executive branch is, you tend to avoid risks and overdocument.  My personal theory is that the reason is insistence on compliance instead of risk management.
• Revising FISMA:  I’ve said it time and time again, the law is good and doesn’t need to be changed, the execution is the part that needs work.

Bookmark to:

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 decision 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 business 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 bit 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 appears we have to go back and fix everything we’ve built 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.

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.

The service uses a router that accepts SIM cards for authentication, but the backhaul is pure VoIP over Internet. Regular POTS (plain old telephone service) phones can be plugged into the router. The router is also compatible with HotSpot@Home (an additional $10/month), which allows unlimited domestic calling over Wi-Fi using special handsets from T-Mobile; there are now 8 handset models available. Customers have to have at least a $40 single-line or $50 family plan service to add either @Home or HotSpot@Home.

Probably the key remaining advantage for Vonage and other Internet telephony services that typically charge $20 to $30 per month for unlimited calling is that they include unlimited calls to any number in Canada or the U.S., not just the U.S., as well as unmetered calls to landlines in dozens of other countries in Europe as well as Australia. For those who regularly call outside the U.S., the @Home service would quickly become ridiculously expensive for its international tolls.