Boaz Gelbord

Comodo, RSA, and Security Priorities

noreply@blogger.com (Boaz Gelbord) — Wed, 30 Mar 2011 02:38:00 +0000

More details are coming in on the Comodo digital certificate hack by an Iranian hacker. The young man apparently exploited the use of plaintext usernames and passwords in a generally vulnerable certificate issuing system.

Coming on the heels of the recent RSA SecurID breach, it has been a bad last couple of weeks for security vendors in general, and for both the SSL certificate and two-factor authentication hardware token businesses in particular. But RSA's pain is likely to be more acute. The SSL certificate business is unlikely to suffer in the long term. Websites need certificates, even if they don't guarantee security. Folks might move away from Comodo in the short term, but even that seems unlikely given the small-time nature of a certificate purchase. SSL certificates are mostly viewed as a commodity, and price is the main differentiator.

But the hardware token business could be in for some rough times ahead. SecurID is at the end of the day a discretionary purchase based on a desire to have the gold-standard of security. It is the security equivalent of a luxury good. But you wouldn't buy a BMW if you thought it was just as prone to accidents as the Toyota down the street. If RSA SecurID doesn't provide a concrete measure of added, or at least perceived, security, CIOs will be reluctant to pay the premium that hardware solutions naturally command.

RSA's vague pronouncements about "Advanced Persistent Threats" might have done more harm than good. There may be some mitigating law enforcement issues we don't know about that are preventing RSA from really coming clean. But APT is all-too often used as a code word for stuff-we-can't-really-do-anything-about. Which is fair enough of course; RSA can genuinely make the case that they've sold security products for a long time, but everything is breakable and stuff happens.

The security of RSA's SecurID system was always a combination of the strength of their underlying algorithms combined with the strength of their underlying operations and environment. Ditto with the Comodo situation - the security of SSL certs is dependent on many factors and the difficulty of factoring the products of large prime numbers is way down the list. Comodo is a business, and in businesses significant numbers of people need access to significant amounts of sensitive data. Invariably there will be screw-ups in how those people handle those responsibilities. This time it seems like an Italian reseller was partially to blame.

But this raises the larger question of whether particularly sophisticated and expensive security products are justified when most organizations face threats that are far most basic. In other words, the recent Comodo and RSA hacks ironically underscore the point that SecurID tokens are somewhat of a Maginot line for many organizations where other much more immediate threats are present.

