Security Scoreboard is Live!

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

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

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

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

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

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

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

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

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

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.