Towards Collaborative Cyber Threat Intelligence for Security

Management

Oleksii Osliak

1,2

, Andrea Saracino

, Fabio Martinelli

and Theo Dimitrakos

Istituto di Informatica e Telematica, Consiglio Nazionale delle Ricerche, Pisa, Italy

Department of Computer Science, University of Pisa, Pisa, Italy

Huawei Technologies, Munich, Germany

Keywords:

Access Control, Policy Update, Cyber Threat Intelligence, Amazon Web Services.

Abstract:

Managing access to resources is one of the security mechanisms used for protecting the organization’s assets

from unauthorized usage, and thus potential data leaks. Thus, keeping access control policies up to date is a

crucial task for any organization. However, the access control policy update process usually requires direct

interaction of security specialists, which have knowledge and experience in counteracting abuse of privileges.

Therefore, in this paper, we consider access control policies update using collaborative knowledge in the latest

cyber activities. We describe the correlation between security policies and security reports using ontology for

cybersecurity. Finally, we present a framework that enables access control policies update within the Cloud

infrastructure offered by Amazon using Cyber Threat Intelligence.

1 INTRODUCTION

An important security requirement for any infor-

mation management system is to protect data and

resources from unauthorized access, and improper

modiﬁcations still providing availability of those re-

sources. An enforcement of such protection requires

that every access to a system, resources and data is

controlled only allowing accesses that should be au-

thorized. The evaluation of a certain access request to

execute an operation on a resource is done according

to security policies, which deﬁne rules for access con-

trol regulation. Security policies can allow or deny the

execution of certain operations on resourses depend-

ing on roles assigned to users or attributes that charac-

terize a particular user. Additionally, security policies

can contain other attributes used to describe context

information (e.g., date, time, location, etc.) that can

inﬂuence decision making. Since security policies

play a critical role in organizations’ assets protection,

it is important to regularly update policies and control

the way those policies are updated. The security pol-

icy update process may be caused by various factors

including the data breach that took place in a system

and external knowledge about potential data breaches.

Nowadays, security specialists from various organiza-

tions and communities share threat-related informa-

tion better known as Cyber Threat Intelligence (CTI)

to prevent cyber-attacks and their spread. According

to NIST (Johnson et al., 2016), CTI sharing allows de-

veloping new and improving existing security mech-

anisms to predict and prevent potential cyberattacks

and defend organizations’ assets. However, various

tools that support CTI usage and enforcement, usu-

ally require direct human interaction which is a cum-

bersome process that might require a large amount of

time. Moreover, security specialists share CTI using

different formats, thus following different ontologies.

In this paper, ﬁrstly we describe the interconnectiv-

ity between security reports and access control poli-

cies components using ontology. Secondly, we pro-

pose and describe a framework and its components

for access control management within the Cloud envi-

ronment using collaborative knowledge about cyber-

attacks in the form of structured reports. Finally, we

present practical example of the usage of the proposed

approach.

The paper is structured as follows. In Section 2,

we provide simple formalization of Attribute Based

Access Control model together with a deﬁnition of

Cyber Threat Intelligence and tools used for its shar-

ing. Section 3 describes the correlation between secu-

rity reports and security policies. Section 4 presents

and describes the security policy update process. Sec-

tion 5 describes the proposed framework as well as its

components. Finally, we provide related work in Sec-

Osliak, O., Saracino, A., Martinelli, F. and Dimitrakos, T.

Towards Collaborative Cyber Threat Intelligence for Security Management.

DOI: 10.5220/0010191403390346

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 339-346

ISBN: 978-989-758-491-6

339

tion 6, and Section 7 concludes the paper with a plan

for future work.

2 BACKGROUND

In this section, we provide a background knowledge

in access control and CTI approaches.

2.1 Access Control

Proper control of access to assets is one of the

fundamental techniques for securing assets against

cyberattacks and data abuse. Existing tech-

niques and models like Role Based Access Control

(RBAC) (Sandhu, 1998) and Attribute Based Access

Control (ABAC) (Jin et al., 2012) are widely used

by organizations for controlling access both to phys-