The way Comodo was hacked is particularly illustrative of this phenomena. The reseller credentials were apparently sitting around in plaintext (or at least that's what the Iranian hacker taking responsibility for the attack claims). Most businesses, and especially businesses that live primarily in the cloud, have web front-ends to critical data that do not involve two-factor authentication. This might be a Salesforce account, Google Docs, an administrative console to a CMS like Drupal, or whatever. And many web 2.0 businesses live in shared hosting or VPS environments where the root credentials to their accounts actually live in plaintext in the host's servers, often visible by anyone in support. Using two-factor authentication in this kind of environment strictly to increase the general level of security rarely makes economic sense.

It's hard to say if RSA or Comodo will suffer any lasting damage from these attacks. For the vast majority of businesses, the ease of implementation and integration of a two-factor authentication solution trumps abstract concerns about the system's hackability. And SecurID's large library of clients and authentication agents is in itself a security feature; a competing product with a smaller number of clients introduces new threats, since you have to either cobble together your own code (almost always a bad idea) or you end up with some of your systems not covered.

The Rise and Fall of Hardware Tokens?

One primary beneficiary of SecurID's troubles could be competing vendors who offer two-factor solutions that do not rely on actual hardware tokens. CA has quickly gotten on the bandwagon and is offering to switch out SecurID tokens with its own ArcotID system. On the one hand it's easy to see how an actual physical hardware token is "more secure" than a software token installed on a mobile phone; a software token could theoretically be subject to all kinds of OS-related attacks and other vulnerabilities in both the issuing and maintenance. On the other hand, the actual overall environment in which hardware tokens live - the issuing, recalling, and indeed the APT in a vendor environment itself - paint a much murkier picture.

SSL and two-factor are part of the longstanding conventional wisdom of the security industry. They have made their way into the requirement documents of countless RFPs and contracts. In fact, the use of SSL is often one of the only security requirements in specs for outsourced web applications. But the shortcomings of this checklist approach to security are clear when Comodo's certificates can be brought down by a sloppy reseller or RSA's own SecurID can be subverted.

Security Scoreboard - Join the Conversation

noreply@blogger.com (Boaz Gelbord) — Mon, 24 Jan 2011 04:32:00 +0000

This week Security Scoreboard made an exciting announcement - the company received angel funding and Dominique Levin has joined as full-time CEO.

Now that we have an expanded team and some cash (both good things), we would like to share some of our plans with the community. And more importantly, we would like to invite the community to join in and help shape the future of Security Scoreboard.

A bit of background...

Security Scoreboard's mission is to provide unbiased end user  experiences with security solutions in order to help security professionals find the right vendor for their organization's challenges. Almost  exactly one year ago, I launched Security Scoreboard out of a  need that I felt as a security practitioner: I was not happy with the  information available about end user experiences with security  solutions. If you tried researching a security solution, you found plenty of product information from vendors themselves. If you were lucky you might have found some analyst and third party or trade publication reviews. All potentially relevant - but what about actual end-user experiences? There was a lack of information from users who had actually bought, implemented, and used different security solutions.

Security Scoreboard was built to answer this need.   The response within the community was extremely positive and underscored the urgent need for a credible platform for unfiltered end-user voices. It also became clear over time that the Security Scoreboard movement had grown beyond the capability of one person to build and operate in their spare time. I am very excited that Dominique Levin - an industry veteran well known to many of you from her time heading up LogLogic - shares the original vision and has joined Security Scoreboard as its full-time CEO.

Challenges to Building a New Ecosystem

Security Scoreboard seeks to fundamentally change the way CISOs, CIOs and other "security consumers" evaluate vendors. There are four key ingredients to achieve this:

1. TRUST - Users need a way to determine the credibility of reviews
2. PRIVACY - Users need to be able to leave reviews with a reasonable degree of privacy
3. ACTIONABLE INFORMATION - Users need a way to get the information that matters to them quickly and efficiently
4. TRANSPARENCY - Users need to know how the site funds itself and the formula behind any pay-for-play.

Consumer reviews sites like TripAdvisor and Yelp face similar challenges in the consumer space. And while security professionals might be a slightly more skeptical bunch than your average person, the basic challenges Security Scoreboard faces are the same as other community driven review sites. These challenges are make-or-break for Security Scoreboard, so we want to share our thoughts on each one with the community -

 1. TRUST - How do you know whether a review is legitimate?

Screening reviews for obvious plugs or badmouthing is a critical challenge. Users need to know how legit each review is. As Hoff, Lenny Zeltser, and others have pointed out, developing a reputation system allowing users to evaluate Security Scoreboard reviews is critical to our success.

We envision Security Scoreboard having tiered reviews – those written by loosely authenticated reviewers should be taken with a grain of salt, while those written by reviewers who have been vouched for by reputable entities should carry more weight. The nature of this reputation system needs to be rooted in the existing security community. We are exploring a number of tools to factor into this reputation system – from transitive tokens (more on this below) to leveraging existing security organizations and communities. At the same time we are studying what has worked and what doesn't work in other online communities facing the same challenge.

2. PRIVACY

Many security managers do not feel comfortable posting comments about vendors in public forums. Some might even regard their use of a particular solution as confidential information. On the other hand, as discussed above Security Scoreboard needs to vet that reviews have been posted by legitimate users.

Currently we have an informal and not completely scalable approach to vetting reviews while not publishing reviewers' identifying information. As we grow, we are building a more formal structure around reviewer identification. We are also looking into some fancier token-based systems, so that a current trusted user of the site can distribute these tokens to trusted colleagues without the site being aware of their identity. This can spill over into the privacy-overkill zone, so we intend to restrict ourselves to those reasonable privacy measures that would make typical users comfortable leaving reviews on the site. This is tightly bound with the credibility issue and is an issue we intend to continuously involve the community in.

3. ACTIONABLE INFORMATION

Credible reviews are only valuable if they lead to easily accessible and actionable data. Security Scoreboard strongly believes in openness of data and metrics (check out the analytics data for product categories or register to see the popular keywords associated with each individual vendor). As we gather more reviews and evolve the authentication schemes described above, we plan to build more sophisticated accompanying metrics to slice and dice data according to parameters that are important to end-users. Reviewer credibility will become an important factor in these algorithms.

There are some other obvious improvements that are on our short terms product roadmap. Some of you have noticed that Security Scoreboard currently does not let you rate a vendor’s individual products. For small vendors with one main product, rating the product and rating the company is pretty much the same thing. But for large companies like Symantec, McAfee, Microsoft, etc there is an obvious need to rate individual products rather than the vendor as a whole. We’re onto this, and will be shortly introducing changes to allow for rating of specific products as well as direct product comparisons.

4. TRANSPARENCY

Nothing kills credibility faster than backdoor pay-for-play. This lack of transparency affects a large portion of the third party information available today for IT systems in general.

Right now we are focused on building the community at Security Scoreboard and have not yet decided on a final revenue model. Vendors will play a role in this model, but we intend to keep completely openness about how the bills are being paid. Sponsored content and objective results are not mutually exclusive; for example the existence of Google Adwords has not eroded confidence in the organic results produced by the Page Rank algorithm. At Security Scoreboard we intend to have a similarly transparent and open revenue model from day one.

Help us build the future of Security Scoreboard

We are looking for community insight and input on all four of these challenges, and especially in building our reputation and privacy systems. The Security Scoreboard cause will stand or fall with the authenticity and credibility  of product reviews and ratings.   This is a movement for and by end users, so if you have some time to chime in, we would love to hear from you.

Joining the Discussion

If you want to join the discussion, please just send an email to voice at securityscoreboard dot com with your name and affiliation. Don't worry about spam - we'll be happy to take you off the list whenever you want.

This mailing list is open to anyone in the security community and beyond who is interested in contributing to our discussion - end-users, vendors, academics, and the like. If you think that Security Scoreboard is a useful tool and you are interested in influencing our future direction, please be sure to sign up and join the discussion!

iPad and the Illusion of Privacy

noreply@blogger.com (Boaz Gelbord) — Thu, 10 Jun 2010 06:06:00 +0000

It's been a bad week for Apple. First the wifi choked at Steve Job's iPhone 4 demo at WWDC. And now Gawker has reported that AT&T inadvertently leaked the email addresses of 114,000 iPad purchasers.

It should come as no surprise that the culprit here is a web application vulnerability. According to a story on Slashdot, a web service that was supposed to provide an AJAX-type response within AT&T's web apps was left exposed externally. Oops.

A lot of big name people are going to be pissed off. The celebrities on the list are not going to be happy about having their email address in the papers. And public officials who expensed the iPad will (or at least should) have some serious explaining to do as to why the taxpayer needs to subsidize their new toy.

Email addresses can be changed. But the leak also exposed something called the ICC-ID, a number that uniquely identifies a device's SIM card.

At the time of writing (night time EST 6/9) there is still no official announcement on what is going to happen with the leaked identifiers. My guess is that they can't be reliably changed without a manual recall. This raises privacy concerns for the affected users, since ICC-IDs are relatively liberally shared during the course of network communications.

But in the end it doesn't really matter. Using an iPad or an iPhone already binds your personal information to your web traffic in a much deeper way than your old fashioned Mac or PC. After all, most iPhones are full of apps that tie your real actual personal data - your name, credit card, address, etc to your device. iTunes works the same way. And unlike a full blown computer, iPhones and iPads afford very little GUI control of what is happening in the background. You could of course gain control through jail breaking. But that's not the MO of 99% of users, and violates the terms of service to boot.

I don't mean to justify the leak - users have a reasonable expectation that their personal information is not totally exposed for the world to see. But when you use an iPhone or iPad, you need to realize that your personal data is lurking in thinly veiled form in countless transaction and traffic logs. Although the 114,000 folks whose ICC-IDs are now public domain are slightly more at risk than the rest of us, it is not as though everyone else was operating in anonymity. The AT&T incident demonstrates that on rigid mobile platforms everyone's traffic is just one badly configured web service away from exposure.

It is amazing how quickly mobile communications has gone from the most secure to the least anonymous form of communication. Mobile security has a special place in my heart since the days I served as one of the dozen-odd members of the ETSI Secure Algorithm Group of Experts that standardized the GSM and UMTS encryption algorithms in the first half of the last decade. Back then it was easy - security derived from cryptography, and mobile Internet usage was barely getting off the ground. Today the underlying strength of the mobile cryptographic algorithms is almost irrelevant to most practical attacks. And anonymity is essentially impossible to achieve on devices locked down by both the manufacturer and the operator.

With a brick and mortar PC that connects to networks the old fashioned way, there is a certain default anonymity that even non-technical users can achieve. On locked down mobile devices - where Steve Jobs decides what applications can run and how - a user's identity is at best protected by a myriad of minimalistic authentication mechanisms. For most users, it is worth trading robust privacy in the interest of a rich user experience. That's why millions of users (myself included) own iPhones. But it also means that when the inevitable data breaches occur, there is a lot more information potentially at risk.

Napera selling security at the Google Apps Marketplace

noreply@blogger.com (Boaz Gelbord) — Wed, 09 Jun 2010 03:48:00 +0000

Napera networks announced yesterday the availability of what appears to be the first systems management application in the Google Apps Marketplace.

Google Apps Marketplace was launched in March of this year and is exactly what the name implies - a place to buy and install apps that integrate directly with Google Apps. Most of the 45 offerings currently listed in the Security and Compliance category are related to email security. This makes sense since email is the most popular Google Apps product.

Napera's PC Security Informer is trailblazing as the first security management offering in the Google Apps Marketplace (there are of course plenty of competing cloud security management offerings like for example Shavlik PatchCloud).

Does buying security management from the Google Apps Marketplace make sense?

Luckily for Napera, the usual cloud security FUD will not hold much water with its potential Google Apps Marketplace customers. The small and medium sized businesses that are the target market for Napera's PC Security Informer have already moved big chunks of their infrastructure to the cloud. Since the data is already in the cloud, there is no reason that the security to protect that data shouldn't be in the cloud as well.

The bigger issue for most businesses will be business control, customization, privacy policies, and SLA's. Moving apps to a platform-as-a-service infrastructure is scary from a can-I-get-someone-on-the-phone-when-the-^%&$^-hits-the-fan perspective. And for applications deployed within Google Apps, there are multiple vendors to deal with. When you use a cloud-built-on-a-cloud service like Napera PC Security Informer, you are dependent on both Napera and Google for everything to run smoothly.

The litmus test for the success of any app in the Google Apps Marketplace is whether the integration advantages outweigh the lock-in. The biggest competition for Google Apps Marketplace security products will come from competing hosted solutions. With third party hosted solutions, what you lose in Google Apps integration might be gained back in control and peace of mind.

A challenge for Napera in driving adoption of the PC Security Informer is the nature of the Google Apps customer base. With 25 million users spread over 2 million businesses, the typical Google Apps customer is a ten-guys-working-virtually type of company. Those organizations are not in the market for systems management. Many of the larger companies using Google Apps are still dipping their toes in the water. Those companies are unlikely to realize much advantage in the tight integration with the rest of their Google Apps domain that is the main value added of the app approach.

I haven't used the product, but it would certainly be interesting to hear from someone who has. Which brings me to a plug for Security Scoreboard, the vendor review site for the security community. If you are a current customer of Napera Networks, please share your experiences on Security Scoreboard and help the rest of the community evaluate this vendor.

Flash Security Under the Microscope

noreply@blogger.com (Boaz Gelbord) — Mon, 07 Jun 2010 05:04:00 +0000

On the heels of Apple's very public tussle with Adobe over Flash support on the iPad, Adobe announced a "critical vulnerability" in Flash on Friday.

Vulnerability announcements happen all the time. For better or worse, the nature of today's software industry is to build first and repair later. But its been months since Flash experienced a security issue of this scope. And the timing is not good for Adobe, as Steve Jobs specifically mentioned Flash security issues in his "Thoughts on Flash" manifesto in April. With the major media players deciding what graphics and animation standards to support, Flash is under the microscope.

I don't think security usually determines winners and losers in the mass market/desktop environment. But there are rare occasions when the cumulative perception of security vulnerabilities coupled with lingering privacy issues can form a tipping point in the fortunes of a technical standard or company. Many companies are immune to this phenomena due to a lack of alternatives (for all the user outrage, Facebook is not about to be upended by fledgling alternatives like Diaspora anytime soon). But with HTML5 and other open web based standards based offering competing functionality, a series of badly handled security vulnerabilities would not augur well for the future of Flash.

Incomprehensible warnings

Miscommunicating vulnerabilities like the one announced on Friday can fall into this straw-that-broke-the-camel's-back. At the time of writing (Saturday night June 5th) the Adobe announcement does not make clear that all users running current versions are vulnerable and that there is no available fix. Instead, Adobe published that anyone running Flash version 10.0.45.2 or earlier is at risk. Since there is no version 10.0.45.3, that basically means that by default everyone is potentially vulnerable. Since most non-RainMan users do not have the version numbers of their installed programs memorized, this should have been more explicitly spelled out in plain English. A more technical explanation could have been included to parse out which installations exactly are at risk.

But even more troubling for the average user is the lack of a viable fix. Adobe has announced that this vulnerability is being exploited in the wild (again an incomprehensible term for most users…). There appears to be no available patch for the Flash vulnerability. And for the accompanying Reader and Acrobat vulnerabilities the solution is to remove the authplay.dll component that ships with the product. How many users know what a dll is?

Of course Adobe isn't alone in producing vulnerability announcements that are inactionable for most users. And this announcement is far from the worst. My unscientific thumb-in-the-wind estimate would give this a B or B- for clarity on a weighted curve with other major software vendors. But even more problematic and potentially more damaging to Adobe's long term perch within everyone's browser is the lack of user control over Flash privacy settings.

Flash's privacy exception

Flash has long existed in its own little fiefdom on the desktop, immune to many of the privacy controls applied to browser plugins. But that situation could be ripe for change. When even Facebook's CEO - with the closest thing the planet has to a universal social network - is literally sweating up a storm over users' privacy concerns, more easily replaced plugins like Flash cannot continue indefinitely to fly under the radar.

Until now Flash has somehow gotten a free pass when it comes to user privacy. In response to user demand, all the major browsers include a private browsing mode that does not record cookies and generally does not leave digital fingerprints on the user's computer (earning it its more technical name, porn mode). But Flash doesn't play by this game. Most users are very surprised to learn that Flash cookies persist on their machines long after the user has diligently cleared caches, cookies, and even reset their browsers. The only clue for the average user is the seemingly mysterious way that programs like Pandora still remember them long after they thought they scrubbed their browser clean. Flash may have a webpage where users can theoretically manage their cookies, but I would guess that only a minuscule portion of users are even aware of its existence.

Regardless of whether you think Flash on a website is cool or just annoying, it's hard to get the full web experience without Flash and that's why its installed on 99% of browsers. If Flash were to lose its ubiquity the transition to competing standards could snowball. With so little information available about the latest vulnerability, it is difficult to know whether it is the result of overzealous feature integration at the price of security. But as the ubiquitous incumbent in the web multimedia war of 2010, Flash will be judged - fairly or unfairly - to a higher standard than some of its emerging competitors.

Google Secure Search and Security Overkill

noreply@blogger.com (Boaz Gelbord) — Tue, 25 May 2010 23:21:00 +0000

Google announced on Friday the availability of a beta version of its secure search.

Secure search? Well, kind of. Google, of course, still retains all your search data. But users will now have the option of searching over an SSL connection. Just type https instead of http in the Google URL and your searches are safe from prying eyes, Google and your desktop notwithstanding.

The rushed timing of the latest announcement is no coincidence. Google has been in some serious hot water over the last few weeks for gathering data from insecure wifi connections using StreetView. Unlike previous Google privacy $@#%-ups, StreetView wifi-gate has users, and especially governments, genuinely annoyed. A big American company driving by in a van and kinda sorta intercepting wifi traffic understandably rubs a lot of folks the wrong way, especially in Europe.

There is a certain delicious irony here. Google gets busted for spying on unencrypted wifi connections, and responds by offering encrypted search. Google is basically saying that you had better think about encrypting your search results, because there are a lot of crazy folks out there who might be trying to listen in. Heck, even we might be accidentally listening in!

Ironic or not, at least this makes some sense. Last week I wrote about Facebook trying to address a growing privacy uproar by offering a totally unrelated security option. While offering a rare mea culpa for the wifi snooping, with secure search Google is also not-so-subtly castigating users for their use of insecure connections. A bit like Toyota reminding users about the importance of seat belts...

[Since we're on the wifi topic, one quick digression - I don't believe for a minute that Google has any interest in spying on user wifi data. With so much data on so many users, the last thing the company needs is to physically go to users to get their information. I take at face value the claim that a "programming error" was responsible for the extraneous data collection. Unlike Facebook, Google has a deeper well of general public sympathy to draw on and my theory is that the public, if not necessarily the legal, aspects of this incident will quickly blow over.]

But back to secure search, which has been in the works for a while and is much more than a response to the wifi incident. Cynics say that secure search is just a ploy by Google to keep precious search data from the ISPs. To me that doesn't hold much water. Secure search will never comprise more than a tiny slice of overall Google searches unless it is the default. And I don't see that happening any time soon.

At the risk of overestimating the importance of the security profession, I would argue that one of the main motivations behind the new service is Google's interest in placating the security purists within organizations considering its enterprise services. As the biggest cloud service provider in the world, Google's entire corporate future is tied into trust and security in web applications. If Google wants to convince users to ditch desktop applications and behind-the-firewall servers in favor of its web-centered universe, it needs to convince enterprises that it takes security uber-seriously. By being the first major player to offer to secure pre-authentication search data, Google casts itself as a cutting edge provider of secure cloud services.

But does secure search fulfill an actual security function that justifies its cost? Or is it a case of security overkill meets security theatre?

Searching away from prying eyes

Let's start with what Google searches over https achieve. By encrypting traffic, search traffic will be safe from network sniffers.

Here's my best stab at a list of people/entities you might not want seeing your Google searches:

1. Your husband/wife/roommate/parents
2. Your employer
3. The random sys admin at your Internet cafe, university, etc.
4. Your government or ISP

Secure search does nothing for (1). In case (2), your employer is probably not terminating SSL connections, but they may very well be, so you can't really count on your searches being secure. With (4), your government or ISP have enough information on you (like your entire traffic history) that your search history becomes largely irrelevant.

That leaves (3). The only real advantage of secure search is protecting you in random networks you might be connecting to. This seems like a pretty limited use case. And anyone sufficiently security conscious is already tunneling their traffic on public networks rendering moot the privacy advantage of secure search.

How did you get here?

There is one big privacy advantage to secure search - referrer headers are no longer passed, so the web page you are landing on no longer knows how you got there. The vast majority of Internet users do not realize a simple fact that is obvious to most of the security minded readers of this blog. When you search "furry animals" on Google, and land on www.myfurryanimals.com, the webmaster of the latter sees that you landed there by searching "furry animals". The entire web analytics industry is built around this fact.

But you don't need SSL to disable referrer headers. And besides, if someone is so concerned about privacy, they might be better off getting an anonymous proxy. Proxied traffic usually uses encrypted protocols, so at that point using secure search becomes superfluous.

I have no idea what the performance or functionality hit on secure search will be, but for now I don't see the numbers adding up in favor of the service. Searching on the beta Google secure search site seems slightly slower than regular http Google, (although admittedly from the confines of a crowded New York cafe on a Sunday evening). So here's my back-of-the-napkin calculation: I probably do 100 Google searches a day. If each of those is 1 second slower (and I'm just making up the numbers here), is it really worth an extra 1min and 40 seconds of my time every day to hide my Google search history from a hypothetical person who might want to look at it?

The large majority of users have so many toolbars, widgets, and logged in applications running at the same time that the entire concept of SSL encrypting their search traffic is ridiculous. But even for privacy conscious users this seems like one proverbial bridge too far. Secure search might give users a false sense of privacy with little tangible benefit.

An interesting project by the Electroric Freedom Foundation called Panopticlick shows that your browser basically provides servers enough information to be uniquely identifiable. With all the fonts, plugins, and other settings your browser has, even with an anonymous proxy a website can identify you as a return visitor. For the average user, online privacy is a bit of a heads they win, tail you lose proposition. No matter what measures they are taking, it turns out that they are still traceable online.

All this certainly should't be construed as meaning that secure search is useless. Whatever one thinks of Google's privacy policies, they do offer a rich set of user security configuration options. With options like tying password reset to a mobile number, showing the last IP addresses that logged into a Google Account, and default SSL for many enterprise applications, Google offers a significant arsenal of security options that is more robust than many of its competitors. I'm just not sure if secure search adds much to this portfolio.

Facebook and Security Minimalism

noreply@blogger.com (Boaz Gelbord) — Fri, 21 May 2010 23:09:00 +0000

Facebook can't seem to catch a break. Just this Wednesday an XSRF bug was announced that gave access to birthdates users had designated as private.

Not that Facebook users care. I would bet dollars to proverbial donuts that no more than 0.01% of Facebook users has ever heard of XSRF. And more importantly, I would bet that almost none of them has really suffered from these vulnerabilities. Bad security in social networks is a non-story. Lax privacy policies, on the other hand, are much more in your face. No user is going to notice an insecure version of Python running on your webserver. But share their data with unauthorized contacts and the same user might go beserk.

User apathy notwithstanding, Facebook is making some half-hearted attempts to calm the masses. The company announced last Thursday the ability to limit the devices from which an account can be accessed. But this attempt to soothe the raging Facebook villagers with sharpened pitchforks is misdirected. Users are concerned about who Facebook is sharing their information with, not how. Device authentication - a poor man's security control at the best of times - is an unnecessary inconvenience to the vast majority of users and an insufficient safety control for the truly paranoid.

Facebook are not fools of course. You don't build a business that engages every tenth adult on the planet without honing a pretty good sense for which way the wind is blowing. The company realizes that it is under no obligation to provide any real security controls to its users. Providing window dressing security such as device authentication is a good way to appear conscientious to a public that tends to conflate security with privacy. And in any case, the risk that device authentication addresses - preventing User A from logging in as User B - is the one area where Facebook and its users have a common interest.

So Facebook's mission is not entirely at odds with security. Facebook has an interest in providing application security insofar as it does not impede its vision of becoming the web's authoritative social platform (more on that in a bit). But beyond that, why would Facebook provide security that involves substantial resources or limits its collaborative abilities? Facebook may throw its users a security bone when in comes on the cheap, but the company is under no obligation to provide anything beefier.

Really? Here is a simple fact most security folks won't like - unless you are in a regulated industry you are under almost no specific obligation to offer secure web applications. Unlike privacy regulations, this statement is true across all major jurisdictions. Laws will limit who you can share data with, and in some cases like children whether information can be collected to begin with. But they impose virtually no requirements on small businesses on how or even whether they need to secure their data.

This means that anybody can fire up a web application and start collecting, storing, and processing data that may or may not be sensitive to its owner. And they can do this while being under almost no legal or business requirement to provide adequate security.

With hosting costs approaching zero and development frameworks hiding the uglier layers of the stack, this means that any old schmo can be in business in no time. Just like you can blog on Blogger without touching any code, you can now build some pretty impressive quasi-professional web apps without touching any real code. Millions of people have done exactly that.

But what about big apps? Surely the ubiquitous brand name web applications are subject to some sort of control that two guys in their garage are not? Well, not really. The fact is that many web 2.0 apps that are in common enterprise use are probably not more than 5 or 10 guys. They may look like big businesses, but the beauty of the Internet is the ability for small organizations to amplify their presence and take on the trappings of the big boys.

Today there are gazillions of sites out there that will do anything from storing files to reformatting reports that are operating with almost zero intentional application security. And its not just small or medium sized businesses. Even the big players are, at the end of the day, only subject to restriction on who they can share data with. Having mostly evolved from small start-up operations, they take an understandably minimalist approach to information security. Application security - in stark contrast to privacy - is basically a good faith effort.

The kerfuffle around Google's recent StreetView-wifi snafu is a good example of the priority of privacy over security. Apparently Google's StreetView had collected information from open wifi networks. Google has attracted a great deal of negative press and is facing numerous investigations in Germany and elsewhere for this. At the same time, the numerous security vulnerabilities that are frequently exposed at most large companies hardly register on the legal radar screen, and is certainly not something that will get investigated. You don't trigger an EU investigation by having too many bugs to patch in a given release or by using a vulnerable version of PHP.

The More Social, The Less Secure

That's not to say that security and privacy are totally unrelated in social networks. If Facebook wants to build a platform that others can plug into, it necessarily opens the application to vulnerabilities. A very good example of this is the recent hiccup with Yelp. Facebook's Instant Personalization exposed users to a cross-site-scripting vulnerability on Yelp that could harvest user data. Without the Yelp integration, this vulnerability would never have happened.

When it comes to social networks, there is no free security lunch. Collaborative services are by definition less secure. Facebook is meant to be collaborative and thus can never offer the same level of security as a more gated service. This is the same reason that Times Square cannot be secured in the same way an airport can. One is meant to be open and one is meant to be closed, or at least controlled. Although hundreds of security vendors may try to secure web 2.0 applications, robust security and social collaboration are ultimately opposing aims.

Of course there are numerous technological standards that are being built precisely to secure the web 2.0 world. The move to OAuth from BasicAuth (a transition that Twitter will be enforcing next month) is a good example. But from a business perspective, the raison d'etre of most social applications is the collaboration, not the security. When web services communicate, there is generally only one level of authentication required to reach the crown jewels. Unlike traditional applications, most web services only require one screw-up or misconfiguration to expose your data.

Social Media vs the Enterprise

This single-line-of-defense approach that most web 2.0 applications take is sufficient for most individual personal data. Your Facebook settings may limit photos of you drinking at a keg party from your work colleagues, but their accidental exposure is not such a big deal and is a risk most users are willing to assume. In our personal lives, there is no breach notification, limited personal financial liability, and a much lower expectation of due care. Even the recent mess-up exposing your friends' private chats on Facebook is probably met with a stuff-happens shrug by everyone not directly affected.

But enterprises should - in theory - be more cautious. Breaches can carry real costs, financial liability is more substantial, and there are often contractual obligations to provide security. Indeed while there might be no affirmative legal obligation for application providers to provide security, customers may very well be prevented from using their services if there is insufficient security. After all, most enterprises that deal in personal data are under some form of contractual obligation to reasonably protect that data.

Will this raise the bar for small providers of cloud services? Unlikely. As I have frequently ranted about in the past, in non-regulated industries these obligations usually refer to some dinosaur-like provisions about SSL and biometric readers at server room entrances. Unless a company is truly conscientious about applying the meaning of due and reasonable care, there are practically no legal or contractual security requirements to which web applications are subject. (This is of course not true of heavily regulated industries like finance, but most corporations are operating in much more loosely regulated spaces).

Many enterprises are driving full steam ahead with the integration of minimally secured third party web applications into the enterprise. The transition from walled-off silo to full member of the application ecosystem is well underway. We may not be in a Jericho-Forum world of perimeterless utopia, but we are in the awkward teenage state of integrating our IT environment with hundreds of smaller companies - through APIs, SDKs, and the like.

Much like real life, digital hookups put enterprises at risk - you no longer have to worry just about who you are with, but everyone they have been with and will be with in the future. And just like real life, the process of evaluating the safety of a potential application hookup is largely heuristic. With an increasingly promiscuous digital environment, we lose the ability to do a full battery of tests on each potential partner (and belated apologies for the lame analogy).

For individuals, the risks of collaborative web services are far outweighed by the benefits. That's the reason that Facebook has 400 million users and why thousands of popular applications with only the thinnest veneer of authentication thrive. This risk calculus will also hold for many enterprises, both large and small. For more security heavy environments, however, fundamental changes will be needed. For some environments it will take a lot more than device authentication to make today's handy web applications ready for enterprise prime time.

Application Security Underfunded

noreply@blogger.com (Boaz Gelbord) — Wed, 28 Apr 2010 02:30:00 +0000

Imperva and WhiteHat just came out with a report on security spending and resource allocation (registration required). This report is a must-read for anyone who is in charge of security budgets.

The basic gist of the report is that application security is not getting it's rightful share of the security spending pie. This is perhaps an unsurprising conclusion for a study sponsored by web application security vendors, but the real mystery is why the wider security industry is not talking more about this undeniable and perplexing spending imbalance in the security industry. Simply put, most threats are web based, but most security budgets are not. Why?

Here are a few reasons I can think of for the spending imbalance:

Decision makers are unaware of the relative risks.
Inertia
Legal and regulatory requirements overlook web app security
Perception that web application security cannot be solved by throwing money or resources at it.

All these factors feed into one another but there is one other factor at play that is internal to the security industry itself. By and large, the same security standards have traditionally been applied to an incredibly broad swath of companies. Rather than raising the standard for everyone, this approach has had the de facto effect of exempting certain companies from what they perceive to be irrelevant requirements. This in turn drags the entire market down to the lowest common denominator. By using the same hammer to hit all nails, the security industry has inadvertently generated a "security race to the bottom".

One Size Fits None

Some companies operate in highly regulated and highly sensitive environments where security is not up for debate. Let's call this the Fort Knox zone. In the Fort Knox zone, web application security is governed by detailed SLAs on remediating vulnerabilities and applying secure development processes. In this zone, the security of the web application is considered an inherent part of the finished product or service. Everybody thinks and breathes security. These are the big banks and the three letter agencies amongst others.

Then there's the Pragmatic zone, where security matters, but where business decisions are constantly being made to balance security against price, convenience, and functionality. Most businesses fit in the Pragmatic zone even though they might deal with sensitive data. Online health records is one example. For most people, the risk that a random hacker might find out their medical allergies pales in comparison to the risk that in an emergency a doctor might be unaware of those allergies. In the Pragmatic zone, security takes a back seat to functionality, but basic security remains highly desirable.

Finally there is the Whatever zone - a place where basically everything you use is at your own risk. This is the guy who runs a cool web service from his parents' basement that allows you to see when you and your buddies are both within stumbling distance of the same pub. In the Whatever zone, there is no guarantee - and often no mention - of security. It's not that security is trumped by other considerations. It simply was never really a consideration to begin with. And if you don't like it, don't use it.

The Failed Quest for the Esperanto of Security

Today's security industry speaks largely in the language of the Fort Knox zone. "Critical" and "severe" vulnerabilities are presented as something that must be fixed within as short a time as possible. But most businesses are actually graduates of the Whatever zone that are today in the Pragmatic zone. The shrill tone of vulnerability disclosures coupled with its frequently monolithic approach produces tone deaf customers and businesses.

In other words, the real problem is not that there are so many insecure apps out there, but rather that as an industry we set a bar that is both unattainable and inappropriate for many applications. Consider the very recently published OWASP Top 10 web application security risks. Many companies and many security folks view this list as an all-or-nothing proposition (although OWASP makes clear that it isn't). There is no inherent reason that all web applications need to be immune to all these threats. It just takes too much effort with far too little return. And this isn't even counting the opportunity cost of fixing security vulnerabilities.

The specific metrics of the WhiteHat-Imperva report underscore why the absolute approach does not work. Take for example the 38% of respondents who believe that 20 hours of developer time are needed to fix a vulnerability. Regardless of whether this figure is perception or reality, there is no way that a small operation is going to budget 20 hours to fix a seemingly obscure vulnerability when that time could be used to fix a visible bug or build a new feature. The return for spending lots of extra money to truly lock down most apps is just not there - not in the customer recognition, not in improved regulatory compliance, and often not even in a reduction in damaging security incidents (or at least not in a way that is readily measurable for organizations with limited resources).

So it shouldn't really surprise us that vulnerabilities aren't getting fixed. In most companies if the website doesn’t actually work there is hell to pay. But if there is an unfixed vulnerability almost no one knows or cares.

The User Has Spoken (while logging in over http)

This user indifference runs deep. I never cease to be amazed by the number of early and even mid-stage start-ups that don’t have login over https. From a security, or even a marketing, perspective secure login seems like a no-brainer – certificates are relatively easy to install and it is one of the few – perhaps the only – security mechanism that almost every single end user is on the lookout for. So it is very telling that many start-ups do not consider it worth investing even the slight pain-in-the-ass that using certificates introduces.

As security professionals this may seem jarring, but these start-ups know their business better than anyone else. They have figured out a well known secret of today's Internet -

Much of the Internet is pretty much useless if you follow security rules.

OK, that’s a bit harsh. But conventional security wisdom does not jibe with having fun or even getting things done online. There are just too many things you miss out on online if you actually abide by all the security rules that the purists preach. (Here's a simple list for starters - storing passwords on your iPhone, storing passwords in your browser, giving up your passwords for application integration, simultaneously logging on to numerous applications, and the list goes on).

So as an end user, you basically have a choice – seriously handicap your use of the Internet, or take your chances with a half-hearted that's-what-everyone-does attempt to minimize risk (aka anti-virus). The vast majority of end-users have opted for the latter. Or put differently, end users are fundamentally happy with the Whatever zone of security.

The low bar from home to enterprise

Most companies start operations in much the same way - in the Whatever zone of security. They need to push something out fast and get to market with the bare number of features. And the barely working mentality applies to security just as much as anything else.

It's here that the seeds of the specific spending disparity described in the Imperva-WhiteHat study first come to light. Application security comes with real project risk costs. This is in stark contrast to network security – you can secure your network layer fairly easily without risking screwing up your app. Compare the pain of setting up a WAF with the relative ease of setting up a firewall. When a small company needs to choose how to answer the security checkbox that most customers will never look beyond, the choice is clear. And so the imbalance is born - Network security 1, Application Security 0.

Of course start-ups start using the services of other start-ups, and before you know it you have a growing company within a relatively large enterprise ecosystem where everyone is using consumer-grade security without real threat analysis. It is this transition to the enterprise level where in theory the threat analysis should mature and security measures fundamentally reassessed. By that point though, the ship has gotten big and bulky and reversing course is no longer easy.

So often as companies go from the Whatever zone to the Pragmatic zone, they sweep app sec issues under the rug and hope (often correctly) that no one is going to notice or care. Today, too many enterprises are treating web application vulnerabilities as if they were still in the Whatever zone - and then if someone asks about security, they can proudly answer glad-you-asked, look-at-our-firewall. The details of the Imperva-WhiteHat report (and if you have made it this far in the post, you should really read the full report) reflect this - most security professionals report an internal culture that is either cavalier or helpless about web application vulnerabilities.

How is this going to change? If recent history is any judge, regulations and contracts will either break or re-enforce the current security spending imbalance. The current trend is towards the latter. At the risk of sounding like a broken record, I’ll mention again that even relatively recent pieces of legislation and standards (PCI, Massachusetts data security regulation, and for that matter most RFPs) completely gloss over application security. For reasons that I don't fully understand, the PCI Prioritized Approach puts most network security issues ahead of application security issues. And now Washington State has adopted a PCI-based law. This certainly doesn't bode well for correcting security spending imbalances any time soon.

Security Scoreboard is Live!

noreply@blogger.com (Boaz Gelbord) — Mon, 01 Feb 2010 02:35:00 +0000

I am very excited to announce the launch this week of Security Scoreboard - an online resource for researching and reviewing information security vendors. Security Scoreboard features over 600 vendors and aims to become a valuable resource for CISOs, CIOs, system administrators, and anyone who is in the market for information security products and services.

Why Security Scoreboard? As an information security executive at a mid-size company in New York City, I constantly face the challenge of trying to quickly identify and assess the security vendors who offer solutions in a given space. While there is a ton of available vendor content - webinars, press releases, whitepapers, etc - I have always found one vital resource to be missing in the purchase process. Until now there hasn't been one convenient and objective place to see side-by-side profiles of all the vendors addressing a specific security challenge. Security Scoreboard fills this gap by providing a starting point to get oriented about all available solutions before doing a deep dive on those vendors that seem the most promising.

CENTRALIZING RELEVANT INFORMATION

Let's take the example of a security manager looking for an enterprise privileged access management solution. Searching online will lead him or her to some of the larger players. But finding a comprehensive online list of all the players in this field is surprisingly hard, and involves plowing through an overwhelming amount of irrelevant information.

And once the main players are identified, finding basic objective information on each vendor can be tough. The average vendor publishes numerous press releases that then get picked up and replicated on multiple other sites. Independent opinions and information about the vendor get buried at the bottom of online search results.

That's where Security Scoreboard fits in the picture. Security Scoreboard is meant as a time saver - a quick way for security consumers to orient themselves and separate the wheat from the informational chaff.

This is especially useful for buyers in the SMB market. One of the things that strikes me every time I go to conferences like RSA is the sheer number of security vendors with unique and innovative approaches to various security challenges. At the same time, there has been a distinct lack of freely available resources for researching these vendors. Potential buyers lack an easy way to put a vendor in context, research its competitors, and objectively assess whether a vendor's solution will work for them.

The information imbalance is less of a problem for security pros in larger companies that have access to analyst and other services to research the competing claims of a large number of vendors. But security managers and CISOs at smaller companies usually do not have extensive access to such services. For them, even identifying who the main players are in a space can be a time consuming process. Security Scoreboard is of particular use for these often-overlooked consumers of IT security.

CUSTOMER REVIEWS

Security Scoreboard provides more than just a comprehensive directory of security vendors. Users can also leave reviews describing their good or bad experiences with security vendors they have worked with. Of course, like any public review site, there is no reliable way to verify that online reviews correspond to actual customers. But security pros by nature are sophisticated enough to process information accordingly and to spot obvious attempts to game the system.

RESOURCES FOR VENDORS

Most information security vendors will find their company listed with its own company page on Security Scoreboard. Vendors who are not yet listed can submit a request and will be added if they meet the basic requirements (a focus on information security and an active market presence). There is also a form vendors can fill out to get free monthly Google Analytics reports showing the search terms that are leading users to their company page.

Security Scoreboard will also be offering vendors the ability to convert their page to a "premium page" and expand on the very short summary currently in place for each company. This will give vendors who want to spruce up their company page an opportunity to get their message across next to the user reviews and other links related to their company. In keeping with the transparency that is at the heart of Security Scoreboard, this structure will be clearly described on the website.

To celebrate our launch, Security Scoreboard will be sponsoring some great prizes at the Security Podcasters and Bloggers Meetup at ShmooCon this coming weekend in DC. Come by and say hello if you are going to be at the event.

Mass Security Regulation Gets Tech Priorities Wrong

noreply@blogger.com (Boaz Gelbord) — Tue, 10 Nov 2009 01:52:00 +0000

The final version of a sweeping new data security regulation in Massachusetts was published last week. Some parts look pretty good. But some parts look like they are straight out of 1999.

Let's start with a bit of history, for the benefit of the 99.9999% of the population that does not spend its time following obscure state-level data security regulations. The Massachusetts regulation, known as 201 CMR 17.00, was introduced a couple of years ago to address a spate of breaches of personally identifiable information. The business community balked but the regulation survived. Since then it has undergone numerous revisions to address concerns that it imposes an undue burden on businesses.

The regulation has some fairly standard and common sense requirements on the policy and procedural side. But it is on the technical level that the latest - and supposedly final - version of the regulation sounds woefully out of date. Reading through the text gives an awkward time-warp feeling. Like a newly published technical manual talking about dial-up modems and floppy discs.

That 90s feeling starts with the title of the technical section - "Computer System Requirements". Hmmm...What about all the iphones and netbooks and what not floating around the enterprise? And more critically, while securing computers is important, isn't securing servers more important? A more inclusive title like "IT Systems Requirements" would have definitely made more sense.

So what are these "computer system" requirements any how? The only purely technical requirements in the regulation talk about anti-virus software, operating system security patches, firewalls, and encryption. If you are having bad flashbacks to the CISSP you took a decade ago, that's probably not a coincidence. Those are all important issues, but are they really crucial to most technical data breaches in 2009? What about secure configurations? What about securing web applications and secure code development?

So it seems that the security-apparatchik mentality of anti-virus programs, patches, firewalls, and encryption is unfortunately alive and well in the legislative branch. And of course those measures might be the best way to secure a home computer. But they simply do not reflect the reality that most enterprise data breaches that are not a result of stupidity occur as a result of insecure configurations and applications. Up-to-date virus definitions are usually neither here nor there.

Most large companies already know this. They have an internal risk function in place that prevents them from overspending on anachronistic security measures, except when required to do so by outdated regulations like 201 CMR 17.00. But for small and medium sized businesses – including small shops that manage millions of sensitive records – regulations like 201 CMR 17.00 will drive security spending priorities. These companies are inadvertently being misled into believing that securing their environment means buying an anti-virus program and setting up auto-update.

The truth is of course very different. Installing anti-virus software is easy, but actually locking down an environment is incredibly difficult for smaller companies. That is because it requires reconfiguring other applications that no one in the organization really understands. It requires fiddling around with Unix and database permissions and PHP users in systems that no one normally touches. At the end of the day, it is hard to secure systems you do not understand, and most smaller companies do not understand the systems they run internally.

The legislation does not even begin to allude to this. From an actual risk perspective, you are better off with an out-of-date anti-virus program and a really locked down internal environment than the other way around. You are also (sometimes) better off running an unpatched operating system with few services running than a patched one with a gazillion plugins and other third party components. Whoever wrote 201 CMR 17.00 can't be expected to know this, which is why when the law gets technical it just regurgitates some old security one liners that are found in CISSP prep courses.

Interestingly, even the weak and outdated technical requirements have a get-out-of-complying free clause. The technical requirements are all prefaced with the bizarre exemption “to the extent technically feasible”. As we speak they are building some sort of a black hole I understand nothing about underneath the French-Swiss border. So of course turning on a firewall or encrypting some data is “technically feasible”. I am not a lawyer, but I cannot see how any one could make an argument that any of the requirements listed in 201 CMR 17.00 are not technically feasible. There is a very ill-defined exemption at play here that will make it difficult for companies to understand what the regulation actually requires of them.

It is a shame that the poorly written technical portion of 201 CMR 17.00 detracts from what is otherwise a well written regulation. The sections on policy, training, and contractual language are important and will prompt some companies to get their data security house in order. It is only when the regulation tries to get even vaguely technical that it falters. I do not know whether "final version" really means "final version" this time around. But if there is room for one more revision before the March 1st compliance deadline, a few words on secure configurations and applications would go a long way to improving the regulation.

YouSendIt Indictment is a Cloud Warning

noreply@blogger.com (Boaz Gelbord) — Sat, 31 Oct 2009 20:44:00 +0000

IDG is reporting that the former CEO of YouSendIt, Khalid Shaikh, was indicted this week by a grand jury for launching DoS attacks against his former company.

Disgruntled ex-employees sabotaging their old company happens all the time. When that employee is a former CEO or CTO (and Shaikh was both) it makes you wonder what kind of data that person may have had access to. Especially when the company in question is one of the market leaders in so-called managed file transfer.

Managed file transfer companies help people get around limits on the size of email attachments. If you are sending a 2GB file, email is just not an option. Fedexing a DVD is a royal pain and makes you look about as tech-savvy as a government agency that still insists on receiving faxes. This has given rise to a large managed file transfer market, which includes vendors like Accellion, Axway, Globalscape, and many others. There are basically two types of file transfers - the one where your data stays on your servers, and the one where the vendor hosts the data. YouSendIt is in the latter category.

There is something very convenient about externally hosted managed file transfer - you don't have to configure and manage your own server, for starters. But you lose control of your data, and when your provider is breached your data might be exposed. This won't keep you up at night if the only files at risk are photos of your pet cat. But what about companies that use YouSendIt or other cloud services to transfer confidential files?

To be certain, there is absolutely no indication that Shaikh or any one else at YouSendIt accessed any data improperly. The only charges relate to the DoS attacks. But the incident serves as a good example that when your data is in the cloud, you need to be sure that your cloud provider has the right measuers in place to protect against external and internal attacks to their network.

There are not many enterprises that can withstand an attack from a technically sophisticated former insider who is willing to criminally attack the enterprise. After all, this person knows

1) the network and data architecture like the back of their hand

2) security vulnerabilities

3) passwords that haven't changed (and how many companies change all their passwords every time someone leaves?)

This is why the internal data handling policies of cloud providers are critical to the protection of their customer data. The more robust their data structure is, the less likely that an insider can compromise sensitive data.

So how secure is the data on YouSendIt's servers? YouSendIt has a detailed security policy that describes their overall security narrative. Against an insider, the most important security measure is data encryption. But their policy implies that data is not actually encrypted on YouSendIt's servers:

All files stored on YouSendIt servers are encoded and stored using a scrambled name, which makes it impossible for a network intruder to identify the file by its original name or read the contents of the file. In order to access and download a file from YouSendIt’s servers, either the full download link or complete user credentials are required.

I don't really know what "encoded and stored using a scrambled name" means, but I can't imagine it means encryption. After all, if they were actually encrypting, wouldn't they just say that?

So let's assume that there is no actual encryption - not just obfuscation - in place. This means that any employee of YouSendIt can access raw files if they gain access to the right server.

I have written before about how encryption in the internal environment is not always worth the price, particularly for database encryption which can be costly from both a complexity and licensing perspective. Encryption in that case does little to protect the organization against the bad apples in its midst, because those people likely have access to the raw unencrypted data in much easier to reach places. But in the cloud this whole calculus is reversed, which is why encryption of data should be a requirement for any cloud deployment.

I certainly do not mean to pick on YouSendIt. As far as cloud managed file transfer systems go, they at least have a detailed explanation of their security policies on their site. The fact that they are one of the larger companies in this space also provides some reassurance. But the indictment of their former CEO should act a a general wake-up call for anyone who is thinking of using cloud services for confidential information.

In the end, enterprises need to make their own risk assessment for using such cloud based services. For low to medium security files, using a cloud managed file transfer solution does not introduce significant new risk. However for highly sensitive files, incidents like the YouSendIt attack are further evidence that enterprises should either stick with internally hosted solutions, or should use the cloud with caution. Encrypting files prior to using the cloud is one measure that grants additional peace of mind at the cost of slight inconvenience.

SEC eyes Identity Theft

noreply@blogger.com (Boaz Gelbord) — Mon, 26 Oct 2009 12:50:00 +0000

A few weeks ago, the SEC fined the Commonwealth Financial Network for its failure to mandate proper anti-virus software on its computers.

Here is the basic story - Commonwealth Financial has a decentralized advisor structure where independent contractors work out of about 1000 branch offices. These advisors access the Commonwealth online trading platform from their own computers. Commonwealth has a central IT office that supports these users.

Sound like a recipe for infected computers? Turns out it was. Using malware, an intruder managed to get the login credentials of some brokers. He (or she) then created a list of high value accounts and tried to execute some fraudulent transactions. At that point Commonwealth's clearing systems apparently picked up that something fishy was going on and shut down the illegal activity.

It would seem that Commonwealth's basic controls worked in this case - a criminal was unable to carry out fraud and potential victims were notified. But the data on the violated accounts was leaked (including information such as the net worth of individuals). And the SEC has a Safeguards Rule that requires broker dealers and Commission-registered investment advisors to "adopt written policies and procedures reasonably designed to protect customer information".

The SEC has not traditionally taken direct action on information security issues that are unrelated to the filings of publicly traded companies (by contrast other regulatory bodies like the FTC have been fining companies for bad information security practices for years). It is hard to say whether the Commonwealth fine indicates that this is about to change. The overall draft five year plan for the SEC released earlier this month contains a fleeting reference to identity theft on page 35 that may indicate a prioritization of this issue. A very detailed overview of the current issues being discussed can be found in the Federal Register.

Of course the Commonwealth fine is so low that it may actually have an adverse effect. It reinforces the business practice of risking low fines rather than changing business practices. The fines companies face for information security issues are dwarfed by the fraud-related fines that regulatory agencies in the United States issue. MoneyGram was fined $18 million the other day for turning a blind eye to fraudulent transactions on its network.

But the SEC action in the Commonwealth case does tell us something about how regulators look at information security. Two main issues were cited in the SEC action -

(1) the failure to actually require - rather than just recommend - anti-virus software, and

(2) the failure of the support center to properly follow up on a report the computer was infected.

Recommendations and Requirements

The first item underscores what legal departments have known for years and what CISOs are just starting to learn - that the most important thing for an organization is a well formulated and well communicated security policy. This is actually more important than most technical controls in addressing the overall enterprise IT risk.

Commonwealth might have avoided a fine entirely if it had just switched around a few words in its security policy. To regulators, there is a big difference between requiring and recommending, even if you can't actually enforce your requirements.

To technically require anti-virus software is a pain. Network Access Control (NAC) systems have struggled to gain acceptance outside of highly controlled corporations or environments like universities where infected users threaten availability, and not just security, of networks. The recent failure of the once-promising Consentry Networks is a sign that NAC vendors had over estimated the appetite for pure-play NAC appliances.

But there is a world of difference between getting a complex NAC solution to make sure everyone on your network has anti-virus software, and just telling people they have to get anti-virus. The latter is free. And although cynics would say that it does little to influence actual user behavior, it does help create a culture of security within the organization. And, critically, these policy mandates create a framework for liability and accountability when something goes wrong.

What You Don't Know Sometimes Cannot Hurt You

Item (2) raises an uncomfortable truth that undercuts the selling strategy of many security vendors. Namely, organizations are sometimes better off not knowing about security vulnerabilities than knowing about them and doing nothing about them. In this specific case, knowledge of a vulnerability came from a human being noticing their computer was infected. But most vulnerabilities come to light by an automated system detecting them. In that case ignorance is sometimes bliss.

Many security vendors pitch their products with "You have no idea how much bad stuff is going down on your network! Buy our new ZXT3000 to discover and mitigate threats ABC". For some businesses, this is an appealing proposition because their data is so sensitive that it is being specifically targeted. But for the large majority of organizations, buying the ZXT3000 (and apologies if such a product actually exists) is just going to create more liability than they previously had; after all, they may have the budget to buy the device, but they don't have the manpower to monitor all the alerts it creates. This is why many organizations have turned off their complex IPS systems. They turned it on, got gazillions of alerts, and then intuitively realized that having all these high severity alerts and not doing anything about them is worse than having no alerts at all.

Visa Embraces End-to-End Encryption

noreply@blogger.com (Boaz Gelbord) — Mon, 19 Oct 2009 00:31:00 +0000

It feels like it has been a slow last few months in the information security regulatory and compliance space. That is my excuse for why it has been quiet on this blog for a while (well, that and being very busy with other stuff).

PCI was back in the news last week with an announcement by Visa in support of end-to-end encryption. With all the hundreds of requirements that PCI imposes on merchants, it can come as a bit of a surprise that data is not in fact encrypted at all stages as it travels between the Point-of-Sale and the card brand. This latest announcement by Visa is a signal that the payment industry is finally looking to fix this.

Further evidence of this shift comes from an unexpected source. This week I had the chance to hear Heartland CEO Bob Carr talk at the SC World Congress in New York about the massive data breach his company experienced in January of this year. Now you might think that the Heartland CEO addressing a security conference would be as likely as Nancy Pelosi addressing the NRA. But ever since Heartland's data breach, Carr has been aggressively engaging the IT security community.

He has called for reform of the QSA system (more on that later) and Heartland is promoting a new end-to-end encryption standard being developed with Voltage called E3. The E3 system will ensure encryption of card data from the moment a card is swiped until it is transmitted to the card brands.

Heartland is not alone in proposing a more robust system for securing card data throughout the transaction lifecycle. First Data and RSA have a competing tokenization product that basically replaces sensitive card data with random numbers and offers both advantages and disadvantages when compared with the E3 end-to-end encryption approach.

So will these new technologies reduce the number of credit card data breaches? That is hard to say, because we don't know enough about the cause of most of these breaches. But it seems like a safe bet that implementing these systems will at a minimum substantially reduce the risk of data compromise between the PoS and the acquirer.

But What About Internet Sales?

Card Not Present (CNP) transactions are a different ball game. After all, card data in a CNP transaction needs to travel a long road before it is safely in an end-to-end or tokenized environment. Removing the number of nodes that store actual unencrypted data will not do anything to secure these initial stages of CNP transactions. But it will make it easier to identify where breaches occurred. And this, in turn, will help sort out the liability issues which are at the heart of the practical problems with PCI.

Untangling the Liability Mess

Let's take a closer look at the liability issue. One reason for the poor state of application security today is that organizations are often not held accountable for data breaches that do not involve card holder data. With nearly ubiquitous data breach laws in effect, this is usually not the result of willfully concealing a breach but rather because companies don't know - and aren't motivated to uncover - whether they have been breached. In an ecosystem where many parties have handled the same data set, breaches cannot be definitively traced back to the offending party. This leaves little inherent incentive to invest in security technologies.

Take for example the fraudulent use of Social Security Numbers. If a criminal manages to take out fake credit in the name of a certain John Smith through use of his SSN, address, and birthdate, there is almost no way to realistically figure out where the leak came from. After all, John Smith has probably directly and indirectly provided this information to gazillions of service providers and others over time.

Cardholder data is a different ball of wax. The payment card industry is in a unique position to trace back its fraud and does this very successfully in the physical world. A waitress who runs cards through a skimmer in the back of the restaurant will lead to a list of fraudulent charges that will in all likelihood be traced back to the merchant. So the restaurant is incentivized (have never really been sure if that word actually exists) to prevent such fraud - whether by trying to hire trustworthy employees, keeping a closer eye on employees, etc.

In the Card Not Present environment, the lack of end-to-end encryption makes pinpointing blame slightly more difficult since the identical data set may exist in a number of different systems belonging to different entities. Perhaps not more difficult in a breach on the scale of Heartland, but more difficult for the thousands of mini-breaches that occur all the time. By securing this travelling data, it becomes easier to actually locate where smaller scale breaches have happened.

The Failure of the QSA System

As the screws tighten on data-in-transit and it becomes easier to assign blame for misused cards, the issue of QSA liability becomes even more important.

The QSA system is badly broken, and Heartland is just another example of a certified entity that was breached shortly after certification. The lack of liability is the greatest failure of the PCI system. In a normal financial audit, part of the deal is that if the company totally opens its books and does nothing to willfully mislead its auditor, then the auditor takes a certain liability with regards to the statements it produces. With PCI, nothing of the sort exists. What is the PCI audit worth if no one is responsible for its conclusions?

(The oft-quoted notion that one is never truly PCI compliant because compliance is a just snapshot in time doesn't hold much water. After all, a financial audit is also just a snapshot in time, in the sense that if someone raided the corporate bank account a week after an audit then of course the audit results are no longer valid. Liability can exist even without continuous monitoring)

Small Businesses

The liability issue is especially critical for small businesses. Although PCI has been around for a while, there are still a vast number of the 6 million odd smaller merchants in the US whose only experience with PCI is a line item on their merchant fees (many acquiring banks actually itemize a "PCI fee" to merchants). The credit crisis has left smaller merchants in a precarious situation, with merchant accounts being shut down when accounts exceed normal charging activity. Add PCI fines to the mix and a small company could easily go out of business altogether if it falls afoul of its acquiring bank.

Which means that in the short-term, increased awareness of PCI is driving an increased use of external payment gateway systems to offload card processing altogether. Most gateways are relatively inexpensive (small monthly fees and a small per transaction fee). It seems unlikely that any small company can invest the necessary funds to really make their IT systems PCI compliant. Data security regulations like the Massachussetts law go to great lengths to emphasize that small businesses are only expected to spend relative to their size. PCI is less forgiving. Level IV merchants may be under less validation requirements than Level I merchants, but the actual requirements are the same. It is no wonder that merchants are exiting the online payment business completely.

Of course those small businesses still have to deal with the PCI requirements for their non-Internet processing, but increasingly these IT environments are separate from a company's web presence. Many companies are outsourcing this processing as well. Indeed, significant amounts of card data can pop up in unlikely places. A recent British survey revealed that 97% of call centers record sensitive card holder data data. Better to have those systems outside the gate as well.

The new move to end-to-end encryption is certainly good news for the payment card industry, but will also require businesses to invest in new equipment and generally reassess their card payment architecture. For many small web merchants it may well serve as a motivation to reduce their card gathering activities even further.

https Can Wait - SaaS Needs Better Authentication First

noreply@blogger.com (Boaz Gelbord) — Tue, 21 Jul 2009 04:40:00 +0000

Twitter just got burned in the cloud. Some "hacker" managed to figure out a password to one of Twitter's Google Docs accounts. This guy went on to send a whole slew of confidential Twitter documents over to TechCrunch.

This kind of stuff happens all the time, but our collective Twitter obsession has catapulted this story to the top of the news. Twitter's role in the recent Iranian protests has given the fledgling service a new gravitas. An attack on Twitter, it would seem, is an attack on all of us. And to make things worse this was a direct attack on cloud services. This perfect storm even has the New York Times talking about cloud security.

First let's look at what actually happened. An administrative assistant at Twitter used the same password for her corporate Google Docs account as for a whole bunch of personal services. Enter some guy going by the name Hacker Kroll. He managed to reset her password by answering her "secret questions" and reviving a defunct hotmail account the assistant had given for password reset. A bit of Googling and voila - all the company's goodies from secret business plans to personal emails are in the public domain.

Reading over the chain of events, it seems like this could happen to pretty much any company using SaaS (which according to various studies means most companies). And it raises an uncomfortable question - can Google Docs be trusted for anything truly sensitive given the flimsy password authentication it relies on? For the average user, Citibank password=Amazon password=Salesforce password=Twitter password=Hotmail password=...you get the point.

The Inevitability of Password Recycling

So who is to blame for this gaping security vulnerability?

Let's start with who is not to blame. Users can't be blamed for doing what comes naturally. And in fact, sticking to a very small number of passwords makes sense from an availability perspective. The security risks arising from using the same passwords everywhere pale in comparison to the total catastrophe that ensues from actually getting locked out of accounts. The average user would rather risk a 0.01% chance of their online accounts being compromised than a 5% chance of being locked out of their accounts (OK, I'm making those numbers up but you get the point).

There is another reason not to blame users - they haven't been given any workable alternatives to password recycling. Users are justifiably nervous about browser-based password managers - it opens up a Pandora's box of cross-site scripting and other vulnerabilities, no matter how complex your passwords are. And systems like KeePass that allow users to store their passwords in encrypted form may be very convenient for a paranoid minority, but just don't meet the real world needs of the average user.

Some companies try to force unique passwords through complexity requirements or password expiration policies. These settings aren't always available (Google Docs doesn't allow password expiry) but in Salesforce for example these settings can be set administratively. But this still doesn't solve the problem of password recycling. If a given user has hundreds of pictures of their golden retriever on Facebook and all of his passwords are goldenretriever1, goldenretriever2, etc, there's no configuration setting in the world that's going to pick up on this.

So the solution isn't going to come from user education or unenforceable corporate policies. SaaS providers need to offer more secure cloud authentication alternatives, even if this means charging a premium. SaaS vendors will of course only react to a market need. Unfortunately there has been very little pressure on vendors and the focus to date has been disproportionately on old fashioned network security issues. This has come at the expense of improving the very weak authentication structure in place in most SaaS offerings today.

https and Barking Up the Wrong Security Tree...

Take for example the recent letter to Google from a group of security industry thought leaders calling on the company to enforce https rather than http. While that is a worthy goal, it builds on the security industry's https fetish while ignoring the much more significant cloud authentication crisis.

Defaulting to https protects against packet sniffing; an important security objective, but one that is less critical in the cloud than on corporate networks. Compared to guessing passwords, running a packet sniffer requires a high level of technical expertise and a high level of direct network access. The rewards are also limited - sniffing a Google Doc that is being transmitted in plaintext gives access to that one document. Compromising a password yields the mother lode. That's why the majority of attacks we hear about involve guessing user credentials, not performing network monitoring (the TJMaxx case notwithstanding). Nine times out of ten when the media talks about an account being "hacked into", they are not talking about a compromised router or server. They are talking about plain old password guessing a la Twitter or Sarah Palin Yahoo account.

Security risks in SaaS differ sharply from the traditional firewalled corporate network. At the risk of vast generalizations, https is more important than robust authentication in a walled environment, but in the cloud that priority order is flipped. Password authentication is often sufficient protection for in house corporate resources because there is usually at least one more hurdle to climb to actually get at the data. That hurdle might be knowing how to get onto a company VPN or even just knowing the URLs of the company's web facing resources. These aren't state secrets, but probably enough to deter the casual hacker. Remember, the only technical skills involved in many headline-grabbing "hacking" incidents are a bit of Googling and combing Facebook for clues to password reset questions.

Poor password management is of course still a problem within corporate networks, especially for shared passwords. I recently discussed this issue in an interview that was published in Computerworld today. The lack of administrative password management is another example of skewed security resource allocation; organizations that spends enormous sums on firewalls, IDSs and other network security devices and services often fail to properly secure system access accounts such as root passwords on Linux servers, administrative passwords in Windows, or sa passwords on databases. Indeed the lack of proper management of administrative passwords was apparently yet another security issue at Twitter.

But the shift to cloud services like Google Docs gives potential hackers an even lower hanging fruit than guessing at default or poorly chosen administrative passwords. Cloud computing increasingly means that the only thing standing between a hacker and confidential data is a single password. After all, there's no point in trying to gain access to a core router with a potentially stupid password when you could just guess away at docs.google.com and try your luck there. And as an added bonus to the password-guessing approach, the lucky guesser gets all the data served on a silver platter, all formatted and ready to go. No messy databases to sift through and no need to have any knowledge of SQL, IOS, or other unpleasant technicalities.

Adding Just a Bit of Security to the Cloud

Eliminating the all-you-need-to-do-is-guess-a-password vulnerability in cloud computing isn't rocket science. It is in fact much easier to address than the politically dicey issues involved with shared administrative passwords. And there is no reason SaaS providers can't charge for the service. SaaS providers such as Survey Monkey already offer https versions of their products at a cost. Incidents like the recent Twitter snafu will push mainstream SaaS providers to offer premium authentication services as well.

There are a couple of easy-to-implement solutions that would have prevented the Twitter hack and also the vast majority of other SaaS password-guessing attacks that have been going on lately. One method is to require an extra "corporate password" to get into an account, so that employees need to enter both an individual password and a second password maintained and periodically changed by the company. Not a perfect solution, but one that would deter the flood of amateur attacks that SaaS seems to attract.

There are other more robust methods to beef up security - users can be required, for example, to submit corporate email accounts as their back up accounts. Another option is to force users to dial into a corporate center to reset their password. They can be then be subjected to much more detailed questions to authenticate them.

Letting companies insert themselves into the authentication process will do a lot more than https to secure cloud services. There just aren't that many folks out there running Wireshark in hopes of stealing a spreadsheet off of Google Docs. As the recent Twitter breach indicates, there are many more people out there trying to guess your employees' maiden names and get to passwords that way. That's not to say that https isn't important. But it's much more important to beef up authentication first.

OWASP Security Spending Benchmarks Project Report for Q2 Published

noreply@blogger.com (Boaz Gelbord) — Tue, 30 Jun 2009 11:47:00 +0000

Today the OWASP Security Spending Benchmarks Project Report for Q2 was published.

This project measures security spending in the development process. This quarter we focused on cloud computing. We were trying to measure how much use companies are making of cloud computing, how this affects spending, and how they are dealing with related legal and business issues.

We are lucky to have some great security folks volunteering their time on this OWASP project - Jeremiah Grossman, Rich Mogull, Dan Cornell, Bob West, and others have all provided valuable feedback and support. We were also very fortunate to have organizations like the Open Group and the Computer Security Institute (CSI) join our project over the last quarter. They join organizations such as eema, Teletrust and companies such as nCircle, Cenzic, Fortify and others that have been actively contributing to this effort. A full list of partners can be found on the project website.

Cloud computing gets some people's eyes rolling because it sounds like a marketing gimmick or meaningless term. But whatever you want to call it, infrastructure, platforms, and software are resources that are increasingly being outsourced or externally hosted. This has enormous security implications because it undermines the traditional notions of ownership and management that security has been based on in the past.

Here are the key findings in the OWASP Security Spending Benchmarks Q2 report:

THE OWASP SSB Q2 SURVEY RESULTS:

1. Software-as-a-Service is in much greater use than Infrastructure-as-a-Service or Platform-as-a-Service. Over half of respondents make moderate or significant use of SaaS. Less than a quarter of all respondents make any use of either IaaS or PaaS.

2. Security spending does not change significantly as a result of cloud computing. Respondents did not report significant spending changes in the areas of network security, third party security reviews, security personnel, or identity management.

3. Organizations are not doing their homework when it comes to cloud security. When engaging a cloud partner, only half of organizations inquire about common security-related issues, and only a third require documentation of security measures in place.

4. The risk of an undetected data breach is the greatest concern with using cloud computing, closely followed by the risk of a public data breach.

5. Compliance and standards requirements related to cloud computing are not well understood. Respondents report having the greatest understanding of PCI requirements relating to cloud computing and the least understanding of HIPAA cloud requirements.

SURPRISES AND NON-SURPRISES IN OUR SURVEY RESULTS...

1) The fact that SaaS is reported as the most prevalent of all cloud models is not surprising at all. Leveraging Platform-as-a-Service requires a level of expertise and sophistication many companies still do not have. And Infrastructure-as-a-Service has been dogged by performance issues and has yet to really supply an appropriate ROI model.

2) It is more perplexing that organizations do not report significant spending changes as a result of cloud computing. On the face of it, one would expect that cloud computing would result in lower expenses in a number of security areas, particularly network security. The fact that this has yet to occur may mean that organizations have been slow to adapt security budgets as a result of their cloud activities. Over time, both budgets and the role of security management will be increasingly focused on managing and auditing cloud relationships. Which brings us to number 3...

