crowmoor.se

In Steve´s blog there was a note that he had to leave Microsoft and from other places I heard that it was the better part of TWC that was eliminated. I am a bit unsure about what the consequences of this are. Microsoft has for several years been the top player when it comes to security, especially since the initiated TWC. The question is now if eliminating means that TWC is an integrated part of Microsoft development process (SDL) so that security will remain stable or if this mean that security will now erode into nothing leaving Microsoft in the same situation as it was before TWC.

When looking at the code base (from what could be understood from patches) there is still a lot of old code that pops up vulnerabilities now and then (just look at affected systems when next security patch is released). Will the removal of TWC really help Microsoft to stay on top of the security or is it possibly so that they have decided that their business model has changed to “good enough” instead leaving there customers in the hands of the bad guys?

Only time will tell, but I will keep an eye on the development of this issue. I am a bit disturbed by this.

Update:
I spoke with a guy inside Microsoft regarding this issue. He told me that even if Steve Riley is to leave Micdrosoft TWC will be an integrated part of Microsoft even if it will not be a sales pitch anymore. TWC has entered the core of Microsoft and will stay there. 🙂

I am sorry to say that I currently do not allow automatic user registration due to a possibility to use the “new password” function to spam. Until a patch for this exists I will manually give you accounts. Just send a mail to crowmoor@crowmoor.se.

During a meeting I was told that many customers in UK view Jericho documentation as only a description of what is happening, not a toolkit for actually solving the security problems that arises. When thinking of it they may be correct in some sense. The documentation is rather high level and is not technically useful in its current state.

The Jericho books should be perceived as a mindset for someone working within the field of security to understand and live by. Jericho does not say that you should not use firewalls, nor does it say that your security solutions should be enterprise wide. What it gives is a way of thinking of the risk that could arise and a high level templates on how to solve these problems.

Let’s look at a brief example: Publishing of a yearend report on your website. This document is very sensible up to a certain point where it becomes publicly available. For security reasons you have not put it on your website yet but kept it on the fileserver. In one way or another it leaks out and de disaster happens.
If you where to work perimeter security style security you would most probably make sure you had firewalls, virus protection, the correct Access Control Lists, hard drive encryption and backups of the document stored in safe places. Hopefully you have a risk analysis showing the risks connected to your solution.

Jericho style security takes the approach of appropriate security in the right places; hence a risk analysis built on more the just infrastructure. It needs to be information centric. Secondly identity has to be established to make sure that everything that needs to be logged is logged. Thirdly secure development should be done to make sure that applications that are used are not vulnerable for attacks. Within this I also include ordinary patch management.

And so on…

What is the difference? Jericho takes on a bigger and more holistic approach to security. Jericho also focuses on using a more value based security; hence calculating asset values, ROSI-models and security layers.

So from my point of view Jericho should be used as a way of thinking holistic and a review model and not as a recipe. Depending of the risk analysis different solutions could be implemented where the problem seem to be the same.

The seventh of May will I give a seminar for the it-forensics team of the national police in Sweden. I will describe how you work with forensics when you have no access to the underlying infrastructure. I will also briefly describe what will happen when you work with information theft investigations when it comes to cloud computing and of course describe Jericho style security. This seminar will be delivered together with Karin Ekeblom.

Finally skimming has reached unmanned gas stations in Sweden. I have wondered the last years why the criminals decide to go for the ATM: s that has camera surveillance when there are so many unmanned gas stations and other units in Sweden.

Hopefully this will force all gas companies to start changing all their payment devices. Sadly the cost will most probably force a few of the smaller ones, already struggling with the cash flow, out of business, but that’s the price of taking cards. Either you do it safely or you don´t do it at all.

Read an interesting article about how card readers where manipulated either in production process or just afterwards making the signs of manipulation almost undetectable unless the readers where weighed.

This of course means that there still is a lot of money to make in the area of credit card scams and that working towards being PCI DSS compliant is as important as ever. The past events show that the handling of card readers has to start to include a physical scan of the unit including weighing them every morning. Interesting way to solve a security problem but currently it looks as that is the only way to find manipulated readers.

But let’s take a further look at the problem. The current problem is attacks on the supply chain making the integrity of the readers null and void. The question is if it is possible to find new ways of solving this problem as the current system has flaws. The real issue is that if you get hold of the information you have access to the whole card. One way to solve this is to use a challenge response system that would make the information useless unless it is used in the same store again. A bit cumbersome but it is still an idea to explore.

