Dynamic Cascade Vulnerability Checks in Real-World Networks Rachel Craddock, Adrian Waller, Noel Butler, Sarah Pennington

Thales UK Research and Technology

David Llewellyn-Jones, Madjid Merabti, Qi Shi, Bob Askwith

School of Computing and Mathematical Sciences, LJMU

3rd December 2012

© Thales UK 2011

•  Cascade Vulnerability Problem

•  Detection Overview

•  Practical Issues

•  Simulation Results

•  Conclusions

Outline 1 /

CVP Cascade Vulnerability Problem

© Thales UK 2011

Cascade Vulnerability Problem

Security vulnerability in MLS systems that interact across networks

u  Data compromise is potentially easier for networked systems than for a single system accredited to the same level

u  Caused by the way that systems are assured based on the level of the data held on them

Common formulation u  Data is assigned a security level e.g. TS, S, C u  In normal operation data can be upgraded freely, but not downgraded u  MLS devices may store data of more than one level u  Risk that if device is compromised, attacker could downgrade data

£  Greater the downgrade, the more serious the damage caused, and the greater the risk

u  To mitigate the risk, MLS devices must be assured to a certain level £  The higher the assurance, the harder to compromise £  Assign a difficulty to compromise device that is inversely proportional to the risk requirement

Problem u  Works in isolation, but can fail with networked devices

© Thales UK 2011

CVP Example

u  Assign a difficulty to each machine £  Commensurate with risk £  For defence systems risk requirements

generally result in discrete numerical security levels being defined

u  Single TS-C machine must be accredited to difficulty level 3

u  Difficulty of compromising multiple machines is the maximum of both machines £  Compromise both h1 and h3 is difficulty 2

u  To reduce level of data from TS to C: £  Downgrade from TS to S on h1

£  Transmit to h3 via h2

£  Downgrade to C by compromising h3

£  Achieved with difficulty of 2

Easier to compromise the networked system than would be required by the

TCSEC criteria for an isolated system

Max Data Sensitivity

C S TS

Min

Clearance

TS 0 0 0

S 0 0 2

C 0 1 3

© Thales UK 2011

CVP Solutions

Current approaches u  Centralised u  Require complete knowledge of the network

£  Applied to network as a whole £  Structure of network must be known in full at time algorithm is applied £  In real networks, may not be desirable or even possible

u  Less efficient u  Horton algorithm

£  First finds all legal paths through the network £  Considers all paths through the network and highlights cascading paths

Our approach u  Distributed algorithm u  Detection occurs at the point of connection of a new link in the network

£  Vulnerabilities can be detected using only local information £  Allows new links that will cause a cascade vulnerability to be safely refused in an

efficient way u  Immediate decision

© Thales UK 2011

CVP Detection Algorithm Distributed Dynamic Cascade Checks

© Thales UK 2011

CVP Detection

Each system maintains input and output tables u  Capture the nature of the paths entering and leaving the system u  Limited amount of data u  n x n matrix of difficulty values

£  n: number of possible classification levels the network supports

Input

Output

© Thales UK 2011

CVP Detection

Initialisation Procedure u  Sets the initial values that should be stored before it makes any connections

£  Based on standard risk matrix used across the network u  Each cell represents relationship between level of system storing data and

level of system connected to it u  A symbol is used to indicate where a downgrade or upgrade cannot arise u  Initially input and output tables have the same values

© Thales UK 2011

CVP Detection

Decision Procedure u  When a new unidirectional connection is requested we aim to ensure it does

not cause a vulnerability £  Connecting nodes exchange input and output tables as shown £  Nodes compare input and output tables ●  Nodes calculate the minimum difficulty of performing a downgrade using existing links

and the new link ●  Must be higher than pre-specified difficulty requirements

£  If CVP is detected, the link is refused and no further action is needed

© Thales UK 2011

CVP Detection

Update Procedure u  Each system performs a merge on their tables u  Changes to the table must be propagated to other nodes

£  System must send changes to any connected systems so they can perform updates £  If the table doesn’t change, no further propagation is needed

Implementation Practical Issues

© Thales UK 2011

Secure On-Demand Architecture

SODA u  Developed as part of EC SUPHICE project u  Allows dynamic, policy-based connections to be made semi-automatically

between high-assurance networks £  Pair-wise decisions only

u  Uses hardware crypto devices to encrypt channels u  Rules-based approach

£  Human administrators define rules £  Can change rules quickly if required

Extended SODA u  Include CVP checks into authorisation process

© Thales UK 2011

Secure On-Demand Architecture