ical and cyber resources. Meanwhile, RBAC and

ABAC are the most used models that follow differ-

ent approaches. While subjects in the RBAC poli-

cies are deﬁned through assigned roles (e.g., profes-

sor, student), in the ABAC model, both subjects and

objects deﬁned through the set of corresponding at-

tributes. Thus, decision-making depends on the cur-

rent attribute values. Furthermore, the ABAC policy

allows deﬁning context information through the set of

corresponding attributes and considers roles assigned

to subjects as additional attributes. Hence, the ABAC

model allows policymakers to deﬁne ﬁne-grained

policies and express certain conditions through envi-

ronmental attributes that do not belong directly to the

subject or object.

In this work, we consider access control policies

as policy objects that are speciﬁed by subjects, ob-

jects, environment and operations. Formally, we de-

note S, O, E and OP as ﬁnite sets of subjects, ob-

jects, environment and possible operations allowed in

the system respectively. SA, OA and EA denote a set

of subject, object and environmental attributes respec-

tively. The policy object P is deﬁned in a form of a tu-

ple P := hSA, OA, EA, opi, where SA, OA and EA de-

note subject, object and environmental attribute con-

ditions, deﬁned as sets of attribute name-value pairs.

Finally, the op ∈ OP is possible operation from a set

of operations OP. The following example presents

a policy that allows a subject with a role student or

supervisor to execute read and write operations on a

ﬁle1 and ﬁle2 iff the current time when the system re-

ceived a request is in the range between 9 and 18.

:=hh∃role.student ∨ role.supervisori∧

h∃operation.read ∧ operation.writei∧

h∃ob ject. f ile1 ∧ ob ject. f ile2i∧

h∃currentTime ≥ 9 ∧ currentTime ≤ 18ii

In fact, the subject can have other attributes in-

cluding speciﬁc ID number, associated risk level, etc.,

meanwhile, we skip these attributes for simplicity.

2.2 Cyber Threat Intelligence

Nowadays, many organizations produce, collect and

share information related to cyber threats. Accord-

ing to National Institute of Standards and Technology

(NIST)(Johnson et al., 2017), Cyber Threat Informa-

tion is any information related to threats that might

help organizations in protecting themselves against

cyber threats or in detecting the activities of a threat

agent. While, Cyber Threat Intelligence (hereinafter

CTI), is what threat information becomes after its pro-

cessing and analysis. Another deﬁnition given by

Gartner considers CTI as evidence-based knowledge

that includes context, mechanisms, indicators, impli-

cations and actionable advice about an existing or

emerging menace or hazard to IT or information as-

sets. Many organizations (e.g., NIST

, MITRE

) have

formulated enumerations of types of malware, vul-

nerabilities, and exploitations. Particularly, MITRE

maintains three dictionaries, namely Common Vul-

nerabilities and Exposures (CVE)

, Common Plat-

form Enumeration (CPE)

and Common Weakness

Enumeration (CWE)

. Additionally, the classiﬁcation

of attack patterns provided within Common Attack

Pattern Enumeration and Classiﬁcation (CAPEC)

and standardized in OASIS, XML/JSON-structured

language for CTI representation i.e. Structure Threat

Information Expression (STIX)

Nowadays, the STIX standard is the most widely

in use language for describing CTI in a structured

way. The CTI report described through the STIX 2.0

standard is a collection of multiple STIX Domain Ob-

jects (SDOs) and STIX Relationship Objects (SROs)

that describe different concepts in domain and how

those concepts relate to each other. Each SDO is

https://www.nist.gov/

https://www.mitre.org

https://cve.mitre.org/

https://cpe.mitre.org/

https://cwe.mitre.org/

https://capec.mitre.org/

https://oasis-open.github.io/cti-documentation/

http://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-part2-

stix-objects.html

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

340

based on a set of attributes known as properties (Intel-

ligence, 2020). Each property deﬁnes speciﬁc infor-

mation related to cyberattack including vulnerability

ID, malware name, a pattern for a ﬁle with a given

hash, textual recommendation for a countermeasure,

