Security & Compliance
< Back to Article ListIS-08 Operating Procedures for Software & Infrastructure
Last updated: 25 October 2024 at 09:29:47 UTC by Russell Briggs
Operating Procedures for Software & Infrastructure
Document Ref No |
IS-08 |
Version No |
V1 |
Last review date |
16/10/2021 |
Approved by |
Dom Tyler |
Next review |
16/10/2022 |
Contents
1.Purpose, scope and users 2
2.Operating Procedures for Software & Infrastructure 3
2.1.Development Change Management 3
2.2.Infrastructure Change management 3
2.3.Backup 3
2.3.1.Backup policy 3
2.3.2.Testing backup copies 4
2.4.Antivirus protection 4
2.5.Patch Management 4
2.6.Network security management 4
2.7.System monitoring 5
3.Document management 5
4.Version history 5
1. Purpose, scope and users
The purpose of this document is to ensure correct and secure functioning of information and communication technology.
This document is applied to the entire Information Security Management System (ISMS) scope, i.e. to all the information and communication technology, as well as to related documentation within the scope.
Users of this document are all development and IT staff.
2. Operating Procedures for Software & Infrastructure
2.1. Development Change Management
Development change control management must be documented, and any change managed from start to finish, including communication with the customer as appropriate. All changes must be tested before being deployed at a time agreed with the customer, where possible. Roll-back to previous versions should be possible for all changes.
Security should be considered along with any software development changes, this should include consideration of all common web application exploits such as described in the OWASP Top 10 (https://owasp.org/www-project-top-ten/)
2.2. Infrastructure Change management
Infrastructure change control management must be documented, and any change managed from start to finish. Any significant changes must be tested before being deployed at a time agreed with the customer and any other interested parties, where possible. Roll-back to previous versions should be possible for all changes.
For each change to operational or production systems, the following steps should be evidenced:
- The
proposed changes should be requested, communicated and progress updated
and tracked.
- Security should be a top priority when proposing, planning and implementing infrastructure changes.
- Changes must be implemented by a technically competent individual/team.
- The requestor or suitable delegate is responsible for checking/testing that the change has been implemented in accordance with the requirement.
- Any change should not be put into production before sufficient testing has been conducted.
- Implementation of changes must be reported to all affected users – this is the responsibility of the requester/suitable delegate.
2.3. Backup
2.3.1. Backup policy
Backup copies must be created for all systems which support critical business services. The frequency and type of backup must be sufficient to meet Recovery Time Objectives (RTO).
The IT/Development department is responsible for backing up the information, software and system images.
Logs of the backup process should be created on systems where the backup copy is made.
2.3.2. Testing backup copies
A sample of backup copies and the process of their restoration must be tested at least annually by implementing a data restore process and checking that all data has been successfully recovered.
2.4. Antivirus protection
Standard server and desktop builds should include antivirus software with activated automatic updates where possible.
2.5. Patch Management
The IT department is responsible for ensuring that all systems, including servers and desktops, are appropriately patched: -
● Standard desktop and laptop builds should include automatic OS patch updates.
● Server patches should be tested before being applied to live systems.
2.6. Network security management
The IT department is responsible for managing and controlling the computer networks, to ensure the security of information in networks, and to protect the services connected to the networks from unauthorised access. It is therefore necessary:
● To separate the operational responsibility for networks from the responsibility for sensitive applications and other systems.
● To protect sensitive data passing over the public network by use of appropriate encryption (e.g. HTTPS).
● To protect sensitive data passing over wireless networks by use of authentication and encryption where required.
● To protect equipment connecting to the network from remote locations by use of authentication and encryption.
● To apply appropriate traffic segregation VLANS etc, set up robust (default restrict) firewall policies and allow access to back-end infrastructure via 2FA where available.
● To ensure the availability of network services by appropriate monitoring.
● The IT department must regularly monitor, and test implemented controls
2.7. System monitoring
The IT/Development department must decide which logs will be kept on which systems and for which systems, and how long they will be stored. Logs must be kept for all administrators and system operators on sensitive systems.
The IT department is responsible for monitoring the logs of automatically reported faults on a daily basis, as well as to register faults reported by users, to analyse why errors occurred and to take appropriate corrective actions.
The IT/Development department is responsible for regularly reviewing logs in order to monitor the activities of users, administrators and system operators (an appropriate automated log management solution is the preferred approach).
Log entries which indicate security incidents or increased security risk should be raised as a security incident and the Incident Management Procedure must be followed.
3. Document management
This policy shall be available to all Recycly Employees and any Third Parties where required. The policy must be reviewed and, if necessary, updated at least once a year. Notice of significant revisions shall be provided to Recycly Employees via email.
4. Version history
Summary of Change |
Date of Change |
Author |
Version No |
First Draft |
16/10/2021 |
Dom Tyler |
1 |
|
|
|
|
|
|
|
|