Evaluation of Vulnerability Reproducibility

in Container-based Cyber Range

Ryotaro Nakata

and Akira Otsuka

Institute of Information Security, Yokohama, Kanagawa, Japan

Keywords:

Information Security Education, Cyber Range, Container-based Virtualization, Docker, Vulnerability.

Abstract:

The cyber range is a practical and highly educational information security exercise system, but it has not been

widely used due to its high introduction and maintenance costs. Therefore, there is a need for a cyber range

that can be adopted and maintained at a low cost. Recently, container type virtualization is gaining attention

as it can create a high-speed and high-density exercise environment. However, existing researches have not

clearly shown the advantages of container virtualization for building exercise environments. Moreover, it is not

clear whether sufﬁcient vulnerabilities are reproducible, required to conduct incident scenarios in the cyber

range. In this paper, we compare container virtualization with existing virtualization type and conﬁrm that

the amount of memory, CPU, and storage consumption can be reduced to less than 1/10 of the conventional

virtualization methods. We also compare and verify the reproducibility of the vulnerabilities used in common

exercise scenarios and conﬁrm that 99.3% of the vulnerabilities are reproducible. The container-based cyber

range can be used as a new standard to replace existing methods.

1 INTRODUCTION

With the development of ICT technology, the scale

and impact of cyber-attacks continue to increase

worldwide.On the other hand, the shortage of human

resources for security is pointed out, and the gov-

ernment and higher education institutions are making

various efforts for human resource development. Still,

the quantitative and qualitative shortage has not been

solved (Maki et al., 2020).

Information security skills can be effectively

learned through education using cyber ranges. The

cyber range is a large scale exercise system for learn-

ing by experiencing real security incidents in an or-

ganization in a virtual environment that simulates a

real-world system. Although the educational effect is

high, the cyber range’s introduction and maintenance

are millions of dollars (Razvan et al., 2017).

Although the effectiveness and necessity of cyber

ranges are recognized, it is difﬁcult for educational

institutions to implement and maintain them indepen-

dently. Therefore, a low-cost training environment is

needed, and the use of container type virtualization is

attracting attention (Irvine et al., 2017).

https://orcid.org/0000-0001-8885-848X

https://orcid.org/0000-0001-6862-2576

However, previous research does not show the ad-

vantages of container type virtualization in concrete

terms. Containers are not suitable for recreating real-

istic environments and are generally considered to be

limited to speciﬁc applications. As a result, most ex-

isting cyber range products and educational research

use other virtualization types (Razvan et al., 2017).

This paper uses a container-based cyber range en-

vironment to examine the differences between virtu-

alization types and conﬁrm the performance beneﬁts

of container type virtualization in cyber range. We

also describe the results of our comparison with other

virtualization types by applying vulnerability check-

ing tools and attack programs to see how well the vul-

nerabilities and incidents in commonly used exercise

scenarios can be reproduced in cyber range exercises.

2 THE CYBER RANGE

2.1 Deﬁnition of Cyber Range

The cyber range is a system to build and provide an

environment for information security exercises. For

smooth implementation of the exercises, with the fol-

lowing functions.

Nakata, R. and Otsuka, A.

Evaluation of Vulnerability Reproducibility in Container-based Cyber Range.

DOI: 10.5220/0010324606350642

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

ISBN: 978-989-758-491-6

635

• Creating a realistic system environment

The system environment can be faithfully repro-

duced as it is used in the real world.

• Duplicate or replace the environment

Exercise environments can be reset, replicated, or

replaced ﬂexibly and quickly.

• Reproduction of vulnerabilities and incidents

Vulnerable environments and actual malware can

be used to recreate security incidents and execute

attack and defense scenarios.

These functions are made possible by virtualiza-

tion technology (Costa et al., 2020).

2.2 Typical Cyber Range Scenarios

In the cyber range exercise, various scenarios will be

developed depending on the learning objectives and

the student’s level. Figure 1 shows a network envi-

ronment that reproduces a typical attack scenario.

Figure 1: Example of a virtual network for cyber range.

In the cyber range, reproduce vulnerabilities in