etc. Furthermore, some properties can contain in-

formation related to a speciﬁc entity (e.g., adversary

or victim) that allows security specialist using those

properties for further mitigation strategies. The ﬁnal

report with the description of a cyberattack and de-

scribed throught the STIX standard is represented as

a collection of SDOs and SROs.

3 SECURITY POLICIES AND

SECURITY REPORTS

In this section, we describe relationships between ac-

cess control policy components and CTI elements us-

ing ontology for cybersecurity. As a backbone taxon-

omy, in this work, we adapt the DOLCE-spray (Oltra-

mari et al., 2013) ontology that is a simpliﬁed version

of Descriptive Ontology for Linguistic and Cognitive

Engineering (DOLCE) (Masolo et al., 2002).

DOLCE aims at capturing the conceptual primi-

tives underlying natural language and commonsense

reasoning. DOLCE-spray hierarchy deﬁnes entity as

at the class of anything that can be identiﬁable as an

object. The entity is a root component that is deﬁned

in concrete entity and abstract entity. The concrete

entity instances are located in deﬁnite spatiotemporal

regions, while instances of abstract entity do not have

inherent spatiotemporal dimensions. The concrete en-

tity deﬁnes continuant, occurrent, and physical qual-

ity that are entities with inherent spatial parts, entities

with inherent temporal parts and entities whose exis-

tence depends on their host respectively. The contin-

uant further deﬁnes agent, object and substance. The

agent describes person and group, while object de-

ﬁnes artifact and natural entity.

The abstract entity branch of DOLCE-spray’s

root deﬁnes abstract quality, information and char-

acterization. Furthermore, the characterization

deﬁnes role, plan, task and requirement. The

abstract quality class deﬁnes qualities that do not

have any spatiotemporal dimension, while infor-

mation refers to any content that can be conveyed

by some physical object. The characterization

deﬁnes a class for functions that map n-tuples of

individuals to truth-values. Antisymmetric relation

characterizes associates them with the objects

they denote. Finally, the requirement class deﬁnes a

set of demands either adopted or proposed by a group.

Following, we describe the alignment of the

STIX objects, which represent CTI elements, and the

DOLCE-spray ontology by using relations deﬁned in

the DOLCE-spray and using Description Logic (DL)

notation. It is worth noting, that STIX does not have

a speciﬁc STIX Domain Object to describe the system

or network, instead, it conveys information about cy-

bersecurity related entities such as ﬁles, systems, and

networks using the STIX Cyber-observables

. Hence,

for further deﬁnition of an asset i.e., a system that

was attacked, we will use STIX Observed Data ob-

ject denoted as Observed Data

sys

. We used DOLCE-

spray relations including characterizes, isQualityOf,

hasParticipant, uses, exploits and executes to describe

the alignment between DOLCE-spray and STIX stan-

dard.

Identity

v ROLE u ∀characterizes.AGENT

Identity

v ROLE u ∀characterizes.AGENT

Identity

v ¬Identity

Observed Data

sys

v ROLE

u∀characterizes.OBJECT

u∀characterizes.INFORMATION

Malware v ROLE

u∀characterizes.(OBJECT t INFORMATION)

Malware v ¬Observed Data

sys

Tool v ROLE u ∀characterizes.OBJECT

Tool v ¬Malware

Vulnerability v ABSTRACT QUALITY

uisQualityO f .Observed Data

sys

Attack Pattern ≡ PLAN

u∃hasParticipant.Malware

u∃hasParticipant.Tool

u∃exploits.Vulnerability

Threat Agent ≡ Identity

u∀exploits.Vulnerability

u∃executes.Attack Pattern

u∃uses.(Tool t Malware)

Indicator v ARTIFACT

u∀characterizes.Threat Agent

Indicator v ARTIFACT u ∀characterizes.Malware

Indicator v ARTIFACT u ∀characterizes.Identity

Course of Action v ARTIFACT

uhasParticipant.PLAN

uhasParticipant.INFORMATION

umitigates.Attack Pattern

umitigates.Vulnerability

umitigates.Malware

