12 Operations security
12.1 Operational procedures and responsibilities
Objective: To ensure correct and secure operations of information processing facilities.
12.1.1 Documented operating procedures
2431
Control 2432
Operating procedures shall be documented and made available to all users who need them. 2433
Implementation guidance 2434
Documented procedures should be prepared for operational activities associated with information 2435
processing and communication facilities, such as computer start-up and close-down procedures, 2436
backup, equipment maintenance, media handling, computer room, control roomand network 2437
management, system updates, system migration, mail handling management and safety. 2438
The operating procedures should specify the operational instructions, including: 2439
a) the installation and configuration of systems; 2440
b) processing and handling of information both automated and manual; 2441
c) backup (see 12.3); 2442
d) scheduling requirements, including interdependencies with other systems, earliest job start and 2443
latest job completion times; 2444
e) instructions for handling errors or other exceptional conditions, which might arise during job 2445
execution, including restrictions on the use of system utilities (see 9.4.4); 2446
f) support and escalation contacts including external support contacts in the event of unexpected 2447
operational or technical difficulties; 2448
g) special output and media handling instructions, such as the use of special stationery or the 2449
management of confidential output including procedures for secure disposal of output from 2450
failed jobs (see 8.3 and 11.2.7); 2451 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
h) system restart and recovery procedures for use in the event of system failure; 2452
i) the management of audit-trail and system log information (see 12.4); 2453
j) monitoring procedures (see 12.4). 2454
k) under which conditions the incident, emergency or crisis handling procedures are to be invoked 2455
(see section 16.1.2) 2456
Operating procedures and the documented procedures for system activities should be treated as 2457
formal documents and changes authorized by management. Where technically feasible, information 2458
systems should be managed consistently, using the same procedures, tools and utilities. 2459
disabled or the proposed control structure should be reviewed to determine if advantage can be 2460
taken of the enhanced functionality available. 2461
12.1.2 Change management
2462
Control 2463
Changes to the organization, business processes, information processing facilities and systems that 2464
affect information security shall be controlled. A change management system for the IACS 2465
environment shall be developed and implemented. The change management process shall follow 2466
separation of duty principles to avoid conflict of interest. 2467
The adequacy and effectiveness of the change management policies and procedures shall be 2468
reviewed at planned intervals to ensure their continuing suitability for managing changes to IACS 2469
systems. The change management procedures shall include provisions to conduct safety and 2470
security reviews when significant changes are proposed or made to the IACS to ensure that the 2471
changes do not increase risks to HSE or business continuity. 2472
The organization shall develop, disseminate, and periodically review/update: (i) a formal, 2473
documented, configuration management policy that addresses purpose, scope, roles, 2474
responsibilities, management commitment, coordination among organizational entities, and 2475
compliance; and (ii) formal, documented procedures to facilitate the implementation of the 2476
configuration management policy and associated configuration management controls. 2477
The organization shall develop, document, and maintain a current baseline configuration of the 2478
IACS. 2479
(1) The organization updates the baseline configuration of the IACS as an integral part of IACS 2480
component installations. 2481
(2) The organization employs automated mechanisms to maintain an up-to-date, complete, 2482
accurate, and readily available baseline configuration of the IACS. 2483
The organization employs automated mechanisms to: (i) document proposed changes to the IACS; 2484
(ii) notify appropriate approval authorities; (iii) highlight approvals that have not been received in 2485
a timely manner; (iv) inhibit change until necessary approvals are received; and (v) document 2486
completed changes to the IACS. 2487
The organization tests, validates, and documents changes (e.g., patches and updates) before 2488
implementing the changes on the operational IACS. 2489
The organization shall conduct security impact analyses to determine the effects of configuration 2490
changes. 2491
The IACS vendor shall provide guidelines for recommended network and security configurations. 2492
The organization shall, based upon guidelines provided by the vendor: (i) establish mandatory 2493
network and security configuration settings for IACS components (ii) configure these settings to 2494 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
the most restrictive mode consistent with operational requirements; (iii) document these settings; 2495
and (iv) enforce these settings in all components of the IACS. 2496
(1) The organization shall employ automated mechanisms to centrally manage, apply, and 2497
verify configuration settings. 2498
Implementation guidance 2499
In particular, the following items should be considered: 2500
a) identification and recording of significant changes; 2501
b) planning and testing of changes; 2502
c) assessment of the potential impacts, including information security impacts, of such changes; 2503
d) formal approval procedure for proposed changes; 2504
e) verification that information security requirements have been met; 2505
f) communication of change details to all relevant persons; 2506
g) fallback procedures, including procedures and responsibilities for aborting and recovering from 2507
unsuccessful changes and unforeseen events; 2508
h) provision of an emergency change process to enable quick and controlled implementation 2509
of changes needed to resolve an incident (see 16.1). 2510
i) using clearly defined criteria, proposed changes to the IACS should be reviewed for their 2511
potential impact to HSE risks and cyber security risks by individuals technically 2512
knowledgeable about the industrial operation and the IACS system; 2513
j) the security requirements of a new system being installed in the IACS environment in an 2514
existing zone should meet the security policies and procedures required for that 2515
zone/environment; (See ISA-62443-1-1 for more information about zones and conduits.) 2516
k) maintenance upgrades or changes should meet the security requirements for the zone; 2517
l) cyber security change management procedures should be integrated with existing process 2518
safety management (PSM) procedures 2519
Formal management responsibilities and procedures should be in place to ensure satisfactory control 2520
of all changes. When changes are made, an audit log containing all relevant information should be 2521
retained. The risk of proposed changes to the IACS should be reviewed by individuals technically 2522
knowledgeable about the industrial operations and IACS. 2523
The configuration management policy and procedures are consistent with applicable laws, 2524
directives, policies, regulations, standards, and guidance. The configuration management policy 2525
can be included as part of the general information security policy for the organization. 2526
Configuration management procedures can be developed for the security program in general, and 2527
for a particular IACS, when required. 2528
This requirement establishes a baseline configuration for the IACS. The baseline configuration 2529
provides information about a particular component’s makeup (e.g., the standard software load for 2530
a workstation or notebook computer including updated patch information) and the component’s 2531
logical placement within the IACS architecture. The baseline configuration also provides the 2532
organization with a well-defined and documented specification to which the IACS is built and 2533
deviations, if required, are documented in support of mission needs/ objectives. 2534
The organization manages configuration changes to the IACS using an organizationally approved 2535
process. Configuration change control involves the systematic proposal, justification, 2536
implementation, test/evaluation, review, and disposition of changes to the IACS, including 2537
upgrades and modifications. Configuration change control includes changes to the configurati on 2538
settings for information technology products (e.g., operating systems, firewalls, routers). The 2539 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
organization includes emergency changes in the configuration change control process, including 2540
changes resulting from the remediation of flaws. The approvals to implement a change to the IACS 2541
include successful results from the security analysis of the change. The organization audits 2542
activities associated with configuration changes to the IACS. 2543
The organization ensures that testing does not interfere with IACS functions. The individual/group 2544
conducting the tests fully understands the organizational information security policies and 2545
procedures, the IACS security policies and procedures, and the specific health, safety, and 2546
environmental risks associated with a particular facility and/or process. A production IACS may 2547
need to be taken off-line, or replicated to the extent feasible, before testing can be conducted. If 2548
an IACS must be taken off-line for testing, the tests are scheduled to occur during planned IACS 2549
outages whenever possible. In situations where the organization cannot, for operational reasons, 2550
conduct live testing of a production IACS, the organization employs compensating controls (e.g., 2551
providing a replicated system to conduct testing). 2552
Prior to change implementation, and as part of the change approval process, the organization 2553
analyzes changes to the IACS for potential adverse security consequences. After the IACS is 2554
changed (including upgrades and modifications), the organization checks the security features to 2555
verify that the features are still functioning properly. The organization audits activities associated 2556
with configuration changes to the IACS. Monitoring configuration changes and conducting security 2557
impact analyses are important elements with regard to the ongoing assessment of security controls 2558
in the IACS. 2559
Other information 2560
Inadequate control of changes to information processing facilities and systems is a common cause of 2561
system or security failures. Changes to the operational environment, especially when transferring a 2562
system from development to operational stage, can impact on the reliability of applications 2563 (see14.2.2). 2564 12.1.3 Capacity management 2565 Control 2566
The use of resources shall be monitored, tuned and projections made of future capacity requirements 2567
to ensure the required system performance. 2568
Implementation guidance 2569
Capacity requirements should be identified, taking into account the business criticality of the 2570
concerned system. System tuning and monitoring should be applied to ensure and, where necessary, 2571
improve the availability and efficiency of systems. Detective controls should be put in place to 2572
indicate problems in due time. Projections of future capacity requirements should take account of new 2573
business and system requirements and current and projected trends in the organization's information 2574
processing capabilities. 2575
Particular attention needs to be paid to any resources with long procurement lead times or high costs; 2576
therefore managers should monitor the utilization of key system resources. They should identify 2577
trends in usage, particularly in relation to business applications or information systems management 2578
tools. 2579
Managers should use this information to identify and avoid potential bottlenecks and dependence on 2580
key personnel that might present a threat to system security or services, and plan appropriate action. 2581
Providing sufficient capacity can be achieved by increasing capacity or by reducing demand. 2582
Examples of managing capacity demand include: 2583
a) deletion of obsolete data (disk space); 2584
b) decommissioning of applications, systems, databases or environments; 2585 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
c) optimizing batch processes and schedules; 2586
d) optimizing application logic or database queries; 2587
e) denying or restricting bandwidth for resource-hungry services if these are not business critical 2588
(e.g. video streaming). 2589
A documented capacity management plan should be considered for mission critical systems. 2590
Other information 2591
This control also addresses the capacity of the human resources, as well as offices and facilities. 2592
12.1.4 Separation of development, testing and operational environments
2593
Control 2594
Development, testing, and operational environments shall be separated to reduce the risks of 2595
unauthorized access or changes to the operational environment 2596
.Implementation guidance 2597
The level of separation between operational, testing, and development environments that is necessary 2598
to prevent operational problems should be identified and implemented. 2599
The following items should be considered: 2600
a) rules for the transfer of software from development to operational status should be defined and 2601
documented; 2602
b) development and operational software should run on different systems or computer processors 2603
and in different domains or directories; 2604
c) changes to operational systems and applications should be tested in a testing or staging 2605
environment prior to being applied to operational systems; 2606
d) other than in exceptional circumstances, testing should not be done on operational systems; 2607
e) compilers, editors and other development tools or system utilities should not be accessible from 2608
operational systems when not required; 2609
f) users should use different user profiles for operational and testing systems, and menus should 2610
display appropriate identification messages to reduce the risk of error; 2611
g) sensitive data should not be copied into the testing system environment unless equivalent 2612
controls are provided for the testing system (see 14.3). 2613
Other information 2614
Development and testing activities can cause serious problems, e.g. unwanted modification of files or 2615
system environment or system failure. There is a need to maintain a known and stable environment in 2616
which to perform meaningful testing and to prevent inappropriate developer access to the operational 2617
environment. 2618
Where development and testing personnel have access to the operational system and its information, 2619
they may be able to introduce unauthorized and untested code or alter operational data. On some 2620
systems this capability could be misused to commit fraud or introduce untested or malicious code, 2621
which can cause serious operational problems. 2622
Developers and testers also pose a threat to the confidentiality of operational information. 2623
Development and testing activities may cause unintended changes to software or information if they 2624
share the same computing environment. Separating development, testing and operational 2625
environments is therefore desirable to reduce the risk of accidental change or unauthorized access to 2626
operational software and business data (see 14.3 for the protection of test data). 2627 This document is a WORKING DRAFT of an ISA99 committee work product. It may not be accurate of complete and is subject to change without notice. It is provided SOLELY for the purpose of review in support of further development of committee work products. This document may not be copied, distributed to others, or offered for further reproduction or for sale.
If the separation of development, test, and operational systems cannot be implemented, then, 2628
depending upon the criticality of the system in question, specially adapted change management, 2629
incident, emergency and crisis handling procedures should be established that will allow a rapid 2630
and appropriate reaction to interferences and problems in the operational system. 2631
Moreover it should be ensured that development and test systems are also secured using the 2632
state-of-the-art technology. According to their criticality it should be ensured that the test and 2633
development systems are sufficiently isolated from other system and networks (e.g. operation in a 2634
separate network environment, no direct Internet access, etc.) and that they are exclusively used 2635
for development and testing. 2636
12.2 Protection from malware