# Vulnerability Assessment of Sensor Systems
## 4 Validation of the Sensor System Vulnerability Assessment Method
One of these important sources is the organization responsible for the Common Criteria implementation in the given country and supervising the licensed ITSEFs (scheme owner, certification body). The information source knowledge base defines \"where to search\" for this knowledge. Figure 3 shows the sources as individuals of ontology classes. The left panel shows the class hierarchy of the CCO ontology, including subclasses of the _InfoSourceTaxonomy_ class. The middle panel presents the individuals as examples of sources belonging to different categories. One of them, _SecRep_CAPEC_, is shown in the right panel. Currently, the given source is defined by a short name, description, and link to knowledge in the public service, database, data feed, or internal ITSEF repository. The VRI and info sources are the basic input of EEP2-2, but, during the search, the evaluator may look to the evaluation evidences, mainly ADV documents, for details dealing with the TOE design. EEP2-2 concerns the public domain search and:  
1. The evaluator searches the publicly available sources of information (_InfoSourceTaxonomy_ knowledge base) to identify possible attack scenarios on the evaluated TOE or similar products, and the vulnerabilities exploited by these attacks. 2. Potential vulnerabilities are registered in the _PotentialVulnerability_PV_ knowledge base. The related scenarios are placed into the _AttackScenario_AS_ knowledge base. 3. Optionally, only for AVA_VAN.1, if the given potential vulnerability is applicable to the TOE in its operational environment, the analysis should be performed. As the input, the assumptions (a part of ASE_SPD) and security objective for the operational environment (ASE_OBJ) are used. 4. All vulnerabilities considered as \"applicable\" are marked as the candidates for testing, are placed into the _ApplicableVulnerability_AV_ knowledge base, and reported in the ETR (evaluation technical report). 5. The evaluator assigns the verdict (PASS/FAII/INCONCLUSIVE) for the AVA_VANx.2E and justifies it. Please note that EEP2-2's output is placed in three knowledge bases. The first, _PotentialVulnerability_PV_, includes identified potential vulnerabilities resulting from the search (EEP2-2) or analyses of the vulnerability-relevant items (EEP3-2). The vulnerability  
Figure 3: Information sources presented in the Protége tool. specification is based on the main elements of vulnerability description ontology (VDO) [48], expressed by data properties:  
* _VulnerabProvenance_--such as the name of the source which provides information [25; 42; 43; 44] and any other source from the _InfoSourceTaxonomy_ knowledge base;
* _ExtVulnerablD_--a unique identifier of a vulnerability in an external source, such as a knowledge base article number, patch number, bug tracking database identifier, or a common identifier, such as common vulnerabilities and exposures (CVE) [43] or common weakness enumeration (CWE) [44];
* _VulnerabDescription_--analogous to the VDO \"scenario\";
* _Product_--software and/or hardware configurations that are recognized as vulnerable;
* _AttackTheater_--area or place from which an attack may occur;
* _EngineeringMethod_--method or mechanism used to manipulate the user into interacting with a malicious resource;
* _VulnerabContext_--entity where the impacts are realized from successful exploitation of a security vulnerability;
* _VulnerabilityScore_--according to the common vulnerability scoring system [49];
* _Equipment_--equipment used to exploit a vulnerability;
* _CEMreference_--reference to the CEM attack taxonomy. Apart from data properties expressing knowledge, the individual includes object properties expressing relations between other individuals belonging to the evaluation project. The right panel of Figure 4 presents an example of a potential vulnerability specification in the knowledge base.