crowmoor.se

In a Swedish article today they describe a case of skimming at an unmanned gas station. This has become rather common nowadays with new cases found weekly. This is just in line with my previous posting on the subject. One would suspect that more of the oil companies would have updated their payment systems but sadly not. In some cases it boils down to bad internet connection, cost of authorizing every transaction and the cost of new technology but sadly in many cases it is all a matter of the cost of upgrading versus the costs for fraud. PCI DSS fines are rising. I wonder when the oil industry will be hit by VISA/MasterCard.

Forrester reports are always interesting to read. I cannot say that I trust them all of the time but they do often point in the right direction. Just recently I found a report showing the % of retailers in US that have been fined, currently 8% with 27% more that have been threatened with fines. As US often is the frontrunner when it comes to compliance this will of course spread to Europe soon. Currently I know of several retailers in Europe that are stalling their PCI DSS projects as their acquirer has not engaged them further to reach PCI DSS compliance.

This of course leads to that card security has stalled in Europe as well. Last figure I heard was that 3 300 000 cards was stolen I Europe every week from retailers. Let’s hope the number goes down fast.

One of the most important tools I use when working with security is reference architecture. It really helps me speed up my projects. So what is reference architecture? It is as simple as a visualized description of the best way to solve a problem. So whenever I am to implement PCI DSS, ISO 27001 or any other compliance or if a client asks me about the best way to implement remote access solutions I bring up my diagrams and start mapping.

Best thing is that I directly find any possible flaws in the solution they are proposing making me seem to be extremely knowledgeable. 😉 But in the end it is only a thing of understanding the best way to do something and then adapt it to map the client’s possibilities in their current setup. If you are not working with reference architecture then you are bound to be doing the same errors over and over again in a very slow pace.

Where do you find reference architectures? Some are proprietary like the ones I have created. Others are readily available at for example www.opensecurityarchitecture.com.

I have worked several years with PCI DSS and even if I am not as experienced as some QSAs I know I do have a kind of experience they don´t, working with security from a business angle. In one assignment we were looking into several possibilities to make the client PCI DSS compliant. One of those routes was to implement a payment service provider everywhere payments were handled. At first glance this looked like the best solution. There was an added annual cost of 1.2 M€ but that should be matched towards the 40 M€ it would cost to changes the systems to become compliant.

So, what was the deal breaker here? Fraud. The payment provider could of course handle credit card fraud in all ways possible and imaginable but what about fraud specific for this industry? Nope. In case my client couldn´t use credit cards for investigating fraud between different payments they expected fraud costs to rise with 2-8 M€ annually. Now the 40 M€ looks much more promising.

Finally when we looked at the solutions to become compliant we found yet many more ways to decrease the cost hitting ROI much faster than imagined in the first place.

BBC ran an interesting article today regarding how easy it is to take control of a car even when it is in motion. The scientists says that it is a rather difficult attack for the common man but something we all learned is that when it is hard in the beginning soon enough there will be a tutorial on YouTube and exploit code to download at different sites.

So, what’s the problem from an architectural point of view? This is a quite easy one actually. If you have an application that communicates someone will try to communicate with it. There for you need to implement secure coding. Any application will at one point attract a malicious user’s attention and if you are not writing secure code…you are history.

In this specific case we could have a rather interesting situation when it comes to insurance fraud. “I swear, the breaks didn´t work anymore. The car must have been hacked! BTW my laptop was lost in the crash. It must have flown out the window and disappeared with an elk.”

So Writing secure code (read the book) and implement SDL: Secure Development Lifecycle (read this as well) is something you have to do in all projects from now on. To use one of my favorite commercials: Just do it!

In a Swedish newspaper today they ran a story regarding identity theft. A woman´s drivers license (the main identification in Sweden) was stolen and used to take out credits in here name. They got several thousands of SEK before she finally understood and contacted “Upplysningscentralen”, UC where you block the possibility to take credits in your name.

Usually an identity theft stops here but not in this case. The imposter sent a new application to lift the ban to take out credits in her name. During the same time they had her mail temporary stored at the post office where they, with the same drivers license, was able to confirm lifting the ban and then take out credits for over 100 000 SEK.

So where are the problems here? The obvious is that the ID was not checked enough by any clerk where they managed to get credits. Even if an application exists that should be used for checking the ID against UC it is not always used. Secondly there is no way to distinctly tell that a single ID has been used for fraud. When the woman got her new ID it looked exactly as the first one. Third and most important, relying on mail service for security is still very unreliable. The possibility to have mail stored at the post office is of course very convenient but there has to be a check to UC if this should be allowed for the single client.

No one in Europe has missed the fact that there is a volcano erupting spewing out ash all over Europe grounding virtually all flights here. This has of course put a strain on a lot of sectors. During media coverage there have been the usual comments but one thing that became very visible this time was all the domes day prophets crying out that we are going back to the sixties, no planes will leave the ground for years and a lot of flight companies will go broke sending us back into a recession.

This is actually not far from my own industry. I don´t know how many times I have read risk analysis pointing out one risk after another with this or that probability but very seldom I find a follow up report that actually investigated the risk analysis prognosis and compared it to actual facts.

Could this be to that logging of incidents is not taking place or that incidents are kept so well hidden that not even their management gets the reports due to the information is classified? I prefer the Apache approach giving full disclosure both on what happened and how the mitigate the problem again. Information is our best weapon in the battle of security.

Sadly not. There are a number of compliance frameworks out there now; PCI DSS, SOX, HIPAA, HITECH, Part 11 and you name it. It is a rather interesting fact that there are as many consultants being specialized in that one or the other without having the faintest idea that they are all the same!

Take a look from a bit of a higher ground and you see that all of them manages risk, manages the most common security problems in a sector, manages what the industry believes is the big problems right now. A year ago I was engaged in a large PCI DSS engagement with a customer and when I during a workshop explained that when I work with a compliance framework I always aim for being as compliant as possible with security mechanisms in a security architecture that supported the common problems all listed in the frameworks, their security department all in unison became silent. Apparently this was a way of thinking they have never encountered. So after a few very constructive workshops we have drawn the first lines in creating a security architecture built on a generic compliance structure.

If you have a good modeling language it is rather easy to perform this task but you really need to have a firm grasp of security otherwise you will create a rigid set of unreachable rules.

Security is a very interesting subject. Quite often I get questions regarding the connection of security policies, security mechanisms and technical solutions and when and where to have those. My answer is as always: It depends. That said the real issue to handle is how you would like to handle your rules.

A rule has two properties; how it is monitored and how breaking it is punished. Any rule without any of those will inevitable be disregarded. Take a simple thing as walking towards red light at a crossing. The law in Sweden states that it is not allowed, but there is no punishment if you do. Hence the law is toothless and therefore is broken on a daily basis. Same thing with speeding; most of the time there is no monitoring on your speed making a lot of people driving faster than allowed.
This is true for security as well. Creating a security policy that does not handle monitoring of it and doesn´t have any actions if it is disregarded is not worth the computing power used when writing it.

A rule is only in effect if it is monitored and if there is an enforcement on it.

I have now published the Jericho Books on my blog. You´ll find them at the top page named Jericho Books.