Last month I wrote about the shift in threats to ATMs. Explosives and cash trapping are on a sharp rise. The ATM Security 2011 conference in London confirmed this but also speculated that insider threats using malware attacks also will rise.

The conference highlighted that 80% of unauthorized withdrawals against European chip cards now come from American ATMs. It also had a couple presentations with control suggestions for solid and gas explosive attacks.

The increase in the number of ATMs in unsecured locations has presented criminals with new opportunities for brute force attacks such as burglaries, explosive attacks and ram raids. This case study will show how the use of an indelible security ink can successfully mark cash as stolen in the event of an attack.

But the most interesting ATM security news of late is an announcement from the Banque Populaire du Rwanda. allAfrica reported yesterday that people with a mobile phone and without bank accounts can now withdraw money from the ATMs using only a denomination and a PIN-code:

[The Bank’s Head of Marketing and Product Development, Richard Ndahiro] explained that a BPR account holder can send money from his/her bank account using a phone to the receiver who gets a pin number and the amount.

“The receiver pushes a pin code and amount received on the mobile phone on any BPR ATM to access the money,” he said, explaining that the bank has introduced alternative banking channels and streamlined its operations for better services.

Currently, BPR has over 1.4 million clients, with 190 branches….

It is free for both sender and receiver. Of course mobile phones may be shared, so it could be people without mobile phones and without bank accounts can withdraw cash from ATMs. In other words cash can be withdrawn without any trace of identity information for the cash recipient. This seems to be a new direction from the South African FNB system, which used mobile phones as authentication to replace ATM cards, and quite unlike the fingerprint requirement of NCR.

While the card brands say America is past the tipping point for chips to be added to cards to reduce cash withdrawal fraud, Africa appears to be quickly headed towards obsoleting cards altogether.

Massimo Re Ferre’, vCloud Architect at VMware, has posted an excellent article on Custom Portals and Backend Integrations in a Service Provider Environment

VMware, and the ecosystem as a whole, is coming out with a number of tools that interact with the vCloud APIs natively. VMware vFabric AppDirector is another good example of these tools consuming these programmable interfaces. I encourage you to have a look at the brief demo video available here.

If it isn’t clear yet, this is the reason for which developing a ton of logic right above the vCloud APIs isn’t a good strategy if SPs want to offer a VMware compatible cloud service. You want the vCloud APIs to be widely available and well exposed. Not obscured by “a ton of scripts and workflows”.

Another thing to consider before building custom logic is the associated risk of customization. Yes, this is the same old build versus buy debate but in context of security risks and how they relate to compliance. Generally speaking compliance is more complicated and expensive with customized portals. I will give several examples of this in my presentation at BayThreat.

There are many interesting elements to the recent decision on the RockYou.com case (Claridge v. Rockyou, Case No. 4:09-cv-06032-PJH) as clearly explained on the Data Privacy Monitor blog. Here are just a couple examples:

1) The company was found liable, due to marketing language found in their public privacy policy, for not preventing a breach.

The court’s decision also provides a practical consideration when drafting limitation of liability clauses for website privacy policies. RockYou.com’s privacy policy provided that: “RockYou! . . . assumes no liability or responsibility for . . . (III) any unauthorized access to or use of our secure servers and/or any and all personal information and/or financial information stored therein . . .” RockYou.com argued that this provision barred the plaintiff’s breach of contract claims. The court, however, found that the policy language did not automatically preclude the claim because the plaintiff alleged that the servers were not secure.

The servers stored passwords in plain text. The breach was based on a SQL injection attack that simply dumped all the passwords. Definitely not secure.

2) While the court dismissed 8 out of 9 complaints they still heard the plaintiff’s argument that PII loses value (e.g. harmed) if breached. It ended in settlement but the plaintiff’s argument was left standing.

The proposed settlement is very modest—under the proposed terms RockYou: (1) consents to a 36-month injunction during which it will retain a third-party to conduct two audits of its security policies concerning consumer records; (2) agrees to pay the plaintiff $2,000 as well as the plaintiff’s attorney’s fees of $290,000; and (3) represents and warrants that it is financially unable to provide the monetary relief sought by the plaintiff. Because only the plaintiff’s claims would be dismissed with prejudice, other putative class members may still assert claims for monetary damages. It is important to note that the proposed settlement does not vacate the district court’s April 2011 decision, leaving it of record for other plaintiffs to reference in future putative class actions.

Ok, so the $292K is really $290K in legal fees — maybe RockYou.com put up quite a fight before settling. But they left themselves, and other companies, open to face others who want to make the same arguments.