The Lens

Security Through Obscurity and the TSA

Wed, 09 Dec 2009 08:11:15 -0800

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

Vulnerability Management Panel Discussion

Mon, 27 Jul 2009 07:13:46 -0800

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.

Mild mannered company by day ...

Thu, 23 Apr 2009 07:37:24 -0800

... 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.

Web Applications: The Biggest Risk to the Enterprise

Tue, 21 Apr 2009 20:34:31 -0800

(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.

Hello Old Friend Moscone

Tue, 21 Apr 2009 07:15:14 -0800

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.

PCI and Politics

Fri, 13 Mar 2009 08:54:18 -0800

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.

Next Step for Data Breach Laws

Sun, 08 Mar 2009 17:53:22 -0800

California pioneered laws around data breach disclosure with SB-1386, requiring that companies inform consumers when their data has been compromised. Now, state senator Joe Simitian wants to update the law with SB-20. The primary change is greater specificity around what information must be included in the notifications, and a requirement that breaches of a certain size generate notification to the state attorney general. While these are largely good changes, I still think the law misses the one question that most consumers really want answered when their data has been compromised: What should I do about it? Of course, that's a hard question to answer, so it's not surprising that it hasn't been adequately tackled.

Study finds you have a problem our product solves!

Tue, 03 Mar 2009 16:25:26 -0800

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.

Web application security isn't just about web applications

Fri, 27 Feb 2009 13:11:32 -0800

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.

PCI Compliance Podcast at Practical eCommerce

Thu, 26 Feb 2009 07:04:55 -0800

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.

iPhone 2.0 is Less Secure

Tue, 10 Jun 2008 13:13:31 -0800

There's nothing quite as effective for illustrating a point than a top n list. Here are the top 4 reasons that the new iPhone is less secure than the previous version.

4. The Price

How could the price make the product less secure? Very simply, the more ubiquitous a platform, the more attractive a target it is. By lowering the price in order to increase market-share, Apple is creating a more attractive base of targets.

3. The SDK

Complexity breeds insecurity. The addition of third party code creates an avenue for exploit. Apple can work to minimize that, but there's a choice of functionality over security here. After all, not shipping the product at all would be very secure.

2. MS Office Compatibility

Do you remember MS08-026? How about MS07-044? Well, welcome to the world of remote code execution via MS Office Documents, little iPhone.

1. Enterprise-Ready

If the price of the iPhone increases its attractiveness as a target due to volume, then being enterprise-ready increases its attractiveness due to value. All the things about other enterprise computing devices that attackers love will now be present in the iPhone. Along with that comes a whole new world of exciting hackability. Who wouldn't want to break into it and see what juicy data the CEO is storing there?

A Virtual Advantage

Wed, 28 May 2008 10:24:25 -0800

First, the article.

Second, the salient quote so that you don't really have to read said article:

"If you are getting any benefit from Microsoft's software, you need to have a license, whether that benefit is for physical machines or virtual machines," Voce said in a session titled "Microsoft Licensing in a Virtual World." "You cannot engineer your way around licensing requirements. You can't use the technology as a way to cut corners around licensing."

The question I find myself asking is whether virtualization diminishes the perceived value of the operating system. As I deploy more virtual servers to do more specialized tasks, along with the very useful MTTR benefits of full VM snapshots, the relative value of the OS in that asset decreases. In fact, if I could have a purpose built OS that's completely built around executing the application function I require. Wouldn't that be far better than loading up a full, bloated, operating environment? In this equation, the value of that virtual appliance model far outweighs the value of the separate OS+Application model of the past. In fact, you might even be willing to pay more for the cost of ownership benefits of the virtual appliance (more for less, so to speak).

That's all well and good to think about, but what's the security angle (I hear you saying). Well, ubiquity breeds risk. A larger pool of targets is more attractive. 100,000 Windows based VMs is just as attractive a target as 100,000 physical servers. Purpose built virtual appliances, however, would increase the diversity of the target population. Further, they're purpose built, and we all know that increased complexity results in more bugs (aka, vulnerabilities). What I'm suggesting here, I suppose, is that the open-source community should figure this out before Microsoft because right now there's a clear financial advantage to using a free (as in beer) OS for your multitude of virtual images.

Secure360 Conference

Mon, 12 May 2008 10:00:46 -0800

I'm headed to the Secure360 Conference in St. Paul tomorrow and Wednesday. Despite the name, it doesn't have anything in particular to do with IP360 or nCircle. I attended this show last year and it was pretty valuable if you're part of the Twin Cities InfoSec community. Here are the sessions that look interesting to me and why:

Christopher Buse
Chief Information Security Officer, Office of Enterprise Technology, State of Minnesota
Building An Enterprise Security Program

In some ways, federal and state agencies are like large enterprises where the same problems are just harder to solve. You have more bureaucracy and no profit motive, which makes for some interesting challenges.

Anton Chuvakin
Chief Logging Evangelist, LogLogic, Inc
Application Logging 'Worst Practices'

This just sounds like fun.

Jay Cline
President, Minnesota Privacy Consultants
Project Plan for Data Inventorying and Mapping

Identifying and mapping sensitive data within an organization is a huge challenge. I'll be interested to see if Jay has any novel approaches.

Jenny Geisler
Principal Consultant
Governance and Ethics: An Overview

This has the potential to either be very very interesting or give me a chance to catch up on some sleep. There are some difficult questions to explore with governance and ethics, but you could easily have a presentation of the same title that studiously avoids all of them.

Ray Kaplan
Principal Consultant, Ray Kaplan & Associates
Spreadsheets From Hell - Measurements to Metrics

I'd rather see this presentation from a non-consultant, but it still has the potential to be informative.

Brent Lassi
Director of Security, Digital River, Inc.
Building a Culture of Security

It was this part of the description that got me, "resulting in a viral spread of security knowledge." Tapping into the socio-cultural mechanisms within an organization is a great way to get knowledge distributed.

Seth Peter
CTO, NetSPI
Payment Card Industry Data Security Standards Update

Always keeping up to date on PCI.

Gunnar Peterson
Managing Principal, Arctec Group
Building a Security Architecture Blueprint - A Strategic Approach to Enterprise Security

There's enough overlap here with Chris Buse's earlier presentation that I'll be interested to see how they compare.

Well, those are the sessions that caught my eye on the first pass through the agenda. I haven't checked out the schedule, so I've got no idea if I can actually attend them all. Maybe I'll see you there.

It's Not Always About You

Wed, 02 Apr 2008 07:07:32 -0800

Earlier this week, someone asked me this question:

"What should the PCI Council be working on next to protect card holder data?"

I thought about this for a while, and decided that the only honest answer is nothing.

I will acknowledge up front that the PCI DSS is lacking in a number of ways, that it could be changed to better protect card holder data and that even a fully compliant merchant still puts card holder data at risk. I'll also ask this question, fair minded reader: Who cares?

As one who holds a few cards, I care. A merchant who wants my business *might* care, but only if they think that the strength of my conviction is such that I might not shop there. The PCI Council is the furthest from caring in this chain, and the successful adoption of the PCI DSS will only make them care less. How so? Well, it's all about revenue and liability.

The PCI Council represents the card companies, who are *gasp* in it for the money. For them, card holder data theft is a liability. It hurts their bottom line if they have to pay out and it hurts their bottom line if card holders don't use their cards. In other words, they can't make themselves liable and they can't make the card holder's liable; neither option is viable for their business. The PCI DSS allows them to place liability at the merchant, which is largely appropriate given their relationship to the card data.

The PCI DSS protects two ways:

Basically, the merchant chooses one of two states: Compliant or Non-Compliant. If they're compliant, then they're less likely to have a breach and compliance can also instill card holder confidence. If they're non-compliant, then they're electing to take on the risk and liability of any breach that occurs. In either circumstance, the card companies have successfully limited their liability.

Hannaford, Hannaford, Hannaford. I know what you're thinking. What about a compliant merchant that experiences a breach?! Well, here's the test. Theoretically, Hannaford shouldn't be liable. I'd argue that it's in the card companies best interest to pay out in this case. They solidify the positioning of PCI and probably increase adoption by merchants too. We'll just have to wait and see how it plays out.

But I Egress...

Mon, 31 Mar 2008 05:20:50 -0800

We're often so focused on who is getting into our infrastructure that we forget about who or what might be getting out. It's a natural tendency, of course, given the focus that InfoSec has traditionally had, and given that we still have the problem of people getting in. There's a quote at the end of this article about the Hannaford breach:

"Clearly, there was a pathway back out of the network that Hannaford should have closed,"

How many organizations implicitly trust outbound connections from their own servers? How many organizations inspect the content and patterns of outbound connections? In this case, Hannaford might have seen correlation between credit cards being processed and a connection out to "an overseas destination," or at least an unexplained outbound connection to that destination on a regular basis.

Having just watched Ocean's 11 last night, I'm reminded that overcoming the challenge of getting into the vault is worthless if you can't manage to get out with the cash.