下载文档原格式
ISO标准——IEC 27001:2005信息安全管理体系——规范与使用指南Reference numberISO/IEC 27001:2005(E)0简介0.1总则本国际标准的目的是提供建立、实施、运作、监控、评审、维护和改进信息安全管理体系（ISMS）的模型。
采用ISMS应是一个组织的战略决定。
组织ISMS的设计和实施受业务需求和目标、安全需求、应用的过程及组织的规模、结构的影响。
上述因素和他们的支持系统预计会随事件而变化。
希望根据组织的需要去扩充ISMS的实施，如，简单的环境是用简单的ISMS解决方案。
本国际标准可以用于内部、外部评估其符合性。
0.2过程方法本国际标准鼓励采用过程的方法建立、实施、运作、监控、评审、维护和改进一个组织的ISMS的有效性。
一个组织必须识别和管理许多活动使其有效地运行。
通过利用资源和管理，将输入转换为输出的活动，可以被认为是一个过程。
通常，一个过程的输出直接形成了下一个过程的输入。
组织内过程体系的应用，连同这些过程的识别和相互作用及管理，可以称之这“过程的方法”。
在本国际标准中，信息安全管理的过程方法鼓励用户强调以下方面的重要性：a)了解组织信息安全需求和建立信息安全策略和目标的需求；b)在组织的整体业务风险框架下，通过实施及运作控制措施管理组织的信息安全风险；c)监控和评审ISMS的执行和有效性；d)基于客观测量的持续改进。
本国际标准采用了“计划-实施-检查-改进”（PDCA）模型去构架全部ISMS流程。
图1显示ISMS如何输入相关方的信息安全需求和期望，经过必要的处理，产生满足需求和期望的产品信息安全输出，图1阐明与条款4、5、6、7、8相关。
采用PDCA模型将影响OECD《信息系统和网络的安全治理》（2002）中陈述的原则，0 Introduction0.1 GeneralThis International Standard has been prepared to provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an Information Security Management System (ISMS). The adoption of an ISMS should be a strategic decision for an organization. The design and implementation of an organization’s ISMS is influenced by their needs and objectives, security requirements, the processes employed and the size and structure of the organization. These and their supporting systems are expected to change over time. It is expected that an ISMS implementation will be scaled in accordance with the needs of the organization, e.g. a simple situation requires a simple ISMS solution.This International Standard can be used in order to assess conformance by interested internal and external parties.0.2 Process approachThis International Standard adopts a process approach for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an organization's ISMS.An organization needs to identify and manage many activities in order to function effectively. Any activity using resources and managed in order to enable the transformation of inputs into outputs can be considered to be a process. Often the output from one process directly forms the input to the next process.The application of a system of processes within an organization, together with the identification and interactions of these processes, and their management, can be referred to as a “process approach”.The process approach for information security management presented in this International Standard encourages its users to emphasize the importance of: a) understanding an organization’s information security requirements and the need to establish policy and objectives for information security;b) implementing and operating controls to manage an organization's information security risks in the context of the organization’s overall business risks;c) monitoring and reviewing the performance and effectiveness of the ISMS; andd) continual improvement based on objective measurement.This International Standard adopts the "Plan-Do-Check-Act" (PDCA) model, which is applied to structure all ISMS processes. Figure 1 illustrates how an ISMS takes as input the information security requirements and expectations of the interested parties and through the necessary actions and processes produces information security outcomes that meets those requirements and expectations. Figure 1 also illustrates the links in the processes presented in Clauses 4, 5, 6, 7 and 8.The adoption of the PDCA model will also reflect the principles as set out in the本国际标准提供一个健壮的模型去实施指南中的控制风险评估、安全设计和实施、安全管理和再评估的原则。
saso 2655 沙特标准SASO 2655: The Saudi Arabian Standard for [Specific Industry or Product]SASO 2655, the Saudi Arabian Standard, serves as a crucial regulatory framework for ensuring the quality and safety of [specific industry or product] within the Kingdom of Saudi Arabia. SASO 2655作为沙特阿拉伯标准，是确保沙特阿拉伯王国境内[特定行业或产品]质量和安全的重要监管框架。
The standard is designed to protect consumers from potential hazards and risks associated with the use of substandard or unsafe products.该标准旨在保护消费者免受使用劣质或不安全产品所带来的潜在危害和风险。
It outlines strict requirements and specifications that manufacturers and importers must adhere to in order to comply with Saudi Arabian regulations.它概述了制造商和进口商必须遵守的严格要求和规范，以确保符合沙特阿拉伯的法规。
Compliance with SASO 2655 is essential for any company seeking to export [specific industry or product] to the Saudi market.任何寻求向沙特市场出口[特定行业或产品]的公司都必须遵守SASO 2655标准。
Common CriteriaForewordCC version 2.2 contains all final interpretations, editorial changes, and agreed new material since the publication of CC v2.1.CC version 2.2 consists of the following parts:−Part 1: Introduction and general model−Part 2: Security functional requirements−Part 3: Security assurance requirementsPage 2 of 64 Version 2.2 January 2004Version 2.2 January 2004This Legal NOTICE has been placed in all Parts of the CC by request:The seven governmental organisations (collectively called the “Common Criteria Project Sponsoring Organisations”) listed just below, as the joint holders of the copyright in the Common Criteria for Information Technology Security Evaluations, version 2.2 Parts 1 through 3 (called “CC 2.2”), hereby grant non-exclusive license to ISO/IEC to use CC 2.2 in the continued development/maintenance of the ISO/IEC 15408 international standard. However, the Common Criteria Project Sponsoring Organisations retain the right to use, copy, distribute, translate or modify CC 2.2 as they see fit.Canada: Communications Security EstablishmentFrance: Service Central de la Sécurité des Systèmes d’InformationGermany: Bundesamt für Sicherheit in der InformationstechnikNetherlands: Netherlands National Communications Security AgencyUnited Kingdom: Communications-Electronics Security GroupUnited States: National Institute of Standards and TechnologyUnited States: National Security AgencyTable of contents Table of Contents1SCOPE (8)2DEFINITIONS (10)2.1Common abbreviations (10)2.2Scope of glossary (11)2.3Glossary (11)2.4Reserved Terms (17)3OVERVIEW (19)3.1Introduction (19)3.1.1Target audience of the CC (19)3.2Evaluation context (21)3.3Organisation of the Common Criteria (22)4GENERAL MODEL (24)4.1Security context (24)4.1.1General security context (24)4.1.2Information technology security context (26)4.2Common Criteria approach (26)4.2.1Development (26)4.2.2TOE evaluation (28)4.2.3Operation (29)4.3Security concepts (29)4.3.1Security environment (31)4.3.2Security objectives (32)4.3.3IT security requirements (33)4.3.4TOE summary specification (34)4.3.5TOE implementation (34)4.4CC descriptive material (34)4.4.1Expression of security requirements (34)4.4.2Types of evaluation (41)5COMMON CRITERIA REQUIREMENTS AND EVALUATION RESULTS (42)5.1Introduction (42)5.1.1Requirements in PPs and STs (43)5.1.2Requirements in TOE (43)5.1.3Conformance results (44)5.2Use of TOE evaluation results (45)Page 4 of 64 Version 2.2 January 2004Table of contentsA SPECIFICATION OF SECURITY TARGETS (47)A.1Overview (47)A.2Content of Security Target (47)A.2.1Content and presentation (47)A.2.2ST introduction (48)A.2.3TOE description (49)A.2.4TOE security environment (49)A.2.5Security objectives (50)A.2.6IT security requirements (50)A.2.7TOE summary specification (52)A.2.8PP claims (53)A.2.9Application Notes (54)A.2.10Rationale (55)B SPECIFICATION OF PROTECTION PROFILES (57)B.1Overview (57)B.2Content of Protection Profile (57)B.2.1Content and presentation (57)B.2.2PP introduction (58)B.2.3TOE description (58)B.2.4TOE security environment (59)B.2.5Security objectives (60)B.2.6IT security requirements (60)B.2.7Application notes (62)B.2.8Rationale (62)C BIBLIOGRAPHY (64)January 2004 Version 2.2 Page 5 of 64Table of contentsList of figuresFigure 1 - Evaluation Context (22)Figure 2 - Security concepts and relationships (24)Figure 3 - Evaluation concepts and relationships (25)Figure 4 - TOE development model (27)Figure 5 - TOE evaluation process (28)Figure 6 - Derivation of requirements and specifications (31)Figure 7 - Organisation and construction of requirements (35)Figure 8 - Use of security requirements (39)Figure 9 - Evaluation results (42)Figure 10 - Use of TOE evaluation results (45)Figure 11 - Security Target content (48)Figure 12 - Protection Profile content (58)Page 6 of 64 Version 2.2 January 2004List of figuresList of tablesTable 1 Roadmap to the Common Criteria (23)January 2004 Version 2.2 Page 7 of 64ScopePage 8 of 64 Version 2.2 January 20041 Scope1This multipart standard, the Common Criteria (CC), is meant to be used as the basis for evaluation of security properties of IT products and systems. By establishing such a common criteria base, the results of an IT security evaluation will be meaningful to a wider audience. 2The CC will permit comparability between the results of independent security evaluations. It does so by providing a common set of requirements for the security functions of IT products and systems and for assurance measures applied to them during a security evaluation. The evaluation process establishes a level of confidence that the security functions of such products and systems and the assurance measures applied to them meet these requirements. The evaluation results may help consumers to determine whether the IT product or system is secure enough for their intended application and whether the security risks implicit in its use are tolerable. 3The CC is useful as a guide for the development of products or systems with IT security functions and for the procurement of commercial products and systems with such functions. During evaluation, such an IT product or system is known as a Target of Evaluation (TOE). Such TOEs include, for example, operating systems, computer networks, distributed systems, and applications. 4The CC addresses protection of information from unauthorised disclosure, modification, or loss of use. The categories of protection relating to these three types of failure of security are commonly called confidentiality, integrity, and availability, respectively. The CC may also be applicable to aspects of IT security outside of these three. The CC concentrates on threats to that information arising from human activities, whether malicious or otherwise, but may be applicable to some non-human threats as well. In addition, the CC may be applied in other areas of IT, but makes no claim of competence outside the strict domain of IT security. 5The CC is applicable to IT security measures implemented in hardware, firmware or software. Where particular aspects of evaluation are intended only to apply to certain methods of implementation, this will be indicated within the relevant criteria statements. 6Certain topics, because they involve specialised techniques or because they are somewhat peripheral to IT security, are considered to be outside the scope of the CC. Some of these are identified below. a) The CC does not contain security evaluation criteria pertaining to administrative security measures not related directly to the IT security measures. However, it is recognised that a significant part of the security of a TOE can often be achieved through administrative measures such as organisational, personnel, physical, and procedural controls. Administrative security measures in the operating environment of the TOE are treated as secure usage assumptionsScopewhere these have an impact on the ability of the IT security measuresto counter the identified threats.b)The evaluation of technical physical aspects of IT security such aselectromagnetic emanation control is not specifically covered,although many of the concepts addressed will be applicable to thatarea. In particular, the CC addresses some aspects of physicalprotection of the TOE.c)The CC addresses neither the evaluation methodology nor theadministrative and legal framework under which the criteria may beapplied by evaluation authorities. However, it is expected that the CCwill be used for evaluation purposes in the context of such aframework and such a methodology.d)The procedures for use of evaluation results in product or systemaccreditation are outside the scope of the CC. Product or systemaccreditation is the administrative process whereby authority isgranted for the operation of an IT product or system in its fulloperational environment. Evaluation focuses on the IT security partsof the product or system and those parts of the operationalenvironment that may directly affect the secure use of IT elements.The results of the evaluation process are consequently a valuableinput to the accreditation process. However, as other techniques aremore appropriate for the assessments of non-IT related product orsystem security properties and their relationship to the IT securityparts, accreditors should make separate provision for those aspects.e)The subject of criteria for the assessment of the inherent qualities ofcryptographic algorithms is not covered in the CC. Shouldindependent assessment of mathematical properties of cryptographyembedded in a TOE be required, the evaluation scheme under whichthe CC is applied must make provision for such assessments. January 2004 Version 2.2 Page 9 of 64DefinitionsPage 10 of 64 Version 2.2 January 2004 2 Definitions2.1 Common abbreviations 7 The following abbreviations are common to more than one part of the CC: 8 CC:Common Criteria9 EAL:Evaluation Assurance Level10 IT:Information Technology11 PP:Protection Profile12 SF:Security Function13 SFP:Security Function Policy14 SOF:Strength of Function15 ST:Security Target16 TOE:Target of Evaluation17 TSC:TSF Scope of Control18 TSF:TOE Security Functions19 TSFI:DefinitionsTSF Interface20 TSP:TOE Security Policy2.2 Scope of glossary21 This subclause 2.2 contains only those terms which are used in a specialisedway throughout the CC. The majority of terms in the CC are used either according to their accepted dictionary definitions or according to commonly accepted definitions that may be found in ISO security glossaries or other well-known collections of security terms. Some combinations of common terms used in the CC, while not meriting glossary definition, are explained for clarity in the context where they are used. Explanations of the use of terms and concepts used in a specialised way in CC Part 2 and CC Part 3 can be found in their respective “paradigm” subclauses.2.3 Glossary22 Assets:Information or resources to be protected by the countermeasures of a TOE.23 Assignment:The specification of an identified parameter in a component.24 Assurance:Grounds for confidence that an entity meets its security objectives.25 Attack potential:The perceived potential for success of an attack, should an attack be launched, expressed in terms of an attacker's expertise, resources and motivation.26 Augmentation:The addition of one or more assurance component(s) from Part 3 to an EAL or assurance package.27 Authentication data:Information used to verify the claimed identity of a user.28 Authorised user:A user who may, in accordance with the TSP, perform an operation.Definitions29Class:A grouping of families that share a common focus.30Component:The smallest selectable set of elements that may be included in a PP,an ST, or a package.31Connectivity:The property of the TOE which allows interaction with IT entitiesexternal to the TOE. This includes exchange of data by wire or bywireless means, over any distance in any environment orconfiguration.32Dependency:A relationship between requirements such that the requirement that isdepended upon must normally be satisfied for the other requirementsto be able to meet their objectives.33Element:An indivisible security requirement.34Evaluation:Assessment of a PP, an ST or a TOE, against defined criteria.35Evaluation Assurance Level (EAL):A package consisting of assurance components from Part 3 thatrepresents a point on the CC predefined assurance scale.36Evaluation authority:A body that implements the CC for a specific community by meansof an evaluation scheme and thereby sets the standards and monitorsthe quality of evaluations conducted by bodies within thatcommunity.37Evaluation scheme:The administrative and regulatory framework under which the CC isapplied by an evaluation authority within a specific community.38Extension:The addition to an ST or PP of functional requirements not containedin Part 2 and/or assurance requirements not contained in Part 3 of theCC.Definitions39External IT entity:Any IT product or system, untrusted or trusted, outside of the TOEthat interacts with the TOE.40Family:A grouping of components that share security objectives but maydiffer in emphasis or rigour.41Formal:Expressed in a restricted syntax language with defined semanticsbased on well-established mathematical concepts.42Guidance Documentation:Guidance documentation describes the delivery, installation,configuration, operation, management and use of the TOE as theseactivities apply to the users, administrators, and integrators of theTOE. The requirements on the scope and contents of guidancedocuments are defined in a PP or ST.43Human user:Any person who interacts with the TOE.44Identity:A representation (e.g. a string) uniquely identifying an authoriseduser, which can either be the full or abbreviated name of that user or apseudonym.45Informal:Expressed in natural language.46Internal communication channel:A communication channel between separated parts of TOE.47Internal TOE transfer:Communicating data between separated parts of the TOE.48Inter-TSF transfers:Communicating data between the TOE and the security functions ofother trusted IT products.49Iteration:The use of a component more than once with varying operations.Definitions50Object:An entity within the TSC that contains or receives information andupon which subjects perform operations.51Organisational security policies:One or more security rules, procedures, practices, or guidelinesimposed by an organisation upon its operations.52Package:A reusable set of either functional or assurance components (e.g. anEAL), combined together to satisfy a set of identified securityobjectives.53Product:A package of IT software, firmware and/or hardware, providingfunctionality designed for use or incorporation within a multiplicityof systems.54Protection Profile (PP):An implementation-independent set of security requirements for acategory of TOEs that meet specific consumer needs.55Reference monitor:The concept of an abstract machine that enforces TOE access controlpolicies.56Reference validation mechanism:An implementation of the reference monitor concept that possessesthe following properties: it is tamperproof, always invoked, andsimple enough to be subjected to thorough analysis and testing.57Refinement:The addition of details to a component.58Role:A predefined set of rules establishing the allowed interactionsbetween a user and the TOE.59Secret:Information that must be known only to authorised users and/or theTSF in order to enforce a specific SFP.60Security attribute:DefinitionsCharacteristics of subjects, users, objects, information, and/orresources that are used for the enforcement of the TSP.61Security Function (SF):A part or parts of the TOE that have to be relied upon for enforcing aclosely related subset of the rules from the TSP.62Security Function Policy (SFP):The security policy enforced by an SF.63Security objective:A statement of intent to counter identified threats and/or satisfyidentified organisation security policies and assumptions.64Security Target (ST):A set of security requirements and specifications to be used as thebasis for evaluation of an identified TOE.65Selection:The specification of one or more items from a list in a component.66Semiformal:Expressed in a restricted syntax language with defined semantics.67Strength of Function (SOF):A qualification of a TOE security function expressing the minimumefforts assumed necessary to defeat its expected security behaviourby directly attacking its underlying security mechanisms.68SOF-basic:A level of the TOE strength of function where analysis shows that thefunction provides adequate protection against casual breach of TOEsecurity by attackers possessing a low attack potential.69SOF-medium:A level of the TOE strength of function where analysis shows that thefunction provides adequate protection against straightforward orintentional breach of TOE security by attackers possessing amoderate attack potential.70SOF-high:A level of the TOE strength of function where analysis shows that thefunction provides adequate protection against deliberately planned orDefinitions organised breach of TOE security by attackers possessing a highattack potential.71Subject:An entity within the TSC that causes operations to be performed.72System:A specific IT installation, with a particular purpose and operationalenvironment.73Target of Evaluation (TOE):An IT product or system and its associated guidance documentationthat is the subject of an evaluation.74TOE resource:Anything useable or consumable in the TOE.75TOE Security Functions (TSF):A set consisting of all hardware, software, and firmware of the TOEthat must be relied upon for the correct enforcement of the TSP.76TOE Security Functions Interface (TSFI):A set of interfaces, whether interactive (man-machine interface) orprogrammatic (application programming interface), through whichTOE resources are accessed, mediated by the TSF, or information isobtained from the TSF.77TOE Security Policy (TSP):A set of rules that regulate how assets are managed, protected anddistributed within a TOE.78TOE security policy mode:A structured representation of the security policy to be enforced bythe TOE.79Transfers outside TSF control:Communicating data to entities not under control of the TSF.80Trusted channel:A means by which a TSF and a remote trusted IT product cancommunicate with necessary confidence to support the TSP.81Trusted path:DefinitionsA means by which a user and a TSF can communicate with necessaryconfidence to support the TSP.82TSF data:Data created by and for the TOE, that might affect the operation ofthe TOE.83TSF Scope of Control (TSC):The set of interactions that can occur with or within a TOE and aresubject to the rules of the TSP.84User:Any entity (human user or external IT entity) outside the TOE thatinteracts with the TOE.85User data:Data created by and for the user, that does not affect the operation ofthe TSF.Terms2.4 Reserved86The following terms are used in accordance with the ISO definitions contained in ISO/IEC Directives Part 2, Rules for the structure and draftingof International Standards: All text should be considered “Normative”unless specifically denoted as “Informative”.87Normative:Normative text is that which “describes the scope of the document,and which set out provisions.” (ISO/IEC Directives, Part 2) Withinnormative text, the verbs “shall”, “should”, “may”, and “can” havethe ISO standard meanings described in this glossary and the verb“must” is not used. Unless explicitly labeled “informative”, all CCtext is normative. Any text related to meeting requirements isconsidered normative.88Informative:Informative text is that which “provides additional informationintended to assist the understanding or use of thedocument.”(ISO/IEC Directives, Part 2). Informative text is notrelated to meeting requirements.89Shall:Within normative text, “shall” indicates “requirements strictly to befollowed in order to conform to the document and from which nodeviation is permitted.” (ISO/IEC Directives, Part 2)Definitions90Should:Within normative text, should indicates “that among severalpossibilities one is recommended as particularly suitable, withoutmentioning or excluding others, or that a certain course of action ispreferred but not necessarily required.”(ISO/IEC Directives, Part 2)The CC interprets 'not necessarily required' to mean that the choice ofanother possibility requires a justification of why the preferred optionwas not chosen.91May:Within normative text, may indicates “a course of action permissiblewithin the limits of the document”(ISO/IEC Directives, Part 2)92Can:Within normative text, can indicates “statements of possibility andcapability, whether material, physical or causal”(ISO/IEC Directives,Part 2)Overview3 Overview93This clause introduces the main concepts of the CC. It identifies the target audience, evaluation context, and the approach taken to present the material.3.1 Introduction94Information held by IT products or systems is a critical resource that enables organisations to succeed in their mission. Additionally, individuals have areasonable expectation that their personal information contained in ITproducts or systems remain private, be available to them as needed, and notbe subject to unauthorised modification. IT products or systems shouldperform their functions while exercising proper control of the information toensure it is protected against hazards such as unwanted or unwarranteddissemination, alteration, or loss. The term IT security is used to coverprevention and mitigation of these and similar hazards.95Many consumers of IT lack the knowledge, expertise or resources necessary to judge whether their confidence in the security of their IT products orsystems is appropriate, and they may not wish to rely solely on the assertionsof the developers. Consumers may therefore choose to increase theirconfidence in the security measures of an IT product or system by orderingan analysis of its security (i.e. a security evaluation).96The CC can be used to select the appropriate IT security measures and it contains criteria for evaluation of security requirements.3.1.1 Target audience of the CC97There are three groups with a general interest in evaluation of the security properties of IT products and systems: TOE consumers, TOE developers,and TOE evaluators. The criteria presented in this document have beenstructured to support the needs of all three groups. They are all considered tobe the principal users of this CC. The three groups can benefit from thecriteria as explained in the following paragraphs.3.1.1.1 Consumers98The CC plays an important role in supporting techniques for consumer selection of IT security requirements to express their organisational needs.The CC is written to ensure that evaluation fulfils the needs of the consumersas this is the fundamental purpose and justification for the evaluationprocess.99Consumers can use the results of evaluations to help decide whether an evaluated product or system fulfils their security needs. These security needsare typically identified as a result of both risk analysis and policy direction.Consumers can also use the evaluation results to compare different productsor systems. Presentation of the assurance requirements within a hierarchysupports this need.Overview100The CC gives consumers -- especially in consumer groups and communities of interest -- an implementation-independent structure termed the ProtectionProfile (PP) in which to express their special requirements for IT securitymeasures in a TOE.3.1.1.2 Developers101The CC is intended to support developers in preparing for and assisting in the evaluation of their products or systems and in identifying securityrequirements to be satisfied by each of their products or systems. It is alsoquite possible that an associated evaluation methodology, potentiallyaccompanied by a mutual recognition agreement for evaluation results,would further permit the CC to support someone, other than the TOEdeveloper, in preparing for and assisting in the evaluation of a developer sTOE.102The CC constructs can then be used to make claims that the TOE conforms to its identified requirements by means of specified security functions andassurances to be evaluated. Each TOE s requirements are contained in animplementation-dependent construct termed the Security Target (ST). One ormore PPs may provide the requirements of a broad consumer base.103The CC describes security functions that a developer could include in the TOE. The CC can be used to determine the responsibilities and actions tosupport evidence that is necessary to support the evaluation of the TOE. Italso defines the content and presentation of that evidence.3.1.1.3 Evaluators104The CC contains criteria to be used by evaluators when forming judgements about the conformance of TOEs to their security requirements. The CCdescribes the set of general actions the evaluator is to carry out and thesecurity functions on which to perform these actions. Note that the CC doesnot specify procedures to be followed in carrying out those actions.3.1.1.4 Others105While the CC is oriented towards specification and evaluation of the IT security properties of TOEs, it may also be useful as reference material to allparties with an interest in or responsibility for IT security. Some of theadditional interest groups that can benefit from information contained in theCC are:a)system custodians and system security officers responsible fordetermining and meeting organisational IT security policies andrequirements;b)auditors, both internal and external, responsible for assessing theadequacy of the security of a system;Overviewc)security architects and designers responsible for the specification ofthe security content of IT systems and products;d)accreditors responsible for accepting an IT system for use within aparticular environment;e)sponsors of evaluation responsible for requesting and supporting anevaluation; andf)evaluation authorities responsible for the management and oversightof IT security evaluation programmes.3.2 Evaluationcontext106In order to achieve greater comparability between evaluation results, evaluations should be performed within the framework of an authoritativeevaluation scheme that sets the standards, monitors the quality of theevaluations and administers the regulations to which the evaluation facilitiesand evaluators must conform.107The CC does not state requirements for the regulatory framework. However, consistency between the regulatory frameworks of different evaluationauthorities will be necessary to achieve the goal of mutual recognition of theresults of such evaluations. Figure 1 depicts the major elements that form thecontext for evaluations.108Use of a common evaluation methodology contributes to the repeatability and objectivity of the results but is not by itself sufficient. Many of theevaluation criteria require the application of expert judgement andbackground knowledge for which consistency is more difficult to achieve. Inorder to enhance the consistency of the evaluation findings, the finalevaluation results could be submitted to a certification process. Thecertification process is the independent inspection of the results of theevaluation leading to the production of the final certificate or approval. Thecertificate is normally publicly available. It is noted that the certificationprocess is a means of gaining greater consistency in the application of ITsecurity criteria.109The evaluation scheme, methodology, and certification processes are the responsibility of the evaluation authorities that run evaluation schemes andare outside the scope of the CC.。
项目参照原则盖特佳企业将根据对安全风险具有良好定义旳ISO15408/BS7799/SSE_CMM 等国际原则来XXX单位进行安全服务。
这些原则是协助XXX单位计算机信息网络系统构建信息安全管理框架旳国际原则。
该原则规定各组织建立并运行一套通过验证旳信息安全管理体系，用于处理如下问题：资产旳保管、组织旳风险管理、管理原则和管理措施、规定抵达旳安全程度等。
1）国际安全原则ISO 15408ISO国际原则化组织于1999年正式公布了ISO/IEC 15408。
ISO/IEC JTC 1和Common Criteria Project Organisations共同制定了此原则，此原则等同于Common Criteria V2.1。
ISO/IEC 15408有一种通用旳标题——信息技术—安全技术—IT安全评估准则。
此原则包括三个部分：第一部分简介和一般模型第二部分安全功能需求第三部分安全认证需求ISO/IEC 15408第二部分简介ISO/IEC15408第二部分安全功能需求，重要归结信息安全旳功能需求：1．审计——安全审计自动响应、安全审计数据产生、安全审计分析、安全审计评估、安全审计事件选择、安全审计事件存储2．通信——源不可否认、接受不可否认3．密码支持——密码密钥管理、密码操作4．顾客数据保护——访问控制方略、访问控制功能、数据鉴别、出口控制、信息流控制方略、信息流控制功能、入口控制、内部安全传播、剩余信息保护、反转、存储数据旳完整性、内部顾客数据保密传播保护、内部顾客数据完整传播保护5．鉴别和认证——认证失败安全、顾客属性定义、安全阐明、顾客认证、顾客鉴别、顾客主体装订6．安全管理——安全功能旳管理、安全属性管理、安全功能数据管理、撤回、安全属性终止、安全管理角色7．隐私——匿名、使用假名、可解脱性、可随意性8．安全功能保护——底层抽象及其测试、失败安全、输出数据旳可用性、输出数据旳保密性、输出数据旳完整性、内部数据传播安全、物理保护、可信恢复、重放检测、参照仲裁、领域分割、状态同步协议、时间戳、内部数据旳一致性、内部数据复制旳一致性、安全自检。
(A)系统架构设计师-案例分析(二)(总分：100.10，做题时间：90分钟)一、{{B}}案例分析题{{/B}}(总题数：20，分数：100.00)阅读以下软件架构设计的问题，在答题纸上回答问题。
某软件开发公司欲为某电子商务企业开发一个在线交易平台，支持客户完成网上购物活动中的在线交易。
在系统开发之初，企业对该平台提出了如下要求。
(1)在线交易平台必须在1秒内完成客户的交易请求。
(2)该平台必须保证客户个人信息和交易信息的安全。
(3)当发生故障时，该平台的平均故障恢复时间必须小于10秒。
(4)由于企业业务发展较快，需要经常为该平台添加新功能或进行硬件升级。
添加新功能或进行硬件升级必须在6小时内完成。
针对这些要求，该软件开发公司决定采用基于架构的软件开发方法，以架构为核心进行在线交易平台的设计与实现。
（分数：4.00）(1).软件质量属性是影响软件架构设计的重要因素。
请用200字以内的文字列举6种不同的软件质量属性名称，并解释其含义。
（分数：2.00）__________________________________________________________________________________________正确答案：(常见的软件质量属性有多种，例如性能(Performance)、可用性(Availability)、可靠性(Reliability)、健壮性(Robustness)、安全性(Security)、可修改性(Modification)、可变性(Changeability)、易用性(Usability)、可测试性(Testability)、功能性(Functionality)和互操作性(Inter-operation)等。
这些质量属性的具体含义如下。
①性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。
②可用性是系统能够正常运行的时间比例。
中国工商银行企业架构咨询服务项目企业安全架构现状Current Enterprise Security Architecture文件名：日期: 3/22/2022文档信息标题工行企业安全架构现状描述创建日期2007/05/31打印日期2022/3/22文件名工行企业安全架构现状描述存放目录所有者作者甘小戈修订记录日期描述作者2007年8月22日根据用户反馈删除2.2章节《风险管理》甘小戈修改2.1.1章节的金子塔图中文字表述甘小戈甘小戈文档审核/审批此文档需如下审核。
姓名职务/职称文件名：日期: 3/22/2022文档分发此文档将分发至如下各人。
姓名职务/职称目录1 企业安全架构简介ESA Introduction (6)1.1 企业安全架构的目标Objectives of Current ICBC ESA (7)1.2 企业安全架构的范围Scope of Current ESA (7)1.3 构建企业安全架构的方法Approach of Current ESA (8)2 企业安全架构战略现状Current ESA Strategy ...................................... 错误!未定义书签。
2.1 Understanding the Current Environment ....................................... 错误!未定义书签。
2.1.1 战略性分析Current Strategy Analysis ............................ 错误!未定义书签。
2.1.2 安全原则Current Security Principle ............................... 错误!未定义书签。
2.1.3 安全策略Current Security Policies ................................. 错误!未定义书签。
个人信息保护影响评估报告的国际标准与最佳实践案例分析个人信息保护是当今数字化时代不可忽视的重要议题之一。
随着信息技术的迅猛发展，个人信息的收集、存储、处理和共享变得越来越容易。
然而，随之而来的是个人信息泄露、滥用和侵犯的风险。
为了确保个人信息的安全和隐私，越来越多的国家和地区开始制定相关的法规和标准，并提出了个人信息保护影响评估报告的要求。
一、国际标准国际标准组织（ISO）是一个由国际标准化和相关组织组成的国际组织，其目标是制定和推广各种标准，以促进国际贸易的发展和合作。
在个人信息保护领域，ISO制定了一系列标准，其中最具代表性的是ISO/IEC 27001和ISO/IEC 27701。
ISO/IEC 27001是信息安全管理系统（ISMS）的国际标准，该标准提供了一套严格的要求和最佳实践，以确保组织能够有效地管理个人信息的安全。
该标准涵盖了信息安全风险评估、信息安全政策和目标、信息安全组织和资源管理、个人信息保护等各个方面。
ISO/IEC 27701是ISO/IEC 27001的扩展标准，它关注于个人信息的保护和隐私，为组织提供了实施个人信息管理系统（PIMS）的指南。
该标准强调了隐私保护的原则和最佳实践，并为组织提供了一个框架，帮助其评估和管理个人信息保护的风险。
二、最佳实践案例分析在实际应用中，有许多组织已经开始进行个人信息保护影响评估报告，并取得了一些成功的经验。
以下是两个国际标准的最佳实践案例分析：1. 微软公司（Microsoft）个人信息保护影响评估报告微软公司是一家全球知名的科技公司，其关注个人信息保护，并采取了一系列措施来确保用户数据的安全和隐私。
为了满足不同国家和地区的法规要求，微软根据ISO/IEC 27701制定了个人信息保护影响评估报告。
在该报告中，微软详细描述了其个人信息处理的目的和方式，并评估了其可能对个人权利和自由的潜在影响。
该报告还列出了采取的措施和策略，以减轻和管理个人信息保护风险。
