A Domain-speciﬁc Modeling Framework for Attack Surface Modeling

Tithnara Nicolas Sun

, Bastien Drouot

, Fahad R. Golra

, Jo

el Champeau

, Sylvain Guerin

Luka Le Roux

, Ra

ul Mazo

1,2

, Ciprian Teodorov

, Lionel Van Aertryck

and Bernard L’Hostis

Lab STICC UMR6285, ENSTA Bretagne, Brest, France

GIDITIC, Universidad EAFIT, Medellin, Colombia

DGA-MI, Bruz, France

Keywords:

Attack Surface Modeling, Model Federation, DSL, Modeling, Cyber Security.

Abstract:

Cybersecurity is becoming vital as industries are gradually moving from automating physical processes to

a higher level automation using cyber physical systems (CPS) and internet of things (IoT). In this context,

security is becoming a continuous process that runs in parallel to other processes during the complete life

cycle of a system. Traditional threat analysis methods use design models alongside threat models as an input

for security analysis, hence missing the life-cycle-based dynamicity required by the security concern. In this

paper, we argue for an attacker-aware systems modeling language that exposes the systems attack surfaces.

For this purpose, we have designed Pimca, a domain speciﬁc modeling language geared towards capturing the

attacker point of view of the system. This study introduces the formalism along with the Pimca workbench, a

framework designed to ease the development and manipulation of the Pimca models. Finally, we present two

relevant use cases, serving as a preliminary validation of our approach.

1 INTRODUCTION

As industry is moving towards automation through

software and communication technologies, cyber se-

curity is coming into focus, more than ever before.

The systems modeling industry addresses this need

through initiatives like threat modeling (Farrell et al.,

2019). Threat modeling techniques, like attack trees,

are used alongside system models to perform security

analysis. The outcomes of such analysis are then se-

rialized as different artifacts. Despite the advances in

the domain of cyber security, not all security analy-

sis techniques are fully automated and a consider-

able amount of human involvement is required in an-

alyzing the security status of an architecture (Siponen

and Willison, 2009). For example, in security audits

like Systems Security Engineering Capability Matu-

rity Model (SSE-CMM), the security guidelines are

manually validated by reviewers. In such situations,

a domain speciﬁc language (DSL) that highlights the

attack surface, i.e. the sum of different points where

an attacker can interact on the system (Manadhata and

Wing, 2011), improves the communication between

stakeholders, the comprehension, and the rationaliza-

tion of the system architecture.

In this article, we present Pimca framework along-

side its DSL for highlighting the security concerns

of a system. Pimca can be seen as a security-

focused systems modeling language, which captures

the coarse-grain architecture of large-scale systems

(like CPS, enterprise systems and system of systems)

to exhibit the security concerns (e.g. attack surfaces,

attack scenarios, etc.) while abstracting away the in-

ternal architectural details. The Pimca DSL was orig-

inally developed by the Directorate General of Arma-

ments (DGA), French ministry armed forces. In this

context, it was used to facilitate preemptive attack sur-

face analysis, attack impact analysis, attack routing

analysis. Apart from the DSL, this study introduces

an open-source security modeling framework

, based

on Pimca, that offers (i) A graphical modeling lan-

guage (ii) A methodology, and (iii) The associated

tools focused on the following objectives:

1. System Modeling with the Intent of Highlighting

the Attack Surface. A language that incorporates

the basic system analysis and the understanding

of system functions to model the system from the

perspective of cyber threat analysis (CTA).

2. Security Concerns Modeling using a Graphical

Language, Geared towards Automation. This

http://downloads.openﬂexo.org/CTA

Sun, T., Drouot, B., Golra, F., Champeau, J., Guerin, S., Le Roux, L., Mazo, R., Teodorov, C., Van Aertryck, L. and L’Hostis, B.

A Domain-speciﬁc Modeling Framework for Attack Surface Modeling.

DOI: 10.5220/0008916203410348

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 341-348

ISBN: 978-989-758-399-5; ISSN: 2184-4356

341

operates

connec ts

prints

Figure 1: Running example.

helps support both manual and automated analy-

sis. Furthermore, a human-readable model facili-

tates communication between multiple stakehold-

ers.

3. Analysis Independent Modeling. Analysis tech-

niques are often tightly coupled with certain

DSLs, resulting in a plethora of languages. With

the separation of concerns, we look forward to

enabling different security analysis based on the

