Sound and Complete Runtime Security Monitor for Application Software

0.37 MB·

by  Muhammad Taimoor Khan

Sound and Complete Runtime Security Monitor for
Application Software
Muhammad Taimoor Khan Dimitrios Serpanos Howard Shrobe
QCRI, HBKU QCRI, HBKU MIT CSAIL, USA
Abstract—Conventional approaches for ensuring the security
of application software at run-time, through monitoring, either
produce (high rates of) false alarms (e.g. intrusion detection
6
systems) or limit application performance (e.g. run-time veri-
1
fication). We present a run-time security monitor that detects
0
both known and unknown cyber attacks by checking that the
2
run-time behavior of the application is consistent with the

n expected behavior modeled in application specification. This is
a crucial because, even if the implementation is consistent with
J its specification, the application may still be vulnerable due to
7 flaws in the supporting infrastructure (e.g. the language run-
1 timesystem,supportinglibrariesandtheoperatingsystem).This
run-time security monitor is sound and complete, eliminating
] false alarms, as well as efficient, so that it does not limit run- Fig.1. ClassificationofRuntimeSecurityMonitoringSystems
R time application performance and so that it supports real-time
C systems. Importantly, this monitor is readily applicable to both
legacy and new system platforms.
s. The security monitor takes as input the application spec- systems do not “understand” what an attacker is trying to
c ification and the application implementation, which may be achieve. Actually, most such systems are retrospective, taking
[ expressed in different languages. The specification language of into account and analyzing historical data, resulting to attack
the application software is formalized based on monadic second
1 surface signatures of previous attacks and attempting to iden-
orderlogic(i.e.firstorderlogicandsettheory)andeventcalculus
v tify the same signature(s) in new traffic. Thus, conventional
interpreted over algebraic data structures. This language allows
3 us to express behavior of an application at any desired (and run-timemonitorsarepassive,waitingfor(andexpectingthat)
6
practical) level of abstraction as well as with high degree of something similar to what has already happened to recur.
2
modularity. The security monitor detects every attack by sys- Attackers, of course, respond by varying their attacks so as
4
tematicallycomparingtheapplicationexecutionandspecification
0 to avoid detection.
behaviors at runtime, even though they operate at two different
. Therearetwodimensionsalongwhichrun-timemonitoring
1 levelsofabstraction.Wedefinethedenotationalsemanticsofthe
0 specification language and prove that the monitor is sound and systems for security can be classified. The first one is the
6 complete,i.e.iftheapplicationisconsistentwithitsspecification, behaviordescriptionmethod,i.e.profile-basedormodel-based.
1 the security monitor will produce no false alarms (soundness) The second one is the behavior comparison method, i.e.
: and that it will detect any deviation of the application from the
v matching to bad behavior or deviation from good behavior.
behaviorsanctionedbythespecificationlanguage(completeness).
i This classification approach leads to four classes, as shown
X Furthermore, the monitor is efficient because of the modular
application specification at appropriate level(s) of abstraction. in Figure 1, which include existing techniques and systems,
r
a Importantly, the application specification language enables the each with its own strengths and weaknesses. Profile-based
description of known or potential attack plans, enabling not systems that detect attacks by matching with bad behavior
only attack detection but attack characterization as well and,
(Class1inthefigure)typicallyemploystatisticalandmachine
thus, facilitating effective and efficient defenses to sophisticated
learning methods to build a profile of bad behavior of the
attacks.
systems and more specifically, build statistical profiles of
I. INTRODUCTION attacks (e.g., [27], [28]). These systems are more robust than
Runtime security monitors are components of defending model based systems, since the machine learning techniques
systems against cyber attacks and must provide fast and ac- tend to generalize from the data presented. However, they
curate detection of attacks. Conventional run-time monitoring do not provide rich diagnostic information and suffer from
systems suffer from high false alarm rates, for both positive false alarms. Alternatively, profile-based systems that detect
and negative alarms, and are inefficient because their typical deviation from good behavior (Class 3 in the figure) typically
amountofobservedparametersislargeandpossiblyirrelevant buildastatisticalprofileofnormal(good)behavioranddetect
to a number of attacks. There are two key reasons for these deviations from this profile (e.g. [25], [26]). Such anomaly
limitations:first,thesystemsdonot“understand”thecomplete detectors are even more robust than Class 1 systems, because
behavior of the system they are protecting, and second, the they do not depend on historical knowledge of the form of
an attack. However, they have a significant false alarm rate, specificbehaviorof”real-time”systemswithoutaffectingtheir
because they have limited diagnostic information: when a performance at run-time. As our run-time security monitor is
deviation is detected, the known information about it is that using an executable application specification, it is efficient for
something out of the ordinary has happened, but there is no useinreal-timesystemashasbeenprovenforreal-timesafety-
sufficient information whether this is malicious, accidental or critical systems [31].
justavariationofthenormalbehaviorbeyondthestatistically Ourrun-timesecuritymonitor(“RSM”),showninFigure2,
accepted profile. is the core component of a larger system named ARMET.
Model-basedsystems(Classes2and4inFigure1)arepop- ARMET takes as input a specification (“AppSpec”) and an
ular in highly secure environments, where successful attacks implementation (”AppImpl”) of the application of interest.
cause significantly high costs. Signature-based systems are a Based on the specification, the “Wrapper Synthesizer” of
typical example in this class (e.g. [23], [24]), and they look ARMETgeneratesprobestoobservetherun-timebehaviorof
for matches to bad behavior, i.e. they are systems in Class 2. the application that corresponds to the specification elements.
The advantage of such systems is that, when a match occurs, During execution of the “AppImpl”, the RSM checks whether
i.e. an attack is detected, the systems have enough diagnostic the actual behavior of the system (observations generated
information available to ”understand” what the failure has by ”Wrapper Synthesizer”) is consistent with the predictions
been. However, they lack robustness, since they will fail to generated from ”AppSpec”. If an inconsistency is detected,
detect an attack, if they have no model of it; thus, they are RSM raises an alarm and ARMET suspends the application
susceptible to zero-day attacks and, in general, attacks they execution and proceeds to diagnosis, in order to identify why
have not been trained for. Finally, model-based systems that the execution of ”AppImpl” did not behave as predicted. In
employrun-timesoftwareverificationtodetectdeviationfrom addition to run-time monitoring, ARMET employs diagnostic
good behavior fall in Class 4 of the figure. These systems reasoning techniques to further isolate and characterize the
model the good behavior of a system (e.g. [29], [30]) and failure [11]. ARMET is highly robust and has high diagnostic
detect deviations from that behavior using run-time software data resolution, which is a key requirement of real-time sys-
verification techniques. Their advantage is that, whenever tems that require continuous operation even after a successful
the system execution deviates from good behavior, there is attack. ARMET achieves continuous operation through the
knowledge of the exact problem that led to the deviation construction of a far more complex models of applications.
(i.e. the offending instruction or routine). However, such ver- RSM runs executable application specification in parallel
ification methods (a) require adequate design/implementation withtheactualapplicationcode,comparingtheirresultsatthe
information of the system to operate (which is usually not granularity and abstraction level of the executable specifica-
the case for legacy systems) and (b) limit run-time system tion. The executable specification is hierarchical and modular,
performance, with high impact on real-time systems, such as allowing flexibility in the granularity of the monitoring. De-
industrial control systems (ICS). pending on the environment, the executable specification may
Our run-time security monitor falls in Class 4, because it run at a high level of abstraction, incurring less overhead,
(a) models normal (good) behavior of the system through but requiring more diagnostic reasoning when the program
a formal specification description and (b) raises an alarm diverges from the behavior of the executable specification.
when the behavior of the application’s execution deviates Alternatively, the executable specification can be elaborated
from the behavior described in the (executable) specification. ingreaterdetail,incurringmoreoverhead,butprovidingmore
Specifically, our security monitor has an active model of containment.
normal behavior, namely an executable specification of the Optionally, the model can also specify suspected incorrect
application [3]. This executable specification consists of a behaviors of a component and associated potential attack
decomposition into sub-modules and pre- and post-conditions plans, allowing the diagnostic reasoning to characterize the
and invariant for each sub-module. In addition, data-flow and wayinwhichacomponentmayhavemisbehaved.Then,diag-
control-flow links connect the sub-modules, specifying the nosis is a selection of behavioral modes for each component
expected flow of values and of control. The pre- and post- of the specification, such that the specification predicts the
conditions and invariant are arbitrary first-order statements observed misbehavior of the system.
about the set of data values (that flow into and out of the sub- Through this work, we introduce a highly reliable run-
modules) and about other arbitrary constraints respectively. time security monitor with proven absence of false alarms
Our run-time security monitor is suitable not only for (i.e. soundness and completeness). Importantly, the proof
new systems, which derive application implementation from establishes a contract between the monitor and its user such
applicationspecification,butalsofor”legacy”systems,where that, if the user establishes the assumptions of the proof, the
applicationimplementationsexistwithoutadequate(formalor monitor guarantees to detect any violation at run-time.
informal) application specifications. This can be achieved by The remaining of the paper is organized as follows. In
describing application specification at any feasible level of Section II, we describe related work and in Section III we
abstraction through available specification information. Fur- present the calculus (syntax and semantics) of the application
thermore, modular application specification at any desired specification language. In Section IV, we first present the
level of abstraction also allows us to monitor only attack(s) calculus of the security monitor and then we present the
formulation and proof of soundness and completeness of the
for run-time monitoring of real-time systems [18]. However,
Barnett et al. have used ASML as an executable specification
language forrun-time monitoring[19]. ASMLis anextension
of ASM, which is based on the formalism of a transition sys-
temwhosestatesarefirstorderalgebras[4].Thereisnoformal
semantics of ASML, however, the operational semantics of
someconstructsofASMhasbeendefinedbyHannanetal.[5].
More recently, Choilko et al. have developed a framework for
executable specification based run-time monitoring of timed
systems [21]. In this work, the formalism of the specification
isbasedonanextendedtimeintervalwhichisapairofatime
event and a time interval. The formalism for implementation
Fig.2. TheArchitectureofCoreDefending-System is based on timed word which is a sequence of time events
andthegoalofthemonitoristochecktheconformanceofan
implementation word and the specification trace.
monitor. We conclude in Section V.
In contrast to the approaches discussed above, the focus
of our run-time security monitor is to check consistency
II. RELATEDWORK
of automatically generated predictions (conditions) from an
The operation of RSM is to check the consistency between executable specification language and run-time observations
thespecifiedandexecutionbehaviorsofanapplicationatrun- of application execution. The formalism of our specification
time. This may be viewed as a run-time verification problem. language is based on monadic second order logic [20] and
The goal of run-time verification is to specify the intended event calculus interpreted over algebraic data structures. This
behavior of a system in some formalism and to generate an formalism allows specification of faulty behaviors of a sys-
executablemonitorfromthisformalism(i.e.specification)that tem. Furthermore, the formalism enables description of attack
reports inconsistent execution, if detected. plans, which are exploited by the monitor at run-time for
There has been extensive research on specification based early threat detection against more sophisticated and complex
run-timemonitoring.Mostsuchapproachesemployformalism attacks, e.g. advanced persistent threats. Our formalism is
suchascontextgrammars,regularexpressions[13],eventcal- similar to Crash Hoare-logic that is used to capture the faulty
culus [10], temporal logic [7], [6] and rule systems operating behavior of a file system [22]. Our formalism allows sound
overatomicformulas[9].Suchformalismofferlimitedexpres- construction (resp. specification) of high-level abstract behav-
sive power to formalize complex system properties, although ior of a system from low-level abstract behavior(s) using a
theycanbetranslatedintoefficientexecutablemonitors.Toad- methodanalogoustoclassicalsetbuilder.Oursecuritymonitor
dressesthechallengesofrun-timemonitoringof”legacy”and is the first approach in run-time monitoring that formally
”real-time” systems (namely the lack of design information assures the absence of false alarms and thus is sound and
and performance respectively), our formalism allows not only complete. For our proof we use the denotational semantics of
to specify dependencies, system level behavior and security the application specification language as described in [2].
properties(incaseofpartialdesigndetails),butalsotospecify
internal system behavior and complex security properties (in III. APPLICATIONSPECIFICATIONLANGUAGE
case of desired design details) of such systems as well. Ourexecutable(application)specificationlanguage[3]con-
Run-time monitoring of legacy systems has not received sists of a decomposition of an application behavior into sub-
significant attention. However, there have been attempts to modules and pre- and post-conditions and invariant (behav-
apply similar monitoring techniques. For example, Kaiser et ioral description) for each sub-module: in rest of the paper,
al. instrument the systems by probing and passing data to we use the term system for application behavior. The decom-
another component that forms a basis of the system’s model position is further equipped with data-flow and control-flow
whichislaterusedtomonitorrun-timemodificationsautomat- links that connect the sub-modules, specifying the expected
ically [15]. More recently, Wofgang et al. have automatically flow of values and of control. The specification also allows
generated run-time monitor for network traffic from a high- to specify potential attack plans for the components based on
level specification language which is based on first order attack models and associated rules that imply a certain attack
predicate logic and set theory [14]. Furthermore, based on a model.
variantofdenotationalsemanticsofthespecificationlanguage In the following subsection, we discuss selected high level
and operational semantics of the monitor [17], they verified syntactic domains and their semantics.
soundness of the resource analysis of the monitor [16]. The
A. Syntax
resource analysis identifies the number of instances of the
monitor and the number of messages required to detect a Based on the aforementioned description, syntactically, the
violation. specificationlanguage(representedbysyntacticdomainω)has
Model-basedexecutablespecificationshavebeenrarelyused following three main top level constructs:
α ::= define-ensemble CompName
1) hierarchical decomposition (ζ) of sub-modules,
:entry-events :auto | set(Evnt)
2) behavioral description (η) of each sub-module and
:exit-events set(Evnt)
3) attack plans ((cid:15)) of modules/sub-modules.
:allowable-events set(Evnt)
The simplified grammar of these top level domains is shown
:inputs set(ObjName)
in Figure 3.
:outputs set(ObjName)
:components set(Comp)
Application Specification ω ::= ... ζ η (cid:15)... :controlflows set(CtrlFlow)
Decomposition ζ ::= α | (α) ζ :splits set(SpltCF)
Behavioral Model η ::= β | (β) η :joins set(JoinCF)
Attack Plan (cid:15) ::= δ ρ | (δ ρ) (cid:15) :dataflows set(DataFlow)
... :resources set(Res)
:resource-mapping set(ResMap)
Fig.3. TopLevelSyntacticDomainsoftheLanguage
:model-mappings set(ModMap)
:vulnerabilities set(Vulnrablty)
In the following we briefly discuss the decomposition and
attack plans, and will focus more on behavioral description,
Fig.4. SyntacticDomainforDecomposition(α)
being core and the only one that is also used in the following
sections for semantics and proof.
β ::= defbehavior-model (CompName normal | compromised)
Decomposition (α): The hierarchical decomposition α of a
component1 consists of :inputs set(ObjName)
:outputs set(ObjName)
1) its interface
:allowable-events set(Evnt)
• sets of inputs and outputs respectively :prerequisites set(BehCond)
• a set of the resources used by the component :postconditions set(BehCond)
(e.g. files, binary code, ports) and a set of sub- :invariant set(BehCond)
components
• sets of events that allow entry and exit to and from Fig.5. SyntacticDomainforBehavioralDescription(β)
the component respectively
• a set of events that are allowed to occur during the
execution of the component
Attack Plan ((cid:15)): The attack plan (cid:15) consists of a description
• a set of conditional probabilities between the possi- of potential attack models (δ) and the rules (ρ) that imply a
ble modes of the resources and the possible modes
certain attack. Syntactically, an attack plan includes
ofthecomponentandasetofknownvulnerabilities
occurred to the component • a set of types of attacks that are being anticipated and
the prior probability of each of them,
2) and a structural model that is a set of sub-components
some of that might be splits or joins of • a set of effects such that how each attack type can effect
mode (normal/compromised) of a resource and
• data-flows between linking ports of the sub- • a set of rules expressing the conditional probabilities
components and
between attack types and resource modes.
• control-flow links between cases of a branch and
a component that will be enabled if that branch is The syntactic domains of δ and ρ are defined in Figure 6
taken resp.
In principle, attack plans are hypothetical attacks based
The syntactical domain α is defined in Figure 4.
on rules that describe different ways of compromising a
The elements of α are informally discussed above. Further
component. The monitor exploits such plans to match at run-
details of α are out of the scope of this paper.
timeanddetectanysuchattack,thusmakingthemonitormore
Behavioral Description (β): The β describes normal (and
robust.
optionallyvariouscompromised)behaviorofacomponentthat
includes
• set of inputs and outputs respectively, δ ::= define-attack-model AtkModName
• allowable events during the execution in that mode and :attack-types (set(AtkType))
• preconditionsontheinputs,post-conditionsandinvariant, :vulnerability-mapping (set(AtkVulnrabltyMap))
all of that are first order logical expressions.
ρ ::= defrule AtkRulName (:forward)
The complete syntax of β is defined in Figure 5. if set(AtkCond) then set(AtkCons)
1The”component”and”module/sub-module”areusedinterchangeably. Fig.6. SyntacticDomainsofAttackModel(δ)andRule(ρ)
B. Example controller will continuously issue commands to the pump to
To provide an intuitive grounding for these ideas we will addwatertothetank,eventuallycausingthetanktooverflow.
consider an example of a simple ICS and of its model in the In the second case, a change in value of one of the controller
specification language. The system consists of a water tank, parameterswillcausethecontrollertocalculateinanincorrect
a level sensor and a pump that is capable of either filling or command. This can have a variety of effects, depending on
draining the tank. The tank has a natural leakage rate that is which parameters are changed.
Monitoring of such a system requires its behavioral spec-
proportionaltotheheightofthewatercolumninthetank.The
ification as shown in Figure 9 (b). The actual system is a
tank is controlled by a PID controller; this is a computational
cyber-physical system, containing both physical components
device running a standard (PID) control algorithm that has a
(i.e. the tank, the pump) and computational components (i.e.
simple structure:
The algorithm has two inputs: The set-point, i.e. the water thecontrollerandthesensor).Themonitormodelparallelsthis
level that the tank should maintain and the sensor value structure; it contains computational models of the controller
andthesensoraswellasacomputationalmodelofthephysical
provide by the level sensor. It has a simple output, the
command.Thealgorithmperformsthefollowingcomputations plant.Thislatermodelperformsanumericalintegrationofthe
basedonthethreeparametersnotatedasKp,KiandKdthatare differential equations describing the physical plant’s behavior,
e.g. the dynamics of the pump. The application specification
used as scaling weights in the algorithm as shown in Figure 9
of the controller, essentially mirrors the structure of the
(a).
algorithm:Thereisacomponentthatcalculatestheerrorterm,
1) Calculate the error, the difference between the set-point
data-flow links that connect the error term to each of three
and the sensor value
parallel steps that calculate the Proporational, Integral and
2) Calculate three terms:
Derivative terms, finally there is the summation component
a) The Proportional term; this is just the error
that adds the three terms, calculating the command output.
weighted by Kp.
The structural model of the controller is shown diagram-
b) The Integral term; this is a running sum of the
matically in Figure 9 (b) (N and C refers to normal and
errors seen so far, weighted by Ki.
compromised behavior and A refers to possible attacks). The
c) TheDerivativeterm;thisisalocalestimateofrate
models for the components of the controller are reasonably
of change of the sensor value, weighted by Kd.
straightforward.Forexample,thenormalbehavioralmodelfor
3) Calculate the sum of the three terms.
the Kd calculation states that the output of the component is
4) The value of the sum is the command output of the
the derivative of the error, weighted by Kd. This is expressed
algorithm.
as a post-condition, as shown in Figure 8.
The command output of the algorithm is sent to the pump, Notice that what the controller calculates is a discrete
controlling the rate at which the pump either adds or removes approximation of the derivative of the error term, which is
water. The algorithm is “tuned” by the choice of the three calculatedusingthepreviousandcurrentversionsoftheerror.
parameters Kp, Ki and Kd; when well tuned the system The value of the error term is conceptually a state variable
responds quickly to deviations from the set-point with little that is updated between successive iterations of the controller
over-shoot and very small oscillations around the set-point. computation.Inourspecificationlanguage,however,wemodel
Finally, we note that the level sensor can be viewed as these as extra inputs and data flows (as we do also for control
(and often is) a computational and communication device that algorithm parameters such as Kd). For simplicity, we have
estimatestheactualheightofthewatertankandcommunicates omitted these extra items from the diagram in Figure 9.
the estimated height back to the controller. The compromised behavioral model states that any other
There are two standard categories of attacks on such a behaviorisacceptable;itdoessobystatingnopost-conditions.
system: The run-time behavior of the monitor will depend on the
• False Data Injection Attacks. These are attacks on strength of the post-conditions; if these are too weak, the
the sensor and its communication channel, such that the monitor may allow undesired behaviors..
controllerreceivesavaluethatisdifferentfromtheactual
C. Formal Semantics
level of the tank.
In this section, we first give the definition of semantic
• Controller Attacks. These are penetrations to the com-
algebras, then discuss informal description and the formal
puter running the control algorithm. For our purposes it
denotational semantics of the core construct (i.e. behavioral
is only necessary to consider attacks that overwrite the
description) of the specification language.
value of one of Kp, Ki, or Kd. Any such attack, will
1) SemanticAlgebras: Semanticdomains1 2 representaset
cause the controller to calculate an incorrect command.
of elements that share some common properties. A semantic
In either case, the end result is that the level in the water
tank will not be correctly maintained. In the first case, the 1Thesedomainsarecommontoaprogramtobemonitored,itsspecification
controller calculates a correct response to the distorted sensor languageandthemonitor.
2We use subscript s and r to specify domains for specification and
value.Forexample,supposethattheattackerissystematically
program’sruntimeresp.,e.g.States =specificationstate,Stater =program’s
distorting the sensor value to be too low. In that case, the runtimestate,State=combinedmonitorstate.
domain is accompanied by a set of operations as functions
(define-component-type controller-step
over the domain. A domain and its operations together form
:entry-events (controller-step)
:exit-events (controller-step) a semantic algebra [8]. The domains of our language are
:allowable-events (update-state accum-error) similar to the domains of any classical programming/speci-
:inputs (set-point sens-val) fication language (e.g. Java, JML, ACSL). In the following
:outputs (com)
we declare/define only important semantic domains and their
operations.
:components
((err-comp :type err-comp :models (normal)) Environment Values: The domain Environment holds the
(comp-der :type comp-der :models (normal)) ... ) environment values of the language and is formalized as a
tuple of domains Context (which is a mapping of identifiers
:dataflows
totheenvironmentvalues)andSpace(thatmodelsthememory
((set-point controller-step set-point err-comp)
space). The Environment domain includes interesting values,
(the-error err-comp the-error comp-der)...))
e.g. component, attack plan and resource. Here resource can
be binary code in memory, files and ports etc.
Fig.7. DecompositionoftheModulecontroller-step
Domain: Environment
Environment := Context × Space
Context := Identifier → EnvValue
(define-component-type comp-der
EnvValue := Variable + Component + AtkPlan + Resource +
:entry-events (compute-derivative)
...
:exit-events (compute-derivative)
:inputs (the-error old-error kd time-step) Space := P(Variable)
:outputs (der-term) Variable := n, where n ∈ N represents locations
:behavior-modes (normal compromised) ) The domain Environment supports typical selection, update
and equality operations over its values.
(defbehavior-model (comp-der normal)
State Values: The domain State represents the execution of
:inputs (the-error the-old-error kd time-step)
:outputs (der-term) aprogram.AStoreisimportantelementofthestateandholds
:prerequisites ([data-type-of the-error number])for every Variable a Value. The Data of the state is a tuple
:post-conditions of a Flag that represents the current status of the state and a
([and [data-type-of der-term number]
Mode to represent the current mode of execution of the state
[equal der-term
of a component.
(*kd(/(- new-error old-error) time-step))]]))
Domain: State
(defbehavior-model (comp-der compromised) State := Store × Data
:inputs (the-error the-old-error kd time-step) Store := Variable → Value
:outputs (der-term)
Data := Flag × Mode
:prerequisites ()
Flag := {running, ready, completed}
:post-conditions ())
Mode := {normal, compromised}
The domain State has typical operations, e.g. read and
Fig.8. NormalandCompromisedBehaviorofcomp-der(kd)
write/updateofvalues,checkingequalityofFlagandModein
a given state, and setting a certain Flag and Mode of a given
state.
Semantic Values: Value is a disjunctive union domain and
note that the domain Value is a recursive domain.
Domain: Value
Value := ObsEvent + RTEvent + Component + AtkPlan + ... + Value∗
The domain includes semantic values of observable event, a
run-time event and attack plan etc. The equality of the given
two semantic values can be evaluated.
Component Values: The Component formalizes the seman-
tic model of a component as a predicate over decomposition,
normal and compromised behavior and a pre-state and a post-
state of the component’s execution respectively. The predicate
is formalized as follows:
(a)
Application (b) Specification Component = P(SBehavior × NBehavior × CBehavior ×
State × State 3)
⊥
Fig.9. AControllerApplicationanditsModel
3State⊥ =State∪{⊥}
where t∈{ENTRY,EXIT,ALLOWABLE,NONE}
SBehavior := P(Value∗ × Value∗ × Value∗ × State × State⊥) typeOf(oe,c)→t
NBehavior = CBehavior := P(Value∗ × Value∗ × State × State )
⊥
Furthermore, SBehavior is defined as a predicate over sets of dataArrives(c,s(i),s(cid:48)(i))
input and output values, set of allowable values, a pre-state comp(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),False,0) s(i+1)=s(i)
and a post-state of the behavior. Also, normal behavior and s(cid:48)(i+1)=s(i) setMode(s(cid:48)(i+1),”compromised”)
compromised behavior (NBehavior and CBehavior) are also run(ENTRY,c,e,e(cid:48),s,s(cid:48),i,False)
defined as predicates over sets of input and output values, a
pre-state and a corresponding post-state respectively. dataArrives(c,s(i),s(cid:48)(i))
Attack Values: The semantics domain AtkModel formalizes comp(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),True,0)
the attack model and is defined as a predicate over an setFlag(s(cid:48)(i+1),”running”) s(i+1)=s(cid:48)(i)
attack name, probability of the attack and the corresponding e(i+1)=e(cid:48)(i) cseq =components(c)
vulnerabilitycausingtheattack;theattackmodelisformulated mon(cseq,s(i+1),s(cid:48)(i+1),e(i+1),e(cid:48)(i+1))
as follows:
run(ENTRY,c,e,e(cid:48),s,s(cid:48),i,True)
AtkModel := P(Identifier × FVal × Vulnerability)
2) SignaturesofValuationFunctions: Avaluationfunction dataArrives(c,s(i),s(cid:48)(i)) setFlag(s(cid:48)(i+1),”completed”)
defines a mapping of a language’s abstract syntax structures comp(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),b,1)
to its corresponding meanings (semantic algebras) [8]. The s(i+1)=s(cid:48)(i) s(cid:48)(i+1)=s(cid:48)(i)
valuationfunctionoperatesonasyntacticconstructandreturns [b=False⇒setMode(s(cid:48)(i+1),”compromised”)]
a function from the environment to a semantic domain. [b=True⇒setMode(s(cid:48)(i+1),”normal”)]
Wedefinetheresultofthevaluationfunctionasapredicate, run(EXIT,c,e,e(cid:48),s,s(cid:48),i,b)
e.g. the behavioral relation (BehRelation) is defined as a
predicate over an environment, a pre- and a post-state and inv(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),b )
1
is defined as follows: noatk(c,e(i),b ) s(i+1)=s(cid:48)(i) e(i+1)=e(cid:48)(i+1)
1
BehRelation := P(Environment × State × State⊥) run(ALLOWABLE,c,e,e(cid:48),s,s(cid:48),i,b1∧b2)
The valuation functions for the abstract syntax domains of
specification (ω), behavioral description (β) and attack plans setMode(s(cid:48)(i),”compromised”
((cid:15)) have same signatures. For example, a valuation function s(i+1)=s(cid:48)(i) e(cid:48)(i+1)=e(i+1)
signature for β is defined as follows: run(NONE,c,e,e(cid:48),s,s(cid:48),i,Flase)
[[β]]: Environment → BehRelation
nbeh=(cid:104)inseq,outseq,s,s(cid:48)(cid:105)
Based on the above relation and the auxiliary semantic
c(cid:48) =(cid:104)c[1],nbeh,c[3],s,s(cid:48)(cid:105)
inference rules (see Figure 10), we define valuation functions
for β and (cid:15) in the following subsection. update(c,e1[id(c)(cid:55)→c(cid:48)],s,s(cid:48),inseq,outseq,True)
3) Definition of Valuation Functions: Semantically, normal
and compromised behavioral models results in modifying the cbeh=(cid:104)inseq,outseq,s,s(cid:48)(cid:105) c(cid:48) =(cid:104)c[1],c[2],cbeh,s,s(cid:48)(cid:105)
corresponding elements of the environment value Component update(c,e [id(c)(cid:55)→c(cid:48)],s,s(cid:48),inseq,outseq,False)
1
as defined below:
[[β]](e)(e’, s, s’) ⇔ a=(cid:104)aseq,apseq,vnseq(cid:105)
LET c ∈ Component: [[CompName]](e)(s, s’, inValue(c)) IN
atk(atkName,e,e[atkName(cid:55)→a],aseq,apseq,vnseq)
∀ e ∈ Environment, nseq ∈ set(EvntName), b , b : B,
1 1 2
eseq ∈ ObsEvent*, iseq, oseq ∈ Value∗:
b=[∀at:AtkName:at=context(e)(AtkName)⇒notcomp(c,at)]
[[set(ObjName )]](e)(s, iseq) ∧ [[set(BehCond )]](e) (s) ∧
1 1
noatk(c, e, b ) ∧ [[set(Evnt)]](e) (e’, s, s’, nseq, eseq) ∧ noatk(c,e,b)
1
[[set(ObjName )]](e’)(s’, oseq) ∧[[set(BehCond )]](e’)(s,s’)∧
2 2
[[set(BehCond )]](e’) (s, s’) ∧ noatk(c, e’, b ) inv(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),b )
3 2 1
⇒ b =[x=0⇒precond(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),True)]
2
LET v = b ∧ b ∧ eqMode(s’, ”normal”) IN b =[x=1⇒postcond(c,e(i),e(cid:48)(i),s(i),s(cid:48)(i),True)]
1 2 3
update(c, e’, s, s’, iseq, oseq, v) noatk(c,e(i),b )
4
where update is an auxiliary semantic rule as shown in comp(c,s,s(cid:48),e,e(cid:48),b1∧b2∧b3∧b4,x)
Figure 10.
In detail, if the semantics of β in an environment e yields ∃rte arrives(rte,s) monitors(i+1,rte,c,e,e(cid:48)(cid:48),s,s(cid:48)(cid:48))
environment e(cid:48) and transforms a pre-state s into a post-state mon(cseq,s(cid:48)(cid:48),s(cid:48),e(cid:48)(cid:48),e(cid:48),s(cid:48)(cid:48),s(cid:48),i)
s(cid:48) then mon(c;cseq,s,s(cid:48),e,e(cid:48),s,s(cid:48),i)
Fig.10. AuxiliarySemanticInferenceRules
• the evaluation of inputs set(ObjName1) yields a set of the data and if they succeed, it transforms the state of the
values iseq in environment e and state s such that the component into “ready” mode. Should the conditions fail, it
pre-conditions set(BehCond ) hold in e and s and the raises a flag.
1
component c has no potential threat (see rule noatk) After the above startup, the execution monitor starts mon-
and itoring the arrival of every observation (run-time event) as
• the evaluation of allowable events results in environment follows:
e(cid:48) and given post-state s(cid:48) with some auxiliary sets nseq 1) If the event is a “method entry”, then the execution
and eseq and monitor checks if this is one of the “entry events”
• the evaluation of outputs set(ObjName2) yields a set of the component in the “ready” state; if so, then
of values oseq in e(cid:48) and s(cid:48) such that post-conditions after receiving the data, the respective preconditions,
set(BehCond ) hold in e , s and s(cid:48) and invariant and absence of attack plans are checked; if
2 1
• the invariant set(BehCond2) holds in e(cid:48), s and s(cid:48), and they succeed, then the data is applied on the input port
the component c has no threat (noatk), finally the of the component and the mode of the execution state
environment e(cid:48) can be constructed as follows is changed to “running”.
– if the post-state is “normal” then e(cid:48) is an update 2) If the event is a “method exit”, then the execution
to the normal behavior “nbeh” of the component monitor checks if this is one of the “exit events” of the
“CompName” component in the “running” state; if so, it changes its
– otherwise e(cid:48) is an update to the compromised be- state into “completed” mode and collects the data from
havior “cbeh” of the component as shown in the the output port of the component and checks for the
corresponding inference rules of update. corresponding postconditions, invariant and absence of
Moreover, the valuation function for attack plan is defined as: attack plans. Should the checks fail, the monitor raises
an alarm.
[[δ]](e)(e’, s, s’) ⇔
3) If the event is one of the “allowable events” of the
∀ s” ∈ State, aseq, aseq’, vnseq ∈ ISeq, apseq ∈ Value∗:
component,ifinvariantholdsandthereisnoattackplan
[[set(AtkType)]](e)(s, inState (s”), aseq, apseq) ∧
⊥ then it continues execution and finally
[[set(AtkVulnrabltyMap)]](e) (s”, s’, aseq’, vnseq) ∧
4) otherwise, if the event is an none of the above events,
atk(AtkModName, e, e’, aseq, apseq, vnseq)
then the monitor raises an alarm.
In detail, the semantics of the domain “δ” updates the
A. Formal Semantics
environment e with a semantic value of AtkPlan such that
Based on the aforementioned description of the execution
if
monitor,wehaveformalizedthedenotationalsemanticsofthe
• in a given e and s, the evaluation of “set(AtkType)”
monitor by a relation monitor that is declare and defined as
yields post-state s(cid:48)(cid:48), a set of attack types aseq and a set
follows:
of values (conditional probabilities) apseq and also
• in given e and s, the evaluation of monitor ⊆ AppImpl × AppSpec
“set(AtkVulnrabltyMap)” yields post-state s(cid:48), a → Environment → State × State⊥
set of attack types aseq(cid:48) and a set of vulnerabilities monitor(κ, ω)(e)(s, s’) ⇔
vnseq, then ∀ c ∈ Component, t, t’ ∈ States, d, d’ ∈ Environments, rte ∈ RTEvent:
• the environment e(cid:48) is an update of environment e with [[ω]](d)(d’, t, t’) ∧ [[κ]](er)(er’, s, s’) ∧ setFlag(s, “running”) ∧
the semantic value AtkPlan, which is a triple of (a) a set eqMode(s, ”normal”) ∧ arrives(rte, s) ∧ equals(s, t) ∧ equals(er, d)
of attack types (b) a set of corresponding probabilities ⇒
and (c) a set of vulnerabilities causing the attack types, ∀ p, p’ ∈ Environment*, m, n ∈ State*:
respectively. equals(m(0), s) ∧ equals(p(0), er) ∧
∃ k ∈ N:
IV. SECURITYMONITOR ( ∀ i ∈ N : monitors(i, rte, c, p, p’, m, n) ∧ equals(s’, n(k)) ) ∧
k
Based on [3], in this section we discuss the informal
[( eqMode(n(k), “normal”) ∨ eqMode(n(k), “compromised”)] ∧
behavior of our run-time security monitor whose main goal
IF eqMode(n(k), “normal”) THEN
is to check consistency between a program’s run-time ob-
eqFlag(n(k), “completed”) ∧ equals(s’, t’)
servations and its specification-based predictions and to only
ELSE ¬ equals(s’, t’)
raise a flag if any inconsistency is identified. In detail, when
the application implementation starts execution, a “startup” In detail, the predicate says that if we execute specification
event is generated and dispatched to the top level component (ω) in an arbitrary safe pre-state (s) and environment (d)
of the system, which transforms the execution state of the and execute program (κ) in an arbitrary pre-state (t s.t. s
component into “running” mode. The component instantiates equals t) and environment (er s.t. er equals d) then there is a
its subnetwork (i.e. sub-components) and propagates the data finite natural number (k) at which monitor can be observed
along its data-links by enabling the corresponding control- such that for all iterations until k, the monitor continuous
links (if involved). When the data arrives on the input port operation. However, at iteration k, either the monitor is in a
of the component, the monitor checks if it is complete; if so, ”normal” mode or in a ”compromised” mode. If the mode is
the monitor checks the preconditions of the component for ”normal”, then the component under monitoring has finished
itsjobsafelyandthepost-stateoftheprogramexecution(t’)is All of the above choices are modeled by the corresponding
equaltopost-state(t)ofthespecificationexecution,otherwise semantic inference rule of run, see Figure 10.
component is compromised and thus the program execution
state(s’)andspecificationexecutionstate(t’)areinconsistent. B. Overview of the Soundness
The core semantics of monitor is captured by an auxiliary
The intent of soundness statement is to articulate whether
predicate monitors that is defined as a relation on
thesystem’sbehaviorisconsistentwiththebehavioralspecifi-
• the number of observation i w.r.t. of a component, cation.Essentially,thegoalhereistoshowtheabsenceoffalse
• an observation (run-time event) rte, component c being negativealarmsuchthatwheneverthesecuritymonitoralarms
observed, there is indeed a semantic inconsistency between post-state
• sets of pre- and post-environments e and e(cid:48) resp. and of the program execution and post-state of the specification
• sets of pre- and post-states s and s(cid:48) respectively. execution. The soundness theorem is stated as follows:
The predicate monitors is formalized as follows:
Theorem 1 (Soundness of security monitor). The result of
monitors ⊆ N × RTEvent × Component the security monitor is sound for any execution of the target
× Environment∗ × Environment∗ systemanditsspecification,iff,thespecificationisconsistent4
× State∗ × State∗ withtheprogramandtheprogramexecutesinasafepre-state
⊥
monitors(i, [[rte]], [[c]], e, e’, s, s’) ⇔ and in an environment that is consistent with the environment
eqMode(s(i), ”completed”) of the specification, then
∨ • for the pre-state of the program, there is an equivalent
[ ( eqMode(s(i), “running”) ∨ eqMode(s(i), “ready”) ) ∧ safepre-stateforwhichthespecificationcanbeexecuted
¬ eqMode(s(i), ”compromised”) ∧ [[c]](e(i))(e’(i), s(i), s’(i)) ∧ and the monitor can be observed and
∃ oe ∈ ObEvent: equals(rte, store([[name(rte)]])(e(i))) ∧ • if we execute the specification in an equivalent safe pre-
run(type(oe, c), c, e, e’, s, s’, i, eqMode(s’, ”normal”))) ] stateandobservethemonitoratanyarbitrary(combined)
post-state, then
In detail, the predicate monitors is defined such that, at any
arbitrary observation either the execution is completed and – either there is no alarm, and then the post-state is
returns or the current execution state s(i) of component c is safe and the program execution (post-state) is se-
“ready” or “running” and the current execution state is safe manticallyconsistentwiththespecificationexecution
andbehaviorofthecomponentchasbeenevaluatedandthere (post-state)
isarun-timeeventoethatwewanttoobserve(andthusequals – or there is an alarm, and then the post-state is
anobservationrte)andthenanyofthefollowingcanhappen: compromisedandtheprogramexecution(post-state)
and the specification execution (post-state) are se-
• either the prediction resp. observation is an entry event
mantically inconsistent.
of the component c, then it waits until the complete data
for c arrives, if so, then Formally, soundness theorem has the following signatures
– eitherthepreconditionsandtheinvariantof“normal” and definition.
behavior of the component hold and there is no
Soundness ad ⊆ P(AppImpl × AppSpec × Bool)
potential attack for the component (as modeled by
Soundness ad(κ, ω, b) ⇔
semantic rule comp in Figure 10); if so, then the
∀ e ∈ Environment , e , e ’ ∈ Environment , s, s’ ∈ State :
subnetwork of the component is initiated and the s s r r r r
consistent(e , e ) ∧ consistent(κ, ω) ∧
sub-components in the subnetwork are monitored s r
[[κ]](e )(e ’, s, s’) ∧ eqMode(s, ”normal”)
iteratively with the corresponding arrival of the ob- r r
⇒
servation
∃ t, t’ ∈ State , e ’ ∈ Environment :
– or the preconditions and the invariant of “compro- s s s
equals(s, t) ∧ [[ω]](e )(e ’, t, t’) ∧ monitor(κ, ω)(e ;e )(s;t, s’;t’) ∧
mised” behavior of the component hold or some s s r s
∀ t, t’ ∈ State , e ’ ∈ Environment :
attackplanisdetectedforthecomponent,inthiscase s s s
equals(s, t) ∧ [[ω]](e )(e ’, t, t’) ∧ monitor(κ, ω)(e ;e )(s;t, s’;t’)
the state is marked to “compromised” and returns s s r s
⇒
• or the observation is an exit event and after the arrival LET b = eqMode(s’, ”normal”) IN
of complete data, the post-conditions and the invariant
IF b = True THEN equals(s’, t’) ELSE ¬ equals(s’, t’) (G)
hold and if there is no potential threat detected, then the
resulting state is marked as “completed” In detail, the soundness statement says that, if
• or the observation is an allowable event, the invariant 1) aspecificationenvironment(e )isconsistentwitharun-
s
holds and there is no threat for c, then the c continues time environment (e ) and
r
the execution 2) a target system (κ) is consistent with its specification
• ortheobservationisanunexpectedevent(i.e.noneofthe (ω) and
above holds), then the state is marked as “compromised”
and returns. 4Seedefinitionofthecorrespondingpredicateconsistentin??.
3) in a given run-time environment (e ), execution of the monitor(κ, η)(e ;e )(s;t, s’;t’)
r r s
system (κ) transforms pre-state (s) into a post-state (s’) ⇒
and LET b = eqMode(s’, ”normal”) IN
4) thepre-state(s)issafe,i.e.thestateisin”normal”mode, IF b = True THEN equals(s’, t’)
then ELSE ¬ equals(s’, t’) (G-1)
• there is such pre- and post-states (t and t’ respectively) Here, we have two syntactic cases for η but we will show
andenvironment(es’)ofthespecificationexecutionsuch only one case in the following subsection.
that in a given specification environment (es), execution 2) Case when η = β: We can re-write (G-1) as
ofthespecification(ω)transformspre-state(t)intoapost-
Soundness ad(κ, β, b) ⇔
state (t’) and
∀ e ∈ Environment , e , e ’ ∈ Environment , s, s’ ∈ State :
• the pre-states s and t are equal and monitoring of the s s r r r r
consistent(e , e ) ∧ consistent(κ, β) ∧
system (κ) transforms combined pre-state (s;t) into a s r
[[κ]](e )(e ’, s, s’) ∧ eqMode(s, ”normal”)
combined post-state (s’;t’) and if r r
⇒
• inagivenspecificationenvironment(es),executionofthe
∃ t, t’ ∈ State , e ’ ∈ Environment :
specification (ω) transforms pre-state (t) into a post-state s s s
equals(s, t) ∧ [[β]](e )(e ’, t, t’) ∧
(t’) and s s
monitor(κ, β)(e ;e )(s;t, s’;t’) ∧
• the pre-states s and t are equal and monitoring of the r s
∀ t, t’ ∈ State , e ’ ∈ Environment :
system (κ) transforms pre-state (s) into a post-state (s’) s s s
equals(s, t) ∧ [[β]](e )(e ’, t, t’) ∧
then s s
monitor(κ, β)(e ;e )(s;t, s’;t’)
– either there is no alarm (b is True) and then the r s
⇒
post-state s’ of program execution is safe and the
LET b = eqMode(s’, ”normal”) IN
resulting states s’ and t’ are semantically equal
IF b = True THEN equals(s’, t’)
– orthesecuritymonitoralarms(bisFalse)andthen
ELSE ¬ equals(s’, t’) (F.1)
the post-state s’ of program execution is compro-
mised and the resulting states s’ and t’ are semanti- From (F.1), we know
cally not equal.
• consistent(es, er) (1)
In the following section we present proof of the soundness • consistent(κ, β) (2)
statement. • [[κ]](er)(er’, s, s’) (3)
• eqMode(s, ”normal”) (4)
C. Proof of the Soundness
We show
The proof is essentially a structural induction on the el-
ements of the specification (ω) of the system (κ). We have • ∃ t, t’ ∈ States, es’ ∈ Environments: equals(s, t) ∧
[[β]](e )(e ’, t, t’) ∧ monitor(κ, β)(e ;e )(s;t, s’;t’) (G-1.1)
proved only interesting case β of the specification to show s s r s
that the proof works in principle. However, the proof of the • ∀ t, t’ ∈ States, es’ ∈ Environments: equals(s, t) ∧
[[β]](e )(e ’, t, t’) ∧ monitor(κ, β)(e ;e )(s;t, s’;t’)
remaining parts can easily be rehearsed following the similar s s r s
⇒
approach.
LET b = eqMode(s’, ”normal”) IN
Theproofisbasedoncertainlemmas(seesubsectionIV-F),
IF b = True THEN equals(s’, t’)
which are about the relations between different elements of
ELSE ¬ equals(s’, t’) (G-1.2)
the system and its specification (being at different levels
of abstraction). These lemmas and relations can be proved Goal:G-1.1: Wesplitthegoal(G-1.1)intofollowingthree
based on the defined auxiliary functions and predicates (see sub-goals:
subsection IV-E) that are based on the method suggested by equals(s, t) (G-1.1.1)
Hoare [1]. [[β]](es)(es’, t, t’) (G-1.1.2)
In the following, we start proof with induction on η. monitor(κ, β)(er;es)(er’;es’, s;t, s’;t’) (G-1.1.3)
1) Case (η): We can re-write (G) as Sub-Goal: G-1.1.1: We define
Soundness ad(κ, η, b) ⇔ t := constructs(s, β) (5)
∀ e ∈ Environment , e , e ’ ∈ Environment , s, s’ ∈ State :
s s r r r r We instantiate Lemma (1) with s as s, t as t, ω as β to get
consistent(e , e ) ∧ consistent(κ, η) ∧
s r
[[κ]](e )(e ’, s, s’) ∧ eqMode(s, ”normal”) t := constructs(s, β) ⇒ equals(s, t) (I.1)
r r
⇒
The goal (G-1.1.1) follows from (I.1) and definition (5). (cid:3)
∃ t, t’ ∈ State , e ’ ∈ Environment :
s s s Sub-Goal: G-1.1.2: We expand definition (2) and get
equals(s, t) ∧ [[η]](e )(e ’, t, t’) ∧
s s
monitor(κ, η)(e ;e )(s;t, s’;t’) ∧ ∀ m, m’ ∈ State, n, n’ ∈ Environment:
r s
∀ t, t’ ∈ State , e ’ ∈ Environment : [[κ]](n)(n’, m, m’) ∧ eqMode(m, ”normal)
s s s
equals(s, t) ∧ [[η]](e )(e ’, t, t’) ∧ ⇒ [[β]](n)(n’, m, m’) (F.2)
s s