Heading to Las Vegas

Here I am going to Las Vegas for Black Hat and DefCON again! It's funny that this time I have really lower expectations for the event. My feeling from the last news in the field is that it's too much the 0-day of the week and buzzword contest (APT/Cloud). Anyway, it's always the place to be when talking about information security, and I hope to be wrong about it. It will also be a great opportunity to meet friends and colleagues. If you are there, please feel free to drop a tweet (@apbarros), I'll be tweeting live there.And let's see that B-Sides stuff. Honestly, from what I've seen from the last editions and the current schedule, it may become the A-Side quite soon. 

SCADA worm!

As everybody in the field had predicted, malware targetting SCADA system has finally come true. The lucky thing is this one is looking for information to steal only, not actually doing anything. I wonder what outcome could we have if this nasty little thing was designed to force systems to fail.

SCADA systems are one of the most critical blind spots in organizations Today. Few people have access to then and know how they work, so there is a false perception of security about them. Specialized systems, such as SCADA and ATMs, often rely on obscurity as their main security strategy. It's not even something done intentionally, but as result of a neverending vicious cycle. Internal security resources don't know about security on those systems and the specialists in that technology don't understand security. You can think about hiring external consultants to check the systems, but the consultants also don't have much contact with that technology. Of course they won't tell you that, they will run their off-the-shelf tools anyway. The results will tell you nothing, what you will interpret as "secure", perpetuating the notion that there are no security issues with that technology. As there are no security concerns there, the security team won't spend time learning that technology and the specialists will keep saying that this security thing is for those Internet-web-2.0-cloud-stuff guys. Until the next Black Hat briefings or sexy malware.

I wonder when this is going to hit the old mainframe. I must say it will be fun to watch.

Visa push for truncation and tokenization

It's good to see that Visa is putting additional pressure for truncation and tokenization of card numbers. However, "PCI DSS solutions" in general cost money that the merchants and service providers in general don't want to spend. They make sense from a technical point of view, but they incur in costs that would eventually drive those organizations away from them.

 

Now, just food for thought: what if the card brands (Visa, Mastercard, Amex) started to offer tokenization services in a cloud based way? The merchant could just use the service to get tokens directly from Visa, who would be responsible for storing the real numbers and providing merchant specific tokens through a web service. The concerns related to hosting that data to a third-party wouldn't be relevant on this scenario, as the brand already has all those numbers anyway. The brands also have their networks already in place, that could also be used for "token request" transactions for the organizations that have big pipes and gateways to those networks and don't want to create a dependency between their highly available payment systems and their Internet connection.

 

Visa could also use it for additional fraud prevention services (although it could also generate privacy related issues), by correlating the last request for a specific number with the fraudulent payment authorizations using that card. It would also remove the operating and technology support costs from the tokenization solution from the end-user organizations, making it more attractive to be implemented. 

 

What do you think of it? Does it fly? 

Cryptography and the wrong problems

I was reading Schneier's blog Today as he posted an old text he published on Dark Reading back in 2006, about Cryptography usage. It's interesting how an article of four years ago is still very relevant. I've been seeing some cases where people considers encryption as the most appropriate control to implement, when access control is really the key."Much of the Internet's infrastructure happens automatically, without human intervention. This means that any encryption keys need to reside in software on the network, making them vulnerable to attack. In many cases, the databases are queried so often that they are simply left in plaintext, because doing otherwise would cause significant performance degradation. Real security in these contexts comes from traditional computer security techniques, not from cryptography."Those cases show how frequently controls are implemented in a checklist-based approach, without any attempt to do a threat based assessment first. As Einstein said once, "things should be made as simple as possible, but not any simpler". Although I am among those that think that PCI DSS is a step in the right direction, there are clear misconceptions that come from the heavy push towards encryption in that standard. Applying the wrong control for a threat is as bad as an inefficient or non-existent control, or even worse, due to the false sense of security, added complexity and cost. I'm sure that checklists can help us with the most basic stuff, but when we start touching things such as database encryption, I don't believe we can apply a checklist-based approach.