Linked Knowledge Nuggets: arrow_forward "Fo(u)rces of Cybersecurity Engineering"
personAuthor: Timo Karasch,
Florian Schmitt
Cybersecurity Goals, Controls, Requirements and Threats are important forces for cybersecurity engineering. It is nearly impossible to separate them in a timely manner. In fact, they influence each other during definition.
This webinar gives a simple example of the interaction of these four forces and addresses the consistency to existing standards in Cybersecurity (ISO 21434 and Automotive SPICE for Cybersecurity). It shows a possible approach for implementation in your organization.
school
Webinar recording and slides
# PROCESS PURPOSE
The purpose is to specify and verify the cybersecurity requirements, and to validate the cybersecurity goals.
# PROCESS OUTCOMES
O1
Cybersecurity requirements are derived from cybersecurity goals
O2 (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) is specified and performed
O3
Activities are identified and documented to validate cybersecurity goals and validation results are recorded
O4
Traceability is established between the cybersecurity goals and validation results
O5
Traceability is established between cybersecurity requirements and goals, and between the cybersecurity requirements and (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) specification
# BASE PRACTICES
BP1
Specify cybersecurity requirements for the cybersecurity goals. (
O1 )
Specify functional cybersecurity requirements for the cybersecurity goals, including criteria for the achievement of the cybersecurity goals. Note 1: This may include requirements for post-development phases such as preproduction, production, operation, maintenance, and decommissioning.
BP2
Cybersecurity verification measures are specified and performed. (
O2 )
Specify and perform the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) suitable to provide evidence for compliance of the integrated system with the cybersecurity requirements. Record the (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) results including pass/fail status. Note 2: Depending on the context the system might be a pure software system.
BP3
Cybersecurity validation activities are identified and documented. (
O3 )
Cybersecurity validation activities are identified and documented to validate cybersecurity goals.
BP4
Results of cybersecurity validation activities are recorded. (
O4 )
BP5
Traceability is established (
O5 )
Ensure traceability between the cybersecurity requirements and goals and between the cybersecurity requirements and (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) treatment (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) specification. Ensure traceability between the cybersecurity goals and validation results. Note 3: Traceability supports consistency, (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.), and validation coverage demonstration.
Linked Knowledge Nuggets: arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
# OUTPUT INFORMATION ITEMS
15-51
Analysis result (
O5 )
Identification of the object under analysis.
The analysis criteria used, e.g.:
selection criteria or prioritization scheme used
decision criteria
quality criteria
The analysis results, e.g.:
what was decided/selected
reason for the selection
assumptions made
potential negative impact
Aspects of the analysis may include
correctness
understandability
verifiability
feasibility
validity
Used by these processes:
CSVV Cybersecurity Verification and Validation
PCOM Partner and Collaboration Management
REEL Requirements Elicitation
SWDI Software Requirements, Design and Implementation
SYRD System Requirements and Design
17-00
Requirement (
O1 )
An expectation of functions and capabilities (e.g., non- (Functional requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.)), or one of its interfaces
from a black-box perspective
that is verifiable, does not imply a design or implementation decision, is unambiguous, and does not introduce contradictions to other requirements.
A requirements statement that implies, or represents, a design or implementation decision is called “Design Constraint”.
Examples for requirements aspects at the system level are thermal characteristics such as
heat dissipation
dimensions
weight
materials
Examples of aspects related to requirements about system interfaces are
connectors
cables
housing
Examples for requirements at the (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) level are
lifetime and mission profile, lifetime robustness
maximum price
storage and transportation requirements
functional behavior of analog or digital circuits and logic
quiescent current, voltage impulse responsiveness to crank, start-stop, drop-out, load dump
temperature, maximum (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) heat dissipation
power consumption depending on the operating state such as sleep-mode, start-up, reset conditions
frequencies, modulation, signal delays, filters, control loops
power-up and power-down sequences, accuracy and precision of signal acquisition or signal processing time
computing resources such as memory space and CPU clock tolerances
maximum abrasive wear and shearing forces for e.g., pins or soldering joints
requirements resulting from lessons learned
safety related requirements derived from the technical safety concept
Used by these processes:
CSVV Cybersecurity Verification and Validation
REEL Requirements Elicitation
SWDI Software Requirements, Design and Implementation
SYRD System Requirements and Design
13-19
Review evidence (
O5 )
Provides the context information about the review:
what was reviewed
lists reviewers who attended and their area of responsibility
status of the review
Provides information about the scope of the review:
checklists
review criteria
requirements
compliance to standards
Effort information about:
preparation time spent for the review
time spent in the review
Review findings:
non-conformances
improvement suggestions
Used by these processes:
CSVV Cybersecurity Verification and Validation
PQAS Process Quality Assurance
08-59
Validation Measure (
O3 )
A (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) can be a test case, a (Measurement = “The activity to find the size, quantity or degree of something”.), a simulation, an emulation, or an end user survey
The specification of a (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) includes
pass/fail criteria for (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) (completion and end criteria)
a definition of entry and exit criteria for the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
), and abort and re-start criteria
Techniques
Necessary validation environment and infrastructure
Necessary sequence or ordering
Used by these processes:
CSVV Cybersecurity Verification and Validation
13-24
Validation Results (
O4 )
Validation data, logs, feedback, or documentation
(Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) passed
(Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) not passed
(Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) not executed, and a rationale
Information about the validation execution (date, participants etc.)
Abstraction or summary of validation results
Used by these processes:
CSVV Cybersecurity Verification and Validation
08-60
Verification Measure (
O2 )
A (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) can be a test case, a (Measurement = “The activity to find the size, quantity or degree of something”.), a calculation, a simulation, a review, an optical inspection, or an analysis
The specification of a (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) includes
pass/fail criteria for (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) (test completion and ending criteria)
a definition of entry and exit criteria for the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), and abort and re-start criteria
Techniques (e.g., black-box and/or white-box-testing, equivalence classes and boundary values, fault injection for Functional Safety, penetration testing for Cybersecurity, back-to- back testing for model-based development, ICT)
Necessary (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) environment and infrastructure
Necessary sequence or ordering
Used by these processes:
CSVV Cybersecurity Verification and Validation
SWIV Software Integration and Verification
SYIV System Integration and Verification
08-58
Verification Measure Selection Set (
O2 )
Include criteria for re- (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) in the case of changes (regression).
Identification of (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), also for regression testing
Used by these processes:
CSVV Cybersecurity Verification and Validation
SWIV Software Integration and Verification
SYIV System Integration and Verification
13-25
Verification Result (
O2 )
(Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) data and logs
(Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) passed
(Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) not passed
(Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) not executed, and a rationale
Information about the (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) execution (date, “object-under- (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.)”, etc.)
Abstraction or summary of (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) results
CSVV
Cybersecurity Verification and Validation