https://docs.oasis-open.org/cti/stix/v2.0/stix-v2.0-

part4-cyber-observable-objects.pdf

Towards Collaborative Cyber Threat Intelligence for Security Management

341

Since the STIX Identity object allows deﬁning

entities that suffer from cyberattacks as well as en-

tities that act in malicious attempts i.e., adversaries,

we used Identity

and Identity

to differenti-

ate adversary and victim entities. Hence, an adver-

sary Identity

is described as an agent that is char-

acterized by its role, while Identity

is an entity

that suffers from the cyberattack and tries to pro-

tect assets. Differently to the Identity object, the

Threat Agent describes the proﬁle of an adversary,

that may belong to multiple entities. In this case,

entities may use the same attack technique, strive to

achieve the same goal (e.g., ﬁnancial, personal gain,

etc.), have same available resources level, etc. Thus,

we deﬁne the Threat Agent as Identity

that ex-

ploits Vulnerability, executes an Attack Pattern

and uses Tool in order to deliver Malware. In fact,

both Malware and Tool are software variants, how-

ever, designed for different purposes. We deﬁne the

Attack Pattern as a Plan that deﬁnes Malware and

Tool required to exploit the Vulnerability, while

the Vulnerability is an abstract quality of a sys-

tem denoted as Observed Data

sys

. Finally, the coun-

termeasure used to protect the system against cyber-

attacks or minimize potential impact is deﬁned as

the Artifact that provides the mitigation Plan to-

gether with necessary Information in order to miti-

gate Attack Pattern, existing Vulnerability and

Malware used to exploit it. In our work, we consider

that any user can cause potential intentional or unin-

tentional threat to a system. One of the security strate-

gies to prevent a system from potential abuse and

protect assets, is to deﬁne ﬁne-grained access con-

trol policies and keep them up to date. Furthermore,

some complex attacks similar to ones that used Black-

Energy backdoor, were using multiple techniques, in-

cluding the exploitation of privileged accounts. Thus,

one of the mitigations of such attacks is to imple-

ment and use strong Identity and Access Manage-

ment (IAM) controls together with ﬁne-grained ac-

cess policies to minimize or eliminate loses caused by

illegal exploitation of privileged accounts. Therefore,

following, we describe the alignment of basic compo-

nents of ABAC model and DOLCE-spray ontology.

USER v ROLE u ∀characterizes.AGENT

DEVICE v ROLE

u∀characterizes.(ARTIFACT t INFORMATION)

SUBJECT v ROLE u ∀hasParticipant.(USER t DEVICE)

OBJECT v ROLE

u∀characterizes.(ARTIFACT t INFORMATION)

OBJECT v ¬DEVICE

OPERATION v ACTION u ∃exploits.OBJECT

ABAC POLICY v POLICY u ∃protects.OBJECT

In some scenarios, additionally to a user ID, a role

and other attributes, an IP address or network type

might be required to evaluate the user’s request. Thus,

in our work, we consider a user and device as inde-

pendent elements of the ABAC model, since different

users can request certain operations on an object using

the same device as well as one user can perform re-

quests using different devices. Hence, a subject is de-

ﬁned through the set of attributes that belong to a user

and device. Elements of the ABAC policy model and

STIX objects that constitute CTI reports are deﬁned

through their attributes. Since Indicators of Com-

promise (IoC) (e.g., IP and email addresses, names,

etc.) speciﬁed in CTI reports can identify adversaries,

these identiﬁers can be also used in ABAC policies to

restrict access to users under certain conditions speci-

ﬁed through IoC. Moreover, CTI reports also provide

other information including time-window, when the

malicious event occurred, and the number of obser-

vations of this event. This information can be used

in deﬁning the access control context of the policy.

Furthermore, many CTI reports provide textual rec-

ommendations known as countermeasures that can be

used either for eliminating or mitigating cyberattacks.

However, countermeasures speciﬁed in the CTI re-

ports provide a guidelines or a sequence of actions to

be taken for protecting resources, rather than modify-

ing security policies. Therefore, in our work, we use

IoC to extend policies with new conditions, and we

