Combining Data Safety and Cyber Security: An
Description: Combining Data Safety and Cyber Security: An Equipment Health Monitoring Case Study Robert Oates, Rolls-Royce Software Centre of Excellence David Higgins, Dstl Software and Systems Dependability Private Rolls-Royce Proprietary Information
Related Topics
Download Presentation
"Combining Data Safety and Cyber Security: An" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. Combining Data Safety and Cyber Security: An Equipment Health Monitoring Case Study Robert Oates, Rolls-Royce Software Centre of Excellence David Higgins, Dstl Software and Systems Dependability Private – Rolls-Royce Proprietary Information<br>
slide2. Talk Roadmap Risk as an input to development
Equipment Health Monitoring
Data-centric Safety/Security Risk Assessment
Conclusions
Q&A 2<br>
slide3. Point to Note There is no a single process
We are not intending to come up with a single process.
Focus here is on interactions
Looking to better understand ‘how / where / when / what’ aspects interact
This is initial work into this area. Feedback is most welcome 3<br>
slide4. ISO 31000 Style Risk Driven Development 4 Establish context
(Section 4 – Establish Context) Acceptable risk Finish Start Unacceptable risk Text in bold refers to the relevant Data Safety Chapter<br>
slide5. Impact For every data artefact:
What happens if I lose the property of… 5 Disposability / Deletability Properties for a
cyber security assessment
(Microsoft SDL) Properties for a data safety assessment (SCSC) i.e. Strong links between security properties and safety properties<br>
slide6. Likelihood Divergence for safety/security
Security
- Technical capability required to undermine property
- Motivation and capability of threat actors to achieve impact
- Political/social issues
Safety
- Historical data pertaining to failure rates
- Media properties (error rate etc.)
- Environmental conditions 6<br>
slide7. An Introduction to Equipment Health Monitoring 7<br>
slide8. What is EHM? 8 Determining state by using sensed data
Analysing the data to determine health
Accurate fault isolation for efficient maintenance
Predicting future faults and deteriorating health and proposing maintenance actions to prevent disruption EHM is generally not a Safety Critical System itself – however, it is a highly data centric system used to inform safety related decisions.<br>
slide9. An Introduction to Equipment Health Monitoring 9 Application
Domain Process Domain Application
Domain<br>
slide10. Example – Rolls-Royce Trent 1000 SAGB AVM P160 TBH AVM P50 T50 I/C AVMs EMU Input: Messages from other
avionics systems
EMU Output: Obfuscated health
reports to ground<br>
slide11. Aerospace EHM Model 11 engine data<br>
slide12. A Combined Safety/Security Risk Assessment “Data centric” viewpoints into system quality factors
Shared intent: prevent harm
Risk-driven
Initiate design change
Controls & Analyses are proportionate to risks
Design Principles 12 Safety Security Data Safety Cyber Security<br>
slide13. Data Artefacts Involved in Providing EHM Services Data at rest
Raw sensor data
Externally sourced data
Local data aggregates
Analytical algorithms
Signatures of interest
Mass-storage
Decisions
Data Transportation
Digital Packets
Analogue Transmissions
Portable media
Bespoke Network Protocols 13<br>
slide14. Impact: Key Data Security Property Loss Confidentiality : Medium
No commercial/sensitive IP (impacted by domain: defence and localisation data may rise to high). Privacy issues for pilots.
Integrity : High
High value decisions made based on data
Availability : Medium
Loss of service would be easily identified. Could have business impact over time
Non-repudiation : Low
Sensors are under our control and sanity checking is performed against external data sources and redundant sensors
Authorisation : Low
Sensors should not issue commands (assuming that these are not “intelligent sensors”)
Authentication : High
Need to be confident that sensors are what they claim to be 14<br>
slide15. Impact: Key Data Safety Property Loss Summary Integrity (loss, partial loss, incorrect, multiple) : High
High value decisions made based on data
Format (loss, partial loss, incorrect, multiple) : High
Multiple sensors are to be assessed by aggregator, critical to have an understanding of units
Resolution (loss, partial, incorrect, multiple) : High
The number and type of failures we can respond to is affected by our capacity to measure and distinguish
Traceability (loss, partial, incorrect, multiple, too early, too late, loss of sequence) : High
The aggregator will accept data from multiple sensors and external inputs with different levels of integrity and provenance.
Fidelity / Representation (loss, partial, incorrect, multiple, too early, too late) : High
The data’s relationship to the real world is essential to making informed decisions 15<br>
slide16. Likelihood: Security Integrity: : Low
Attack mode: tampering (malicious user changes data)
Technical skill required: Context dependent, typically difficult as entire model has coherence, so one rogue sensor easy to spot.
Availability: : High
Attack mode: Denial of service
Technical skill required: Context dependent but, low. Physical destruction/tampering, wireless jamming, power supply attacks, network bombardment etc
Authentication: : Medium
Attack mode: Spoofing (pretending to be a legitimate sensor)
Technical skill required: Needs access to media, wireless range, connect to sensor bus, remote attack possible for certain IoT architectures 16<br>
slide17. Likelihood: Safety Integrity: : High
Cause: Sensor noise, calibration errors, physical deterioration
Format: : Medium
Cause: Failure to explicitly represent units at the interface
Resolution: : Medium
Cause: Failure to explicitly specify quality requirements
Traceability: : Medium
Cause: Configuration failure. Failure to log/understand data source. Failure of log integrity.
Fidelity / Representation: : High
Cause: Design error (failure to capture the right data), sensor characteristics (undermined assumptions of linearity), physical deterioration 17<br>
slide18. Headline Risks: Integrity (safety): High Impact, High Likelihood
Fidelity / Representation: High Impact, High Likelihood
Design principles are likely to address these issues
Shielded cables, filters for integrity
Process: ability to purge incorrect data and return to a pessimistic model
Requirements engineering to ensure that the data required to perform function is the data captured 18<br>
slide19. Likelihood: Safety Integrity: : High
Cause: Sensor noise, calibration errors, physical deterioration
Format: : Medium
Cause: Failure to explicitly represent units at the interface
Resolution: : Medium
Cause: Failure to explicitly specify quality requirements
Traceability: : Medium
Cause: Configuration failure. Failure to log/understand data source. Failure of log integrity.
Fidelity / Representation: : High
Cause: Design error (failure to capture the right data), sensor characteristics (undermined assumptions of linearity), physical deterioration 19 Low Low<br>
slide20. Residual Risks Security:
Availability (M,H)
Network design to maximise resilience, use of protocols that are resistant to common causes of DoS
Authentication (H,M)
Encryption techniques if computational power available
Safety:
Format (H,M)
Interface Definition
Resolution (H,M)
Requirements engineering - explicit QoS requirements
Traceability (H,M)
Explicit requirements for logs, log review, log backup 20<br>
slide21. Conclusions Data-centric viewpoints for a common understanding of impact
Safety impact
Security impact
Divergence at the point of “likelihood”
Mitigations can be engineered separately, but must respect the requirements of the other
Design principles encode mitigations to the main risks, risk assessments to clean up the rest 21<br>
slide22. Questions? 22<br>
slide2. Talk Roadmap Risk as an input to development
Equipment Health Monitoring
Data-centric Safety/Security Risk Assessment
Conclusions
Q&A 2<br>
slide3. Point to Note There is no a single process
We are not intending to come up with a single process.
Focus here is on interactions
Looking to better understand ‘how / where / when / what’ aspects interact
This is initial work into this area. Feedback is most welcome 3<br>
slide4. ISO 31000 Style Risk Driven Development 4 Establish context
(Section 4 – Establish Context) Acceptable risk Finish Start Unacceptable risk Text in bold refers to the relevant Data Safety Chapter<br>
slide5. Impact For every data artefact:
What happens if I lose the property of… 5 Disposability / Deletability Properties for a
cyber security assessment
(Microsoft SDL) Properties for a data safety assessment (SCSC) i.e. Strong links between security properties and safety properties<br>
slide6. Likelihood Divergence for safety/security
Security
- Technical capability required to undermine property
- Motivation and capability of threat actors to achieve impact
- Political/social issues
Safety
- Historical data pertaining to failure rates
- Media properties (error rate etc.)
- Environmental conditions 6<br>
slide7. An Introduction to Equipment Health Monitoring 7<br>
slide8. What is EHM? 8 Determining state by using sensed data
Analysing the data to determine health
Accurate fault isolation for efficient maintenance
Predicting future faults and deteriorating health and proposing maintenance actions to prevent disruption EHM is generally not a Safety Critical System itself – however, it is a highly data centric system used to inform safety related decisions.<br>
slide9. An Introduction to Equipment Health Monitoring 9 Application
Domain Process Domain Application
Domain<br>
slide10. Example – Rolls-Royce Trent 1000 SAGB AVM P160 TBH AVM P50 T50 I/C AVMs EMU Input: Messages from other
avionics systems
EMU Output: Obfuscated health
reports to ground<br>
slide11. Aerospace EHM Model 11 engine data<br>
slide12. A Combined Safety/Security Risk Assessment “Data centric” viewpoints into system quality factors
Shared intent: prevent harm
Risk-driven
Initiate design change
Controls & Analyses are proportionate to risks
Design Principles 12 Safety Security Data Safety Cyber Security<br>
slide13. Data Artefacts Involved in Providing EHM Services Data at rest
Raw sensor data
Externally sourced data
Local data aggregates
Analytical algorithms
Signatures of interest
Mass-storage
Decisions
Data Transportation
Digital Packets
Analogue Transmissions
Portable media
Bespoke Network Protocols 13<br>
slide14. Impact: Key Data Security Property Loss Confidentiality : Medium
No commercial/sensitive IP (impacted by domain: defence and localisation data may rise to high). Privacy issues for pilots.
Integrity : High
High value decisions made based on data
Availability : Medium
Loss of service would be easily identified. Could have business impact over time
Non-repudiation : Low
Sensors are under our control and sanity checking is performed against external data sources and redundant sensors
Authorisation : Low
Sensors should not issue commands (assuming that these are not “intelligent sensors”)
Authentication : High
Need to be confident that sensors are what they claim to be 14<br>
slide15. Impact: Key Data Safety Property Loss Summary Integrity (loss, partial loss, incorrect, multiple) : High
High value decisions made based on data
Format (loss, partial loss, incorrect, multiple) : High
Multiple sensors are to be assessed by aggregator, critical to have an understanding of units
Resolution (loss, partial, incorrect, multiple) : High
The number and type of failures we can respond to is affected by our capacity to measure and distinguish
Traceability (loss, partial, incorrect, multiple, too early, too late, loss of sequence) : High
The aggregator will accept data from multiple sensors and external inputs with different levels of integrity and provenance.
Fidelity / Representation (loss, partial, incorrect, multiple, too early, too late) : High
The data’s relationship to the real world is essential to making informed decisions 15<br>
slide16. Likelihood: Security Integrity: : Low
Attack mode: tampering (malicious user changes data)
Technical skill required: Context dependent, typically difficult as entire model has coherence, so one rogue sensor easy to spot.
Availability: : High
Attack mode: Denial of service
Technical skill required: Context dependent but, low. Physical destruction/tampering, wireless jamming, power supply attacks, network bombardment etc
Authentication: : Medium
Attack mode: Spoofing (pretending to be a legitimate sensor)
Technical skill required: Needs access to media, wireless range, connect to sensor bus, remote attack possible for certain IoT architectures 16<br>
slide17. Likelihood: Safety Integrity: : High
Cause: Sensor noise, calibration errors, physical deterioration
Format: : Medium
Cause: Failure to explicitly represent units at the interface
Resolution: : Medium
Cause: Failure to explicitly specify quality requirements
Traceability: : Medium
Cause: Configuration failure. Failure to log/understand data source. Failure of log integrity.
Fidelity / Representation: : High
Cause: Design error (failure to capture the right data), sensor characteristics (undermined assumptions of linearity), physical deterioration 17<br>
slide18. Headline Risks: Integrity (safety): High Impact, High Likelihood
Fidelity / Representation: High Impact, High Likelihood
Design principles are likely to address these issues
Shielded cables, filters for integrity
Process: ability to purge incorrect data and return to a pessimistic model
Requirements engineering to ensure that the data required to perform function is the data captured 18<br>
slide19. Likelihood: Safety Integrity: : High
Cause: Sensor noise, calibration errors, physical deterioration
Format: : Medium
Cause: Failure to explicitly represent units at the interface
Resolution: : Medium
Cause: Failure to explicitly specify quality requirements
Traceability: : Medium
Cause: Configuration failure. Failure to log/understand data source. Failure of log integrity.
Fidelity / Representation: : High
Cause: Design error (failure to capture the right data), sensor characteristics (undermined assumptions of linearity), physical deterioration 19 Low Low<br>
slide20. Residual Risks Security:
Availability (M,H)
Network design to maximise resilience, use of protocols that are resistant to common causes of DoS
Authentication (H,M)
Encryption techniques if computational power available
Safety:
Format (H,M)
Interface Definition
Resolution (H,M)
Requirements engineering - explicit QoS requirements
Traceability (H,M)
Explicit requirements for logs, log review, log backup 20<br>
slide21. Conclusions Data-centric viewpoints for a common understanding of impact
Safety impact
Security impact
Divergence at the point of “likelihood”
Mitigations can be engineered separately, but must respect the requirements of the other
Design principles encode mitigations to the main risks, risk assessments to clean up the rest 21<br>
slide22. Questions? 22<br>