Engineering management requirement in computer information system classified security protection
Some standard content:
GA/T483—2004
GB17859--1999 "Guidelines for Classification of Computer Information System Security Protection Levels" is an important standard for information security level management of computer information systems in my country, which was issued on September 13, 1999. In order to promote the normal and orderly development of computer information system security level management, a series of relevant standards are formulated, including: a series of standards for technical requirements for computer information system security level protection; a series of standards for computer information system security level protection evaluation criteria; a series of standards for computer information system security level protection engineering management requirements; computer information system security level protection management requirements. This standard is one of the above related series of standards. Appendix A of this standard lists the level requirement comparison table. Appendix A of this standard is an informative appendix.
This standard is proposed by the Public Information Network Security Supervision Bureau of the Ministry of Public Security. This standard is under the jurisdiction of the Information System Security Standardization Technical Committee of the Ministry of Public Security. Drafting units of this standard: Public Information Network Security Supervision Bureau of the Ministry of Public Security, the 30th Research Institute of China Electronics Technology Group, and Shanghai Sanling Guard Information Security Co., Ltd.
The main drafters of this standard are: Zhang Jianjun, Wei Zhong, Ye Ming, Chen Kejun, Qing Hao, Wu Xiaoxing. Ⅲ
GA/T483—2004
The information system security level protection project referred to in this standard refers to the new construction, expansion and upgrading of information network systems, information application systems and information resource development projects in accordance with the requirements of GB17859--1999 and its related supporting standards for computer information system security level management.
This standard is not only a guide for the implementation of computer information system security level protection projects, but also a basis for implementing computer information system security level protection projects and establishing a project implementation guarantee system. It is also the basis for the relevant national authorities to conduct computer information system security project level evaluation. This standard can be used as a reference for Party A, Party B, and third parties when constructing security protection projects, and can also be used as a basis and reference for the formulation of laws, regulations, and standards related to the quality of security protection projects. IV
１ Scope
Security Level Protection of Computer Information Systems
Project Management Requirements
GA/T 483---2004
This standard specifies the requirements for the management of computer information system security projects (hereinafter referred to as information security projects). It is a guiding document for the implementation of security projects by Party A, Party B and third parties involved in information security projects. All parties can use this as a basis to establish a security project management system for security projects.
This standard specifies different security requirements for the implementation of projects for computer information systems of different security protection levels in accordance with the five security protection levels divided by GB17859-1999. This standard is applicable to the development and integration project management of computer information systems related to information security in accordance with the requirements of the five security protection levels of GB17859-1999. It can also be used as a reference for organizations that provide security services and security project organizations. This standard is applicable to the project management of security system organizations and developers. It can also be used as a reference for integrators, security service providers and security project organizers.
2 Normative references
The clauses in the following documents become the clauses of this standard through reference in this standard. For all dated references, all subsequent amendments (excluding errata) or revisions are not applicable to this standard. However, parties reaching an agreement based on this standard are encouraged to study whether the latest versions of these documents can be used. For all undated references, the latest versions apply to this standard. GB17859—1999 Criteria for Classification of Computer Information System Security Protection Levels GA/T390--2002 General Technical Requirements for Computer Information System Security Level Protection GA/T391—2002 Management Requirements for Computer Information System Security Level Protection 3 Terms and Definitions
The following terms and definitions apply to this standard. 3.1
information security
Information security
Confidentiality, integrity and availability of information. 3.2
owner
The investor (or owner) of the information system security project, representing the party that needs the information system security project construction. 3.3
Developer
The entity that undertakes the construction of information system security engineering. Through its own efforts, it builds information system security engineering to meet the security needs of information system builders.
Third Party
An organization or institution independent of Party A and Party B. 3.5
Security Engineering
Security Engineering
GA/T483-—2004
System engineering activities carried out to ensure the confidentiality, integrity, availability and other goals of information systems. 3.6
bh Security Engineering Related Activity
Other engineering activities related to security engineering, including: enterprise engineering, system engineering, software engineering, human engineering, communication engineering, hardware engineering, test engineering and system management. 3.7
Security Engineering Lifecycle
Security Engineering Lifecycle Security engineering activities performed throughout the lifecycle of an information system include: concept formation, concept development and definition, verification and validation, engineering implementation development and manufacturing, production and deployment, operation and support, and termination. 3.8
Organizationorganization
A group established according to a certain purpose and system. 3.9
Projectproject
A project is the sum of various related implementation activities and resources used to develop or maintain information security engineering. A project often has associated funding, cost accounts, and delivery schedules. 3.10
Processprocess
A series of structured processes on one or more inputs and transforms the results of the processes into interrelated or interacting activities that are valuable to users.
Vulnerabilityvulnerability
A part of a system that is not intended by design, such as a weakness, security hole, or implementation defect, which can be exploited by threats to attack the system. 3.12
Process CapabilityprocessCapability
Quantitative indicator for assessing the ability of an organization to follow engineering processes. 3.13
Process Maturity
Indicates the degree to which a specific process is clearly defined, managed, measured, and controlled, and its effectiveness. 3.14
Process Management
Process Management
A series of activities and architectures used to foresee, evaluate, and control process execution. 3.15
Security Engineering Guidesecurity Engineering GuideDecisions made by the engineering team on how to select the engineering architecture, design, and implementation. 3.16
Key Resourcekeyresource
Important resources that have a decisive impact on the success of a project. 4 Security Engineering System
4.1 Overview
Requirements for Level of Protection of Computer Information System Security EngineeringThe architecture can determine the level of security engineering requirements within the entire security engineering scope. The goal of this standard using this architecture is to clearly separate the basic characteristics of security engineering from management and institutional characteristics, and to establish a hierarchical management model for security engineering. bzxz.net
4.2 Security Engineering Objectives
GA/T483—2004
Understand the security risks of users, establish reasonable security requirements based on the identified security risks, and convert security requirements into security guidelines. These security guidelines guide other activities of project implementation, and establish confidence and assurance in information security under correct and effective security mechanisms; judge the residual security vulnerabilities in the system and during system operation, and whether their impact on operation is tolerable (i.e., acceptable risk), so that security engineering becomes a credible engineering activity that can meet the requirements of information system design at the corresponding level. 4.3 Basic model
A two-dimensional model consisting of security level, assurance and implementation (as shown in Figure 1), in which assurance is composed of qualification assurance requirements and organizational assurance requirements, and implementation is composed of engineering implementation requirements and project implementation requirements. Qualification assurance requirements represent the qualification requirements of Party B or third parties related to the project that should have a certain capability level; organizational assurance requirements represent the requirements for Party A's organizational assurance in the information security engineering process requirements; engineering implementation requirements represent the requirements for the security process in the information security engineering; and project implementation requirements represent the requirements for the project implementation process of the information security engineering.
Security level
Level 5
Level 4
Level 3
Level 2
Level 1,
Assurance and implementation
5 Qualification assurance requirements
5.1 System integration qualification requirements
Organizational assurance
Figure 1 Security engineering level protection model
5.1.1 The national competent authority recognizes the first-level integration qualification. 5.1.2 The national competent authority recognizes the second-level integration qualification. 5.1.3 The national competent authority recognizes the third-level integration qualification. 5.1.4 The national competent authority recognizes the fourth-level integration qualification. 5.2 Personnel qualification requirements
The Ministry of Public Security recognizes the service personnel qualifications.
5.3 Third-party service requirements
5.3.1 The Ministry of Public Security recognizes the first-level service unit qualifications. 5.3.2 The Ministry of Public Security recognizes the second-level service unit qualifications. 5.3.3 The Ministry of Public Security recognizes the third-level service unit qualifications. 5.3.4 The Ministry of Public Security recognizes the fourth-level service unit qualifications. 5.3.5 The Ministry of Public Security recognizes the fifth-level service unit qualifications. Qualification guarantee
GA/T 483—2004
5.4 Security product requirements
5.4.1 Information security products should have a license for production, operation and sales in China. 5.4.2 The operating system meets the same level of protection level operating system requirements. 5.5 Project supervision requirements
5.5.1 There should be a supervision and management system for the implementation of information security system construction projects. 5.5.2 The system employs a professional supervision company, and the supervision company has a supervision qualification certificate recognized by the national competent department. 5.6 Cryptography management requirements
5.6.1 Comply with the requirements of the national cryptography competent department. 5.6.2 The cryptography products used are cryptography products approved by the national competent department. 5.6.3 The source of the cryptography products is the products of the designated sales units approved by the national competent department. 5.6.4 The development of the cryptography products used comes from the cryptography development units approved by the national competent department. 5.7 Other requirements
The system complies with relevant laws and regulations on public security, and effectively controls illegal information and malicious codes in accordance with the technical management regulations of the relevant competent departments, and controls the equipment in accordance with relevant regulations so that it is not used as a source or springboard for illegal attacks. 6 Organizational assurance requirements
6.1 Define the organization's system engineering process
6.1.1 Set process goals
6.1.1.1 Set goals for the organization's system engineering process based on the organization's application goals. 6.1.1.2 The systems engineering process operates in a business environment. In order to institutionalize the organization's standards, this goal should be clearly recognized; the goals of this process should consider financial, quality, human resources and issues that are important to business success. 6.1.2 Collect process assets
6.1.2.1 Collect and maintain system engineering process assets. 6.1.2.2 At the organizational and project levels, the information generated by process definition activities needs to be stored (in the process asset library) so that the assets from the tailoring and process design activities can be understood by the users and maintained and maintained. 6.1.3 Develop the organization's systems engineering process
6.1.3.1 Develop a fully defined standard systems engineering process for the organization. 6.1.3.2 In developing the organization's standard systems engineering process, equipment in the process asset library may be used; when developing tasks, some new process assets may be required, and these assets should be added to the process asset library; the organization's standard systems engineering process should be placed in the process asset library.
6.1.4 Define Tailoring Guide
Define the guidelines for tailoring the organization's standard systems engineering processes to be used during the definition of development projects. 6.2 Improve the Organization's Systems Engineering Processes
6.2.1 Overview
This requirement item includes continuous activities to measure and improve the performance of systems engineering processes in the organization, leveraging the initial collection of organizational process assets and the definition of the organization's standard systems engineering processes to gain greater competitive advantage by continually improving the effectiveness and efficiency of the systems engineering processes used by the organization.
6.2.2 Assessment Process
6.2.2.1 Assess the organization's existing performance processes to understand their strengths and weaknesses. Understanding the strengths and weaknesses of the organization's existing performance processes is key to establishing a baseline for improvement activities. 6.2.2.2 The assessment should consider both the measurement and learning process of process performance; the assessment can be conducted in a variety of forms, and the choice of assessment method should match the culture and organizational needs.
6.2.3 Plan process improvements
GA/T 483—2004
A process improvement plan should be developed for the organization based on an analysis of the impact of potential improvements to achieve the process objectives. 6.2.4 Change standard processes
Change the organization's standard system engineering processes to reflect the improvement of objectives 6.2.5 Communicate process improvements
Appropriately communicate process improvements with existing projects and other interested parties. 6.3 Manage product family evolution
6.3.1 Overview
The product family should evolve toward its ultimate goal by introducing services, equipment and new technologies to achieve product updates, reduce engineering costs, and achieve the best benefits in engineering progress and execution. 6.3.2 Define product evolution
6.3.2.1 Define the types of products to be provided. 6.3.2.2 Define the product family that supports the strategic objectives of the organization. 6.3.2.3 Consider the organization's strengths and weaknesses, competitive advantages, potential market share and available technologies. 6.3.3 Identify new production technologies
6.3.3.1 Identify new production technologies or enhance infrastructure that will help the organization acquire, develop and apply new production technologies to improve competitive advantage.
6.3.3.2 Identify new production technologies that may be introduced into the product line, and establish and maintain source data and methods for identifying new technologies and infrastructure improvements.
6.3.4 Adapt the development process
6.3.4.1 Make necessary changes in the product development cycle to support the development of new products. 6.3.4.2 Adapt the organization's product development process and be familiar with and utilize components that are intended for future use. 6.3.5 Ensure the availability of key components
6.3.5.1 Ensure that key components are available and can support planned product improvements. 6.3.5.2 The organization shall determine the key components of the product line and the plan for their availability. 6.3.6 Insert product technology
6.3.6.1 Insert new technology into product development, marketing and manufacturing processes. 6.3.6.2 Manage the work of introducing new technology into the product series (including the improvement of existing product series components and the introduction of new components); identify and manage the risks associated with product design changes. 6.4 Manage the system engineering support environment
6.4.1 Overview
This requirement item lists the items that belong to the system engineering support environment at both the project level and the organizational level. The elements of the support environment are composed of all environments for system engineering activities, including: computer resources, network bandwidth, analysis methods, organizational structure policies and procedures, machine purchases, chemical processing facilities, environmental stress facilities, system engineering simulation tools, software development tools, proprietary system engineering tools, workspace, etc. 6.4.2 Maintain technology awareness
6.4.2.1 Maintain awareness of those technologies that support the achievement of organizational goals. 6.4.2.2 New technologies should be inserted into the current state of the process or implementation, and the organization should have a full understanding of the new technologies. 6.4.3 Determine support requirements
Determine the requirements for the organization's systems engineering support environment based on the needs of the organization. 6.4.4 Obtain a systems engineering support environment
6.4.4.1 Obtain a systems engineering support environment that meets the requirements established by implementing the analysis of candidate solution requirements in determining support requirements.
6.4.4.2 Determine the evaluation criteria and potential candidate solutions for the required systems engineering support environment; select a solution using the analysis of candidate solution requirements; obtain and implement the selected systems engineering support environment. 5
GA/T 483—2004
6.4.5 Tailor the systems engineering support environment
Tailor the systems engineering support environment to meet the requirements of individual projects. 6.4.6 Insert new technology
6.4.6.1 Insert new technology into the system engineering support environment according to the organization's application goals and project needs. 6.4.6.2 The organization's system engineering support environment is updated with new technology and supports the organization's application goals and engineering needs; training on the use of new technology should be provided in the system engineering support environment. 6.4.7 Maintain the environment
6.4.7.1 Maintain the system engineering support environment to continuously support projects that rely on the environment. 6.4.7.2 Maintenance activities include computer system management, training, hotline support, expert roles, development or expansion of a technology library, etc. 6.4.8 Monitor the system engineering support environment
6.4.8.1 Monitor the system engineering support environment to identify opportunities for improvement. 6.4.8.2 Determine factors that affect the usefulness of the system engineering support environment, including any newly inserted technology; monitor the acceptance of new technologies and the entire system engineering support environment.
6.5 Training
6.5.1 Determine training requirements
6.5.1.1 Guided by the project requirements, the organization's strategic plan, and the existing workforce skills, determine the improvements needed in the organization's skills and knowledge.
6.5.1.2 Determine these requirements based on information from existing procedures, the organization's strategic plan, and the skills of the existing workforce. 6.5.2 Select modes for acquiring knowledge or skills 6.5.2.1 Evaluate and select appropriate modes for acquiring knowledge or skills through training or other resources. 6.5.2.2 Ensure that the methods selected are optimal so that the required skills and knowledge are available and effective for the project in a timely manner. 6.5.3 Ensure the availability of skills and knowledge
Ensure that the skills and knowledge are applicable to system engineering activities. 6.5.4 Prepare training materials
6.5.4.1 Prepare training materials based on the identified training requirements. 6.5.4.2 Prepare training materials for each class established by personnel within the organization, or prepare training materials for each existing class. 6.5.5 Training personnel
6.5.5.1 Training instructors should have the skills and knowledge to perform the roles assigned to them. 6.5.5.2 Personnel training should be carried out according to the training plan and the prepared materials. 6.5.6 Evaluate the effectiveness of training
6.5.6.1 Evaluate the effectiveness of training to meet the determined training requirements. 6.5.6.2 The methods for evaluating effectiveness should be listed at the same time as the preparation of the training plan and the preparation of training materials; the results of the effectiveness evaluation should be obtained in a timely manner so that the training can be adjusted accordingly. 6.5.7 Maintain training records
6.5.7.1 Maintain records of training and experience gained. 6.5.7.2 Maintain records to track the training status of each person and the skills and abilities after training. 6.5.8 Maintain training materials
6.5.8.1 Maintain training materials in the knowledge base. 6.5.8.2 Maintain course materials in a knowledge base for future access by employees and to track changes to course materials. 6.6 Coordinate with suppliers
6.6.1 Determine system components or services
Determine system components or services that should be provided by other external organizations. 6.6.2 Determine competent suppliers or vendors6
6.6.2.1 Identify suppliers with expertise in specific areas. GA/T 483-2004
6.6.2.2 The supplier's capabilities include competence in development processes, manufacturing processes, verification responsibilities, timely delivery, life cycle support processes, and remote effective communication capabilities. The above capabilities should meet the requirements of this organization. 6.6.3 Select suppliers or vendors
6.6.3.1 Select suppliers in accordance with requirement (7.1). 6.6.3.2 Select suppliers in a logical and fair manner to meet product objectives; provide supplier characteristics that best complement the organization's capabilities and identify qualified candidates; use the implementation of requirements (7.1) to select appropriate suppliers. 6.6.4 Provide expectations
6.6.4.1 Provide suppliers with the organization's requirements, expectations and performance indicators for system components or services. 6.6.4.2 When signing a contract, the organization should clearly specify and prioritize its requirements and expectations, and specify all restrictions on suppliers; the organization should work closely with suppliers to fully understand the requirements to be met by the product and the responsibilities it must assume, and reach a mutual understanding.
6.6.5 Maintain communication
6.6.5.1 Maintain timely two-way communication with suppliers. 6.6.5.2 The organization and suppliers should establish a mutual understanding of expected and required communication. The characteristics of the communication established include: the types of information that are recognized by both parties to be open without any restrictions, the types of information that are restricted (such as policies or contractual relationships), the expected timeliness of information requests and responses, the tools and methods used for communication, security, confidentiality, and the expected distribution. 7 Project Implementation Requirements
7.1 Management Security Control
7.1.1 Overview
It should be ensured that the system achieves the expected security characteristics of the design under the operating state, and the security control measures are configured and can be used normally. 7.1.2 Establish Security Responsibilities
7.1.2.1 Establish the responsibilities and responsibilities of security control measures and notify everyone in the organization. 7.1.2.2 This project should ensure that the personnel with corresponding security responsibilities are responsible and have obtained the corresponding authorization; it should ensure that all security control measures adopted are clear and widely and consistently applied. 7.1.3 Management Security Measures Configuration
7.1.3.1 The security configuration of all equipment needs to be managed. 7.1.3.2 Manage the configuration of system security control measures. Manage security awareness, training and education programs7.1.4
Organize and manage security awareness training and education for all employees.7.1.4.1
7.1.4.2 Manage security awareness, training and education programs for all users and administrators. Manage security services and controls
General management of security services and controls is similar to the management of other services and controls, including protecting them from damage, accidental7.1.5.1
accidents and human failures, and documenting and documenting them according to legal and policy requirements.7.1.5.2 Perform regular maintenance and management of security services and controls.7.2 Assess impacts
7.2.1 General
Identify the impacts of concern to the system and assess the likelihood of their occurrence.7.2.2 Prioritize impacts
Identify, analyze and prioritize the critical operational, business or mission capabilities of the system. 7.2.3 Identify system assets
7.2.3.1 Identify the system assets that support the safety objectives or critical capabilities (operational, business or mission functions). 7
GA/T 483—2004
7.2.3.2 Identify the necessary system resources and data; define each asset by evaluating the significance of each asset in providing such support in a given environment. 7.2.3.3 Identify and characterize the system assets that support the critical operational capabilities or safety objectives of the system. 7.2.4 Select metrics for impact
Appropriate metrics should be determined in advance for assessing impacts. 7.2.5 Identify metric relationships
Identify the relationship between the metrics for assessing the selected impacts and the metric conversion factors. 7.2.6 Identify and characterize impacts
Use multiple metrics or unified metrics to identify and characterize the unexpected impacts of the incident. 7.2.7 Monitor impacts
Monitor changes in impacts. This clause is closely linked to the generic monitoring activities in 7.8.3. 7.3 Assess security risks
7.3.1 Overview
By understanding the security risks associated with operating the system in a given environment, and prioritizing risk issues according to a given methodology.
7.3.2 Select risk analysis methods
7.3.2.1 This requirement item includes defining a method for identifying system security risks in a given environment, which is a method for analyzing, evaluating and comparing security risks; it should include a scheme for classifying and grading risks based on relevant issues such as threats, operating functions, established system vulnerabilities, potential losses, security requirements, etc. 7.3.2.2 Select methods, techniques and criteria for analyzing, evaluating and comparing system security risks in a given environment. 7.3.3 Identify risks
7.3.3.1 Identify the risk, recognize the stakes of these threats and vulnerabilities, and then identify the impact caused by threats and vulnerabilities; these risks should be considered in selecting system protection measures. 7.3.3.2 Identify the threat/vulnerability/impact combination (risk). 7.3.4 Assess risks
7.3.4.1 Identify the probability of each risk occurring. 7.3.4.2 Assess the risk associated with each risk. 7.3.5 Assess overall uncertainty
7.3.5.1 Each risk has an uncertainty associated with it; the overall risk uncertainty is the accumulation of the uncertainties of the threats, vulnerabilities and impacts and their characteristics identified in 7.4.6, 7.4.6, 7.5.4 and 7.3.6. This requirement item is closely related to 7.6 because evidence can be used to track modifications that reduce uncertainty under certain inputs. 7.3.5.2 Assess the overall uncertainty associated with the risk. 7.3.6 Prioritize risks
7.3.6.1 The identified risks should be ranked based on organizational priorities, the likelihood of the risk occurring, the uncertainty associated with these factors, and the available financial resources; risks can be mitigated, avoided, transferred or accepted, or a combination of these measures can be used. The measure of "mitigation" can address the threat, vulnerability, impact or risk itself; the choice of security measures should take into account the requirements of 7.10 "Specify security requirements", business priorities and the overall system architecture. 7.3.6.2 Prioritize the risks. 7.3.7 Monitor risks and their characteristics
7.3.7.1 Check new risks regularly. This clause is closely related to the general monitoring activities in 7.8.3 "Monitor changes in threats, vulnerabilities, impacts, risks and environment".
7. 3.7.2 Monitor changes in risk frequency and changes in risk characteristics. 7.4 Evaluate threats
7.4.1 Overview
GA/T 483—2004
Security threats and their nature and characteristics should be identified, and threats to system security should be identified and characterized; threats should be monitored regularly to ensure that the security understanding generated by this requirement is always maintained. 7.4.2 Identify natural threats
Identify corresponding threats caused by natural causes. 7.4.3 Identify man-made threats
Identify threats caused by accidental man-made causes and threats caused by intentional actions. 7.4.4 Identify threat measurement scales
7.4.4.1 For expected events that may occur in a specific location, establish the maximum and minimum measurement unit ranges based on the actual situation. 7.4.4.2 Identify the appropriate measurement scale and scope of application in a specific environment. 7.4.5 Evaluate the effects of threat impacts
7.4.5.1 Determine the potential capabilities of hackers to successfully attack the system. 7.4.5.2 Evaluate the causes and consequences of threat impacts caused by human factors. 7.4.6 Evaluate the likelihood of threats
Evaluate the likelihood of how threat events occur and the likelihood of threat events occurring. 7.4.7 Monitor threats and their characteristics
7.4.7.1 Regularly monitor existing threats and their characteristics and check for new threats; this clause is closely related to the general monitoring activities of 7.8.3.
7.4.7.2 Monitor the constant changes in the threat spectrum and the changes in corresponding characteristics. 7.5 Evaluate Vulnerabilities
7.5.1 General
System security vulnerabilities shall be identified and characterized. This requirement includes analyzing system assets, defining specific vulnerabilities, and providing an assessment of overall system vulnerabilities, and obtaining an understanding of system security vulnerabilities in a defined environment. 7.5.2 Select Vulnerability Analysis Methods
7.5.2.1 All analyses shall be conducted within a known and documented configuration framework within a pre-arranged and specified timeframe; the analysis methodology shall include expected results; and the specific objectives of the analysis shall be clearly stated. 7.5.2.2 Select methods, techniques, and standards for identifying and characterizing system security vulnerabilities in a defined environment. 7.5.3 Identify Vulnerabilities
The vulnerability analysis methodology studied in 7.5.2 shall be extended to the verification of vulnerabilities; all discovered system security vulnerabilities shall be documented and identified.
7.5.4 Collect Vulnerability Data
Collect data related to vulnerabilities.
7.5.5 Comprehensive system vulnerability
Analyze which vulnerabilities or combinations of vulnerabilities will cause problems to the system. All analyses should identify the characteristics of the vulnerability; evaluate the system vulnerability and overall vulnerability caused by specific vulnerabilities and specific vulnerability combinations. 7.5.6 Monitor vulnerabilities and their characteristics
7.5.6.1 This requirement is closely related to the general monitoring activities of changes in 7.8.3. 7.5.6.2 Monitor the continuous changes of vulnerabilities and their characteristics. 7.6 Establish assurance evidence
7.6.1 Overview
This project includes the identification and definition of assurance related to requirements, including the generation and analysis of evidence, including additional evidence required to support assurance requirements, document lists and processes, and those that can clearly provide users with evidence that their security requirements have been met. This project requires the establishment of records of activities related to assurance evidence, including management, identification, planning, packaging and submission of security assurance evidence. GA/T 483—2004
7.6.2 Identify assurance objectives
7.6.2.1 Identify security assurance objectives.
7.6.2.2 The system security assurance objectives shall specify the confidentiality level of the mandatory system security policy: the adequacy of the objectives shall be determined by the developers, integrators, users and signature authorizers.
7.6.2.3 The identification of new and modified security assurance objectives shall be coordinated with all security-related groups such as internal and external engineering organizations.
7.6.2.4 The changes to the security assurance objectives shall be explained in a timely manner. 7.6.2.5 The security assurance objectives shall be clearly communicated. 7.6.3 Define assurance strategies
7.6.3.1 Plan and ensure that the mandatory security objectives are correctly achieved; the evidence generated by the implementation of the security assurance strategy shall provide (to the system signature authorizer) an acceptable confidentiality level, and this level of security measurement is sufficient to manage security risks. By developing and issuing a security assurance strategy, effective management of assurance-related activities is achieved; the identification and definition of assurance related to requirements in the early stage of the project generates necessary supporting evidence; through continuous external coordination, the satisfaction of user requirements is understood and monitored to ensure high-quality combined assurance requirements.
7.6.3.2 Define a security assurance strategy for all assurance objectives. 7.6.4 Control assurance evidence
Security assurance evidence is collected by coordinating with all engineering implementation requirements and using evidence from different levels of abstraction identified in the security assurance strategy; evidence should be controlled. 7.6.5 Analyze evidence
Analyze security assurance evidence to ensure that the engineering product is complete and correct relative to the baseline system. 7.6.6 Provide assurance arguments
7.6.6.1 Develop a complete security assurance argument that proves consistency with the security objectives and provide it to the user; the assurance argument is a series of declarative assurance objectives supported by a combination of assurance evidence obtained from multiple levels of abstraction; defects in the submitted evidence and defects in the security assurance objectives should be reviewed.
7.6.6.2 Provide security assurance arguments to prove that user security requirements are met. 7.7 Coordinate security
7.7.1 Overview
Ensure that all departments have a sense of participation in security engineering, coordinate and maintain the relationship between the involved security organizations, other engineering organizations and external organizations; a variety of mechanisms are used to coordinate and communicate decisions and suggestions on security engineering between these departments, including memoranda, documents, emails, meetings and working groups.
All members of the project team should have a sense of participation in security engineering work, and decisions and suggestions on security are the result of mutual communication and coordination.
Professional security engineers should be all major design teams and working groups, development and operation organizations; the connection between security engineering and other engineering teams should be established early in the engineering life cycle after key design decisions are made. 7.7.2 Define coordination objectives
Define and establish connections and obligations with other organizations; these relationships should be accepted by all participating departments. 7.7.3 Identify coordination mechanisms
Identify the coordination mechanism for security engineering and clarify the methods for implementing the coordination mechanism. 7.7.4 Promote coordination
7.7.4.1 Ensure that different organizations with different priorities communicate and that any conflicts and disputes that may arise are resolved in an appropriate and productive manner.
7.7.4.2 Promote coordination of security engineering.
7.7.5 Coordinate security decisions and recommendations6 is closely related, because evidence can be used to track modifications that reduce uncertainty under certain inputs. 7.3.5.2 Assess the overall uncertainty associated with the risk. 7.3.6 Risk Prioritization
7.3.6.1 The identified risks should be ranked based on organizational priorities, the likelihood of the risk occurring, the uncertainty associated with these factors, and available financial resources; risks can be mitigated, avoided, transferred or accepted, or a combination of these measures can be used. The "mitigation" measure can address threats, vulnerabilities, impacts, or the risk itself; the choice of security measures should take appropriate account of the requirements in 7.10 "Specify security requirements", business priorities and the overall system architecture. 7.3.6.2 Prioritize risks. 7.3.7 Monitor risks and their characteristics
7.3.7.1 Check for new risks regularly. This clause is closely related to the general monitoring activities in 7.8.3 "Monitor changes in threats, vulnerabilities, impacts, risks and the environment".
7. 3.7.2 Monitor changes in risk frequency and changes in risk characteristics. 7.4 Evaluate threats
7.4.1 Overview
GA/T 483—2004
Security threats and their nature and characteristics should be identified, and threats to system security should be identified and characterized; threats should be monitored regularly to ensure that the security understanding generated by this requirement is always maintained. 7.4.2 Identify natural threats
Identify corresponding threats caused by natural causes. 7.4.3 Identify man-made threats
Identify threats caused by accidental man-made causes and threats caused by intentional actions. 7.4.4 Identify threat measurement scale
7.4.4.1 For expected events that may occur in a specific location, the maximum and minimum measurement unit ranges should be established based on the actual situation. 7.4.4.2 Identify the appropriate measurement scale and scope of application in a specific environment. 7.4.5 Evaluate the effect of threat impact
7.4.5.1 Determine the potential capabilities of hackers to successfully attack the system. 7.4.5.2 Evaluate the causes and consequences of threat impacts caused by human factors. 7.4.6 Evaluate the likelihood of threats
Evaluate the likelihood of how threat events occur and evaluate the likelihood of threat events occurring. 7.4.7 Monitor threats and their characteristics
7.4.7.1 Regularly monitor existing threats and their characteristics, and check for new threats; this item is closely linked to the general monitoring activities of 7.8.3.
7.4.7.2 Monitor the constant changes in the threat spectrum and the changes in corresponding characteristics. 7.5 Evaluate vulnerabilities
7.5.1 Overview
The security vulnerabilities of the system should be identified and characterized. This requirement item includes analyzing system assets, defining specific vulnerabilities, and providing an assessment of the vulnerabilities of the entire system, and obtaining an understanding of the security vulnerabilities of the system in a determined environment. 7.5.2 Select vulnerability analysis methods
7.5.2.1 All analyses should be conducted within a known and documented configuration framework within a pre-arranged and specified time; the analysis methodology should include expected results; the specific objectives of the analysis should be clearly stated. 7.5.2.2 Select methods, techniques and standards for identifying and characterizing system security vulnerabilities in a defined environment. 7.5.3 Identify vulnerabilities
The vulnerability analysis methodology studied in 7.5.2 should be extended to the verification of vulnerabilities; all discovered system security vulnerabilities should be recorded and identified.
7.5.4 Collect vulnerability data
Collect data related to vulnerabilities.
7.5.5 Comprehensive system vulnerabilities
Analyze which vulnerabilities or combinations of vulnerabilities will cause problems to the system. All analyses should identify the characteristics of the vulnerability; evaluate the system vulnerability and overall vulnerability caused by specific vulnerabilities and specific combinations of vulnerabilities. 7.5.6 Monitor vulnerabilities and their characteristics
7.5.6.1 This requirement is closely linked to the general monitoring activities for changes in 7.8.3. 7.5.6.2 Monitor the continuous changes in vulnerabilities and their characteristics. 7.6 Establish assurance evidence
7.6.1 Overview
This item includes the identification and definition of assurance related to requirements, including activities for the generation and analysis of evidence, including additional evidence, document lists and processes required to support assurance requirements, and those that clearly provide users with evidence that their security requirements have been met. This item requires the establishment of records of activities related to assurance evidence, including the management, identification, planning, packaging and submission of security assurance evidence. GA/T 483—2004
7.6.2 Identify assurance objectives
7.6.2.1 Identify security assurance objectives.
7.6.2.2 The system security assurance objectives shall specify the confidentiality level of the mandatory system security policy: the adequacy of the objectives shall be determined by the developer, integrator, user and signature authorizer.
7.6.2.3 The identification of new and modified security assurance objectives shall be coordinated with all security-related groups such as internal and external engineering organizations.
7.6.2.4 The changes in the security assurance objectives shall be explained in a timely manner. 7.6.2.5 The security assurance objectives shall be clearly communicated. 7.6.3 Define the assurance strategy
7.6.3.1 Plan and ensure that the mandatory security objectives are correctly achieved; the evidence generated by the implementation of the security assurance strategy shall provide (to the system signature authorizer) an acceptable confidentiality level, and this level of security measurement is sufficient to manage security risks. Through the development and promulgation of the security assurance strategy, effective management of assurance-related activities is achieved; the identification and definition of assurance related to requirements in the early stage of engineering shall generate necessary supporting evidence; through continuous external coordination, the satisfaction of assurance user requirements is understood and monitored to ensure high-quality combined assurance requirements.
7.6.3.2 Define a security assurance strategy for all assurance objectives. 7.6.4 Control Assurance Evidence
Security assurance evidence is collected by means of evidence at different levels of abstraction identified within the security assurance strategy in coordination with all engineering implementation requirements; evidence should be controlled. 7.6.5 Analyze Evidence
Analyze security assurance evidence to ensure that the engineering product is complete and correct relative to the baseline system. 7.6.6 Provide Assurance Arguments
7.6.6.1 Develop a complete security assurance argument that proves consistency with security objectives and provide it to users; the assurance argument is a series of declarative assurance objectives supported by a combination of assurance evidence obtained from multiple levels of abstraction; deficiencies in the submitted evidence and deficiencies in the security assurance objectives should be reviewed.
7.6.6.2 Provide security assurance arguments that prove that user security requirements are met. 7.7 Coordinate safety
7.7.1 Overview
Ensure that all departments have a sense of participation in safety engineering, coordinate and maintain the relationship between the involved safety organizations, other engineering organizations and external organizations; a variety of mechanisms are used to coordinate and communicate safety engineering decisions and suggestions between these departments, including memoranda, documents, emails, meetings and working groups.
All members of the project team should have a sense of participation in safety engineering work, and the decisions and suggestions on safety are the result of mutual communication and coordination.
Professional safety engineers should be all major design teams and working groups, development and operation organizations; the connection between safety engineering and other engineering teams should be established early in the engineering life cycle after key design decisions are made. 7.7.2 Define coordination objectives
Define and establish the connection and obligation relationship with other organizations; these relationships should be accepted by all participating departments. 7.7.3 Identify coordination mechanism
Identify the coordination mechanism of safety engineering and clarify the method to implement the coordination mechanism. 7.7.4 Promote coordination
7.7.4.1 Ensure that different organizations with different priorities communicate and that any conflicts and disputes that may arise are resolved in an appropriate and productive manner.
7.7.4.2 Promote coordination of security engineering.
7.7.5 Coordinate security decisions and recommendations6 is closely related, because evidence can be used to track modifications that reduce uncertainty under certain inputs. 7.3.5.2 Assess the overall uncertainty associated with the risk. 7.3.6 Risk Prioritization
7.3.6.1 The identified risks should be ranked based on organizational priorities, the likelihood of the risk occurring, the uncertainty associated with these factors, and available financial resources; risks can be mitigated, avoided, transferred or accepted, or a combination of these measures can be used. The "mitigation" measure can address threats, vulnerabilities, impacts, or the risk itself; the choice of security measures should take appropriate account of the requirements in 7.10 "Specify security requirements", business priorities and the overall system architecture. 7.3.6.2 Prioritize risks. 7.3.7 Monitor risks and their characteristics
7.3.7.1 Check for new risks regularly. This clause is closely related to the general monitoring activities in 7.8.3 "Monitor changes in threats, vulnerabilities, impacts, risks and the environment".
7. 3.7.2 Monitor changes in risk frequency and changes in risk characteristics. 7.4 Evaluate threats
7.4.1 Overview
GA/T 483—2004
Security threats and their nature and characteristics should be identified, and threats to system security should be identified and characterized; threats should be monitored regularly to ensure that the security understanding generated by this requirement is always maintained. 7.4.2 Identify natural threats
Identify corresponding threats caused by natural causes. 7.4.3 Identify man-made threats
Identify threats caused by accidental man-made causes and threats caused by intentional actions. 7.4.4 Identify threat measurement scale
7.4.4.1 For expected events that may occur in a specific location, the maximum and minimum measurement unit ranges should be established based on the actual situation. 7.4.4.2 Identify the appropriate measurement scale and scope of application in a specific environment. 7.4.5 Evaluate the effect of threat impact
7.4.5.1 Determine the potential capabilities of hackers to successfully attack the system. 7.4.5.2 Evaluate the causes and consequences of threat impacts caused by human factors. 7.4.6 Evaluate the likelihood of threats
Evaluate the likelihood of how threat events occur and evaluate the likelihood of threat events occurring. 7.4.7 Monitor threats and their characteristics
7.4.7.1 Regularly monitor existing threats and their characteristics, and check for new threats; this item is closely linked to the general monitoring activities of 7.8.3.
7.4.7.2 Monitor the constant changes in the threat spectrum and the changes in corresponding characteristics. 7.5 Evaluate vulnerabilities
7.5.1 Overview
The security vulnerabilities of the system should be identified and characterized. This requirement item includes analyzing system assets, defining specific vulnerabilities, and providing an assessment of the vulnerabilities of the entire system, and obtaining an understanding of the security vulnerabilities of the system in a determined environment. 7.5.2 Select vulnerability analysis methods
7.5.2.1 All analyses should be conducted within a known and documented configuration framework within a pre-arranged and specified time; the analysis methodology should include expected results; the specific objectives of the analysis should be clearly stated. 7.5.2.2 Select methods, techniques and standards for identifying and characterizing system security vulnerabilities in a defined environment. 7.5.3 Identify vulnerabilities
The vulnerability analysis methodology studied in 7.5.2 should be extended to the verification of vulnerabilities; all discovered system security vulnerabilities should be recorded and identified.
7.5.4 Collect vulnerability data
Collect data related to vulnerabilities.
7.5.5 Comprehensive system vulnerabilities
Analyze which vulnerabilities or combinations of vulnerabilities will cause problems to the system. All analyses should identify the characteristics of the vulnerability; evaluate the system vulnerability and overall vulnerability caused by specific vulnerabilities and specific combinations of vulnerabilities. 7.5.6 Monitor vulnerabilities and their characteristics
7.5.6.1 This requirement is closely linked to the general monitoring activities for changes in 7.8.3. 7.5.6.2 Monitor the continuous changes in vulnerabilities and their characteristics. 7.6 Establish assurance evidence
7.6.1 Overview
This item includes the identification and definition of assurance related to requirements, including activities for the generation and analysis of evidence, including additional evidence, document lists and processes required to support assurance requirements, and those that clearly provide users with evidence that their security requirements have been met. This item requires the establishment of records of activities related to assurance evidence, including the management, identification, planning, packaging and submission of security assurance evidence. GA/T 483—2004
7.6.2 Identify assurance objectives
7.6.2.1 Identify security assurance objectives.
7.6.2.2 The system security assurance objectives shall specify the confidentiality level of the mandatory system security policy: the adequacy of the objectives shall be determined by the developer, integrator, user and signature authorizer.
7.6.2.3 The identification of new and modified security assurance objectives shall be coordinated with all security-related groups such as internal and external engineering organizations.
7.6.2.4 The changes in the security assurance objectives shall be explained in a timely manner. 7.6.2.5 The security assurance objectives shall be clearly communicated. 7.6.3 Define the assurance strategy
7.6.3.1 Plan and ensure that the mandatory security objectives are correctly achieved; the evidence generated by the implementation of the security assurance strategy shall provide (to the system signature authorizer) an acceptable confidentiality level, and this level of security measurement is sufficient to manage security risks. Through the development and promulgation of the security assurance strategy, effective management of assurance-related activities is achieved; the identification and definition of assurance related to requirements in the early stage of engineering shall generate necessary supporting evidence; through continuous external coordination, the satisfaction of assurance user requirements is understood and monitored to ensure high-quality combined assurance requirements.
7.6.3.2 Define a security assurance strategy for all assurance objectives. 7.6.4 Control Assurance Evidence
Security assurance evidence is collected by means of evidence at different levels of abstraction identified within the security assurance strategy in coordination with all engineering implementation requirements; evidence should be controlled. 7.6.5 Analyze Evidence
Analyze security assurance evidence to ensure that the engineering product is complete and correct relative to the baseline system. 7.6.6 Provide Assurance Arguments
7.6.6.1 Develop a complete security assurance argument that proves consistency with security objectives and provide it to users; the assurance argument is a series of declarative assurance objectives supported by a combination of assurance evidence obtained from multiple levels of abstraction; deficiencies in the submitted evidence and deficiencies in the security assurance objectives should be reviewed.
7.6.6.2 Provide security assurance arguments that prove that user security requirements are met. 7.7 Coordinate safety
7.7.1 Overview
Ensure that all departments have a sense of participation in safety engineering, coordinate and maintain the relationship between the involved safety organizations, other engineering organizations and external organizations; a variety of mechanisms are used to coordinate and communicate safety engineering decisions and suggestions between these departments, including memoranda, documents, emails, meetings and working groups.
All members of the project team should have a sense of participation in safety engineering work, and the decisions and suggestions on safety are the result of mutual communication and coordination.
Professional safety engineers should be all major design teams and working groups, development and operation organizations; the connection between safety engineering and other engineering teams should be established early in the engineering life cycle after key design decisions are made. 7.7.2 Define coordination objectives
Define and establish the connection and obligation relationship with other organizations; these relationships should be accepted by all participating departments. 7.7.3 Identify coordination mechanism
Identify the coordination mechanism of safety engineering and clarify the method to implement the coordination mechanism. 7.7.4 Promote coordination
7.7.4.1 Ensure that different organizations with different priorities communicate and that any conflicts and disputes that may arise are resolved in an appropriate and productive manner.
7.7.4.2 Promote coordination of security engineering.
7.7.5 Coordinate security decisions and recommendations7 Monitor risks and their characteristics
7.3.7.1 Check new risks regularly. This clause is closely related to the general monitoring activities in 7.8.3 "Monitor changes in threats, vulnerabilities, impacts, risks and environment".
7. 3.7.2 Monitor changes in risk frequency and changes in risk characteristics. 7.4 Evaluate threats
7.4.1 Overview
GA/T 483—2004
Security threats and their nature and characteristics should be identified, and threats to system security should be identified and characterized; threats should be monitored regularly to ensure that the security understanding generated by this requirement is always maintained. 7.4.2 Identify natural threats
Identify corresponding threats caused by natural causes. 7.4.3 Identify man-made threats
Identify threats caused by accidental man-made causes and threats caused by intentional actions. 7.4.4 Identify threat measurement scales
7.4.4.1 For expected events that may occur in a specific location, establish the maximum and minimum measurement unit ranges based on the actual situation. 7.4.4.2 Identify the appropriate measurement scale and scope of application in a specific environment. 7.4.5 Evaluate the effects of threat impacts
7.4.5.1 Determine the potential capabilities of hackers to successfully attack the system. 7.4.5.2 Evaluate the causes and consequences of threat impacts caused by human factors. 7.4.6 Evaluate the likelihood of threats
Evaluate the likelihood of how threat events occur and the likelihood of threat events occurring. 7.4.7 Monitor threats and their characteristics
7.4.7.1 Regularly monitor existing threats and their characteristics and check for new threats; this clause is closely related to the general monitoring activities of 7.8.3.
7.4.7.2 Monitor the constant changes in the threat spectrum and the changes in corresponding characteristics. 7.5 Evaluate Vulnerabilities
7.5.1 General
System security vulnerabilities shall be identified and characterized. This requirement includes analyzing system assets, defining specific vulnerabilities, and providing an assessment of overall system vulnerabilities, and obtaining an understanding of system security vulnerabilities in a defined environment. 7.5.2 Select Vulnerability Analysis Methods
7.5.2.1 All analyses shall be conducted within a known and documented configuration framework within a pre-arranged and specified timeframe; the analysis methodology shall include expected results; and the specific objectives of the analysis shall be clearly stated. 7.5.2.2 Select methods, techniques, and standards for identifying and characterizing system security vulnerabilities in a defined environment. 7.5.3 Identify Vulnerabilities
The vulnerability analysis methodology studied in 7.5.2 shall be extended to the verification of vulnerabilities; all discovered system security vulnerabilities shall be documented and identified.
7.5.4 Collect Vulnerability Data
Collect data related to vulnerabilities.
7.5.5 Comprehensive system vulnerability
Analyze which vulnerabilities or combinations of vulnerabilities will cause problems to the system. All analyses should identify the characteristics of the vulnerability; evaluate the system vulnerability and overall vulnerability caused by specific vulnerabilities and specific vulnerability combinations. 7.5.6 Monitor vulnerabilities and their characteristics
7.5.6.1 This requirement is closely related to the general monitoring activities of changes in 7.8.3. 7.5.6.2 Monitor the continuous changes of vulnerabilities and their characteristics. 7.6 Establish assurance evidence
7.6.1 Overview
This project includes the identification and definition of assurance related to requirements, including the generation and analysis of evidence, including additional evidence required to support assurance requirements, document lists and processes, and those that can clearly provide users with evidence that their security requirements have been met. This project requires the establishment of records of activities related to assurance evidence, including management, identification, planning, packaging and submission of security assurance evidence. GA/T 483—2004
7.6.2 Identify assurance objectives
7.6.2.1 Identify security assurance objectives.
7.6.2.2 The system security assurance objectives shall specify the confidentiality level of the mandatory system security policy: the adequacy of the objectives shall be determined by the developers, integrators, users and signature authorizers.
7.6.2.3 The identification of new and modified security assurance objectives shall be coordinated with all security-related groups such as internal and external engineering organizations.
7.6.2.4 The changes to the security assurance objectives shall be explained in a timely manner. 7.6.2.5 The security assurance objectives shall be clearly communicated. 7.6.3 Define assurance strategies
7.6.3.1 Plan and ensure that the mandatory security objectives are correctly achieved; the evidence generated by the implementation of the security assurance strategy shall provide (to the system signature authorizer) an acceptable confidentiality level, and this level of security measurement is sufficient to manage security risks. By developing and issuing a security assurance strategy, effective management of assurance-related activities is achieved; the identification and definition of assurance related to requirements in the early stage of the project generates necessary supporting evidence; through continuous external coordination, the satisfaction of user requirements is understood and monitored to ensure high-quality combined assurance requirements.
7.6.3.2 Define a security assurance strategy for all assurance objectives. 7.6.4 Control assurance evidence
Security assurance evidence is collected by coordinating with all engineering implementation requirements and using evidence from different levels of abstraction identified in the security assurance strategy; evidence should be controlled. 7.6.5 Analyze evidence
Analyze security assurance evidence to ensure that the engineering product is complete and correct relative to the baseline system. 7.6.6 Provide assurance arguments
7.6.6.1 Develop a complete security assurance argument that proves consistency with the security objectives and provide it to the user; the
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.