1、EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONSecure Information Processingversus the Concept of Product EvaluationECMA TR/64December 1993Free copies of this document are available from ECMA,European Computer Manufacturers Association,114 Rue du Rhne - CH-1204 Geneva (Switzerland)Phone: +41 22 735 36 3
2、4 Fax: +41 22 786 52 31X.400: C=ch, A=arcom, P=ecma, O=genevanet,OU1=ecma, S=helpdeskInternet: helpdeskecma.chEUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONSecure Information Processingversus the Concept of Product EvaluationECMA TR/64December 1993Brief HistoryIn September 1990 the European Commission
3、announced the “Harmonized IT Security Evaluation Criteria“ ITSEC. Thegovernments of France, Germany, Great Britain and the Netherlands had agreed on a common set of criteria for IT securityevaluations. The European Commission proposed these criteria for usage within the European Community.The ITSEC
4、deviated substantially from the US TCSEC, (Trusted Computer System Evaluation Criteria) commonly known asOrange Book, the de-facto standard since 1983.This created a problem for all world-wide operating computer manufacturers who were faced with two problems: to which set of criteria they should dev
5、elop their products, and if a product was developed to one set of criteria, would a customer in a country outside the influence of this set accept theproduct and its evaluation.Users of IT products were confused because they did not know, which set of criteria would meet their requirements.The Europ
6、ean Computer Manufacturers Association, ECMA, was alerted by its members, mostly world-wide operatingcompanies. The ECMA General Assembly therefore decided already in December 1990 to establish an ad hoc group onSecurity. This group started its work in March 1991. Later in 1991 the group became ECMA
7、/TC36 and then TC36/TG1.The group decided to address the problem twofold: First, to write an ECMA Technical Report which positions security evaluations in the context of secure informationprocessing in order to highlight the fact that an evaluated product or system can only guarantee security, when
8、the totalsystem, its environment and its operation are secure. Second, to develop an ECMA Standard for a functionality class which defines a minimum set of requirements forcommercial application. This class was called “Commercially Oriented Functionality Class“ or COFC. It distinguishesitself from t
9、he Orange Book and respective ITSEC functionalities, which are more tuned towards military and governmentrequirements for confidentiality of classified information. Assurance criteria, as addressed on the Orange Book andITSEC, have not been taken into account.Both, the Technical Report and the Stand
10、ard are intended to be a contribution to the ongoing harmonisation process. Theyhighlight commercial requirements, which call for an appropriate evaluation process, ranging from vendor self-testing toaccredited third party testing, and a minimal set of functional requirements, which satisfy commerci
11、al needs.Adopted as an ECMA Technical Report by the General Assembly of December 1993.- i -Table of contents1Scope 12 References 13 Acronyms and abbreviations 14 Introduction 25 Approaching Security: System perspective, Balance, Feedback 25.1 System perspective 25.2 Balance 35.3 Feedback 36 Security
12、 Evaluations: the Practice 47 The Value of Formal Evaluations in the Commercial Market 58 Conclusions 6Annex A - The Concept of Security Evaluations - A Tutorial 7A.1 Introduction 7A.2 Availability, Integrity, Confidentiality 8A.3 Security Target 8A.4 Protection Profile 9A.5 Functional Criteria 9A.6
13、 Assurance Criteria 10A.7 Predefined Functionality Classes 11A.8 The Evolution of Security Evaluation Criteria 11A.9 Evaluation and Certification 13A.10 Harmonization of Criteria 14- ii -1ScopeThis paper examines the value of security evaluation criteria and the accompanying evaluation process in ac
14、ommercial environment. It argues this question must be approached systematically within the context of a fullcomplement of security measures so as to maximize the value from associated investments. It then focuses on thepotential benefit specific to evaluations and makes recommendations as to the pr
15、ocesses for creating an IT securityprogram with special emphasis on security evaluations.Annex A is a review of the history and current status of formal evaluation programs. Readers unfamiliar with thistopic may wish to read this first.2 ReferencesECMA-138 Security in Open Systems - Data Elements an
16、d Service Definitions (1989)ECMA-205 Commercially oriented functionality class for security evaluation (COFC) (1993)ECMA-TR/46 Secutiry in Open Systems - A Security Framework (1988)ECMA-apa Auhentication and Priviliege Attribute Security Application with Related Key DistributionFunctions (in prepara
17、tion)/Lipner 91/ Steven B. Lipner, “Criteria, Evaluation and the International Environment: where have webeen, where are we going?“. Proceedings of the IFIP TC11 Seventh International Conferenceon Information Security: IFIP/SEC91 Brighton, UK, 45-17 May 1991. Edited by David T.Lindsay. Wyn L. Price.
18、 lSBN: 0 444 89219 2./GIS 91/ Information Technology Security Evaluation Criteria - Harmonized Criteria of France,Germany, the Netherlands, the United Kingdom. Provisional. Version 1.2 GermanInformation Security Agency, Bonn, 1991./DOD 85/ Department of Defense: Trusted Computer Systems Evaluation C
19、riteria. DOD 5200.28-STD,USA, 1985./Neumann 91/ Peter G. Neumann and Contributors: Risks to the Public. ACM Software Engineering Notes.Vol. 46, Jan. 1991./Le Roux 90/ Yves Le Roux, “Technical Criteria for Security Evaluation of Information TechnologyProducts“, Digital Equipment Corporation 1990/ECTE
20、L. EUROBIT/ Conformity Testing for IT Products, Second Edition 1992.3 Acronyms and abbreviationsDoD Department of Defense (USA)COFC Commercially Oriented Functionality ClassCTCPEC Canadian Trusted Computer Product Evaluation CriteriaIEC International Electrical CommitteeISO International Standards O
21、rganisationIT Information TechnologyITSEC Information Technology Security Evaluation CriteriaITSEM IT Security Evaluation Methodology ManualJTC1 Joint Technical Committee 1NIST National Institute for Standardization and Technology (USA)NSA National Security Agency (USA)- 2 -TCSEC Trusted Computer Sy
22、stem Evaluation CriteriaTOE Target of EvaluationTR Technical ReportSC27 ISO/IEC JTC1 SC (Sub Committee) 27 “IT Security“WG3 ISO/IEC JTC1/SC27 WG (Working Group) 3 “IT Security Evaluation Criteria“4 IntroductionWe assume the bank will keep our money in a safe, use armoured vehicles for transport, onl
23、y permit authorized peopleto complete a transaction, and audit all transactions. Furthermore, we require banks to adhere to accepted bankingpractices and open their books to independent review. Doing this well can give one bank a competitive edge over itsrivals. Information is the currency in a comm
24、ercial enterprise, and information management is critical to itscompetitive position. How to protect information and the potential role of formally evaluated systems is the subject ofthis paper.In the past 30 years weve seen computer technology revolutionize how we manage information - and its not o
25、veryet. Businesses can have access to the data they need: it is current, malleable, and easily disseminated. Technology isreducing the cost to process data and introducing.new methodologies to manipulate data, e.g. workgroup applications.Staying on top of these changes and adopting the right match o
26、f technology to the business need is high on mostmanagers agendas.But new technologies introduce new risks: the same capabilities that gives us current, malleable, and easilydisseminated information expose that data to new forms of attack. Weve come to rely on data being shared for updateand access,
27、 on networks for inter-and intra-company connections, on PCs, and on dial-up lines. The typical enterprisehas an IT environment composed of many computers.These computers range in size and location. It is no longer safe to assume that the “mission critical“ applications areconfined to the data centr
28、e, nor that they run over a single vendors equipment. Networks are pervasive, providingconnectivity not only within workgroups and across the enterprise, but also to external data sources, suppliers, andcustomers.Electronic information is a company asset and protecting it must be woven into the ente
29、rprises asset-protection plan.In the 60s, we could lock computers in specially built rooms; this approach is woefully inadequate today.Weve all experienced the horrors of the system being down. Not only have we come to depend upon the availabilityof our systems, but we must also guard against unauth
30、orized or inadvertent modification (information integrity) ordisclosure (confidentiality) of the data. Thus we arrive at the three tenants of Security: Confidentiality, Integrity andAvailability . or CIA.5 Approaching Security: System perspective, Balance, Feedback5.1 System perspectiveInformation i
31、s subject to a number of threats from a number of sources. “Acts of God“ and acts of war or civilunrest have dealt the dramatic blows. Employees make mistakes and miscalculations a few commit fraud, abuseauthority, or vandalize property. Outsiders may target an enterprise for vandalism, fraud, or es
32、pionage.By their very nature, accidents can hit anywhere, any time. Intelligent malicious attacks will seek out the path ofleast resistance - it is often via a dial-up line, but may be by sifting through the wastebaskets. Effective protectioninvolves adopting a structured management approach to secu
33、rity where policy and investment decisions take allrisks into consideration. Since this approach involves many facets of the business, it is important that those incharge of security have enough authority to enforce the policies. In practice, this means a security organizationreporting to top manage
34、ment. Identifying the Security Organization is the first step in managing security.Before defining the IT security strategy, it is necessary for the Security Organization to address security from aglobal viewpoint. Answering such questions as listed result in defining the Corporate Security Policy.
35、What are the assets? What is the value of the assets?- 3 - Who is allowed access or knowledge of the assets? How vulnerable are the assets? Which threats have to be anticipated? What is the impact of failure? Which organizational measures are necessary to protect the assets? What regulations, rules,
36、 processes are needed to ensure security?This policy is a set of rules and practices regulating how assets are managed, protected, and distributed. It typicallycovers people, buildings, material, equipment, and information; it includes such things as personnel policy,business planning, facility plan
37、ning, IT strategy, and operational procedures.The Corporate Security Policy is the starting point for the IT security strategy. It is important that top managementissues the Corporate Security Policy in order to demonstrate its commitment. This is critical since such policyimplies changing behaviour
38、s at every level, and a failure in IT security can have serious financial repercussions.The following steps then lead to a strategy for managing IT security - a clear demonstration that managing ITsecurity is much more about good business management than about technology. Publish the corporate IT se
39、curity policy. Analyse business needs and risks. This is achieved through a process of needs identification, threat assessment,vulnerability assessment, and risk analysis. Assess impact on current or expected situation. Develop security policies, standards, countermeasures, and contingency plans. Th
40、is step constitutes the ITsecurity program and involves choosing a set of safeguards that balances with ones risk acceptance decisions. Implement IT security program, not forgetting user training. Ensure compliance.5.2 BalanceSecurity is not about achieving 100 percent. Getting the balance right is
41、the key to good security management; it isa game of trade-offs. There are three main factors to consider when making an investment in a security measure: Cost Productivity (fullness of functionality and ease-of-use) Security (features and assurance)The paradox is that you want all three, but any two
42、 pull against the third! You can have a cheap solution atmaximum security (unplug all the machines) but you wont be pleased with the functionality; maximum security atfull functionality would be prohibitively expensive; while ignoring security minimises initial investment, butmaximises your risks.An
43、other paradox is that people think of IT security as managing technology, hence tend to focus on the technicalaspects. They may even invest in technical solutions at the cost of other aspects; for example, requiring (henceinvesting in) formal security evaluations of products at the cost of sufficien
44、t investment in user training.Investment is limited in every enterprise. Only people understand the business dynamics and can judge whichinvestments will yield the greatest benefit. This analysis is best approached as a team: involving users as well asmanagement, often aided by external consultants.
45、Today there is an investment imbalance, with more going into the scrutiny, methodology, and assurance of productsecurity compared with that spent in managing the security of operations. We should insist that any innovations insecurity evaluations amend this balance.5.3 FeedbackAchieving and maintain
46、ing balance depends on listening to experience and incorporating its lessons into ourguidelines, policies, and procedures. IT security evaluation criteria and any associated evaluation process fall intothis category. The quality of any guideline, policy, or procedure is directly proportional to how
47、much realexperience, from a variety of sources, it incorporates and how adaptive it is to changing conditions. The rest of thispaper will look at the value of IT security Evaluation Criteria and associated evaluation processes as mechanismsfor encapsulating and passing on such experience.- 4 -6 Secu
48、rity Evaluations: the practiceAnnex A describes the concepts behind formal evaluations as exemplified by TCSEC and ITSEC. The nextparagraphs examine the practice, looking at the following limitations: Ambiguity Time delay Maintenance and re-evaluations Secretive/closed process Non-productive nature
49、of the investment Real use CostAny development manager who has taken a system through a formal evaluation can attest to seemingly endlessdisputes around the interpretation of the requirements: To what granularity must one take the definition of an “object“for requiring access controls and auditing; e.g. is inter-process communication an object? Why does a mechanism thatpassed as C2 in one evaluation, fail in a later one? What the original authors regarded as clearly stated requirementshave proven ambiguous in practice, especially as applied by evalua
