GA/T 1562-2019Information security technology - Security technical requirements for boundary security special gateway products of industrial control system (English PDF)

5.1 Classification of safety technical requirements

This standard divides the security technical requirements of the dedicated security gateway products for industrial control systems into three major functions. security functions, performance, and security assurance.

class. Among them, the security function requirements are specific requirements for the security functions that industrial control system border security dedicated gateway products should have. For example, such as. white list-based policy-based access control, function protection, attack response processing, time proofreading, business auditing, and industrial control protocols Support, suitable for multiple field environments, time synchronization, dual-system hot backup, support for IPv6/IPv4, protocol customization, management control function, physical Authentication, administrator management, security audit, event data security, communication security, self-monitoring, etc .; performance is the boundary of industrial control systems the performance of the security dedicated gateway product puts forward specific requirements, such as throughput, delay, reliability of data transmission, number of nodes that can be protected, etc .; security the assurance requirements put forward specific requirements for the content of the development and use documents of the dedicated security gateway products for industrial control systems, such as the development of Development, instructional documentation, lifecycle support and testing.

5.2 Classification of security levels

The security level of the industrial control system border security dedicated gateway product is based on its security function requirements, performance requirements, and security assurance requirements.

The strength is divided into basic level and enhanced level, in which security requirements refer to GB/T 18336.3-2015.

6.1 Whitelist-based access control

Products should support access control based on whitelist policies, including network layer and application layer.

6.2 Control function protection

The product shall provide protection for the protected industrial control system and equipment with control functions, block abnormal operations, and ensure the stability of normal operations.

run.

6.3 Attack response processing

When the product may be attacked, it can automatically record the IP address of the attacker and the time of the attack. Product safety features should.

a) Generate real-time alarm information;

b) Block the re-access of the IP address that initiated the attack.

6.4 Time proofreading

Products should provide a reliable time proofing mechanism for their own applications.

6.5 Business Audit

The product should have the function of auditing business events. The auditing content includes protocol inspection, filtering, exchange, blocking, etc., including normal Operation and abnormal operation. Each audit log should include at least the date, time, source IP, destination IP, protocol, and event description of the event.

Remarks and results.

6.6 Industrial Control Protocol Support

The product shall have the functions of inspection, filtering, exchange, blocking, etc. of the proprietary protocols of industrial control and data in various states or instructions in mainstream formats, the number of supported agreements is as follows.

a) Basic level supports at least 2 industrial control protocols;

b) The enhanced level supports at least 5 industrial control protocols.

6.7 Suitable for a variety of field environments

The product should be suitable for field environments such as distributed control systems (DCS), data acquisition and monitoring control systems (SCADA) or field buses.

6.8 Time synchronization

The product should provide its own application with a reliable time synchronization mechanism with the time server.

6.9 Hot Standby

The product should have the dual-system hot backup function. The specific technical requirements are as follows.

a) Support physical device status detection. When the main gateway itself loses power or other failures, the standby gateway detects and takes over the main network in time.

Related work

b) With dual-system hot backup function based on link status detection. When the link directly connected to the master gateway fails and does not work properly at this time, the standby gateway discovers and takes over the work of the main gateway in time.

6.10 Support IPv4/IPv6

6.10.1 Support product self-management in IPv4/IPv6 network environment

Communication between product components (if there are multiple components, including remote management terminals) should support IPv6 and transition environments.

6.10.2 Support the protection of industrial control systems in IPv4/IPv6 network environment

When the product protects the industrial control system, it should support IPv6 and the transition environment.

6.11 Protocol customization

In addition to supporting the default set of industrial control protocols, the product should also allow authorized administrators to define new protocols or re-determine the protocol ports Righteousness.

6.12 Management control functions

6.12.1 Distributed deployment

Products should have the ability to be deployed locally or remotely and managed remotely.

6.12.2 Central Management

A centralized management center should be set up to centrally and centrally manage distributed and multi-level deployed products to form a multi-level management structure.

6.12.3 Port separation

Products should be equipped with different ports for product management and service.

6.12.4 Multi-level management

Products should have multi-level management capabilities.

6.13 Identity

6.13.1 Administrator authentication

The product should authenticate the administrator before the administrator performs any security-related operations.

6.13.2 Authentication Failure Handling

When the administrator authentication attempts fail for the specified number of consecutive times, the product should lock the account or login IP. The maximum number of failures is only granted by Rights administrator settings.

6.13.3 Authentication data protection

The product shall protect authentication data from unauthorized access and modification.

6.13.4 Timeout setting

The product should have administrator login timeout reauthentication capabilities. Terminate the session without any action for a set period of time, Re-identification is required to re-manage the product. The maximum timeout period is set only by an authorized administrator.

6.13.5 Multiple authentication mechanism