same modeling language.

Section 2 details the Pimca modeling language.

Section 3 introduces the tooling and implementation

of the proposed framework. Section 4 illustrates the

capabilities of the framework on two use-cases from

the CPS and enterprise network domains. The related

works are over-viewed in Section 5 before concluding

the paper in Section 6.

2 PIMCA DSL

This section introduces Pimca, a systems DSL con-

ceived for highlighting the attack surface during CTA.

To facilitate the comprehension, let us consider a sim-

ple use-case of a technician who wants to print a doc-

ument on a printer. The topology of the system com-

prises of a workstation and a printer, both connected

to a local area network (LAN), as shown in Fig. 1. To

print the document, the technician operates his work-

station and sends data through the LAN. Data is then

transmitted to the printer, which performs the print-

ing task. This example highlights several aspects of

systems architecture. For example, the interaction

of the cyber component (”network”) with a physical

agent (”technician”) and the use concrete relations

(”operates” and ”connects”) and conceptual relations

(”prints”).

The Pimca model captures the structure of the

system-under-study. An excerpt

of the metamodel is

presented in Fig. 2. A system is viewed as a composi-

The complete metamodel is now open-source and ac-

cessible online at https://github.com/fgolra/Pimca

tion of macro structures in the context of cyber phys-

ical systems, industrial control systems or systems of

systems. These systems are composed of interacting

and interdependent elements (Lee et al., 2015), ab-

stracted as a knowledgeComponent. A knowledge-

Component is uniquely identiﬁable and has a de-

ﬁned address which can be either physical, virtual or

generic. A knowledgeComponent is an abstract meta-

class with three concrete subclasses: machinery, re-

source and relation.

A Machinery deﬁnes the active elements of the sys-

tem. Instances of machinery have the ability to in-

teract with other elements of the system via relations;

i.e., they can trigger actions and react to them. This

concept is used to capture the active elements dur-

ing CTA. When considering attack possibilities, one

should consider actions and effects triggered by the

active elements as potential attack steps.

A machinery has a dimensionType i.e., physical,

virtual or compound. A dimension deﬁnes the space

in which the machineries interact i.e., a machinery

with physical dimension has a tangible reality and can

only interact directly with other ”physical machiner-

ies”. Similarly, a machinery with virtual dimension

has an intangible reality and can only interact directly

with other ”virtual machineries”. A machinery with

compound dimension bridges the gap between the

physical and virtual dimensions. This distinction is

useful for CTA because an adversary starts an interac-

tion with the system either from a virtual or a physical

node. To progress further in a different dimension, an

adversary is compelled to pass through a ”compound

machinery”.

The machinery is further specialized to represent

performers, interfaces, checkpoints and networks.

• Performer represents a human element. This con-

cept is mandatory for CTA because the human el-

ements have a unique behavior compared to auto-

mated elements. They expose a particular weak-

ness of the system e.g. social engineering. In-

herently, the performers have physical existence,

so they are modeled as physical machineries. In

our running example, the operator working in the

system is a performer. The performer is further

specialized to attacker. An attacker represents a

human adversary or a group of human adversaries.

• Interface represents a concept bridge between two

dimensions, physical and virtual. This concept is

vital in CTA because it characterizes the attack

surface as highlighted by (Theisen et al., 2018)

and (Manadhata and Wing, 2011). Interfaces are

the only concepts in the Pimca language that can

be of compound dimension i.e., they can access

both physical and virtual spaces simultaneously.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

342

KnowledgeComponent

Resource

Machinery

kind : DimensionType

Relation

PimcaModel

Check

Control

Use

Produce

Exchange

Maintain

Instruction

Passport

Performer

Checkpoint

Network

sort : NetworkType

Attacker

Interface

NetworkType

Energy

Matter

Data

EntryPoint

ExitPoint

Match

DimensionType

physical

virtual

compound

[0..*] /employing

[0..*] /conveying

[0..*] passingThrough

[1..1] source

[0..*] outgoings

[1..1] target

[0..*] incomings

[0..1] refines

[0..*] refinements

[0..*] knowledge

Figure 2: Pimca metamodel.

However Pimca model also allows for interfaces

to be deﬁned between two dimensions of the same

type. To show directionality, the interfaces are

specialized into entryPoint and exitPoint. From a

virtual system perspective, a keyboard is an entry-

Point (a physical to virtual bridge) while a screen

