In this training submodule we outline the core workings of the MILS Adaptation System (for details please refer to the project deliverable D4.3 [1]) and we describe how to create the artifacts which are taken as input by the MILS Adaptation System. Specifically, we focus on the Adaptation Engine, the core component of the MILS Adaptation System.
4. MILS Adaptation Engine
List of Figures
1 Adaptation Plane architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Handling of alarms and commands by the Adaptation Engine . . . . . . . . . . . . . 4
3 Initial architectural configuration of the example model . . . . . . . . . . . . . . . . 5
Page iv Version 1.0
Confidentiality: Public Distribution
28 January 2019
5. MILS Adaptation Engine
Document Control
Version Status Date
0.1 Document outline 11 January 2019
0.4 Initial content 17 January 2019
0.8 Full content 25 January 2019
1.0 Final version 28 January 2019
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page v
6. MILS Adaptation Engine
1 Overview
In this training submodule we outline the core workings of the MILS Adaptation System (for details
please refer to the project deliverable D4.3 [1]) and we describe how to create the artifacts which are
taken as input by the MILS Adaptation System. Specifically, we focus on the Adaptation Engine, the
core component of the MILS Adaptation System.
The training submodule CITADEL Context Awareness describes the Context Awareness subcompo-
nent of the MILS Adaptation System, and the training module CITADEL Platform: Model-based
Adaptation describes how to start the MILS Adaptation System.
Following this document requires:
• a text editor, and
• the COMPASS 3 release for CITADEL.
2 Adaptation Engine overview
The MILS Adaptation system is implemented as a set of components, which together constitute
the Adaptation Plane. The main functionality of the Adaptation Plane (Fig. 1) is to take as input
alarms from the Monitoring Plane, compute the model of the next architectural configuration and
send it to the Configuration Plane. In addition, it sends status notifications to the operator console
from which it can also receive commands, and it sends the next architectural configuration to the
Certification Assurance Plane, requesting the assurance case update for the next configuration. An
optional Context Awareness component can be used in order to estimate the current execution context,
which is an additional source of information for an operator monitoring the system operation.
Adaptation Engine is the central component of the Adaptation Plane, implementing a rule-based
adaptation strategy. Evaluator Module is a helper component whose purpose is to perform model-
based reasoning in order to find the next configuration. In the following, we describe the interfaces
and the functionality of the Adaptation Engine.
2.1 Interfaces
The interfaces of the Adaptation Engine are as follows.
2.1.1 Interface with the Monitoring Plane
Adaptation Engine receives alarms from the Monitoring Plane. The alarms are specified in the system
model; at runtime this interface is fully automatic and allows no human interaction.
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 1
7. MILS Adaptation Engine
Monitoring
Plane
Configuration
Plane
MILS Console
Subsystem
Adaptation
Engine
Evaluator
Module
Adaptation Plane
alarms
commands
system
status
evaluation
requests
model of next
architectural
configuration
model of next
architectural
configuration
reconfiguration
status
Certification
Assurance Plane
Context
Awareness
current context
monitored data
context feedback
Figure 1: Adaptation Plane architecture
2.1.2 Interface with the MILS Console Subsystem
Adaptation Engine sends notifications about all events to the MILS Console Subsystem.
Adaptation Engine may receive commands from the MILS Console Subsystem. A command may be
either a reconfiguration request or a request to stop execution.
Reconfiguration request A reconfiguration request is a triplet containing the following comma-
separated elements:
• a requested reconfiguration action,
• a priority,
• a time limit,
where the priority and time limit are optional and can be omitted. The syntax and semantics of the
above three elements are described in Section 4. The reconfiguration request may be used by an
operator in order to manually bring the system to a desired architectural configuration.
Request to stop execution An operator can request immediate stopping of execution of the Adap-
tation Engine by sending it the command halt.
Page 2 Version 1.0
Confidentiality: Public Distribution
28 January 2019
8. MILS Adaptation Engine
2.1.3 Interface with the Configuration Plane
In order to request a reconfiguration, the Adaptation Engine sends to the Configuration Plane the syn-
thesized model of the next configuration of the system. The Configuration Plane responds by sending
the status (success or failure) of the attempted reconfiguration. This interface is fully automatic and
allows no human interaction.
2.1.4 Interface with the Certification Assurance Plane
The Adaptation Engine sends to the Certification Assurance Plane a model of the next architectural
configuration, in order to request an update of the assurance case. This interface is fully automatic
and allows no human interaction.
2.1.5 Interface with the Evaluator Module
In order to request the computation of the next architectural configuration, the Adaptation Engine
sends to the Evaluator Module a representation of the current architectural configuration in the form
of an assignment of values to parameters (see next subsection), a requested reconfiguration action,
and a time limit.
The Evaluator Module responds within the specified time limit by either sending an instantiated
model of the next configuration, or by sending a notification about the failure to compute the next
architectural configuration.
This interface is fully automatic and allows no human interaction.
2.2 Functionality
On startup, the Adaptation Engine loads the following artifacts:
• an initial architectural configuration of the system, specified by the initial assignment to the
parameters,
• a rule table which specifies the reconfiguration strategy that is to be implemented by the Adap-
tation Plane.
The Adaptation Engine is a simple state machine. Its state contains the current assignment to the
system parameters (which defines the current architectural configuration of the system) and other
elements such as the alarm and rule which are currently being processed, as well as the information
used for managing communication with the other components of the CITADEL Framework (such as
flags to denote whether currently there is ongoing computation by the Evaluator Module or reconfig-
uration by the Configuration Plane).
The main functionality of the Adaptation Engine is to listen for alarms incoming from the Monitoring
Plane, match received alarm with an entry in its rule table in order to trigger the appropriate recon-
figuration action, request (based on the selected action) from the Evaluator Module synthesis of the
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 3
9. MILS Adaptation Engine
model of the next architectural configuration, request (based on the synthesized model) from the Con-
figuration Plane the reconfiguration of the system, and request re-certification from the Certification
Assurance Plane.
In addition, the Adaptation Engine may receive reconfiguration commands from the operator via the
MILS Console System, which are handled analogously to the reconfiguration actions triggered by
the alarms.
Figure 2: Handling of alarms and commands by the Adaptation Engine
Figure 2 shows the algorithm used by the Adaptation Engine to handle incoming alarms and operator
commands. When an alarm is received by the Adaptation Engine, it is matched against the rules
in the rule table. If there is a matching rule, and its specified priority is higher than the currently
evaluating action, the rule is triggered and the reconfiguration action specified in the rule is evaluated.
Evaluation of the action involves requesting the evaluation from the Evaluator Module, which returns
(within the time limit specified in the rule) either a model of the next configuration of the system or
a failure status. If the evaluation succeeds, the Adaptation Engine requests the reconfiguration and
re-certification of the system, from the Configuration Plane and the Certification Assurance Plane,
respectively. In case the evaluation fails, its fallback rule (if any) is triggered. (Another possibility,
not shown in the figure, is that the evaluation may be cancelled if a higher priority rule is triggered
by another alarm or if a higher priority operator command is received concurrently with the current
evaluation.) In case of reconfiguration failure by the Configuration Plane, the Adaptation Engine
halts, stopping the MILS Adaptation System (reconfiguration failures are considered fatal because
they may leave the system in an inconsistent configuration). Commands received from the operator
are handled in the same manner, except that the priority, action and timeout are obtained from the
Page 4 Version 1.0
Confidentiality: Public Distribution
28 January 2019
10. MILS Adaptation Engine
command itself and not from a matching rule as in the case of an alarm. Another difference is that
for operator commands there are no fallback rules.
More information about the Adaptation Engine can be found in the project deliverable D4.3 [1].
3 Specifying the initial architectural configuration
In this section we specify an initial assignment of values to the system parameters. As the exam-
ple model, we use the load balancer model developed in the training module CITADEL Modeling,
Specification and Verification Tools, and whose listing can be found in Appendix A.1.
The initial assignment of values to the parameters, which specifies the initial architectural configu-
ration of the system, is a formula specifying the values of all parameters. The following is an initial
assignment for the running example, which specifies the configuration shown in Figure 3:
node_ids = {0, 1} and db_node_id = 0 and
user_ids = {0, 1, 2} and server_block_ids = {0, 1} and
server_block_redundant[0] = false and server_block_redundant[1] = true
Figure 3: Initial architectural configuration of the example model
In order to check that the specified initial architectural configuration corresponds to the intended one,
the tool instantiate.py can be used to instantiate the configuration from the system model and
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 5
11. MILS Adaptation Engine
a file containing the initial assignment to parameters. If these two artifacts are stored in the files
model.slim and assignment.txt, respectively, the model of the architectural configuration
corresponding to the assignment can be generated by invoking the tool instantiate.py:
compass3$ python scripts/instantiate.py model.slim
--assign assignment.txt
--- Instance of model.slim
[rest of output omitted]
Appendix A.3 contains the instantiated model of the initial architectural configuration of the example
model, obtained by invoking:
compass3$ python scripts/instantiate.py
/path/to/load_balancer_with_monitors.slim --assign
/path/to/load_balancer_with_monitors_assignment.txt
[output omitted]
For a video demonstration of the use of this tool, please refer to the training module CITADEL
Modeling, Specification and Verification Tools.
4 Specifying adaptation rule table
The adaptation rule table specifies the reconfiguration strategy implemented by the Adaptation En-
gine.
4.1 Rule table semantics
The rule table contains a sequence of rules, specified in the rows of the rule table. A rule which
specifies an alarm pattern can be triggered by an incoming alarm with the matching name, while a
rule which does not specify an alarm pattern is a fallback rule, and is automatically triggered when
the execution of the rule in the preceding row of the table fails. This results in the following simple
semantics: when an alarm is received, the matching rule in the rule table is triggered and its action is
evaluated. If the evaluation fails, the fallback rule (if any), specified in the next row of the rule table,
is triggered, evaluating its action. This process of falling down through the fallback rules in the rule
table is repeated until evaluation of some rule succeeds or there are no more fallback rules.
4.2 Reconfiguration rules
Each rule in the rule table contains five elements:
• a unique rule identifier (for example r2);
• (optional) an alarm pattern, consisting of the alarm name and identifiers to which the alarm
values are bound when the alarm is received (for example malicious_user(id)); rule
without an alarm pattern is a fallback rule (as explained above);
Page 6 Version 1.0
Confidentiality: Public Distribution
28 January 2019
12. MILS Adaptation Engine
• the reconfiguration action (for example remove_user[id]);
• (optional) an integer value specifying the rule priority (for example 0); default priority (if
omitted) is 0;
• (optional) a floating point value specifying the evaluation time limit in seconds (for example
60.0).
4.2.1 Alarms and alarm patterns
Alarms An alarm
alarm_name(val_1, ..., val_n)
received from the Monitoring Plane contains
• an alarm name alarm_name,
• a (possibly empty) list of alarm values val_1, ..., val_n.
The alarm name is an identifier, while the values can be identifiers, Booleans, integers or reals. An
example alarm is
malicious_user(7)
where the alarm name is malicious_user and there is one alarm value 7.
Alarm patterns An alarm pattern
alarm_pattern_name(arg_1, ..., arg_m)
specified in a rule contains
• an alarm pattern name alarm_pattern_name,
• a (possibly empty) list of arguments arg_1, ..., arg_m.
The alarm pattern name and its arguments are identifiers. An example alarm pattern is
malicious_user(user_id)
where the alarm pattern name is malicious_user and there is one argument user_id.
Matching of alarms and alarm patterns An alarm and an alarm pattern match if their names are
the same,
alarm_name = alarm_pattern_name
and if the number of their values and arguments is the same,
n = m .
Matching binds the names of the alarm pattern arguments to the corresponding alarm values. For
example, the above example alarm and alarm pattern match, resulting in the binding user_id → 7.
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 7
13. MILS Adaptation Engine
4.2.2 Reconfiguration actions
The reconfiguration action can be one of:
• a reconfiguration transition label, as specified in the system model with specified transition
arguments (for example, add_user[11]) or unspecified transition arguments (for example,
add_user[*]);
• one of the special reconfiguration actions
• search "<property>", specifying that the reasoning-based adaptation should be
performed: the MILS Adaptation System in this case automatically selects a reconfigura-
tion transition which leads to a configuration satisfying the optional specified property,
• ask, specifying that an engineer should be asked to provide the (values of parameters for
the) next architectural configuration,
• halt, specifying that the MILS Adaptation System should immediately halt.
Action halt is handled directly by the Adaptation Engine, while the rest are first evaluated by the
Evaluator Module as described previously.
4.3 Specifying the rule table
The file containing the rule table is a plain text file with one rule per line. The five elements in a rule
are separated by semicolons:
rule_id_1 ; alarm_pattern_1 ; reconf_action_1 ; priority_1 ; time_limit_1
rule_id_2 ; alarm_pattern_2 ; reconf_action_2 ; priority_2 ; time_limit_2
...
rule_id_n ; alarm_pattern_n ; reconf_action_n ; priority_n ; time_limit_n
In the following, we specify the rules for the example load balancer model (see Appendix A.1 and the
training module CITADEL Modeling, Specification and Verification Tools). The first rule implements
addition of a user when the alarm new_user() is received. The used action is add_user[*],
specifying addition to the system of a user with an unspecified index (the appropriate index will be
selected automatically by the Evaluator Module). The priority is set to 0, and the time limit is set to
0:
r1 ; new_user() ; add_user[*] ; 0 ; 0
The second rule implements removal of a user when its monitor detects malicious behaviour. Here
the value from the alarm (bound to identifier id when the alarm pattern in the rule is matched with
the alarm) is passed as the first argument to the reconfiguration action remove_user[id]:
r2 ; malicious_user(id) ; remove_user[id] ; 0 ; 0
The third and the fourth rule implement addition of a server block (with a redundant application
server) when server overload is detected: the third rule tries to apply the reconfiguration transition
add_server_block[*][true] and, if it fails, the fourth rule is executed, asking the engineer
to provide the next architectural configuration within 5 minutes (300 seconds). The priority of the
fallback rule is higher than that of the previous rule to reflect the increased criticality.
Page 8 Version 1.0
Confidentiality: Public Distribution
28 January 2019
14. MILS Adaptation Engine
r3 ; overload(load) ; add_server_block[*][true] ; 0 ; 0
r4 ; ; ask ; 1 ; 300
The next three rules implement replacement of a server block when one of the servers in it fails. If
the server block replacement specified in rule r5 fails, the engineer is asked by rule r6 to provide
the next architectural reconfiguration. If he is unable to do so, the next fallback rule r7 is executed
and the Adaptation System halts.
r5 ; server_failed(kind, id) ; replace_server_block[id][*] ; 0 ; 0
r6 ; ; ask ; 1 ;
r7 ; ; halt ; 2 ;
The last two rules implement migration of the database to the other node when the alarm
node_unhealthy() is received. If the migration fails, the Adaptation System halts.
r8 ; node_unhealthy() ; migrate_database ; 0 ; 0
r9 ; ; halt ; 1 ;
The complete rule table, with all of the above rules, can be found in Appendix A.4.
An explanation and a video demonstration of the use of the rule table and the initial assignment in
the start-up of the Adaptation Plane can be found in the training module CITADEL Platform: Model-
Based Adaptation.
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 9
15. MILS Adaptation Engine
References
[1] MILS Adaptation System. Technical Report D4.3, Version 1.0, CITADEL Project, May 2018. 1,
5
Page 10 Version 1.0
Confidentiality: Public Distribution
28 January 2019
16. MILS Adaptation Engine
A Example artifacts
A.1 Load Balancer Model
Content of the system model file load_balancer_with_monitors.slim:
package LoadBalancerModel
public
--- Abstract data types ---
data HTTP_Message
end HTTP_Message;
data implementation HTTP_Message.Data
end HTTP_Message.Data;
data SQL_Query
end SQL_Query;
data implementation SQL_Query.Data
end SQL_Query.Data;
--- Subject representing a user ---
subject User
features
get: out event data port HTTP_Message.Data;
end User;
subject implementation User.Imp
end User.Imp;
--- Subject representing a web server ---
subject WebServer
features
in_get: in event data port HTTP_Message.Data;
out_get: out event data port HTTP_Message.Data;
heartbeat: out event port;
end WebServer;
subject implementation WebServer.Imp
end WebServer.Imp;
--- Subject representing an application server ---
subject ApplicationServer
features
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 11
17. MILS Adaptation Engine
in_get: in event data port HTTP_Message.Data;
out_get: out event data port SQL_Query.Data;
heartbeat: out event port;
end ApplicationServer;
subject implementation ApplicationServer.Imp
end ApplicationServer.Imp;
--- Subject representing a database ---
subject Database
parameters
port_ids: set of index;
features
get1: set indexed by port_ids of in event data port SQL_Query;
get2: set indexed by port_ids of in event data port SQL_Query;
end Database;
subject implementation Database.Imp
end Database.Imp;
--- Subject representing a load balancer ---
subject LoadBalancer
parameters
port_ids: set of index;
features
in_get: in event data port HTTP_Message.Data;
out_get: set indexed by port_ids
of out event data port HTTP_Message.Data;
avg_load: out event data port real;
end LoadBalancer;
subject implementation LoadBalancer.Imp
end LoadBalancer.Imp;
--- System representing a load balancer monitor ---
system LoadMonitor
features
load_in: in event data port real;
overload: out event data port real {
Alarm => true;
AlarmArguments => "load_in";
MonitoringProperty =>
"always (last_data(load_in) < MaxLoad)";
};
Page 12 Version 1.0
Confidentiality: Public Distribution
28 January 2019
18. MILS Adaptation Engine
properties
FDIR => true;
end LoadMonitor;
system implementation LoadMonitor.Imp
end LoadMonitor.Imp;
--- Datatype for the alarm subject_failed ---
data ServerFailed
end ServerFailed;
data implementation ServerFailed.Data
subcomponents
sk: data enum(web_server, main_app_server,
redundant_app_server);
bi: data index;
end ServerFailed.Data;
--- System representing a heartbeat monitor ---
system HeartbeatMonitor
parameters
server_kind: enum(web_server, main_app_server,
redundant_app_server);
block_id: index;
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(server_kind, block_id)";
MonitoringProperty =>
"always (time_until(heartbeat_in) msec < HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor;
system implementation HeartbeatMonitor.Imp
end HeartbeatMonitor.Imp;
--- Parametrized architecture representing a server block ---
system ServerBlock
parameters
id: index;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 13
19. MILS Adaptation Engine
redundantAS: bool;
features
in_get: in event data port HTTP_Message.Data;
out_get1: out event data port SQL_Query.Data;
out_get2: out event data port SQL_Query.Data if redundantAS;
end ServerBlock;
system implementation ServerBlock.Imp
subcomponents
WS: subject WebServer.Imp;
WS_mon: system HeartbeatMonitor.Imp
where WS_mon.server_kind = web_server
and WS_mon.block_id = id;
AS1: subject ApplicationServer.Imp;
AS1_mon: system HeartbeatMonitor.Imp
where AS1_mon.server_kind = main_app_server
and AS1_mon.block_id = id;
AS2: subject ApplicationServer.Imp if redundantAS;
AS2_mon: system HeartbeatMonitor.Imp
where AS2_mon.server_kind = redundant_app_server
and AS2_mon.block_id = id
if redundantAS;
connections
port in_get -> WS.in_get;
port WS.out_get -> AS1.in_get;
port WS.out_get -> AS2.in_get if redundantAS;
port WS.heartbeat -> WS_mon.heartbeat_in;
port AS1.out_get -> out_get1;
port AS1.heartbeat -> AS1_mon.heartbeat_in;
port AS2.out_get -> out_get2 if redundantAS;
port AS2.heartbeat -> AS2_mon.heartbeat_in if redundantAS;
end ServerBlock.Imp;
--- System representing a user anomaly monitor ---
system UserMonitor
parameters
user_id: index;
features
user_out: in event data port HTTP_Message.Data;
malicious_user: out event data port index {
Alarm => true;
AlarmArguments => "user_id";
MonitoringProperty => "never Malicious(last_data(user_out))";
};
properties
FDIR => true;
Page 14 Version 1.0
Confidentiality: Public Distribution
28 January 2019
20. MILS Adaptation Engine
end UserMonitor;
system implementation UserMonitor.Imp
end UserMonitor.Imp;
--- System representing a monitor for incoming users ---
system IncomingMonitor
features
new_user: out event port {
Alarm => true;
};
properties
FDIR => true;
end IncomingMonitor;
system implementation IncomingMonitor.Imp
end IncomingMonitor.Imp;
--- Node representing a hardware node ---
node Node
features
healthy: out event data port bool;
end Node;
node implementation Node.Imp
end Node.Imp;
--- System representing a hardware node monitor ---
system NodeMonitor
features
healthy_in: in event data port bool;
node_unhealthy: out event port {
Alarm => true;
MonitoringProperty =>
"always (last_data(healthy_in) = true)";
};
properties
FDIR => true;
end NodeMonitor;
system implementation NodeMonitor.Imp
end NodeMonitor.Imp;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 15
21. MILS Adaptation Engine
--- Parametrized architecture representing the system ---
system System
parameters
user_ids: set of index;
server_block_ids: set of index;
server_block_redundant: set indexed by server_block_ids of bool;
node_ids: set of index;
db_node_id: index;
assumptions
size(server_block_ids) > 0;
db_node_id in node_ids;
end System;
system implementation System.Imp
subcomponents
users: set indexed by user_ids of subject User.Imp;
incoming_mon: system IncomingMonitor.Imp;
user_mons: set indexed by user_ids of system UserMonitor.Imp
where forall(i in user_ids, user_mons[i].user_id = i);
load_balancer: subject LoadBalancer.Imp
where load_balancer.port_ids = server_block_ids;
load_balancer_mon: system LoadMonitor.Imp;
server_blocks: set indexed by server_block_ids
of system ServerBlock.Imp
where forall(i in server_block_ids,
server_blocks[i].id = i and
server_blocks[i].redundantAS
= server_block_redundant[i]);
database: subject Database.Imp
{ DeployedOn => reference(nodes[db_node_id]); }
where database.port_ids = server_block_ids;
nodes: set indexed by node_ids of node Node.Imp;
db_node_mon: system NodeMonitor.Imp;
connections
port users[i].get -> load_balancer.in_get for i in user_ids;
port users[i].get -> user_mons[i].user_out for i in user_ids;
port load_balancer.out_get[i] -> server_blocks[i].in_get
for i in server_block_ids;
port load_balancer.avg_load -> load_balancer_mon.load_in;
port server_blocks[i].out_get1 -> database.get1[i]
for i in server_block_ids;
port server_blocks[i].out_get2 -> database.get2[i]
if server_block_redundant[i]
for i in server_block_ids;
port nodes[db_node_id].healthy -> db_node_mon.healthy_in;
end System.Imp;
Page 16 Version 1.0
Confidentiality: Public Distribution
28 January 2019
22. MILS Adaptation Engine
--- Configuration transition system ---
CTS SystemCTS
architecture
a: System.Imp where a.node_ids = {0, 1} and
size(a.user_ids) <= 100 and
size(a.server_block_ids) <= 10;
initial
a.user_ids = {0, 1, 2} and a.server_block_ids = {0, 1}
and a.server_block_redundant[0] = false
and a.server_block_redundant[1] = true
and a.node_ids = {0, 1} and a.db_node_id = 0;
transitions
add_user[id]: step(next(a.user_ids) = add(a.user_ids, {id}))
for id not in a.user_ids;
remove_user[id]: step(next(a.user_ids) =
remove(a.user_ids, {id}))
for id in a.user_ids;
add_server_block[id][red]:
step(next(a.server_block_ids) = add(a.server_block_ids, {id})
and next(a.server_block_redundant[id]) = red)
for id not in a.server_block_ids, red in bool;
remove_server_block[id]:
step(next(a.server_block_ids) =
remove(a.server_block_ids, {id}))
for id in a.server_block_ids;
replace_server_block[old_id][new_id]:
step(next(a.server_block_ids) =
add(remove(a.server_block_ids, {old_id}), {new_id})
and next(a.server_block_redundant[new_id]) =
a.server_block_redundant[old_id])
for old_id in a.server_block_ids,
new_id not in a.server_block_ids;
flip_redundancy[id]:
step(next(a.server_block_redundant[id]) =
not a.server_block_redundant[id])
for id in a.server_block_ids;
migrate_database:
step(next(a.db_node_id) = case a.db_node_id = 0 : 1
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 17
23. MILS Adaptation Engine
otherwise 0 end);
end SystemCTS;
properties
Constants => "Malicious: function HTTP_Message.Data -> bool;
HeartbeatTimeout: clock msec := 1 msec;
MaxLoad: real := 0.9;";
end LoadBalancerModel;
A.2 Initial assignment file
Content of the assignment file load_balancer_with_monitors_assignment.txt:
node_ids = {0, 1} and db_node_id = 0 and
user_ids = {0, 1, 2} and server_block_ids = {0, 1} and
server_block_redundant[0] = false and server_block_redundant[1] = true
A.3 Initial instance
Content of the model file load_balancer_with_monitors_instance.slim:
--- Instance of load_balancer_with_monitors.slim
--- Root implementation: LoadBalancerModel::System.Imp
--- Assignment: user_ids = {2, 0, 1} and server_block_ids = {0, 1} and
--- server_block_redundant[0] = false and
--- server_block_redundant[1] = true and
--- node_ids = {0, 1} and db_node_id = 0
package LoadBalancerModel
public
node Node
features
healthy: out event data port bool;
end Node;
subject ApplicationServer
features
heartbeat: out event port;
in_get: in event data port HTTP_Message.Data;
out_get: out event data port SQL_Query.Data;
end ApplicationServer;
subject Database__0
features
Page 18 Version 1.0
Confidentiality: Public Distribution
28 January 2019
24. MILS Adaptation Engine
get1__0: in event data port SQL_Query;
get1__1: in event data port SQL_Query;
get2__0: in event data port SQL_Query;
get2__1: in event data port SQL_Query;
end Database__0;
subject LoadBalancer__0
features
avg_load: out event data port real;
in_get: in event data port HTTP_Message.Data;
out_get__0: out event data port HTTP_Message.Data;
out_get__1: out event data port HTTP_Message.Data;
end LoadBalancer__0;
subject User
features
get: out event data port HTTP_Message.Data;
end User;
subject WebServer
features
heartbeat: out event port;
in_get: in event data port HTTP_Message.Data;
out_get: out event data port HTTP_Message.Data;
end WebServer;
system HeartbeatMonitor__0
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(main_app_server, 0)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__0;
system HeartbeatMonitor__1
features
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 19
25. MILS Adaptation Engine
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(web_server, 0)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__1;
system HeartbeatMonitor__2
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(main_app_server, 1)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__2;
system HeartbeatMonitor__3
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Alarm => true;
AlarmArguments => "(web_server, 1)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__3;
system HeartbeatMonitor__4
features
heartbeat_in: in event port;
server_failed: out event data port ServerFailed.Data {
Page 20 Version 1.0
Confidentiality: Public Distribution
28 January 2019
26. MILS Adaptation Engine
Alarm => true;
AlarmArguments => "(redundant_app_server, 1)";
MonitoringProperty =>
"always ((time_until(heartbeat_in)) msec
< HeartbeatTimeout)";
};
properties
FDIR => true;
end HeartbeatMonitor__4;
system IncomingMonitor
features
new_user: out event port { Alarm => true; };
properties
FDIR => true;
end IncomingMonitor;
system LoadMonitor
features
load_in: in event data port real;
overload: out event data port real {
Alarm => true;
AlarmArguments => "load_in";
MonitoringProperty =>
"always (last_data(load_in) < MaxLoad)";
};
properties
FDIR => true;
end LoadMonitor;
system NodeMonitor
features
healthy_in: in event data port bool;
node_unhealthy: out event port {
Alarm => true;
MonitoringProperty =>
"always (last_data(healthy_in) = true)";
};
properties
FDIR => true;
end NodeMonitor;
system ServerBlock__0
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 21
27. MILS Adaptation Engine
features
in_get: in event data port HTTP_Message.Data;
out_get1: out event data port SQL_Query.Data;
end ServerBlock__0;
system ServerBlock__1
features
in_get: in event data port HTTP_Message.Data;
out_get1: out event data port SQL_Query.Data;
out_get2: out event data port SQL_Query.Data;
end ServerBlock__1;
system System__0
end System__0;
system UserMonitor__0
features
malicious_user: out event data port int {
Alarm => true;
AlarmArguments => "0";
MonitoringProperty =>
"never (Malicious(last_data(user_out)))";
};
user_out: in event data port HTTP_Message.Data;
properties
FDIR => true;
end UserMonitor__0;
system UserMonitor__1
features
malicious_user: out event data port int {
Alarm => true;
AlarmArguments => "1";
MonitoringProperty =>
"never (Malicious(last_data(user_out)))";
};
user_out: in event data port HTTP_Message.Data;
properties
FDIR => true;
end UserMonitor__1;
system UserMonitor__2
features
Page 22 Version 1.0
Confidentiality: Public Distribution
28 January 2019
28. MILS Adaptation Engine
malicious_user: out event data port int {
Alarm => true;
AlarmArguments => "2";
MonitoringProperty =>
"never (Malicious(last_data(user_out)))";
};
user_out: in event data port HTTP_Message.Data;
properties
FDIR => true;
end UserMonitor__2;
node implementation Node.Imp__0
end Node.Imp__0;
subject implementation ApplicationServer.Imp__0
end ApplicationServer.Imp__0;
subject implementation Database__0.Imp__0
end Database__0.Imp__0;
subject implementation LoadBalancer__0.Imp__0
end LoadBalancer__0.Imp__0;
subject implementation User.Imp__0
end User.Imp__0;
subject implementation WebServer.Imp__0
end WebServer.Imp__0;
system implementation HeartbeatMonitor__0.Imp__0
end HeartbeatMonitor__0.Imp__0;
system implementation HeartbeatMonitor__1.Imp__0
end HeartbeatMonitor__1.Imp__0;
system implementation HeartbeatMonitor__2.Imp__0
end HeartbeatMonitor__2.Imp__0;
system implementation HeartbeatMonitor__3.Imp__0
end HeartbeatMonitor__3.Imp__0;
system implementation HeartbeatMonitor__4.Imp__0
end HeartbeatMonitor__4.Imp__0;
system implementation IncomingMonitor.Imp__0
end IncomingMonitor.Imp__0;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 23
29. MILS Adaptation Engine
system implementation LoadMonitor.Imp__0
end LoadMonitor.Imp__0;
system implementation NodeMonitor.Imp__0
end NodeMonitor.Imp__0;
system implementation ServerBlock__0.Imp__0
subcomponents
AS1: subject ApplicationServer.Imp__0;
AS1_mon: system HeartbeatMonitor__0.Imp__0;
WS: subject WebServer.Imp__0;
WS_mon: system HeartbeatMonitor__1.Imp__0;
connections
port AS1.heartbeat -> AS1_mon.heartbeat_in;
port AS1.out_get -> out_get1;
port WS.heartbeat -> WS_mon.heartbeat_in;
port WS.out_get -> AS1.in_get;
port in_get -> WS.in_get;
end ServerBlock__0.Imp__0;
system implementation ServerBlock__1.Imp__0
subcomponents
AS1: subject ApplicationServer.Imp__0;
AS1_mon: system HeartbeatMonitor__2.Imp__0;
AS2: subject ApplicationServer.Imp__0;
AS2_mon: system HeartbeatMonitor__4.Imp__0;
WS: subject WebServer.Imp__0;
WS_mon: system HeartbeatMonitor__3.Imp__0;
connections
port AS1.heartbeat -> AS1_mon.heartbeat_in;
port AS1.out_get -> out_get1;
port AS2.heartbeat -> AS2_mon.heartbeat_in;
port AS2.out_get -> out_get2;
port WS.heartbeat -> WS_mon.heartbeat_in;
port WS.out_get -> AS1.in_get;
port WS.out_get -> AS2.in_get;
port in_get -> WS.in_get;
end ServerBlock__1.Imp__0;
system implementation System__0.Imp__0
subcomponents
database: subject Database__0.Imp__0
Page 24 Version 1.0
Confidentiality: Public Distribution
28 January 2019
30. MILS Adaptation Engine
{ DeployedOn => reference(nodes__0); };
db_node_mon: system NodeMonitor.Imp__0;
incoming_mon: system IncomingMonitor.Imp__0;
load_balancer: subject LoadBalancer__0.Imp__0;
load_balancer_mon: system LoadMonitor.Imp__0;
nodes__0: node Node.Imp__0;
nodes__1: node Node.Imp__0;
server_blocks__0: system ServerBlock__0.Imp__0;
server_blocks__1: system ServerBlock__1.Imp__0;
user_mons__0: system UserMonitor__0.Imp__0;
user_mons__1: system UserMonitor__1.Imp__0;
user_mons__2: system UserMonitor__2.Imp__0;
users__0: subject User.Imp__0;
users__1: subject User.Imp__0;
users__2: subject User.Imp__0;
connections
port load_balancer.avg_load -> load_balancer_mon.load_in;
port load_balancer.out_get__0 -> server_blocks__0.in_get;
port load_balancer.out_get__1 -> server_blocks__1.in_get;
port nodes__0.healthy -> db_node_mon.healthy_in;
port server_blocks__0.out_get1 -> database.get1__0;
port server_blocks__1.out_get1 -> database.get1__1;
port server_blocks__1.out_get2 -> database.get2__1;
port users__0.get -> load_balancer.in_get;
port users__0.get -> user_mons__0.user_out;
port users__1.get -> load_balancer.in_get;
port users__1.get -> user_mons__1.user_out;
port users__2.get -> load_balancer.in_get;
port users__2.get -> user_mons__2.user_out;
end System__0.Imp__0;
system implementation UserMonitor__0.Imp__0
end UserMonitor__0.Imp__0;
system implementation UserMonitor__1.Imp__0
end UserMonitor__1.Imp__0;
system implementation UserMonitor__2.Imp__0
end UserMonitor__2.Imp__0;
data HTTP_Message
end HTTP_Message;
data SQL_Query
end SQL_Query;
28 January 2019 Version 1.0
Confidentiality: Public Distribution
Page 25
31. MILS Adaptation Engine
data ServerFailed
end ServerFailed;
data implementation HTTP_Message.Data
end HTTP_Message.Data;
data implementation SQL_Query.Data
end SQL_Query.Data;
data implementation ServerFailed.Data
subcomponents
sk: data enum(web_server, main_app_server,
redundant_app_server);
bi: data int;
end ServerFailed.Data;
properties
Constants => "Malicious: function HTTP_Message.Data -> bool;
HeartbeatTimeout: clock msec := 1 msec;
MaxLoad: real := 0.9;";
end LoadBalancerModel;
A.4 Rule table
Content of the rule table file load_balancer_with_monitors_rules.csv:
r1 ; new_user() ; add_user[*] ; 0 ; 0
r2 ; malicious_user(id) ; remove_user[id] ; 0 ; 0
r3 ; overload(load) ; add_server_block[*][true] ; 0 ; 0
r4 ; ; ask ; 1 ; 300
r5 ; server_failed(kind, id) ; replace_server_block[id][*] ; 0 ; 0
r6 ; ; ask ; 1 ;
r7 ; ; halt ; 2 ;
r8 ; node_unhealthy() ; migrate_database ; 0 ; 0
r9 ; ; halt ; 1 ;
Page 26 Version 1.0
Confidentiality: Public Distribution
28 January 2019
