Supporting Cyber Threat Analysis with Service-Oriented Enterprise

Modeling

Kees Leune

and Sung Kim

Adelphi University, 1 South Avenue, Garden City NY, U.S.A.

Keywords:

Conceptual Modeling, Threat Modeling, Service-Oriented Architecture, Service-Oriented Computing,

Conceptbase, Threat Analysis, Indicators of Compromise, IOC.

Abstract:

Today’s enterprise environment is rapidly changing with organizations adopting cloud services at record rates.

This deperimeterization of enterprise computing architectures depends on software as a service (SaaS) and

makes traditional perimeter-based defense controls less effective. We propose a service-oriented threat model-

ing approach that focuses on the perspective of a service consumer. We supplement our approach by providing

an implementation view that includes technical details of service implementations that can be queried to iden-

tify potential vulnerabilities in the system. Our approach differs from existing threat modeling methods in that

we seek to capture interactions between services in a technologically agnostic manner. This extends the appli-

cability of our model into the realm of security operations. A case study and proof-of-concept are presented

to validate our approach and demonstrate how such a model can be used to provide meaningful support for

operations engineers.

1 INTRODUCTION

Threat modeling is commonly used to denote a pro-

cess that systematically enumerates attack vectors and

potential weaknesses at design time. As such, it is a

tool widely used by cybersecurity builders. However,

the term threat modeling, as used in cyber defense, is

somewhat of a misnomer since it is generally not used

to model actual threats. Rather, cyber threat model-

ing methods are used to describe systems, and to sup-

port analysis of those systems, to identify and analyze

threats.

Many different approaches to threat modeling

have emerged in literature in the recent past. Most

of those position threat modeling as an activity that

should be performed as part of requirements engi-

neering and systems design efforts. For example,

(Dhillon, 2011) sees threat modeling as a conceptual

exercise to analyze a system’s architecture or design

to ﬁnd security ﬂaws and to reduce architectural risk.

He acknowledges that threat modeling can occur at

any time during a system’s life cycle, but recommends

it to be part of the architecture or design phase. More

recently, (Sion et al., 2019) deﬁned threat modeling

as entailing the systematic enumeration of misuse and

https://orcid.org/0000-0003-1171-6410

https://orcid.org/0000-0002-1344-5653

attack vectors and considering their applicability in

the system under design.

As early as 2008, (Malik et al., 2008) acknowl-

edged that threat modeling should be an ongoing pro-

cess and proposed a 7-step threat modeling approach

that loops continuously. However, the approach is de-

ﬁned at a high-level, and does not propose any spe-

ciﬁc methods by which each step should be accom-

plished. In this paper, we agree with with Dhillon and

Malik that threat modeling should be considered as an

ongoing process that continues beyond requirements

engineering and design into the deployment and oper-

ation of a full enterprise computing landscape.

Today’s environment is rapidly changing. Organi-

zations are adopting cloud services at a rate not seen

before, as 92% of organizations today have IT envi-

ronments that are at least partly in the cloud (IDG,

2020). Increased use of cloud services results in de-

creased visibility into the operations of those systems.

Consequently, traditional (perimeter-based) cyberse-

curity practices become less effective.

Employees are also increasingly removed from

the enterprise network as they complete their daily

duties from home. This trend started well before the

outbreak of the global COVID-19 pandemic, but the

move to telecommuting was signiﬁcantly ampliﬁed

and accelerated by lock-down mandates and social

Leune, K. and Kim, S.

Supporting Cyber Threat Analysis with Service-Oriented Enterprise Modeling.

DOI: 10.5220/0010502503850394

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 385-394

ISBN: 978-989-758-524-1

385

Figure 1: Deperimeterization.

distancing concerns.

The third observable trend is the increased adop-

tion of transport-level encryption (TLS) to crypto-

graphically protect network communications. As

of the time of writing this article, adoption of

the HTTPS-protocol to access websites exceeds

95% (Google, 2020).

The problem caused by these three coalescing

trends is illustrated in Figure 1, which shows that

most enterprise computing security controls, like ﬁre-

walls, intrusion detection/prevention systems, and/or

data loss prevent systems, are commonly placed at

the perimeter of the enterprise network. However,

with neither the service provider, nor the service con-

sumer present on that network, the effectiveness of

perimeter-based controls has decreased since data no

longer ﬂows through them.

The ongoing process of deperimeterization, in

which organizations continue to rapidly adopt cloud

services, and in which employees are increasingly

mobile, makes defending the enterprise environment

a much harder process. While some organizations re-

sort to the use of virtual private networks (VPNs) to

route network trafﬁc between service providers and

their employees through the enterprise network before

sending it back out to the Internet, we see this as a so-

lution that does not scale and will not be sustainable

in the long term. In addition, requiring employees to

establish VPN connections in order to access Internet-