is an exitPoint (a virtual to physical bridge). The

workstation can be modeled as an interface be-

tween the physical space of the technician and the

virtual space of the LAN network.

• Checkpoint represents an element checking for

a speciﬁc resource before granting passage. In

CTA, this concept highlights machineries that will

hinder the attacker’s progression. Checkpoints are

either physical or virtual machineries. For exam-

ple, an ID checkpoint at the entrance of an indus-

trial site is a physical checkpoint. A network ﬁre-

wall is a virtual checkpoint.

• Network represents exchange channels. In CTA,

this concept highlights machineries that allow

reaching linked knowledgeComponents. Access-

ing a particular network is a pivotal step for at-

tackers, because it offers access to other ma-

chineries by nature. In a physical network, the en-

tities interact at the physical level and may only be

reached by physical means. In a virtual network,

the entities interact at the virtual level and may

only be reached by virtual means. The nature of

the exchange is deﬁned by the networkType which

is either energy, matter or data. For example, an

electric grid is a physical energy network, while a

LAN is a virtual data network.

A Resource deﬁnes passive elements of the system.

As opposed to machineries, resources do not act on

their own. They are only recipient/targets of the ac-

tions performed by the machineries. For example, re-

sources may range from the water running in a pump-

ing system to the electricity supplied to pumps of said

system. This concept is the counterpart of machiner-

ies as it represents valuable assets in the system.

While resources can be deﬁned as is, we also de-

ﬁne two specialized resources i.e., passport and in-

struction. These resources are deﬁned as follows:

• Passport represents a resource directly linked to

a speciﬁc checkpoint. The use of a passport is

mandatory to get through the checkpoint. This

concept is required for CTA since it captures the

keys (for example IDs, SSH keys, etc.) required

to pass through checkpoints.

• Instruction represents the resources like com-

mands, inputs or orders used by a machinery to

restrict its behavior. This concept symbolizes the

fact that the behavior of a machinery may consti-

tute a target in itself for the attacker. If instruc-

tions are represented in the system, then they can

be tampered with. For example, the LAN secu-

rity policy is an instance of instructions. An au-

tomaton description that models the behavior of a

machinery is also an instance of instructions.

A Relation models the complex interactions between

the knowledgeComponents. A relation has a single

source and a single target of any type including other

relations. The relation may be employing interme-

diary machineries on which it depends. In the ex-

ample, the ”print” relation depends on the network

and the workstation. Another relation can be con-

A Domain-speciﬁc Modeling Framework for Attack Surface Modeling

343

veying a resource. In the example, the document to

be printed is linked with the ”print” relation using a

conveying attribute. Another attribute of a relation,

passingThrough links it to other relations on which

it depends. In the running example, the ”print” re-

lation is not possible without the following relations:

”operates”, ”connected to” and ”connects”. Thus, a

relation refers to any numbers of machineries via the

employing attribute, to any numbers of resources via

the conveying attribute and to any numbers of rela-

tions via the passingThrough attribute. A relation is

an abstract type and has multiple concrete types: ex-

change, control, use, produce and check, which are

deﬁned as follows:

• Exchange is a bidirectional relation between two

machineries. In the example the workstation ma-

chinery exchanges data with the LAN network.

• Control, similarly to Exchange, relates two ma-

chineries, with the source inﬂuencing (dominat-

ing) the behavior of the target. This relation em-

phasizes the criticality of the source machinery

i.e., successfully corrupting the source, results in

gaining control over the target actions. In the ex-

ample the operator (performer) controls his work-

station (machinery).

• Use relation states that the source machinery

needs a knowledgeComponent to perform its ac-

tions. This relation highlights the reliance of the

source on the target to properly function i.e., suc-

cessfully depriving the source of the target results

in disrupting behavior. For example, a computer

(machinery) needs (uses) electricity (resource).

• In Produce relation, opposed to use, the source

produces the target knowledgeComponent. This

highlights the reliance of the target on the source

to exist, successfully corrupting the source results

in corrupting or disrupting the production of the

target. For example, a power plant (machinery)

is producing the electricity (resource). Shutting

down the power plant stops the electricity.

• Check relation, deﬁned between a machinery and

a knowledgeComponent, represents a ”sensorial”

relation representing that the source machinery

has partial knowledge of the target state. Tam-

pering with the target might be detected by the

source. For example, a sensor checks the level of

