(5) Risk Treatment Ch7

7. Operations security

7.1 Operational procedures and responsibilities

Objective: To ensure correct and secure operations of information processing facilities.

7.1.1 Documented operating procedures

Operating procedures should be documented and made available to relevant users.

Prepare documented procedures for operational activities associated with information processing and communication facilities, such as computer start-up and close down procedures, backup, equipment maintenance, media handling, computer room and mail handling management and safety. This includes:
a) the installation and configuration of systems;
b) processing and handling of information both automated and manual as well as backup;
c) scheduling requirements, including interdependencies with other systems, earliest job start and latest job completion times;
d) instructions for handling errors or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities;
e) support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties;
f) special output and media handling instructions, such as the use of special stationery or the management of confidential output including procedures for secure disposal of output from failed jobs;
g) system restart and recovery procedures for use after a system failure;
h) the management of audit-trail and system log information and monitoring procedures.
Manage information systems consistently, where technically feasible, using the same procedures, tools and utilities.

In some cases, organizations bring together software development and operations to shorten development cycles. This allows organizations to be agile, and maintain the pace of innovation while taking advantage of cloud-native technology and practices. More about this approach is available from the NIST virtual workshop from January 2021 on improving the security of DevOps practices .

7.1.2 Change management

Changes to the organization, business processes, information processing facilities and systems that affect information security should be controlled.

Put in place formal approval procedure, management responsibilities and procedures to ensure satisfactory control of all changes. Consider the following:
a) identify and record significant changes;
b) assess potential impacts, including information security impacts, of such changes; c) communicate change details to all relevant persons;
d) plan and test changes and verify that information security requirements have been met;
e) abort and recover from unsuccessful changes and unforeseen events using fall-back procedures;
f) enable quick and controlled implementation of changes needed to resolve an incident via an emergency change process
g) retain an audit log containing all relevant information about changes.

Prevent system or security failures with an adequate control of changes to information processing facilities and systems.

7.1.3 Capacity management

The use of resources should be monitored, tuned and projections made of future capacity requirements to ensure the required system performance.

Identify system capacity requirements (considering also the capacity of the human resources, as well as offices and facilities), taking into account the business criticality of the concerned system.
a) consider a documented capacity management plan for mission critical systems.
Apply system tuning and monitoring to ensure and, where necessary, improve the availability and efficiency of systems.
a) put in place detective controls should to indicate problems in due time;
b) take account of new business and system requirements as well as current and projected trends in the organization’s information processing capabilities for projections of future capacity requirements;
c) providing sufficient capacity can be achieved by increasing capacity or by reducing demand. Examples of managing capacity demand include:
1. deletion of obsolete data (disk space);
2. decommissioning of apps, systems, databases or environments;
3. optimising batch processes and schedules;
4. optimising application logic or database queries;
5. denying or restricting bandwidth for resource-hungry services if these are not business critical (e.g. video streaming)
Ensure the management monitors the utilization of key system resources, and identifies trends in usage, particularly in relation to business applications or information systems management tools.
a) use this information to identify and avoid potential bottlenecks and dependence on key personnel that might present a threat to system security or services, and plan appropriate action;
b) pay attention to any resources with long procurement lead times or high costs

7.1.4 Separation of development, testing and operational environments

Development, testing, and operational environments should be separated to reduce the risks of unauthorized access or changes to the operational environment.

Identify and implement the level of separation between operational, testing, and development environments that is necessary to prevent operational problems.
a) define and document rules for the transfer of software from development to operational status;
b) run the development and operational software on different systems or computer processors and in different domains or directories;
c) do not make accessible compilers, editors and other development tools or system utilities from operational systems when not required;
d) use different user profiles for operational and testing systems.
Maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the operational environment.
a) test the changes to operational systems and applications in a testing or staging environment prior to being applied to operational systems. Do not do testing on operational systems;
b) do not copy sensitive data into the testing system environment unless equivalent controls are provided for the testing system.

Preventing any unwanted modification of files or system environment or system failure during development and testing requires to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access. With the access to the operational system and its information, developers and testers are able to introduce unauthorized and untested code or alter operational data. Especially if they share the same computing environment. Separating development, testing and operational environments is therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business.