3) It is also somewhat surprising that organizations are not doing their homework when it comes to cloud computing. The survey found that only a third of organizations ask for the security policies of cloud partners. With all the talk of cloud security dangers, you would expect there to be heightened awareness and that companies would take the time to look into cloud partners' security narratives. That this has not been happening indicates that companies see cloud computing in the same vein as other outsourcing arrangements - the actual under-the-hood operations or security are not that important as long as the issues are contractually addressed. This approach may be more a result of necessity than choice, since for a small company with significant operations in the cloud it is hard to see how they could make any significant assessment of their cloud partner's security posture.

4) Data breaches are and will always remain the main fear factor driving the security industry. While compliance has always a bit fuzzy (especially when it comes to non-technical regulations, where there is a lot of wiggle room), the same cannot be said of a breach. You have either been breached or you haven't, which probably accounts for the greater concern survey respondents reported. It is interesting however that despite this very high level of concern with data breaches, organizations are still doing very little to vet cloud partners. Most organizations seem to have come to the conclusion that although there are many data security dangers related to cloud computing, there is not much they can do to mitigate this risk.

(5) Compliance is the issue that is really raining on the entire cloud computing parade. While PCI has fairly detailed supporting documentation to guide companies, other standards and regulations are much more vague so it is easy to see why people are confused. Regulators are still struggling to understand Web 1.0, so I do not expect we will be seeing much concrete guidance in this area in the near future.

