1、EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONSTANDARD ECMA - 205Commercially oriented functionality classfor security evaluation(COFC)December 1993Free copies of this document are available from ECMA,European Computer Manufacturers Association,114 Rue du Rhne - CH-1204 Geneva (Switzerland)Phone: +41 2
2、2 735 36 34 Fax: +41 22 786 52 31X.400: C=ch, A=arcom, P=ecma, O=genevanet,OU1=ecma, S=helpdeskInternet: helpdeskecma.chEUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONSTANDARD ECMA - 205Commercially oriented functionality classfor security evaluation(COFC)December 1993Brief HistoryIn September 1990 the
3、European Commission 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
4、Community.The ITSEC deviated substantially from the US TCSEC, (Trusted Computer System Evaluation Criteria) commonly knownas Orange 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 crit
5、eria they should develop 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 acceptthe product and its evaluation.Users of IT products were confused because they did not know, which set of criteria would meet their re
6、quirements.The European 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 t
7、he group became ECMA/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 guara
8、ntee security, when 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 distin
9、guishesitself from the Orange Book and respective ITSEC functionalities, which are more tuned towards military andgovernment requirements for confidentiality of classified information. Assurance criteria, as addressed on the OrangeBook and ITSEC, have not been taken into account.Both, the Technical
10、Report and the Standard 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, wh
11、ich satisfy commercial needs.This ECMA Standard has been adopted by the ECMA General Assembly of December 1993.- i -Table of contents1 Scope 12 Conformance 23 References 24 Definitions 24.1 Terms defined in this document 24.1.1 Access right 24.1.2 Administration 24.1.3 Customer-specifiable 24.1.4 Id
12、entification 24.1.5 User identifier 24.2 Terms defined in other documents 35 Acronyms 36 Specification of security enforcing functions 36.1 Identification and Authentication 36.1.1 Unique Identification and Authentication 36.1.2 Identification and Authentication prior to all other interactions 36.1.
13、3 Associate information to users 36.1.4 Logon message 36.1.5 Number of logon trials 36.1.6 Expiration of unused user identifiers 46.1.7 Disable users temporarily 46.1.8 User status information 46.1.9 Authentication information protection 46.1.10 Authentication information independence 46.1.11 Authen
14、tication information aging 46.2 Access Control 46.2.1 Authenticated user identification 46.2.2 Individual user 46.2.3 User groups 46.2.4 Objects 46.2.5 Types of access rights 56.2.6 Default access rights 56.2.7 Precedence of access rights 56.2.8 Date of modification 56.2.9 Verification of rights 56.
15、2.10 Application controlled access rights 56.3 Accountability and audit 5- ii -6.3.1 Associate actions and users 56.3.2 Logging 56.3.4 Copy audit trails 66.3.5 Alarm if unable to record 66.3.6 Select users 66.3.7 Dynamic control 76.4 Object Reuse 76.5 Accuracy 76.5.1 TOE software integrity 76.5.2 Da
16、ta integrity 76.5.3 Security parameters status report 76.6 Reliability of service 76.6.1 Recovery 76.6.2 Data backup 77 Password specific requirements 77.1 User-changeable password 77.2 Password aging 77.3 Password expiration notification 77.4 Password reuse 77.5 Password complexity 87.6 Password lo
17、gging 87.7 Default passwords 8Annex A (informative) Access control model 9Annex B (informative) Terms defined in other documents 111 ScopeThe objective of this ECMA Standard is to define a widely accepted basic security functionality class for thecommercial market. It is articulated in a structured
18、way consistent with TCSEC, ITSEC and MSFR concepts.Readers unfamiliar with security and these concepts are encouraged to read TCSEC, ITSEC and MSFR if they wishto understand fully this text.This standard addresses only IT security. Other security areas like personnel security, physical security andp
19、rocedural security are not covered.This standard defines a basic functionality class for the commercial market. It addresses multi-user, stand-alone IT-systems without considering networking or remote access. The areas networking, distributed processing, anonymity,pseudonymity, unlinkability, unobse
20、rvability are still evolving. Once these matters are better understood additionalrequirements will be defined as an add-on, in a new version of this class or in a new extended class. Multi-processorsystems however are covered as long as a single system image is provided.Table 1 shows the security en
21、forcing functions by which the major assumed threats are countered.Table 1. Major assumed threats countered by security enforcing functionsTHREAT SECURITY ENFORCING FUNCTIONOutsider attack - Unauthorized access to the TOE 6.1.2 Identification and Authentication prior toall other interactionsInsider
22、attack - Individual responsibility 6.1.1 Unique Identification and Authentication6.3 Accountability6.4 AuditAutomatic logon attacks 6.1.5 Number of logon trialsDisclosure of authentication information 6.1.9 Authentication information protection6.1.10 Authentication information sharing6.1.11 Authenti
23、cation information agingDisclosure of information 6.2 Access Control6.5 Object ReuseManipulation of information (accidental orintentional)6.2 Access Control6.6 AccuracyTOE failure 6.7.1 RecoveryNatural disasters 6.7.2 Data backupThis Standard defines minimum functional requirements independent of an
24、y platform. It focuses on functions andnot on mechanisms or implementation specific details. Where mechanisms are addressed, e.g. “Password specificrequirements,“ they are clearly separated. Examples are introduced with the phrase “As an example .“; they are forillustration purposes only.- 2 -2 Conf
25、ormanceA system conforms to the requirements of this Standard if it conforms to clause 6, and if a password mechanism isavailable, to the requirements of clause 7.To conform to this Standard, systems with functions not covered in this Standard, such as Networking or RemoteAccess, are required to cou
26、nter all the threats addressed by this functionality class and may require significantadditional security enforcing functions and definitions.3 ReferencesECMA-138 Security in open Systems - Data Elements and Service Definitions (1989)ECMA TR/46 Security in open Systems - A Security Framework (1988)E
27、CMA TR/64 Secure information processing versus the concept of product evaluation (1993)ECMA-206 Association context management - Including security context management (1993)ISO 7498-2:1989 Information processing systems - Open Systems Interconnection - Basic Reference Model - Part2: Security Archite
28、cture.ISO 9594-2:1990 Information technology - Open Systems Interconnection - The Directory - Part 2: Models -Annex F (Informative) Access Control.CBEMA The American National Dictionary for Information Processing Systems - Computer andBusiness Equipment Manufacturers Association (1982).TCSEC Trusted
29、 Computer System Evaluation Criteria (TCSEC) - Department of Defense - DoD5200.28-STD (December 1985).ITSEC Information Technology Security Evaluation Criteria (ITSEC) - Provisional HarmonisedCriteria - Commission of the European Communities - ISBN 92-826-3004-8 (June 1991).MSFR Minimum Security Fun
30、ctionality Requirements for Multi-user Operating Systems - NationalInstitute of Standards and Technology - Issue 1 (January 16, 1992).4 Definitions4.1 Terms defined in this documentFor the purpose of this document the following definitions apply:4.1.1 Access rightThe ability of a user to access an o
31、bject.4.1.2 AdministrationThe act of controlling security relevant objects. This can be performed by one or several users through theassignment of security relevant access rights.NOTEThese users are sometimes called administrators.4.1.3 Customer-specifiableA characteristic of security relevant param
32、eters for which a customer can specify a value.4.1.4 IdentificationThe process of recognising a user by the TOE. This is done by the user providing the TOE with someinformation that is known by the TOE and associated with the user. See ITSEC page 254.1.5 User identifierA string of characters that un
33、iquely identifies a user to a system.- 3 -NOTEThis does not exclude a user which does have several identifiers within the system, for instance, as described inECMA-138 and ECMA TR/46.4.2 Terms defined in other documentsThe following terms are used with the meanings defined in other documents. The de
34、finitions are repeated forconvenience in annex B.Access IntegrityAccess Control MechanismAccess Control List ObjectAccountability Object ReuseAudit PasswordAudit Trail ProcedureAuthenticate SecurityAuthentication Information Security AuditAuthorization Security Audit TrailAvailability Security Enfor
35、cingConfidentiality Security MechanismCustomer Target of Evaluation (TOE)Data Integrity User5 AcronymsThe following acronyms are used in this document:ACL Access Control ListCBEMA Computer and Business Equipment Manufacturers AssociationISO International Organization for StandardizationITSEC Informa
36、tion Technology Security Evaluation CriteriaMSFR Minimum Security Functionality RequirementsTCSEC Trusted Computer System Evaluation CriteriaTOE Target of Evaluation ITSEC6 Specification of security enforcing functions6.1 Identification and Authentication6.1.1 Unique Identification and Authenticatio
37、nThe TOE shall uniquely identify and authenticate users.6.1.2 Identification and Authentication prior to all other interactionsIdentification and Authentication shall take place prior to all other interactions between the TOE and the user.Other interactions shall only be possible after successful id
38、entification and authentication.6.1.3 Associate information to usersA mechanism shall be available for administration to associate customer-defined information, e.g., user nameand affiliation, with each user.6.1.4 Logon messageThe TOE shall provide an advisory warning message upon TOE entry regardin
39、g unauthorized use, and thepossible consequences of failure to meet those requirements. The message shall be customer-specifiable tomeet their own requirements and state laws.6.1.5 Number of logon trialsThe TOE logon procedure shall exit and end the session if the user authentication procedure is in
40、correctlyperformed a customer-specifiable number of times within a logon session. The TOE shall provide a mechanism to immediately notify administration when this threshold isexceeded.- 4 - When the above threshold has been exceeded, a customer-specifiable interval of time shall elapse beforethe log
41、on process can be restarted on that I/O port. The TOE shall not suspend the user upon exceeding the above threshold.6.1.6 Expiration of unused user identifiersThe TOE shall allow the customer to specify an action which is taken by the TOE after a period of time duringwhich the user was not logged on
42、. The time period shall be customer-specifiable.As an example the following actions may be provided: disabling the access of the user to the TOE; alerting administration.6.1.7 Disable users temporarilyThe TOE shall allow administration to temporarily disable a user accessing the TOE.6.1.8 User statu
43、s informationA mechanism shall be available for administration to provide the status, e.g., active, inactive, etc., of any user.6.1.9 Authentication information protectionThe TOE shall protect the integrity of stored authentication information and the confidentiality of anyassociated secrets.6.1.10
44、Authentication information independenceUser-provided authentication information need not be unique. For example, two users may provide the samepassword, however the TOE shall not indicate the presence or absence of such duplicated authenticationinformation.6.1.11 Authentication information agingIf t
45、he authentication information is not biometric the TOE shall provide a mechanism which enforces periodicchanges. The time period shall be customer-specifiable.6.2 Access Control6.2.1 Authenticated user identificationControl of access to objects shall only be granted to authenticated users, e.g. thro
46、ugh an authenticated useridentifier.6.2.2 Individual userThe TOE shall be able to distinguish and administer access rights between each user and the objects which aresubject to the administration of access rights. It shall be possible to grant the access rights down to thegranularity of an individua
47、l user.6.2.3 User groupsThe TOE shall be able to distinguish and administer access rights between each user group and the objectswhich are subject to the administration of access rights, on the basis of membership to a group of users. It shallbe possible to grant the access rights down to the granul
48、arity of an individual group.6.2.4 ObjectsDistinct security relevant objects shall be subject to the administration of access rights.As an example the following objects may be subject to the administration of access rights: The objects of one user to protect them from any other user and their object
49、s. The objects of the TOE (security relevant objects) to protect them from any user and their objects.To allow functional separation of administrative users it shall be possible to grant access rights to individualsecurity relevant objects to different users.As an example the following security relevant objects may be subject to the administration of access rights: The Identification and Authentication mechanisms objects. The Access Control mechanisms objects.- 5 - The Accountability mechanisms objects for non-administrative tasks. The Accountability mechanisms objects fo
