Dynamic Cascade Vulnerability Checks in Real-World Networks

Transcription

1 3 rd December 2012 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

2 1 / Outline Cascade Vulnerability Problem Detection Overview Practical Issues Simulation Results Conclusions

3 CVP Cascade Vulnerability Problem

4 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

5 CVP Example Min Clearance Max Data Sensitivity C S TS TS S C 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 h 1 and h 3 is difficulty 2 u To reduce level of data from TS to C: Downgrade from TS to S on h 1 Transmit to h 3 via h 2 Downgrade to C by compromising h 3 Achieved with difficulty of 2 Easier to compromise the networked system than would be required by the TCSEC criteria for an isolated system

6 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

7 CVP Detection Algorithm Distributed Dynamic Cascade Checks

8 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

9 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

10 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

11 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

12 Implementation Practical Issues

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 Simulation Results

21 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

22 Simulation Results Testing accuracy u 1000 random graphs of nodes and 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

23 Simulation Results Fixed number of links

24 Simulation Results Fixed number of nodes

25 Simulation Results Testing time required to add new link to existing network u 1000 nodes cascade-free network with 7500 to 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)

26 Conclusions

27 Conclusions Distributed CVP Detection algorithm u Application to SODA u Practical approach for real-world systems u Simulation results show efficiency and scalability

28 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

29 Questions?

30 Contact Details Adrian Waller Thales UK Research and Technology David Llewellyn-Jones School of Computing and Mathematical Sciences Liverpool John Moores University