Crisis Mapping and Cybersecurity – Part II: Risk Assessment

This blog expresses only my personal views, and not the one of any organization or institution I have worked or currently work for.

I have a background in human rights and humanitarian affairs, and in those fields you do something that I realized was not that common in the ICT world – or maybe it is just under reported – that is called risk assessment. How does a risk assessment look like?

There are several components to the matrix: there is the risk, the source (sometimes), the likelihood, the mitigation tool/measure and (sometimes) the independent variables. I truly believe that this matrix can help in understanding what are the things that we should focus our attention on and what are the things that we cannot change or we should just ignore. The very key factor in the use of this matrix though does not lie in the matrix, but in whom is filling it.

Here is a couple of examples of simple matrix for risk assessments:

This is exactly the same matrix that we used for the U-Shahid project in Egypt and while I was the one that proposed to use it, I didn’t fill it: the people that fill it where the Egyptian activists that had a very deep knowledge or all those factors, due to their experience. If I would have fill it, the outcome would have been very different, since my ideas on the possible risks associated with this project were very different.

Here an example of how we used this matrix.

1. First step was to identify the source of risks: in the Egyptian case the source was very easy to identify since it was only one, the Egyptian government and it’s national security. We also identifies an additional source of threat that could have been the Muslim Brotherhood, but since they came to our training to learn how to use the system, we decided that they were not going to be a bit threat: after all they have been discriminated against several times and they are not allowed to participate in the election, so we realized that they also had an interest in the project.
2. Second step was to list all the possible risks and to associate them with a degree of likelihood from 1 to 10 and design mitigation systems. We came out with the following matrix:

A. Hardware:

  Get the computers where the Flsms software was hosted: DL= 8

We set up what I call the FLSMS mobile system. Here mobile stands for “that moves” and not for mobile phones. Basically we realized that the likelihood of those computers to get caught by the national security was to find them when they were getting online to send data to the Ushahidi system. For this reason we decided that all the people managing the FLSMS system had NoT to do that from their home, but instead from an Internet point. But since an Internet point can be found over the course of 12 hours (election day) we decided that the team responsible for using this system was going to move from Internet point to Internet point every 1 hour / 1 hour an a half. In addition to this, the messages were sent to the Ushahidi platform once in all every time the person managing the software was moving to another Internet point.

The second problem, related to the fact that the sim card could have been indent infield thanks to the IMEI number, the sim cards for the system were bought by the organization and registered all under the same name (yes that was a risk that the organization was taking, but they decided that it was better to have the risk on the organization than on individuals).

  Get to the server: DL= 5

The server was hosted abroad and accessed remotely. In addition to that, several copies of the databases were done and  distributed in different other servers. The main server had an automatic backup done every hour and it was encrypted.

B. System:

  Block the SMS number (in and out): DL = 9

This was one of the risks we knew we could do less. We had a public number that we had to advertise since the project was based on crowd sourcing methodology and the number was registered, as it was obligatory in the country. We decided to have other 5 numbers available and already working, that were registered as personal numbers of some of the less known people participating in the project (but swapped in between them). Those numbers were divided like this: one was used by the monitors, one by the NGOs involved in the project, one was used by the known network of the people that the organizers knew and that were also reporting (and they were sharing it with their trusted network). The other 2 were backups numbers.

  Block the website: DL= 9

We created several mirror websites, and we bought under several names all the similar domains that we could use to replace the main one.

  Infiltrate the platform: DL= 9

The high likelihood of this variable is due to the fact that we knew that the government was easily able to arrest the organizers and torture them to get the password to the system. For this reason we decided that it was not worth it to try to get any super hardcore security system, also because this could have meant for people to be killed if not able to access the system for the repressive regime security people. Some decided that the main thing for us was not to prevent them to access the system, but to make sure that if they did they could not destroy the information contained in there or get to the identity of the people working on it. So what we did was to create a system where we could monitor what each recorded person was doing inside the platform and allowed only the editorial board to be able to delete informations or change settings.

The only 2 people that had access to the database containing all the details of the SMS coming for example were 1 tech person inside the country and 1 tech person outside. All the back ups where handle by the person outside the country and the tech person inside the country had no access to it – this information, the fact that the tech guy was not able to access info from inside the country, was shared broadly on channels that we knew were controlled by the national security.

  Falsify informations DL= 10

