Conference PaperPDF Available

About being the Tortoise or the Hare? - A Position Paper on Making Cloud Applications too Fast and Furious for Attackers

Authors:
  • Lübeck University of Applied Sciences

Abstract and Figures

Cloud applications expose - beside service endpoints - also potential or actual vulnerabilities. And attackers have several advantages on their side. They can select the weapons, the point of time and the point of attack. Very often cloud application security engineering efforts focus to harden the fortress walls but seldom assume that attacks may be successful. So, cloud applications rely on their defensive walls but seldom attack intruders actively. Biological systems are different. They accept that defensive "walls" can be breached at several layers and therefore make use of an active and adaptive defense system to attack potential intruders - an immune system. This position paper proposes such an immune system inspired approach to ensure that even undetected intruders can be purged out of cloud applications. This makes it much harder for intruders to maintain a presence on victim systems. Evaluation experiments with popular cloud service infrastructures (Amazon Web Services, Google Compute Engine, Azure and OpenStack) showed that this could minimize the undetected acting period of intruders down to minutes.
Content may be subject to copyright.
About being the Tortoise or the Hare?
A Position Paper on Making Cloud Applications too Fast and Furious for Attackers
Nane Kratzke
L¨
ubeck University of Applied Sciences, Center of Excellence for Communication, Systems, and Applications (CoSA),
M¨
onkhofer Weg 239, 23562 L¨
ubeck, Germany
nane.kratzke@fh-luebeck.de
Keywords: Immune System, Cloud-native Application, Zero-day, Exploit, Cloud, Application, Security.
Abstract: Cloud applications expose – beside service endpoints – also potential or actual vulnerabilities. And attackers
have several advantages on their side. They can select the weapons, the point of time and the point of attack.
Very often cloud application security engineering efforts focus to harden the fortress walls but seldom assume
that attacks may be successful. So, cloud applications rely on their defensive walls but seldom attack intruders
actively. Biological systems are different. They accept that defensive “walls” can be breached at several
layers and therefore make use of an active and adaptive defense system to attack potential intruders - an
immune system. This position paper proposes such an immune system inspired approach to ensure that even
undetected intruders can be purged out of cloud applications. This makes it much harder for intruders to
maintain a presence on victim systems. Evaluation experiments with popular cloud service infrastructures
(Amazon Web Services, Google Compute Engine, Azure and OpenStack) showed that this could minimize the
undetected acting period of intruders down to minutes.
1 INTRODUCTION
“The Tortoise and the Hare” is one of Aesop’s most
famous fables where ingenuity and trickery are em-
ployed by the tortoise to overcome a stronger oppo-
nent – the hare. Regarding this paper and according
to this fable, the hare is an attacker and the tortoise
is an operation entity responsible to protect a cloud
system against security breaches. Zero-day exploits
make this game an unfair game. How to protect a
cloud system against threats that are unknown to the
operator? But, when the game itself is unfair, should
not the system operation entity be unfair as well? That
is basically what this position paper is about. How to
build “unfair” cloud systems that permanently jangle
attackers nerves.
Cloud computing enables a variety of innovative
IT-enabled business and service models and many re-
search studies and programs focus to develop systems
Table 1: Some popular open source elastic platforms.
Platform Contributors URL
Kubernetes Cloud Native Found. http://kubernetes.io
Swarm Docker https://docker.io
Mesos Apache http://mesos.apache.org/
Nomad Hashicorp https://nomadproject.io/
in a responsible way to ensure the security and pri-
vacy of users. But compliance with standards, au-
dits and checklists, does not automatically equal se-
curity (Duncan and Whittington, 2014) and there is a
fundamental issue remaining. Zero-day vulnerabili-
ties are computer-software vulnerabilities that are un-
known to those who would be interested in mitigat-
ing the vulnerability (including the entity responsible
to operate a cloud application). Until a vulnerability
is mitigated, hackers can exploit it to adversely af-
fect computer programs, data, additional computers
or a network. For zero-day exploits, the probability
that vulnerabilities are patched is zero, so the exploit
should always succeed. Therefore, zero-day attacks
are a severe threat and we have to draw a scary conclu-
sion: In principle attackers can establish footholds
in our systems whenever they want.
Recent research (Kratzke, 2017; Kratzke, 2018b)
made successfully use of elastic container platforms
(see Table 1) and their “designed for failure” capa-
bilities to realize transferability of cloud-native appli-
cations at runtime. By transferability, the conducted
research means that a cloud-native application can be
moved from one IaaS provider infrastructure to an-
other without any downtime. These platforms are
more and more used as distributed and elastic runtime
Kratzke, N.
About being the Tortoise or the Hare? - A Position Paper on Making Cloud Applications too Fast and Furious for Attackers.
In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 465-472
ISBN: 978-989-758-295-0
Copyright ©2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reser ved
465
Figure 1: The cyber attack life cycle model Adapted from the cyber attack lifecycle used by the M-Trends reports, see Table
2.
environments for cloud-native applications (Kratzke
and Quint, 2017) and can be understood as a kind
of cloud infrastructure unifying middleware (Kratzke
and Peinl, 2016). It should be possible to make use
of the same features to immunize cloud applications
simply by moving an application within the same
provider infrastructure. To move anything from A to
A makes no sense at first glance. However, let us be
paranoid and aware that with some probability and at
a given time, an attacker will be successful and com-
promise at least one virtual machine (Bilge and Du-
mitras, 2012). In these cases, a transfer from A to
A would be an efficient counter measure – because
the intruder immediately loses any hijacked machine
that is moved. To understand that, the reader must
know that our approach does not effectively move a
machine, it regenerates it. To move a machine means
to launch a compensating machine unknown to the
intruder and to terminate the former (hi-jacked) ma-
chine. Whenever an application is moved all of its
virtual machines are regenerated. And this would ef-
fectively eliminate undetected hi-jacked machines.
The biological analogy of this strategy is called
“cell-regeneration” and the attack on ill cells is coor-
dinated by an immune system. This paper describes
first ideas for such a kind of immune system following
this outline. To provide some context for the reader,
Section 2 will explain the general life-cycle of a cyber
attack. It is assumed that every system can be pene-
trated due to zero-day exploits. Section 3 will sum-
marize some of our recent research to explain how
such immune systems could be built. Section 4 shows
some evaluation results measured from transferability
experiments. These numbers are used to estimate pos-
sible regeneration intervals for systems of different
sizes and to compare them with median dwell times
reported by security companies over the last seven
years (see Table 2). The advantages and limitations
of this proposal are related to other work in Section 5.
Finally, this proposal is discussed from a more criti-
cal point view in Section 6 to derive future research
challenges in Section 7.
2 CYBER ATTACK LIFE CYCLE
Figure 1 shows the cyber attack life cycle model
which is used by the M-Trends reports1to report de-
velopments in cyber attacks over the years. Accord-
ing to this model, an attacker passes through different
stages to complete a cyber attack mission. It starts
with initial reconnaissance and compromising of ac-
cess means. These steps are very often supported by
social engineering methodologies (Krombholz et al.,
2015) and phishing attacks (Gupta et al., 2016). The
goal is to establish a foothold near the system of in-
terest. All these steps are not covered by this paper,
because technical solutions are not able to harden the
weakest point in security – the human being. The fol-
lowing steps of this model are more interesting for
this paper. According to the life cycle model the at-
tacker’s goal is to escalate privileges to get access to
the target system. Because this leaves trails on the
system which could reveal a security breach, the at-
tacker is motivated to compromise this forensic trail.
According to security reports attackers make more
1http://bit.ly/2m7UAYb (visited 9th Nov. 2017)
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
466
Table 2: Undetected days on victim systems reported by
M-Trends. External and internal discovery data is reported
since 2015. No data could be found for 2011.
Year External notification Internal discovery Median
2010 - - 416
2011 - - ?
2012 - - 243
2013 - - 229
2014 - - 205
2015 320 56 146
2016 107 80 99
and more use of counter-forensic measures to hide
their presence and impair investigations. These re-
ports refer to batch scripts used to clear event logs and
securely delete arbitrary files. The technique is sim-
ple, but the intruders’ knowledge of forensic artifacts
demonstrate increased sophistication, as well as their
intent to persist in the environment. With a barely de-
tectable foothold, the internal reconnaissance of the
victim’s network is carried out to allow the lateral
movement to the target system. This is a complex and
lengthy process and may even take weeks. So, infil-
trated machines have worth for attackers and tend to
be used for as long as possible. Table 2 shows how
astonishingly many days on average an intruder has
access to a victim system. So, basically there is the re-
quirement, that an undetected attacker should lose
access to compromised nodes of a system as fast as
possible. But how?
3 REGENERATE-ABLE CLOUD
APPLICATIONS
Our recent research dealt mainly with vendor lock-in
and the question how to design cloud-native applica-
tions that are transferable between different cloud ser-
vice providers. One aspect that can be learned from
this is that there is no common understanding of what
a cloud-native application really is. A kind of soft-
ware that is “intentionally designed for the cloud”
is an often heard but vacuous phrase. However,
noteworthy similarities exist between various view
points on cloud-native applications (CNA) (Kratzke
and Quint, 2017). A common approach is to define
maturity levels in order to categorize different kinds
of cloud applications (see Table 3). (Fehling et al.,
2014) proposed the IDEAL model for CNAs. A CNA
should strive for an isolated state, is distributed,
provides elasticity in a horizontal scaling way, and
should be operated on automated deployment ma-
chinery. Finally, its components should be loosely
coupled.
(Balalaie et al., 2015) stress that these proper-
ties are addressed by cloud-specific architecture and
infrastructure approaches like Microservices (New-
man, 2015), API-based collaboration, adaption of
cloud-focused patterns (Fehling et al., 2014), and
self-service elastic platforms that are used to deploy
and operate these microservices via self-contained de-
ployment units (containers). Table 1 lists some of
these platforms that provide additional operational ca-
pabilities on top of IaaS infrastructures like automated
and on-demand scaling of application instances, ap-
plication health management, dynamic routing and
load balancing as well as aggregation of logs and met-
rics (Kratzke and Quint, 2017).
If the reader understands and accepts the com-
monality that cloud-native applications are operated
(more and more often) on elastic – often container-
based – platforms, it is an obvious idea to delegate
the responsibility to immunize cloud applications to
these platforms. Recent research showed that the op-
eration of these elastic container platforms and the de-
sign of applications running on-top of them should be
handled as two different engineering problems. This
often solves several issues in modern cloud-native ap-
plication engineering (Kratzke, 2018b). And that is
not just true for the transferability problem but might
be an option to tackle zero-day exploits. These kind
of platforms could be an essential part of the immune
system of modern cloud-native applications.
Furthermore, self-service elastic platforms are
really “bulletproofed” (Stine, 2015). Apache Mesos
(Hindman et al., 2011) has been successfully op-
erated for years by companies like Twitter or Net-
flix to consolidate hundreds of thousands of compute
nodes. Elastic container platforms are designed for
failure and provide self-healing capabilities via auto-
Table 3: Cloud Application Maturity Model, adapted
from OPEN DATA CENTER ALLIANCE Best Practices
(Ashtikar et al., 2014).
Level Maturity Criteria
3 Cloud - Transferable across infrastructure providers at
native runtime and without interruption of service.
- Automatically scale out/in based on stimuli.
2 Cloud - State is isolated in a minimum of services.
resilient - Unaffected by dependent service failures.
- Infrastructure agnostic.
1 Cloud - Composed of loosely coupled services.
friendly - Services are discoverable by name.
- Components are designed to cloud patterns.
- Compute and storage are separated.
0 Cloud - Operated on virtualized infrastructure.
ready - Instantiateable from image or script.
About being the Tortoise or the Hare? - A Position Paper on Making Cloud Applications too Fast and Furious for Attackers
467
Figure 2: The control theory inspired execution control loop compares the intended state rof an elastic container platform
with the current state sand derives necessary scaling actions. These actions are processed by the execution pipeline explained
in Figure 3. So, platforms can be operated elastically in a set of synchronized IaaS infrastructures. Explained in details by
(Kratzke, 2017).
Figure 3: The execution pipeline processes necessary actions to transfer the current state sinto the intended state r. See
(Kratzke, 2018b) for more details.
placement, auto-restart, auto-replication and auto-
scaling features. They will identify lost containers
(for whatever reasons, e.g. process failure or node un-
availability) and will restart containers and place them
on remaining nodes. These features are absolutely
necessary to operate large-scale distributed systems
in a resilient way. However, the same features can be
used intentionally to purge “compromised nodes”.
(Kratzke, 2017) demonstrated a software proto-
type that provides the control process shown in Fig-
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
468
ure 2 and Figure 3. This process relies on an in-
tended state rand a current state sof a container
cluster. If the intended state differs from the cur-
rent state (r6=s), necessary adaption actions are de-
duced (creation and attachment/detachment of nodes,
creation and termination of security groups) and pro-
cessed by an execution pipeline fully automatically
(see Figure 3) to reach the intended state r. With this
kind of control process, a cluster can be simply re-
sized by changing the intended amount of nodes in
the cluster. If the cluster is shrinking and nodes have
to be terminated, affected containers of running appli-
cations will be rescheduled to other available nodes.
The downside of this approach is, that this will
only work for Level 2 (cloud resilient) or Level 3
(cloud native) applications (see Table 3) which by de-
sign, can tolerate dependent service failures (due to
node failures and container rescheduling). However,
for that kind of Level 2 or Level 3 application, we
can use the same control process to regenerate nodes
of the container cluster. The reader shall consider a
cluster with s=Nnodes. If we want to regenerate
one node, we change the intended state to r=N+1
nodes which will add one new node to the cluster
(s0=N+1). And in a second step, we will decrease
the intended size of the cluster to r0=Nagain, which
has the effect that one node of the cluster is terminated
(s00 =N). So, a node is regenerated simply by adding
one node and deleting one node. We could even re-
generate the complete cluster by changing the cluster
size in the following way: s=N7! s0=2N7! s00 =
N. But, this would consume much more resources be-
cause the cluster would double its size for a limited
amount of time. A more resource efficient way would
be to regenerate the cluster in Nsteps: s=N7! s0=
N+17! s00 =N7! ... 7! s2N1=N+17! s2N=N.
This should make the general idea clear. The reader
is referred to (Kratzke, 2018b) for more details, es-
pecially if the reader is interested in the multi-cloud
capabilities, that are not covered by this paper due to
page limitations.
Whenever such a regeneration is triggered, all –
even undetected – hijacked machines would be ter-
minated and replaced by other machines, but the ap-
plications would be unaffected. For an attacker, this
means losing their foothold in the system completely.
Imagine this would be done once a day or even more
frequently?
4 EVALUATION RESULTS
The execution pipeline presented in Figure 3 was
evaluated by operating and transferring two elastic
platforms (Swarm Mode of Docker 17.06 and Kuber-
netes 1.7). The platforms operated a reference “sock-
shop” application being one of the most complete ref-
erence applications for microservices architecture re-
search (Aderaldo et al., 2017). Table 4 lists the ma-
chine types that show a high similarity across differ-
ent providers (Kratzke and Quint, 2015).
The evaluation of (Kratzke, 2018b) demonstrated
that most time is spent on the IaaS level (creation and
termination of nodes and security groups) and not on
the elastic platform level (joining, draining nodes).
The measured differences on infrastructures provided
by different providers is shown in Figure 4. For the
current use case the reader can ignore the times to
create and delete a security group (because that is a
one time action). However, there will be many node
creations and terminations. According to our exe-
cution pipeline shown in Figure 3, a node creation
(s=N7! s0=N+1) involves the durations to cre-
ate a node (request of the virtual machine including
all installation and configuration steps), to adjust se-
curity groups the cluster is operated in and to join
the new node into the cluster. The shutdown of a
node (s=N7! s0=N1) involves the termination
of the node (this includes the platform draining and
deregistering of the node and the request to terminate
the virtual machine) and the necessary adjustment of
the security group. So, for a complete regeneration
of a node (s=N7! s0=N+17! s00 =N) we have
to add these runtimes. Table 5 lists these values per
infrastructure.
Even on the “slowest” infrastructure, a node can
be regenerated in about 10 minutes. In other words,
one can regenerate six nodes every hour or up to
144 nodes a day or a cluster of 432 nodes every 72h
(which is the reporting time requested by the EU Gen-
eral Data Protection Regulation). If the reader com-
pares a 72h regeneration time of a more than 400 node
cluster (most systems are not so large) with the me-
Table 4: Used machine types and regions for evaluation.
Provider Region Master type Worker type
AWS eu-west-1 m4.xlarge m4.large
GCE europe-west1 n1-standard-4 n1-standard-2
Azure europewest Standard A3 Standard A2
OS own datacenter m1.large m1.medium
Table 5: Durations to regenerate a node (median values).
Provider Creation Secgroup Joining Term. Total
AWS 70 s 1 s 7 s 2 s 81 s
GCE 100 s 8 s 9 s 50 s 175 s
Azure 380 s 17 s 7 s 180 s 600 s
OS 110 s 2 s 7 s 5 s 126 s
About being the Tortoise or the Hare? - A Position Paper on Making Cloud Applications too Fast and Furious for Attackers
469
Figure 4: Infrastructure specific runtimes of IaaS opera-
tions Taken from (Kratzke, 2018b).
dian value of 99 days that attackers were present on a
victim system in 2016 (see Table 2) the benefit of the
proposed approach should become obvious.
5 RELATED WORK
To the best of the author’s knowledge, there are cur-
rently no approaches making intentional use of virtual
machine regeneration for security purposes. How-
ever, the proposed approach is derived from multi-
cloud scenarios and their increased requirements on
security. And there are several promising approaches
dealing with multi-cloud scenarios. So, all of them
could show comparable opportunities. But often,
these approaches come along with a lot of inner com-
plexity. A container based approach seems to han-
dle this kind of complexity better. There are some
good survey papers on this (Barker et al., 2015; Petcu
and Vasilakos, 2014; Toosi et al., 2014; Grozev and
Buyya, 2014).
To secure the forensic trail is essential for anomaly
detection approaches in log data (Fu et al., 2009;
Wurzenberger et al., 2017). Therefore (Duncan and
Whittington, 2016a; Duncan and Whittington, 2016b)
propose to use an immutable database for this pur-
pose, which they suggested to be kept in a remote lo-
cation from the main cloud system. Further research
deals with append-only data structures on untrusted
servers (Pulls and Peeters, 2015). Other approaches
propose building a secure and reliable file synchro-
nization service using multiple cloud synchronization
services as untrusted storage providers (Han et al.,
2015). Further approaches focus on the integrity of
logs and ensure their integrity by hash-chain schemes
and proofs of past logs published periodically by the
cloud providers (Zawoad et al., 2016). The ques-
tion remains, whether these approaches are scalable
enough to provide robust logging means for the foren-
sic trail of up to thousands of nodes. Messaging solu-
tions like Kafka (Wang et al., 2015) or logging stacks
like the ELK-Stack are bullet-proofed technologies
for consolidating logs but assume to be operated in a
trusted environment which often ends in very compli-
cated kind of double logging architectures (Kratzke,
2018a).
6 CRITICAL DISCUSSION
The idea of using an immune system like approach
to remove undetected intruders in virtual machines
seems to a lot of experts intriguing. But state of the art
is, that this is not done. And there might be reasons
for that and open questions the reader should consider.
Several reviewers remarked that the proposal can
be compared with the approach to restart periodically
virtual machines that have memory leak issues. This
has nothing to do with security concerns, and could
be applied to traditional (non-cloud) systems as well.
So, the approach may have even a broader focus than
presented (which is not a bad thing).
Another question is how to detect “infected”
nodes? The presented approach selects nodes sim-
ply at random. This will hit every node at some time.
The same could be done using a round-robin approach
but a round-robin strategy would be better predictable
for an attacker. However, both strategies will create
a lot of unnecessary regenerations and that leaves ob-
viously room for improvements. It seems obvious to
search for solutions like presented by (Fu et al., 2009;
Wurzenberger et al., 2017) to provide some “intelli-
gence” for the identification of “suspicious” nodes.
This would limit regenerations to likely “infected”
nodes. In all cases it is essential for anomaly de-
tection approaches to secure the forensic trail (Dun-
can and Whittington, 2016a; Duncan and Whitting-
ton, 2016b).
Furthermore, to regenerate nodes periodically or
even randomly is likely nontrivial in practice and de-
pends on the state management requirements for the
affected nodes. Therefore, this paper proposes the ap-
proach only as a promising solution for Level 2 or 3
cloud applications (see Table 3) that are operated on
elastic container platforms. That kind of applications
have eligible state management characteristics. But,
this is obviously a limitation.
One could be further concerned about exploits that
are adaptable to bio-inspired systems. Stealthy res-
ident worms dating back to the old PC era would
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
470
be an example. This might be especially true for
the often encountered case of not entirely stateless
services, when data-as-code dependencies or code-
injection vulnerabilities exist. Furthermore, attackers
could shift their focus to the platform itself in order
to disable the regeneration mechanism as a first step.
On the other hand, this could be easily detected – but
there could exist more sophisticated attacks.
Finally, there is obviously room and need for a
much more detailed evaluation. The effectiveness of
this approach needs a large scale and real world eval-
uation with more complex cloud native applications
using multiple coordinated virtual machines. This is
up for ongoing research and should be kept in mind.
7 CONCLUSION
There is still no such thing as an impenetrable system.
Once attackers successfully breach a system, there is
little to prevent them from doing arbitrary harm – but
we can reduce the available time for the intruder to
do this. The presented approach evolved mainly from
transferability research questions for cloud-native ap-
plications. But it can be the foundation for an “im-
mune system” inspired approach to tackle zero-day
exploits. The main intent is simply to massively
reduce the time for an attacker acting undetected.
Therefore, this paper proposed to regenerate virtual
machines (the cells of an IT-system) with a much
higher frequency than usual to purge even undetected
intruders. Evaluations on infrastructures provided by
AWS, GCE, Azure and OpenStack showed that a vir-
tual machine can be regenerated between two minutes
(AWS) and 10 minutes (Azure). The reader should
compare these times with recent cyber security re-
ports. In 2016 an attacker was undetected on a victim
system for about 100 days. The presented approach
means for intruders that their undetected time on vic-
tim systems is not measured in months or days any-
more, it would be measured in minutes.
Such a biology inspired immune system solution
is charming but may also involve downsides. To re-
generate too many nodes at the same time would let
the system run “hot”. The reader might know this
health state from own experiences as fever. And if the
immune system attacks to many unaffected (healthy)
nodes again and again, this could be even called an
auto-immune disease. Both states are not the best op-
eration modes of immune systems. Although the pre-
sented approach can limit available time for an attack
substantially, we should consider that even in a very
short amount of time an attacker could delete (parts)
of the cloud forensic trail. This could limit the effec-
tiveness of “suspect node” detection mechanisms. To
use external and trusted append-only logging systems
seems somehow obvious. However, existing solutions
rely very often on trusted environments.
So, further research should investigate how “re-
generating” platforms and append-only logging sys-
tems can be operated on untrusted environments with-
out fostering unwanted and non-preferable effects
known from the human immune system like fever
or even auto-immune diseases. The critical discus-
sion in Section 6 showed that there is need for ad-
ditional evaluation and room for more in-depth re-
search. However, several reviewers remarked inde-
pendently that the basic idea is so “intriguing”, that it
should be considered more consequently.
ACKNOWLEDGEMENTS
This research is partly funded by the Cloud TRANSIT
project (13FH021PX4, German Federal Ministry of
Education and Research). I would like to thank Bob
Duncan from the University of Aberdeen and all the
anonymous reviewers for their inspiring thoughts on
cloud security challenges.
REFERENCES
Aderaldo, C. M., Mendonc¸a, N. C., Pahl, C., and Jamshidi,
P. (2017). Benchmark requirements for microservices
architecture research. In Proc. of the 1st Int. Work-
shop on Establishing the Community-Wide Infras-
tructure for Architecture-Based Software Engineer-
ing, ECASE ’17, Piscataway, NJ, USA. IEEE Press.
Ashtikar, S., Barker, C., Clem, B., Fichadia, P., Krupin, V.,
Louie, K., Malhotra, G., Nielsen, D., Simpson, N.,
and Spence, C. (2014). OPEN DATA CENTER AL-
LIANCE Best Practices: Architecting Cloud-Aware
Applications Rev. 1.0.
Balalaie, A., Heydarnoori, A., and Jamshidi, P. (2015).
Migrating to Cloud-Native Architectures Using Mi-
croservices: An Experience Report. In 1st Int. Work-
shop on Cloud Adoption and Migration (CloudWay),
Taormina, Italy.
Barker, A., Varghese, B., and Thai, L. (2015). Cloud Ser-
vices Brokerage: A Survey and Research Roadmap.
In 2015 IEEE 8th International Conference on Cloud
Computing. IEEE.
Bilge, L. and Dumitras, T. (2012). Before we knew it: an
empirical study of zero-day attacks in the real world.
In ACM Conference on Computer and Communica-
tions Security.
Duncan, B. and Whittington, M. (2014). Compliance with
standards, assurance and audit: does this equal secu-
rity? In Proc. 7th Int. Conf. Secur. Inf. Networks - SIN
’14, pages 77–84, Glasgow. ACM.
About being the Tortoise or the Hare? - A Position Paper on Making Cloud Applications too Fast and Furious for Attackers
471
Duncan, B. and Whittington, M. (2016a). Cloud cyber-
security: Empowering the audit trail. Int. J. Adv. Se-
cur., 9(3 & 4):169–183.
Duncan, B. and Whittington, M. (2016b). Creating an Im-
mutable Database for Secure Cloud Audit Trail and
System Logging. In Cloud Comput. 2017 8th Int.
Conf. Cloud Comput. GRIDs, Virtualization, pages
54–59, Athens, Greece. IARIA, ISBN: 978-1-61208-
529-6.
Fehling, C., Leymann, F., Retter, R., Schupeck, W., and Ar-
bitter, P. (2014). Cloud Computing Patterns: Funda-
mentals to Design, Build, and Manage Cloud Appli-
cations. Springer Publishing Company, Incorporated.
Fernandes, D. A. B., Soares, L. F. B., Gomes, J. V. P., Freire,
M. M., and In´
acio, P. R. M. (2014). Security issues in
cloud environments: a survey. Int. Journal of Infor-
mation Security.
Fu, Q., Lou, J.-G., Wang, Y., and Li, J. (2009). Execution
Anomaly Detection in Distributed Systems through
Unstructured Log Analysis. In 2009 Ninth IEEE Int.
Conf. on Data Mining.
Grozev, N. and Buyya, R. (2014). Inter-Cloud architectures
and application brokering: taxonomy and survey. Soft-
ware: Practice and Experience, 44(3).
Gupta, S., Singhal, A., and Kapoor, A. (2016). A literature
survey on social engineering attacks: Phishing attack.
2016 International Conference on Computing, Com-
munication and Automation (ICCCA), pages 537–540.
Han, S., Shen, H., Kim, T., Krishnamurthy, A., Anderson,
T. E., and Wetherall, D. (2015). MetaSync: File Syn-
chronization Across Multiple Untrusted Storage Ser-
vices. In USENIX Annual Technical Conference.
Hindman, B., Konwinski, A., Zaharia, M., Ghodsi, A.,
Joseph, A. D., Katz, R. H., Shenker, S., and Stoica,
I. (2011). Mesos: A Platform for Fine-Grained Re-
source Sharing in the Data Center. In 8th USENIX
Conf. on Networked systems design and implementa-
tion (NSDI’11), volume 11.
Kratzke, N. (2017). Smuggling Multi-Cloud Support into
Cloud-native Applications using Elastic Container
Platforms. In Proc. of the 7th Int. Conf. on Cloud
Computing and Services Science (CLOSER 2017).
Kratzke, N. (2018a). About an Immune System Un-
derstanding for Cloud-native Applications - Biology
Inspired Thoughts to Immunize the Cloud Forensic
Trail. In Proc. of the 9th Int. Conf. on Cloud Comput-
ing, GRIDS, and Virtualization (CLOUD COMPUT-
ING 2018, Barcelona, Spain).
Kratzke, N. (2018b). About the complexity to transfer cloud
applications at runtime and how container platforms
can contribute? In Cloud Computing and Service Sci-
ences: 7th International Conference, CLOSER 2017,
Revised Selected Papers, Communications in Com-
puter and Information Science (CCIS). Springer In-
ternational Publishing. to be published.
Kratzke, N. and Peinl, R. (2016). ClouNS - a Cloud-Native
Application Reference Model for Enterprise Archi-
tects. In 2016 IEEE 20th Int. Enterprise Distributed
Object Computing Workshop (EDOCW).
Kratzke, N. and Quint, P.-C. (2015). About Automatic
Benchmarking of IaaS Cloud Service Providers for a
World of Container Clusters. Journal of Cloud Com-
puting Research, 1(1).
Kratzke, N. and Quint, P.-C. (2017). Understanding Cloud-
native Applications after 10 Years of Cloud Comput-
ing - A Systematic Mapping Study. Journal of Sys-
tems and Software, 126(April).
Krombholz, K., Hobel, H., Huber, M., and Weippl, E.
(2015). Advanced social engineering attacks. Jour-
nal of Information Security and Applications, 22.
Newman, S. (2015). Building Microservices. O’Reilly Me-
dia, Incorporated.
Petcu, D. and Vasilakos, A. V. (2014). Portability in clouds:
approaches and research opportunities. Scalable Com-
puting: Practice and Experience, 15(3).
Pulls, T. and Peeters, R. (2015). Balloon: A Forward-Secure
Append-Only Persistent Authenticated Data Structure.
Springer International Publishing, Cham.
Stine, M. (2015). Migrating to Cloud-Native Application
Architectures. O’Reilly.
Toosi, A. N., Calheiros, R. N., and Buyya, R. (2014). In-
terconnected Cloud Computing Environments. ACM
Computing Surveys, 47(1).
Wang, G., Koshy, J., Subramanian, S., Paramasivam, K.,
Zadeh, M., Narkhede, N., Rao, J., Kreps, J., and Stein,
J. (2015). Building a Replicated Logging System with
Apache Kafka. In Proc. of the VLDB Endowment, vol-
ume 8.
Wurzenberger, M., Skopik, F., Fiedler, R., and Kastner, W.
(2017). Applying High-Performance Bioinformatics
Tools for Outlier Detection in Log Data. In CYB-
CONF.
Zawoad, S., Dutta, A. K., and Hasan, R. (2016). To-
wards building forensics enabled cloud through secure
logging-as-a-service. IEEE Transactions on Depend-
able and Secure Computing, 13(2):148–162.
CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science
472
... Kratzke et 'al. [20] proposed a biology-inspired immune system that takes advantage of the agile properties of MSA to improve security. Our proposed mechanism can be combined with this work to improve resiliency. ...
... For example, a synergy of the security potentials of MSA asserted by Kratzke et 'al. [20] and our mechanism can be explored. This approach uses microservices attributes e.g. ...
Conference Paper
Full-text available
Microservice Architectures (MSA) structure applications as a collection of loosely coupled services that implement business capabilities. The key advantages of MSA include inherent support for continuous deployment of large complex applications, agility and enhanced productivity. However, studies indicate that most MSA are homogeneous, and introduce shared vulnerabilites, thus vulnerable to multi-step attacks, which are economics-of-scale incentives to attackers. In this paper, we address the issue of shared vulnerabilities in microservices with a novel solution based on the concept of Moving Target Defenses (MTD). Our mechanism works by performing risk analysis against microservices to detect and prioritize vulnerabilities. Thereafter, security risk-oriented software diversification is employed , guided by a defined diversification index. The diversification is performed at runtime, leveraging both model and template based automatic code generation techniques to automatically transform programming languages and container images of the microservices. Consequently, the microservices attack surfaces are altered thereby introducing uncertainty for attackers while reducing the attackability of the microservices. Our experiments demonstrate the efficiency of our solution, with an average success rate of over 70% attack surface randomization.
... Kratzke et 'al. [17] proposed a biology-inspired immune system that takes advantage of the agile properties of MSA to improve security e.g. recovery from failures. ...
... Similarly, a synergy of the security potentials of MSA asserted by Kratzke et 'al. [17] and our mechanism can be explored. ...
Preprint
Full-text available
Microservice Architectures (MSA) structure applications as a collection of loosely coupled services that implement business capabilities. A key advantage of MSA is inherent support for continuous deployment of large complex applications. However, studies indicate that homogeneous MSA are vulnerable to code reuse attacks, and as such serves as an economics-of-scale incentive to attackers. In this paper, we address the issue of code reuse vulnerabilities with a novel solution based on the concept of Moving Target Defenses (MTD). Our mechanism works by performing risk analysis against target microservices to detect and prioritize vulnerabilities. Thereafter, a risk-oriented diversification index is derived to define the depth of diversification to be implemented. Generative programming techniques e.g. OpenAPI code generators are then used to automatically transform the programming languages and container images of the target microservices. Consequently, the attack surfaces are altered thereby introducing uncertainty for attackers and reduced possibilities for successful attacks. Also, we model microservice attack surfaces and correlated failures structures to detect and prioritize causal dependence relationship between vulnerabilities. Our practical experiments validate the efficiency of our security tactics, over 50 % of the attack surface is randomized.
Conference Paper
Full-text available
There is no such thing as an impenetrable system, although the penetration of systems does get harder from year to year. The median days that intruders remained undetected on victim systems dropped from 416 days in 2010 down to 99 in 2016. Perhaps because of that, a new trend in security breaches is to compromise the forensic trail to allow the intruder to remain undetected for longer in victim systems and to retain valuable footholds for as long as possible. This paper proposes an immune system inspired solution which uses a more frequent regeneration of cloud application nodes to ensure that undetected compromised nodes can be purged. This makes it much harder for intruders to maintain a presence on victim systems. Basically the biological concept of cell-regeneration is combined with the information systems concept of append-only logs. Evaluation experiments performed on popular cloud service infrastructures (Amazon Web Services, Google Compute Engine, Azure and OpenStack) have shown that between 6 and 40 nodes of elastic container platforms can be regenerated per hour. Even a large cluster of 400 nodes could be regenerated in somewhere between 9 and 66 hours. So, regeneration shows the potential to reduce the foothold of undetected intruders from months to just hours.
Article
Full-text available
The capability to operate cloud-native applications can generate enormous business growth and value. But enterprise architects should be aware that cloud-native applications are vulnerable to vendor lock-in. We investigated cloud-native application design principles, public cloud service providers, and industrial cloud standards. All results indicate that most cloud service categories seem to foster vendor lock-in situations which might be especially problematic for enterprise architectures. This might sound disillusioning at first. However, we present a reference model for cloud-native applications that relies only on a small subset of well standardized IaaS services. The reference model can be used for codifying cloud technologies. It can guide technology identification, classification, adoption, research and development processes for cloud-native application and for vendor lock-in aware enterprise architecture engineering methodologies.
Article
Full-text available
Cyber-security presents a serious challenge. Cyber security in the cloud presents a far more serious challenge, due to the multi-tenant nature of cloud relationships and the transitory nature of cloud instances.We have identified a fundamental weakness when undertaking cloud audit, namely the misconceptions surrounding the purpose of audit, what comprises a proper audit trail, what should be included, and how it should be achieved and maintained. A properly specified audit trail can provide a powerful tool in the armoury against cyber-crime, yet it is all too easy to throw away the benefits offered by this simple tool through lack of understanding, incompetence, mis-configuration or sheer laziness. A major weakness is the need to ensure the audit trail is properly preserved. We propose that some simple changes in approach are undertaken, which can considerably improve the status quo, while radically improving the ability to conduct forensic examination in the event of a breach, but of course, merely having an effective audit trail is not enough — we actually have to analyse it regularly to realise the potential benefits it offers.
Conference Paper
Full-text available
Microservices have recently emerged as a new architectural style in which distributed applications are broken up into small independently deployable services, each running in its own process and communicating via lightweight mechanisms. However, there is still a lack of repeatable empirical research on the design, development and evaluation of microservices applications. As a first step towards filling this gap, this paper proposes, discusses and illustrates the use of an initial set of requirements that may be useful in selecting a community-owned architecture benchmark to support repeatable microservices research.
Conference Paper
Full-text available
Conventional web based systems present a multiplic-ity of attack vectors. One of the main components, the database, is frequently configured incorrectly, often using default settings, which leave the system wide open to attack. Once a system has been attacked, valuable audit trail and system log data is usually deleted to cover the trail of the perpetrator. Given the average industry time between breach and discovery, there is often little forensic trail left to follow. Of equal importance is that in cloud settings, where new instances are automatically spooled and shut down to follow the demand curve, any data stored on the running instance before shut down is lost. We demonstrate how the configuration of a simple immutable database, running on a separate private system can go a long way to resolving this problem. Index Terms—Cloud security and privacy; immutable database; forensic trail.
Conference Paper
Full-text available
Elastic container platforms (like Kubernetes, Docker Swarm, Apache Mesos) fit very well with existing cloud-native application architecture approaches. So it is more than astonishing, that these already existing and open source available elastic platforms are not considered more consequently in multi-cloud research. Elastic container platforms provide inherent multi-cloud support that can be easily accessed. We present a solution proposal of a control process which is able to scale (and migrate as a side effect) elastic container platforms across different public and private cloud-service providers. This control loop can be used in an execution phase of self-adaptive auto-scaling MAPE loops (monitoring, analysis, planning, execution). Additionally, we present several lessons learned from our prototype implementation which might be of general interest for researchers and practitioners. For instance, to describe only the intended state of an elastic platform and let a single control process take care to reach this intended state is far less complex than to define plenty of specific and necessary multi-cloud aware workflows to deploy, migrate, terminate, scale up and scale down elastic platforms or applications.
Article
Full-text available
It is common sense that cloud-native applications (CNA) are intentionally designed for the cloud. Although this understanding can be broadly used it does not guide and explain what a cloud-native application exactly is. The term "cloud-native" was used quite frequently in birthday times of cloud computing (2006) which seems somehow obvious nowadays. But the term disappeared almost completely. Suddenly and in the last years the term is used again more and more frequently and shows increasing momentum. This paper summarizes the outcomes of a systematic mapping study analyzing research papers covering "cloud-native" topics, research questions and engineering methodologies. We summarize research focuses and trends dealing with cloud-native application engineering approaches. Furthermore, we provide a definition for the term "cloud-native application" which takes all findings, insights of analyzed publications and already existing and well-defined terminology into account.
Conference Paper
Phishing is a network type attack where the attacker creates the fake of an existing webpage to fool an online user into elicit personal Information. The prime objective of this review is to do literature survey on social engineering attack: Phishing attack and techniques to detect attack. Phishing is the combination of social engineering and technical methods to convince the user to reveal their personal data. The paper discusses about the Phishing social engineering attack theoretically and their issues in the life of human Beings. Phishing is typically carried out by Email spoofing or instant messaging. It targets the user who has no knowledge about social engineering attacks, and internet security, like persons who do not take care of privacy of their accounts details such as Facebook, Gmail, credit banks accounts and other financial accounts. The paper discusses various types of Phishing attacks such as Tab-napping, spoofing emails, Trojan horse, hacking and how to prevent them. At the same time this paper also provides different techniques to detect these attacks so that they can be easily dealt with in case one of them occurs. The paper gives a thorough analysis of various Phishing attacks along with their advantages and disadvantages.