MOVING FORWARD...

I gave a whole bunch of caveats the last time we published our survey results about why web surveys need to be taken with a healthy grain of salt. This still holds true for our cloud computing survey, and probably even more so because no one seems to agree on what cloud computing is. But even so there are some important take-aways from the data we collected.

The most significant warning sign in the survey results in my opinion is that companies are moving to the cloud without really inquiring about the security policies and posture of their cloud partners. And when they do ask about these issues, they rarely ask for documentation. This does not bode well for the future security of cloud computing. Although smaller companies rarely have the resources to truly assess the security of their cloud partner, asking for written documentation of security policies at least forces the cloud partner to maintain a security narrative they share with customers. As more customers inquire about security, this security narrative takes on an increasingly strategic role for the cloud partner.

You can read the full report here.

Nevada Mandates PCI Standard, Part II

noreply@blogger.com (Boaz Gelbord) — Sat, 27 Jun 2009 06:30:00 +0000

Did Nevada really mandate the PCI Standard into law last week?

It sure seems like it when you read Senator Wiener's bill SB 227. I am not a lawyer, but the following sentence seems pretty clear: "If a data collector doing business in this State accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the Payment Card Industry (PCI) Data Security Standard, as adopted by the PCI Security Standards Council".

For anyone involved in information security management or compliance, this is a really big deal. PCI has just been catapulted from a contractual obligation to a full legal requirement.

