Restitution for Hacks

I wrote earlier about a recent decision on computer fraud related to ATMs. I did a little history reading to jog my memory and see if I could figure out what about the case sounded familiar. I found Section 6-1 of my HP-UX System Security Manual, from October of 1989, with the following warning:

The U.S. Computer Security Act of 1987 casts new urgency on computer security in all business segments. It stipulates that if financial loss occurs due to computer fraud or abuse, the company, not the perpetrator, is liable for damages. Thus, ultimate responsibility for safeguarding information lies with individual businesses themselves.

Ronald Reagan’s Computer Security Act (CSA) was repealed by FISMA in 2002. Could it be relevant to today’s attacks?

The CSA was a reaction to the news of computer attacks in the early 1980s, especially by seven teenagers from Milwaukee. An eager Congressman from Kansas (Glickman) called House hearings that pointed out attacks were successful mostly because of weak and default passwords as well as of missing patches.

Here’s an amusing excerpt from InfoWorld in 1983:

…the FBI had implied that [a perpetrator] had violated the law when he sent electronic mail on the Telenet network. “We weren’t even aware that using the [stolen] passwords was illegal” he said.”

Obviously attacks have not changed much. What really has changed is restitution.

The major difference from pre-CSA regulation to today seems to have more to do with the liability of an attacker to pay for restitution than with any radical shift in system vulnerabilities.

Note the details in a case earlier this year. A man in New Hampshire was set to pay restitution of more than $2 million and forfeit another $8 million after running a four-year malware operation.

PALA and his co-conspirators infected German citizens’ computers with a program that would force the computers’ telephone modems to surreptitiously dial premium telephone numbers rented from German telephone companies by PALA’s co-conspirators. …from 2003 through 2007, PALA made approximately $7,941,336 from the computer hacking conspiracy. PALA also allegedly failed to pay approximately $2,287,993 in income taxes during this time.

Modems? He was expected to pay a hefty restitution to the IRS for undeclared profits from (unauthorised) dial-up fees.

Another interesting restitution case earlier this year was in Massachusetts, where a prisoner hacked the common computers and then was ordered to pay to protect the identity of other inmates.

Souter conceded that individual current and former employees could have paid for their own credit monitoring when they learned of the hacking, “but this in no way diminishes the reasonableness of the Facility’s investigation prompted by the risk that its security failure created.”

[Retired U.S. Supreme Court Associate Justice David] Souter rejected Janosko’s timeliness argument. “An employer-victim contemplating the resolution of a charge like the one here could be expected to press the prosecutor to demand any terms that would be necessary to make the members of the employer’s workforce whole, and a credit check even up to the moment of a plea agreement would therefore be timely,” he wrote.

The BofA case thus fits the trend of ordering a hefty restitution award from perpetrators. Unlike the time of the CSA the laws now seem headed towards large recovery awards, which some argue are disincentives to attackers. Hopefully the restitutions will not prematurely reduce the pressure to enhance technical controls.

ATM Malware Author Sentenced: 27mos in Prison

A US District Judge in North Carolina handed down the sentence to Rodney Caverly along with a restitution order of more than $400,000 (70% to cover the cash stolen and 30% — over $100,000 — to cover “costs incurred by BOA” to remove the malware)

According to court records and sentencing proceedings, Caverly, who was hired by BOA to design and maintain its computer systems, had been assigned to work on a project involving the bank’s automated teller machine (ATM) system. Filed documents and court records show that from March 2009 to October 2009, Caverly knowingly and with intent to defraud exceeded his authorized access by gaining access to one or more protected BOA computers and deployed a malicious computer code to select BOA ATMs. The malicious code caused a limited number of infected ATMs to disburse cash from the ATMs without any transaction record of the cash disbursements. The code Caverly entered caused only the unauthorized disbursement of cash stored in the ATM machines and did not affect any financial accounts of BOA’s customers.

