I spoke about CSRF attacks at Defcon a few months ago, and while I was there, I had the opportunity to meet with Justin Samuel, the creator of RequestPolicy. RequestPolicy is a Firefox extension designed to provide CSRF protection and enforce web application boundaries. I love it.

Request Policy completely breaks the web... in all the right ways. You'll initially hate using it. StumbleUpon links will no longer work, due to their use of cross-site iframes. Shortened bit.ly and tinyurl links will present you with an intermediate page instead of following 302 redirects. Deeplinked images on blogs, social networking sites, and other pages won't show up. You will have to manually approve off-domain requests on a case-by-case basis. It's not convenient, but it's a lot safer than letting your browser blindly request resources.

In short, RequestPolicy gives you granular control over your browser. If you know what you're doing, this is a good thing. If you're a normal user, you'll probably find yourself checking the "Temporarily Allow All Requests" box or disabling the extension completely. I can't say I'd blame you, but try not to. The extension is still very young in its development process, and most of the issues that I've run into are UI/usability problems. The developer is aware of many of these issues and working to fix them, but it's not easy. Samuel is very open to suggestions, feedback, and criticism, so if you have useful input, I'm sure he'd be happy to hear it- just hit the contact link on the extension's website.

The UI is heavily modeled after NoScript, so if you're a fan of that extension (and you should be), it isn't too difficult to figure out. Off-domain requests are disabled by default, and can be enabled on a per-site, as-needed basis. The preferences pane is simple and fairly easy to understand, allowing you to more easily manage your whitelist of allowed domains. Additionally, the extension ships with a setup wizard to create generic whitelists based on common sites (recaptcha, for example, has to be whitelisted for every domain that uses it). All in all, it's pretty easy to set up, and though it will break a lot of sites at first, as you fine tune the settings to your browsing habits, it really doesn't get in the way too much.

RequestPolicy was created for a very specific purpose: to give users the ability to better control their browsers and prevent CSRF. It's a bit rough at the moment, but it's very good at it.

--Mike Bailey

When I was at Hacker Halted recently, I watched a great talk by Ron Gula of Tenable. He brought up that most of the advice for IDS tuning is wrong. It's something I've been arguing for years, but haven't ever sat down to write out the main process by which I recommend to clients to reduce IDS noise.

First, I'm a big believer in the horrible damage caused by false positives. My view on the world was altered irrevocably in the early days of IDS by Stefan Axelsson's paper "The Base Rate Fallacy and its implications for the difficulty of Intrusion Detection". It consistently amazes me how few in our industry have read the paper. For those who aren't going to read the paper (and you really, really should), the message is simple: false negatives are annoying. False positives will quickly undermine the value of the IDS in any environment.

This isn't counter-intuitive, as the advice given by most IDS tuning guides is to eliminate the "false positive generating" signatures first. While this is good advice, we don't usually consider what is meant by a false positive.

There are two types of false positives. First, the signature that detects good traffic as inappropriate. This is what we're used to tuning out.

But these aren't the cause of most of the noise in most environments.

In most environments, we spend a lot of time dealing with the second type of false positive: the inappropriate traffic that is legitimately detected that we just don't care about. This corresponds to the risk tolerance of the organization where it comes to security events. In most organizations, that nmap is run is not a risk that the organization cares about. However, we tune these events out of our IDS far too infrequently "just in case it finds something".

It's the "just in case it finds something" that causes us to take too much data from our IDS and get overwhelmed with the noise.

Ask yourself... where are you allowing your IDS to alert on items that are below your risk tolerance? Why?

(This one's cross-posted from my blog over at Episteme.ca)

I had a blast last week at Hacker Halted last week, and I did a talk that I was incredibly excited about. It was the first time I was going to talk about some of the new research I’ve done and, while I didn’t plan to give out a huge number of details on the methods, I hoped that the talk was going to be well received.

Well, I’m sure that it would have been, had it actually finished. Because I didn’t read the program nearly closely enough, and I prepared a normal 80 minute talk, only to realize that my speaking slot was 45 minutes.

So, I only got about 1/2 way through my slides, and much of the meat was lost. A couple of audience members talked to me afterwards and seemed a bit disappointed, so I promised I’d provide the talk another way.

I do like to keep promises. So I sat down at my computer this morning and recorded the slides and the audio. The entirety of the talk that the audience would have seen is below.

The whole idea of the Certification & Accreditation (C&A for short) process within the government started out as a fundamentally sound plan.  Unfortunately, as everything began to unfold over time, it quickly changed into a convoluted and burdening process for any Information System Security Officer (ISSO).

Each agency is required to meet the controls that are adapted from the National Institute of Standards and Technology (NIST) Special Publications (SP) 800-53.  The issue is not necessarily in the controls that are required to be met but in the interpretations that are handed down to sub-agencies from their parent agency.  Not every sub-agency operates in the same manner but many times each parent agency treats all sub-agencies the same regardless of the function of the sub-agency.

Luckily, there is a solution that is easier said than implemented.  That solution is to allow the sub-agencies to adapt the NIST SP 800-53 controls to their specific environments then get approval for their adaptations from their parent agency.  Now, even though this solution is obviously not definitive nor is it fool-proof, it allows for the already existing C&A infrastructure to be used as seen fit but it also allows for the modifications as needed by the sub-agencies.

I'm not saying this would be an easy task but in the end the C&A process that started out so promising could once again be a good plan.

NOTE: This is not the only thing about the C&A process that needs work but keep checking back with us to find out what else could be done to better improve the process.