14 System acquisition, development and maintenance
14.2 Security in development and support processes
Objective: To ensure that information security is designed and implemented within the development lifecycle of information systems.
14.2.1 Secure development policy
3361
Control 3362
Rules for the development of software and systems should be established and applied to 3363
developments within the organization. 3364
Implementation guidance 3365
Secure development is a requirement to build up a secure service, architecture, software and system. 3366
Within a secure development policy, the following aspects should be put under consideration: 3367
a) security of the development environment; 3368
b) guidance on the security in the software development lifecycle: 3369
1) security in the software development methodology; 3370
2) secure coding guidelines for each programming language used; 3371
c) security requirements in the design phase; 3372
d) security checkpoints within the project milestones; 3373
e) secure repositories; 3374
f) security in the version control; 3375
g) required application security knowledge; 3376
h) developers' capability of avoiding, finding and fixing vulnerabilities. 3377
Secure programming techniques should be used both for new developments and in code re- 3378
use scenarios where the standards applied to development may not be known or were not consistent 3379
with current best practices. Secure coding standards should be considered and where relevant 3380
mandated for use. Developers should be trained in their use and testing and code review should verify 3381
their use. 3382
If development is outsourced, the organization should obtain assurance that the external party 3383
complies with these rules for secure development (see 14.2.7). 3384
Other information 3385
Development may also take place inside applications, such as office applications, scripting, browsers 3386
and databases. 3387
14.2.2 System change control procedures
3388
Control 3389
Changes to systems within the development lifecycle shall be controlled by the use of formal 3390
change control procedures. A change management system for the IACS environment shall be 3391
developed and implemented. The change management process shall follow separation of duty 3392
principles to avoid conflicts of interest. 3393
Implementation guidance 3394
Formal change control procedures should be documented and enforced to ensure the integrity of 3395
system, applications and products, from the early design stages through all subsequent maintenance 3396
efforts. Introduction of new systems and major changes to existing systems should follow a formal 3397
process of documentation, specification, testing, quality control and managed implementation. 3398 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.
This process should include a risk assessment, analysis of the impacts of changes and specification 3399
of security controls needed. This process should also ensure that existing security and control 3400
procedures are not compromised, that support programmers are given access only to those parts of 3401
the system necessary for their work and that formal agreement and approval for any change is 3402
obtained. 3403
Wherever practicable, application and operational change control procedures should be integrated 3404
(see 12.1.2). The change control procedures should include but not be limited to: 3405
a) maintaining a record of agreed authorization levels; 3406
b) ensuring changes are submitted by authorized users; 3407
c) reviewing controls and integrity procedures to ensure that they will not be compromised by the 3408
changes; 3409
d) identifying all software, information, database entities and hardware that require amendment; 3410
e) identifying and checking security critical code to minimize the likelihood of known security 3411
weaknesses; 3412
f) obtaining formal approval for detailed proposals before work commences; 3413
g) ensuring authorized users accept changes prior to implementation; 3414
h) ensuring that the system documentation set is updated on the completion of each change and 3415
that old documentation is archived or disposed of; 3416
i) maintaining a version control for all software updates; 3417
j) maintaining an audit trail of all change requests; 3418
k) ensuring that operating documentation (see 12.1.1) and user procedures are changed as 3419
necessary to remain appropriate; 3420
l) ensuring that the implementation of changes takes place at the right time and does not 3421
disturb the business processes involved. 3422
m) ensuring that HSE and cyber security risks are assessed by indivudals technically 3423
knowledgeable about the industrial operations and the IACS; 3424
n) ensuring that the security requirements of a new system meet the security policies and 3425
procedures required for the existing zones, conduits and environment; and 3426
o) ensuring that maintenance ‘upgrades or changes meet the security requriements for the 3427
zones, conduits and environment. 3428
Other information 3429
Changing software can impact the operational environment and vice versa. 3430
Good practice includes the testing of new software in an environment segregated from both the 3431
production and development environments (see 12.1.4). This provides a means of having control over 3432
new software and allowing additional protection of operational information that is used for testing 3433
purposes. This should include patches, service packs and other updates. 3434
Where automatic updates are considered, the risk to the integrity and availability of the system should 3435
be weighed against the benefit of speedy deployment of updates. Automated updates should not 3436
be used on critical systems as some updates can cause critical applications to fail. 3437
14.2.3 Technical review of applications after operating platform changes
3438
Control 3439
When operating platforms are changed (including upgrades, updates and patches) business critical 3440
applications should be reviewed and tested to ensure there are no adverse impacts on organizational 3441 operations or security. 3442 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.
Implementation guidance 3443
This process should cover: 3444
a) review of application control and integrity procedures to ensure that they have not been 3445
compromised by the operating platform changes; 3446
b) ensuring that notification of operating platform changes is provided in time to allow appropriate 3447
tests and reviews to take place before implementation; 3448
c) ensuring that appropriate changes are made to the business continuity plans (see 17). 3449
Other information 3450
Operating platforms include operating systems, databases and middleware platforms. The control 3451
should also be applied for changes of applications. 3452
14.2.4 Restrictions on changes to software packages
3453
Control 3454
Modifications to software packages should be discouraged, limited to necessary changes and all 3455
changes should be strictly controlled. 3456
Implementation guidance 3457
As far as possible and practicable, vendor-supplied software packages should be used without 3458
modification. Where a software package needs to be modified the following points should be 3459
considered: 3460
a) the risk of built-in controls and integrity processes being compromised; 3461
b) whether the consent of the vendor should be obtained; 3462
c) the possibility of obtaining the required changes from the vendor as standard program updates; 3463
d) the impact if the organization becomes responsible for the future maintenance of the software 3464
as a result of changes; 3465
e) compatibility with other software in use. 3466
If changes are necessary the original software should be retained and the changes applied to a designated copy. 3467
A software update management process should be implemented to ensure the most up-to-date approved patches 3468
and application updates are installed for all authorized software (see 12.6.1). All changes should be fully 3469
tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the 3470
modifications should be tested and validated by an independent evaluation body. 3471
14.2.5 Secure system engineering principles
3472
Control 3473
Principles for engineering secure systems should be established, documented, maintained and applied 3474
to any information system implementation efforts. 3475
Implementation guidance 3476
Secure information system engineering procedures based on security engineering principles should 3477
be established, documented and applied to in-house information system engineering activities. 3478
Security should be designed into all architecture layers (business, data, applications and technology) 3479
balancing the need for information security with the need for accessibility. New technology should be 3480
analyzed for security risks and the design should be reviewed against known attack patterns. 3481
These principles and the established engineering procedures should be regularly reviewed to ensure 3482
that they are effectively contributing to enhanced standards of security within the engineering process. 3483
They should also be regularly reviewed to ensure that they remain up-to-date in terms of combating 3484 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.
any new potential threats and in remaining applicable to advances in the technologies and solutions 3485
being applied. 3486
The established security engineering principles should be applied, where applicable, to outsourced 3487
information systems through the contracts and other binding agreements between the organization and 3488
the supplier to whom the organization outsources. The organization should confirm that the rigor of 3489
suppliers' security engineering principles is comparable with its own. 3490
Other information 3491
Application development procedures should apply secure engineering techniques in the development 3492
of applications that have input and output interfaces. Secure engineering techniques provide guidance 3493
on user authentication techniques, secure session control and data validation, sanitization and 3494
elimination of debugging codes. 3495
14.2.6 Secure development environment
3496
Control 3497
Organizations should establish and appropriately protect secure development environments for system 3498
development and integration efforts that cover the entire system development lifecycle. 3499
Implementation guidance 3500
A secure development environment includes people, processes and technology associated with 3501
system development and integration. 3502
Organizations should assess risks associated with individual system development efforts and establish 3503
secure development environments for specific system development efforts, considering: 3504
a) sensitivity of data to be processed, stored and transmitted by the system; 3505
b) applicable external and internal requirements, e.g. from regulations or policies; 3506
c) security controls already implemented by the organization that support system development; 3507
d) trustworthiness of personnel working in the environment (see 7.1.1); 3508
e) the degree of outsourcing associated with system development; 3509
f) the need for segregation between different development environments; 3510
g) control of access to the development environment; 3511
h) monitoring of change to the environment and code stored therein; 3512
i) backups are stored at secure offsite locations; 3513
j) control over movement of data from and to the environment. 3514
Once the level of protection is determined for a specific development environment, organizations 3515
should document corresponding processes in secure development procedures and provide these to 3516
all individuals who need them. 3517
14.2.7 Outsourced development
3518
Control 3519
The organization should supervise and monitor the activity of outsourced system development. 3520
Implementation guidance 3521
Where system development is outsourced, the following points should be considered across the 3522
organization’s entire external supply chain: 3523
a) licensing arrangements, code ownership and intellectual property rights related to the 3524
outsourced content (see 18.1.2); 3525 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.
b) contractual requirements for secure design, coding and testing practices (see 14.2.1); 3526
c) provision of the approved threat model to the external developer; 3527
d) acceptance testing for the quality and accuracy of the deliverables; 3528
e) provision of evidence that security thresholds were used to establish minimum acceptable 3529
levels of security and privacy quality; 3530
f) provision of evidence that sufficient testing has been applied to guard against the absence 3531
of both intentional and unintentional malicious content upon delivery; 3532
g) provision of evidence that sufficient testing has been applied to guard against the presence 3533
of known vulnerabilities; 3534
h) escrow arrangements, e.g. if source code is no longer available; 3535
i) contractual right to audit development processes and controls; 3536
j) effective documentation of the build environment used to create deliverables; 3537
k) the organization remains responsible for compliance with applicable laws and control 3538
efficiency verification. 3539
Other information 3540
Further information on supplier relationships can be found in ISO/IEC 27036. 3541
14.2.8 System security testing
3542
Control 3543
Testing of security functionality should be carried out during development. 3544
Implementation guidance 3545
New and updated systems require thorough testing and verification during the development processes, 3546
including the preparation of a detailed schedule of activities and test inputs and expected outputs 3547
under a range of conditions. As for in-house developments, such tests should initially be performed 3548
by the development team. Independent acceptance testing should then be undertaken (both for in- 3549
house and for outsourced developments) to ensure that the system works as expected and only as 3550
expected (see 14.1.1 and 14.1.2). The extent of testing should be in proportion to the importance and 3551
nature of the system. 3552
14.2.9 System acceptance testing
3553
Control 3554
Acceptance testing programs and related criteria should be established for new information systems, 3555
upgrades and new versions. 3556
Implementation guidance 3557
System acceptance testing should include testing of information security requirements (see 14.1.1 and 3558
14.1.2) and adherence to secure system development practices (see 14.2.1). The testing should also 3559
be conducted on received components and integrated systems. Organizations can leverage automated 3560
tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of 3561
security-related defects. 3562
Testing should be performed in a realistic test environment to ensure that the system will not introduce 3563
vulnerabilities to the organization’s environment and that the tests are reliable. 3564
14.3 Test data 3565
Objective: To ensure the protection of data used for testing.
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.
14.3.1 Protection of test data 3566
Control 3567
Test data should be selected carefully, protected and controlled. 3568
Implementation guidance 3569
The use of operational data containing personally identifiable information or any other confidential 3570
information for testing purposes should be avoided. If personally identifiable information or otherwise 3571
confidential information is used for testing purposes, all sensitive details and content should be 3572
protected by removal or modification (see ISO/IEC 29101). 3573
The following guidelines should be applied to protect operational data, when used for testing 3574
purposes: 3575
a) the access control procedures, which apply to operational application systems, should also 3576
apply to test application systems; 3577
b) there should be separate authorization each time operational information is copied to a test 3578
environment; 3579
c) operational information should be erased from a test environment immediately after the testing 3580
is complete; 3581
d) the copying and use of operational information should be logged to provide an audit trail. 3582
Other information 3583
System and acceptance testing usually requires substantial volumes of test data that are as close 3584
as possible to operational data. 3585
15 Supplier relationships