On some systems this capability could be misused to commit fraud or introduce untested or malicious code, which causes serious operational problems.

7.2 Protection from malware

Objective: To ensure that information and information processing facilities are protected against malware.

7.2.1 Controls against malware

Detection, prevention and recovery controls to protect against malware should be implemented, combined with appropriate user awareness.

Base the protection against malware on malware detection and repair software, information security awareness and appropriate system access and change management controls. Establish a formal policy, which includes:
a) prohibiting the use of unauthorized software;
b) protection against risks associated with obtaining files and software either from or via external networks or on any other medium, indicating what protective measures should be taken;
c) implement procedures to regularly collect information, such as subscribing to mailing lists or verifying websites giving information about new malware. Esnure that this information is correct by verifying it.
Implement controls that prevent or detect the use of unauthorized software (e.g. application whitelisting).
Reduce vulnerabilities that could be exploited by malware, e.g. through technical vulnerability management.
Conduct regular reviews of the software and data content of systems supporting critical business processes. Formally investigate the presence of any unapproved files or unauthorized amendments.
Install and regularly update malware detection and repair software to scan computers and media as a precautionary control, or on a routine basis; the scan carried out should include:
a) scan any files received over networks or via any form of storage medium, for malware before use;
b) scan electronic mail attachments and downloads for malware before use; this scan should be carried out at different places, e.g. at electronic mail servers, desk top computers and when entering the network of the organization;
c) scan web pages for malware.
Define procedures and responsibilities to deal with malware protection on systems, training in their use, reporting and recovering from malware attacks.
Prepare appropriate business continuity plans for recovering from malware attacks, including all necessary data and software backup and recovery arrangements.
Isolate environments where catastrophic impacts may result.

Be aware that malaware can be introduced during maintenance and emergency procedures, which may bypass normal malware protection controls. Also, relying on malware detection and repair software alone as a malware control is not sufficient, and must be accompanied by operating procedures that prevent introduction of malware.

Malware protection can cause disturbance within operations.

The following NIST publications provide more detail:
- NIST SP 1800-25C
- NIST SP 1800-26B.
See also CIS Control 10 Malware Defenses.

7.3 Backup

Objective: To protect against loss of data.

7.3.1 Information backup

Backup copies of information, software and system images should be taken and tested regularly in accordance with an agreed backup policy.

Establish a backup policy to define the organization’s requirements for backup of information, software and systems.
a) design a backup plan detailing the accurate and complete records of the backup copies;
b) ensure the extent (e.g. full or differential backup) and frequency of backups are refleting the business requirements of the organization, the security requirements of the information involved and the criticality of the information to the continued operation of the organization;
c) produce documented restoration procedures and other operational procedures, e.g. on how to monitor the execution of backups and address failures of scheduled backups to ensure completeness of backups according to the backup policy;
d) determine the retention period for essential business information, taking into account any requirement for archive copies to be permanently retained.
Provide appropriate backup facilities to ensure that all essential information and software can be recovered following a disaster or media failure.
a) tore the backup in a remote location, at a sufficient distance to escape any damage from a disaster at the main site.
Ensure that the backup information recieves an appropriate level of physical and environmental protection consistent with the standards applied at the main site.
Regularly test the backup media to ensure that they can be relied upon for emergency use when necessary.
a) regularly test also the backup arrangements for individual systems and services to meet the requirements of business continuity plans. Cover all critical systems information, applications and data.
b) include into the test also the restoration procedures and check against the restoration time required.
c) carry out the testing the ability to restore backed-up data onto dedicated test media, not by overwriting the original media in case the backup or restoration process fails and causes irreparable data damage or loss.
In situations where confidentiality is of importance, encrypt the backups.

See also NIST SP 800-34 Rev.1 and CIS Control 11 Data Recovery.

7.4 Logging and monitoring

Objective: To record events and generate evidence.

7.4.1 Event logging

Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed.

