There is immense complexity in creating an effective Vehicle Cyber Security approach. It requires a hybrid approach that combines safety and security that includes programs, people, processes, and technologies. An approach for securing Cyber Physical Systems.
Through the entire vehicle lifecycle: Design, Build, Operate, Service and Decommission
Additionally, it should include capabilities to dynamically monitor and address risks that may arise in the future. The vehicle and its entire ecosystem is required to remain protected from full range of security threats.
To add further complexity, the highly connected functionality makes vehicles today, Internet of Things, which have points of risk that can be introduced at many levels.
OutSecure has developed a framework that addresses these challenges.
- This article describes a cybersecurity process framework and guidance to help Organizations Identify and Assess cybersecurity threats
- and Design cybersecurity into cyber-physical vehicle systems throughout the entire development lifecycle process.
It is a Risk based & holistic approach to cybersecurity for CPS.
Security Integrated System Development & Deployment (SISDD)
Approach: Cybersecurity should be built into the design rather than added on at the end of development.
The objective: Build a system that supports and enforces the necessary authentication, authorization, confidentiality, data integrity, accountability, availability, and non-repudiation requirements, even when the system is under attack.
Building Cybersecurity into the design requires an appropriate lifecycle process from the concept phase through production, operation, service, and decommissioning. This document provides a complete lifecycle process framework that may be tailored to a specific requirement.
SISDD Training Phase:
All members of system development teams should receive appropriate training to stay informed about security basics and recent trends in security and privacy. Individuals who develop systems should attend at least one security training class each year. Security training can help ensure system is created with security and privacy in mind and can also help development teams stay current on security issues.
Basic Concepts
- Secure design, including the following topics:
- Attack surface reduction
- Defense in depth
- Principle of least privilege
- Secure defaults
- Threat modeling, including the following topics:
- Overview of threat modeling
- Design to a threat model
- Coding to a threat model
- Testing to a threat model
- Secure coding SEI CERT C Coding Standard for the C programming language, developed by the CERT Coordination Center to improve the safety, reliability, and security of software systems.
- Buffer overruns
- Integer arithmetic errors
- Cross-site scripting
- SQL injection
- Weak cryptography
- Managed code issues (C, C++, Misra, Python)
- Security testing, including the following topics:
- Security testing versus functional testing
- Risk assessment
- Test methodologies
- Test automation
Privacy, including the following topics:
- Types of privacy data
- Privacy design best practices
- Risk analysis
- Privacy development best practices
- Privacy testing best practices
Advanced Concepts
The preceding training concepts establish an adequate knowledge baseline for technical personnel. As time and resources permit, it is recommended that you explore other advanced concepts. Examples include (but are not limited to):
- Security design and architecture.
- User interface design.
- Security concerns in detail.
- Security response processes.
- Implementing custom threat mitigations.
Security Requirements
- All engineers, developers, testers, and program managers must complete at least one security training class each year. Individuals who have not taken a class in the basics of security design, development, and testing must do so.
SISDD Requirements Phase
The Risk Assessment section that follows is exclusive to designing a security & safety requirements plan for the CPS system development. It includes identifying:
- Overall System functionality
- Components and assets in the components
- Interfaces between components
- Threat modeling of each component’s assets and interfaces.
Note: Some of the components may be complete System of Systems “SoS. They require ‘risk model’ analysis that considers both the impact to each system objective individually and the SoS objective as a whole
Security Requirements
- System Security portfolio
- The portfolio system can track information, such as contacts, dependencies, deployment considerations, milestones, testing information and history, locations of relevant documents, and tasks and security controls used during the system life cycle. Ideally, the portfolio would feature support, such as automated notification if the system is not in compliance with required (and, as appropriate—optional) controls.
- System risk assessment
- System risk level is determined based on a questionnaire filled out by the system team. This determines the SDL- tasks the system owner must complete and is used to determine if the system is in scope for a security and privacy assessment.
The output of this phase dictates the degree of oversight from a security SME. Questions in the assessment are weighted together into an overall “score,” while questions may dictate a review regardless of the overall “score.” This approach ensures consistency and reputability combined with flexibility. Experience has shown that a “one-size-fits-all” approach is not effective.
SISDD Design Phase
The Design phase is crucial to ensure that the system is “secure by design” and compliant with security and privacy policies and standards. As with the standard SDL, threat modeling is crucial to accomplishing this, although the SDL- distinguishes itself by taking a more asset-centric approach to creating the threat model. Threat modeling evaluates the threats and vulnerabilities that exist in the project’s environment or that result from interaction with other systems. You cannot consider the Design phase complete unless you have a threat model or models that include such considerations. Threat models are critical components of the Design phase and reference a project’s functional and design specifications to describe vulnerabilities and mitigations.
The threat actor(s) gain access to the assets via attack vectors and vulnerabilities present in the technology components that house or provide direct access to the targeted components. Security controls are applied to the technology components with the intent to counter or mitigate the vulnerabilities
and/or attack vectors used by the threat actors, thereby protecting the assets.
We suggest using Microsoft SDL Threat Modeling Tool to select, implement, evaluate and determine gaps in security controls at the application, system, infrastructure and enterprise levels. It also enables the developers to –
• Communicate about the security design of their systems
• Analyze those designs for potential security issues using a proven methodology
• Suggest and manage mitigations for security issues
Microsoft Threat Modeling Tool 2016 comes with a base set of threat definitions using STRIDE categories – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. In addition there is an option to add threats related to specific domains.
Design Reviews
Conduct design reviews of high-risk systems by a security SME to ensure that the design conforms to security/privacy standards and policies. The advantages of this include:
- An architecture and design review helps you validate the security-related design features of your system before you start the development phase. This allows you to identify and fix potential vulnerabilities before they can be exploited and before the fix requires a substantial reengineering effort. Essentially this results in a reduced attack surface exposed by systems, thus increasing the security of the user and the system.
Important design areas to be reviewed during this task are the OWASP top ten for IoT and IEEE: Avoiding the top 10 security flaws
SISDD Build Phase
The Build & Implementation Review includes the analysis activities and results that affect the implementations at the hardware and software levels.
This would be followed by the verification and validation review to help ensure that the system was designed and developed according to the requirements and that the Cybersecurity Controls are appropriate and work as intended; These reviews may be conducted by an team of technical experts that should ideally be independent of the feature development. To maintain consistency and completeness across the feature development, it is recommended that this same 3-4 person team participates in all of the reviews throughout the system development. The results of each review may be a pass, or a conditional pass (rework required).
A gate review should be completed successfully prior to exiting the gate and moving on to the next phase.
Technical “gate” review concept is to be used – review is considered a gate to the next phase and is performed at the end of the development phase being completed,
SISDD Security, Safety Testing & Integration Phase
This phase performs a validation and testing on the facets relevant:
- Functional
- Business
- Human
- Trustworthiness
- Data
- Timing
- Boundaries
- Composition
- Lifecycle
Hardware Level Vulnerability Testing and Penetration Testing
Cybersecurity vulnerability testing and/or penetration testing helps to determine whether the hardware has been secured against a creative intelligent threat, such as a skilled human attacker. Testing helps determine the amount of residual risk that remains after Cybersecurity controls have been applied. It may not be possible to eliminate all risk; some risk may need to be accepted. The test results and residual risk are documented, and an individual with the authority to accept the residual risk will determine whether the risk is acceptable or whether additional Cybersecurity design work and controls are needed to lower the risk to an acceptable level. The documentation package for this stage may also include a plan of action for addressing the residual risk. For example, a particular risk could be acceptable if a policy and procedures were created that made owners/operators or maintenance personnel aware of the potential risk and provided instructions for avoiding it.
Hardware level vulnerability testing should seek to verify that known vulnerabilities and potential vulnerabilities have been mitigated. The test methodology would check against a list of known hardware vulnerabilities and their recommended mitigations to ensure the corresponding Cybersecurity controls have been implemented and are working properly. Hardware level penetration testing should simulate the actions of an attacker or attackers attempting to circumvent Cybersecurity
Controls and gain control over the system. Penetration testing can be carried out by a range of simulated attackers having novice to expert skillsets and attacks can simulate attackers having increased knowledge of the target system with each attack or having increasingly advanced attack tools, until an attack is successful, which helps define the system’s threshold of resistance to attack.
Hardware vulnerability testing and penetration testing may begin as soon as a working prototype is available, and the testing should be repeated at key points during the development lifecycle.
Vulnerability and penetration testing can be performed by personnel on an internal Cybersecurity test team as a baseline evaluation, but a qualified, independent entity should ultimately be engaged for this testing to identify issues that an internal team may miss.
REFERENCES
1. ISO 26262 Part 8 First Edition, “Supporting Processes, Road Vehicles – Functional Safety”, 11-15-2011.
2. Barbara J. Czerny. “System Security and System Safety Engineering: Differences and Similarities and a System Security Engineering Process Based on the ISO 26262 Process Framework”, SAE Technical Paper 2013-01-1419, SAE World Congress and Exhibition, 2013.
3. B. Potter. ‘Microsoft SDL Threat Modelling Tool’. In: Network Security 2009.1 (2009), pp. 15–18. ISSN: 1353-4858.
4. Iván Arce, Kathleen Clark-Fisher, Neil Daswani, Jim DelGrosso, Danny Dhillon, Christoph Kern, Tadayoshi Kohno, Carl Landwehr, Gary McGraw, Brook Schoenfield, Margo Seltzer, Diomidis Spinellis, Izar Tarandach, and Jacob West. “Avoiding the Top 10 Software Security Design Flaws”, IEEE Computer Society, 2014.
5. OWASP Internet of Things Project.
6. ISO (International Organization for Standardization). “ISO/IEC 27001: – Information technology – Security techniques – Information security management systems – Requirements”. International Organization for Standardization. 27 January 2015.
7.ISO (International Organization for Standardization). “ISO/IEC 27002: Information Technology – Security Techniques. Code of Practice for Information Security Controls” 2008.12. ISO (International Organization for Standardization). “ISO/IEC 27001: – Information technology – Security techniques – Information security management systems – Requirements”. International Organization for standardization. 27 January 2015.
8. SURFACE VEHICLE RECOMMENDED PRACTICE Issued 2016-01 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
Published in Telematics Wire
