Cybersecurity Key Principles and Verification

Minimize Attack Surface

Unnecessary attack surfaces arise from active software handling unused GPIOs (General Purpose Input/Output) interfaces.
Attackers might exploit unintended software triggers linked to these unused GPIOs.
Minimizing attack surfaces extends to connectivity technologies like Bluetooth.
Leaving unused active Bluetooth profiles (e.g., keyboard profile in a radio head unit) can create vulnerabilities.
Attackers can exploit these profiles, even if the device doesn't logically require them.
The presence of such profiles provides avenues for attack.

Secure Defaults

Computers are generally built for multiple purposes, leading to permissive default configurations.
Manufacturers lack specific knowledge of end-user activities, resulting in open default settings.
Instead of accepting OS vendor defaults, consider secure defaults tailored to product intent.
For purpose-built products like airbag systems, interfaces are known, allowing for secure default settings.
Secure defaults should permit only necessary calibrations, enhancing overall system security.

Untested Changes

Software management requires validating every change made as standard practice.
Uncontrolled releases and untested changes by software developers may introduce vulnerabilities.
Delta Airlines' ticketing system failure after an untested update highlights risks of untested changes.
This incident exposed the potential for malicious actors to replicate such attacks, emphasizing the need for thorough validation.

Zero Trust Architecture

Zero trust architecture integrates other cybersecurity principles and is well-documented by NIST.
It advocates checking all inputs, questioning all outputs, and ensuring action viability and security.
No implicit trust is granted outside of the algorithm itself, with continuous verification.
This aligns with the principle of least privilege, requiring understanding trust boundaries.
Complete zero trust is not practical, as initial memory lines must trust subsequent lines.
Where trust in another entity is necessary, encapsulate it within a secure shell.
Implement zero trust principles when development organizations hand off work.

Defense in-Depth

Organizations should create written policies explaining their defense in-depth strategies, covering the product lifecycle.
Defense in-depth should be considered on the production line as it relies on network and IT system defenses.
ECUs (Engine Control Units) are protected via in-vehicle networks, external interfaces and end-to-end security measures.
Connected services on remote servers have network identity application and data security layers. These need clear end to end security policies.
These elements combine to form consistent policies for defense in-depth across the product's lifecycle.
Cybersecurity is iteratively developed across systems, software, and hardware, indicating shared responsibility.
Unlike 26262, 21434 recognizes that system, software, and hardware requirements may be identical based on the application architecture.

Iteration and Refinement

Deliverables (e.g., work product 10-4) are often repeated due to feedback from verification reports.
Refinement may affect earlier stages, such as identifying insufficient initial requirements.
Cybersecurity controls may prove inadequate, necessitating reevaluation of threat scenarios and reprioritization of attack steps.
Verification is repeated after each refinement to ensure adequate risk mitigation.

Traceability

Traceability is key so requirements have a direct through-line to cybersecurity concepts of a TARA analysis.
Traceability requires good record-keeping and transparent sharing across boundaries, like cybersecurity interface agreements (CSIA).
Suppliers should understand the mitigated attack step to prevent architectural or implementation changes that may affect threat mitigation.
Sharing risk information, including threat scenarios, through CSIAs is an important aspect of 21434.
Sharing threat scenarios related to requirements (not revealing entire TARA) is necessary for consistent risk mitigation.
Sharing requirements helps engineers deduce potential threat scenarios and supports overall security efforts.

Verification vs. Validation

Verification: Testing the product according to its requirements i.e. "is the product built right?"
Validation: Determining if the right product is built based on user stories and threat scenarios i.e. "is the right product built?"
Difficult to separate these processes.
Test implemented product against requirements not business model, which may be removed due to IP sharing problems.

V&V is More Than Testing

V&V includes work product, schematic, code and requirements reviews.
TARA is inherently validation as it determines stakeholder interests and necessary security controls.
Simulation based, requirements based and user testing complete full V&V.
Penetration testing uses creative users to try to break systems outside of documentation.
Cybersecurity methods overlap with V&V, meaning they have security purposes too.
Test cybersecurity requirements with existing tests, before using fuzz vulnerability and penetration testing.

Cybersecurity V&V is Part of All System V&V

Integrate cybersecurity requirements into all V&V functions to assess happy path of security.
If security is in the way, it indicates over-prescription, user story inadequacy, or incorrect cybersecurity application.
Build for testability, aiding the verification team and identifying breaks before attackers do.
Verification and validation plan includes requirements test, integration test, system test stress test, functional validation, cybersecurity specific tests such as penetration testing.

Cybersecurity Specific Tests

Include cybersecurity edge conditions and non-traditional validation like penetration testing.
Requirements testing comes in form of vulnerability scanning, also fuzz and penetration testing.
Negative conditions of cybersecurity might compromise product that then falls out of normal V&V conditions.
The end of these tests is an arbitrary journey. It can be extended at any point and is therefore used during the full lifecycle.

Vulnerability Scanning

Vulnerability scanning is based on vulnerability database from pen testing and pulls properties out and also test according to methods.
For example this scan may use code from Metasploit.
The result of vulnerability scan is list of report. Types of scanning including binary code static and dynamic.
External vulnerability scanning looks at ports, the external API and public facing interfaces.

Fuzz Testing

In fuzz testing invalid outputs result to invalid function and algorithm fails. It then loops.
Inexpensive generally fully automated. A random or malformed input results in unexpected algorithm behavior. A boundary condition has been crossed without proper error handling.
Limitations- time consuming with difficult actionable failures. The obscure errors require testers.

Pen Testing

Called Security Research. Looking at the unanticipated outputs by creative innovators, as a beta test.
Prioritizes which ones to fix out of well formed testing plan.
Great with known buzz test and comprehensive outputs- giving the testers questions is a great way to shorten work.
But pen tests must be to mostly complete products and are very expensive.

Cybersecurity Case

Cybersecurity case is evidence and record accomplished from the secured or fulfilled action plan.
Includes post production requirements. Case can combined by customers or suppliers in some kind of book.
Includes TARA applying Cybersecurity goals, reference to risk from the threat. Includes potential iteration. Test then into cybersecurity case.

Post Development/Continuous Cybersecurity Activities

Product needs to be produced, operate and be maintained to eventually be decommissioned.
This production control plan doesn’t talk about OT security. It is for manufacturing sites with tools inside facility, OT network of plant.
Unauthorized alteration, also unauthorized access or records of security parameter of the product is a source of potential exploit.
There are also the SIEM (Security Information and Event Management) or event handling.

Information and Event Management

Information management includes internal data from threats and events from product, and external intelligence that are gathered on the internet
This data is then triaged into data. It it is evolved through all the data then an event with a correlation. Next there should be weakness. Once determined then there turns in weakness to vulnerable.

Incident Response

During an incident the response process requires that you analyze the threat. You need containment by limiting the contact to product. You have to contain and mitigate the breach, then communicate within the network what has happened. In the continuous aspect all concept decommissions and monitoring and analysis should be ongoing as continuous.

Audits and Assessments

You can make an audit, for example if you are looking towards that you can sell this part.
It prevent fine liability and should be ready for release. Another approach could that the organization internally doesn't want liability.
Qualified and independent the order is really like judgment. Assessor is process oriented but has lower Independence.
Continuous operation should consider concepts including communications to concepts and design.