web servers, DB servers, client devices, etc., to carry

out the scenario. Also, security devices such as ﬁre-

walls, IDS/IPS, etc. will be installed, depending on

the exercise’s nature. To execute scenarios in the cy-

ber range that replicate real security incidents and re-

sponses, prepare a virtual environment equivalent to

the real system environment (Stout et al., 2018).

3 VIRTUALIZATION

TECHNOLOGY

3.1 Types of Virtualization Technologies

Virtualization technology efﬁciently utilizes hardware

by sharing and dividing the resources required for

operating systems and applications among multiple

environments (VM: Virtual Machine) (Ameen and

Hamo, 2013). Figure 2 shows an overview of each

virtualization technology type.

Figure 2: Overview of each virtualization types.

In the hypervisor type, a program called hypervi-

sor builds a VM on specially prepared hardware, and

it operates by occupying resources such as memory

and CPU. In the host type, a VM is built by running

dedicated software that plays a hypervisor role on an

operating system (host OS) running on the actual ma-

chine. A portion of the resources recognized by the

host OS is allocated and operated.

Unlike other virtualization types, the container

type operates like a VM by creating a separate names-

pace, called a container, on a running host OS that op-

erates only the processes required for the functions to

be used. Containers do not occupy physical resources

and run as a single process on the host OS. Table 1

shows the characteristics of each virtualization types.

Table 1: Characteristics of each virtualization types.

Virtualization isolation over guest

type level head OS

Hypervisor max high require

Host high max require

Container low low unrequire

The isolation level indicates independence from

the host OS and other VMs running on the same hard-

ware. If the isolation level is low, there is a high prob-

ability that the host OS and other VMs will be affected

if processing on the VM is slow or troubles occur.

Overhead refers to the decrease in processing perfor-

mance that occurs in a virtual environment. Since the

hardware is accessed through the mechanism used to

run the VM, there is a high probability that process-

ing performance will decrease compared to the actual

environment.

Figure 3 shows the operating architecture of each

virtualization types In the hypervisor and host type,

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

636

Figure 3: Operating architecture of each virtualization type.

Figure 4: Comparison of resource consumption as the number of virtual instances increases.

the VMs run independently and replicate the real ma-

chine’s equivalent environment. Still, they require in-

stalling a guest OS, which consumes a large number

of physical resources (Li et al., 2017). The guest OS

does not need to be started or stopped in the container

type, and only the necessary functions can be run with

minimal conﬁguration. Containerized systems share

kernels and resources. They can be fast and efﬁcient.

Still, they are affected by interactions with the host

OS and other containers and may behave differently

from the real machine (Preeth E N et al., 2015).

3.2 Virtualization Type Used in the

Cyber Range

Existing cyber ranges use HV and hosted virtualiza-

tion types. In particular, virtualization solutions such

as VMWare and Citrix are being used in the com-

mercial cyber range for their stability and VM man-

agement capabilities (VMWare, 2019). However, de-

pending on the number of participants and the num-

ber of exercise groups, there are more than 100 vir-

tual instances running at the same time, requiring

high load operations such as environment replica-

tion and rapid startup/termination. Therefore, high-

performance hardware is required, causing increased

costs (Maki et al., 2020).

3.3 Advantages of Container-based

Cyber Range

Cyber range environments using containerized virtu-

alization are faster and less resource-intensive than

other virtualization types. Figure 4 shows a compari-

son of the resources consumed by VMs and contain-

ers as the number of virtual instances increases.

In the example of the ﬁgure 4, the OS was installed

on a VM with 1GB memory allocated and prepared as

a device intended to be a client for the cyber range en-

vironment. We also installed the same OS and desk-

top package as the VM in a container running on the

same host. The resource consumption was compared

by preparing the container as a container that allowed

the same operations as the VM.

VMs always consume host resources without any

particular actions, such as running a guest OS and var-

ious services. Many processes that are not necessary

to execute cyber range scenarios are also running, and

even virtual machines that are not explicitly running

consume a certain amount of resources, which is in-

efﬁcient.

Containers, on the other hand, consume very few