based resources introduces additional attack vectors

into the protected enterprise network, thus potentially

decreasing the overall security posture of the organi-

zation. The increased use of end-to-end encryption

will continue to erode the effectiveness of perimeter-

based controls.

This realization leads us to formulate our research

problem as: deperimeterization of enterprise com-

puting architectures will continue, making traditional

perimeter-based controls increasingly less effective.

Our long-term research objective is to evolve cy-

ber threat modeling to provide meaningful support to

enterprise defenders operating in a deperimeterized

computing environment for identifying and analyzing

cyber threats. We ﬁrst need to determine the goal of

threat modeling, as well as the additional complexi-

ties introduced by operating in a deperimeterized en-

vironment. Next, we divide the modeling problem

into three separate sub-problems: modeling the enter-

prise computing environment, modeling threats, and

mapping threats to the environment. Each of these

steps will be validated through a manual exercise,

based on a case study. Lastly, we explore the pos-

sibility to automate each of these steps.

This paper will focus on addressing the ﬁrst of the

above objectives: how can we threat model deperime-

terized environments to adequately reﬂect a service-

oriented approach to software utilization? We posit

that traditional threat modeling approaches, mostly

undertaken during requirements engineering and for

systems design, can be augmented to provide mean-

ingful support for operations engineers. We propose a

model with main components that beneﬁts the service

consumer as well as the service provider.

To demonstrate our modeling process, we present

a case study and a proof of concept of our model-

ing proposal using ConceptBase implementing the O-

Telos language. We compare our modeling approach

vis-

a-vis traditional modeling techniques to see how

it better describes a deperimeterized environment and

how we can query our model to identify potential

threats to the described environment. We conclude

with directions for future work, including potential

approaches to automate this process.

2 RELATED WORK

2.1 Threat Modeling

Modeling is an activity in which an analyst creates

an abstract representation of the relevant aspects of

a system or process. Modeling approaches are gen-

erally speciﬁc to their purpose. For example, a data

model provides the analyst a vocabulary and a gram-

mar to express data stored in a system and/or moving

throughout a system.

Threat modeling is a structured method used to

identify possible threats to systems (Hussain et al.,

2014). Threat modeling is not new. In an early pa-

per, (Shostack, 2007) describes the experiences of

his team at Microsoft with threat modeling going

back as early as 1999. The modeling approach de-

scribed in the paper consists of four main activities:

diagramming using data ﬂow diagrams, per-element

threat enumeration using the STRIDE methodol-

ogy, mitigation, and validation. Other well-known

SECRYPT 2021 - 18th International Conference on Security and Cryptography

386

threat modeling methods include PASTA (UcedaV-

elez and Morana, 2015), Attack Trees (Schneier,

1999), VAST (Shevchenko et al., 2018) and OC-

TAVE (Alberts et al., 2003). All threat modeling ap-

proaches have elements in common: they deﬁne a

narrow, well-deﬁned vocabulary to describe concep-

tual elements, and the relationships that exist between

them. Some also propose a modeling process.

To be effective, cyber threat management pro-

cesses require that defenders have an established pro-

cess in place for mapping knowledge of known cyber

threats to the current state of their infrastructure. In

the context of product development, threat modeling

should be done early in the process. When developing

threat models to analyze enterprise networks, mod-

eling must be an ongoing process. As enterprise IT

landscapes are highly dynamic in nature, and new ser-

vices are adopted and brought to end-of-life continu-

ously, models of enterprise architectures must contin-

uously be updated to ensure that they are correct and

complete representations of the actual environment.

Approaches to threat modeling can be organized

into three categories: asset-centric, attacker-centric,

or software-centric (Shostack, 2007). In a later book,

Shostack argues for the software-centric approach as

the best option as it requires understanding the com-

plexity of the models, which results in substantial

improvement in the security of the software compo-

nents (Shostack, 2014). Focusing on assets requires

mapping those assets to software to be useful in iden-

tifying threats. Focusing on attackers often does not

create reproducible results. Focusing on the software

being built and the systems being deployed best incor-

porates the understanding of threats into the overall

operation of the system.

Threat modeling involves understanding the com-

plexity of the system and identifying all possible

threats to the system, regardless of whether or not they

can be exploited (Myagmar et al., 2005). The authors

discuss threat modeling in the context of requirements

analysis, which takes place prior to software design

and construction.

The focus on applying threat modeling techniques

to software development is prevalent throughout the

literature. For example, (Torr, 2005) states that “threat

modeling an entire product is typically too complex,

whereas doing so for individual features is too sim-

plistic.”

(Steven, 2010) takes a broader approach to threat

modeling. He deﬁnes it as “the process of enumer-

ating and risk-rating malicious agents, their attacks,

and those attack’s possible impacts on a system’s as-

sets.” However, Steven also argues that the adoption