propose a method for extracting and enforcing miti-

gation strategies speciﬁed in CTI reports.

4 DEFINING ACCESS CONTROL

POLICY UPDATE

In this section, we describe the access control policy

update as a process that changes the state of the pol-

icy. In fact, any changes in access control policies can

increase or decrease access rights of a certain subject,

hence allowing previously restricted operations or re-

stricting operations that were allowed by the policy.

Furthermore, in some scenarios, a policy update pro-

cess might require the creation of a new element to

restrict some operations to be performed on an ob-

ject if certain conditions are not satisﬁed. Hence, the

process we consider includes 3 possible operations on

the policy i.e., policy update, policy creation and pol-

icy deletion. Following we describe each operation of

the process.

The policy update operation in further divided in

policy attenuation and policy restriction. We con-

sider the policy attenuation as an operation that in-

creases privileges of a subject, while the policy re-

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

342

striction decreases subject’s privileges by changing or

removing one or multiple policy elements. Let the

policy object P

:= hSA

, OA

, EA

, OP

i to be changes

to P

:= hSA

, OA

, EA

, OP

i. Hence, the policy ob-

ject P

is changed to P

by transforming the SA

and

to SA

and EA

respectively. Particularly, we con-

sider the policy update operation changes access con-

trol conditions speciﬁed in the policy object without

changing allowed operations speciﬁed in OP

. Sup-

posing that the policy 1 is changed to the policy 2, the

privilege of the subject with a name Alice decreased

since the level of associated risk deﬁned in the policy

decreased together with a time-window for accessing

the ﬁle1 and ﬁle2 objects. Hence, operations read and

write are no longer allowed for the subject Alice ex-

cept the deﬁned time-window from 11 to 15, and if the

associated risk level is less or equal to 5. Thus, this is

an example of policy restriction operation, since ac-

cess privileges of the subject has decreased. On the

other hand, the reverse operation, will increase the

access privileges, thus it can be treated as the policy

attenuation operation.

:=hh∃name.Alice ∧ riskLevel ≤ 8i∧ (1)

h∃ob ject. f ile1 ∧ ob ject. f ile2i∧

h∃currentTime ≥ 9 ∧ currentTime ≤ 18i∧

h∃operation.read ∧ operation.writeii

:=hh∃name.Alice ∧ riskLevel ≤ 5i∧ (2)

h∃ob ject. f ile1 ∧ ob ject. f ile2i∧

h∃currentTime ≥ 11 ∧ currentTime ≤ 15i∧

h∃operation.read ∧ operation.writeii

While the policy attenuation and policy restriction

operations target modiﬁcations of certain policy el-

ements, the policy creation targets creating the new

policy according to available policy templates. The

policy creation operation uses available policy tem-

plates to create the P

≡ hSA

, OA

, EA

, OP

i policy.

Considering only positive authorization policies with

default deny effect, the policy creation can be con-

sidered as a policy attenuation operation. Thus, be-

fore creating the policy P

, the subject S

could not

perform any operation on the object O

. Hence, we

denote P

as the ﬁctitious policy that denies all oper-

ation requested by a subject S

to be enforced on the

object O

. Thus, the policy creation can be treated as

the policy attenuation operation, when the policy P

is changed to the P

policy.

Finally, the policy deletion operation is used for

removing security policies from the database to elim-

inate the policy conﬂict caused by different effects

of those policies for a single user. However, the

policy deletion operation can be treated as the pol-

icy restriction operation since by removing the policy

≡ hSA

, OA

, EA

, OP

i might result in restriction of

some operations for the subject S

5 PROPOSED FRAMEWORK

In this section, we present and describe our frame-

work shown in Figure 1, the architecture of the tool

for security management, and its deployment. The

proposed framework consists of three main compo-

nents following described.

The ﬁrst component of the framework is the Ama-

zon Web Services (AWS) account that provides a va-

riety of cloud services to which access is controlled

according to implemented RBAC and ABAC (Zhang

et al., 2015) models. Particularly, the management of

the AWS account is done with the Identity and Access

Management (IAM

) service, that allows customers