The product should provide multiple authentication methods or allow authorized administrators to implement custom authentication measures to achieve multiple identity authentication measures.

Multiple authentication mechanisms should be used simultaneously.

6.13.6 Session Lock

The product should allow administrators to lock their own interactive sessions. Once locked, they need to be authenticated again to be able to re-manage the product.

6.14 Administrator Management

6.14.1 Uniqueness of identification

The product should ensure that the administrator ID set is globally unique.

6.14.2 User attribute definition

The product shall maintain a security attribute table for each administrator. Attributes include but are not limited to. administrator identification, authentication data, authorization information, or Management group information.

6.14.3 Security Behavior Management

It shall be limited to the designated authorization role to have the ability to prohibit and modify the functions of the product.

6.14.4 Administrator Role

The product should have multiple roles, and different management roles have different management rights.

6.14.5 Security attribute management

The product should be limited to the specified authorization role to query, modify, delete, and change the default values of the specified security attributes.

6.15 Security Audit

6.15.1 Audit data generation

The product shall be able to generate audit records for the following auditable events. the start and shutdown of audit functions, all auditable events within the audit level Events (such as major events such as failure to identify).

The product shall record at least the following information in each audit record. the date and time of the event, the type of event, the identity of the subject, and the conclusion of the event Results (success or failure), etc.

6.15.2 Ease of use of audit data

Audit data should be recorded in a way that is easy for administrators to understand.

6.15.3 Audit review

The product shall provide authorized administrators with the ability to read all audit information from the audit records.

6.15.4 Restricted audit access

Except for authorized administrators with clear read access, the product should prohibit all unauthorized administrators from reading the audit records ask.

6.15.5 Optional audit review

The product shall support retrieval or sorting of audit logs according to certain conditions.

6.16 Event Data Security

6.16.1 Safety data management

The product should restrict access to the event data to the specified authorized role, and prohibit other administrators from operating on the event data.

6.16.2 Data protection

In the event of an attack, the product should be able to retain the event data that has been saved intact.

6.16.3 Data storage security

In the event that event data storage space will be exhausted, the product shall take measures to prevent the latest event data from being lost.

6.16.4 Data storage alarm

When the event data storage space is used up, the product should automatically generate an alarm and take measures to avoid event data loss.

The size of the remaining storage space that generates the alarm should be set by the authorized administrator.

6.17 Communication Security

6.17.1 Communication integrity

The product should ensure that data (such as configuration and control information, alarms, and event data) transmitted between components cannot be tampered with.

6.17.2 Communication stability

Products should adopt methods such as point-to-point protocols to ensure communication stability, and ensure that the information transmitted between each component and the console is not caused by the network Lost or delayed.

6.17.3 Upgrade Security

The product should ensure communication security during event library and version upgrade, and ensure that the upgrade package is provided by the developer.

6.18 Self-monitoring

When the product starts up and works normally, it should perform self-test periodically or according to the requirements of authorized administrators to verify the product's own performance.

The correctness of the line.

7.1 Throughput

With application-level protection enabled, the throughput of the product should reach line speed levels.

7.2 Delay

The maximum delay of the product should not exceed 100ms.

7.3 Data transmission reliability

The data transmission reliability of the product should reach 100%, and the specific indicators include.

a) the bit error rate of 500 million bits of data is 0;

b) The packet loss rate for 12-hour data transmission is 0.

7.4 Number of nodes that can be protected

The number of nodes that the product can protect should not be less than 500 points.

8.1 Development

8.1.1 Security Architecture

The developer should provide a description of the security architecture of the product's security functions. The description of the security architecture should meet the following requirements.

a) Consistent with the level of abstract description of security functions implemented in the product design document;

b) describe the security domain of the product security function consistent with the requirements of the security function;

c) describe why the product safety function initialization process is safe;

d) confirm that product safety functions can be prevented from being compromised;

e) Verify that product safety functions prevent safety features from being bypassed.

8.1.2 Functional Specifications

Developers should provide complete functional specifications, which should meet the following requirements.

a) fully describe the safety functions of the product;

b) describe the purpose and use of all safety function interfaces;

c) identify and describe all parameters related to each safety function interface;

d) describe the safety function implementation behavior related to the safety function interface;

e) describe direct error messages caused by the behavioral processing of safety functions;

f) confirm that the safety function requires traceability to the safety function interface;

g) describe all actions related to the safety function interface during the implementation of the safety function;

h) Describe all direct error messages that may be caused by the call of the safety function interface.

8.1.3 Implementation Representation

Developers should provide implementation representations for all security functions. Implementation representations should meet the following requirements.

a) Provide a mapping between product design descriptions and implementation representation examples and prove their consistency;

b) Define product safety functions according to the level of detail, to a level of detail that can be generated without further design;

c) Provided in the form used by developers.