water tanks. If the water level raises, the sensor

measures it. This relation is specialized as:

– Maintain is a check relation between a per-

former and a KnowledgeComponent, such that

the human source is responsible to keep the tar-

get node in proper condition. In this case, a per-

former may also perform operations on the tar-

get node. It can be seen as a conditional writing

access from the source to the target in addition

to the reading access. This relation is crucial

in CTA because it highlights the resilience of

the target node as long as the source is opera-

tional. In our example, an operator can main-

tain the printer (machinery). If the printer mal-

functions, the technician acts to repair it.

– Match is the specialization of the check rela-

tion, between a checkpoint and a passport, cap-

turing that a speciﬁc passport is required to pass

through a checkpoint. This relation is a key fea-

ture because checkpoints are the roadblocks an

adversary encounters when attacking the sys-

tem, disabled only by the right passports.

With these concepts and relations we are able to

model the macro structures of a system. Moreover,

the versatile nature of the interface (machinery) en-

ables capturing the attack surface of the cyber system,

thus satisfying our ﬁrst objective.

3 PIMCA FRAMEWORK

This section overviews the Pimca workbench design

and the proposed modeling methodology.

Workbench Overview: A Pimca model is intended for

conducting various security analysis like attack sur-

face analysis, impact analysis, attack coverage analy-

sis, etc. and also the development of threat mo-

deling views like attack modeling and vulnerabil-

ity modeling. The heterogeneity of both the tar-

geted systems and the analysis types pushes for a

model federation based approach (Golra et al., 2016).

Model federation allows binding the models of dif-

ferent paradigms through semantically rich refer-

ences. Openﬂexo

is an open-source model federa-

tion framework. To link different paradigms, Open-

Flexo proposes reusable COTS technology adapters

that bridge the paradigm gaps (EMF, JDBC, Pdf, etc.).

The Pimca workbench, illustrated in Fig. 3, uses

the diagramming adapter and the FML core language

of Openﬂexo, which provides a satisfactory solution

for our second requirement (the creation of a graphi-

cal language editor for Pimca). The graphical work-

bench is composed of multiple panels as follows:

The project structure explorer (1) contains the Pimca

XML model and the diagrams exportable in several

graphical formats. Each model can be viewed through

the modeling editor (3). The Pimca model explorer

(2) lists all the instances of machinery, resource and

https://www.openﬂexo.org/

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

344

Figure 3: Running example implementation in Openﬂexo technology.

relation used in a given model. One can edit the

properties of individual instances through this panel.

The model explorer can also be used to instantiate,

to delete, to show, and/or hide the language concepts.

The modeling editor shows the graphical representa-

tions associated to each Pimca model. We can ex-

plore the different levels of granularity of the model

for a composite node, we can zoom in to view the sub-

nodes and the relationships between them. New mod-

els are designed and edited in this panel. The concept

palette (4) exposes the available modeling concepts

and relations, enabling their instantiation via drag-

and-drop operations. The model inspector (5) allows

inspecting and editing the graphical properties of in-

dividual elements and of the model as a whole.

Modeling Methodology: A Pimca model evolves it-

eratively along with the designer comprehension of

the targeted system. If a system design document

is present (say a SysML speciﬁcation) the process is

streamlined. In this case, the initial step of the pro-

cess consists of identifying and instantiating the ac-

tive (machineries) elements and their functional con-

nections (exchanges). The following step consists of

identifying the passive objects (resources) along with

their relations to the active elements (use/produce).

Then the other relations are instantiated according to

the conceptual understanding of the systems function.

In case, the system is unknown, the system discov-

ery phase can be interleaved with the Pimca modeling

phase. As such, as the level of comprehension in-

creases the Pimca model can be iteratively reﬁned.

In this situation, the Pimca model can be seen as a

blackboard capturing the systems architecture from

a cyber-security perspective. In this situation, the

model federation environment exposed by our work-

bench could be leveraged for manipulating the hetero-

geneous information sources.

Currently, the architecture model can be a SySML

model or any other EMF model. The architecture

model, the Pimca model and the diagram are all fed-

erated in the Pimca workbench and the environment

ensures that they remain synchronized. With this mo-

deling style, on one hand, we facilitate both manual

and automated analysis (objective 2) and on the other

hand, we make the framework extensible for real-life

use. For example, if needed, one can connect a vul-

nerability database to our proposed framework, using

a database technology adapter.