creating or removing users, assigning them individual

credentials, or request temporary security credentials

to provide users access to other AWS services and re-

sources.

The second component of the framework is Threat

Intelligence Sharing Platform (TISP) that acts as the

black box allowing users to store and share CTI in the

form of structured reports under security constraints

speciﬁed in Data-Sharing Agreements (DSA) and de-

ﬁned by the data controller. Hence, only authorized

entities can use shared and sanitized form of CTI re-

ports. To deﬁne and enforce DSA, in (Martinelli et al.,

2018) and (Osliak et al., 2019), authors proposed an

approach used for the DSA representation and en-

forcement of Data Operation Manipulation speciﬁed

in that DSA.

The third component of the framework is the Se-

curity Management Tool (SMT) that retrieves CTI re-

ports from the TISP, and it also communicates with

the AWS account. Following, we describe the SMT,

its elements, and functionalities.

5.1 Security Management Tool

This sub-section reports and describe a component of

the proposed framework. The core component of the

framework is the Security Management Tool (SMT)

that includes 9 elements as shown on Figure 2. The

CTI Manager element is in charge of performing mul-

tiple retrieval operations on CTI reports speciﬁed ac-

cording to the STIX standard. The element inter-

acts with the Context Analyzer and Attribute Engine

https://aws.amazon.com/iam/

Towards Collaborative Cyber Threat Intelligence for Security Management

343

Figure 1: The proposed framework.

Figure 2: Security Management Tool.

elements by respectively forwarding Course of Ac-

tions (CoA) and attributes retrieved from the STIX

report. The Context Analyzer is in charge of per-

forming analysis of the CoA speciﬁed in the text for-

mat and selecting the most appropriate functions to

be performed within the AWS account. The ele-

ment exploits the advanced Natural Language Pro-

cessing (NLP) approach offered by the Spacy

li-

brary. Hence, the Context Analyzer uses a combina-

tion of multiple functions used for the text analysis,

including Part-of-Speech (PoS) tagging, Dependency

Parsing, and Semantic Similarity. Particularly, the

Context Analyzer element extracts root verb and noun

pairs and matches each pair with the list of function

names (e.g., remove user, attach policy, etc.) stored in

the Enforcement Operations element, using semantic

similarity determined by the word vectors compari-

son, selecting only those function names, whose sim-

ilarity is in the range from 98% to 100% in order to

not select random functions. Additionally, the Con-

text Analyzer can use the object of preposition (e.g.,

table, group, etc.) and related adjective to improve the

result of semantic similarity. Once the Context Ana-

lyzer deﬁnes the most appropriate functions, it for-

wards them to the Operation Manager element that is

in charge of enforcing operations in the AWS account.

As the function arguments, the Operation Manager

https://spacy.io

element uses attributes from the Attribute Engine and

it can also use additional information speciﬁed in the

CoA. The Attribute Engine element stores retrieved

attributes including IoC, names, and the number of

occurrences of a single cyber event within a certain

time-window. These attributes used by the Operation

Manager and Policy Manager elements in enforcing

functions within the AWS account and for policy op-

erations respectively. Hence, the Policy Manager is in

charge of updating existing and creating new policies

according to available templates and elements of pol-

icy conditions stored in the Policy Template and Con-

dition Components respectively. Finally, the Account

Manager element acts as an interface of the AWS

account and it is able to retrieve, create and upload

policies, enforce operations speciﬁed in the Opera-

tion Manager element, and retrieve account activity

using AWS CloudWatch

service. The CloudWatch

service allows monitoring activity within the AWS ac-

count and use log ﬁles for different security purposes.

5.2 Practical Example

To better explain and demonstrate the functionality of

our approach, in this section we illustrate an example

of countermeasure speciﬁed in the CTI report.

To exploit vulnerabilities and steal information,

https://docs.aws.amazon.com/cloudwatch/

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

344

adversaries may manipulate accounts to maintain ac-

cess to victim systems while acting as legitimate

users (CERT, 2018) and perform iterative password

updates to bypass password duration policies to pre-