No one seems to have seen this one coming. In fact, I am not even sure that the Nevada legislature really saw this coming and they may not have realized the very far reaching implications of this legislation. But more on that in a minute.

Ira Victor, President of the Sierra Nevada chapter of Infragard and Director of Compliance at Data Clone Labs, was kind enough to reach out to me this week after I published my original post on this topic. Ira was intimately involved in the discussions around the new Nevada PCI law and testified before the Nevada Senate Committee on Judiciary in support of the law. Ira has some terrific insight into the history of this bill that can be heard in my interview today with him on this topic.

Here's a quick history of the bill as related to me by Ira. The current law came about to replace NRS 597.970, an earlier bill mandating encryption that apparently left open the door for criminal liability and did not define encryption. To remedy these issues, the new bill is much more specific about encryption requirements and somewhat randomly also requires PCI compliance. In exchange it provides a safe harbor for companies that are PCI compliant.

There is a thick irony here. Businesses that objected to the original bill on the grounds that it was too harsh now have a much much stricter bill on their hands that actually mandates PCI. This is either a very bold and trailblazing move by Nevada, or a last minute oversight because businesses didn't understand the implications. My money is on the latter for a couple of reasons:

1. There is no precedent of any other state legally mandating PCI. Some people think PCI is good and some think it is bad. But either way there is something plain weird about a law mandating a specific contractual agreement between merchants and card issuers.

