Automated Testing System for Hardware Software Security

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The architecture of hardware and software systems ensures functional safety but often fails to guarantee informational security, requiring additional measures that may not consider the interests of authorized users or requirements of functional safety.

Innovation Solution

An automated testing system that uses a threat model to compare with a usage model, identifying vulnerable components that could compromise informational security, and selects hardware and software components to limit unauthorized use and threat realization while meeting functional safety requirements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If additional security means are added to address informational security, then informational security is improved, but device complexity and potential conflict with functional safety requirements increase

Engineering Contradiction:
Improveinformational securityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary analysis by comparing the threat model with the usage model during the design phase, identifying potential security vulnerabilities before the system is deployed. This allows security measures to be integrated into the architecture from the beginning rather than added as afterthoughts, reducing overall system complexity while maintaining security.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The comparison between threat model and usage model acts as an intermediary analysis layer that identifies security issues without requiring direct implementation of complex security mechanisms. This intermediary comparison reveals vulnerabilities that can then be addressed through targeted, simplified security measures rather than comprehensive complex systems.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If additional security means are added to address informational security, then informational security is improved, but the interests of authorized users and functional safety requirements may be compromised

Engineering Contradiction:
Improveinformational securityVSAvoidcompatibility with user interests and functional safety
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

By performing the threat-model-versus-usage-model comparison during the design phase, the system identifies security vulnerabilities before finalizing the architecture. This allows security requirements to be balanced against user interests and functional safety requirements from the outset, ensuring all three aspects are considered together rather than security being added later at the expense of other requirements.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system changes the parameter of analysis by introducing a formal comparison between threat models and usage models. This analytical approach allows for quantitative or qualitative assessment of security vulnerabilities while simultaneously evaluating their impact on user interests and functional safety, enabling optimized balance among competing requirements.

Inventive Principle:
Principle #35Parameter changes

3Measurement precision

If comprehensive security testing is performed to detect all vulnerabilities, then informational security detection capability is improved, but testing time and system complexity increase

Engineering Contradiction:
Improvevulnerability detection capabilityVSAvoidtesting time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system extracts and compares only the essential elements between the threat model and usage model, focusing on specific vulnerability patterns rather than performing exhaustive testing of all system components. This selective extraction of critical security issues enables efficient identification of the most important vulnerabilities without requiring comprehensive testing of every possible attack vector.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The comparison approach performs a targeted analysis that may identify more vulnerabilities than strictly necessary (excessive action), but does so through an efficient automated process that compensates for the increased scope. Alternatively, it performs partial testing focused on the most critical threat scenarios, achieving sufficient detection capability without exhaustive coverage.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP3557468B1Method for automated testing of hardware and software systems
Publication Date: 2023.01.04 AO KASPERSKY LAB
  • EP3557468B1 patent drawingFigure 1
  • EP3557468B1 patent drawingFigure 2a~2b
  • EP3557468B1 patent drawingFigure 3

AI summary

Disclosed herein are methods and systems for automated testing of hardware and software systems. An exemplary method comprises receiving a formalized architecture description describing an architecture of a system being designed, receiving a formalized threat description describing threats to systems similar to the system being designed, building, by a processor, a use model based on the formalized description, building, by a processor, a threat model based on the formalized threat description, determining, by a processor, kinds of use of the system by comparing the threat model to the use model and determining, by a processor, components of the system based on the kinds of use.