The charges were filed April 1, 2010 but the attacks started in early 2009, months before Barnaby Jack was to present at the BlackHat conference:

In the description of his talk on the conference web site, Jack wrote that, “The most prevalent attacks on Automated Teller Machines typically involve the use of card skimmers, or the physical theft of the machines themselves. Rarely do we see any targeted attacks on the underlying software.”

Jack’s talk was cancelled due to controversy over the timing.

…the affected ATM vendor has expressed to us concern about publicly disclosing the research findings before its constituents were fully protected. Considering the scope and possible exposure of this issue on other vendors, Juniper decided to postpone Jack’s presentation until all affected vendors have sufficiently addressed the issues found in his research

The vendors were given more time, but by early 2010 another case was filed, related to a North Carolina grocery worker planning to manipulate the software on 31 ATMs.

To prove to Brian Martin that Morris knew what he was actually in a position to gain unauthorized access into the specific Tranax ATM machines, Morris sent Brian Martin a manual titled Tranax_MB_Operator_Manual that describe the key sequence to enter the specific ATM machine’s programming and then the master password. Morris also sent Brian Martin two other manuals on how to gain unauthorized access into another type of ATM machine and a manual for a supermarket/store point of sale credit/debit card processor.

When Jack returned to the conference in the summer of 2010 he finally was able to present his views but with a very different tone. He no longer was talking about rareness of targeted attacks on software, but rather the ease of a software attack.

Every ATM I’ve looked at, I’ve found a game-over vulnerability that allows me to get cash from the machine.

To sum it all up, the very large amount of restitution money ordered for “costs incurred” may not be just to fix Caverly’s bad code…it also may be influenced by an effort to secure ATMs against outsider attack methods that are increasingly public.

NIST Cloud Computing Standards Roadmap

The near final draft of the NIST Cloud Computing Standards Roadmap has been posted. I submitted a lot of updates and this paragraph stood out to me in particular:

Auditing is especially important for federal agencies and “agencies should include a contractual clause enabling third parties to assess security controls of cloud providers” (by Vivek Kundra, Federal Cloud Computing Strategy, Feb. 2011.) Security controls are the management, operational, and technical safeguards or countermeasures employed within an organizational information system to protect the confidentiality, integrity, and availability of the system and its information. For security auditing, a cloud auditor can make an assessment of the security controls in the information system to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.

It might not be wise for me to draw the attention of a man who pretends on TV to play Russian roulette with a nail gun, but the above paragraph indicates to me that Google’s cloud campaign spokesman may be headed for trouble.

Eran Feigenbaum, who is apparently also known as a Television magician or “mentalist”, has boasted on numerous occasions that customers do not get to audit Google. He has even said if customers need to audit an environment, Google is not the right place for them. Anyone who wants assurances about things like password protection is told to read their SAS 70.

So, I wonder…if Feigenbaum were selling houses made by Google would he say “you don’t get windows, you just get a list from us of what’s on the other side of this wall: tree, grass, bird…it’s all there, trust us”? They appear to be floating a non-standard definition of transparency.

We’ve been very transparent about our FISMA authorization. Our documentation has always been readily available for any government agency to review, and dozens of officials from a range of departments and agencies have availed themselves of the opportunity to learn more about how we keep our customers’ data secure.

What does it mean to be “availed of the opportunity to learn more”? I had to look up Feigenbaum’s experience with compliance and information audit to get some perspective. His public profile says little other than he spent a couple years as a sales engineer before jumping to a CISO title at a consulting firm and then Google. Surprise. Not transparent. Did I avail myself of the opportunity to learn more?

So, it will be interesting to see if/how cloud providers will change their messaging around audits if NIST avails themselves of this opportunity to push through their draft definition:

…agencies should include a contractual clause enabling third parties to assess security controls of cloud providers.

Amazon has adjusted itself already to the PCI DSS, which requires auditors on-site. Can Google catch up?