crowmoor.se

The first thing I read in the news, and the year is only 45 minutes old, is an advanced case of identity theft where someone had stolen a lot of snail mail from postboxes over a whole town and got hold of identity information. This information was then used for applying for credit cards that are sent to the same, obviously unprotected, mailbox where the card was the stolen and used for fraud.

It is time to start looking at snail mail as we already are looking at e-mail. As an insecure distributor of information and not having our unprotected mailbox be regarded as safe. Just think of it. Would you leave your wallet in the mailbox?

2009 will be the year when identity theft will be on top of the agenda. Jericho, here I come!

I just learned that public MD5 certificates could be forged breaking the chain of trust. The forging means that you web browser will think that the certificates is valid and not question you if you want to go to the site. In IE 7 you will not get a green bar showing it is a valid certificate but you will not get a red warning either. But take this a step further. What if I was to create a CA using a forged certificate and starting to issue SHA1 certificates and then set up a bank site that is 100% identical to your bank? What would then happen? Would you trust the site? Read more here.

Happy new year!

When I wake up in the morning I think Jericho. Before I fall asleep my last thoughts are Jericho. Finally you all are allowed to read the books I have been studying for a long time.

You will find the books here and the covers here.

Four years ago I stumbled into a discussion regarding how security was handled in RUP. As the discussion went on the voices rose and in the end the poor bastard yelled at me: “You are abusing my use cases” and by that the Abuse Case was born.

Just to set the context: An abuse case is not a type of use case. It is something completely different.
An abuse case consists of four parts:
*An Abuser, that does the attacks
*A process/solution, that is attacked/exploited
*An Endlooser, whose identity is used or who is abused
*An Asset, that what is lost or in other ways tampered with
(and yes, I actually uses these words, both for fun and to get the right mindset). 😉

The abuse case is small and granular to its nature and the purpose is to connect several of those into one or more attack scenarios that are modular and flexible. By combining different abusers and assets together with the defined attack ways against a solution it is possible to create far more complex attacks that to a bigger extent mimics the real complexity of real world attacks.

To able to create abuse cases you must have something that could be attacked. On this process/solution you map out the possible attack ways and from those you start mapping out all possible abusers. After this you look at the different parts of your attack area to find what parts different abusers attack. In those parts you then map in the asset that could be lost and the possible end looser that actually either is losing the information or who is to take the blame.

Last in this process is to include the mitigating solutions you have that actually prevent a certain abuse case. It is important to do this last in the process to not hinder the creativity in the workshop. You should always take into account that a certain layer can and will fail so if any protective layer is administered by the same person it would be rather easy to bribe that person into making an error just the exact time as you are inserting a trojan.

Abuse cases may sound as a joke (and the naming certainly is) but I have used them successfully in too many workshops to just neglect them. Please feel free to ask questions on how to use them in your work shopping.

I have former mentioned TBC: Trusted Computing Base, a possible decision point where you have to say that either you trust or do not trust a system. I am using this word quite often when deciding upon security perimeters but during the last few assignments where I have worked quite a lot with defining partnerships between companies I have found that I needed a new word for to define the point to where you should let the partners get into your company in a trusted manner. Entering Trusted Business Base, TBB.

TBB is the point where you decide “This far but no further”. It is at that point you have to start authenticating, rise the security level or completely block. TCB handled the inner trust, going for full internal trust to no trust at all. TBB handled the trust level going from the outside and inwards. At some point these will meet. Take care if they ever cross because then you have trust leakage to handle.

I often get one specific question when I am out work shopping, is doing a speech or in any other way get in the cross hair of the public: What is Security Architecture?. Still to this day I cannot give a good answer due to the following:

Security is only a quality property of any functional or non functional requirement.

So the answer always starts with: It depends… as any other architect most probably recognise as a default answer. It gets really interesting when I am approached with the question: Why did our security architecture fail?

The most common problem when a security architecture fails (the definition of fails is currently: cost to much, opens up vulnerabilities, inflexible, [insert possible flaw here]) is often due to the lack of a holistic view on security. You could have a great architecture with SOA, compliance, Identity and other components making you Buzzword-compliant but still lack a simple thing as making sure you have a secure coding process, patch management, internal audit process or stuff like that.

When doing a security architecture start out by doing the functional architecture and after that take into account the security aspects of all your components. Use ISO-2700X, PCI DSS or Jericho Style Security as a reference model to make sure you do not miss anything and do not forget to do a risk analysis. If you have no risk you have no need for security. Just relying on a best practise will get you into trouble sooner or later.

I have had a terrific week at Les Fontaines where I attended a course named Boardroom Enterprise Architecture. From my point of view it was the best course I have attended for many, many years. That said we had a quite interesting discussion regarding how to sell security to CxO-level.

The general opinion was of course to not get technical and that is also the case from my experience from GIO. But after that we ran into a littel bit of an argument if fear or trust was the way to go. We all had different experience in this topic but the general agreement was that to wake the topic of security at CxO you don´t have to do a thing. it is always there and they hate it. What you should do is show them how they should trust you in this matter and that you have a tracable approach to security that brings calm into the boardroom. Sounds easy enough? I spent 4 hours on a presentation that took five minutes. That said security presentations has to be done very carefully and with a mix of trust and a bias for action.

I few years ago I started to tell consultant firms that they have to start deliver secure solutions by default and that not delivering would lead to losing business. Sadly I got this confirmed from a partner today who have been contracted to review several applications delivered by different consultant firms with the specific goal to demand that those companies fix their applications without payment. The new contracts will contain paragraphs stating that all solutions will be tested for vulnerabilities and that the firms will be held liable for any damage.

It is my firm belief that secure by default will have to be a mantra for all consultant firms as high quality and ISO-9000 was a few years ago.

Time to get ready for ISO-2700x-certifications!

I read a very interesting article today regarding a very interesting manipulation of payment terminals. The fraud was very complicated and had an international reach.

From a PCI DSS perspective this is more or less not handled today. Yes, the terminals should be PED approved but what if the supplier has a security breach or if you have a break-in where someone manipulates your terminals? How could you prove that YOU did not have a breach in you payment security?

From my point of view it becomes important to have the PED: s sealed directly from the supplier and most possible the payment application server as well (the server communicating with the bank). How could you otherwise be sure that you are not blamed?

I attended a very interesting workshop today that you most probably will hear more of in a few months from now. Afterwards I had a discussion with a few colleagues regarding security and visible effects of security. We discussed the usage of visible deterrents with it-security. When deploying physical security the deterrent is sometimes the major part of the protection but is that actually needed or desirable when looking at technical solutions?

From an attackers point of view, he/she is more or less already invisible due to the possibilities to use anonynmiser services like TOR or any http-proxy services there is. This means that the only ones that actually are affected by deterants are the ordinary employee. The obvious conclusion for the common worker is that security is cumbersome and in the way of work.

This is where invisible security comes in. Using an open approach to security, meaning that information should be accessible if you are allowed to, also means that it should be invisible. The secure way of working must be the easy way of working.

This of course sounds very obvious but just take a look at the standard system today. Login on often means klicking yes on several screens, entering a password and waiting for the system to load. What if the logon process actually was context sensitive so that while you are starting your computer, entering the first commands on the screen and starts you mail client it identifies your setting, checks logs from the doors where you enter the room and recognizes your face from the webcam you use for speaking to collegues? There you have a much safer authentication that is integrated with your current tools and tasks. Invisible security at is best.

I am most certain that this is the future we are looking at: contextual and invisble security!