8.1.4 Product Design

Developers should provide product design documents, which should meet the following requirements.

a) describe the product structure in terms of subsystems;

b) identify and describe all subsystems of product safety functions;

c) describe the interaction between all subsystems of the safety function;

d) the mapping relationship provided can verify that all the behaviors described in the design can be mapped to call his security function interface;

e) describe safety functions according to the module;

f) Provide the mapping relationship between the safety function subsystem and the module;

g) describe all safety function implementation modules, including their purpose and interaction with other modules;

h) Describe the relevant interfaces required by all modules to implement the security functions, return values from other interfaces, interactions with other modules, and Called interface

i) Describe the supporting or related modules of all safety functions, including their purpose and interaction with other modules.

8.2 Guidance documents

8.2.1 Operation User Guide

Developers should provide clear and reasonable operating user guides, which are kept in line with all other documents provided for evaluation Sincerely, the description of each user role should meet the following requirements.

a) describe the functions and privileges accessible to users controlled in a secure processing environment, including appropriate alert information;

b) describe how to use the available interfaces provided by the product in a secure manner;

c) describe available functions and interfaces, especially all safety parameters controlled by the user, and indicate safety values where appropriate;

d) clearly state each security-related event related to the user-accessible function that needs to be performed, including changes to the control of the security function Security features of the entity;

e) identify all possible states of operation of the product (including failures or operational errors caused by operations), and their relevance to maintaining safety Causality and connection between operations;

f) the security policies necessary to fully implement the security objectives.

8.2.2 Preparation procedures

The developer shall provide the product and its preparation procedures. The preparation procedure description shall meet the following requirements.

a) describe all steps necessary to securely receive the delivered product in accordance with the developer delivery process;

b) Describe all steps necessary to safely install the product and its operating environment.

8.3 Life cycle support

8.3.1 Configuration Management Capability

Developer configuration management capabilities should meet the following requirements.

a) provide unique identification for different versions of the product;

b) use a configuration management system to maintain all configuration items that make up the product and uniquely identify configuration items;

c) Provide configuration management documents, which describe the method used to uniquely identify configuration items;

d) The configuration management system provides an automatic way to support the generation of products, by which it is ensured that only the implementation of the products can be expressed Authorized changes;

e) The configuration management document includes a configuration management plan, which describes how to develop products using a configuration management system. real the implementation of the configuration management is consistent with the configuration management plan;

f) The configuration management plan describes the procedures used to accept modified or newly created configuration items as part of the product.

8.3.2 Configuration Management Scope

The developer should provide a list of product configuration items and describe the developer of the configuration item. The configuration item list should include the following.

a) Evaluation evidence of products, safety assurance requirements and components of products;

b) Implementation indication, security defect report and resolution status.

8.3.3 Delivery procedures

Developers should use a certain delivery procedure to deliver the product and document the delivery process. When delivering versions of the product to the user, the delivery documentation should describe all procedures necessary to maintain security.

8.3.4 Development Security

Developers should provide development security documentation. The development security documentation should describe the design and implementation all physical, procedural, personal and other security measures necessary for confidentiality and integrity.

8.3.5 Life Cycle Definition

The developer should establish a life cycle model to control the development and maintenance of the product, and provide a description of the life cycle definition document.

Describe the models used to develop and maintain products.

8.3.6 Tools and techniques

Developers should clearly define the tools used to develop the product, and provide development tool documentation to unambiguously define the meaning of each statement in the implementation and the meaning of all implementation-dependent options.

8.4 Test

8.4.1 Test coverage

The developer should provide a test coverage document, and the test coverage description should meet the following requirements.

a) indicate the correspondence between the tests identified in the test documentation and the safety functions of the product described in the functional specification;

b) Show that the above correspondence is complete and confirm that all safety function interfaces in the functional specification have been tested.

8.4.2 Test depth

Developers should provide test depth analysis. The test in-depth analysis description should meet the following requirements.

a) confirm the consistency between the tests in the test documentation and the safety function subsystem and implementation modules in the product design;

b) Verify that all safety function subsystems and implementation modules in the product design have been tested.

8.4.3 Functional test

Developers should test product security features, document results and provide test documentation. The test documentation should include the following.

a) A test plan that identifies the tests to be performed and describes the scenarios for each test, including those for other test results any order dependency;

b) the expected test results, indicating the expected output after a successful test;

c) Consistency between actual test results and expected test results.

8.4.4 Independent testing

Developers should provide a set of resources equivalent to those used for self-testing security features for sample testing of security features.

8.5 Vulnerability assessment

Based on the identified potential vulnerabilities, the product is resistant to the following attacks.

a) attacks by attackers with basic attack potential;

b) Attacks by attackers with enhanced basic attack potential.

9.1 Safety function requirements

The security function requirements of the de...