4 PRELIMINARY EVALUATION

We evaluate the effectiveness of our approach on two

use cases: (i) a CPS water pumping station inspired

by (Rocchetto and Tippenhauer, 2016) and (ii) a com-

pany enterprise network.

4.1 UC1 - Water Pumping Station

System Description: The water pumping station sys-

tem features a water tank, various actuators, sensors

and a Programmable Logical Controller (PLC). Water

ﬂows in the system from the environment, through a

motorized valve controlled by PLC. The water ﬂows

out of the system from the tank through a pumping

mechanism also controlled by PLC. There is a man-

ual valve between the tank and the pump. The wa-

ter level is monitored by the PLC through a sensor.

A Domain-speciﬁc Modeling Framework for Attack Surface Modeling

345

Water

Tan k

PLC

Sensor

Manual Valve

Command

SCADA

Network

Inflow Valve

Pump

Manual operator

Water

controls

produces

uses

controls

employing

checks

uses

produces

controls

Figure 4: Use case 1: Water Pumping Station.

The PLC follows the commands entered through a

keyboard. The commands describe that (i) the mo-

torized valve must be activated and the pump must

be shut down when the water reaches a low thresh-

old, and (ii) the motorized valve must be closed and

the pump must be activated when the water reaches

a high threshold. PLC is connected to the plant net-

work which also contains a supervisory control and

data acquisition (SCADA). The Pimca model repre-

senting the model entities and their relations is shown

in Fig. 4.

Attack Surface: Suppose the attacker’s goal is to tar-

get the water running in the system. The Pimca model

shows three relations that can be used to target the

water: (i) uses relation that points to water, (ii) pro-

duces relation between inﬂow valve and water tank

that conveys water, and (iii) uses relation between the

pump and the water tank that conveys water. Further-

more, we can infer that the inﬂow valve, the tank, the

manual valve and the pump are possible intermediary

targets, because the three target relations depend on

them. Informally, tracing back the relations pointing

towards a node highlights the possibilities of reaching

the node i.e. the ”direct attack surface” of the node.

We can extend this reasoning further. The in-

ﬂow valve that produces the water is controlled by

PLC. The tank is checked by PLC employing the sen-

sor. The manual valve is controlled by the operator.

The pump is controlled by PLC. Again, the Pimca

model shows the four relations to target the high-

lighted nodes: the operator controlling the manual

valve, PLC controlling the inﬂow valve, PLC using

the sensor on the tank to check it and PLC control-

ling the pump. These relations rely on three speciﬁc

nodes: PLC, the sensor and the operator. We can re-

peat the process again. The sensor is controlled by

PLC, which we already identiﬁed as a potential attack

surface node. The operator has no relation pointing

towards it. SCADA produces a command for PLC

employing the network. Now, we can see the poten-

tial targets for the nodes we have already highlighted.

To sum up, we can deduce the attack surface of

the system depending on the capabilities of the at-

tacker. For example, if the attacker has social engi-

neering capabilities and has access to the network, the

attack surface extends to the operator node and the

control relation between the operator and the manual

valve. From their network access, the command also

becomes part of the attack surface on the system.

Discussion: In this use case, we designed the Pimca

model to represent the system architecture using the

methodology presented in Section 3 and carried out a

manual CTA on it. This reasoning exposes the differ-

ent ways to target the water in the system by deductive

reasoning and tracing back the relations pointing to-

wards the nodes. We exploit the use, produce and con-

trol relations through the physical and virtual dimen-

sions. To conclude, our systems modeling approach

allows attack surface deduction on this use case.

4.2 UC2-Corporate Network

System Description: The corporate network system

is composed of a web server and an internal network

protected by a ﬁrewall. The web server provides a ser-

vice that is directly accessible from the internet and it

has access to the company’s internal network. The

ﬁrewall prevents external connections from reaching

the internal network. In this use case, a computer and

an active directory are connected in the internal net-

work. The computer (PC1) is used by the administra-

tor of the active directory. The active directory service

handles the user accounts on a computer using Win-

dows OS. This kind of service is a critical target for

an attacker because it is vital to the system’s security.

The Pimca model showing the model entities and

their relations is shown in Fig. 5. Please note that we

chose not to represent employing & passing through

attributes because they are deductible in this particu-

lar analysis.

In our scenario, the attacker has control over the

web server and the web server uses the web server

key (WS-key). Because the attacker controls the web

