ABC news reports today that the TSA screening manual was accidentally posted online with formerly redacted information included.

"This is an appalling and astounding breach of security that terrorists could easily exploit," said Clark Kent Ervin, the former inspector general at the Department of Homeland Security.

It's not hard to conceive of why this is considered a breach, but it really should be. As [information] security professionals it should be extremely hard to understand why the TSA would create a screening process that relies on maintaining the secrecy of the process itself to be effective. First of all, it's very nature (a process that all screeners must follow) means that it's not a secret: all of the screeners know the process by definition. I'm willing to bet that this public disclosure isn't the first disclosure. Somewhere out there is a screener who made a tidy profit selling this very document. And the TSA should have expected that. All that this incident does is level the playing field between the bad guys (who already knew all of this) and Joe Businessman who doesn't want to miss his flight.

In fact, the TSA should have published the process in its entirety publicly to begin with.

One of the points in this article is that the data leaked included instructions for identifying CIA, ATF, and members of congress for alternate screening or no screening at all. First, if I'm a capable terrorist, you've got to assume I can reasonably (visually) replicate these credentials already. Until you have some cryptographically secure ID for these individuals, it's just a given. Secondly, a screening process that has a loophole better ensure that the identification to use that loophole is well secured. But let's give the TSA a little more credit than ABC news does. In fact, if you dig into the document, you'll find that armed Law Enforcement Officers (LEOs) are required to pre-authenticate via a secure network: "they will now obtain a unique identifier code from the TSA via a secure law enforcement network." You can't just walk up to the checkpoint, present an ID and board a flight while armed.

The article also points out that this manual contains a list of items that do not need to be screened, i.e. where to hide things from the TSA. This is a list that could be reasonably assembled by just about anyone who travels frequently. It's a list that can be obtained through observation, and as such it's already not a secret.

I think we all know that the existing airport screenings are minimally effective. Bruce Schneier has some nice pieces on how we might improve them. In the end, the only shocking thing about this breach is that it might have any effect on actual security whatsoever.

The TSA Screening Manual

Images of Credentials

WhitehatWorld organized this vulnerability management thought leaders panel discussion. I was lucky enough to participate as a panelist. You can listen to the recording here.

... superheros by night, or trade show at least. These guys were close enough to our booth that I managed a snapshot. I'm sure I wasn't the only one, given how proficient they were at striking this pose. I wonder what their super powers are.

(This post is a taste of my presentation at the nCircle booth at RSA. Come by and see it if this is interesting).

Web application risk is a hot topic these days, but there's something missing from the discussion. Vendors seem to be focused on addressing web application risk in a vacuum. They limit their marketing and products to custom web applications and ignore two things: vendor supplied web applications and what I'll call the dependency risk of web applications.

When you choose to deploy a web application, you're deploying much more than just that web app. There is, of course, the web application itself.

Whether it's custom built or vendor supplied, the web application can be vulnerable to things like cross-site scripting, SQL injection or cross-site request forgery. Think about all the products you've deployed that are managed via a web interface. They're all potential sources of web application risk. But the risk doesn't stop there. That web application has to run on some kind of HTTP server.

The web server itself can be vulnerable to buffer overflows, directory traversal, cross-site scripting (again) and other conditions. But wait, there's more. That web server has to run on some platform, whether hardware or virtual, you've got an execution space that can also be vulnerable. There are a near infinite number of vulnerabilities that might exist on the OS or other applications running the web server itself.

Finally, there's likely a database somewhere on the back-end. It may have sensitive data or may be vulnerable itself or may run on yet another vulnerable platform.

The point here is that scanning just your customer-built web applications or scanning them with a completely separate tool just doesn't cover the whole problem. You can't make good risk mitigation decisions without a clear view of the entire risk context.

I'm lucky enough to get to San Francisco more than once a year, but for many folks the RSA conference is an annual trek. There are probably a few missing out this year because of restricted travel budgets as well. I walked around about half the show floor last night and didn't see anything outstanding, but there's time yet. I have to say, RSA is the most fun when there are big announcements. Somehow I don't think this is the year for big announcements, but I could be wrong. Heck, continued growth and profitability aren't to be sneezed at these days. In fact, they're downright awesome.

Whether you're a customer, colleague, partner or prospect, stop by the booth and say hello this week.

Did you donate to Norm Coleman? Well, your credit card and donor information has been floating around the dark side of the internet. Wikileaks has published evidence of the data breach. The Minneapolis Star-Tribune has a piece on how Coleman may have violated the law by not notifying donors who were compromised.

But this article misses an important point, or rather only touches on it in a single paragraph. Seth Peter, CTO at NetSPI, points out that "[t]he same rigor that a financial institution or big box retailer puts into their credit card collection needs to be replicated on a smaller scale."

How should/does PCI handle 'retailers' who aren't permanent? We don't know for sure how the Coleman campaign processed transactions, but we do know that they were storing card data that PCI requires you not store (security codes). It's not just PCI that makes this requirement, however, but Minnesota state law (H.F. 1758).

In other words, the Coleman campaign possibly violated the law by not notifying donors of compromised data, may be in violation of PCI (with fines?) by storing the data insecurely, and likely violated the law by storing the data for more than 48 hours after the transaction.

That being said, and left to law enforcement, we're left with a question of how PCI deals with transient retailers. The Coleman campaign (though existing longer than most) isn't a permanent retailer, so the PCI lifecycle can't really apply. What does it mean to get an annual audit if you don't exist for the whole year? What would the 2009 QSA audit for Coleman's campaign look like if it's conducted in December? What about ASV scans?

Yet, at the same time that risk might be reduced by the limited duration of the 'retailer,' entities like political campaigns present a higher risk of compromise. Here are a few things that PCI could do to deal with these situations:

1. Define a merchant tier for ephemeral entities

2. Require that they get audited by a QSA prior to starting processing or that they *completely* outsource the processing operations.

3. Require that they get an ASV scan prior to and during their operating period.

These three things can bring them into compliance and reduce risk using existing PCI mechanisms on a tighter time scale.

You have to love a study run by a vendor where the results clearly demonstrate a problem that very vendor solves. What a pleasant surprise!

Sarcasm aside, Damballa concluded that anti-virus misses a whole bunch of malware. We've seen this conclusion before. Their opinion is that they can protect you from your own compromised machines with their product.

When I read about these sorts of reactive technologies, I have a mixed response. Responding to the fire *is* important, but preventing the fire is always more important. I'm surprised that the industry continues to come up with new reactive technologies.

More Than 500,000 Websites Hit By New Form Of SQL Injection In '08

It's new because it's automated and run from botnets. I'm not sure that really counts as a "new form of SQL injection," but I won't quibble. This paragraph isn't about SQL injection, but is noteworthy:

"While the initial attack vector was SQL Injection, the overall attack more closely resembles a Cross-Site Scripting methodology as the end goal of the attack was to have malicious JavaScript execute within victims' browsers," the WHID reports says. "The JavaScript calls up remote malicious code that attempts to exploit various known browser flaws to install Trojans and Keyloggers in order to steal login credentials to other web applications."

The point that's interesting here is that browser vulnerabilities are the real target. We may be talking about the rise in web application attacks, but they're actually targeted at the users of those web applications. We may all scoff a little at Microsoft's monthly IE roll-up bulletin, but perhaps we should scoff just a little less next month.

There's a short interview I did on PCI compliance over at Practical eCommerce. It's about fees that merchant account providers are charging their merchants. Although not part of the interview, these fees are clearly part of the distributive nature of a regulation like PCI. In the end, the liability that the card brands previously held in its entirety is being distributed all the way down to the merchants themselves.