of threat modeling as a common practice is lagging as

the result of many security managers considering it as

expensive and difﬁcult.

In a cloud-based environment, the natural exten-

sion is to shift to focus on services in threat model-

ing. Focusing on services incorporates the compre-

hensive model of the system as in software-centric

approaches, while considering the assets that are in-

volved in the provided services. It can represent the

system from the perspective of the service consumer.

2.2 Service-Oriented Computing

Service-Oriented Computing (SOC) was established

as a ﬁeld of research when it was described by (Pa-

pazoglou and Georgakopoulos, 2003) as the com-

puting paradigm that utilizes services as fundamen-

tal elements for developing applications with a num-

ber of focus areas for further exploration. In 2017,

these authors revisited their original article and paired

up with others to publish (Bouguettaya et al., 2017),

in which service-oriented computing is positioned as

having emerged as a cross-disciplinary research ﬁeld

that studies the science and technology underlying the

popularity of the IT service industry.

(Papazoglou, 2003) describes the Service Ori-

ented Architecture as a logical way of designing a

software system to provide services to either end-user

applications or other services distributed in a network

through published and discoverable interfaces and on

the premise that services are loosely coupled. (Le-

une, 2007) further identiﬁes services as an aggregate

of atomic computational operations and/or of other

services.

The service-oriented paradigm promotes describ-

ing the services provided by a technical infrastruc-

ture abstractly, and separates the description of the

service’s capabilities and interfaces from their imple-

mentation.

This approach closely resembles how modern

enterprises are deperimeterizing their IT infrastruc-

tures, and, consequently, provides a natural reference

framework. The service-oriented paradigm enables

an analyst to reason about both the capabilities pro-

vided by a service, as well as about the technical prop-

erties of the system used to provide the service.

3 SERVICE-ORIENTED

MODELING FOR CYBER

THREAT ANALYSIS

As mentioned earlier, threat modeling is predomi-

nantly embraced during the requirements analysis and

Supporting Cyber Threat Analysis with Service-Oriented Enterprise Modeling

387

design phases of a software engineering project. We

propose extending the practice by expanding threat

modeling to include separate stages for enterprise ser-

vice modeling and for cyber threat analysis.

Furthermore, threat modeling is commonly per-

formed by service providers, but its adoption by ser-

vices consumers is lagging. Our approach aims to ex-

tend the practice of threat modeling to beneﬁt service

consumers as well.

In this paper, we adopt a service-oriented perspec-

tive on enterprise modeling, rather than a network-

centric approach. We model services, data ﬂows, data

storage, and authentication systems conceptually (i.e.,

technology-agnostic), and then proceed to enrich the

model using technical implementation details. The

technical details provide an operational perspective,

which is mapped to the conceptual overview that pro-

vides the design view.

Our approach provides a mechanism for enterprise

service modeling in support of cyber threat analysis

conducted by service consumers. The deﬁciencies of

traditional modeling techniques in effectively model-

ing services from the perspective of a service con-

sumer can be attributed, at least in part, to the shift to-

wards cloud-based services. Since modelers typically

have fewer insights into the inner workings of the

technologies used to provide software-as-a-service,

modeling approaches that depend on the availability

of such information fall short.

Most of the existing threat modeling techniques

lack adequate expressiveness and semantics to enable

reasoning about threats. Therefore, the lack of ade-

quate semantics makes the development of automated

threat derivation tools and threat model validation dif-

ﬁcult (Mirembe and Muyeba, 2008). The most widely

used threat modeling approach, STRIDE, is based on

an enhanced version of the traditional data ﬂow dia-

gram (DFD) (Hussain et al., 2014). The four prim-

itive terms used in a DFD are the terminal (an en-

tity external to the model), the process, the data ﬂow

representing data-in-motion, and the data store repre-

senting data-at-rest. The models used in STRIDE ex-

tend these four primitives with a ﬁfth: a trust bound-

ary (Shostack, 2007). But in a service-oriented archi-

tecture, many of these concepts no longer apply or are

inaccessible to the analyst. The priority should be on

the capabilities of the services offered and the tech-

nical properties of how they are provided (Leune and

Kim, 2020).

Before we can establish a modeling approach, we

must identify the goals that we set out to achieve.

We believe that using threat modeling during require-

ments engineering and for systems design can be aug-

mented by evolving it to provide meaningful support

to enterprise defenders operating in a deperimeterized

computing environment.

The complexity of the discipline of secure systems

engineering requires automated tool support where

the precise deﬁnition and speciﬁcation of a threat be-

comes a prerequisite (Rouland et al., 2020). Speciﬁ-

cally, we intend to develop a method for mapping cy-

ber threat intelligence to enterprise service models in

a meaningful, and eventually, automated way. By do-

ing so, enterprise defenders will expand and improve

their situational awareness, and be able to better rec-