As long as the credit card company could verify that you are you and are allowed to use this card and that the transaction is quick we are free to find new solutions. If we address it Jericho Style and look at the unit as unsecure the thing we have to do is to transfer our stored security token to the company, having them unlock the information and verify it. If you combine this with the security token from the store you could create a possible information flow that even if eavesdropped upon still could be regarded as secure.

Last week I was attending a workshop within Public Security looking at e-id and the internal consequences for implementing it. The basic idea was to implement a national e-id for everyone living within a country and also giving one for everyone allowed to stay and work. This is of course nothing new but what we looked into what would happen with the government working with the public when their services were digitalized.

It turned out, not unexpectedly, that there was a great possibility for large changes in processes. When implementing e-id for both authentication and signing a lot of processes involving singed documents was possible to change making the workflow that was based on physical papers to actually go from a serialized process to a parallel structure or a mash up. If the case needed several people to be involved that made independent decision the possible handling time of a case could be substantially lowered. A further study has to be done to exactly pinpoint how and where the gains could be made but one thing is sure: it may be a small change for the single citizen but major changes for the government.

To facilitate such a change there need to be done both business architecture and information architecture to understand how cases could be split between services. Without it the gains will most possibly be lost.

A rather interesting phenomenon has surfaced recently: skimming using a mobile phone. It is very simple to do this. Just take a picture of the front and back of the card and your done. The information printed on the card is enough to make purchases on for example poker sites and such where money easily could be moved and washed.

This is a perfect example where security architecture has failed to have a holistic approach on the possible risks connected with grouping of different types of information. In this case all information needed for making an online purchase is stored printed on a card. This is of course very simple for the customer as they only need to bring forward the card. But as there sadly are situations where you have to give the card to a merchant to be able to make a purchase a large risk for the customer opens as taking a photo of your card is done in seconds.

What would be the correct way to handle this? At first I would question the cvv code. It is printed on the card to validate the card´s presence during transaction. This is of course flawed from start. There is nothing preventing me from writing down all information, putting my card in a locked drawer and use my piece of paper instead. The cvv code does not show that the card is present during a transaction. Secondly the cvv code is a change in the security in transactions when looking at other ways to pay. Using your pin code is valid for making transactions, as a writing your signature. These are two types of two-factor-authentication. Cvv code is not as it is printed on the card. When looking at the PCI DSS requirements it clearly states that cvv is not allowed to store. From that perspective the pincode would actually be usable instead of cvv. Of course there are other risks connected to using the pin code, like creating a forged card and withdraw money directly. But nothing hinders to send the cvv code in the same way as the pin code: In an enveloped to be used when making purchases on internet.

All in all, this is a good example of when segregation of information has not been implemented correctly.

During the last months I have held quite a few risk workshops and one topic that always have arisen is if blackmailing and extortion actually is a threat to think of and handle when we look at information security. The first answer would be “No” but thinking a bit longer the answer could only be “Yes” due to the fact that there have been several incidents where threats have both been delivered and actual attacks have been implemented.

In a previous post I wrote about the guy holding a city hostage. There is a trojan out there that encrypts files and the only way to get them back was to pay a amount to get the decryption key. Several of my customers routinely gets threats in their email stating that if they do not fix the vulnerabilities on their sites they will be attacked (this is possibly some kind of sales trick). Other customers with web shops often get threats stating that they will be DDOS:ed. This has actually happened in two cases but only for a few hours.

So with the above information in mind I could state that it is a risk but that it is currently not a large risk. But with encryption tools popping up everywhere both as large scale enterprise tools and freeware it is rather easy to imagine that a disgruntled employee could use this as a way to blackmail his employer or someone else creating a new trojan that implements encryption. The obvious protection against both threats would be backups (and testing to restore the files) but still it creates a disruption in production.

So in the end to achieve 24/7 production this kind of threats has to be handled even if it should not be top of mind (yet).

Durnig my last posts I have written quite much about Jericho as a security referense model. One question I have gotten several times is: “Is it possible to implement?” I have made several security reviews during the last year where I have looked into possible implementations of Jericho Style Security.

Last week I had a workshop with Microsoft and some collegues and during that session we more or less finalized an implementation model of a Sharepoint solution that handled both “old style security” for mitigating infrastructure threats and Jericho Style for handling the information security. This model will be published within Capgemini and hopefully at Open Groups website as a possible infrastructure reference model for Jericho Style Security if all goes well.

I would like to drop the name of the person within Capgemini driving this model forward. Her name is Karin Ekeblom and if she keeps working at this pace you will here a lot more about here within the year.