resources per instance because they run on a mini-

mal number of processes. Therefore, even if the cyber

range environment is built and the number of virtual

Evaluation of Vulnerability Reproducibility in Container-based Cyber Range

637

instances increases, the physical resource consump-

tion can be signiﬁcantly reduced compared to a VM

environment. By using containers to build a cyber

range environment, the required speciﬁcations of the

host machine can be signiﬁcantly reduced.

3.4 Concerns of Container

Using container type virtualization can build a cyber

range environment at a lower cost. However, con-

tainer type virtualization has different characteristics

than VMs used in the existing cyber range and may

have different states and behaviors in executing sce-

narios. As a result, individual vulnerabilities and in-

cidents cannot be reproduced correctly and may not

work as envisioned. The biggest concern with the

container-based cyber range is whether the vulnera-

bilities required to execute a scenario can be repro-

duced on a container similar to on a VM.

4 EXPERIMENTS ON

VULNERABILITY

REPRODUCIBILITY

4.1 Reproducibilty Metrics

To assess the reproducibility of vulnerabilities on a

container-based cyber range, we model the OS/HW

environment in which the programs as an oracle O

and every system calls invoked by a program A is sent

to the oracle O. If a program is run in the environment

over Real, VM, container, we write the output of the

programs as A

Real

, A

and A

Container

respectively.

Where “Real” means the physical environment where

no virtualization technology is used.

If all programs’ execution results are the same,

there is no problem executing any exercise scenario,

and it eliminates concerns of container-based cyber

range. Theoretically, the identiﬁcation algorithm φ

can be deﬁned as the inability to identify which en-

vironment the program A was executed.

We write the set of results of running the program

in each environment as A

Real

, A

V M

, and A

Container

, re-

spectively, as shown in the following equation.

Real

A | φ



Real



= 1

V M

A | φ





= 1

Container

A | φ



Container



= 1

By measuring these sets’ similarity, we conﬁrm

the reproducibility of vulnerabilities in the container-

based cyber range. The relationship between each set

is shown in Figure 5.

Figure 5: Reproducibility Comparison Model.

Considering the current use of VMs in the cyber

range, we will consider Real and VM’s nearly identi-

cal. Thus, J, which represents the similarity between

VMs and containers, be the metric for using container

type virtualization in the cyber range.



V M

, A

container





V M

∩ A

Container



V M

∪ A

Container

The higher the value of J, the less concern there

is about the container-based cyber range. In reality,

some programs that are difﬁcult to reproduce by con-

tainers, such as those related to physical vulnerabil-

ities. These should be excluded from the container-

based cyber range and will be discussed in Chapter

4.2 Experimental Method

We compared the container and VM environment

through an exhaustive experiment with programs used

in cyber range exercise scenarios. We built an equiv-

alent environment with VMs and containers to con-

ﬁrm a difference between the vulnerability assess-

ment tool’s scan results and the results of attacks

against the detected vulnerabilities. Table 2 shows the

vulnerability assessment tools used in the experiment.

Table 2: Vulnerability inspection tool used for veriﬁcation.

Name

Target

Web

App

Middle

ware

Net

work

OpenVAS ◦ ◦

Nmap ◦

Owasp ZAP ◦

We have selected tools that can be used in cyber

range exercises and divided the target areas into four

areas: web applications, middleware, OS, and net-

works. Using tools capable of scanning for each area,

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

638

we thought we could perform a comprehensive exper-

iment for various vulnerabilities.

4.3 Experimental Settings

We experimented with a Docker container and a Vir-

tualBox VM. Docker is a platform for container type

virtualization, becoming more popular for various ap-

plications such as cloud services. VirtualBox is a free

hosted virtualization software widely used in veriﬁca-

tion environments, education, and research because of

its ease of installation and many supported operating

systems. The environments used for veriﬁcation are

shown in Table 3.

Table 3: Experimental Settings detail.

env

Hardware

VM software and Image

Spec

Host

MacBookPro-13inch

Ubuntu 18.04 LTS

2.3GHz Corei5

16GB RAM

VirtualBox6.0

Metasploitable2/3

