The attack trees

Information technology (IT) Security has become more and more important today when as e-commerce is becoming increasingly popular. People in developed countries like America and throughout European countries have been exposed to online trading for a long time; this trend is also taking off in developing countries in other parts of the world. Besides its importance toward business activities, IT security also plays a pivotal role in protecting individuals, organizations assets, which are actually parts of the business operations. Variety methods of securing business have been developed and implemented successfully. Attack Trees is one of those. Not only in Information Technology, Attack Trees is also applicable to security problems in a wide range of fields including: telecommunications, health care, finance, critical infrastructure, aerospace, intelligence and defense.

To secure your business against impending risks, you first need to define all kinds of possible risks and pathways that those risks might be realized. Acknowledging risks and how they might happen, you will be able to develop measures to fight against or mitigate them. This is also what Attack Trees helps clarify. Attack Trees is a formal, convenient way to methodically categorize the different ways (how the risks happen) in which a system can be attacked[1] (risks). Attack trees are a graphical and mathematical construct used to

Identify potential hostile activities that pose the greatest risk to the defender;
Determine effective (and cost effective) strategies for reducing the defender’s risk to an acceptable level;
Describe the potential interactions between the adversary and the defender;
Provide a communication mechanism for security analysts;
Capture what is known (facts) and believed (assumptions) about the system and its adversaries, and store the information in a form that can subsequently be retrieved and understood by others[2]

Attack tree models are graphical diagrams representing the choices and goals available to an attacker. They are represented in a tree structure, in which the root node of the tree is the global goal of an attacker and leaf nodes are different ways of achieving that goal. In an attack tree, children of the root node are refinements of the global goal, and leaf nodes represent attacks that can no longer be refined. A refinement can be conjunctive (AND) or disjunctive (OR). Figure 1 shows an example of an attack tree with the goal of the attacker is to obtain a free lunch[3]. The tree lists three possible ways to reach this goal. Lower levels in the tree explain how these sub-goals are refined. The arc connecting the children nodes expresses that this is a conjunctive (AND) refinement, which means that all sub-goals have to be fulfilled. Refinements without such a connecting arc are disjunctive (OR), expressing that satisfying one sub-goal suffices

The strength of the attack tree methodology lies in the fact that its graphical, structured tree notation is easy to understand to practitioners, yet also promising for tool builders and theoreticians attempting to partially automate the threat analysis process. More and more research papers have been used attack trees in modeling security threat of information system. Over the last year, over 15,000 articles on GoogleÂÂ® Scholar[4] have been used the attack tree technique in some way. The way this technique is used now is usually by assigning different kinds of values to the leaf nodes (for example, possible and impossible, expansive and inexpensive, cost to attack, probability of success of a given attack, etc.) then propagating node values up the tree following some rules. Based on that calculation, people can make some statements about attacks, for example, what is the cheapest low-risk attack or most likely non-intrusive attack[5].

In retrospect personal experiences, we notice that what we have done in the past and until now are closely related to what is presented in Attack Trees model, although back by that time, we were not exposed to concept of Attack Trees, but the approach is basically the same. It was when we worked on a project and had to define all possible risks/threats that might happen and how we can take mitigate actions against those risks. The only thing that we had not paid enough attention to, and was actually very important thing, was how all those risks might happen. Failing to do this costs us a lot later on when the risk did happen in a way that we had not thought of, so did not develop appropriate cause of actions and we were passively react to it. It was when we were developing an online testing system to help students prepare for entrance exam to universities[6]. We would have a strong team of excellent teachers from many famous schools build the test content; and have a team of people to import those tests, including answers (multiple choice format), into the system. We conducted training for importing team. (Also, the importing work did take a lot of time so we could not talk all the teachers into it). Things went well until the day we actually launched the Beta version. We had volunteers, who were actual pupils, do the test; it was nothing better for them to take free tests and receive free feedbacks. But when it came to result announce and feedbacks were given to those pupils, everything was just totally wrong; many of student answers, which were actually correct, were marked incorrect and the must-be-correct answers given by the system were actually incorrect. Recalling that single day, it was a BIG shame on us, the team who worked on the project. We had a person head of quality control who would make sure that all the tests designed, including questions and answers, are without mistakes. We were very strict on that. We also had a head of training department who will make sure that our collaborators, who performed importing job, do their job carefully and without mistakes. Random test were taken before we launched the first version and things were all going very well. We developed risk monitoring blocks and figure 2 is shown as an example. For a risk that the test is invalidate, we clarified three possible reasons: design problem, importing problem and system problem. The reasons are then tracked further along blocks which are colored accordingly. So to prevent or mitigate the risk, we only need to make sure that our teacher quality is excellent, our training and importing job are done beautifully and our system will not malfunction. But we only did to the extent that, for example, as long as our collaborators work diligently and carefully, mistakes would largely be avoided. Later on, we found out the root of the problem was that one of our collaborator was person from our main competitor and he purposely destroyed our system by changing all correct answers just a night before the free testing event. This was the thing that we had never thought of. We did not think that we had problem right from the collaborators recruitment and that this might had been one of many possible ways that can invalidate our test bank. Until then did we know that what we called in general “collaborators quality” is not limited to the fact that whether they were capable of understanding and doing the job, but also including their working ethic. Consequently, we were left with everything beginning from scratch; all teachers work was carefully rechecked because we did not know right away what exactly caused the problem. Almost all the imported work was deleted and restarted. If we had been able to clarify this possibility, though small, we would have developed action appropriate enough to prevent it, such as lock the system and deny any access before we launched the first version, this would have saved us money and time and prestige as well. We finally were able to offer a running version but it surely had cost us much more resources.[7]

The attack trees

Order Now