# Vulnerability Assessment of Sensor Systems
## 2 Background and Related Work
### Vulnerability Assessment According to the Common Criteria Methodology  
Generally, a vulnerability is understood as a weakness of the IT product (TOE) that can be used to violate the security requirements (SFRs) in the operational environment. Vulnerabilities are caused by failures in the security requirements identification, in the TOE development, e.g., possibility of defeating self-protection through tampering, or in operation, e.g., insecure configuration of the TOE. Threat agents may intentionally exploit or unintentionally trigger a vulnerability, causing security breaches in IT business applications. For these reasons, vulnerabilities should be removed, neutralized, minimized with respect to their consequences, and monitored.  
The vulnerability assessment is the key activity of the IT security evaluation process. It is based on the requirements (CC components) belonging to the vulnerability assessment assurance class(AVA), which contains one family called AVA_VAN (vulnerability analysis) including five assurance components with the rising and cumulated rigor, (part 3 of the Common Criteria standard [5]):  
* AVA_VAN.1 Vulnerability survey (applied for EAL1),
* AVA_VAN.2 Vulnerability analysis (applied for EAL2 and EAL3),
* AVA_VAN.3 Focused vulnerability analysis (applied for EAL4),
* AVA_VAN.4 Methodical vulnerability analysis (applied for EAL5),
* AVA_VAN.5 Advanced methodical vulnerability analysis (applied for EAL6 and EAL7).  
Each AVA_VAN component, like each other CC assurance component, has three kinds of elements:  
* D-element, expressing what should be delivered by the developer as the evidence, e.g., \"AVA_VAN.3.1D Developer shall provide the TOE for testing\";
* C-element, i.e., contents and presentation of this evidence item, e.g., \"AVA_VAN.3.1C The TOE shall be suitable for testing\";
* E-evaluator's action elements, denoted, e.g., as AVA_VAN.3.1E, express how this evidence item shall be checked by the evaluator; for each subactivity (a component) one or more evaluator's actions elements exist (to be discussed later); to each action, a verdict is assigned; each action has several \"work units\" structuring properly and refining the evaluator's activity.  
The objective of AVA_VAN is to determine whether the identified potential vulnerabilities could allow the attacker to violate the SFRs. Using the evaluation evidence and public information, the evaluator performs the vulnerability analysis according to CEM [29] and carries out penetration tests. During the vulnerability assessment a wide range of assessment methodologies, unspecific to the kind of an attack scenario, can be applied. The CC vulnerability assessment is relatively specific compared to other vulnerability assessment services offered on the market to \(\Pi\) systems used in organizations:  
* it is better defined on a general level;
* it should provide repeatability of assessments performed in different ITSEFs;
* it considers \"a type\", i.e., a group of \(\Pi\) products, not a concrete system applied in an organization;
* it considers the assumed operational environment of an \(\Pi\) product;
* it embraces multidirectional evaluation activities: examination of generally known vulnerabilities described in public information sources, analysis of evaluation evidences to find vulnerabilities introduced by developers, less or more formal vulnerability analyses (including the flaw hypotheses), assessment of resistance to a given attack potential, and experimental confirmation of the analysis results by penetration tests;
* it is multilayered--the analytical rigor depends on the EAL and is specified by AVA_VAN.x assurance components.