We realized that there was little we could do prevent this. Some decided to ignore this issue by relying on the fact that the numbers would have played in our favor. In fact several tentatives to send in false informations were done and always detected. In addition to this, we had a very strong verification system that was verifying information one by one and was only flagging as verified information that were supported by several independent known sources, or by multimedia that we’re undoubtedly showing what was reported. In addition to this we were encouraging people to use the SMS alert system of the Ushahidi platform of that if something was being reported in their area, they could go and verify it.

C. People:

   Arrest all the participants: DL= 5

To try to avoid this possibility we wanted to keep the identity of the people working on the project hidden. Unfortunately this was not possible, since the national security pretended to have the list of all the people working on this project. Since any measure to prevent them from arresting the participants was completely unless we decided to do 2 things: the first one was that all participants were well aware about the fact that their contact information were in the hand of the ns. The second one was to ask to all of them to move as much as possible during the election day, to avoid an easy identification of their location. The third one was to create an arrest protocol (see below).

   Arrest of the activists managing the projects (editorial board): DL= 9

This was the most likely hung to happen, as all the activists had been already arrested before and where all well known by the NS for this project. To them we applied the same arrest protocol. In addition to this we set up an external team, based in another country. In the case all the participants were arrested, the entire system could be taken over and managed by a team of people, trained in the previous months, and that was unreadable by the national security of the country. In this way, the information could still come in from the country, but the processing was “outsourced” to a foreign team (key for this was the trust already present in between the two groups).

   Close the organization managing the project DL= 5

For this eventuality we had already set up a chain of international organizations (human rights watchdogs) that could at least use their international power to put pressure on the gov’t in case of the closure of the organization. In addition to this, the organization keeps constant contact with the national security and responded to all their inquiries about the project, including giving them all the information requested (sometimes written in such a way that was impossible to understand what we were doing for example).

   Intimidate the participants to the project DL= 10

This was something that was already happening during the design phase of the project. To avoid bad things to happen, we were always sure that the organizers – especially the less known once, and so the most vulnerable – were never alone and always in busy areas when outside.

   Intimidate the people sending in informations DL= 7

This eventuality was agin something that we could not avoid easily. For this reason, we were making very clear, even in the advertisement of the project was we the possibilities, how the government could reach out to people and how it could trace them. In addition to this we did training for free to people on how to use social media, mobile and Internet security and to do video and pictures with their phones without being caught.

In addition to this we had an arrest protocol in place. The arrest protocol was design by asking to the people that had been arrested before to describe exactly how the arrests happened. The main thing for us was to let everyone else know if someone was arrested, for two reasons: to allow action to be taken immediately, like call a lawyer, and to allow the rest of the team to take actions in order to avoid to be arrested or to stop working on the project.

The phases that we identified for the arrests were:

1. Police arrive.
2. If person to be arrested in the house possibly ring the bell or open the door directly
3. If person to be arrested outside simply get the person
4. In both cases ask/take their mobile phone and computer

On this premises we realized that our chance to get the information out, especially if the person was arrested while alone, so with no witnesses, was to allow for them to send an SMS out. The way we did that was really simple: we ask everyone to set up a direct SMS already written in their phone linked to the keyboard ( something as simple as to set up a button in the phone that automatically bring you to the message already written). The time necessary to send the SMS out was as short as two clicks on the same button: one to get to the SMS already written, one to send it to 10 predefined numbers. Simple as it is.

This deployment was particular for several reasons. The first one was that we knew that we could not prevent the gov’ t from doing certain things, like arrest us, or get into the system, so instead of trying to prevent them from doing it, we try to mitigate the effects.

The second one was that the people involved were activists, so people that were taking a certain amount of risk, knowing it, and we’re ok with that since they were willing to risk to achieve their goals.

For those 2 reasons our security protocols were focusing more on mitigation measures for the EFFECTS and not on preventing the act from actually happen.

In addition to this, we knew were well that there was no way we could control or mitigate all the risks, so for those ones, we decided to create system where the act was at least going to be known by others, as to allow other measures to be taken.