- Email: [email protected]
The ITSEC revision
Computer Fraud & Security Bulletin
June 7997
if it contravenes a rule. It was developed under a US government contract and has been tested on the SRI net over the past two years. Current applications are at the Los Alamos National Laboratories and in FBI systems. A commercial version of IDES will become available within the next 18 months, probably for an IBM mainframe implementation. Marty Silverman cited the current ignorance of users and the public perception that security is a dirty word. He called for a change in this attitude, that we should work towards making users responsible for the day to day implementation of system security. He also called for systems to be marketed with inbuilt security, which is both efficient and more cost effective. Pat Gallagher from the NSA spoke about the new, combined efforts of the NSA and NIST for increasing awareness, particularly in the public sector and government departments. But, he warned the audience, in computer security “what you get is what you pay for”. Lynn McNulty from NIST was the next speaker, and warned that the USA needs to start addressing the issue of data privacy, which has become a major issue in other parts of the world. The USA is currently covered by 1973 legislation, which has not been updated since. The session was followed by questions from the floor, and one addressed to Pat Gallagher asked about the status of potential relaxation of COCOM restrictions. “I don’t know that we’re doing that, are we?” was the somewhat surprised reply.
She recommended that any awareness campaign should be lively and entertaining, should be positive and avoid long list of ‘don’ts’ and ‘nots’. It needs to be persistent, varied and target specific. In response the user should get respect, praise, recognition, learning and satisfaction. Employees must end up believing that the threats are real, realize that they, personally, can be affected and know what they need to do if an incident occurs. One of the most popular sessions on the final day was that given by Sanford Sherizen on the subject of information security in the Soviet Union. Sherizen spoke about the ISSA delegation which had visited Russia in 1989, but the subject was one where many of the audience had something to contribute, and the talk frequently resembled a round table discussion. The conclusion seemed to be that almost all information technology is still under the strict control of government authorities, and that initiatives to improve security and information exchange should be approached with caution. Particularly disturbing was the news that the KGB are now advertising that their intelligence expertise is available for use by private enterprises.
THE ITSEC REVISION A response to the reviewers’ comments
Robert Wells from the Florida Lottery spoke about ‘Waking up the non-believer’ and identified nine excuses within an organization which block effective computer security. These
include “I
don’t want to know”; “its too costly”; “we’re too busy”; “we’ve been safe so far”; and “we don’t have anything important enough to protect”. For each he listed positive ways to overcome those objections and constructive ways of getting them to help. Mutt Daniel from BellSouth also spoke on the subject of motivation, maintaining that the critical question for users is “what’s in it for me?
01991
Four Nation Working Group Spring 199 1
Elsevier Science Publishers Ltd
In response to widespread distribution (6000 copies to over 20 countries) written comments relating to ltsec 1.0 were received before and during the international review conference which was sponsored by the European Commission in Brussels, 25-26 September 1990. The contribution made by reviewers has been of enormous value in preparing a revision of the Itsec. In all, approximately 100 written contributions were received from which a database of around 1000 individual detailed
7
Computer Fraud & Security Bulletin
points was constructed. Analysis of the database revealed a list of core issues of interest to respondents. Having taken the comments received during the review conference into account, this list now comprises 37 key issues which this response paper seeks to address. Many of the detailed comments were directly treatable as reviewers identified straightforward improvements or suggested an approach which was better than that originally proposed. As a direct result of the comments substantive improvements can be made in: l
l
l
Evaluation concepts, definitions and criteria. Context and scope (criteria, methodology, procedures). Editorial aspects (layout, style, explanations etc).
The revision provides for an extensive restructuring and careful annotation to simplify use of the ltsec and we are confident that it will be a more manageable document as a result. Notwithstanding the revisions, many central aspects of the ltsec philosophy, which derive directly from experience evaluation
effort,
in the international
remain
conceptually
unchanged. For example: l
Independence of any specific security policy or administration structure, in order to meet the ever changing control needs of various public and private enterprises.
l
l
l
8
Decoupling of functional specification from claimed Assurance, a proven approach, again providing flexibility of application, but one which must be constrained by the practical implementation of specific, well understood controls. Flexibility of functional class specification, with the predefined classes in the ltsec providing only examples of a much larger set of potential options. Distinction of Effectiveness and Correctness, examining both the developer’s adherence to
June 1991
specification effectiveness
and the operational of the Target of Evaluations
(TOE). l
Flexibility
of options
for specifications
languages and methods, including well defined roles for both natural language and a graded use of formal methods. l
Accepting standards increasing
reference to international definitions, reflecting the need for application of many
security definitions and processes as common elements of IT infrastructures in public and private enterprises. Many reviewers raised questions concerning the methods and procedures of evaluation and certification schemes, which are undeniably important, but beyond the scope of the Itsec. The ltsec authors adopted a deliberate strategy of separating such issues from the definition of the basic evaluation criteria (what is evaluated) while recognizing that future harmonization needs to take them into account. To that end a harmonized methodology manual (the ltsem - how the evaluation is done) is being prepared, with a first draft scheduled for publication by the end of 1991. This will still leave aside some issues of associated procedures, e.g. certification scheme rules, which would need to be addressed by the terms of any international mutual recognition agreement for evaluation results and certificates. Nevertheless, harmonized criteria and methods are seen as fundamental technical prerequisites to international mutual recognition, and the consequent avoidance of artificial barriers to trade, which are the ultimate goals of the ltsec initiative. To aid the process of further international harmonization and the development of a harmonized methodology, the ltsec will be adopted on a provisional basis in the national evaluation and certification schemes currently planned or operating in each of the four originating countries. This will provide practical experience of applying the ltsec without prejudice to the further harmonization process.
01991
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
June 1991
Each
of the main
issues
derived
from
analysis of the ltsec comment database is now presented, authors.
together with a response from the In some
cases,
points
of view
concerning an issue were more or less equally divided -this
is reflected by phrasing the issue
as a question rather than a statement. Some issues
do not conveniently
categorization
fall
into the
adopted and so appear under
more than one heading. The issues are grouped under the headings used by CEC conference
closely into line with the format used in the Correctness chapter.
rapporteur
during the review
and, for ease of reference,
each
issue is also labelled with the sequence number (in parentheses)
which
was
used
at the
Evaluation Criteria are nor set our in a consistent manner (31) This criticism is accepted by the working group. It will be treated in the next version of the ltsec by adopting a more consistent approach. Under Requirements for Content and Presentation, the criteria will identify information to be supplied by the sponsor. Under Requirements for Evidence, the criteria will identify things that the information supplied must show. Under Evaluator Actions, the criteria will identify what must be checked by the evaluator and what additional actions must be performed.
conference. Definitions Format/Structure Criricisms of the layour and style of the lrsec (27) The working group accepts that the layout and style of Version 1 .O of the ltsec made it difficult to use. This will be treated in the next version of the ltsec by adding paragraph numbers so that every paragraph in the criteria is uniquely identified. Paragraphs will be numbered sequentially within each chapter, except within the Correctness chapter, where details of each level will be separately numbered by level. The layout of levels will then enable the same numbered paragraph to address the same topic in each level. For example, paragraph El .34 will deal with Delivery and Configuration Evaluator Actions for Level El and E6.34 will deal with the same actions at Level E6. The running heading at the top of each page in the Correctness chapter will specify the level in question. The optional testing criteria at Level El will be clarified and made consistent with the description of non-mandatory criteria in the Introduction. In consequence, ltsec Level El with optional developer testing will then correspond closely to the correctness aspects of Tcsec Class Cl. The presentation of the effectiveness criteria will be brought more
01991
Elsevier Science Publishers Ltd
Should accountability and non-repudiation be considered as fundamental aspects of IT security? (8) There is general consensus that confidentiality, integrity and availability are the most commonly used high-level titles, and so the working group proposes no change to the Itsec. However, non-repudiation is an important aspect of communications security (data exchange in ltsec terminology). In the next version of the ltsec this will be emphasized by listing the IS0 headings from IS 7498-2 (which of course include non-repudiation) in the data exchange section of the Functionality chapter, to encourage the widespread and consistent use of these terms in functional specifications. Is the definition of inregn’ry right? (9) The working group accepts that some people have found the ltsec definition confusing; however, there is no consensus in the international community as to what a better definition of integrity might be. Thus no change to the ltsec is proposed. The working group recommends that in the future any internationally accepted definition that emerges, for example, from the current NCSC or NIST work, should be adopted.
9
Computer
Fraud & Security Bulletin
June 1991
In the next version of the ltsec the inconsistency between the Glossary and the introduction over the definition of aspects of security will be resolved, and the definitions of the Generic Headings ‘Accuracy’ and ‘Reliability of Service’ will be widened in scope.
in the next version of the ltsec by introducing a new concept of ‘security enforcing’ in addition to ‘security relevant’. This will then enable ‘security relevant’ to be used only where it is has the same meaning as the US Tcsec.
Essential definitions criteria (12)
The terminology used to describe semiformal and formal descnp tions is inconsistent (35)
are missing from the
This criticism is accepted by the working group; certain essential definitions were indeed missing or poorly explained. In particular, due to an oversight certain crucial
This criticism is accepted by the working group. This will be treated in the next version of the ltsec by rewording the relevant criteria in the Correctness chapter, and adding extra
verbs (state, describe and explain) were used throughout the ltsec in a special way which was never defined. This will be treated in the next version of the ltsec by modifying the Introduction to define this usage, in the same way that the special use of shall, may and will is currently defined. There will also be a number of additions to the Glossary.
explanations to the Functionality chapter. The order of presentation of information in the Functionality chapter will be improved.
How do the given definitions for the rating of minimum strength of mechanisms relate to integrity and availability? (16) The wording of these definitions was carefully chosen. It has been reassessed and no problems are seen in using the current definitions against these headings. No change to the ltsec is proposed. There are too many concepts for security functionality and its related documents (e.g. objectives, functions, mechanisms; Corporate, Sys tern, Technical Security Policies) (2 1) The working group disagrees and believes that all these terms are necessary and helpful - all being used in current practice. However, the structure of the Functionality chapter of the ltsec will be revised and more explanation of these terms provided. The meaning of ‘security relevant component’ is unclear (22) An alternative would be ‘trusted component’, but the working group considered that there were already as many different interpretations for the meaning of ‘trust’, as for ‘security relevant’. The problem will be treated
10
International
Standards
The Clark and Wilson Model is notable by its absence from the ltsec (24) It will be added, see also below. The definitions of the predefined functionality classes are inadequate and internally inconsistent (19) Annex A of Version 1 .O of the ltsec stated that the functionality classes it contained were intended only as guidelines, rather than as specifications of definitive standards. Furthermore, functionality may be defined by reference to recognized (external) standards. This should have been reiterated in the body of the document. The specification of standardized functionality classes is beyond the scope of the Itsec, being a matter (of considerable importance) for practitioners in the various market sectors. However, both Chapter 2 and Annex A of the next version of the ltsec will make it dearer that the given classes are intended as examples only. The classes will be renamed to distinguish between the hierarchical Tcsec-derived classes and the others. The Tcsec-derfved classes will be renamed F-Cl to F-63 to more clearly indicate the intended correspondence, while the others will be relabelled with a mnemonic relating to their intended objectives (e.g. F-IN, for the high integrity class).
01991
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
June 7991
Product Life Cycle Not enough is said in the ltsec about the need for Quality Controt/C?ualityManagement (13) The working group agrees that successful application of the ltsec criteria for assessment of correctness is only possible if there is an active quality assurance programme throughout the whole life cycle of a TOE. The need for quality at all stages of the product life cycle will be stressed in the ‘Approach’ section of the Correctness chapter. Criteria for objects under Configuration Control are impractical (34) The scope of these criteria was poorly defined. This will be treated in the next version of the ltsec by rewording the criteria to make it clear that they only apply to objects that are frozen, i.e. those objects that should only be changed in a controlled and audited manner. It will be made mandatory at Level El to identify uniquely the version of the TOE. The software development tool criteria are unclear and do not belong under Con figuration Control in any case (37) This criticism is accepted by the working group. This will be treated in the next version of the ltsec making Programming Languages and Compilers a separate and software-only aspect of the Development Environment. In addition, the relevant criteria will be simplified and made independent of evaluation or approval by third parties. Relevance
Those criteria that only apply to software implementation (such as criteria for programming languages and compilers) will be clearly identified as such. Purely hardware issues - such as control of electromagnetic emanations - are outside the intended scope of the Itsec, and a change will be made to the Scope chapter to state this. There is a minimum sensible Confidence Level for certain product Functionality Classes (3) The ltsec permits in principle, arbitrary combinations of functionality and assurance/confidence. However, certain combinations of functionality and assurance are sensible and some are not; intelligent application of pairings is required. For example, (F3, E2) in ltsec Version 1.O terms is a non-Tcsec combination which is required for many EC government applications. A change will be made to the Scope chapter of the next version of the ltsec to state that not all combinations of functionality and confidence will necessarily be sensible or useful. It is expected ranges of combinations will be established by practitioners in the different market sectors, appropriate to the requirements in those sectors.
of Criteria and Approach
Evaluation of hardware is ignored within the criteria ( 7) ltsec Version 1 .O did not ignore considerations of hardware, although the criteria as issued were phrased excessively in terms of software evaluation. Implementations in hardware can be treated by a parallel approach; for example, by examining hardware logic specifications whenever requirements are expressed in terms of source code.
01991
This will be treated in the next version of the ltsec by modifying the Scope chapter to indicate explicitly that the criteria can be applied to security functions implemented in hardware. References to the method of implementation will refer to hardware alternatives where appropriate.
Elsevier Science Publishers Ltd
The ltsec does not address the problems of building secure systems out of evaluated products (4) The problem is being considered by the working group in the ltsec companion volume on evaluation methodology, the Itsem, currently being developed. However, this is, in part, a matter for national evaluation and certification schemes to set down what product evaluation results and certificates are acceptable under that scheme for reuse in a system evaluation, without repetition of the
11
Computer Fraud & Security Bulletin
June 1991
product evaluation work. It is thus beyond the scope of the ltsec to address it directly.
specify preclusion functions -
a requirement for
the absence of known channels of unacceptably high bandwidth that can transmit information
However, the Functionality chapter of the next version of the ltsec will be modified to require a product rationale as part of all product security targets. This will give the necessary assumptions about the environment within which the product is intended to be used to enable product evaluators to confirm that there are no missing assumptions and for system evaluators to check that the assumptions hold in the actual system environment. The format of Claims Documents in Annex B will be similarly extended. The ltsec is biased towards confidentiality (5) This is perhaps an inevitable criticism of ltsec Version 1 .O in that the security problems of confidentiality are better understood than those of integrity or availability. A change will be made to the next version of the ltsec to add the Clark and Wilson integrity model to the list of example models, although to be of practical value there would need to be a functionality class corresponding to the integrity requirements for commercial online transaction processing systems expressed
by that model.
The working group notes with interest that one of the
working
groups
subcommittee Committee
of a new
of the Joint ISO-IEC
One (JTCl)
is considering a work
item to develop functionality commercial sectors. Another
factor contributing
issue is that a security confidentiality requirements constrain
information
security Technical
classes
for
to the above
target with no has no need to
leakage
through covert
channels, but could not pass evaluation against
between
processes
access rights Guideline
without
verification
of
and then to refer to the Tcsec
for guidance
on acceptability.
Assessment of effectiveness against a security target specifying such a class would examine the convert channels that had been discovered and determine
if, under the circumstances
(e.g.
auditability, context), the maximum bandwidth of any channel is unacceptable. Should system evaluation include the people and procedural aspects of the system? (7) The Operational Environment correctness criteria of ltsec Version 1 .O were biased towards TOES based upon a single site with dedicated operational staff bearing security responsibilities. Clearly not all TOES match this description. This will be treated in the next version of the ltsec by modifying the Correctness chapter to remove this bias. There will be a distinction between the security responsibilities of end-users and those responsible for the adminstration of security. Levels E4 and above are unsuitable for the commercial world (7) Many such criticisms treated high security and high assurance as being synonymous, whereas the working group considers that they are not. High security implies appropriate functionality and environmental measures as well as high assurance of functionality. The ltsec levels El to E6 merely form a scale for use as a metric for assurance, and other (non commercial) market sectors do need the higher points of that scale. This will be mentioned in the Scope chapter of the next version of the Itsec.
the ltsec Version 1 .O at level E4 or higher. This represents an error in Version 1 .O of the Itsec. This will be treated in the next version of the ltsec by removing the corrections criteria specific to covert channels. Instead, covert channels will be treated example
as precluded
functionality
functionality.
The
classes that match the
Tcsec Classes B2 and B3/Al will be modified to
12
Can one set of criteria real/y address both products and systems? (26) The use of identical criteria to evaluate both systems and products has been proven to work within the national schemes of several of the participating countries, and has been shown to be of value in assisting systems integrators to use evaluated products in
01991
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
June 1991
producing secure systems. The only distinguishing factor between systems and products in evaluation is whether the threats to security are real or assumed. No change to the ltsec is proposed. Functionality The definitions of the pfedefined functionality classes are inadequate and internally inconsistent (19) The classes are exemplary only. A justification should be provided as part of all predefined functionality classes (20) A choice of functions included. The examples in Annex A will be upgraded accordingly. Assurance/Confidence
Criteria
The treatment of effectiveness is too subjective (2) Subjectivity is a real problem for evaluation against any criteria. In particular, assessment of effectiveness is a relatively new concept, and will inevitably contain some subjective elements, although this should reduce with greater practical evaluation experience. However, it is certainly unreasonable for failure on grounds of effectiveness to be purely a matter for evaluator judgement. This will be treated in the next version of the ltsec by modifying the Effectiveness chapter to require evaluators to find exploitable security vulnerabilities for a TOE to be failed on effectiveness grounds. In addition, a section on the implied Certification Process underlying use of the ltsec will be added to the Scope chapter. This will make it clear that national certification bodies using the criteria must adopt practical measures (e.g. selection and control of approval evaluators) to maintain the uniformity of certified evaluation results, despite a residual level of subjectivity in the criteria. Automatic award of EO in the event of any failure to meet criteria is too harsh (6) This criticism is accepted by the working
01991
Eisevier Science Publishers Ltd
group. it will be treated in the next version of the itsec by adding a new chapter on the Results of Evaluation. This will permit a TOE to be withdrawn from evaluation by the evaluation sponsor as an alternative to being awarded EO. It will also require that, for a TOE failed on grounds of effectiveness, an exploitable vulnerability that has not been eliminated by the developer must be found and documented. it will permit a TOE that cannot meet the criteria for its targeted evaluation level, but where no exploitable vulnerability has been found, to be considered for award of a lower level. The correctness criteria are too stringent or are wrong (11) The working group accepts that many minor inconsistencies and actual errors were found by respondents in the correctness criteria of Version 1 .O of the ltsec and these have been corrected. Concerning stringency, however, the ltsec criteria were often deliberately more precise than previous criteria in order to reduce subjectivity in the evaluation process and to speed up evaluation; this does not mean that meeting the ltsec criteria will be more difficult in practice. This will be treated in the next version of the ltsec by improving the wording of numerous detailed criteria. Certain criteria will be better explained, or more carefully bounded in scope. Ease Of Use should nor be a criterion (14) The working group disagrees. A TOE whose management and configuration is so complex that nobody can be sure whether the security measures are properly enabled cannot be considered effective. However, the scope of the Ease of Use aspect of assessment of effectiveness was poorly stated and bounded. This will be treated in the next version of the ltsec by modifying the definition of this aspect of effectiveness to make it clear that consideration is restricted to determining whether the TOE can be configurated or used in a way which is insecure when it is stated to be secure or could reasonably be believed to be secure. Does rhe faring of effectiveness rime? (17)
degrade with
13
Computer Fraud & Security Bulletin
A rating of effectiveness should remain valid provided that the threats considered in its assessment do not change. If threats do change with time, it may then be necessary to revise the required security target, but how to manage this process of change is beyond the scope of the ltsec. No change to the ltsec is proposed. Is effectiveness more important than correctness? (18) Yes; from the intuitive perspective used when selecting a product to purchase, it would have made more sense to put the effectiveness chapter first. This will be treated in the next version of the ltsec by swapping the order of the chapters on correctness and effectiveness. In addition, the introductions to these chapters will indicate that assessment of correctness and effectiveness will normally take place in parallel (although since effectiveness must consider the impact of all vulnerabilities found during evaluation of correctness, it clearly cannot be completed until after the investigation of correctness is completed). Is evaluation of the strength of mechanisms mandatory at Level El or not? (32) The criteria in Version 1 .O of the ltsec for this topic were inconsistent. This will be corrected in the next version of the Itsec. Rating of strength of mechanisms will be made compulsory at Level El. However, the criteria will be adjusted to remove the requirement for the provision of design level information on the mechanisms employed at Level El. Object Code Analysis Criterion at Level E6 is unusable (33) The intention of this criterion was poorly explained. It was intended as a way of investigating suspected Trojan horse attacks where the executable code did not fully correspond to the source code provided. This will be treated in the next version of the ltsec by rewording the criterion to make its objective clearer.
14
June 1991
Specification
Languages
Why is a Format Description required at Level E4? (36) The working group believes that the semiformal specification of security functions introduced at this level needs to be supported by a precise (and therefore formal) statement of the underlying security objectives of the security target. This is necessary to understand the intended relationships between functions. The working group accepts that these criteria were poorly expressed and poorly explained. This will be treated in the next version of the ltsec by making a clearer distinction between the specification of security enforcing functions (in both semiformal and informal styles for levels E4 and E5; formal and informal for E6), and the specification of a Formal Model of Security Policy at E4 and higher as a definition of the undertying concept of security supported by the security target. It will be made clear that this criterion can be satisfied by reference to an appropriate published model, together with an (informal) interpretation of that model in terms of the users, process and objects defined in the security target. The software development tool criteria are unclear and do not belong under Configuration Control in any case (37) See above remarks concerning ‘approval’ of programming languages. Harmonization Mapping to concepts of TCB and Reference Monitor needs to be stronger (23) The ltsec is intended to have a wider coverage than the confidentiality requirements addressed by the Tcsec. The working group considers that it would be inappropriate to mandate a TCB/reference monitor approach in all possible circumstances. However, the ltsec criteria permit a security target to require the use of a particular mechanism to implement a particular security function or functions defined within the target. There is therefore no reason
01991
Elsevier Science Publishers Ltd
June 1991
Computer Fraud & Security Bulletin
why a particular predefined class cannot mandate use of a reference monitor.
considered to be matters for national schemes and therefore beyond the scope of the ltsec document.
This will be treated in the next version of the ltsec by adding a section on the relationship
The criteria must support a Ratings
with the Tcsec to the Scope chapter, making it clear that a functionality class can be constrained to use a particular mechanism (such as the reference monitor concept) as
Maintenance Programme (RAMP) (29) Ratings maintenance will be one of the topics addressed (as far as is possible) in a new volume on evaluation methodology.
part of the definition of a security target. Furthermore, in a number of places the wording of the ltsec will be made identical to that of the Tcsec where there is identical intent, but where at present the ltsec use slightly different words.
However, the working group considers that this is also a matter for national evaluation schemes, since although full re-evaluation will often not be needed, independent judgement is necessary following all changes, not simply self-certification by the sponsor. The working group is following the US experiment with RAMP with interest.
The ltsec must address TCB subsetting (25) The working group believes that the current ltsec approach will be applicable to the security evaluation of database products. No change to the ltsec is proposed. Evaluation/Certification
Process
Should evaluators repeat the Sponsor’s threat analysis? (15) No. This was an error in Version 1 .O of the Itsec. Threats are defined within the security target and are not a matter for reassessment by the evaluator. This will be treated in the next version of the ltsec by removal of the offending criterion from the Evaluator Actions for Suitability of Functionality. Scheme information is necessary to interpret the ltsec in various areas (28) There are several important policy issues, necessary for use of the criteria, but not directly addressed by the Itsec. The working group believes that these matters for consideration either in the companion volume, Itsem, or within the national evaluation and certification schemes that will use the ltsec (and Itsem). It is likely that some scheme details will vary from country to country.
The need for ratings maintenance will be acknowledged in the new section on the certification process in the Scope chapter of the next version of the Itsec. Details of the actual procedures for re-certification of evaluated TOES (which may involve partial or complete re-evaluation) will be addressed as far as possible in the Itsem, but are also a matter for national certification schemes. Cost of evaluations is a major concern to vendors (29). The working group notes and accepts this comment. In particular, the practical difficulties in evaluation of a distributed development environment spread over several countries is a real problem that had not been previously envisaged by the working group. Nevertheless, the working group believes the structure of the ltsec criteria will assist in keeping costs down by, for example, defining precise roles and tasks for both sponsors and evaluators. No respondent identified a practical way in which the ltsec could be changed to further reduce costs without reducing confidence. Thus no change to the ltsec is proposed.
This will be treated in the next version of the ltsec by adding a section on the certification process to the Scope chapter of the criteria. This section will indicate the key issues
01991
Elsevier Science Publishers Ltd
15
June 7997
if it contravenes a rule. It was developed under a US government contract and has been tested on the SRI net over the past two years. Current applications are at the Los Alamos National Laboratories and in FBI systems. A commercial version of IDES will become available within the next 18 months, probably for an IBM mainframe implementation. Marty Silverman cited the current ignorance of users and the public perception that security is a dirty word. He called for a change in this attitude, that we should work towards making users responsible for the day to day implementation of system security. He also called for systems to be marketed with inbuilt security, which is both efficient and more cost effective. Pat Gallagher from the NSA spoke about the new, combined efforts of the NSA and NIST for increasing awareness, particularly in the public sector and government departments. But, he warned the audience, in computer security “what you get is what you pay for”. Lynn McNulty from NIST was the next speaker, and warned that the USA needs to start addressing the issue of data privacy, which has become a major issue in other parts of the world. The USA is currently covered by 1973 legislation, which has not been updated since. The session was followed by questions from the floor, and one addressed to Pat Gallagher asked about the status of potential relaxation of COCOM restrictions. “I don’t know that we’re doing that, are we?” was the somewhat surprised reply.
She recommended that any awareness campaign should be lively and entertaining, should be positive and avoid long list of ‘don’ts’ and ‘nots’. It needs to be persistent, varied and target specific. In response the user should get respect, praise, recognition, learning and satisfaction. Employees must end up believing that the threats are real, realize that they, personally, can be affected and know what they need to do if an incident occurs. One of the most popular sessions on the final day was that given by Sanford Sherizen on the subject of information security in the Soviet Union. Sherizen spoke about the ISSA delegation which had visited Russia in 1989, but the subject was one where many of the audience had something to contribute, and the talk frequently resembled a round table discussion. The conclusion seemed to be that almost all information technology is still under the strict control of government authorities, and that initiatives to improve security and information exchange should be approached with caution. Particularly disturbing was the news that the KGB are now advertising that their intelligence expertise is available for use by private enterprises.
THE ITSEC REVISION A response to the reviewers’ comments
Robert Wells from the Florida Lottery spoke about ‘Waking up the non-believer’ and identified nine excuses within an organization which block effective computer security. These
include “I
don’t want to know”; “its too costly”; “we’re too busy”; “we’ve been safe so far”; and “we don’t have anything important enough to protect”. For each he listed positive ways to overcome those objections and constructive ways of getting them to help. Mutt Daniel from BellSouth also spoke on the subject of motivation, maintaining that the critical question for users is “what’s in it for me?
01991
Four Nation Working Group Spring 199 1
Elsevier Science Publishers Ltd
In response to widespread distribution (6000 copies to over 20 countries) written comments relating to ltsec 1.0 were received before and during the international review conference which was sponsored by the European Commission in Brussels, 25-26 September 1990. The contribution made by reviewers has been of enormous value in preparing a revision of the Itsec. In all, approximately 100 written contributions were received from which a database of around 1000 individual detailed
7
Computer Fraud & Security Bulletin
points was constructed. Analysis of the database revealed a list of core issues of interest to respondents. Having taken the comments received during the review conference into account, this list now comprises 37 key issues which this response paper seeks to address. Many of the detailed comments were directly treatable as reviewers identified straightforward improvements or suggested an approach which was better than that originally proposed. As a direct result of the comments substantive improvements can be made in: l
l
l
Evaluation concepts, definitions and criteria. Context and scope (criteria, methodology, procedures). Editorial aspects (layout, style, explanations etc).
The revision provides for an extensive restructuring and careful annotation to simplify use of the ltsec and we are confident that it will be a more manageable document as a result. Notwithstanding the revisions, many central aspects of the ltsec philosophy, which derive directly from experience evaluation
effort,
in the international
remain
conceptually
unchanged. For example: l
Independence of any specific security policy or administration structure, in order to meet the ever changing control needs of various public and private enterprises.
l
l
l
8
Decoupling of functional specification from claimed Assurance, a proven approach, again providing flexibility of application, but one which must be constrained by the practical implementation of specific, well understood controls. Flexibility of functional class specification, with the predefined classes in the ltsec providing only examples of a much larger set of potential options. Distinction of Effectiveness and Correctness, examining both the developer’s adherence to
June 1991
specification effectiveness
and the operational of the Target of Evaluations
(TOE). l
Flexibility
of options
for specifications
languages and methods, including well defined roles for both natural language and a graded use of formal methods. l
Accepting standards increasing
reference to international definitions, reflecting the need for application of many
security definitions and processes as common elements of IT infrastructures in public and private enterprises. Many reviewers raised questions concerning the methods and procedures of evaluation and certification schemes, which are undeniably important, but beyond the scope of the Itsec. The ltsec authors adopted a deliberate strategy of separating such issues from the definition of the basic evaluation criteria (what is evaluated) while recognizing that future harmonization needs to take them into account. To that end a harmonized methodology manual (the ltsem - how the evaluation is done) is being prepared, with a first draft scheduled for publication by the end of 1991. This will still leave aside some issues of associated procedures, e.g. certification scheme rules, which would need to be addressed by the terms of any international mutual recognition agreement for evaluation results and certificates. Nevertheless, harmonized criteria and methods are seen as fundamental technical prerequisites to international mutual recognition, and the consequent avoidance of artificial barriers to trade, which are the ultimate goals of the ltsec initiative. To aid the process of further international harmonization and the development of a harmonized methodology, the ltsec will be adopted on a provisional basis in the national evaluation and certification schemes currently planned or operating in each of the four originating countries. This will provide practical experience of applying the ltsec without prejudice to the further harmonization process.
01991
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
June 1991
Each
of the main
issues
derived
from
analysis of the ltsec comment database is now presented, authors.
together with a response from the In some
cases,
points
of view
concerning an issue were more or less equally divided -this
is reflected by phrasing the issue
as a question rather than a statement. Some issues
do not conveniently
categorization
fall
into the
adopted and so appear under
more than one heading. The issues are grouped under the headings used by CEC conference
closely into line with the format used in the Correctness chapter.
rapporteur
during the review
and, for ease of reference,
each
issue is also labelled with the sequence number (in parentheses)
which
was
used
at the
Evaluation Criteria are nor set our in a consistent manner (31) This criticism is accepted by the working group. It will be treated in the next version of the ltsec by adopting a more consistent approach. Under Requirements for Content and Presentation, the criteria will identify information to be supplied by the sponsor. Under Requirements for Evidence, the criteria will identify things that the information supplied must show. Under Evaluator Actions, the criteria will identify what must be checked by the evaluator and what additional actions must be performed.
conference. Definitions Format/Structure Criricisms of the layour and style of the lrsec (27) The working group accepts that the layout and style of Version 1 .O of the ltsec made it difficult to use. This will be treated in the next version of the ltsec by adding paragraph numbers so that every paragraph in the criteria is uniquely identified. Paragraphs will be numbered sequentially within each chapter, except within the Correctness chapter, where details of each level will be separately numbered by level. The layout of levels will then enable the same numbered paragraph to address the same topic in each level. For example, paragraph El .34 will deal with Delivery and Configuration Evaluator Actions for Level El and E6.34 will deal with the same actions at Level E6. The running heading at the top of each page in the Correctness chapter will specify the level in question. The optional testing criteria at Level El will be clarified and made consistent with the description of non-mandatory criteria in the Introduction. In consequence, ltsec Level El with optional developer testing will then correspond closely to the correctness aspects of Tcsec Class Cl. The presentation of the effectiveness criteria will be brought more
01991
Elsevier Science Publishers Ltd
Should accountability and non-repudiation be considered as fundamental aspects of IT security? (8) There is general consensus that confidentiality, integrity and availability are the most commonly used high-level titles, and so the working group proposes no change to the Itsec. However, non-repudiation is an important aspect of communications security (data exchange in ltsec terminology). In the next version of the ltsec this will be emphasized by listing the IS0 headings from IS 7498-2 (which of course include non-repudiation) in the data exchange section of the Functionality chapter, to encourage the widespread and consistent use of these terms in functional specifications. Is the definition of inregn’ry right? (9) The working group accepts that some people have found the ltsec definition confusing; however, there is no consensus in the international community as to what a better definition of integrity might be. Thus no change to the ltsec is proposed. The working group recommends that in the future any internationally accepted definition that emerges, for example, from the current NCSC or NIST work, should be adopted.
9
Computer
Fraud & Security Bulletin
June 1991
In the next version of the ltsec the inconsistency between the Glossary and the introduction over the definition of aspects of security will be resolved, and the definitions of the Generic Headings ‘Accuracy’ and ‘Reliability of Service’ will be widened in scope.
in the next version of the ltsec by introducing a new concept of ‘security enforcing’ in addition to ‘security relevant’. This will then enable ‘security relevant’ to be used only where it is has the same meaning as the US Tcsec.
Essential definitions criteria (12)
The terminology used to describe semiformal and formal descnp tions is inconsistent (35)
are missing from the
This criticism is accepted by the working group; certain essential definitions were indeed missing or poorly explained. In particular, due to an oversight certain crucial
This criticism is accepted by the working group. This will be treated in the next version of the ltsec by rewording the relevant criteria in the Correctness chapter, and adding extra
verbs (state, describe and explain) were used throughout the ltsec in a special way which was never defined. This will be treated in the next version of the ltsec by modifying the Introduction to define this usage, in the same way that the special use of shall, may and will is currently defined. There will also be a number of additions to the Glossary.
explanations to the Functionality chapter. The order of presentation of information in the Functionality chapter will be improved.
How do the given definitions for the rating of minimum strength of mechanisms relate to integrity and availability? (16) The wording of these definitions was carefully chosen. It has been reassessed and no problems are seen in using the current definitions against these headings. No change to the ltsec is proposed. There are too many concepts for security functionality and its related documents (e.g. objectives, functions, mechanisms; Corporate, Sys tern, Technical Security Policies) (2 1) The working group disagrees and believes that all these terms are necessary and helpful - all being used in current practice. However, the structure of the Functionality chapter of the ltsec will be revised and more explanation of these terms provided. The meaning of ‘security relevant component’ is unclear (22) An alternative would be ‘trusted component’, but the working group considered that there were already as many different interpretations for the meaning of ‘trust’, as for ‘security relevant’. The problem will be treated
10
International
Standards
The Clark and Wilson Model is notable by its absence from the ltsec (24) It will be added, see also below. The definitions of the predefined functionality classes are inadequate and internally inconsistent (19) Annex A of Version 1 .O of the ltsec stated that the functionality classes it contained were intended only as guidelines, rather than as specifications of definitive standards. Furthermore, functionality may be defined by reference to recognized (external) standards. This should have been reiterated in the body of the document. The specification of standardized functionality classes is beyond the scope of the Itsec, being a matter (of considerable importance) for practitioners in the various market sectors. However, both Chapter 2 and Annex A of the next version of the ltsec will make it dearer that the given classes are intended as examples only. The classes will be renamed to distinguish between the hierarchical Tcsec-derived classes and the others. The Tcsec-derfved classes will be renamed F-Cl to F-63 to more clearly indicate the intended correspondence, while the others will be relabelled with a mnemonic relating to their intended objectives (e.g. F-IN, for the high integrity class).
01991
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
June 7991
Product Life Cycle Not enough is said in the ltsec about the need for Quality Controt/C?ualityManagement (13) The working group agrees that successful application of the ltsec criteria for assessment of correctness is only possible if there is an active quality assurance programme throughout the whole life cycle of a TOE. The need for quality at all stages of the product life cycle will be stressed in the ‘Approach’ section of the Correctness chapter. Criteria for objects under Configuration Control are impractical (34) The scope of these criteria was poorly defined. This will be treated in the next version of the ltsec by rewording the criteria to make it clear that they only apply to objects that are frozen, i.e. those objects that should only be changed in a controlled and audited manner. It will be made mandatory at Level El to identify uniquely the version of the TOE. The software development tool criteria are unclear and do not belong under Con figuration Control in any case (37) This criticism is accepted by the working group. This will be treated in the next version of the ltsec making Programming Languages and Compilers a separate and software-only aspect of the Development Environment. In addition, the relevant criteria will be simplified and made independent of evaluation or approval by third parties. Relevance
Those criteria that only apply to software implementation (such as criteria for programming languages and compilers) will be clearly identified as such. Purely hardware issues - such as control of electromagnetic emanations - are outside the intended scope of the Itsec, and a change will be made to the Scope chapter to state this. There is a minimum sensible Confidence Level for certain product Functionality Classes (3) The ltsec permits in principle, arbitrary combinations of functionality and assurance/confidence. However, certain combinations of functionality and assurance are sensible and some are not; intelligent application of pairings is required. For example, (F3, E2) in ltsec Version 1.O terms is a non-Tcsec combination which is required for many EC government applications. A change will be made to the Scope chapter of the next version of the ltsec to state that not all combinations of functionality and confidence will necessarily be sensible or useful. It is expected ranges of combinations will be established by practitioners in the different market sectors, appropriate to the requirements in those sectors.
of Criteria and Approach
Evaluation of hardware is ignored within the criteria ( 7) ltsec Version 1 .O did not ignore considerations of hardware, although the criteria as issued were phrased excessively in terms of software evaluation. Implementations in hardware can be treated by a parallel approach; for example, by examining hardware logic specifications whenever requirements are expressed in terms of source code.
01991
This will be treated in the next version of the ltsec by modifying the Scope chapter to indicate explicitly that the criteria can be applied to security functions implemented in hardware. References to the method of implementation will refer to hardware alternatives where appropriate.
Elsevier Science Publishers Ltd
The ltsec does not address the problems of building secure systems out of evaluated products (4) The problem is being considered by the working group in the ltsec companion volume on evaluation methodology, the Itsem, currently being developed. However, this is, in part, a matter for national evaluation and certification schemes to set down what product evaluation results and certificates are acceptable under that scheme for reuse in a system evaluation, without repetition of the
11
Computer Fraud & Security Bulletin
June 1991
product evaluation work. It is thus beyond the scope of the ltsec to address it directly.
specify preclusion functions -
a requirement for
the absence of known channels of unacceptably high bandwidth that can transmit information
However, the Functionality chapter of the next version of the ltsec will be modified to require a product rationale as part of all product security targets. This will give the necessary assumptions about the environment within which the product is intended to be used to enable product evaluators to confirm that there are no missing assumptions and for system evaluators to check that the assumptions hold in the actual system environment. The format of Claims Documents in Annex B will be similarly extended. The ltsec is biased towards confidentiality (5) This is perhaps an inevitable criticism of ltsec Version 1 .O in that the security problems of confidentiality are better understood than those of integrity or availability. A change will be made to the next version of the ltsec to add the Clark and Wilson integrity model to the list of example models, although to be of practical value there would need to be a functionality class corresponding to the integrity requirements for commercial online transaction processing systems expressed
by that model.
The working group notes with interest that one of the
working
groups
subcommittee Committee
of a new
of the Joint ISO-IEC
One (JTCl)
is considering a work
item to develop functionality commercial sectors. Another
factor contributing
issue is that a security confidentiality requirements constrain
information
security Technical
classes
for
to the above
target with no has no need to
leakage
through covert
channels, but could not pass evaluation against
between
processes
access rights Guideline
without
verification
of
and then to refer to the Tcsec
for guidance
on acceptability.
Assessment of effectiveness against a security target specifying such a class would examine the convert channels that had been discovered and determine
if, under the circumstances
(e.g.
auditability, context), the maximum bandwidth of any channel is unacceptable. Should system evaluation include the people and procedural aspects of the system? (7) The Operational Environment correctness criteria of ltsec Version 1 .O were biased towards TOES based upon a single site with dedicated operational staff bearing security responsibilities. Clearly not all TOES match this description. This will be treated in the next version of the ltsec by modifying the Correctness chapter to remove this bias. There will be a distinction between the security responsibilities of end-users and those responsible for the adminstration of security. Levels E4 and above are unsuitable for the commercial world (7) Many such criticisms treated high security and high assurance as being synonymous, whereas the working group considers that they are not. High security implies appropriate functionality and environmental measures as well as high assurance of functionality. The ltsec levels El to E6 merely form a scale for use as a metric for assurance, and other (non commercial) market sectors do need the higher points of that scale. This will be mentioned in the Scope chapter of the next version of the Itsec.
the ltsec Version 1 .O at level E4 or higher. This represents an error in Version 1 .O of the Itsec. This will be treated in the next version of the ltsec by removing the corrections criteria specific to covert channels. Instead, covert channels will be treated example
as precluded
functionality
functionality.
The
classes that match the
Tcsec Classes B2 and B3/Al will be modified to
12
Can one set of criteria real/y address both products and systems? (26) The use of identical criteria to evaluate both systems and products has been proven to work within the national schemes of several of the participating countries, and has been shown to be of value in assisting systems integrators to use evaluated products in
01991
Elsevier Science Publishers Ltd
Computer Fraud & Security Bulletin
June 1991
producing secure systems. The only distinguishing factor between systems and products in evaluation is whether the threats to security are real or assumed. No change to the ltsec is proposed. Functionality The definitions of the pfedefined functionality classes are inadequate and internally inconsistent (19) The classes are exemplary only. A justification should be provided as part of all predefined functionality classes (20) A choice of functions included. The examples in Annex A will be upgraded accordingly. Assurance/Confidence
Criteria
The treatment of effectiveness is too subjective (2) Subjectivity is a real problem for evaluation against any criteria. In particular, assessment of effectiveness is a relatively new concept, and will inevitably contain some subjective elements, although this should reduce with greater practical evaluation experience. However, it is certainly unreasonable for failure on grounds of effectiveness to be purely a matter for evaluator judgement. This will be treated in the next version of the ltsec by modifying the Effectiveness chapter to require evaluators to find exploitable security vulnerabilities for a TOE to be failed on effectiveness grounds. In addition, a section on the implied Certification Process underlying use of the ltsec will be added to the Scope chapter. This will make it clear that national certification bodies using the criteria must adopt practical measures (e.g. selection and control of approval evaluators) to maintain the uniformity of certified evaluation results, despite a residual level of subjectivity in the criteria. Automatic award of EO in the event of any failure to meet criteria is too harsh (6) This criticism is accepted by the working
01991
Eisevier Science Publishers Ltd
group. it will be treated in the next version of the itsec by adding a new chapter on the Results of Evaluation. This will permit a TOE to be withdrawn from evaluation by the evaluation sponsor as an alternative to being awarded EO. It will also require that, for a TOE failed on grounds of effectiveness, an exploitable vulnerability that has not been eliminated by the developer must be found and documented. it will permit a TOE that cannot meet the criteria for its targeted evaluation level, but where no exploitable vulnerability has been found, to be considered for award of a lower level. The correctness criteria are too stringent or are wrong (11) The working group accepts that many minor inconsistencies and actual errors were found by respondents in the correctness criteria of Version 1 .O of the ltsec and these have been corrected. Concerning stringency, however, the ltsec criteria were often deliberately more precise than previous criteria in order to reduce subjectivity in the evaluation process and to speed up evaluation; this does not mean that meeting the ltsec criteria will be more difficult in practice. This will be treated in the next version of the ltsec by improving the wording of numerous detailed criteria. Certain criteria will be better explained, or more carefully bounded in scope. Ease Of Use should nor be a criterion (14) The working group disagrees. A TOE whose management and configuration is so complex that nobody can be sure whether the security measures are properly enabled cannot be considered effective. However, the scope of the Ease of Use aspect of assessment of effectiveness was poorly stated and bounded. This will be treated in the next version of the ltsec by modifying the definition of this aspect of effectiveness to make it clear that consideration is restricted to determining whether the TOE can be configurated or used in a way which is insecure when it is stated to be secure or could reasonably be believed to be secure. Does rhe faring of effectiveness rime? (17)
degrade with
13
Computer Fraud & Security Bulletin
A rating of effectiveness should remain valid provided that the threats considered in its assessment do not change. If threats do change with time, it may then be necessary to revise the required security target, but how to manage this process of change is beyond the scope of the ltsec. No change to the ltsec is proposed. Is effectiveness more important than correctness? (18) Yes; from the intuitive perspective used when selecting a product to purchase, it would have made more sense to put the effectiveness chapter first. This will be treated in the next version of the ltsec by swapping the order of the chapters on correctness and effectiveness. In addition, the introductions to these chapters will indicate that assessment of correctness and effectiveness will normally take place in parallel (although since effectiveness must consider the impact of all vulnerabilities found during evaluation of correctness, it clearly cannot be completed until after the investigation of correctness is completed). Is evaluation of the strength of mechanisms mandatory at Level El or not? (32) The criteria in Version 1 .O of the ltsec for this topic were inconsistent. This will be corrected in the next version of the Itsec. Rating of strength of mechanisms will be made compulsory at Level El. However, the criteria will be adjusted to remove the requirement for the provision of design level information on the mechanisms employed at Level El. Object Code Analysis Criterion at Level E6 is unusable (33) The intention of this criterion was poorly explained. It was intended as a way of investigating suspected Trojan horse attacks where the executable code did not fully correspond to the source code provided. This will be treated in the next version of the ltsec by rewording the criterion to make its objective clearer.
14
June 1991
Specification
Languages
Why is a Format Description required at Level E4? (36) The working group believes that the semiformal specification of security functions introduced at this level needs to be supported by a precise (and therefore formal) statement of the underlying security objectives of the security target. This is necessary to understand the intended relationships between functions. The working group accepts that these criteria were poorly expressed and poorly explained. This will be treated in the next version of the ltsec by making a clearer distinction between the specification of security enforcing functions (in both semiformal and informal styles for levels E4 and E5; formal and informal for E6), and the specification of a Formal Model of Security Policy at E4 and higher as a definition of the undertying concept of security supported by the security target. It will be made clear that this criterion can be satisfied by reference to an appropriate published model, together with an (informal) interpretation of that model in terms of the users, process and objects defined in the security target. The software development tool criteria are unclear and do not belong under Configuration Control in any case (37) See above remarks concerning ‘approval’ of programming languages. Harmonization Mapping to concepts of TCB and Reference Monitor needs to be stronger (23) The ltsec is intended to have a wider coverage than the confidentiality requirements addressed by the Tcsec. The working group considers that it would be inappropriate to mandate a TCB/reference monitor approach in all possible circumstances. However, the ltsec criteria permit a security target to require the use of a particular mechanism to implement a particular security function or functions defined within the target. There is therefore no reason
01991
Elsevier Science Publishers Ltd
June 1991
Computer Fraud & Security Bulletin
why a particular predefined class cannot mandate use of a reference monitor.
considered to be matters for national schemes and therefore beyond the scope of the ltsec document.
This will be treated in the next version of the ltsec by adding a section on the relationship
The criteria must support a Ratings
with the Tcsec to the Scope chapter, making it clear that a functionality class can be constrained to use a particular mechanism (such as the reference monitor concept) as
Maintenance Programme (RAMP) (29) Ratings maintenance will be one of the topics addressed (as far as is possible) in a new volume on evaluation methodology.
part of the definition of a security target. Furthermore, in a number of places the wording of the ltsec will be made identical to that of the Tcsec where there is identical intent, but where at present the ltsec use slightly different words.
However, the working group considers that this is also a matter for national evaluation schemes, since although full re-evaluation will often not be needed, independent judgement is necessary following all changes, not simply self-certification by the sponsor. The working group is following the US experiment with RAMP with interest.
The ltsec must address TCB subsetting (25) The working group believes that the current ltsec approach will be applicable to the security evaluation of database products. No change to the ltsec is proposed. Evaluation/Certification
Process
Should evaluators repeat the Sponsor’s threat analysis? (15) No. This was an error in Version 1 .O of the Itsec. Threats are defined within the security target and are not a matter for reassessment by the evaluator. This will be treated in the next version of the ltsec by removal of the offending criterion from the Evaluator Actions for Suitability of Functionality. Scheme information is necessary to interpret the ltsec in various areas (28) There are several important policy issues, necessary for use of the criteria, but not directly addressed by the Itsec. The working group believes that these matters for consideration either in the companion volume, Itsem, or within the national evaluation and certification schemes that will use the ltsec (and Itsem). It is likely that some scheme details will vary from country to country.
The need for ratings maintenance will be acknowledged in the new section on the certification process in the Scope chapter of the next version of the Itsec. Details of the actual procedures for re-certification of evaluated TOES (which may involve partial or complete re-evaluation) will be addressed as far as possible in the Itsem, but are also a matter for national certification schemes. Cost of evaluations is a major concern to vendors (29). The working group notes and accepts this comment. In particular, the practical difficulties in evaluation of a distributed development environment spread over several countries is a real problem that had not been previously envisaged by the working group. Nevertheless, the working group believes the structure of the ltsec criteria will assist in keeping costs down by, for example, defining precise roles and tasks for both sponsors and evaluators. No respondent identified a practical way in which the ltsec could be changed to further reduce costs without reducing confidence. Thus no change to the ltsec is proposed.
This will be treated in the next version of the ltsec by adding a section on the certification process to the Scope chapter of the criteria. This section will indicate the key issues
01991
Elsevier Science Publishers Ltd
15