2. There is no reference to PCI in any of the discussions or testimony before the Nevada Senate Committee on Judiciary. Wouldn't such a major shift in infosec policy at least be discussed by law makers and special interest groups ahead of a vote?

My guess is that the Nevada legislature meant to waive liability for PCI compliant companies, but not to actually mandate PCI. Recent discussions in Massachusetts objected to the mere mention of encryption in that state's security regulation. I can't possibly see how the business community in Nevada would have knowingly agreed to the whole PCI enchilada without putting up a fight. Being forced to do PCI makes mandated encryption look like a walk in the park.

So if this law doesn't make sense, is it going to stick? Ira knows a lot more about the legislative process in Nevada than I do and he insists that there is very little wiggle room to delay this law. But I just don't see the state of Nevada actually enforcing this. How many small businesses can really claim to be PCI compliant? Even the PCI Council itself tacitly acknowledges as much through the publication of their Prioritized Approach.

For more on this topic you can listen to my interview with Ira here.

Nevada Mandates PCI Standard

noreply@blogger.com (Boaz Gelbord) — Sat, 20 Jun 2009 19:50:00 +0000

Nevada has recently passed a law mandating PCI compliance for companies accepting payment cards that do business in the state. It is scheduled to go into effect on January 1st, 2010.

This makes Nevada the very first state to actually mandate PCI. The prize for toughest-state-data-security-law used to belong to Massachusetts. But Mass has recently been wavering and its technical requirements are almost non-existent compared to PCI.

The Nevada law is no reason to panic and doesn’t really change much for companies dealing with credit card data. Those companies already have a contractual obligation to adhere to PCI. The Nevada law ups the ante by making this an actual legal requirement, but the standard itself remains the same. And as far as actual enforcement goes, the Nevada law says nothing about penalties whereas PCI has the ability to fine non-compliant companies.

The bigger change is for companies that deal with non-credit card personal data. The Nevada law defines nonpublic personal information as a social security number, driver’s license number, or account number in combination with a password. It mandates the use of encryption for the transfer of such data outside of a company's control (this requirement existed in various forms in previous Nevada legislation as well).

One would hope that there aren’t too many companies out there sending account information together with passwords unencrypted. That leaves full Social Security Numbers and the much-less-frequently used driver’s license numbers. (Interestingly, the regulation doesn’t consider the last four digits of the SSN to be personal information. Which is kind of strange when you consider that the last four digits are the most random parts of the number. Oh well).

I suspect there are many companies out there with Nevada customers who will have to play some catch-up when it comes to SSNs. Full SSNs are still frequently used as a primary identifier for many web services related to payroll and benefits as well as many services that have nothing to do with taxes.

Most of these services already encrypt data on the interface level – it is the exception rather than the rule today to see a plain old http login page that asks for your SSN. It’s much tougher to know what is going on behind the scenes. But does the Nevada law really require companies to change their back-end data processing?

Because the law only talks about the “secure system” and the area “beyond the logical or physical controls of the data collector”, it is doubtful that this regulation requires any sort of SSL encryption of data that is not going out in cleartext over public networks. Data behind firewalls or behind some form of password protection would not appear to require encryption based on this wording.

One positive potential outcome of the Nevada law is that it may encourage organizations to move away from using SSNs when they don’t have to (a trend that has already been underway for a while, particularly at universities). There is something particularly jarring about being asked to provide your SSN to get cable service. Strict new rules around handling SSNs may be the necessary kick in the pants for SSN-addicted companies to finally overhaul their authentication methods.

One final thought about the Nevada law itself. In what I believe is a first for state laws, it directly references FIPS, NIST, and other “established standards bodies” when discussing allowable encryption methods. Most data breach notification laws give an exemption for encrypted data without giving any meaningful definition of the term. This has allowed companies to avoid notifying of a data breach when the compromised data was somehow obfuscated. This law will make it harder to claim that some light obfuscation or encoding actually constitutes encryption.

SO…DO I NEED TO BUY SOMETHING TO MAKE THIS GO AWAY?

Companies that sell encryption products have a field day with laws like this. But - like other data security regulation - you don’t need to buy anything to be in compliance with the Nevada data security law. You just need to make sure that you are not sending sensitive data in cleartext over public networks. This means a bit more messing around with certificates and configurations prior to releases but not much more. And of course you also need to make sure that anywhere you are storing this data at rest is considered part of your “secure system” or has some logical or physical controls in place.

FURTHER READING

The actual text of Nevada Senate Bill 227 can be found here.

A good overview of the evolution of data security legislation by Andrew Baer can be found here.

UPDATE: My newest post on this topic can be found here. You can also listen to my interview with Ira Victor who testified before the Nevada Senate Committee on Judiciary in support of the bill.

Opera Invites You to Join the Cloud

noreply@blogger.com (Boaz Gelbord) — Wed, 17 Jun 2009 03:42:00 +0000

Opera reinvented the web today.

Or at least that's what Opera is claiming with the rollout of its new Opera Unite service. It will allow users to serve up web pages from their own computers.

Why would you want your humble desktop to serve up web content? So far Opera doesn’t have much of an answer to that. The sample apps they offer – a “fridge” to post notes to your friends, a way to share music with your friends – don’t exactly scream revolution or Web 5.0 (as Opera likes to refer to the service).

You might also be wondering what’s so special about Opera Unite; after all there is nothing new about being able to run a web server from your computer. Opera itself has supported BitTorrent for a while. And anyone can stitch together a webserver with Firefox plugins or just enable one without going through a browser.

What Opera Unite does is present this functionality to users in one unified service. People who would never dream of firing up a web server on their own might be tempted to give Opera Unite a whirl. Opera seems to be betting that user-friendly client-side content hosting can buck the trend towards increasingly hosted apps.

OPERA LEADS…WILL OTHERS FOLLOW?

Some of Opera’s early features have been adopted by all major browsers. There are accounts of everything from tabbed browsing to private browsing having originated with Opera. So although Opera has a very small user base outside of the mobile world, a successful Opera Unite service could be rapidly mimicked in other browsers. Will Opera Unite usher in a new era where every computer acts as its own server? Has the democratization of the cloud finally arrived?

I wouldn’t bet on this for a couple of reasons. In the enterprise, security concerns will prevent widespread adoption (more on security in a minute). And in the home, there are some basic performance issues that make me wonder if this will really fly.

Let’s start with the home. The most obvious problem is that for a server to work it needs to be powered on. Many people turn their computers off to save power and to be environmentally friendly. Strike one against Opera Unite.

Strike two is that many ISPs hit users hard on upload speeds. Anyone who has tried to use an online back-up service knows that there is a huge difference between uploading a gigabyte of data and downloading it. When I tried to check out Opera Unite’s demo page it was painfully slow. That might have to do with the sheer number of visitors the page is getting today, but it doesn’t bode well for future performance.

HOW TO SECURE A SERVER IN YOUR LIVING ROOM…

Which brings us to security. Opera Unite is by no means the first Web 2.0 service to expose the computer in ways our Web 1.0 ancestors would have found difficult to fathom. Browsers like the Mozilla-powered Flock and others already have their fingers deep into a user’s credentials.

Let’s dive into a few specifics of how Opera handles security. On the interface level, the awkwardly long URLs users need to type will certainly be an attractive target for spammers and phishers to exploit. Users have the option to password protect pages, but since the password is stored in the URL this offers very little security on shared computers. And the under-the-hood security isn't any better; it doesn’t seem like any of the traffic between clients is encrypted, which is to be expected because managing the certificates would be a mess.

For home users none of this is really a big deal; most users running a casual web server out of their living room are either not very security conscious or don’t have very high sensitive data sitting on their machine. But it is another strike against the notion of using Opera Unite in the enterprise.

In the interest of fairness, there is one nice security feature in the current experimental build of Opera 10.0 – Opera Unite is disabled by default. This is a good way to protect users who have no desire to run a web server on their computer.

IN PRAISE OF THE MANAGED CLOUD

Companies often worry about the cloud because they feel they lose control of data and the surrounding security measures. It's tough to lose control, but in reality most cloud providers are much better at providing security than the average enterprise. So for a small to medium sized business, their data is probably safer hosted in the cloud than hosted on site.

This calculus is even more true of home users. Most home users are incapable of managing their desktops, let alone a server. Opera users – like Firefox users – are probably more tech-savvy as a group than IE users. But even so why go through all the trouble of configuring and securing your environment locally when you could just use a hosted service like MobileMe, Facebook, Flickr, or any of the hundreds of other services that exist in every flavor and price point? When I watch a video on YouTube, I am reasonably confident that it does not come with malware. When I watch a video that is being served up from my buddy’s desktop, that level of confidence drops pretty dramatically.

Of course the big disadvantage of hosted services is ownership and control (a good example being the recent failed attempt by Facebook to drastically change its Terms of Service). But my feeling is that, at the end of the day, most end users don’t really care that much about control. They would rather have the advantages that come with the cloud – including automatic backups – than worry about the intellectual property issues surrounding their vacation photos.

That being said, Opera Unite could become very successful for casual home use, particularly as a means of regulating P2P data exchange. And if the developer community steps up to the plate there may be some very handy apps supporting this. The lack of security features is not an issue for the casual user and is not a significant factor in affecting adoption.

But even if Opera Unite scores with home users it does not seem likely to be a candidate for serious enterprise applications. The enterprise client is getting thinner and thinner and I can’t really see Opera Unite stopping that train.

China Votes For Endpoint Security

noreply@blogger.com (Boaz Gelbord) — Fri, 12 Jun 2009 02:45:00 +0000

China is setting up a green dam to help prop up the great firewall.

The green what? The full name is even weirder - The Green Dam Youth Escort. It's a piece of filtering software the Chinese government is requiring to be shipped with all computers as part of its "anti-vulgarity" campaign.

China has been keeping a tight grip on the Internet for a long time. But the Green Dam project marks the country's first widespread attempt to control activity from the actual computer itself. No longer content to just monitor and block network traffic, China's maneouver is a surprising declaration of faith in the importance of endpoint security. Cloud advocates tell us that the endpoint matters less and less, but the world's most populous country seems to be moving in a different direction.

