Dynamic Cascade Vulnerability Checks in Real-World ... · Dynamic Cascade Vulnerability Checks in...
Transcript of Dynamic Cascade Vulnerability Checks in Real-World ... · Dynamic Cascade Vulnerability Checks in...
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 [email protected]
David Llewellyn-Jones School of Computing and Mathematical Sciences Liverpool John Moores University [email protected]