• Ei tuloksia

3 METHODOLOGY AND THE RESEARCH PROCESS

4.3 Case examples of data breaches

4.3.4 Other possible case

Let’s think about one hypothetical case, which might well be true. A big corpo-ration has identified the need for new information security system that covers all the information security areas of their company. The system’s requirements have been well-thought and after that the system has been built based on them.

After the system has been built and tested in the vendor environment and found safe, it is implemented into the customer’s network and systems.

Some time after the system has been taken to use, the company notices that they have had a data breach. After the company has investigated the issue, they notice that there is a backdoor that has been activated by one of their em-ployees. When they question the employee, they discover that the system has asked the employee if he wants to disable one feature of the system. The

em-ployee disables that feature, thinking it is useless, but by disabling that one fea-ture, the poor employee has unwittingly opened the access to the backdoor to the whole internet. Not long after that, a “bad” hacker finds this backdoor and uses it access the company’s internal network and steals their valuable data.

Now, when the company investigates this issue they want to find out and determine who is responsible for all this. Is it the employee who has disabled the function and enabled the hacker to break into their network? Is it the system vendor’s fault that they designed it in such a way that it was possible to disable such a function? Is it the testers’ fault who did not find such a vulnerability from the system? Is it the hackers’ fault that they took advantage of the vulner-ability and committed a crime? All of the answers for the questions could be the right answers and this is why these cases are so complex. For example, one would think that it is the employee’s fault that the company had data breach, but what if the hacker would not have exploited the backdoor? So we can see the causality between all of these actors; for example if the tester or the vendor would have found this error in the system, the employee would not have been able to disable the function, and the hacker would not have been able to break into the system. In another scenario, if the employee hadn’t disabled that func-tion the hacker would not have been able to get into the system, at least from that backdoor. Then if the hacker had not been a “bad hacker” and would not have taken advantage of this situation, there would not have been a data breach and, in the best scenario, the hacker would have informed the company of such a vulnerability.

5 DISCUSSION

As we can see from the analysis, it can be said that the phrase “human is the weakest link in information security” or varieties of it are used without evi-dence that would show this to be true. Many of the articles use the phrase with some generalizations such as “generally considered”. By using the phrase “hu-man is the weakest link in information security” and not criticizing it any way, or at least not withdrawing themselves from such a claim, it can be argued that the authors are committed to the claim (or at least the reader can believe or as-sume so). A good example of this is Thomson & Nierkerk (2012, p. 39) who has written: “It is commonly acknowledged that employees are often the weakest link when it comes to protecting information assets”. So as time passes the phrase moves to a situation where it is referred to as “commonly acknowl-edged”, which implies that it has been proved to be that way. It is a short way from “commonly acknowledged” to be a fact and Flores and Eksted (2016 p. 26-27) actually wrote: “It’s a well-known fact that employees are the weakest link in an organization’s defense against external information security threats”.

While saying this, Flores & Eksted (2016) did not present any evidence or refer-ences to show this true. So all the discussion around this topic have changed the

“generalization” to “well-known fact” but I argue that it cannot be fact if there is no evidence to support this claim.

As we can see in the figure 3, all of the articles used in the literature re-view that claim human is the weakest link have used references that do not ac-tually support this argument. It is interesting to see how many articles have made that claim and refer to another article that does not actually make that claim or does not support any evidence to this claim. Based on the figure 3 and the previous text I argue that this phrase is used without any justification. By claiming humans as the weakest links in information security, many organiza-tions may have allocated resources to the wrong places and, in the worst case, may have left some other important links without any protection at all. Based on the literature review I also argue that humans are, without a doubt, one of the (weakest) links in information security and many information security inci-dents are caused directly or indirectly by humans. However, this does not mean that they are caused only by humans, and most cases are too complex to blame

only humans or some other one link. The causalities between different links are strong in most of the cases, as we can see from the example data breaches, and this is why we should always look at the “bigger picture” and not focus simply on blaming the one link that seems to be the obvious choice.

FIGURE 3 (articles links to their references)