crowmoor.se

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.

Having worked with security and compliance schemes for many years I still find it very challenging to motivate why a client should invest in fulfilling any type of compliance, besides the obvious one: You have to.

But as everyone knows a rule consists of three parts: The rule, the monitoring of rule fulfillment and the penalty if the rule is disregarded. So the question many clients ask themselves, what are the costs compared of compliance compared to non-compliance?

Following a study from Ponemon Institute, LCC named: The true cost of compliance it have become a lot easier to calculate estimates on the costs of compliance and non-compliance.

‘The extrapolated average cost of compliance for 46 organizations in our study is more than $3.5 million, with a range of $446,000 to over $16 million. Adjusting total cost by organizational headcount (size) yields a per capita compliance cost of $222 per employee.

The extrapolated average cost of non-compliance for 46 organizations is nearly $9.4 million, with a range of $1.4 million to nearly $28 million. Adjusting total cost by organizational headcount (size) yields a per capita non-compliance cost of $820 per employee.’

So for a client with a headcount of 50 000 compliance would costs $222×50 000 compared to the non-compliance cost of $820×50 000. The average saving per employee is $598. This is however not true when several compliance schemes are implemented in serial or in parallel. The study shows that internal audits lower the cost of non-compliance. My own experience in this field is that when not coordinating the implementation of the compliance schemes it could give problems with redundant security mechanisms and added costs.

Working with PCI DSS means that you get used to several acronyms flying around in documentation. One of those is CDE standing for Card Data Environment. CDE is mainly used within PCI DSS to explain where card data resides. So any server containing card data is within CDE. All servers touching this server and is not limited by a firewall is also part of CDE.

So CDE is part of the scoping process of PCI DSS. By establishing a secure zone, i.e. a part of the network that is behind a firewall, and placing all your servers behind it you have in effect created a CDE. CDE is then used as a separate part of the network containing sensitive data.

The scandal in UK with the tabloid press hacking of voicemail is a rather interesting affair. During the last two years I have discussed the authentication problem in mobile phones. Most of the time the question is how an app should authenticate to a server. I have seen all kinds of solutions and cut most of them down to size if the used the mobile phone as an authenticator.

With the service of fake numbers to reach voice mail there are several services at different companies that will have to replace their authentication mechanism. Trusting the phone is always a bad thing and when it is so easy the fake a number using the phone number for authentication is null and void.

The most important thing in all setups of mobile security is the authentication. Failing that all other mechanism are useless.

Shopping is always an experience in US. With the dollar all time low from a Swedish perspective shopping is even more interesting to look into every store you could find. Adding to that a very keen interest in PCI DSS and is applications I do understand why PCI DSS was started in US.

Looking into the shopping habits US stores tries to make it as easy as possible for us to shop. Meaning that most of the times (under $50) you just need to swipe the card, get the receipt and you are gone.

If you get hold of a credit card it is extremely easy to embezzle a rather big amount before the card is blocked. We may have a fear that our credit cards will be stolen and sold on internet but with enough details stored on a server or with skimming it is possible to manufacture cards and use them in US or other countries with a low level of secondary security checks. You may not be able to embezzle a large amount but getting caught in using it is almost zero.

In Sweden it is mandatory with pin or signature even for as small amounts as €0.01.

Just back from a wonderful vacation in US I couldn’t fail to notice how they have implemented physical security screening everywhere. There isn´t a theme park without bag check or metal detectors.

In this case it is the little word OR that is the culprit. At one park I had to walk through a metal detector but my bag and other stuff was passed beside it with no checking at all! So if I really wanted to get a knife, gun, bomb or, even worse, a sandwich through the security check I should pack it in my bag.

I had to ask the personnel why they conducted the control in this way and the answer I got was that they do random checks. Waiting there 15 minutes I didn´t see a single random check at all.

This of course points out a very important security architecture principle: Always get in control of all attack vectors.

In any PCI DSS project there is always the ongoing debate of what solutions to implement to reach compliance. In general there is three ways to reach compliance: Out of scope, remediate or replace.

Getting a solution out of scope is rather often the easiest way to reaching compliance. As described in my previous blog entry there could be some issues with that on older systems.

Remediation is quite often the most costly alternative but on any custom made solution this may be the only option available if taking it out of scope is not an option.

Replacement may sound costly but as many systems containing credit card information today are rather old and probably don´t fulfill the business need anyway a replacement could be the best alternative. Just make sure to insert the business advantage in the business case and you are home free. Getting a new system PCI DSS compliant is often quite easy.

In the end, reaching PCI DSS compliance could mean that instead of implementing a costly good-for-nothing security program you upgrade your solutions to put you ahead of your competitors.

During my years working with PCI DSS I rather often get the question how much it costs to become PCI DSS compliant. That is of course not an easy question to answer but adding to that is that the scoping issue had most of the time not been addressed at all.

The scoping of a PCI DSS project is the one most important part of any engagement. You probably have heard of solutions including a PSP, tokenization server or hashing. All of those have one thing in common: they reduce the scope of PCI DSS. That of course means that the cost of getting old systems compliant is reduced as well.

However, getting the functionality working after tokenization could be a rater complex issue. Make sure that you understand the system you are trying to tokenize, otherwise there is a risk that you are in a bad place with high costs and a plan that can´t be followed making the card brands reach for the pen to start fining you.

The events currently unfolding at a large car producer points at a specific problem within security: The fears of letting other know. In many organizations today security has a somewhat impenetrable workflow. The board is briefed by the CSO or CIO with only a minimum off information according to “need to know”. Non-security personnel have no insight in what is logged or not logged and have no means of actually getting the information what is happening out from the security department. To top this forensics praxis is seldom followed and it is very easy to frame anybody if you have control of the security systems. In short, the security department has sometimes returned to the days when the Inquisition was feared.

Being a global security consultant I have seen my fair share of incidents, cover-ups, unknowing CEOs and direct malpractice, where I was called in to sort it all out. Many times it was just lack of understanding of real security or processes that didn´t work that was the culprit but in a few cases it was actually personnel at the security department that hold a grudge towards someone and tried to frame him or her.

The reason they were almost able to pull it off have been the same as it always has been within security, lack of insight in the process, a process that has been decided to be too risky to expose and where secrecy has been implemented for its own good, not to protect anything. Ask any cryptologist about openness and they will tell you that when it comes to algorithms it has to stay secure even if the attacker has the algorithm and the encrypted text. Ask any security specialist about “security by obscurity” and they will tell you that it doesn´t work, that the attacker always has all the time in the world and always find the possible vulnerabilities. Ask the same guy about their process or their network drawings and you´ll get the answer: “No, it is classified!”

It is my opinion that security departments for way to long have been allowed to work as an internal police force hidden under secrecy, conducting risk analysis trying to protect everything without any real understanding of business value. It is not an effect of a bad apple. It is more an effect of a bad barrel as explained in the Stanford Prison Experiment. Without clear rules of engagement, without clear rules from management of what needs to be protected and why you will eventually get a security department that is dysfunctional.

Learning how to run a security department with the same rules of engagement as any other department takes skill and understanding. Equally important are methods and tools that make security an integrated part of the company. Getting something as simple and easy as a risk analysis right have many times been proven to be an impossible task for many companies. Failing this, fear will govern the security department; fear of a breach and fear of having to lax security and thereby always producing answers like: “It is too high of a risk.” or “We can´t allow that because we are not sure it is safe.” Fear creates secrecy, secrecy creates impenetrable areas and sooner or later you will get a bad apple, produced by your bad barrel, which tries to make way with a large amount of money believing he was protected by the system of his own design.