Let us consider a simple example of a control system. The functional requirement of the system is to keep the temperature of a room above16oC. The system is composed of
a heater, a temperature sensor and a controller. For the sake of simplicity, we assume that when the heater is on, the temperature of the room increases at constant rate0.50oC
per minute. When the heater is switched off after being on for up to 20 minutes, the temperature decreases at constant rate0.25oC per minute. In reality, the variation of the
temperature may be much more complicated due to many environmental factors which are out of the scope of this thesis.
We take the design decision that when the temperature of the room reaches a safety level of 16.25oC, the heater is turned on for 20 minutes and then it is turned off. For
security reason, only the controller is authorised to turn the heater off.
We consider the following agents: heater, sensor and controller. The state of the heater (on/off) is modelled with a Boolean variableheaterIsOnwhich equalstrueif the heater is on andf alseif it is off. We assume that initially the heater is off. So the agent
agent heater : var heaterIsOn;heaterIsOn:=f alse.
The controller observes the temperature sensor and switches the heater on or off ac- cordingly. The agent sensor stores the temperature readings in the variable temp. To make our model more realistic, the initial value oftemp is unspecified. This means that the model functions correctly regardless the initial temperature of the room. Remember that in SAS, a variable takes an arbitrary initial value (in its range) if it is not explicitly initialised. The definition of agentsensoris
agent sensor : var temp.
The controller monitors the period in which the heater is on while the temperature is above 16oC using a variable time. Initiallytime equals 0 since the heater is off. The
definition of agentcontrolleris
agent controller : var time;time:= 0.
We also define the following actions which describe the behaviours of the system:
incrT emp,decrT emp,tick,turnOn, andturnOf f.
The actionsincrT empanddecrT empmodels the dynamics of the temperature within the room. We assume that when the heater is on the temperature of the room increases at constant rate0.5oCper minute and, when it is off the temperature decreases with a lower
action incrT empon sensor by sensor async heater: heaterIsOn→temp:=temp+ 0.5.
action decrT empon sensor by sensorasync heater: ¬heaterIsOn→temp:=temp−0.25.
The actiontickmonitors the time period during which the temperature is above16oC
and the heater is on. It is executed jointly by the agentsheater, sensor andcontroller. Its definition is
action tickon controllerby controllerasync heater, sensor : (temp≥16∧heaterIsOn)→time:=time+ 1.
Note that the time spent in the initialisation phase when the room temperature is below
16oC and the heater is switched on does not count. To execute this action, the con-
troller (which is the action’s target agent) need not synchronise with the other participating agentsheaterandsensor. It reads the current room temperature from the sensor, checks the state of the heater and increments the monitoring time by1if the room temperature is above16oC and the heater is on. While the action is being executed, the sensor can con-
currently sample the room temperature (e.g by executing the actionincrT empdescribed above). Another version of the action in whichsensor is a synchronisation agent can be defined by
action tick1on controllerby controller, sensorasync heater: (temp≥16∧heaterIsOn)→temp, time :=temp+ 0.5, time+ 1.
During the execution of the actiontick1, the agentsensorcannot be involved in the exe- cution of any other action. That is why the body oftick1must, at the same time, sample
the room temperature as it changes. To limit such a replication, the set of synchronisation agents of the actions can be minimised.
The actionturnOnis executed jointly by the agentsheater, sensorandcontroller. Its effect is to turn the heater on whenever the temperature of the room is less than or equal16.25oCand the heater is off. If initially the temperature of the room is less than or
equal16.25oCthen the heater must be turned on, otherwise the heater is kept off until the
room temperature reaches the low safety temperature of16.25oC. Its specification is
action turnOnon heaterby controllerasync sensor : (temp≤16.25∧ ¬heaterIsOn)→heaterIsOn :=true.
The action turnOf f is executed jointly by the agents heater and controller. Its effect is to turn the heater off and reset the monitoring time to0whenever it has been on for20time units (while the room temperature is above16oC). Its specification is
action turnOf f on heaterby controller :
(time= 20∧heaterIsOn)→heaterIsOn, time:=f alse,0.
Note that, e.g. the action turnOnand the action incrT emp can execute in parallel because they do not share a common synchronisation agent. By contrast, the actions
turnof f andtickcannot execute in parallel because the two actions are synchronised by the agentcontroller.
The access control predicates in this case are defined as follows, where p1 and p2
range over {heater, sensor, controller} and a stands for any of the actions specified above. The requirement that the controller is allowed to turn the heater on is specified as
The agent sensor is allowed to participate in the execution of the actionturnOnat any time. However the action can oly take place if the room temperature is less or equal
16.25oC. It is not necessary to switch the heater on when the room temperature is already
above the safety level. So the policy here is
autho+(sensor, heater, turnOn) =true.
Apart from the controller and the sensor, no other agent is allowed to perform an action on the heater, viz forp6∈ {controller, sensor},
autho−(p, heater, turnOn) =true, and
autho−(p, heater, turnOf f) = true.
In a similar vein, the agent heateris allowed to increase or decrease the room tem- perature, i.e.
autho+(heater, sensor, incrT emp) =true, and
autho+(heater, sensor, decrT emp) =true.
The agentheaterand the agentsensorare allowed to perform (or to participate in the execution of) the actiontickon the agentcontroller. This is specified by
autho+(heater, controller, tick) =true, and
autho+(sensor, controller, tick) =true.
For all other cases not treated above,autho+(p
1, p2, a)andautho−(p1, p2, a)are taken
to be equal tof alse.
The access control conditionautho(p1, p2, a)for an agentp1 to perform an actiona
autho(p1, p2, a) =autho+(p1, p2, a) ∧ ¬autho−(p1, p2, a).
This means that in the event of conflicts between positive authorisations and negative authorisations, the latter take precedence.
3.7
Summary
We have presented the syntax and the semantics of the Interval Temporal Logic (ITL). ITL is the foundation of our uniform formal framework for integrating the functional, the temporal and the security requirements of secure systems. The operators weak always- followed-by (7→) and strong always-followed-by (↔) are defined. These operators are used in the next chapter to express security policy rules. Interesting properties of the operators have been established that are useful in reasoning about policy rules.
We have presentedSAS, a computational model for describing secure systems. SAS
is a conservative extension of Back’s action system paradigm to cater for security. It allows us to specify the functionalities and the security policies of systems at the imple- mentation level. Security is enforced by strengthening the guard of actions with an access control condition, derived from the system’s security policy. In the next chapter, we focus on the formalisation of security policies, and in a later chapter we show how to develop a SAS that enforces a specific security policy.
Basic Security Policies
Objectives• To present the authorisation model.
• To present the delegation mechanism.
• To describe the syntax and the semantics of simple policies.
• To give the algebraic properties of simple policies.
• To address the completeness of simple policies.
4.1
Introduction
In this chapter, we focus on the specification of security policies. A security policy de- scribes rules about who is allowed to perform what action. Our computation model is a secure action system as described in the previous chapter. So a system is viewed as a col- lection of agents, a collection of actions and a security policy. An Agent can perform an
action on another agent. In this chapter we refer to the latter as an object and to the former as a subject. A security policy is defined by three Boolean functionsautho+,autho−and
autho as presented in the previous chapter. In the sequel, we model these functions as state variables and use them for specifying authorisation policies and delegation policies. A delegation policy specifies the ability of subjects to delegate some of their rights to other subjects to perform actions on their behalf. This is modelled as a special kind of authorisation policies. We assume a finite setSof subjects, a finite setOof objects and a finite setAof actions.