Before we draw too many conclusions, its worth noting that so far the system is not working too well. The Green Dam suffers from the same problems inherent in any massive effort to control the endpoint (kind of a mega FISMA with actual client side software). For one, there are obvious security and performance concerns involved in such a mammoth roll-out. Global Voices has an interesting translation of Chinese language posts about the problems ordinary Chinese are experiencing with the software.

So it's easy to dismiss the Green Dam Youth Escort as a futile project with a really dumb name. But people who mocked China's early efforts to control the Internet as doomed to failure have largely been proven wrong. Despite the apparent ease of circumventing the "Great Firewall", China has been largely successful at controlling and monitoring great portions of its Internet traffic.

The Chinese government has not released many details on the planned scope and implementation of the Green Dam system. There are certainly early indications that the planned Green Dam filtering extends beyond adult material to include political terms as well. It is also unclear whether there will one day be a NAC-type system in which only devices with an approved Green Dam agent are able to connect to the Internet. So far the only government requirement seems to be that the Green Dam software simply ship with the product. But it's hard to imagine that the government intends to rely on voluntary compliance after mandating the software distribution.

The Politburo Votes for Securing the Endpoint

China clearly sees value in controlling the endpoint. While other countries have relied strictly on network methods to control illegal content (such as Australia's recent flirtation with net filtering technology), the Green Dam project marks to my knowledge the first - and undoubtedly the largest - attempt to control content from the actual endpoint.

This is not a political blog so I don't want to get into the very dicey ethical question of whether hardware manufacturers should follow network and service providers in aquiescing to the Chinese government's demands (some justify their compliance by arguing that even a censored Internet ultimately promotes democracy). But aside from the significant human rights issues involved, it is interesting to consider the IT security lessons that China's move holds for enterprises trying to control their own content and traffic, albeit for much different reasons.

More than anything the Chinese move is yet another indication that perimeters and client machines still matter. China's previous model was more or less endpoint agnostic - the idea being that if you were surfing stuff the government didn't approve of, this would be detected or blocked at the ISP level. China now seems to be less confident in that approach. The powers-that-be seem to have decided that even with 30,000 censors the best place to nip things in the bud is right at the user's machine.

Why the Endpoint Still Matters

It's not only in China and the world of Green Dam Youth Escorts that the endpoint still matters. In many enterprises, there are vigorous debates on the role of personal devices and the degree of access they may be granted to corporate networks.

In a theoretical de-perimeterized world, (as advocated by the Jericho Forum and others), the actual endpoint device is basically irrelevant. From a theoretical perspective this may make sense, but reality is much different. The end point still matters a lot for a few major reasons:

1. The Law. What physical machine you work on is often the legal distinction between stuff you own vs. stuff you don't own.

2. Standards and contracts. For better or worse, PCI clearly places much more emphasis on network and client side security versus other forms of security. A lot of RFP and contractual language has the same bias.

3. Forensics and Discovery. A company has a much easier time getting access to it's own computers than access to an employee's personal machine.

4. Management and Auditing. It is still way easier to manage a company device than do some clean-access check on a personal device. Especially for small and medium enterprises, NAC-type projects are often far too costly and complex.

Technical solutions will come up to address issues (3) and (4) above. But it is (1) and (2) - the legal and contractual world - that will keep the endpoint critical in the near term. While the future may be deperimeterized, this will require a tide shift in the clear network-centric language of most contracts, regulations, and standards today. It might happen fast when it does happen. But it hasn't happened quite yet.

In the meantime, the government of the world's largest IT user base is betting that the endpoint can deliver for its censorship and monitoring needs.

The Security of Bing

noreply@blogger.com (Boaz Gelbord) — Sun, 07 Jun 2009 00:42:00 +0000

This week Bing made its big debut. If you haven't yet heard of Bing, Microsoft has a 100 million dollar advertising campaign that should correct your ignorance pretty soon.

Bing hasn't yet hit prime-time. When I Googled the word Bing (ahhh...the irony) the first page of results still contained links to a surf board shop, a columnist for Fortune, and various complaints from the latter about brand name infrigement. That's going to change real fast (like by the time you are reading this), but it goes to show that Bing has a long way to go before it even begins to chip away at Google's dominance of search.

Bing has generally received good reviews - it seems to basically work (no repeat of the initial Vista disaster here) and is a refreshing alternative to Google. But suprisingly there hasn't been much talk about the security of Bing (except for a storm of criticism about the display of inappropriate material in search snippets).

Or maybe not so surprisingly. Most people think of cybercrime in terms of hackers and ID thieves. Search engines just search for stuff that's already out there. But the truth is that the vast majority of criminal and quasi-criminal activity on the web involves gaming the search engine system in one way or another. A lot of crime that just happens to use a computer gets incorrectly labelled cybercrime. But search engine crime (if I may coin a new phrase) is truly cybercrime.

How does search engine crime work? Take the term "hotels New York". Every week thousands of people book millions of dollars of hotel rooms by Googling those three words. Since people only pay attention to the very first search engine results (and almost never click beyond the first page of search results), moving just one spot up the list of results can result in a huge increase in revenue. The difference between being number 8 and number 7 in the Google results for any hotel related word has a very real and measurable price attached to it.

Enter the cybercriminals. Botnets are harnassed to create spam links to sites to raise their profile. Browsers are hijacked to redirect unsuspecting users. Content is culled from one site to another to produce hits in unrelated searches. Spam links are created dynamically on the basis of user input. There are literally thousands of ways of gaming the search engine system. Some are outright criminal, while others are just very shysterish SEO (search engine optimization) techniques.

Of course not all search terms have equal cachet. Take the term CISO (Chief Information Security Officer). A reader who stumbled on my blog by googling the term "CISO" pointed out to me that my recent post on whether companies really need a CISO is now the 5th highest search result for the term "CISO" on Google. Now while this blog has a healthy readership and has built up some decent Google juice over time, what this high ranking really goes to show is that there aren't all too many people talking about CISOs or competing for this term in search engines. Which kind of reinforces the point the post was trying to make in the first place...

But I digress. Let's get back to Bing security. My guess is the majority of all malware, viruses, etc are aimed at gaming Google search results. Now while most of these techniques work to some extent at gaming Yahoo and other search engines, the fraudsters are aiming to maximize Google rankings above all else.

How well has Google done in making it's search engine fraud and spam proof? Google has done pretty well with controlling gmail spam (despite recent glitches). But today Google search results are a mess - malware related sites are frequently misidentified and many common search terms point to malware. Just a bit of ~~Googling~~ - I mean binging around - makes it seems like Bing suffers a bit less from this problem. One reason is that Bing appears to provide less search results than an equivalent Google search. And the other more important factor is that cybercriminals have not yet honed their skills on gaming Bing.

Early indications are that Bing uses much the same malware filtering as other search engines. The web analytics market is already scrambling to understand the implications of Bing. Features like the (annoyingly slow) rollover function undoubtedly have serious implications in terms of both security and user behaviour. How these will be exploited by cybercriminals will have a major influence on the face of cybercrime in the coming months.

The Encryption Myth

noreply@blogger.com (Boaz Gelbord) — Wed, 03 Jun 2009 04:02:00 +0000

Rich Mogull had an interesting post yesterday about some trends he has been observing in enterprise security. Rich is a guy with his ear to the ground when it comes to what security processes and products companies are actually implementing. Reading his assessment on the state of encryption got me thinking about why everybody is talking so much about database encryption and why so few people are actually doing it.

There are three encryption trends in particular that caught my attention -

1. Laptop encryption is being commonly deployed

2. File and folder encryption is not in wide use

3. Database encryption is hard and not in wide use

Let's start with (1). Laptop encryption is the most no-brainer security mechanism out there for any organization dealing with personally identifiable information (PII).

Do the math. Your organization will lose laptops. Some will contain personally identifiable information. And these days whether you like it or not most thefts or losses will be high profile enough that your legal department catches wind of them. And at that point if they're encrypted your IT department fills out a new PO and everyone gets back to work. And if they're not encrypted all of sudden you have a potential breach notification situation on your hands. Which isn't the catastrophe that security vendors make it out to be (and nothing like the $200-per-lost-record myth you hear bandied around) but unpleasant nonetheless. And certainly a situation that is worth shelling out a few bucks per laptop to prevent.

What about (2) and (3) then? Why is almost no one encrypting their file folders and databases server side?

The truth is that you just don't mitigate that much risk by encrypting files at rest in a reasonably secure environment. Of course if a random account or service is compromised on a server, having those database files encrypted would sure come in handy. But for your database or file folder encryption to actually save you from anything, some other control needs to fail.

Contrast this with cleartext data traveling through a public network, where no further control needs to fail for your data to be compromised. Or in other words, depending on your definitions you could say that unencrypted Internet traffic is already compromised. This is why https is ubiquitous, while hardly anyone is using database encryption.

This is not to say that database encryption or file folder encryption is useless - far from it. For the compliance and audit kudos alone there is much to be said for implementing these solutions. But if you only have one play to make, you are much much better off leveraging your organizational capital to actually make sure that your servers are locked down, your database permissions are not too liberal, and that your developers are coding securely.

In good times it is easier to throw money (or a few extra DBAs) at a problem than to effect organizational change. There are organizations out there that have gone through painful database encryption implementations - with all the performance hit and complexity that comes with it - but have thousands of undermanaged accounts and weak configuration settings because the business owners of those processes are beyond the reach of the CISO. But during a recession, folks are only spending money when there is no alternative internal means of achieving the same goal.

There is also another simple reason for the failure of database encryption to hit prime time while laptop encryption is becoming more and more common. Database encryption - while kinda sorta required/recommended in PCI - doesn't naturally flow from any particular legal requirement. As Rich points out and as supported by the results of the OWASP Security Spending Benchmarks Report, compliance is the number one driver of security spending. Without a clearer regulatory paymaster, database encryption isn't heading anywhere in a hurry.

Locking Down the iPhone

noreply@blogger.com (Boaz Gelbord) — Tue, 02 Jun 2009 03:12:00 +0000

The Center for Information Security has just published a report on secure configurations for the iPhone.

iPhones are a thorn in the side of many security administrators. While locking down Blackberries and other devices seems natural, the whole point of the iPhone is to be fun and easy and free. The CIS report gives IT administrators 20 odd tips on how to lock down the devices.

(You need to provide your personal information to get the report here. Just scroll down to the part on mobile devices. Downloading the report from the CIS was an interesting experience. It's not often you are required to agree with a philosophical statement to be allowed to download a whitepaper - By using the Products and/or the Recommendations, I and/or my organization agree and acknowledge that: No network, system, device, hardware, software or component can be made fully secure)

Is the iPhone ready for prime time in the enterprise? Although some large enterprises are already using it, the vast majority of iPhones are still in personal - not enterprise - use. But there are signs that Apple is trying to piggyback on the success that Macs have had in making inroads in the enterprise beyond their traditional graphics and artistic constinuency.

The CIS report is a very good resource - in conjunction with the Apple Enterprise Deployment Guide - for any enterprise thinking of managing or supporting the iPhone. For each security recommendation, it lists whether the setting can be remotely enforced on the device.

The report splits the various security recommendations into two levels - level I stuff that your users will actually let you do, and level II stuff that you will only be able to get away with in a security critical environment.

Some of the level I stuff is slightly annoying to the user but otherwise pretty innocuous - require passcodes, enforce complexity, auto-timeouts, auto-updates and that kind of thing. But it is some of the level II stuff - disabling wifi, disabling Javascript, and other draconian measures that probably isn't going to fly with the average user. There's a lot of basic stuff you can't do on an iPhone without wifi. Why get iPhones for the enterprise if you can't do any of the fun stuff?

Although all the recommendations are useful for both company and (paranoid) home use, there is one structural vulnerability in mobile platforms that they do not - and by construction cannot - address. Many (I am tempted to say most) web attacks on a client/browser somehow involve the abuse of a logged in session or the data that a logged in session left behind. This isn't just XSS (Cross Site Scripting) and XSRF (Cross Site Request Forgery) type stuff, but the abuse of any stored credentials or data on the device.

Now your run-of-the-mill brick PC or Mac are of course theoretically equally vulnerable to this. But users intuitively have a better idea of what sessions are active, what services they are logged into, and what their browser is up to when they are staring at a big screen. In the case of the iPhone, they are even further limited by the user interface from seeing what is really going on.

On mobile platforms, there is an even greater danger to all these live credentials and logged in sessions than fancy XSS type attacks. It is the gazillions of sites that actually have the gall, the chutzpah - the sheer audacity - to use your login credentials to other sites to populate your friend requests or what have you. When you are simulateously logged into 8 social networks, your email, a bunch of bookmarking sites, and who-knows what else, there is a good chance that there is someone out there trying to cull your contacts or something out of one of the other applications.

This practice isn't even considered shady any more and may even be permitted by the terms of use. I remember being asked by LinkedIn (which I consider one of the more privacy friendly social networking sites) if they could have my email password so they could invite all my contacts to link in with me. The pop-up box came up so naturally that many users probably just hand over their password by instinct.

Let's circle back to the iPhone. The iPhone is fundamentally at this point still a end user device. One of the main appeals of the iPhone is that it doesn't feel like work. If Apple were to start tinkering with its default settings and configurations to satisfy corporate IT security policies, this would negatively affect the consumer appeal of the product.

It's also unnecessary. 90% of enterprises require reasonable, but not draconian, security (OK, I made that number up but there is no doubt that the large majority of businesses, even if they deal with sensitive data such as health care or financial data, do not require fortress like data environments). So for these businesses - where data and networks need to be protected but where collaboration, creativity, and efficiency are just as important - there is no need to ban devices like the iPhone as long as sensitive data stays off the device. It is easier to be liberal with devices and strict with the data that gets on them than the other way around.

Since most people are not going to be editing spreadsheets on their iPhone, the main entry point for sensitive data is the corporate mail network. A good example of the threat mobile devices pose is the emailing of sensitive information, and in particular large attachments with personal data whose loss would trigger breach notifications. Many enterprises still do not have corporate policies prohibiting the emailing of such attachments.

Emailing sensitive personally identifiable information is a bad idea for many reasons. It's just too easy to get into a situation that results in a data breach by someone for example emailing a file to the wrong address. But mobile devices (not just the iPhone) are yet another reason why this is a bad - really bad - idea. Many webmail programs like gmail download emails onto end devices without being prompted. Many times these are not encrypted at the disc level upon download. So the unencrypted data is sitting on these devices. But of course these devices disappear/get lost/get stolen all the time. Depending on the data, the circumstances, and the state, it is certainly possible that this would trigger a breach notification requirement.

For larger enterprises some DLP type solutions may help mitigate this risk, although these are very involved implementations. Although I don't often mention particular vendors on this blog, there is one managed file transfer solution I have been a repeat customer of that addresses this issue well. Accellion is largely marketed towards the large file transfer market, but it also provides a simple and auditable way to offload sensitive data transfer from email networks. There are also numerous other managed file transfer solutions that are active in this space. At the end of the day it's easier to manage file transfer than to manage employee mobile phones.

Maine Gives 7 Days for Breach Notification

noreply@blogger.com (Boaz Gelbord) — Sat, 30 May 2009 03:35:00 +0000

Maine is tightening the screws on its data breach law. Breaches will need to be reported within 7 business days unless the authorities request otherwise. The bill, signed into law by the governor last week, goes into effect in 90 days.

Maine is pretty much going at it alone by taking this step. The vast majority of the 44-odd states with data breach notification laws let companies decide what timing makes sense. Here's what most of them have to say-

The disclosure must be made without unreasonable delay, consistent with the legitimate needs of law enforcement… or consistent with any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system.

As far as I can tell, the only other state that defines a notification deadline is Florida (if someone else knows of other states please let me know). It gives 45 days after the discover of the incident and - unlike Maine - has stiff financial penalties for delayed notification.

The Maine and Florida laws might end up getting swallowed up if a pending federal data breach notification law is passed. It would pre-empt these state laws and gives no deadline for notification. The proposed federal law largely mirrors the prevailing state law language of avoiding "unreasonable delay". As this legislation is still under consideration and likely to change, now is a good time for policy makers at both the state and federal level to ponder whether breach notification laws should give hard deadlines.

Data Breaches and Reasonability

So who gets to decide what is a reasonable delay when notifying?
Getting notification in time obviously matters to consumers. The impact of identity theft is limited if consumers get the heads-up in time to take out a security freeze on their credit reports. ( Security freezes are available in most states and make access to credit reports much more difficult).

Deadlines aren't the only place that data breach laws refer to reasonability. Many states only require notification if there is a “reasonable” likelihood of identity theft resulting from the breach. I have written before about the way this has the ironic effect of punishing honest businesses with strong IT management. In borderline breach cases they are much more likely to notify than to make a questionable determination that there is no "reasonable" risk of identity theft.

Companies that don't notify never really get called out on it. The large majority of states still do not have a requirement for breaches that do not trigger a notification to be reported to the Attorney General or another state entity. Which of course makes it much easier to sweep repeated data breaches under the proverbial rug.

A judge recently ruled in favor of Hannaford in the lawsuit that data breach victims had brought against the supermarket chain in Maine. The judge cited the lack of a strict notification deadline, which may have prompted legislators to act. However the judge also cited the lack of a reasonable risk of identity theft in not awarding damages.

Identity theft is such a nebulous concept that it is very hard to measure when a reasonable risk exists or not. This is part of the reason that some state laws presume a reasonable risk to exist by virtue of the fact that certain personally identifiable information (PII) has been leaked. The one exemption that all states grant is for encrypted data, which has spawned an entire industry of full disc encryption products. But interestingly, the encryption the law talks about is very different than the encryption the vendors talk about.

Encryption and the Get-Out-Of-Notifying-Free Card

Security folks think of encryption in terms of DES, AES, RSA and other encryption algorithms that use public and private keys to encrypt data. Various algorithms have come in and out of fashion due to their vulnerability to mathematical attacks like differential cryptanalysis or real world attacks like differential power analysis.

Now let’s gently exit the world of cryptographers and enter the legal world. Most state laws don't define encryption at all, but when they do it looks something like this:

"Encrypted" means transformation of data through the use of an algorithmic process into a form in which there is a low probability of assigning meaning without use of a confidential process or key or securing the information by another method that renders the data elements unreadable or unusable.

But where’s the key? The minimum 128 bits? The ban on single DES? Turns out that for legal purposes, encryption requires some form of obfuscating. Doesn’t need to even involve a key. Doesn't even need to involve too many CPUs. You just need to make sure that the way you obfuscate and then unobfuscate is confidential.

So who's right? Should a lost USB stick with personal data encrypted by a simple vulnerable encryption algorithm (say single DES) require notificaiton? The purist/cryptographer answer would be yes. Does it require notification from a legal perspective? A lawyer would probably say no [although I am by no means a lawyer].

This time I think the lawyers are right. The risk of identity theft from personal information on lost media is already very small; after all, the person who finds a lost laptop, USB stick, or mobile phone is very unlikely to be interested in the data. Now suppose that data is encrypted in some light but ultimately breakable way. The likelihood of actual identity theft drops down to almost nil. What are the chances that the guy who found your iPhone on the subway is both interested in your data and capable of decrypting DES?

That's not to say of course that there isn't data that merits industrial strength encryption, especially when placed on a portable device. But for the purposes of breach notification in the case of loss, sometimes we do really need to keep in mind what is reasonable.

Botnets and Security Hype

noreply@blogger.com (Boaz Gelbord) — Wed, 27 May 2009 03:42:00 +0000

A couple of weeks ago a team at the University of California Santa Barbara managed to take over a botnet for ten days. Their fascinating and well-written analysis is well worth reading for an objective and first-hand look at how a botnet really operates.

So how did they do it? A botnet is just the overly sci-fi name for a bunch of computers that are controlled by a central command-and-control structure. The number one challenge for botnet operators is hiding their command-and-control servers to avoid being taken down (the chances of actually being arrested are pretty close to nil). The Torpig botnet uses an increasingly popular technique where client machines try dialling into a set of pre-determined domain names and accept the first server to respond as the botmaster.

This is where the UCSB researchers moved in - they took over the Torpig botnet by sneakily claiming the domain name that was the next in line to be the command-and-control server. The botmasters behind Torpig had not claimed all the domain names that their victims were meant to dial into, either to save money or because they didn't see this coming. In any case, the UCSB found itself in control of a botnet with hundreds of thousands of hosts.

Don't try this at home. The researchers cooperated with law enforcement and other entities to avoid legal problems. This appears to have helped them steer clear of the hot water the BBC found itself in a few weeks ago for actually purchasing a botnet from criminals.

Botnets and the Hype Cycle

You've probably heard botnets talked about on the evening news. Botnets are a particularly successfully marketed part of the FUD-cycle of the information security industry.

But how bad is the botnet problem in reality? Not as bad as previously thought, according to the UCSB team. Previous studies have counted IP addresses rather than actual hosts when estimating the size of a botnet. Getting from IP addresses to actual machines is tough - DHCP leads to an overcounting, NAT to an undercounting, and there are many other factors at play. In the botnet the UCSB team analyzed, they counted 182900 hosts versus 1,247, 642 IP addresses, and there is evidence that IP addresses generally overcount actual machines.

But in many security reports IP addresses and computers are treated synonymously - the latest MacAfee report actually contains the sentence "In this quarter we detected nearly twelve million new IP addresses, computers under the control of spammers and others". Arrghhhh...

Coverage of the UCSB work in the MSM did not mention the overcounting. "Botnets smaller problem than originally thought" doesn't make much of a headline...

So I'm part of a botnet, so what?

Good question. Theoretically, a botmaster could read your email and abuse your other accounts to their heart's desire. In fact, the UCSB researchers performed a keyword analysis of their victims' emails (not sure how they got the legal clearance to do that...). But they are probably the only ones who bothered reading those emails. Botmasters want control of computers to make money and not to read about your date last Saturday. When someone breaks into your house they steal your valuables, not your diary.

Most online accounts and credit cards do not hold their users liable for fraudulent charges. In this way botnets operate a lot like insurance fraud or old-school credit card fraud. They are an annoyance that creates an indirect cost for everyone, but a cost that is sufficiently low that people are willing to bear it. We live in a society where people want to be able to use a 16 digit number they have given out hundreds of times to pay for stuff. If that means that everything costs 1% more to deal with fraud, so be it.

Brian Krebs (who should be on your reading list if he isn't already) posted a piece today about the dangers of allowing your PC to be compromised. Reading through his list of spam, click-through fraud, DoS attacks, and the like, I couldn't get past the feeling of dangerous for society - yes, dangerous for the user - not really. As far as some of the more nefarious password stealing stuff, there is little to no evidence so far that botnets are actually using user credentials for anything other than non-personal misuse of a person's credentials. This isn't great for society, but isn't something the average user is going to care about.

Seems like just the kind of situation that calls for Uncle Sam (or Uncle Barroso)...

Laying Down the Law

The UCSB authors fault registrars for not sufficiently responsive to requests for taking down botnets. While ISP responsibility for content and traffic is a tricky political issue, the content industry has been very successful in forcing ISP accountability for peer-to-peer traffic on their networks. Of course the content industry has a bunch of well paid folks in Washington, Brussels, and other corridors of power pushing their agenda. Botnets do not directly affecting an entire industry's bottom line and so there is no lobbying effort to move responsibility from the client to the registrars and ISPs.

This could change significantly if the national security angle of botnets takes flight. The apparent role of botnets in Internet disruptions during the Russia-Georgia conflict last year, allegations of Chinese cyber-espionage, and frequent stories in the press about the vulnerability of critical infrastructure have attracted the attention of US policy makers. There are even signs that countries like China - long considered a safe haven for hackers - are taking regulatory steps to address botnets.

Regulatory measures will not completely address the botnet issue, but would potentially significantly change the risk/time-invested/reward ratio. Botnets take a high degree of technical expertise to set-up and are of only limited value. A tighter regulatory regime could significantly reduce the incentive for botmasters.

User Education

You often hear about user education in botnet/information security stories, which all too often is vendor-ese for user indoctrination to buy security products. But the UCSB researchers - who have done a great piece of research and aren't selling anything - also focus on user education as a solution to the botnet issue. Their statement that the "malware problem is fundamentally a cultural problem" places the onus for preventing complex and sophisticated criminal activity on the people least capable of preventing it.

It would be nice if all users were capable of being system administrators. For enterprise users, it is fair to expect a minimal level of technical skill. But the truth is that the technical measures a home user needs to take to secure his or her computer are simply beyond the grasp of significant portion of Internet users. The stuff you can educate home users about - choosing better passwords, not recycling passwords, etc is not going to make a real dent in the botnet problem.

Massachusetts Backtracking on Data Security Legislation

noreply@blogger.com (Boaz Gelbord) — Fri, 22 May 2009 03:44:00 +0000

If you haven't heard of the Massachusetts data security law, you probably don't deal with too many security vendors. My inbox is cluttered with invitations to vendor-sponsored webinars warning of the dire consequences of this law. This "game changing" regulation requires companies to "fundamentally re-assess how you secure your assets"

Of course this isn't true. There was no need to panic before. And now there's really no need to panic, because the Massachussetts legislature may be watering the law down much further. A proposed state senate bill, SB 173, takes almost all the umphhh out of the original legislation:

- it removes the encryption requirement in favor of technological neutrality

- it defers to (much weaker) federal law when relevant

- it basically give a free pass to smaller companies

I don't know what the status of this bill is, although it seems like there is a general consensus that the original law will be watered down one way or the other.

So if you just went out and bought a bunch of fancy encryption gear or log readers or other stuff, you might want to check the return policy. Those might be great things to have, but they are probably totally irrelevant to being in compliance with state and federal laws. There is this bizarre consensus that spending money is more important than re-engineering processes in securing data, when in fact the exact opposite is true.

In case you missed this, let me say it one more time - there is absolutely no need to buy anything as a result of the Massachussetts legislation. Not for big companies. Definitely not for small or medium sized companies. In fact for companies with limited staff buying stuff will probably do more harm than good. You would be much better off locking down the configurations and enabling security features on your existing big vendor stuff (your AD, Exchange Server, Oracle, and the like) than starting to learn how to use new toys.

This isn't supposed to be a rant against security vendors. But there has been a great deal of misinformation (to put it diplomatically) surrounding these regulations. The you-should-buy-productX-because-of-the-new-Massachussetts-data-law argument was absurd to begin with and is even more absurd now that the legislation is on life-support.

The problem in the security space is that there is no real counter voice to the fallacy that you can or should buy compliance. The vendors have an obvious interest in hyping the laws. The analysts stoke the fire. Technical security types can't be bothered to read through a bunch of regulations and so they reluctantly drink the vendor Kool Aid. And everybody else doesn't care because information security legislation - with all due respect to our industry - is among the least important issues being discussed in the United States right now.

Security and the Small Business

There's one part of data security legislation that I find a bit perplexing - the small business exemption. This basically says that any security measures you need to take are only relative to the size and complexity of your business. It is a central part of the Massachussetts legislation as well as most other similar regs I have seen.

Now I get that small businesses require protection from overbearing regulations and legislation. But you can't run a nuclear power plant with a team of 10 people (well, at least I hope there's no out there running a nuclear power plan with just 10 people). Is there a minimum number of people you need to provide adequate data security?

The answer is probably not, as long as you have outsourced both your operations and their security. Really huge famous companies can be shockingly small. In one of the articles about the Craigslist/South Carolina AG feud going on these days there's one detail that really jumped out at me. Craigslist has only 30 employees. To me it's mindblowing that a company with one of the most popular websites in the world and one of the world's leading brands is run by less people than were in my subway car this morning. Yet I haven't heard any one argue that Craigslist is unable to provide sufficient security, or that they should be given a break - or need to be given a break - on their data security.

But not every company is Craigslist. To securely operate a vast complex database with a lot of personal information either requires a lot of money or a minimum number of people. Most small businesses don't have the money and will always be under enormous operational pressure to dedicate staff away from security.