ognize and stop attacks.

Threat models based on services have been ex-

plored by (Kazim and Evans, 2016). They describe

(cloud) services as having four generic properties:

data storage, data processing, data transfer, and au-

thentication. Their approach uses these four proper-

ties as the basis for analyzing a select number threat

that apply to cloud services. For each threat, they

identify a threat actor and a possible method of at-

tack. While this approach can be useful, it falls short

of comprehensively analyzing the full computing en-

vironment.

Most modeling techniques incorporate knowledge

of potential threats, rather than knowledge of actual

threats. In part, that is caused by a relatively broad

approach to modeling. For example, consider a com-

posite service consisting of a web service that is ac-

cessed from a browser via HTTP/1.1 over a TLS 1.3

channel, and of an administrative service that is ac-

cessed via the secure shell protocol. Under traditional

modeling techniques, such a service would simply be

modeled as a collection of processes and data ﬂows,

without the semantic content that would be available

otherwise (Shostack, 2007). In particular, traditional

modeling approaches use data ﬂows merely to show

the existence of and the direction of the ﬂow of data

between structural components (Shostack, 2014). Our

approach seeks to address this deﬁciency by repre-

senting how data ﬂows between services.

We ﬁrst look at deﬁning the service as the funda-

mental concept on which this approach is based. We

then discuss how services can be combined and ex-

tended through orchestration practices. Lastly, we ex-

plore service interaction, as a basis for security anal-

ysis.

3.1 Model Semantics

Prior to deﬁning the syntactic elements of our threat

modeling approach, we introduce its main compo-

nents and explain their semantics.

As shown in Figure 2 The central concept in our

approach is the Service. Services contain data at rest,

SECRYPT 2021 - 18th International Conference on Security and Cryptography

388

Figure 2: Model Overview.

or they receive data ﬂows via ﬂow channels that rep-

resent data in motion. The model is described at

two levels of abstractions: a conceptual design view,

which describes technology-agnostic properties of the

model elements, and a speciﬁc implementation view,

which provides details about their implementation.

3.1.1 Services

Deﬁnition 1 (Service). A Service provides a unit of

work.

From a service consumer’s view, a service is often

considered as a self-contained black box that logically

provides business functions. This conceptual view al-

lows the consumer to reason about the functions pro-

vided by a service, without having to also consider its

technical implementation details and service-delivery

mechanism. This view, which we refer to as the de-

sign view, is most useful when analyzing business

processes, assessing overall system designs, and de-

termining data ﬂows into and out of the service.

However, service models used for security anal-

ysis cannot ignore implementation details. Speciﬁc

knowledge concerning application software, oper-

ating systems, networking conﬁgurations, etc., are

needed to conduct in-depth security analysis. Most

indicators of compromise that are obtained from

sources of cyber threat intelligence will provide such

details.

We acknowledge this by also deﬁning a sup-

plemental implementation view, which describes the

technical details of service implementations. Services

can directly provide functionality, but they can also

rely on other services to provide their functions. This

is known as service aggregation or service composi-

tion.

The design service view extends the work of

Kazim and Evans referenced earlier by acknowledg-

ing that internal service properties include details

about the nature of data stored and processed by the

service, and the mechanism by which it is stored, as

well as details pertaining to data transfer and authen-

tication.

Distinguishing the design view from the imple-

mentation view leads to several items of interest.

First, the comparison of actual behavior and intended

behavior allow for the automated detection of devia-

tions between the two. Any service that is used in a

way that was not expected should be considered for

further investigation. Second, the operational behav-

ior of a system can be observed through analysis of

event logs, such as authentication logs, access control

logs, etc.

3.1.2 Data Flows and Flow Channels

Deﬁnition 2 (Data Flow). Data Flows represent data-

driven interactions between services and other ser-

vices and/or actors playing roles of Service Providers

or Service Consumers. Data ﬂows are described in

the design view.

Services do not exist in isolation and are expected

to interact with other services and/or with individual

actors in speciﬁc roles. Data ﬂows have long been

used to represent such data-driven interactions, and

we adopt the concept to represent interactions be-

tween services as well.

Services are provided by a service provider and

consumed by a service consumer. Both are repre-

sented in our model as roles played by speciﬁc actors.

Knowing what entities interact with a service, and in

what capacity they do so, supports investigations and

may provide the ability to attribute speciﬁc threats to

threat actors. For example, the Diamond Model for

Intrusion Analysis (Caltagirone et al., 2013) explic-

itly identiﬁes actors in the roles of victim and/or ad-

versary. Including information regarding these actors

facilitates mappings to threat intelligence in a later

stage.

Data ﬂows are deﬁned at a conceptual level and, if

known, have a source and a destination.

Deﬁnition 3 (Flow Channel). A Flow Channel de-

scribes implementation-speciﬁc properties of data

