Critical Infrastructures Security Modeling, Enforcement and Runtime Checking Anas Abou El Kalam, Yves Deswarte
[email protected],
[email protected] LAAS-CNRS, Toulouse, France
http://crutial.cesiricerca.it/
Context: Electrical Power Grid in Europe o Production, transport, distribution of electrical energy The CRUTIAL european project CRitical UTility InfrastrurAL resilience.
o Many stakeholders
of different size (from multinational companies to individual customers), with different functions (production, transport, distribution, marketing, brokerage, regulation authorities, …) Most participating companies are competing with each others
o Large (extensible) structures, over large geographic areas and countries o Information Systems: heterogeneous, complex, dynamic, evolvable
Control Center
Public Networks
Control Center
Control Center
Control Center
Problem Statement To address the growing needs of the deregulated market o The different organizations need to share and exchange data and services through public/private networks Security o They have conflicting interests Mutual suspicion o They want to keep control and privacy over their own resources, and they are liable of their own employees Autonomy for authentication and authorization
o PolyOrBAC (cf. paper at CIP 2008) Each organization has its own security policy: OrBAC Interaction between organizations through Web Services
Web Services Based on open, standardized, well-known mechanisms and protocols WS support interoperability between software components belonging to heterogeneous platforms Compatibility with OrBAC o For the organization offering a WS: the other organization is seen as a “virtual user”, which plays a role authorized to execute the service o For the organization requesting a WS: the WS is seen as an “external object”: WS image o Authentication & access control within each organization (OrBAC) o WS security enforcement: through “contracts”
PolyOrBAC & WS
Organisation A
AC
Organisation B
AC
PolyOrBAC & WS
Organisation A
AC
Organisation B
AC
WS
PolyOrBAC & WS
Organisation A
Organisation B
UDDI
AC
AC
WS
PolyOrBAC & WS Manager 1 Organisation A
AC
Manager 2 Contract
Organisation B
AC
WS
PolyOrBAC & WS
Organisation A
Contract
Organisation B
AC
AC
WS WS Image
Virtual user representing A
PolyOrBAC & WS
Organisation A
AC
Contract
Organisation B
AC
WS
PolyOrBAC & WS
Organisation A
AC
Contract
Organisation B
AC
WS
PolyOrBAC & WS
Organisation A
AC
Organisation B
AC
WS
Summary on PolyOrBAC Each organization authenticates its users and manages its resources autonomously (local security policy). Interactions: o Through Web Services, with signed contracts + message logging (evidence) o The requesting organization is liable for its users o The providing organization is liable for the service: compliance with the contract
Contracts Negotiated before WS use Describe the WS: functions and parameters,
expected quality of service, liability of each party, payment, penalties in case of failure/abuse, …
+ security rules (i.e., agreed security policy) o Permissions o Prohibitions o Obligations
o Verified at runtime + evidence collection o At the level of messages exchange --> 1 timed automaton on each side of the WS
Run-time model checking Permissions = transitions between states,
triggered by a valid WS message or by a local event
Prohibitions o Implicit: no transition o Explicit: transitions to “failure states”
Obligations ???
o “Internal obligations” = transition automatically triggered by local events (guarded by time-out) o “External obligations” = those that must be realized by the other party, guarded by a local time-out: if a proof of achievement is not received before the time-out --> transition to an exception (obligation)
CRUTIAL Architecture Facility
Modem server
PSTN
Facility P P
P
CIS
P
hostile environment
Local Network
Node
Node Node
CIS
CIS WAN Node
Node
Local Network
CIS Node
CIS
CIS Internet
PolyOrBAC dans CRUTIAL
Contract
Organisation A
A’s CIS AC
Organisation B
B’s CIS AC
WS
PolyOrBAC dans CRUTIAL
Contract
Organisation A
A’s CIS AC
Organisation B
B’s CIS AC
WS
Scenario Example TSO
Public Networks
Control Center
DSO Control Center
21
Distribution CC
Transmission CC
TSO
Transmission Substation
DSO
Distribution Substation
22
3. Signals and Measurements
DSO
Transmission Substation
Measurements
Measurements
2. Signals and
TSO
1. Signals and
Distribution CC
Transmission CC
Distribution Substation
Normal operation 23
3. Signals and Measurements
Transmission Substation
Measurements
DSO
1. Signals and
Distribution CC
4. Arm for load for x MW
5.Arming/disarm.
Measurements
TSO
2. Signals and
Transmission CC
Distribution Substation
Prepare for possible load shedding 24
3. Signals and Measurements
Transmission Substation
Distribution CC
4. Arm for load for x MW
Measurements
1. Signals and
DSO
5.Arming/disarm.
7. Ack for armed x MW 6. Arm./disarm. Ack
Measurements
TSO
2. Signals and
Transmission CC
Distribution Substation
Ready for load shedding Note : 6 and 7 are facultative: the info can be transmitted by signals in 1&3 For 6 : disarming can be automatic
25
3. Signals and Measurements
Transmission Substation
Measurements
DSO
1. Signals and
Distribution CC
4. Arm for load for x MW
5.Arming/disarm.
Measurements
TSO
2. Signals and
Transmission CC
Distribution Substation
Emergency 26
3. Signals and Measurements
Transmission Substation
Measurements
1. Signals and
DSO
5.Arming/disarm.
Distribution CC
4. Arm for load for x MW
Measurements
TSO
2. Signals and
Transmission CC
7. Load Shedding Distribution Substation
27
Example of automaton Distribution System Control Center: arming/disarming DS Substations for load shedding
Conclusion General security model for inter-organization interactions o Each organization maintains its sovereignty on its assets (authentication, authorization) and is liable for its users o Interactions through Web Services, with controlled compliance with “contracts” verified at run-time
An application scenario demonstration is currently developed in CRUTIAL