crowmoor.se

I rather often conduct interviews of potential candidates to start working at Capgemini. One area that often draws my interest is risk analysis and within that there is a specific topic that always interests me: Probability. Ask any security specialist about the probability of a given risk and they answer with low, medium, high or in some cases with a percentage. Most of us are satisfied with that. But what happens if you ask how they arrived at that number or classification? You´ll most probably get a rather nonspecific answer. And the fun starts when you ask them how they build their cases of probability. Most of them answers with the following story: If you have a computer without a virus protection the risk for it to get a virus is very high.

That is of course an obvious answer. Let them give some more examples and sooner or later they reach the point where they have to say that it is mainly a guess based on experience, most of the time an immeasurable guess. This is my point. We tend to build risk analysis based on our gut feeling without building it on known facts. If you read ‘The sience and politics of fear’ you´ll understand how the brain works in these situations and why our reasoning is flawed. As we very seldom have reliably facts most of our risk analysis we conduct are flawed. This is quite obvious as Wikileaks still get their information, industrial espionage continues to be a lucrative market and that Stuxnet continues to amaze.

So what can you do? I´ll will not explain the model me and my colleagues use in full but sufficient to say it is not built on probability. Instead we build it on a deep understanding of the actions a risk consists of and focus on those instead. We also make sure that when we are conducting workshops we gather a larger subset of our client than is common to make sure we get more input.

No, I don´t believe in probability. For you that understand Swedish: Tage Danielsson ‘Om sannolikhet’. For you that don´t understand Swedish, this monologue is a good reason to learn Swedish. Here is a translation: On likelihood

All over the news is the latest from Wikileaks publishing diplomatic mail from US. The consequences are for others to decide upon. My interest lies in how it could happen. According to what I read in the news there are two main reasons: the possibility to copy material to a CD (I cannot say if labelling it Lady Gaga helps) and that as many as 3 million had access to the information.

The question is not if 3 million had a valid business reason to access the information but how to make sure that not a single individual could rip of a whole database. There are of course a number of mechanisms to handle this. In this case I would say that information classification hasn´t been granular enough and that there was no Enterprise Management System implemented to protect the information. Of course to allow anyone to copy information to a CD is just plain stupid.

I have been invited to present on the topic ‘Everything an architect needs to know about security (but do not dare to ask)’. It will be one hour of methodology and how to understand security topped with an example of how to implement PCI DSS the right way.

PCI DSS is a very interesting compliance framework. It may be very prescriptive describing exactly what to do but when you really understand it you see that it is mainly telling you what to look for in a mechanism and how to measure that it is actually effective. It is here that most companies fail. They start implementing PCI DSS by the letter without understanding how different security mechanisms work. One very good example is hard drive encryption. It is very easy to implement but still many fails. The hard drive is encrypted, no problems there, but the key management is forgotten about until after the system is in place meaning that they most possibly implemented a simple solution that do not support the other requirements. That’s why patterns for implementing PCI DSS are so important. After conducting reviews on my last four PCI DSS engagement I found that the problems in implementation gone down by 57% if patterns was used.

Most important with the patterns is that they take both processes and technology into account making it very hard to actually miss something as simple as key management.

Measuring availability and hunt for nines is rather common. It is a common saying that every nine put another zero on the price tag. However, the real question is not how available a solution is but what to do with the last fraction of the percentage. It is all well to reach 99.9% but I wonder how the last 0.1% should be divided, in a few longer stops or in several shorter stops. That will dictate what kind of availability mechanism you should use. If you should have shorter stops maybe backups to tape is not the way to go.

Log files are mainly used for investigative reasons but there is a secondary usage of logging and that is performance analysis. Just recently I helped a hospitals surgery to pinpoint where they could be more effective by importing the log files into an analysis tool, using user identity to identify who did what and then displaying it graphically and make further assumptions from there. I even found out that I could identify unapproved information flows extremely easy with this method.

So log files are a lot more than just security. It could help you cut time and cost from your processes if used correctly.

One of the most often forgotten mechanisms of all kinds of security practice is tools used for investigation, log files and forensics. It is all good and well to have mechanisms that deter, detect and takes action but if something happens will you know what happened and, more important, who was the one who did it? In many cases logging has helped to identify the culprit. But logging is not just to activate and hope for the best. I have seen way examples where clients have implemented logging and after a very short while their systems crawled to a halt and they were forced to stop logging. They are now stuck with an expensive logging mechanism that they don´t use.

So, how to solve this? You need a few mechanisms to have logging work for you and help you. First of all you need to have time synchronization. Without it investigations are far harder to conduct. I have seen investigations go haywire and accusing innocent people just because a clock wasn´t in synch. Second, you need to create a risk analysis to know what the risks you possibly need information about are. Third, you need to have a forensics process in place so that you quickly could conduct the investigation and do not spend time understanding how your systems are connected. Fourth, you need to have the big picture of your systems so you quickly could identify the affected systems. Fifth, and last, you need to have control of the identity of the users. An IAM system is preferable with two factor authentication but you could get a fairly good hit rate with using individual accounts in your LDAP.

I really love books and books that expand my knowledge in security are even better. As an old social worker I am quite skilled in psychology, sociology and especially crisis management. Reading “The science and politics of fear” is like standing with you head down, bending you neck upwards and for the first time see the stars.

A bit too much praise, ehh? Well. How many times have you done a risk analysis, got the whole crowd to agree on you very bright insights just to learn that all the risk you and the crowd brought forward did of course not happen but that obvious thing indeed happened and it did cost them a fortune. This is all due to how our brain works.

I must urge you to read the book by Dan Gardner as I have to change quite a lot in my risk analysis to circumvent the Example Rule, the Good-Bad rule and the Rule of Typical Things. The brain is nothing more than a cave man in New York, surrounded by other cave mans, that is trying to understand what is happening around us. Do not ever make the mistake to think that a risk analysis is all about numbers and logical decisions. It is all about feelings, either you admit it or not.

You have surly met them, you know, those trying to describe security as locked doors, and the so old question “Why bother with locking the door when a windows is placed beside it?” I ran into one of those just recently and we had a bit of an argument as he was trying to promote network based firewalls instead of using a combination of appliances and host based. So after a bit of discussion the house came up and after listening to the door/window I grew tired and delivered the following:
A locked door may protect you from a would-be thief passing by your door. Locking the doors inside your house may also be beneficial but when doing the risk analysis you should not only think on externals trying to get in. You must also take into account the risk of having a cold from your kids, the possibility of boiler problem, your teenage daughter taking money from your wallet and finally the possibility that your home computer has a disk crash. A locked door only solves a very little problem in a very complex world.

For some reason the discussion ended then and there.

During my years working with security I have met many claiming to work within security, some actually is doing it, some real jokers and some not understanding what it really is. What I learnt during all this years is that security is really complex, specializing in security means that you have to know everything about everything. Being an expert in security without understanding the core of your clients business is like explain the security of a car without having a drivers license.

I have had the opportunity to work with some very passionate people when it comes to security and I must say that there is such a huge difference. If you ever get a team of passionate security people you are very lucky. Not only will you get a secure business but you will get a business that actually works securely with future proof tools and with the most effective processes there is. The team I currently work with in London is all about passion and the feedback we get is marvelous.

I just wonder? Should I implement a Crowmoor approved certification for security professionals? 😉