serve the life of compromised credentials (Ismail

et al., 2015). However, adversaries must already have

sufﬁcient permissions on systems in order to create or

manipulate accounts. Thus, potentially, adversaries

may use the compromised accounts of system admin-

istrators. One of the solutions for this attack is to limit

the privileges of those accounts either by updating se-

curity policies or removing certain user account from

the system.

Therefore, in our work, in order to extend access

control policies within the AWS account, we used ma-

licious IP addresses shared with the MISP

platform,

while in order to extract a sequence of security op-

erations and enforce them within the AWS account,

we used the Mitre Att&ck (Strom et al., 2018) frame-

work that provides real-world observations of adver-

sary tactics and techniques as well as related coun-

termeasures. Particularly, we used synthetic CTI re-

ports that include IoC, a description of the technique

used in attack implementation and countermeasures

to prevent this attack. Hence, the CTI report we con-

sidered denotes that the adversary uses a device with

certain IP address in order to access the system and

exploits Account Manipulation

technique to obtain

conﬁdential information, while one of the counter-

measures

is to remove a user from a system. Fig-

ure 3 illustrates the Privileged Account Management

countermeasure that addresses 80+ techniques used

for cyberattacks including the aforementioned sce-

nario. In this example, we retrieved the remove users

Figure 3: Countermeasure: example.

function name and compare it with the available func-

tions in AWS by using word vector similarity to select

a sequence of functions that have maximum similar-

ity with retrieved function name. As the essential and

additional function arguments, we use group and ad-

ministrator respectively in order to deﬁne a domain

where the function has to be enforced, and we com-

pared these functions arguments with group names

https://www.misp-project.org

https://attack.mitre.org/techniques/T1098/

https://attack.mitre.org/mitigations/M1026/

available in the AWS account. Moreover, the selected

function also use a set of attributes retrieved from CTI

reports. In fact, with our approach, we were able to

retrieve more function names in other countermeasure

strategies. However, due to the speciﬁcity of opera-

tions available in AWS IAM, with our approach, we

were able to enforce limited number of operations re-

trieved from the CTI reports.

Finally, in our work, we did not consider

platform/service-related CTI reports that provide

more speciﬁc information about potential cyberat-

tacks and countermeasures to be taken to prevent or

mitigate those attacks. On the other hand, organiza-

tions can use speciﬁc properties of STIX objects (e.g.,

labels, custom properties) to specify the platform/ser-

vice, to which the countermeasure has to be enforced.

Meanwhile, by using the proposed approach, security

specialist can create and enforce custom operations in

other domains rather than AWS account management.

6 RELATED WORK

Although many works appear in the area of security

policies, the policy updates process received little at-

tention. In (Ray and Xin, 2004) authors proposed an

algorithm for policy updates process that includes 4

possible operations on a policy object. Meanwhile,

the authors considered simple authorization policies

without taking into account any contextual informa-

tion like date, time, etc. Furthermore, the proposed

policy update process modiﬁes only access rights i.e.,

actions allowed for a subject on a single object. More-

over, the usage of external knowledge for updating

policies was out of the scope. While in our work, we

consider more complex policies that deﬁne subjects,

objects, actions, and access context through the set of

corresponding attributes. Hence, in our work, the pol-

icy update process changes multiple policy elements

rather than actions only. Furthermore, the policy up-

date is implemented according to external knowledge

in potential cyberattacks reported in a form of struc-

tured reports.

In another work (Yang et al., 2014), the authors

proposed multiple policy updating algorithms for dif-

ferent types of access policies within the Cloud in-

frastructure. Meanwhile, this work does not use any

information useful for policies update, thus restrict-

ing access to users that potentially threatening the sys-

tem. However, in our work, we also describe a corre-

lation between security policies and security reports

elements, and we update policies according to collab-

orative CTI.

Towards Collaborative Cyber Threat Intelligence for Security Management

345

7 CONCLUSION

Updating security policies is a crucial task for any

organization. In this study, we present and describe

a framework that aims at supporting security poli-

cymakers within the Cloud infrastructure by provid-

ing possible actions to be taken for improving cur-