Kalilinux2019.1

1CPU

2GB RAM

cont-

ainer

DockerCE18.09

Metasploitable2/3(created from VM)

kalilinux/kali-linux-docker(ofﬁcial)

We used Kali-linux, a Linux distribution for pene-

tration testing, and Metasploitable2/3, which are used

as a veriﬁcation environment for deliberately adding

vulnerabilities to containers and VMs, and compared

the vulnerability assessment results and exploit tests

(Kali.org, 2020; Rapid7, 2020).

Since ofﬁcial container images of Metasploitable

2 and 3 are not available to the public, we created

container images from each VM machine. The origi-

nal container image was created using the docker im-

port command, which collects ﬁles other than /boot,

/dev, /mnt, /proc, /sys, /tmp that are unnecessary for

container operation using the tar command creates the

base container image from the archive ﬁle. We have

created an environment that works with the same con-

ﬁguration, although the startup process is different.

5 EXPERIMENTAL RESULTS

5.1 Measuring Reproducibility with

Vulnerability Assesment Tools

5.1.1 OpenVAS

OpenVAS is an open-source vulnerability testing tool

with rich testing capabilities. It can detect a wide

Table 4: Comparison of the number of vulnerabilities de-

tected by OpenVAS.

CWE

vulnerability classiﬁcation

cont-

ainer

16 Conﬁguration 2 2

17 Code 2 2

18 Source Code 1 1

20 Improper Input Validation 82 82

22 Pass Traversal 7 7

59 Link Following 6 6

74 Injection 1 1

79 Cross Site Scripting 33 33

89 SQL Injection 7 7

93 CRLF Injection 4 4

94 Code Injection 13 13

113 HTTP Response Splitting 1 1

119 Buffer Error 66 66

125 Out-of-bounds Read 2 2

134

Use of Externally-Controlled

Format String

5 5

189 Numeric Errors 31 31

190 Integer Overﬂow or Wraparound 3 3

200

Exposure of Sensitive Information

to an Unauthorized Actor

42 42

254 7PK - Security Features 2 2

255 Credentials Management Errors 2 2

264

Permissions, Privileges,

and Access Controls

54 54

275 Permission Issues 1 1

284 Improper Access Control 5 5

287 Improper Authentication 8 8

295 Improper Certiﬁcate Validation 2 2

310 Cryptographic Issues 22 22

311

Missing Encryption

of Sensitive Data

22 22

320 Key Management Errors 2 2

327

Use of a Broken or Risky

Crypto-graphic Algorithm

1 1

345

Insufﬁcient Veriﬁcation

of Data Authenticity

1 1

352 Cross Site Request Forgery 5 5

362 Race Condition’ 9 9

384 Session Fixation 1 1

399 Resource Management Errors 51 51

400

Uncontrolled Resource

Consumption

2 2

415 Double Free 1 1

416 Use After Free 2 2

476 NULL Pointer Dereference 8 8

502

Deserialization of Untrusted

Data

2 2

552

Files or Directories Accessible

to External Parties

1 1

601 Open Redirect 5 5

732

Incorrect Permission Assignment

for Critical Resource

1 1

772

Missing Release of Resource

after Effective Lifetime

1 1

787 Out-of-bounds Write 1 1

835 Inﬁnite Loop 8 8

Design Design errors 4 4

Other Other errors 50 50

noinfo Lack of information 123 123

Evaluation of Vulnerability Reproducibility in Container-based Cyber Range

639

range of vulnerabilities such as software bugs, usage

ﬂaws, and conﬁgurations and check for correspond-

ing CVEs (Common Vulnerabilities and Exposures)

(MITRE, 2020a) using the latest database (Green-

boneNetworks, 2020). Table 4 shows the results of

an experiment by OpenVAS. Since the number of

CVE detections is very high, it is aggregated by CWE

(Common Weakness Enumeration) (MITRE, 2020b).

For the items conﬁrmed in vulnerability scans for

Metasplotable 2 and 3 by OpenVAS, we could con-

ﬁrm the same results for the VM and container. There

was no difference in the functions and services run-