ﬂows. Flow channels are described in the implemen-

tation view.

The channel through which data ﬂows is repre-

sented as a ﬂow channel and a mapping between the

data ﬂow and its ﬂow channel is maintained. Flow

channels are described by properties, which are key-

value pairs that capture protocols used, protections

added, and any other properties that may be deemed

relevant for analysis. For example, common ﬂow

channels properties include proto=https-over-tcp,

encryption=tls1.3, port=443, etc. Flow channel

properties can be made as speciﬁc or as ﬁne-grained

as needed.

Supporting Cyber Threat Analysis with Service-Oriented Enterprise Modeling

389

4 VALIDATION

We validate our approach by manually modeling a

case study, and then implement the model. Since

we begin with manual validation, the case study is

intended to be of relatively low complexity. In fu-

ture work, we will automate sections of the modeling

mechanism and expand testing with additional larger

case studies.

4.1 Case Study

The case study revolves around a hypothetical orga-

nization providing consultancy services to its clients.

To do so, it relies on several cloud-hosted services.

The organization’s employees all telecommute from

various locations around the United States. Employ-

ees communicate among themselves via a messaging

app, via email, and via video chat. Client contact is

generally done via email and video chat only. All

three of these services are adopted as software-as-a-

service (SaaS) and are accessible as web applications

and as mobile apps.

The organization manages its billing and time

planning through a uniﬁed time management plat-

form, which allows a project manager to deﬁne tasks,

and for consultants to log hours to those tasks. The

system is also used to generate billing information.

There is a small corporate ofﬁce, which is staffed

by the CEO and her executive assistant, as well as a

small sales staff. The staffers in the corporate ofﬁces

store their work on a self-hosted ﬁle storage device.

Remote employees can access the storage by connect-

ing to a virtual private network server, which is also

hosted on-premise.

4.2 Proof of Concept

We have implemented a proof-of-concept using Con-

ceptBase, a multi-user deductive database system im-

plementing the O-Telos language. It is a powerful

tool for metamodeling and engineering of customized

modeling languages (Jarke et al., 1995). As such, it is

an ideal tool for the task at hand. The ConceptBase

version used for this proof-of-concept implementa-

tion is designed as a client/server application.

The choice to use the Telos object model was

primarily motivated by our desire to unambiguously

deﬁne core modeling concepts, to be able to reason

about them, and to be able to query the model. We

found this ability in the O-Telos language, which pro-

vides facilities for constructing, querying, and updat-

ing structured knowledge bases (Mylopoulos et al.,

1990).

Service in Class with

attribute

description: ServiceDescription;

implementation: ServiceImplementation;

association: Role;

extends: Service

end

ServiceDescription with

attribute

dataflow: DataFlow;

data: DataElement;

authentication: Authentication

end

ServiceImplementation with

attribute

channel: FlowChannel;

storage: DataStorage;

authenticationMechanism:

AuthenticationMechanism

end

Listing 1: Model Deﬁnition Fragments.

Further beneﬁts of using the O-Telos implemen-

tation provided by ConceptBase include the ability to

query the model using a convenient logic-based syn-

tax, a clear frame-based representation format, and

the availability of a graphical browser that lets a user

easily manipulate constructs. ConceptBase also en-

forces integrity constraints, ensuring that models are

logically consistent at all times.

An O-Telos database has two primary represen-

tation mechanisms: a logic representation based on

proposition logic, and a frame representation that

more closely resembles a typical programming lan-

guage syntax. All expressions included in this paper

are written in frame syntax to ensure greater readabil-

ity.

4.2.1 Base Model

We begin building out the base model using Concept-

Base’s O-Telos frame syntax, and deﬁne a service as

shown in Listing 1.

A Service is an instance of a generic Class

and has four typed attributes: description is

typed as a ServiceDescription, implementation as a

ServiceImplementation, etc.

The ServiceDescription contains a description

of the service’s authentication mechanism, its data

storage mechanism, and incoming and outgoing data

ﬂows. Since O-Telos attributes can contain mul-

tiple values, any descriptive element can describe

multiple instances. The elements contained in the

ServiceDescription represent the design view.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

390

Figure 3: Model.

The implementation view is captured by the

ServiceImplementation, which refers to the imple-

mentation details of the data ﬂow channel, how data is

stored, and what authentication mechanisms are used.

Using ConceptBase’s GraphEditor, we can visual-

ize the full model as shown in Figure 3. Rectangles

represent named objects, black arrows with a solid

head represent named attributes, and magenta open-

headed arrows represent generalization relationships.

The graph deﬁnes the central Service concept

as above, but also contains deﬁnitions for the other

key modeling primitives. Speciﬁcally, it deﬁnes that

a ServiceDescription is associated with a Service

through its description attribute. The Service De-

scription contains DataElements that are stored by the

