crowmoor.se

Yet a costly infrastructure has been shattered leaving an insecurity of payment cards in its wake. Chip and pin has been shown to have a flaw making it possible to withdraw money from a stolen card without knowing the pin. According to the paper it would explain phantom withdrawals between when a card is stolen until the cancellation of the card. Money that the banks until now have refused to reimburse.

The reaction from the payment industry is that the risk is quite low as the cost for such advanced tools is high and that there is a need for high technical skills. If it something former fraud have told us it is that if there is money to be found gears for making such scams will be readily available within a few months, instructions on websites and finally videos on youtube will emerge.

It would be interesting to see if there will be a rise of stolen terminals from small stores during the following months.

Up to six times each year someone in Sweden gets their house stolen, or to be more precise, someone fakes a sales contract, register themselves as owner, goes to the bank taking out a loan and disappears with the money. The legal owner is left with either a new big loan to handle or a big hassle using a lot of their time to solve.
The flaw making this possible is now up for partly remediation but as the fix is very simple it is on its place to discuss an underlying problem: measuring of costs.

I have worked several years with asset valuation and the figures often runs very high. The problem with doing that is that some cases that only affect a few could be over looked even if the cost for a single individual could be tremendous from his point of view. This could be handled if you include impact analysis in your risk analysis and specifically include work hours and time until remediation. This makes it possible for you to point out those kinds of cases.

For those interested I will make a presentation at Security World 2010 in Stockholm (in swedish). The topic will be “Perimeter protection is flawed – think new before it is too late”. I will present my views on the drivers for Jericho style security and what you need to do when working in this new space of security.

Read the program here (in Swedish) .

In an article in a Swedish news paper SMS scams reached new heights. During a tv show collecting money for a charity organization someone, internal or external is unknown, changed the phone number you were supposed to send an SMS to donate money, from the official to a fraudulent. As this phone number recently was involved in a SMS scam during Christmas and New Years Eve I do not believe it is a coincidence. For 21 minutes people donating money sent their money to a scammer that probably laughs all the way to the bank right now.

So what was the problem? Not implementing four eye principle when updating online information. This is actually a very common problem. In most cases this is not a big problem but in an active web shop if someone was to divert the money flow just for a few minutes it would cost quite a lot of money and at least the same amount in investigation costs, bank costs and so on.

Using four eye principle when you handle money has been common practice within finance sector for years. Now this has to be extended to all sectors handling payment flows. Wherever there is money someone will try to steal it.

Just recently read that a German scientist, Karsten Nohl, managed to crack GSM crypto A5/1 due to a vulnerability not previously exposed. The thing that got my attention is the response from the GSM-organization. “The vulnerability is only theoretical because it is illegal to crack the crypto”. I suspect that this is mostly due to a bad translation but still the reasoning is quite common within security.

I once did a vulnerability assessment on a data centre and found an unlocked door that had been unlocked for five years because “everyone knew it was locked”. Same reasoning again. Just because it is illegal or that everyone knew doesn´t mean that some is going to try.

If you want to be secure you have to think not only on the process but on all ways to break the process as well.

Have a happy new year!

In a swedish article today some interesting figures is shown from bank transaction frauds, including credit card frauds:
• 600-700 M SEK was lost 2008 (60-70 M EUR)
• 1% of the grown up population was affected (60 000)
• 84% got their money back partly or in full

FI, Finansinspektionen, the authority responsible for finance compliance in Sweden states that they thought the problem was bigger and that the Swedish population due to fear uses a lot more cash than necessary and that costs the society 1 200 M SEK each year due to higher costs in cash handling. A last interesting fact was that 5% of the population thinks that they will be affected of a fraud within a 2 year period.

Even though the figure maybe low according to FI it still means that there is a very huge amount of cash in financial frauds. 60-70 M EUR only in Sweden. Sweden is very low populated but on the other hand has a high penetration of internet banking and credit cards. But if we make the assumption that the amount is more or less the same in every major country in Europe. That means that the amount for fraud is around 600-700 M EUR each year. This of course means that there is a lot of money in perfecting the hacking tools and now and then they will be used for bigger scams and thefts against bigger companies. If you handle money or information that lead to money (like identities) you will experience fraud in one way or another. Do not let your company or organization be the next to appear in the news.

Jericho requirement 3 clearly states ”Assume context at your peril”. This is one statement that is very easy to understand but many fails to follow. What does it say actually? The key message is that you should always understand the context of security solution. Every solution is created to handle one or more threats within a given context. The trick is to understand the context. Let me give you a few examples:

1. Hard disk encryption protects your information from being accessed.
a. Assumed your computer is not on.
b. Assumed no one have physical access to your computer.

2. Backup protect you from information loss in case of computer failure
a. Assumed you test that you could restore your information.
b. Assumed you handle all other dependencies.

Do you see the assumptions? This is what “Assume context at your peril” is all about. Understand the scope and limitations for a solution. A solution that works perfectly for one industry may be disastrous for another. I still have a rather old example fresh in my memory within transportation where they have configured their servers according to NSA´s guidelines to make them as secure as possible. Downside was that their availability was way below optimum. They had an uptime of 90%. They had assumed that NSA´s guides would protect them from all harm without defining what kind of risks they actually was exposed for and what was important for their industry. Yep, you guessed right. Availability was the most important for them and confidentiality the least.

So, “Assume context at your peril” means that you should understand your security controls before implementing them.

New laws are emerging in Europe that has its origins in US. Those state that companies and organizations that experience a breach where information is lost have to go public in one way or another. This means that public humiliation and loss of face will be a cost to take into account and also the information cost if all affected users has to be informed. Losing a database with two millions customer records will generate a very large cost.

Hopefully this will help to further strengthen the case for the CSO and CIO when arguing with the board regarding investment costs for security mechanism. Hopefully we will also se better evaluation and a better use of security mechanism when investment is driven from an information perspective rather than a infrastructure perspective.

Gartner report: Breach Notification Laws Are Coming to Europe, ID Number: G00172761

At the same presentation I was approached by the CIO asking me: You are suggesting quite substantial changes in our way of working. How do you know that this will solve the problems and how do we know that this is the real problems?

I first started to explain how security works and that you have to make your risk analysis first otherwise you do not know what you are facing. Shortly he hushed med and said: I know that you are an expert on your subject and I trust that your solution is good and sound but I have to explain the added cost for the board. What should I say?

My answer was very quick: “Take the slides explaining Return Of Security Investment and the slides explaining the identified risk and show them. The risk they have identified them self and the costs comes from your CFO. As for the risk mitigation that is the result of this workshop and my experience. Do you think that will do?”

“Probably but are we secure enough?” he said smiling. I only answered with a smile, but the answer to the question is easy. As long as you could do your business every day you are secure enough. A company seldom stands and falls with a single incident. Most of the time the only effect is costs having to be covered. My mission is to make those costs as low as possible with as little money as possible.

Still the issue is as always: How do you calculate the cost?

I was presenting the result from a workshop the other day and half way through I noticed a few persons getting very uncomfortable. I decided to address their awkwardness and asked them if everything was clear. The answer I got baffled me: We think you are making this to complex. We do not understand the solution anymore.

I took a step back and indeed they were partial correct. Looking at the solution from a bit distance there where many changes as we were evolving from perimeter style security to Jericho style. But the functional solution in itself remained untouched. After a few minutes discussion I understood that the problem was not my security solution but that the developers had no understanding of security as they have been relying on perimeter defense for so long.

This quickly turned from a simple presentation of a solution to a crash course in security reasoning. This was not the first time so from now on I will bring in a two hour security understanding part in all my presentation just to make sure I have everyone on track.