ning in both environments, and the vulnerabilities de-

tected were consistent.

5.1.2 Nmap

Nmap is an open source port scanner with exten-

sive OS and service version detection capabilities

(Nmap.org, 2020). In cyber-range exercises, they are

often used in the early stages of exercise scenarios, for

example, to respond to incidents after port scan detec-

tion. Therefore, experimental results from Nmap are

also important in a container-based Cyber-range en-

vironment. Table 5 shows the results of detection by

NMAP.

Table 5: Detection results by Nmap, and CWE classiﬁca-

tion.

CWE Port Service Version

189,339 21 ftp

vsftpd 2.3.4

ProFTPD 1.3.5

119,200 22 ssh

OpenSSH 4.7p1

OpenSSH 6.6 1p1

254,416 53 dns ISC BIND 9.4.2

79,287 80 http

Apache 2.2.8

Apache 2.4.7

399 111 rpcbind 2 (RPC #100000)

22,275 139 samba Samba smbd 3.X-4.X

264,290 631 ipp CUPS 1.7

94,119 1099 java-rmi Java Rmi Registry

264 2049 nfs 2-4(RPC #100003)

22,399 2121 ftp ProFTPD 1.3.1

134,189 3306 MySQL

MySQL 5.0.51a

MySQL 5.5.62

20 8181 http Webrick httpd 1.3.1

other 3632 distccd distccd v1

264,284 5432 postgresql

PostgreSQL

DB8.3.0-8.3.7

other 5900 vnc VNC protocol 3.3

20,189 6667 irc UnrealIRCd

16 8009 ajp13

Apache Jserv

(Protocol v1.3)

20,119 8180 http

Tomcat/Coyte

JSP engine 1.1

189,399 8787 drb Ruby DRb RMI

Table 6: Comparison of the number of detected vulnerabil-

ities by ZAP.

CWE Vulnerability

Metasploi-

table2

Metasploi-

table3

cont-

ainer

cont-

ainer

89 SQL Injection 358 422 2 2

97 Server Side Include 1 1 0 0

79 XSS(refrected) 1075 1000 1 1

79 XSS(stored) 5 5 0 0

22 Pass Traversal 21 21 0 0

78 Command Injection 361 342 0 0

98 File Inclusion 209 206 0 0

200

Application error

disclosure

242 246 1 1

548 Directory Browsing 14 15 21 21

472

Parameter

tampering

13 14 1 0

200

Buffer Error

disclosure

291 287 1 1

200 Private IP disclosure 136 139 1 1

Experiments of port scanning by Nmap gave the

same detection results in VM and container. As

shown in Table 5, we checked the vulnerabilities in

the detected contents and conﬁrmed the correspond-

ing CWE.

5.1.3 OWASP ZAP

ZAP is an open-source web application vulnerabil-

ity assessment tool that can detect many vulnerabil-

ities and check how to deal with them (Makino and

Klyuev, 2015). Metasploitable 2 and 3, prepared as

vulnerable environments, have several web applica-

tion environments, and web pages with various vul-

nerabilities, can be checked. Table 6 shows a compar-

ison of the results of the ZAP vulnerability check.

In some cases, more vulnerabilities were detected

by containers. This result was unexpected. It could

not be determined whether this was due to the char-

acteristics of the container or the ZAP characteristics.

Since many vulnerabilities have been detected, it is

possible to utilize them in a cyber range environment

fully, but we think that clarifying the causes of the

lack of matches will help to deﬁne the possible use of

containers better.

5.2 Measuring Reproducibility with

Exploit Modules

The Metasploit framework included in Kali-linux can

use a variety of exploit modules. We compared the re-

sults of the attack experiments against Metasploitable

2 and 3 in the VM and container environments to see

if the attacks were successful and if the display and

behavior were identical. The exploit modules were

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

640

Figure 6: Match rate of vulnerability reproducibility about VM and container.

Table 7: Modules used for attack testing and CWE classiﬁ-

cation.

CWE Metasploit Module

119 auxiliary/scanner/ssl/openssl heartbleed

200

auxiliary/scanner/ssh/ssh enumusers

auxiliary/scanner/http/options

auxiliary/scanner/http/trace

auxiliary/scanner/http/tomcat enum

310

auxiliary/scanner/http/ssl version

auxiliary/scanner/ssl/openssl ccs

416 auxiliary/scanner/http/apache optionsbleed

other

auxiliary/scanner/rservices/rexec login

auxiliary/scanner/rservices/rlogin login

auxiliary/scanner/rservices/rsh login

119 auxiliary/server/openssl heartbeat client memory

94 exploit/linux/samba/is known pipename

189 exploit/linux/samba/setinfopolicy heap

16 exploit/unix/misc/distcc exec

20 exploit/unix/irc/unreal ircd 3281 backdoor

284 exploit/unix/ftp/proftpd modcopy exec

other exploit/unix/webapp/twiki history

20 exploit/multi/browser/java storeimagearray

other exploit/multi/http/php cgi arg injection

noinfo exploit/multi/samba/usermap script

selected from those capable of attacking vulnerabili-

ties detected by the vulnerability assessment tool used

in the 5.1 experiment.

Table 7 shows the modules used in the attack ex-

periments. All the exploit modules used worked as

expected. We conﬁrmed the reproducibility of the at-

tacks when used in the cyber range exercise, including

the detection of account information using vulnera-

bilities, unauthorized login, and successful privilege

escalation.

5.3 Overall Results

We checked the percentage of coincidence between

VMs and containers for all experiments performed.

Figure 6 shows the total number of detections for

each CWE and the percentage of identical results be-

tween VMs and containers for the vulnerabilities and

detection items identiﬁed in each experiment. Be-

cause the items are displayed in order of number,

there are many CWE items that were detected but are

not shown or that do not correspond to CWEs.

The similarity J calculated from the results of the

experiment was 0.993. This value is higher than ex-

pected, and we believe it is an acceptable value for

the construction of a suitable cyber range environ-

ment and the use of exercise scenarios. This exper-

iment largely eliminates the cyber range concerns of

container-based cyber range.

6 LIMITATIONS OF

REPRODUCIBILITY

Vulnerabilities related to physical resources are dif-

ﬁcult to reproduce due to the characteristics of con-

tainerized virtualization. These are not suitable for

cyber range environments and should be excluded. In

reality, we checked what differences occur between

containers and VMs. Table 8 shows the results of an

attack on a VM and a container.

Table 8: Physical resource consumption and behavior of vir-

tual environment.

resource type results

memory

Program is delayed at VM

memory allocation limit, but other

VMs are not affected.

cont-

ainer

When physical memory usage

reaches a limit, the entire operation,

including the host OS, is delayed.

strage

Machine stops at VM storage

allocation limit, but other VMs are

not affected.

cont-

ainer

When physical storage usage

reaches a limit, the entire operation,

including the host OS, is stopped.

A VM occupies a portion of the resources on the

host OS and operates as an independent machine.

Therefore, even if an attack slows down or stops the

VM, it does not interfere with the host OS’s operation.

However, the standard conﬁguration of the container

shares resources with the host OS and other contain-

Evaluation of Vulnerability Reproducibility in Container-based Cyber Range

641

ers. An attack on the container can affect the entire

system, including the host OS, which is a clear differ-

ence from the VM. Against such attacks, it was con-

ﬁrmed that container type virtualized environments

are unsuitable for cyber range exercises. Similarly,

vulnerabilities such as kernel vulnerabilities, host OS

conﬁguration, and ﬁles required for container execu-

tion, and attacks against them, should be excluded

from container-based cyber range exercises.

7 CONCLUSIONS

With the shortage of information security personnel,

the cyber range is expected to be highly effective in

education. However, the cost of cyber range is high,

making it difﬁcult for educational institutions to im-

plement them independently.

Therefore, to disseminate an inexpensive and de-

ployable cyber range using container-based virtu-

alization, we conﬁrmed the superiority of contain-

ers and the performance of reproducing vulnerabili-

ties through comprehensive experiments. Comparing

the performance of containers and VMs in a typical

cyber-range environment, the containers consumed

less than 1/10th of the resources of the VMs. Con-

tainers can run more virtual instances than VMs on

the same host, building a lower cost cyber range.

We also compared the reproducibility of vulnera-

bilities between containers and VMs in an exhaustive

experiment using the vulnerability assessment tool

and the exploit module. We can conﬁrmed a very high

similarity J of 0.993. Although content derived from

container characteristics must be excluded, contain-

ers have a very high vulnerability reproduction perfor-

mance, conﬁrming that container-based virtualization

can be fully used in the cyber range.

These contents can be used as a benchmark for

developing scenarios and conducting exercises for

container-based cyber ranges. In the future, we will

experiment with more situations and conduct more

detailed research, including the ability to carry out

attack and defense scenarios. We will also promote

research and studies to increase the container-based

cyber range’s effectiveness, such as examining the ef-

fectiveness of education and reﬁning exercise scenar-

ios based on behavioral analysis, to broaden the base

of security personnel training.

ACKNOWLEDGEMENTS

This work is supported in part by the Telecommuni-

cation Advancement Foundation.

REFERENCES

Ameen, R. Y. and Hamo, A. Y. (2013). Survey of server

virtualization.

Costa, G., Russo, E., and Armando, A. (2020). Automating

the generation of cyber range virtual scenarios with

vsdl.

GreenboneNetworks (2020). Openvas - open vulnerability

assessment scanner. https://www.openvas.org.

Irvine, Cynthia, E., Thompson, Michael, F., and Khosalim,

J. (2017). Labtainers: a framework for parameterized

cybersecurity labs using containers.

Kali.org (2020). Ofﬁcial kali linux docker im-

ages. https://www.kali.org/docs/containers/ofﬁcial-

kalilinux-docker-images/.

Li, Z., Kihl, M., Lu, Q., and Andersson, J. A. (2017).

Performance overhead comparison between hypervi-

sor and container based virtualization. In 2017 IEEE

31st International Conference on Advanced Informa-

tion Networking and Applications (AINA), pages 955–

962.

Maki, N., Nakata, R., Toyoda, S., Kasai, Y., Shin, S., and

Seto, Y. (2020). An effective cybersecurity exercises

platform cyexec and its training contents. In 2020 In-

ternational Conference on Advances in Education and

Information Technology(AEIT’20).

Makino, Y. and Klyuev, V. (2015). Evaluation of web vul-

nerability scanners. In 2015 IEEE 8th International

Conference on Intelligent Data Acquisition and Ad-

vanced Computing Systems: Technology and Applica-

tions (IDAACS), volume 1, pages 399–402.

MITRE (2020a). Common vulnerabilities and exposures.

https://cve.mitre.org/.

MITRE (2020b). Common weakness enumeration.

https://cwe.mitre.org/index.html.

Nmap.org (2020). Port scanning techniques.

https://nmap.org/book/man-port-scanning-

techniques.html.

Preeth E N, Mulerickal, F. J. P., Paul, B., and Sastri,

Y. (2015). Evaluation of docker containers based

on hardware utilization. In 2015 International Con-

ference on Control Communication Computing India

(ICCC), pages 697–700.

Rapid7 (2020). Metasploitable2.

https://docs.rapid7.com/metasploit/metasploitable-2/.

Razvan, B., Cuong, P., Dat, T., Ken-ichi, C., Yasuo, T., and

Yoichi, S. (2017). Cytrone: An integrated cyberse-

curity training framework. In Proceedings of the 3rd

International Conference on Information Systems Se-

curity and Privacy (ICISSP 2017): 157-166.

Stout, W. M., Urias, V., Van Leeuwen, B. P., and Lin, H. W.

(2018). An effective cybersecurity exercises platform

cyexec and its training contents. In Proposed for pre-

sentation at the IEEE International Carnahan Confer-

ence on Security Technology (ICCST).

VMWare, I. (2019). Vmware digital learn-

ing platform - cyber range solution.

https://www.vmware.com/content/dam/digitalmarket

ing/vmware/en/pdf/solutions/industry/vmware-cyber

range-datasheet.pdf.

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

642