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.

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?

Securities Technology Monitor has a short list of risk questions for financial firms who are considering the cloud. Spoiler alert, they provide a list of eight:

1. Who Will Have Access to Your Data?
2. Will the Regulators Approve?
3. Where Will My Data Be?
4. How Will My It Be Kept Separate?
5. How Will It Be Brought Back?
6. What If Your Service Provider Goes Out of Business?
7. What Financial Applications Can Be Safely Put into the Cloud?
8. What About Executing Trades?

No surprises, except maybe for the fact that it’s a mixed bag of questions and they have no regulators listed in their sources of information.

SOURCES: Gartner, Accenture, Lime Brokerage, BT Radianz

Easy to tidy things up with some regular compliance-relevant concepts:

1. Data Inventory: Location, Access and Recoverability
2. Application Security
3. Regulatory Approval

Do they have to be questions?

1. Will you be able to maintain a Data Inventory: Location, Access and Recoverability?
2. Will applications be secure enough to protect you and your customers?
3. Will the regulators approve?

The “Hello Cloud” walk-through for Project Kenai gives an example of how “examining the virtual data center” with the Sun Cloud API would show rules on a VM firewall

  "vms": [
    {
      "name" : "Firewall"
      "uri": "/vdc/m~FW01",
      "run_status" : "HALTED",
      "description" : "Firewall appliance; ports 80 and 22 open.",
      "hostname" : "FW01",
      "os" : "Solaris 10",
      "cpu" : 1800,
      "memory" : 2,
      "boot_disk" : 10,
      "data_disk" : 80,
      "temp_disk" : 10,
      "params" : { },
      "tags" : [ ],
      "back_up": "/vdc/m~FW01/ops/back-up",
      "attach": "/vdc/m~FW01/ops/attach",
      "detach": "/vdc/m~FW01/ops/detach",
      "backups" : [ ],
      "interfaces" : [
        {
          "mac_address": "00:16:3E:08:00:91",
          "ip_address": "144.34.100.199",
          "public_address": "/addresses/144.34.100.199",
          "nic": "eth0"
        },
        {
          "vnet": "/vnets/10.31.145.0",
          "mac_address": "00:16:3E:08:00:92",
          "ip_address": "10.31.145.254",
          "nic": "eth1"
        }
      ]
      "controllers": {
        "start": "/vdc/m~FW01/ops/start",
      }
    }
  ]