server, we can infer that (s)he can also use the WS-key

employing the web server. This use relation is passing

through the control relation with the web server and

the use relation with WS-key.

Attack surface: Let us consider that the attacker’s

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

346

Firewall

Intranet

User

Internet

WebServer

PC 1

WS key

PC1 key

Attacker

Active Directory

matchs

uses

controls

uses

controls

Figure 5: Use case 2: Corporate Network.

goal is to target the active directory in the internal net-

work and that the attacker has a ﬁxed IP. We can see

that the ﬁrewall prevents access from the internet to

the company’s network without a matching key. So if

the attacker is connected to the internet, the attack sur-

face on the system is restricted to the user and the web

server. If however the attacker can use the matching

passport with the ﬁrewall, the attack surface expands.

In this case, the internal network can be reached and

consequently, PC1 and the active directory become

part of the attack surface.

To sum up, we can restrict the attack surface of the

system depending on the reach of the attacker. The

reach can be deduced with checkpoint nodes that pre-

vent the attacker from going further. For example, un-

less the attacker has the matching passport, the attack

surface remains restricted to the internet.

Discussion: This use case shows our methodology

in a context of an enterprise system. We carried out

a CTA, complementary to the previous use case, in

which we reduce the attack surface depending on the

attacker’s location and ability to get through a check-

point. To conclude, our systems modeling approach

allows attack surface reﬁnement on this use case.

5 RELATED WORKS

Security analysis approaches vary from automated

and formal approaches like Dolev-Yao (Dolev and

Yao, 1981) to manual and informal approaches like

SSE-CMM security audits. The Dolev-Yao attacker

model is a widely-used formal model for security

analysis on cryptographic protocol, and has been ex-

tended to cyber physical systems (Schaller et al.,

2009; Steinmetzer et al., 2015; Rocchetto and Tip-

penhauer, 2016). Even though such formal ap-

proaches enable automatic security analysis, it re-

quires a throughout understanding of the system be-

havior to create a realistic attacker model. An other

example is Dagger (Peterson, 2016), a mission-driven

semi-automated security modeling approach. We ar-

gue that a separation of concerns between the speci-

ﬁcation and analysis offers the ﬂexibility needed for

analysis independent CTA. Pimca is speciﬁcally de-

signed for systems modeling for security analysis.

Once the system is modeled, security analysis tech-

niques can use this model (Drouot and Champeau,

2019). This allows security analysts to tailor their

analysis to speciﬁc security needs such as attack sur-

face evaluation or attack scenarios exploration.

STRIDE is a proactive security analysis paradigm

(Kohnfelder and Garg, 1999) used in the context of

software systems. Efforts have been made to ex-

tend STRIDE to non-software systems. In particular,

Khan et al. introduce a STRIDE-based methodology

adapted to cyber physical systems (Khan et al., 2017).

However, (Farrell et al., 2019) share the limitations of

STRIDE for cyber physical systems (CPS) noting the

difﬁculties to use its concepts for non-software nodes.

In comparison to STRIDE, our framework is not re-

stricted to information systems and can be used to

model the physical systems as well, i.e., CPS and sys-

tem of systems. In addition, contrary to STRIDE, the

Pimca framework highlights the attack surface of the

modeled system.

Moving Target Defense (MTD) is a security so-

lution that exploits the inherent asymmetry between

proactive attackers and the reactive defense (Jajodia

et al., 2011) through dynamical changes of the system

conﬁguration (Zhuang et al., 2014; Xu et al., 2014).

We argue that MTD fails to capture network-unrelated

vulnerabilities of the system such as the human factor

and operational-level vulnerabilities. Furthermore,

MTD is has clear limitation for attack surface mo-

deling on complex and dynamic architectures. On

the contrary, our approach aims to capture and char-

acterize speciﬁc relations between system elements.

With the speciﬁcation of relations, resources and ma-

chineries, Pimca framework can be used to model the

system operational functions, while at the same time

highlighting the attack surface.

6 CONCLUSION

We present a systems modeling framework, Pimca,

with a domain-speciﬁc modeling language, methodol-

A Domain-speciﬁc Modeling Framework for Attack Surface Modeling

347

ogy and associated tools in the context of cyber threat

analysis. The proposed modeling language satisﬁes

the intention of highlighting the attack surfaces in a

system model. The framework includes a methodol-

ogy for the development of Pimca models. The asso-