Generate consolidated reports and alerts on system security through event logging, which sets the foundation for automated monitoring systems.
Where possible, do not grant system administrators the permission to erase or deactivate logs of their own activities.
Include in the event logs:
a) user IDs;
b) system activities;
c) dates, times and details of key events, e.g. log-on and log-off;
d) device identity or location if possible and system identifier;
e) records of successful and rejected system access attempts;
f) ecords of successful and rejected data and other resource access attempts;
g) hanges to system configuration;
h) use of privileges;
i) use of system utilities and applications;
j) files accessed and the kind of access;
k) network addresses and protocols;
l) alarms raised by the access control system;
m) activation and de-activation of protection systems, such as anti-virus systems and intrusion detection systems;
n) records of transactions executed by users in applications.

Protect the event logs with appropriate privacy protection measures, as they contain sensitive data and personally identifiable information.

See also the NIST Guide to Intrusion Detection and Prevention Systems (IDPS). CIS, furthermore, provides guidance in its controls:
- CIS Control 8 Audit Log Management
- CIS Control 13 Network Monitoring and Defense.

7.4.2 Protection of log information

Logging facilities and log information should be protected against tampering and unauthorized access. System administrator and system operator activities should be logged and the logs protected and regularly reviewed.

Aim the controls to protect against unauthorized changes to log information and operational problems with the logging facility including:
a) alterations to the message types that are recorded;
b) log files being edited or deleted;
c) storage capacity of the log file media being exceeded, resulting in either the failure to record events or over-writing of past recorded events
Archive selected audit log required for the record retention policy or because of requirements to collect and retain evidence.
Consider using suitable system utilities or audit tools to perform file interrogation.
Consdier real-time copying of logs to a system outside the control of a system administrator or operator to safeguard logs; e.g. an intrusion detection system to monitor system and network administration activities for compliance.
a) protect and review the logs to maintain accountability for the privileged users.

Real-time copying of logs to a system outside the control of a system administrator or operator is an ideal solution to safeguard logs. System logs need to be protected, because if the data is modified or data in them deleted, their existence may create a false sense of security. This way of protecting logs is also used to monitor system and network administration activities for compliance.

7.4.3 Clock synchronisation

The clocks of all relevant information processing systems within an organization or security domain should be synchronised to a single reference time source.

Document external and internal requirements for time representation, synchronisation and accuracy. Such requirements can be legal, regulatory, contractual, compliance or requirements for internal monitoring.
a) define a standard reference time for use within the organization;
b) document and implement an approach to obtaining a reference time from external source(s) and how to synchronise internal clocks reliably.
c) determine a master clock. A network time protocol can be used to keep all of the servers in synchronisation with the master clock. The correct setting of computer clocks is important to ensure the accuracy of audit logs, which may be required for investigations or as evidence in legal or disciplinary cases. Inaccurate audit logs may hinder such investigations and damage the credibility of such evidence.

7.5 Control of operational software

Objective: To record events and generate evidence.

7.5.1 Installation of software on operational systems

Procedures should be implemented to control the installation of software on operational systems.

Only trained administrators carry out the updating of the operational software, applications and program libraries upon appropriate management authorization.
Hold only approved executable code and not development code or compilers on the operational systems.
Implement applications and operating system software only after extensive and successful testing;
a) cover with the tests usability, security, effects on other systems and user-friendliness and carry them out on separate systems
b) ensure that all corresponding program source libraries have been updated.
Use a configuration control system to keep control of all implemented software as well as the system documentation.
Maintain an audit log of all updates to operational program libraries.
Have in place a rollback strategy before changes are implemented;
a) retain previous versions of application software as a contingency measure;
b) archive old versions of software, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive.
Maintain vendor supplied software used in operational systems at a level supported by the supplier.
For any decision to upgrade to a new release, take into account the business requirements for the change and the security of the release, e.g. the introduction of new information security functionality or the number and severity of information security problems affecting this version.
a) apply software patches when they can help to remove or reduce information security weaknesses.
Monitor and control externally supplied software and modules to avoid unauthorized changes, which could introduce security weaknesses.

7.6 Technical vulnerability management

