| Cybersecurity Symposium II |
A B S T R A C T |
|
| Speaker: |
Dr. Igor Furgel
T-Systems GEI GmbH |
| Session 1: |
STANDARDIZATION OF TECHNOLOGIES FOR PROVISION OF CYBERSECURITY |
| Session Moderator: |
Mr Herbert Bertine, Chairman of ITU-T Study
Group 17 |
| Title of Presentation: |
Common Criteria: How does this Standard work? |
|
Evaluation Philosophy
Consumer’s security needs and IT products/systems (to have confidence in their security features). The question is how can I gain it (the confidence)? I trust in and rely on the developer (by my experience or his reputation) or I test the product. But how? Can/shall I do it by myself? Or it is more efficient to outsource this to an expert team due to special know-how and experiences? The main pillar of assurance are effectiveness (is my idea good/appropriate to counteract the threats [to control the situation]?) and correctness (is my idea well implemented?)
Evaluation and Validation Scheme
There are the following human players: sponsor/developer, evaluation facility, certification body. The CB is the anchor for trustworthiness and oversees the CLEF for a correct using of the methodology. The sponsor/developer provides evaluation contributions, the evaluation facility examines them applying the criteria and methodology.
The common metric of a contemporary evaluation is Common Criteria. They represent on the one hand a standard, on the other hand they are being enhanced by working groups. These working groups are coordinated by the Common Criteria International Management Board. The CC Version 3.0 draft is now under discussion.
Limits of Evaluation
The scope of evaluation is exactly defined in the ST. The security certificate is valid only for the scope of evaluation defined in the ST. Hence, the consumer – often the operator of the product/system – shall compare the information delivered by the ST with his security needs and merely after having done it decide on using the product. Since the certificate is valid only for the scope of evaluation, the consumer shall operate the product/system only under conditions having been in the scope of evaluation. The question of liability should not be underestimated in this case.
Human factor as the anchor of trust
It is hardly possible to build IT security products, which remain secure independent of human activities: An IT product/system offers different configuration options, shall be maintained etc. Hence, we cannot gain assurance based only upon the technical measures: The organisational – personal and procedural – measures are important as well. The question of plausibility of the assumptions defined in the Security Target for a product/system can primarily be answered by the consumer/operator: He shall know, whether he can implement and enforce the organisational measures assumed.
Benefits and Restrictions of evaluation
The benefits of the application of the evaluation scheme are impartiality, repeatability and comparability. All together it means more objectivity and more confidence in the product. The impartial evaluation, the independent validation of evaluation results, and the documentation resulting from these processes provide valuable information for consumers about the security capability of IT products. However, consumers will still need to review this information carefully and assess its applicability to his special needs, e.g., the situation and operating environment in which the product will actually be used. The assumptions about the method of use of the product and its operating environment, which shall be fulfilled by the system operator, as well as other conditions confining the validity of the assurance assessment are the restrictions of an evaluation.
|
|
|
|
|
