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.