rent IAM using collaborative knowledge in cyberse-

curity. The proposed framework uses collaborative

and anonymized CTI shared through the threat intel-

ligence sharing platform and preprocesses CTI with

the proposed tool that exploits NLP approach. We

described a correlation between elements of attribute-

based access control policies and security reports us-

ing the most comprehensive ontology in cybersecu-

rity. We present and describe the policy update pro-

cess that modiﬁes policy elements using IoC reported

in security reports.

In future work, we plan to extend our approach to

handle more complex attribute-based access control

policies used in speciﬁc environments e.g., industrial

sector, and enforce countermeasures speciﬁed in CTI.

Moreover, we consider extending our framework with

additional components for evaluating the effect of the

updated policies on the overall system’s security, and

thus, test the efﬁciency of new policies. Hence, the

future version approach will allow authorized users to

access digital resources while preserving any access

from entities deﬁned in CTI reports.

ACKNOWLEDGMENT

This paper was partially supported by the EU H2020

funded project SPARTA, ga n. 830892.

REFERENCES

CERT, U. (2018). Russian government cyber activity tar-

geting energy and other critical infrastructure sectors.

Us Cert, pages 1–19.

Intelligence, O. C. T. (2016 (accessed August 28, 2020)).

STIX 2.0 Speciﬁcation.

Ismail, Z., Leneutre, J., and Fourati, A. (2015). An at-

tack execution model for industrial control systems

security assessment. In Security of Industrial Control

Systems and Cyber Physical Systems, pages 157–167.

Springer.

Jin, X., Krishnan, R., and Sandhu, R. (2012). A uniﬁed

attribute-based access control model covering dac,

mac and rbac. In IFIP Annual Conference on Data

and Applications Security and Privacy, pages 41–55.

Springer.

Johnson, C., Badger, M., Waltermire, D., Snyder, J., and

Skorupka, C. (2016). Guide to cyber threat informa-

tion sharing. Technical report, National Institute of

Standards and Technology.

Johnson, C., Feldman, L., Witte, G., et al. (2017). Cyber-

threat intelligence and information sharing. Technical

report, National Institute of Standards and Technol-

ogy.

Martinelli, F., Osliak, O., and Saracino, A. (2018). Towards

general scheme for data sharing agreements empower-

ing privacy-preserving data analysis of structured cti.

In Computer Security, pages 192–212. Springer.

Masolo, C., Borgo, S., Gangemi, A., Guarino, N., Oltra-

mari, A., and Schneider, L. (2002). The wonderweb

library of foundational ontologies.

Oltramari, A., Vetere, G., Chiari, I., Jezek, E., Zanzotto,

F. M., Nissim, M., and Gangemi, A. (2013). Senso

comune: A collaborative knowledge resource for ital-

ian. In The People’s Web Meets NLP, pages 45–67.

Springer.

Osliak, O., Saracino, A., and Martinelli, F. (2019). A

scheme for the sticky policy representation supporting

secure cyber-threat intelligence analysis and sharing.

Information & Computer Security.

Ray, I. and Xin, T. (2004). Implementing real-time update

of access control policies. In Research Directions in

Data and Applications Security XVIII, pages 65–80.

Springer.

Sandhu, R. S. (1998). Role-based access control. In Ad-

vances in computers, volume 46, pages 237–286. El-

sevier.

Strom, B. E., Applebaum, A., Miller, D. P., Nickels, K. C.,

Pennington, A. G., and Thomas, C. B. (2018). Mitre

att&ck: Design and philosophy. Technical report.

Yang, K., Jia, X., Ren, K., Xie, R., and Huang, L. (2014).

Enabling efﬁcient access control with dynamic policy

updating for big data in the cloud. In IEEE INFO-

COM 2014-IEEE Conference on Computer Commu-

nications, pages 2013–2021. IEEE.

Zhang, Y., Patwa, F., and Sandhu, R. (2015). Community-

based secure information and resource sharing in aws

public cloud. In 2015 IEEE Conference on Collab-

oration and Internet computing (CIC), pages 46–53.

IEEE.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

346