crowmoor.se

After 9.5 years I have decided to leave Capgemini and try my wings in an own company. The 1th of January I and Hans Hjertsäll together with Ekelöw, a company within the information security business, started Coresafe. We will focus on compliance and security architecture delivering turnkey ready PCI DSS infrastructure that is cloud based.

But I will still of course blog here twice a month. I enjoy it and hope you are too.

Having a large family puts a constraint on available cars on the market. Not all cars will let seven grownups, teens and kids ride comfortable. Having that said I started to look around and eventually found a car that was just what I needed. When starting to discuss the car with the dealer I experienced a funny thing. For the first time ever I understood more about the inner working than he did. No, I haven’t read more about cars; I just know quite a lot of stuff in electronics and computers.

I created a presentation with a few colleagues a few months ago we named: How about an unstealable car? We took a modern car with all its gadgets and computers and applied Jericho Style Security on it. I can´t say that it is possible to build but it sure was an interesting experience to see that Jericho holds true even if applied to everyday objects, not only it-systems.

Going back to the poor car dealer, I asked him several questions regarding internal communication, possibility to access the onboard computers and so on…I got the car quite a few €100´s cheaper.

During my years working with compliance one thing that have become very obvious is the hard work needed to get old infrastructure compliant while new is like having an ice cream in the sun. I recall working at a client many years ago where we were arguing if an old till system should be upgraded or not. The question was to invest €500 000 in a new system, PA DSS compliant from start, or to spend at least €400 000, testing not included and no guarantee for compliance. The point of arguing was actually not the cost but that a bunch of developers would lose their job supporting the old system. As you could imagine they picked up on every single thing that could be a glitch and made it look like Armageddon at least. In the end I won, exhausted but happy! Why? Because we got all the information we wanted out of the developers, information they didn´t want to give us in the first place.

I have recently started to create a generic compliance architecture for all types of compliance. As you easily understand I immediately ran into some problems. The obvious once is of course that some compliance focuses on confidentiality, like HIPAA and PCI DSS, while other focuses on integrity, like SOX. Another challenge in compliance is not only the CIA-triad but what the compliance structure focuses on. In some cases the focus is on only a few information objects and in some others it the whole business that needs to be compliant.

The strategy for reaching compliance is of course different depending on the type of compliance and how you would like to run your business but in general a single information object compliance, like PCI DSS, is more suitable for minimizing the scope or outsourcing while a compliance scheme that affect the whole business, like ISO-27000 (yes, I know it is not mandatory), demands a more holistic approach.

Several of you are surely using different payment services on internet where you could register your credit card and then use the service instead of putting your credit card at risk. It is also possible to accept payments using those sites but sometime there are mistakes made and the account is suspended. Such incidents are constantly ongoing and there are loads of websites like [yourfavouritpaymentproviderehere]sucks.com etc.

So, why are there incidents? First of all, when conducting log and pattern analysis, there is a tremendous amount of data that needs to be analyzed. You probably start off with a working theory or a best practice and go from there. This method is quite often useful but contrary to formal science you seldom challenge your theory but instead build your whole case on it. If it is flawed you won´t find it until mistakes are made and then it could be too costly to change the analysis, hence the payment provider problems.

To mitigate this you should always make sure to either include a process where you challenge your assumptions or better yet have someone challenge you to make sure that flaws are found early. Our brain is a wonderful tool for pattern recognition but it always makes a best guess based on available data.

Today I had a chat with one of my favourite security consultants in UK. He told me this amusing story about a company where he was supposed to implement Encase Enterprise Edition. When having a meeting with the network guys for pushing out the software as any other software the network guys immediately said: ‘No, our network cannot handle that amount of data.’ End of discussion one would think? No, my friend, who is very resourceful, just simply told them: ‘I have already pushed this out to 10% of your computers without you even noticing it so I think your data of network load is flawed.’

This of course made a few nervous laughs around the table and the matter was never brought up again but the story points at a very specific point: Knowledge. It is so common that security decisions are based upon none or, even worse, bad data. Just take something as simple as a risk analysis. Not even that is done at many companies before investing in a big IAM system. Not to mention that many PCI DSS engagements don´t incorporate a risk analysis and what the cost would be in case of a breach. This information alone would help govern towards a better implementation of PCI DSS.

So make sure you have the data, that you create your risk analysis and that you have measured your environment. Otherwise you will be spending money on something that is not a risk and vice versa.

Having worked with compliance for many years several patterns have emerged and during the last year I have been creating different guides on how to implement a PCI DSS compliant infrastructure. Those guides have proven to be quite effective and just a few months ago I started to look at the possibilities to deliver Compliance as a Service.

If you search in it you´ll find several nice articles that all point in different directions but all ends with: It is a nice idea but really hard to implement.

From the point I´m coming at, being skilled in many areas, I strongly believe that they are wrong. It is not hard to implement, it is the understanding of what you need to do that is hard. Sometimes security is just to know which key to turn or who´s opinion you need to change. It is my firm standpoint that Compliance as a Service will be the way to go moving forward.

Two years back I read about 3D printing of keys and concluded that it more or less changed the game for the concept of keys. Gladly (or sadly) the world moves forward and they innovative uses of 3D printing have emerged. Entering the scene: 3D ATM skimming devices ready from the printer.

An ATM-skimming device used to be quite costly but with the 3D printer the cost has gone down and it is easy to print new ones in case the old are ‘stolen’ by the police. Apparently ATM-skimming has become a commodity.

What would be the effect of this moving forward? Companies will need to rethink security strategies based on physical security and devices and build a strategy more along the lines of combination of hardware and software. Everything that relies on physical access to hardware will be a target, sooner or later.

And putting this in context, how many companies are still struggling with getting a decent printer sharing in place?

Not taking the blame has always been a bit of a sport in some organisations. Some of you may have heard of RACI. In some assignments I have used an alternative named RACI-B where I added a column for Blamed. A perfect tool to use to handle the blame game that always follow a breach.

Following the blame game a new buzzword to avoid blame is APT or Advanced Persistent Threat. As described in this article APT is used rather often to describe why there was a breach. Quite often when the blame game comes into play it is based on two factors: Bad security and bad investigations. Those two often goes hand in hand.

If you fear that your security is lacking and the CSO or CISO cannot describe the security situation without using techie words or even worse can´t describe the security situation for an external auditor using techie words it is good advice to get the investigation service from an external provider a few times to have someone point out what you need to do to mitigate the risk of a breach.

It is not only about the penetration testing, it is also about how you conduct internal investigations on all levels, from the value of drug screening your employees (including managers) to computer forensics.

F-secure published an article today on how they found the mail and file used to hack RSA. A quite simple hack using social engineering and a standard Trojan named Poison Ivy using a zero day exploit, CVE-2011-0609. The article has an interesting video showing what happens from a user perspective when the computer becomes infected.

This type of video is a good addendum to ordinary security awareness training. If the user in question would have become suspicious and informed the support for remediation of a possible problem the hack maybe wouldn´t have happened in the first place.