Service, and it describes the nature of the DataFlows

and Authentication requirements. DataElements are

described by properties. DataFlow can be deﬁned as

having a source Service and a destination Service, as

well as a brief description of the ﬂow. Note that at this

level, no technical details are included.

Likewise, the ServiceImplementation consists of

a description of the mechanism used for DataStorage

and of the mechanism by which the Service commu-

nicates with other Services. The model also maps

the service’s descriptions to their implementations.

For example, when considering the deﬁnition of the

FlowChannel, which describes the technical properties

of the channel through which a dataﬂow travels, the

mapping to that DataFlow is recorded as well.

4.2.2 Case Study Implementation

To support the proof-of-concept implementation of

the model, we once again use ConceptBase. How-

ever, rather than deﬁning the model at a class level, we

focus on instance levels. In this example, we imple-

ment the MessagingService and associate it with its

MessagingDescription in ServiceDescription with

dataflow

employeeMessagingFlow: MessagingFlow

data

messagingData: MessagingData

authentication

sso: SingleSignOn

end

MessagingWebChannel in FlowChannel with

dataflow

dataflow: MessagingFlow

property

protocol: HTTPS;

tcp: TCP443

end

MessagingImplementation in

ServiceImplementation with

channel

webChannel: MessagingWebChannel

authenticationMechanism

onPremSSO: OnPremSSOServer

end

MessagingService in Service with

description

description: MessagingDescription

implementation

implementation: MessagingImplementation

association

usedByClient: Client;

usedByEmployee: Employee

end

Listing 2: Case study deﬁnitions.

ServiceDescription and its ServiceImplementation.

Due to space limitations, we only include a partial

representation of the case study in this paper. The

deﬁnition of the messaging service, as is used by both

employees and clients to interact with each other, is

captured in ﬁgure 4. A sample of corresponding O-

Telos frames in provided in Listing 2.

The ServiceDescription describes the

MessagingService as one that is used by Client and

Employee, which are instances of the ServiceConsumer

Role. The service description identiﬁes one data

ﬂow (MessagingFlow) and one primary data element

(MessagingData). It also describes that the service

may only be accessed after a service consumer

authenticates using SingleSignOn.

The technical details describing the service are

captured in its ServiceImplementation, which de-

scribes a MessagingWebChannel through which the

MessagingFlow will travel. The channel uses the

HTTPS protocol via its default TCP port, 443.

The implementation details also describe the ser-

vice as using an on-premise single sign-on server

(OnPremSSOServer).

Supporting Cyber Threat Analysis with Service-Oriented Enterprise Modeling

391

Figure 4: Case study.

4.2.3 Using the Model for Analysis

Capturing a computing environment in the model-

ing approach outlined in this document helps an an-

alyst visualize the interactions between services and

actors. It also provides a mechanism for answering

questions. For example, on December 12, 2020, Fire-

Eye reported a security problem that was related to its

SolarWinds software (Thomson, 2020; Zetter, 2020).

Unit42, the Threat Intelligence Unit of Palo Alto Net-

works provides several publicly available Indicators

of Compromise that are likely associated with the

breach (jadefeather, 2020). Speciﬁcally, the IOCs

contain suspicious Internet domains, as well as ﬁle

hashes to consider.

Developing an O-Telos query for this situation is

relatively easy, as domain names are associated with

ﬂow channels.

SolarWindsQuery in QueryClass isA Service with

constraint

r: $ exists si/ServiceImplementation

(this implementation si)

and exists fc/FlowChannel

(si channel fc )

and exists fp/FlowProperty

(fc property fp )

and (

(fp in FlowChannelDestination) or

(fp in FlowChannelOrigin)

) and (

(fp domain "databasegalore.com") or

(fp domain "solartrackingsystem.net")

) $

end

The query uses the logic to limit the output

to only those services that match the constraints

speciﬁed above. First, the inheritance speciﬁca-

tion (isA Service) ensures only Services are returned.

Next, we limit the output set to only those services

that have a service implementation that contains a

ﬂow channel with an origin or a destination domain

that includes at-risk domains.

Using this logic, it becomes trivial to perform

threat analysis by querying the model against any

property to identify speciﬁc services.

In a more conventional threat modeling approach,

for example, one based on STRIDE-analysis of data

ﬂow diagrams, this interaction would have been dif-

ﬁcult to capture. Typically, external systems like So-

larwinds network management equipment, are repre-

sented as terminals, with limited information repre-

sented about them. Interactions between that termi-

nal and the system for which the threat model would

be developed would primarily focus on that system’s

expected functionality and not be readily usable for

analysis such as shown above.

5 DISCUSSION

When DFD-based threat models are used during re-

quirements analysis and to design software-based sys-

tems, interactions with third-party systems are typi-

cally modeled as terminals. Terminals are generally

not described in detail, as they are only considered as

