An Abstract Argumentation Framework (AAF ), or System, as introduced in a seminal paper by Dung [6], is simply a pair A, R consisting of a set A whose elements are called arguments and of a binary relation R on A, called "attack" relation. An abstract argument is not assumed to have any specific structure but, roughly speaking, an argument is anything that may attack or be attacked by another argument. The sets of arguments (or extensions) to be considered are then defined under different semantics, which are related to varying degrees of scepticism or credulousness.
In this work, our goal is to start developing a tool to visualise security threats and related countermeasures as arguments, as if security was a continuous dynamic discussion between the administrator and the surveilled system. Existing automated tools to defend a system from such security threats are one potential solution, but a completely automated approach could undervalue the strong analytic capabilities of humans, particularly in problematic situations that require vigilant human oversight.
We measure the strength of subsets of arguments and single arguments in accordance with Argumentation Theory. We print such strength degrees in different colours with the purpose to immediately catch the attention of the Security Administrator on what is going on in his system, and help him to take a decision on the set of countermeasures to be considered.
In this section we briefly summarise the background information related to classical Abstract Argumentation Frameworks (AAFs) [6]. Argumentation semantics [6] characterise a collective "acceptability" for arguments. Respectively, adm, com, prf , and stb stand for admissible, complete, preferred, and stable semantics.
and for each a ∈ A defended by S, a ∈ S holds; -S ∈ prf (F ), if S ∈ adm(F ) and there is no T ∈ adm(F ) with S ⊂ T ; -S ∈ stb(F ), if for each a ∈ A\S, S a;
We also recall that the requirements in Def. 2 define an inclusion hierarchy on the corresponding extensions, from the most to the least stringent: stb(F ) ⊆ prf (F ) ⊆ com(F ) ⊆ adm(F ). Moreover, σ(F ) = ∅ always holds for each considered semantics σ (except for the stable one).
Definition 3 (Arguments acceptance-state). Given one of the semantics σ in Def. 2 and a framework F , an argument a is i) sceptically accepted if ∀S ∈ σ(F ), a ∈ S, ii) a is credulously accepted if ∃S ∈ σ(F ), a ∈ S and a is not sceptically accepted, and iii) a is rejected if S ∈ σ(F ), a ∈ S.
e, e e}. In F we have adm(F ) = {∅, {a}, {c}, {d}, {a, c}, {a, d}}, com(F ) = {{a}, {a, c}, {a, d}}, prf (F ) = {{a, d}, {a, c}}, and stb(F ) = {{a, d}}. Hence, argument a is sceptically accepted in com(F ), prf (F ) and stb(F ), while it is only credulously accepted in adm(F ).
Consider a small research and development company. This company cooperates with other (often large) enterprises for the development of complex goods. Such company possesses high-tech knowledge which has to be protected from competitors. The company needs to efficiently use its resources with the purpose to survive in a highly competitive market. In short, the company has the goal (i.e., asset) of ensuring the productivity of operations (QoS).
In this small example, the security-system administrator has identified the following threats and related security controls (in square brackets): hacker penetration (HP) [host IDS (HI), network IDS (NI)] (where IDS stands for Intrusion Detection System), employee abuse (EA) [monitoring functionality (MF), audit procedures (AP)], and compromise of communication channel (CCC) [virtual private network (VPN), encrypted line (EL)].
We would like to emphasise that abstract arguments have no internal structure, and are not "directly linked" to classical logic. For this reason, we can consider multiple sources of information but and belief, such as case law, common sense, and expert opinion. We can consider information coming from multiple network-sensors, in the form of logs, warnings, and errors. Facts and beliefs can be also taken from internal policy documents, and standard documents as well. For instance the Standard of Good Practice for Information Security, is a business-focused, practical and comprehensive guide to identifying and managing information security risks in organizations and their supply chains. The 2011 Standard is aligned with the requirements for an Information Security Management System (ISMS) set out in ISO/IEC 27000-series standards, and provides wider and deeper coverage of ISOIEC 270023 control topics, as well as cloud computing, information leakage, consumer devices and security governance.
To work on our example we use SecArg4 (Security with Arguments). SecArg is based on ConArg [4,5] (ARGumentation with CONstraints), which is an Abstract Argumentation reasoning-tool using the Gecode library5 , an efficient C++ environment where to develop constraint-based applications. The input (text) file passed to SecArg contains the list of arguments partitioned into countermeasures, threats, assets, and attacks between them: for instance, countermeasure(HI), threat(HP), att(HI,HP) (hacker penetration is prevented by a host IDS). SecArg visually represents the different nature of arguments with different colours: green for countermeasures, red for threats, and yellow for assets.
A more extended example is represented in Fig. 2. In such AAF we have that executing a host IDS and a monitoring functionality on the same machine (i.e., HI&MF) impacts on its QoS. Hence, we pose an attack between them, and we also consider not having HI (NotHI) or MF (NotMF). Moreover, we have some countermeasures in conflict, i.e., EL or VPN, and MF.
We obtain three stable extensions (we use the stable semantics because it is the most sceptical one, see Sec. 2): i) {AP, VPN, EL, HI, NI, NotMF, QoS}, ii) {AP, VPN, EL, HI, NI, HI&MF}, and iii) {AP, VPN, EL, NI, NotHI, NotMF, QoS}. In this case, reasoning in terms of stable or preferred semantics is the same, since they both returns the same three extensions. Reasoning on the scep- tical acceptance of arguments in such three extensions, we obtain that AP, VPN, EL, NI are sceptically accepted (i.e., "always"). This means that, for the attack-/countermeasure scenario we have depicted, having audit procedures, a virtual private network, an encrypted line, and a network IDS is always considered a valid argument. Therefore, they correspond to a strong suggestion for the security administrator. On the other hand, there are some other arguments that are rejected (see Def. 3), that is they never appear in such extensions; for instance EA, HP, MF, and CCC. All three threats are successfully "avoided", in the sense that adopted security countermeasures always prevent all of them. Moreover, also adopting the monitoring functionality countermeasure is not a good idea given this scenario, since it is rejected as well. Finally, the remaining arguments appear sometimes but not always in such three extensions (they are credulously accepted, according to Def. 3): NotHI (in 1 extension), HI&MF (1), HI (2), NotMF (2), QoS (2). The number of times they appear is visually highlighted in SecArg by filling arguments with different shades of grey, and also returning the appearance ratio, e.g,. 66.6% for QoS and 33.3% for NotHI. This can be interpreted as a strength-score for these arguments: for instance, having an host IDS beats not having it (2 to 1): hence the administrator is recommended to use it. For the sake of presentation, in Fig. 3 we use thick continuous circles for sceptically accepted arguments, thin/thick dotted circles for credulously accepted ones (respectively for lower/higher ratio of appearance, e.g., QoS is thicker than NotHI), and light-grey circles for rejected arguments.
Since the application of Argumentation to Cybersecurity-related issues is relatively a new field (or, at least, not deeply investigated), there is a few related work to be mentioned. A bunch of works applying Argumentation-based conflictresolution to the specific case of firewall rules are [1][2][3]. In our approach, however, we would like to provide a general reasoning-tool.
In [8] the authors suggest the use of Argumentation to provide automated support for Cybersecurity decisions. Three different tasks where Argumentation can contribute are surveyed in the paper: first, the establishment of a security policy, drawing from a range of information on best practice and taking into account likely attacks and the vulnerability of the system to those attacks. Secondly, the process diagnosis to determine if an attack is underway after some apparent anomaly in system operation is detected; the final goal is to decide what action, if any, should be taken to ensure system integrity. At last, Argumentation can be used to reconfigure a security policy in the aftermath of a successful attack: this reconfiguration needs to ensure protection against future similar-attacks, without creating new vulnerabilities.
In [7] the authors propose how arguments can support the decision making process: the aim is to help the system security administrator to react (or not) to possible ongoing attacks. For instance, a decision can be taken either to disable traffic through port 80 or not to disable it.
In the next future we would like to extend SecArg from both the theoretical and practical point of view by i) interactively changing the AAF with a new node or attack and immediately see how much such modification impacts on the strength of arguments; ii) selecting a subset S of arguments and get the minimal amount of change to the AAF that transforms S into an extension satisfying a given semantics (e.g., preferred).