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

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?

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.