ciated tools in the framework allow developing Pimca

models and integrating then with other security analy-

sis artifacts for the development of a security solu-

tion. The approach was evaluated using two use cases,

which emphasized the system modeling along with

the attack surface deduction and reﬁnement enabled

by the Pimca DSL and workbench. In future, we plan

to extend the Pimca DSL with behavioral primitives

which will enable dynamic attack scenario enactment

based on vulnerability databases and realistic system

conﬁgurations.

ACKNOWLEDGMENTS

We thank the French ministry of the armed forces and

the DGA for funding this research.

REFERENCES

Dolev, D. and Yao, A. C. (1981). On the security of public

key protocols. In 22nd Annual Symposium on Founda-

tions of Computer Science, SFCS ’81, pages 350–357.

IEEE Computer Society.

Drouot, B. and Champeau, J. (2019). Model federation

based on role modeling. In 7th International Con-

ference on Model-Driven Engineering and Software

Development, MODELSWARD 2019, pages 72–83.

Farrell, M., Bradbury, M., Fisher, M., Dennis, L., Dixon,

C., Yuan, H., and Maple, C. (2019). Using Threat

Analysis Techniques to Guide Formal Veriﬁcation:

A Case Study of Cooperative Awareness Messages,

pages 471–490. Springer.

Golra, F. R., Beugnard, A., Dagnat, F., Guerin, S., and

Guychard, C. (2016). Addressing modularity for het-

erogeneous multi-model systems using model feder-

ation. In Companion Proceedings of the 15th Inter-

national Conference on Modularity, MODULARITY

Companion 2016, pages 206–211. ACM.

Jajodia, S., Ghosh, A. K., Swarup, V., Wang, C., and

Wang, X. S. (2011). Moving target defense: creating

asymmetric uncertainty for cyber threats, volume 54.

Springer Science & Business Media.

Khan, R., McLaughlin, K., Laverty, D., and Sezer, S.

(2017). STRIDE-based threat modeling for cyber-

physical systems. In 2017 IEEE PES Innovative

Smart Grid Technologies Conference Europe (ISGT-

Europe), pages 1–6.

Kohnfelder, L. and Garg, P. (1999). The threats to our

products. Microsoft Interface, Microsoft Corporation,

page 33.

Lee, J., Bagheri, B., and Kao, H.-A. (2015). A cyber-

physical systems architecture for industry 4.0-based

manufacturing systems. Manufacturing letters, 3:18–

23.

Manadhata, P. K. and Wing, J. M. (2011). An attack surface

metric. IEEE Transactions on Software Engineering,

37(3):371–386.

Peterson, E. (2016). Dagger: Modeling and visualization

for mission impact situation awareness. In MILCOM

2016-2016 IEEE Military Communications Confer-

ence, pages 25–30. IEEE.

Rocchetto, M. and Tippenhauer, N. O. (2016). CPDY: Ex-

tending the Dolev-Yao attacker with physical-layer in-

teractions. Lecture Notes in Computer Science, pages

175––192.

Schaller, P., Schmidt, B., Basin, D., and Capkun, S. (2009).

Modeling and verifying physical properties of security

protocols for wireless networks. In 22nd IEEE Com-

puter Security Foundations Symposium, pages 109–

123.

Siponen, M. and Willison, R. (2009). Information security

management standards: Problems and solutions. In-

formation & Management, 46(5):267 – 270.

Steinmetzer, D., Schulz, M., and Hollick, M. (2015). Lock-

picking physical layer key exchange: Weak adversary

models invite the thief. In 8th ACM Conference on

Security & Privacy in Wireless and Mobile Networks,

WiSec ’15, pages 1:1–1:11. ACM.

Theisen, C., Munaiah, N., Al-Zyoud, M., Carver, J. C., Me-

neely, A., and Williams, L. (2018). Attack surface

deﬁnitions: A systematic literature review. Informa-

tion and Software Technology, 104:94–103.

Xu, J., Guo, P., Zhao, M., Erbacher, R. F., Zhu, M., and Liu,

P. (2014). Comparing different moving target defense

techniques. In First ACM Workshop on Moving Target

Defense, pages 97–107. ACM.

Zhuang, R., DeLoach, S. A., and Ou, X. (2014). Towards a

theory of moving target defense. In First ACM Work-

shop on Moving Target Defense, pages 31–40. ACM.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

348