points-of-contact with the environment in which the

newly developed system will function. As such, only

data ﬂows to and from the terminal are modeled. In a

deperimeterized scenario, such reasoning is no longer

sufﬁcient, and it is often necessary to capture addi-

tional details about such systems. SolarWinds, as a

network management tool, would be modeled as such

an external terminal, if it were modeled at all. Our

approach, which is able to capture additional relevant

aspects of such interactions, would be more suited for

analysis.

During the implementation of the case study, it be-

came clear that manual model creation and analysis

does not easily scale. To that effect, it will be neces-

sary to explore how modeling efforts can be supported

by analyzing electronic data sources. It is easy to

imagine a situation in which the implementation view

can be generated and/or supported with observations

derived from sources like netﬂows, application logs,

or authentication logs, while the design view contin-

ues to be primarily analyst-driven.

It also became clear that even simple case studies

become too complex to be fully comprehensible by

human analysts. While the modeling primitives are

intuitive, easy to understand, and can be applied with-

out much effort, resulting models may be too large for

the cognitive abilities of most human analysts.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

392

However, since the models are represented in a

computer-parseable way, they lend themselves for au-

tomated analysis. Several different approaches to

such analysis can be adopted. For example, the mod-

els provide a powerful mechanism to support deci-

sions made by analysts through their query mecha-

nism. In addition, it is conceivable that supervised

machine learning algorithms can be developed to an-

alyze the models to detect signiﬁcant anomalies.

One of the more pragmatic methods by which

these models can be used is by mapping existing in-

dicators or compromise to the implementation model

views. For example, IOCs describing speciﬁc IP ad-

dresses, host names, port numbers, protocols, soft-

ware versions, etc. map relatively easily to ﬂow chan-

nel properties, as shown in section 4.2.3.

Extending the model with role-based access con-

trol analysis techniques should be fairly easy to ac-

complish as well. The model accounts for the pos-

sibility to map actors to roles, and to associate spe-

ciﬁc service provider roles and service consumer roles

with services.

6 CONCLUSIONS AND FUTURE

WORK

The conﬂuence of increased adoption of cloud ser-

vices, the growing prevalence of end-to-end en-

crypted network communications, and the surge in

telecommuting activities has resulted in a signiﬁ-

cant drop in the efﬁcacy of perimeter-based controls.

This process of deperimeterization requires threat an-

alysts to rethink how they achieve and maintain sit-

uational awareness, analyze threats, and design and

build countermeasures.

This observation supports our long-term research

objective to evolve threat modeling into providing

meaningful support to defenders operating deperime-

terized enterprise computing environments.

In this paper, we looked at the ﬁrst stage of this re-

search: determining how enterprise computing land-

scapes can be described. In search of an answer,

we developed a service-oriented threat modeling ap-

proach that can be used to support threat modeling.

The central concept of the approach is to adopt

a service-oriented perspective, rather than a network-

centric approach. We model services, data ﬂows, data

storage, and authentication systems conceptually (i.e.,

technology-agnostic), and then proceed to enrich the

model using technical implementation details. The

technical details provide an operational perspective,

which is mapped to the conceptual overview that pro-

vides the design view.

Speciﬁcally, our paper makes the following contri-

butions: We adopt a service-oriented perspective, and

speciﬁcally that of a service consumer. Most exist-

ing threat modeling methods support analysis and de-

sign of software-based solutions, while we advocate

extending the use of threat modeling into the realm

of security operations. Our approach is speciﬁcally

intended to capture interactions between services, re-

gardless of their ownership or the platform through

which they are provided. Adopting a service-oriented

focus will allow us to capture security-relevant prop-

erties, other than data ﬂows. In the proof-of-concept

implementation, we captured data-at-rest and authen-

tication mechanisms as well. In addition to modeling

data ﬂows, we capture the properties of the channels

through which these data ﬂows travel. Doing so will

allow for more comprehensive analysis and facilitates

mapping to threat intelligence.

Automation will play a critical part in supporting

model maintenance and in threat analysis. Incorpo-

rating automation is the subject of future research.

REFERENCES

Alberts, C. J., Dorofee, A. J., Stevens, J. F., and Woody, C.

(2003). Introduction to the OCTAVE Approach. Tech-

nical report, Carnegie Mellon University Software En-

gineering Institute.

Bouguettaya, A., Singh, M., Huhns, M., Sheng, Q. Z.,

Dong, H., Yu, Q., Neiat, A. G., Mistry, S., Benatal-

lah, B., Medjahed, B., Ouzzani, M., Casati, F., Liu,

X., Wang, H., Georgakopoulos, D., Chen, L., Nepal,

S., Malik, Z., Erradi, A., Wang, Y., Blake, B., Dustdar,

S., Leymann, F., and Papazoglou, M. (2017). A ser-