Objective: To prevent exploitation of technical vulnerabilities.

7.6.1 Management of technical vulnerabilities

Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the organization’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk.

Build the technical vulnerability management with the current and complete inventory of assets in mind.
a) identify information resources that will be used to identify relevant technical vulnerabilities and to maintain awareness about them for software and other technology. For example software vendor, version numbers, current state of deployment (e.g. what software is installed on what systems) and the person(s) within the organization responsible for the software.
b) update these information resources based on changes in the inventory or when other new or useful resources are found.
Take appropriate and timely action in response to the identification of potential technical vulnerabilities.
a) address first systems at a high risk.
b) define and establish the roles and responsibilities associated with technical vulnerability management, including vulnerability monitoring, vulnerability risk assessment, patching, asset tracking and any coordination responsibilities required.
c) define a timeline to react to notifications of potentially relevant technical vulnerabilities;
d) identify the associated risks and the actions to be taken once a potential technical vulnerability has been identified. Such action could involve patching of vulnerable systems or applying other controls;
e) depending on how urgently a technical vulnerability needs to be addressed, carry out the action according to the controls related to change management or by following information security incident response procedures;
If a patch is available from a legitimate source, assess the risks associated with installing the patch (the risks posed by the vulnerability should be compared with the risk of installing the patch);
Test and evaluate patches before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated; if no patch is available:
a) turn off services or capabilities related to the vulnerability;
b) adapt or add access controls, e.g. firewalls, at network borders;
c) increase monitoring to detect actual attacks;
d) raise awareness of the vulnerability;
Keep an audit log for all procedures undertaken.
Regularly monitor and evaluate the technical vulnerability management process in order to ensure its effectiveness and efficiency.
a) align the technical vulnerability management process with incident management activities, communicate data on vulnerabilities to the incident responder and provide technical procedures in case an incident occurs;
Define a procedure to address the situation where a vulnerability has been identified but there is no suitable countermeasure. Evaluate risks relating to the known vulnerability and define appropriate detective and corrective actions.

View technical vulnerability management as a sub-function of 7.1.2 Change management and 9.2.2 System change control procedures.

Because vendors are often under significant pressure to release patches as soon as possible, there is a possibility that a patch does not address the problem adequately and has negative side effects. In some cases, uninstalling a patch cannot be easily achieved once the patch has been applied.

A delay in patching may be considered to evaluate the associated risks, based on the experience reported by other users, if adequate testing of the patches is not possible. An example is the costs or lack of resources.

Read more about the NIST Draft Special Publication (SP) 800-216, Recommendations for Federal Vulnerability Disclosure Guidelines. NIST also provides a number or articles on vulnerability management (example 1 and example 2), publishes, Guide to Enterprise Patch Management Technologies, and issues a publication Automation Support for Security Control Assessments: Software Vulnerability Management.

See also CIS Control 7 Continuous Vulnerability Management.

7.6.2 Restrictions on software installation

Rules governing the installation of software by users should be established and implemented.

Define and enforce strict policy on which types of software users may install.
Apply the principle of least privilege. If granted certain privileges, users may have the ability to install software.
Identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect).
a) grant these privileges with regard to the roles of the users concerned.

Uncontrolled installation of software on computing devices opens the door for introducing vulnerabilities and then to information leakage, loss of integrity or other information security incidents, or to violation of intellectual property rights.

See also CIS Control 2 Inventory and Control of SoftwareAssets.

7.7 Information systems audit considerations

Objective: To minimise the impact of audit activities on operational systems.

7.7.1 Information systems audit controls

Audit requirements and activities involving verification of operational systems should be carefully planned and agreed to minimize disruptions to business processes.

Agree with appropriate management the audit requirements for access to systems and data.
Agree and control the scope of technical audit tests. Esnure to run these tests (if that could affect system availability) outside business hours.
Limite the audit tests to read-only access to software and data.
a) else, allow access other than read-only for isolated copies of system files, which should be erased when the audit is completed, or given appropriate protection if there is an obligation to keep such audit files.
Identify and agree requirements for special or additional processing. Monitor aand log cll access to produce a reference trail.