REVIEW OF THE COMMON CRITERIA FOR INFORMATION TECHNOLOGY SECURITY EVALUATION VERSION 0.9 Statement by the "Privacy and Security Task Force" of the German Society for Informatics (Praesidiumsarbeitskreis "Datenschutz und Datensicherung" der Gesellschaft fuer Informatik) 28 February 1995 The task force welcomes the discussion on the CC V.0.9 and the document itself as a step forward on the way to a thoroughly workable set of security criteria to the benefit of all who need and wish secure systems. The task force supports every effort towards a better understanding of the fact that safety and security are necessary conditions for the controllability of information technology. However, there are some remarks to be made. Therefore this comment is structured as follows: 1 General Comments 2 Balance and Coverage of the Criteria 2.1 Balance 2.2 Coverage 3 Security Functionality 3.1 Balance of Security Functionality 3.2 Covert Channels 3.3 Privacy 3.4 Non Repudiation 4 Assurance Requirements 4.1 Risks through Tools 4.2 Missing Evaluation of Cryptographic Mechanisms 4.3 Covert Channels 4.4 Evaluator Actions 1 General Comments REF:*/Editorial The document has been collected and edited with great and admirable knowledge and industry. The resulting draft, however, has become very large and in some parts not easy to read. Readers, especially consumer and procurers will not be able to read and understand it as a whole. They need a guidance to those parts of the document which are relevant for them. Especially they need information, what a "Standard Certificate" can help them and in which cases it is advisable to develop their own requirements in protection profiles or security targets. In previous national Evaluation Criteria much attention has been given to the attempt to come up with a well structured model of the various aspects and components of the overall and complex notion of "IT Security". While those attempts had been incomplete, the CC now appear to bury structure by an avalanche of details. 2 Balance and Coverage of the Criteria 2.1 Balance REF:*/Approach/Balance Though there are considerable improvements compared to previous criteria the CC are still biased towards the problems caused by users and system outsiders, while almost neglecting the risks caused by system designers, manufacturers and operators. Additionally there is still a bias in the CC towards "classical" TCB protection of centralized systems, while issues most important for distributed computer and telecom systems are underrepresented. One example for this is the ratio of 14 pages for "new" functional components against more than 200 pages for the "old" ones in Part 2 of the CC. 2.2 Coverage REF:1/6/80/Approach/Coverage Without an adequate and internationally compatible and reproducible evaluation of cryptographic mechanisms (which includes the public scrutiny of these mechanisms) the value of certificates and evaluation results for users is reduced dramatically. Secure IT without secure encryption will prove without effect or even impossible in many important practical applications. 3 Security Functionality 3.1 Balance of Security Functionality REF:2/2/Approach/Balance of Security Functionality In the Classes FPR and FCO the CC contain requirements coming up with the wider use of computer aided telecommunication. Also they at least consider the fact, that the protection of users and usees and the protection or avoidance of user and usee data is crucial for the acceptance and success of distributed computer and telecom systems. This is a big step forward. However there is still a bias in the criteria towards "classical" TCB protection of centralized systems. This is documented by a ratio of 14 pages for "new" services against more than 200 pages for the "old" ones. This part should be re-edited as to make it applicable to main frames, decentralized systems and networks as well. Obviously some of the details have to be specialized with respect to their centralized or decentralized environment. The majority, however, should apply to all three types of implementation. 3.2 Covert Channels REF:2/FDP_IFM.7/Detail - Local/Covert Channels This coverage of Covert Channels is a step forward and the conjunction via dependencies to AVA_CCA is a good idea. REF:2/FDP_IFM.8/Detail - Local/Covert Channels This coverage, too, is a step forward and a good idea like in FDP_IFM.7. Some info on sensible maximum bandwidths would be useful. 3.3 Privacy REF:2/FPR/Approach/Privacy and Security Administrators While the coverage of Privacy Functionality is a big step forward, the levelling of the families may need improvement. Especially the special consideration of security administrators as trusted entities causes problems because administrators with their special privileges are liable to induce special risks. Therefore systems which work without specially privileged entities deserve a higher level than others. This info on levelling is missing and should be added. REF:2/FPR/Detail-Local/Relevant Families The four families are relevant to each other. This info should be contained. 3.4 Non Repudiation REF:2/FTE_NRO/Detail-Local/Non Repudiation The list of components given in this family is important but not comprehensive. The same statement applies for the respective components in the ISO criteria, so a combined and augmented approach is needed. Seven Parameters have to be distinguished. 1 What information is marked and assured? 2 In which cases is the Information marked? 3 To whom is the proof given? 4 When is the proof provided? 5 At which time is the proof provided? 6 How long can events be proven? 7 Quality of proof Details on this have already (but after the finishing of V 0.9) been given to members of the CCEB. The modelling instrument "Permitted operations" works fine with this approach. 4 Assurance Requirements 4.1 Risks through Tools REF:3/2/Approach/Risks through Tools The subversion of (software) tools is a special risk of IT compared to other technologies. The current CC only cover the configuration management for tools in the Class ALC. They neglect the risks caused by the developers of tools, e.g. transitive trojan horses or viruses introduced into compilers or editors. A good augmentation would be the introduction of proper components and assurance levels. 4.2 Missing Evaluation of Cryptographic Mechanisms REF:3/Approach/Cryptographic Mechanisms The rating of cryptographic mechanisms has to be international and as objective, compatible, and reproducible as possible. The delegation of responsibility for this important issue to national schemes might help to find consensus in the CCEB. However, trying to achieve certified secure systems by keeping cryptographic mechanisms secret, may not be adequate to the requirements of internationally used and needed communication networks. Important parts of the work are not covered by this restricted approach, which may devaluate the rest of the work. 4.3 Covert Channels REF:3/AVA_CCA/Detail - Global/Covert Channel Elimination To have a class "Covert Channel Analysis" is a good idea, but the main part of part 3 seems to be incomplete. The component CCA.4 "Elimination of all Covert Channels" which is given as a mapping for the CTCPEC does not show up in the main part 3. Even if elimination of all covert channels today seems to be an unsolvable problem the final target should at least be mentioned in criteria. 4.4 Evaluator Actions REF:3/Approach/Evaluator Actions and REF:1/C.4.4/Approach/Evaluator Actions To structure the assurance elements and to highlight the evaluator actions is a good idea for e v a l u a t i o n criteria. ---------------- End of Review --------------------------------