vice computing manifesto: The next 10 years. Com-

mun. ACM, 60(4):64–72.

Caltagirone, S., Pendergast, A., and Betz, C. (2013). The

Diamond Model of Intrusion Analysis. Technical re-

port, Center of Cyber Intelligence Analysis and Threat

Research.

Dhillon, D. (2011). Developer-Driven Threat Modeling.

IEEE Security & Privacy, 9(4):41–47.

Google (2020). HTTPS encryption on the web. Technical

report, Google.

Hussain, S., Kamal, A., Ahmad, S., Rasool, G., and Iqbal,

S. (2014). Threat Modelling Methodologies: A Sur-

vey. Science International, 26(4):1607–1609.

IDG (2020). 2020 IDG Cloud Computing Survey. Techni-

cal report, idg.

jadefeather (2020). Unit42 solarstorm iocs. Technical re-

port, Palo Alto Networks Unit 42.

Jarke, M., Gallersd

orfer, R., Jeusfeld, M. A., Staudt, M.,

and Eherer, S. (1995). ConceptBase — A deductive

object base for meta data management. Journal of In-

telligent Information Systems, 4:167–192.

Supporting Cyber Threat Analysis with Service-Oriented Enterprise Modeling

393

Kazim, M. and Evans, D. (2016). Threat Modeling for Ser-

vices in Cloud. In Proceedings 2016 IEEE Symposium

on Services-Oriented System Engineering (SOSE).

IEEE.

Leune, K. (2007). Access Control and Service-Oriented Ar-

chitectures. PhD thesis, Tilburg University, CentER.

Leune, K. and Kim, S. (2020). Service-oriented model-

ing for cyber threat analysis. In Proceedings of the

Tenth ACM Conference on Data and Application Se-

curity and Privacy, CODASPY ’20, page 150–152,

New York, NY, USA. Association for Computing Ma-

chinery.

Malik, N. A., Javed, M. Y., and Mahmud, U. (2008). Threat

modeling in pervasive computing paradigm. In 2008

New Technologies, Mobility and Security, pages 1–5.

Mirembe, D. P. and Muyeba, M. (2008). Threat Modeling

Revisted: Improved Effectiveness of Attack. In Pro-

ceedings of the Second UKSIM European Symposium

on Computer Modeling and Simulation, pages 93–98.

IEEE.

Myagmar, S., Lee, A. J., and Yurcik, W. (2005). Threat

Modeling as a Basis for Security Requirements. In

Proceedings of the Symposium on Requirements En-

gineering for Information Security (SREIS 2005).

Mylopoulos, J., Borgida, A., Jarke, M., and Koubarakis, M.

(1990). Telos: Representing Knowledge About Infor-

mation Systems. ACM Transactions on Information

Systems, 8(4):325–362.

Papazoglou, M. (2003). Service-oriented computing: con-

cepts, characteristics and directions. In Proceedings of

the Fourth International Conference on Web Informa-

tion Systems Engineering, 2003. WISE 2003. IEEE.

Papazoglou, M. and Georgakopoulos, D. (2003). Service-

Oriented Computing. Communications of the ACM,

46(10):25–28.

Rouland, Q., Hamid, B., and Jaskolka, J. (2020). Reusable

Formal Models for Threat Speciﬁcation, Detection,

and Treatment. In Reuse in Emerging Software En-

gineering Practices, pages 52–68. Springer Interna-

tional Publishing.

Schneier, B. (1999). Attack Trees. Dr. Dobb’s Journal.

Shevchenko, N., Chick, T. A., O’Riordan, P., Scanlon, T. P.,

and Woody, C. (2018). Threat Modeling: A Summary

of Available Methods. Technical report, Carnegie

Mellon University Software Engineering Institute.

Shostack, A. (2007). Experiences Threat Modeling at Mi-

crosoft. Technical report, Microsoft.

Shostack, A. (2014). Threat Modeling: Designing for Se-

curity. Wiley.

Sion, L., Landuyt, D. V., Wuyts, K., and Joosen, W.

(2019). Privacy Risk Assessment for Data Subject-

Aware Threat Modeling. In IEEE Security and Pri-

vacy Workshows (SPW), pages 64–71.

Steven, J. (2010). Threat Modeling—Perhaps It’s Time.

IEEE Security & Privacy, pages 83–86.

Thomson, I. (2020). SolarWinds releases known attack

timeline, new data suggests hackers may have done

a dummy run last year. The Register.

Torr, P. (2005). Demystifying the Threat-Modeling Process.

IEEE Security & Privacy, 3(5):66–70.

UcedaVelez, T. and Morana, M. (2015). Risk Centric Threat

Modeling: Process for Attack Simulation and Threat

Analysis. Wiley.

Zetter, K. (2020). Hackers last year conducted a ’dry run’

of SolarWinds breach. yahoo!news.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

394