Registry u  Provides details of available

networks that meet certain criteria

u  Provides attributes about chosen network

Authorisation Server u  Checks attributes against policy

rules u  Makes decision whether to

connect

Limitation u  Does not take into account

existing connections

© Thales UK 2011

Integration with SODA

u  CVP detection integrated into SODA Authorisation Servers u  Authorisation Servers exchange information for CVP detection u  Authorisation Server performs check and makes decision u  If CVP detected, decision is referred to human operator of both systems

£  Allows overrule and connection can be made “at risk” £  More flexible than rejecting

© Thales UK 2011

Concurrent Updates

Allow concurrent updates u  Requests to connect a node can be revisited u  Input and output tables will correct themselves

£  Doesn’t matter order receive updates and rollbacks u  Unsafe connection may be in place for a short time u  Roll back if incorrect decision

Prevent concurrent updates u  Very dynamic networks u  Very high risk associated with unsafe connections u  Use central, shared Update Manager to ‘lock’ updates

£  Ask permission to initiate update £  Informs Update Manager when process has completed £  If permission denied, node is added to queue of requests

© Thales UK 2011

Preventing Concurrent Updates

Determining update has completed u  Update path is completed when update reaches a node whose tables do not change

or node at end of path u  Node sends completion notification back along path u  Initiating node informs Update Manager when received notifications for each update it

sent

© Thales UK 2011

Practical Issues

Unexpected disconnections u  Node at either end of link detects disconnection and informs Update

Manager £  No update in progress: network is locked so update for lost link can occur £  Update in progress: update for lost link occurs once current update has finished

Discovering links has been lost

u  Node doesn’t receive response to a request £  Periodic connectivity checks

u  Length of time to wait is scenario-dependent

© Thales UK 2011

Security implications of Update Manager

Inherent assumption about trust between nodes u  Nodes will tend to belong to single or set of trusted organisations u  Can assume nodes are not malicious unless compromised u  Authentication between nodes and Update Manager to prevent spoofing u  Nodes only send ‘lock’ request to Update Manager

£  Low confidentiality requirement £  Integrity and availability are important to prevent denial-of-service attack

Access to Update Manager

u  Out-of-band channel, separate to main network connections u  Existing network

£  Multiple, coordinated Update Managers with one nominated as common Yet to be fully addressed

Simulation Results

© Thales UK 2011

Simulation Results

MATTS topology test system u  Networks of components can be build up graphically u  Testing secure component composition results u  CVP check is performed when attempt is made to create a new link

© Thales UK 2011

Simulation Results

Testing accuracy u  1000 random graphs of 30-50 nodes and 100-500 links

£  50% built with our dynamic method – no cascading paths £  50% built with 1 link failing check – at least 1 cascading path

u  Checked graphs with Horton algorithm u  Test results concurred in all cases

Testing efficiency u  Comparison of time taken to generate cascade-free graphs

£  Graph sizes from 20 nodes/100 links to 50 nodes/500 links £  Averaged results of five randomly generated graphs

© Thales UK 2011

Simulation Results

Fixed number of links

© Thales UK 2011

Simulation Results

Fixed number of nodes

© Thales UK 2011

Simulation Results

Testing time required to add new link to existing network u  1000 nodes cascade-free network with 7500 to 20000 links u  Measured processing time to test for CVP when new link added u  10 instances of each network size

Links in Network Time (ms)

8 000 0.156 10 000 0.228 12 000 0.308 14 000 0.396 16 000 0.478 18 000 0.544 20 000 0.596

Conclusions

© Thales UK 2011

Conclusions

Distributed CVP Detection algorithm u  Application to SODA

u  Practical approach for real-world systems

u  Simulation results show efficiency and scalability

© Thales UK 2011

Future Work

•  Implement and test solutions for preventing concurrent updates •  Applications outside military •  Coalition networks

u  Assume common interpretation of security policy, security levels, etc u  Coalition network has multiple organisations and/or nations

£  Could create common set of security levels £  Security policy is likely to be different

•  Aggregation of network information u  Each node has access to information about network

£  Input and output tables u  Could infer more information about network

£  Future work: how much could you infer? u  Centralised approaches

£  Trusted central point with visibility of whole network £  Would have similar or possibly worse problem in coalition networks

Questions?

© Thales UK 2011

Contact Details

Adrian Waller Thales UK Research and Technology Adrian.Waller@uk.thalesgroup.com

David Llewellyn-Jones School of Computing and Mathematical Sciences Liverpool John Moores University D.Llewellyn-Jones@ljmu.ac.uk