Purpose

The protection of our information technology systems is of primary importance to our organisation. Maintaining the confidentiality, integrity, and availability (CIA) of the IT systems we use ensures that the operations we perform, and the services we provide, continue to meet our business objectives, comply with regulatory and legal requirements, and fulfil the requirements of our stakeholders. It also ensures that any personal data we process about our employees and customers is kept secure, minimising any potential risks or harm that may be caused by a breach of that data.

Management are committed to the security of our information, and have developed and approved this information systems security policy in line with the requirements of the ISO 27001 standard for information security, and our organisation’s business requirements.

This document sets out the approved information systems security policy so that it can be clearly communicated to all employees, contractors, and third-parties who have responsibilities for developing, managing, and maintaining our IT systems.

Scope

This policy shall apply to the development, administration, and acquisition of all IT systems that fall within the scope of our organisation’s ISMS.

Audience

All employees, contractors, and third-parties who have responsibility for the design, development, administration, acquisition, and monitoring of our information systems shall adhere to this Information Systems Security Policy. These include, but are not limited to, the following roles:

• System Administrators
• Network Engineers
• IT Support
• IT Services Providers
• Cloud Services Providers
• Cloud Security Architects
• System Architects
• System Developers
• Information Security Analysts
• System Owners
• System Testers

For the purposes of this document, employees, contractors, and third-parties who carry out these roles shall be collectively referred to as “administrators”.

Communication

This Information Systems Security Policy shall be communicated to all employees and agency staff as part of the relevant department training programme, and periodically following any changes to the policy. All contractors and third-parties providing IT services or involved in projects which require connection to our IT systems shall be provided with a copy of this policy as part of the process for contracting services. Contractors and third-parties shall be re-issued with updated versions of this policy periodically, and following any changes.

Disciplinary Process

Where an administrator performs an activity or activities in breach of this Information Systems Security Policy, they shall be subject to the disciplinary process documented in the Company Manual, or the applicable service contract.

Improvement

Management are committed to the continual improvement of our Information Systems Security Policy, and shall review this document on an annual basis, or whenever an independent review of our organisation’s ISMS reveals a non-conformance or opportunity for improvement. The Management Review shall determine if this policy continues to meet the requirements of our organisation.

Management also endeavour to plan our business operations so that our IT systems are not misused, either intentionally or unintentionally. This is done by identifying and assigning separate duties and responsibilities to guard against misuses such as fraud, or malicious insider activities, etc. Where an administrator identifies potential conflicts or misuse of information systems due to improper planning and assignment of duties, administrators should raise their concern immediately with their line manager, or the ISMS Manager.

1. Maintaining Security Awareness

New threats and vulnerabilities to technologies and services emerge on a daily basis. To ensure that the potential impact of these information security risks is minimised, administrators must remain informed of any threats and vulnerabilities that may affect the services we provide, and the information systems that we use. This will allow security best practice, vulnerability, and threat management to be key elements of how we manage risk.

To maintain awareness of emerging threats and vulnerabilities, the following policies apply:

• Administrators shall subscribe to relevant threat intelligence and vulnerability information sources such as security alert feeds, blogs, or forums such as (for example):
  • https://cve.mitre.org/cve/data_feeds.html
  • https://isc.sans.edu/
  • https://us-cert.cisa.gov/ncas/bulletins
  • https://www.cisecurity.org/cybersecurity-threats
• Administrators shall regularly review security alert notifications and other threat intelligence sources to determine if any identified vulnerabilities or issues impact our information systems, services, or how we operate them.
• Administrators shall ensure that they attend security training provided to them to keep their skill-set up-to-date. Administrators should retain evidence of any training received, such as certificates of attendance, certificates of completion, etc., where these are not already retained by HR as part of their employee training programme.
• Administrators shall maintain regular contact with service and technology providers to ensure that they are kept up-to-date with any vulnerabilities or issues that may arise.

1.1 Analysing Threats

Maintaining awareness of threats and security issues that may impact our organisation and information assets is only useful if the information is appropriately analysed and actioned as part of a threat intelligence process or lifecycle. Threat intelligence, whether gathered from suitable, trusted sources such as those listed in section 1 above, or developed by our own organisation using tools such as security information and event management (SIEM) systems, is crucial to our ability to identify and respond to new and developing security threats. Threat intelligence can be divided into three main types, with each providing a different layer of information:

1. Strategic intelligence – high-level, non-technical information about trends in malicious attacks, and the methods and tools attackers are using to launch them. For example, types of malicious attacks and attackers may vary between regions and industries. Where an organisation is expanding into a new region, gathering and assessing strategic threat intelligence would include identifying trends in malicious attacks and attackers in that region. This would allow management to proactively identify necessary resources such as additional security personnel or threat defense systems, before expanding into the new region.
2. Tactical intelligence – detailed practical information about the tactics, techniques, and procedures (TTPs) used by malicious attackers to exploit weaknesses in an organisation’s infrastructure, and attack information systems and assets. For example, information about malicious traffic seen by security experts could help a networking team to configure their organisation’s network to block the traffic using methods such as IP blacklisting. The team could also use the information about malicious traffic to check log data for indicators of compromise (IOCs). These activities could even be automated using technology such as next generation firewalls with an intrusion prevention system (IPS).
3. Operational intelligence – more detailed intelligence about how attacks are initiated, why, and by whom. This helps organisation’s to understand which information systems and assets are more likely to be attacked, and how. For example, information issued by security experts about a type of phishing campaign targetting users working in public infrastructure could help a system administrator working in a state body to pre-emptively issue warnings to users about the campaign, and identify which systems are likely to be exploited if there is a successful phishing attempt. This would then allow a response plan to be developed and implemented to inform personnel, and patch or reconfigure vulnerable systems.

When analysing and actioning threat intelligence, the following policies shall apply:

• The extent and type of intelligence analysed shall depend on the level of risk associated with the loss or compromise of the information systems and assets, and the requirements of the organisation. Administrators shall ensure that information systems and assets are risked assessed in line with our Risk Management Process to identify relevant threats and vulnerabilities, which will assist in identifying sources of threat intelligence such as those suggested in section 1 above.
• Where necessary, administrators shall identify and implement appropriate tools to log and process threat information. Tools could include, but may not be limited to:
  • Networking tools such as IPS, IDS, web content filtering, etc.
  • Log management tools
  • Vulnerability scanners
  • Application firewalls
  • Malware detection systems
  • Endpoint detection and response solutions
  • Specialist threat analysis platforms and SIEM systems
  • Third-party services such as a security operations centre (SOC) or network operations centre (NOC)
• Administrators shall identify and document all relevant sources of threat intelligence using our Threat Intelligence Source Review record, including how the information is typically actioned. The information documented shall include, but may not be limited to:
  • The exact source of the information
  • Whether the source is internal or external
  • Why the information is necessary
  • How the information will be used by the relevant administrator, team, or department The Critical Assets the information will be used to protect
  • The relevant administrator, team, or department who will use the information
  • Any applicable documentation on the use of the information, or procedures used to action the information
• Administrators shall review the information sources used at planned intervals to ensure they remain accurate and relevant, and that appropriate procedures are in place for the use of the data, such as communicating required actions to users, updating network configuration guides, reporting industry-related threats to management, etc.
• Administrators shall ensure that any logging or monitoring systems used to collect data for analysis adhere to the policies set out in section 7 of this document.
• Where an identified threat or vulnerability requires that changes be made to information systems and assets, administrators shall ensure that changes are appropriately controlled in line with section 2 of this document.
• Administrators shall use threat information gathered to ensure this policy document is kept up-to-date and relevant. For example, this could include adding additional secure disposal methods to section 3.7, or refining hardening controls set out in section 3.6.

2. Controlling Changes

Our organisation’s information systems and services may be impacted by new vulnerabilities, changes in security best practice standards, emerging technologies, impacts to supply chains, introduction of new systems and services, etc. Where required, administrators may need to make or suggest changes to our operating procedures, training requirements, system configurations, etc., and may need to initiate new projects in order to meet our business objectives.

When administering our information systems, the following policies shall apply:

• Administrators shall carry out all changes in line with our Change Control Procedure, including any emergency changes that are raised in order to address discovered or reported security vulnerabilities or weaknesses.
• Administrators shall inform their line manager or the ISMS Manager of any potential security policy changes so that these can be reviewed.
• Administrators shall inform their line manager or the ISMS Manager of all new projects that have been raised or initiated so that these can be assessed for any impacts to information security. This will ensure information security requirements are considered when new projects are initiated.

3. Protecting Information Systems & Assets

While users are required to use our organisation’s equipment and services in a secure way, administrators are required to design, develop, administer, and monitor our IT systems and equipment securely, ensuring that any risks to the security of our information are minimised in line with our business objectives. The following section sets out our requirements for IT systems and equipment security.

3.1 Maintaining an Asset Inventory

To ensure all IT systems and equipment are appropriately identified and secured, administrators shall maintain an

Equipment Register. The inventory shall include, but may not be limited to:

• Asset type i.e. server, firewall, router, switch, laptop, mobile phone, computer, backup tape, etc.
• Asset owner (the person assigned responsibility for the asset, or the primary user of the asset)
• Location, where relevant
• Make and model, where relevant
• Serial number, or other unique identifier (sometimes vendor dependent), where relevant Date of purchase, if known
• Date of destruction, where relevant (see section 3.7)
• For backup tapes, these should be clearly labelled as required by our disaster recovery procedure

The Equipment Register shall be reviewed at regular intervals, or when major changes occur, to ensure that it is kept up-to-date and accurate.

3.1.1 Inventorying cloud-based assets

Where assets are predominantly cloud- based, it may not be possible or practical to maintain a full and up-to-date asset list as resources may be spun up or shut down on demand. In this case, the following policies apply:

• Administrators shall implement the appropriate controls to restrict the creation, modification, and deletion of any virtual assets such as virtual servers, cloud containers, storage buckets, virtual networking, virtual services, etc.
• Where possible, alerting should be implemented to indicate when critical resources are created, modified, or deleted, and these notifications shall:
  • Be monitored appropriately to ensure critical assets are not negatively impacted by unplanned modifications
  • Be logged and retained in line with data retention requirements for periodic review
• Administrators shall periodically review cloud-based assets to ensure that all assets used for testing purposes are shut down, decommissioned, or removed, as required.
• Administrators shall periodically review cloud-based assets to ensure that all assets that have been replaced as part of the maintenance and/or upgrade cycles are shut down, decommissioned, or removed, as required.

3.2 Securing & Maintaining Equipment

Physical assets may be physically damaged, tampered with, or removed, resulting in a risk to the security of our IT systems and information. Our physical assets must be appropriately protected from damage in line with our business requirements. The following policies shall apply:

• Administrators shall ensure physical access to critical assets is restricted to only authorised persons. Critical assets would include, but may not be limited to, servers, firewalls, backup tapes, switches, UPS devices, redundant power supplies, modems, etc.
• Administrators shall ensure that access is removed as soon as it is no longer required.
• Administrators shall ensure that third-parties requiring access to restricted areas are accompanied at all times.
• Switch panels which may be attached to walls shall be in lockable cabinets, and the cabinets shall be locked at all times unless maintenance or re-cabling is required. Administrators shall not leave cabinet keys in or near the cabinets.
• Ethernet, fibre, critical power, and any other necessary cabling shall not be laid in ways that they can be tampered with or damaged, such as over carpets, exposed on walls, etc. Protective cages and/or covers should be used to ensure no cables are exposed.
• Appropriate environmental controls shall be installed in server and communication rooms to ensure that equipment is not damaged from excessive temperatures and humidity.
• UPS devices shall be used wherever necessary to ensure power outages do not damage critical assets.
• Where equipment is installed in server or equipment cages, administrators shall ensure that these are locked at all times unless maintenance, upgrade, or re-cabling is required. Administrators shall not leave cage keys near the cages.
• Administrators shall ensure any keys or access fobs are kept secure, and that only authorised persons have access to these
• Removal of assets for maintenance and/or replacement must be authorised, and must be carried out in line with our policy for transferring physical data in our Information Security Policy. Maintenance and/or replacement of assets by third-party providers shall be governed by suitable agreements implemented in line with our Supplier Due Diligence Policy, and shall include the requirement to maintain the confidentiality of any data that may still remain on assets being replaced or repaired.
• Where assets that are being replaced or decommissioned still store data, administrators shall ensure that they are securely destroyed in line with section 3.7 of this policy.
• Where equipment is co-located in third-party data centres, administrators must adhere to visitor and access policies of the third-party data centres at all times.
• Where necessary, suitable power generators shall be installed to maintain the required availability of critical assets
• All physical assets shall be maintained in line with the recommended maintenance guidance from the vendor or manufacturer. Where there are exceptions identified, such as with legacy systems, this shall be risk assessed in line with our Risk Management Process.
• Administrators shall ensure that suitable maintenance agreements for assets are put in place to support our organisation’s availability, performance, capacity, and supply chain requirements.
• Administrators shall provide suitable security cables to users issued with laptops.

3.3 Controlling Malware

Malware is a common tool used to disrupt and destroy information systems, and can include viruses, ransomware, rootkits, spyware, botnets, etc. which may then contribute to other types of malicious attacks, such as DoS and DDoS attacks. Administrators shall implement appropriate controls to prevent malware from infecting and spreading on our IT systems. Administrators shall apply the following policies for controlling malware.

3.3.1 Anti-virus

• Where possible, a centralised anti-virus platform shall be used to monitor and manage anti-virus clients installed on all applicable endpoints that are on, or connect to, our company network, including cloud-based infrastructure.
• Endpoints shall include company laptops, computers, mobile phones, and servers, whether physical or virtual.
• Where the anti-virus client cannot be installed or used on an endpoint, such as with unsupported mobile devices, virtual instances and cloud containers, etc. the endpoint shall be risk assessed in line with our Risk Management Process to determine the level of risk, and any suitable controls that may remediate the risk, such as file change monitoring, additional server hardening, access control, network segregation, etc. These endpoints shall be identified and assessed separately, as appropriate.
• Where a centralised anti-virus platform is not possible or available, a risk assessment shall be performed in line with our Risk Management Process to determine the level of risk, and any suitable compensating controls. At a minimum, standalone anti-virus software should be installed on all endpoints identified as critical, and suitable update and monitoring mechanisms implemented.
• Anti-virus clients shall be configured to update regularly from the centralised anti-virus platform, or from the vendor where the anti-virus software is standalone or unmanaged.
• Anti-virus clients shall be configured to prevent tampering.
• Where possible, alerting should be implemented on anti-virus software to indicate:
  • When anti-virus definitions are out-of-date
  • When potential malicious activity is detected
  • When the software is tampered with
• Where alerts cannot be logged and monitored centrally, proper functioning of the anti-virus client shall be verified by administrators at scheduled intervals. The review schedule shall be dependent on the criticality assigned to the endpoint, and administrators shall ensure that any potential malware infections detected are investigated and removed.
• Where personal devices are used, administrators shall direct users to the Information Security Policy, and assist line managers in determining a suitable solution for malware control. Administrators should identify all endpoints which are personal devices, and ensure the activity of these devices on the network is monitored appropriately.

3.3.2 Personal and host-based firewalls

• Where possible, personal or host-based firewalls shall be enabled on all applicable endpoints that are on, or connected to, our company network, including cloud-based endpoints.
• Endpoints shall include company laptops, computers, and servers, whether physical or virtual.
• Endpoint firewalls shall be configured to prevent tampering.
• Where possible, alerting should be implemented to indicate:
  • When potential malicious activity is detected
  • When the firewall is tampered with
• Where alerts cannot be logged and monitored centrally, proper functioning of the firewall shall be verified by administrators at scheduled intervals. The review schedule shall be dependent on the criticality assigned to the endpoint, and administrators shall ensure that any potential malicious activity detected is investigated.
• Where personal devices are used, administrators should identify all endpoints which are personal devices, and ensure the activity of these devices on the network is monitored appropriately.

3.3.3 Email and web filtering

Email and internet services are frequently used to launch malicious attacks such as phishing and ransomware attacks. Reducing the likelihood that malicious emails will be delivered to users, or that users will be able to browse to malicious sites, reduces the risk of malware infection, and any impacts that may have on the security of our information and information systems.

The following policies apply:

• Administrators shall implement email and web filtering services for company email and internet.
• Filtering services shall be configured to update regularly so that the latest attacks and malicious sites are identified.
• Web filtering controls shall be implemented in line with HR requirements such as blocking access to gambling sites, pornographic sites, streaming sites, etc.
• Where possible, alerting should be implemented to at least indicate:
  • When large volumes of spam are received (may indicate an attack or infected endpoint)
  • When large numbers of false-positives are identified (poor configuration of the filtering software may lead to disruptions in operations)

3.3.4 Software and application installation control

• Administrators shall identify approved software and applications in the Approved Applications Register, and implement controls that prevent the installation of unapproved software and applications on endpoints. In most situations, this should be done by implementing appropriate permissions so that a user or administrator cannot initiate software installation without requesting elevated account privileges.
• Endpoints shall include company laptops, mobile phones, computers, networking devices, and servers, whether physical or virtual.
• Where the software, application, or utility does not require elevated account privileges to be installed or run, or where the utility can override privilege requirements, these software programmes shall be identified and verified by administrators at scheduled intervals. The review schedule shall be dependent on the criticality assigned to the endpoint, and administrators shall ensure that any potential malicious activity detected is investigated.

3.4 Controlling Removable Media

Removable media includes, but is not limited to, USBs, CDs, DVDs, mobile phone storage, external hard-drives, backup tape media, etc. While removable media, and particularly USBs, are sometimes used to introduce malicious software and applications to company endpoints and networks, their primary purpose is to store and transfer data. Company data stored on removable media may be easily lost or stolen due to its portability. Removable media therefore poses a risk to the security of our IT systems and information, and the following policies shall apply:

• Where possible, administrators shall implement controls to block the use of removable media on all endpoints.
• Endpoints shall include company laptops, computers, mobile phones, networking devices, and servers, whether physical or virtual.
• In situations where the use of removable media is unavoidable, the following controls shall be used:
  • USBs, external hard-drives, and SD cards shall be issued only by an authorised administrator, and shall be appropriately scanned and encrypted before use
  • Authorised administrators shall ensure that issued USBs, external hard-drives, and SD cards are recorded and tracked in the Equipment Register in line with section 3.1 of this document
  • Only company mobile phones which are appropriately managed shall be authorised to connect to company endpoints. Users shall not be permitted to connect personal mobile phones to company endpoints.
  • Managed mobile phones shall be appropriately scanned and encrypted before use, and shall have remote wipe functionality enabled
  • CDs and DVDs shall be appropriately scanned before use
  • Administrators should not provide users with CD/DVD burning facilities, wherever possible
  • Where tape media are required for information backup, data should be encrypted if possible, and only authorised administrators shall be permitted to handle backup tape media
  • All removable media shall be handled in line with the data transfer requirements documented in our Information Security Policy

3.5 Controlling Mobile Devices

Evercam follows Bring your own device policy (BYOD). Where appropriate, the use of personal mobile devices is allowed as documented in our Information Security Policy. If a company phone is issued the device needs to be appropriately controlled in order to maintain the security of the information and services it may access and store. The following policies for securing mobile devices shall apply to company issued phones.

3.5.1 Mobile phones

• If a company phone is issued it shall be recorded and tracked in the Equipment Register in line with section 3.1 of this document.
• Wherever possible, administrators should use an MDM solution to easily onboard and manage company mobile phones. Where an MDM solution is not available, solutions such as Exchange ActiveSync, Microsoft 365 Basic Mobility and Security, anti-virus mobile device controls, etc. should be investigated and implemented.
• Where no centralised management of mobile phones is available, administrators shall configure each company phone with a security baseline before it is issued to the user.
• Administrators shall configure the following minimum set of security controls for company mobile devices:
  • The device must be password protected with at least a PIN
  • The PIN shall be a minimum of 6 numbers
  • The device shall be configured to lock itself when it has been idle for more than 1 minute
  • Where possible, installation of apps shall be restricted, and only approved apps shall be installed Only mobile phones with operating systems that use encryption as default shall be used
  • Where possible, the device shall be configured to support features to locate and/or remote wipe the device
  • Anti-malware software shall be installed
  • The device shall be configured to automatically update
• Administrators shall ensure company mobile phones are not jailbroken or rooted.
• Administrators shall facilitate the installation of MDM software on personal mobile phones where requested by the user, and approved by their line manager.

3.5.2 Laptops

Evercam follows Bring your own device policy (BYOD) thus, it is expected that each employee is responsible for safe and secure use of their own work devices (laptops). The following rules apply:

• All employee devices should be password protected.
• 2FA should be enabled to access company applications (Google and Zoho).
• Company information cannot be stored on local device Save (documents to be saved on relevant Google Shared Drive / Zoho Workdrive).
• Employees are in charge of ensuring that the devices have the latest security updates installed.
• Employees should not attempt to log into company applications (Zoho and Google) with a private user account.
• Employees should not install unverified/unapproved applications or software.
• Employees should ensure that their endpoint devices are adequately encrypted.
• All employee laptops shall have anti-malware controls configured in line with section 3.3 of this document.
• Where central management is not possible, encryption keys for each laptop must be recorded and restricted to only authorised administrators.
• Employees should contact Support@Evercam.io immediately if your device is lost or stolen.

3.6 Hardening & Patching

Security vulnerabilities can be introduced to our IT systems and information assets through misconfiguration, software bugs, and other weaknesses. To ensure that our IT systems and information assets are protected against these types of vulnerabilities, the following policies shall apply:

• Administrators shall develop, document, and implement appropriate hardening controls for critical assets, whether they are virtual or physical devices, software, or services. Implementing the hardening guides will ensure that the assets have a minimum set of security controls configured before they are deployed to our organisation’s network, or rolled-out to users. These configuration controls should include, but may not be limited to:
  • Disabling and/or removing all unnecessary services and applications
  • Ensuring that operating systems and applications used are appropriately licensed, and patched to the latest approved versions
  • Managing stored data so that test and/or configuration data is removed from the asset before deployment
  • Encrypting drives and/or data stores with encryption at rest wherever necessary Implementing privileged access controls
  • Enforcing 2FA for cloud-based software and services
  • Changing default operating system and application credentials
  • Disabling generic and/or default accounts wherever possible
  • Installing anti-malware controls as documented in section 3.3 of this policy Blocking removable media as documented in section 3.4 of this policy
  • Implementing controls for resource consumption to limit the impact of DoS, or other capacity issues that might cause the asset to become unavailable
  • Enabling alerts and logging as documented in section 7 of this policy
• Administrators shall review critical assets at regular intervals to ensure that security controls are implemented in line with the established hardening guides.
• Administrators shall review established hardening guides at regular intervals to ensure they remain up-to-date in line with best practice recommendations, and available threat intelligence as documented in section 1.1 of this policy.
• Administrators shall maintain awareness of vulnerabilities and threats as documented in section 1 of this policy and shall implement appropriate patching cycles for all company laptops, computers, mobile phones, networking devices, and servers, whether physical or virtual. Patching cycles should take into consideration the criticality of the assets and associated services.
• Administrators shall review patch levels at regular intervals and ensure that all endpoints are appropriately patched and up-to-date.
• Administrators shall obtain the latest patches only from approved vendors, and shall verify the authenticity of any downloaded patches before deployment.

3.7 Secure Disposal

Information stored on assets can potentially be recovered even after they are removed from our organisation’s network, and disposed of. Disposal of any asset containing company data must therefore be done securely, ensuring that any information remaining is no longer readable. The following policies shall apply:

• Administrators shall ensure that all company mobile phones, laptops, computers, USBs, external hard-drives, and SD cards that are wiped before users departure, ensuring that new users cannot read or access previously stored data or user accounts.
• Administrators shall ensure that all company endpoints that are end-of-life and due for destruction are securely destroyed either by:
  • Physical destruction such as shredding
  • Secure erasure of data by authorised data erasure providers Secure erasure using approved data destruction software
  • Secure erasure services provided by the applicable cloud-service provider
  • Erasure of encryption keys (cryptographic erasure can render the data unrecoverable if the encryption algorithm is a minimum of 128-bits)
• Where using third-parties to destroy assets and associated data, administrators shall ensure that certificates of destruction are received, and that these are retained as evidence.
• Administrators shall ensure that the assets are securely transferred to, or collected by, the third-party in line with the policy for physical data transfer in our Information Security Policy.
• Administrators shall ensure that the Equipment Register is appropriately updated with the Date of Disposal, and the location of applicable certificates of destruction, where available.

3.8 System Continuity & Information Backup

Situations may occur where an IT system or information asset is compromised or fails, despite having the required controls in place. When this happens, it should be possible to restore the IT system or information asset, and recover the information to an acceptable level. The following policies shall apply for IT systems and information backup:

• Administrators shall review our organisation’s Critical Asset Register in conjunction with our Equipment Register, and shall identify appropriate system recovery and information backup procedures for all required assets in line with our organisation’s business requirements.
• Administrators shall document the system recovery and information backup procedures in formal Disaster Recovery Procedure/s, and shall make sure these are made available to all persons involved in the recovery procedures.
• Administrators shall perform system recovery, and information backup and recovery procedures, in line with our documented Disaster Recover Procedure/s.
• Administrators shall ensure that system recovery procedures and information backups are reviewed and tested at regular intervals so that any failures can be investigated and corrected as soon as possible. Where working with IaaS and virtualised environments, site mirroring and server or database cloning activities should be logged and monitored, and logs should be checked at intervals appropriate to the criticality of the environment. Where working with PaaS environments, appropriate redundancy measures should be identified and confirmed in line with the Supplier Due Diligence Policy.

3.9 Information Protection

There may be situations where additional technical protections are required to further restrict the access, copying, and sharing of sensitive or confidential data stored on, or processed using, our information assets. These additional technical protections are typically referred to as data masking and data loss prevention (DLP), or data leakage prevention, techniques. The following policies shall apply for identifying and implementing suitable information protection techniques, where required:

• Administrators shall work with data owners in line with sections 1.8.1 and 1.8.2 of the Data Handling & Retention Guidelines to identify appropriate technical controls for the protection of the information the data owner is responsible for. Types of additional controls may include, but are not limited to:
  • Encryption
  • Masking out
  • Pseudonymisation
  • Email DLP
  • Endpoint DLP
  • Cloud-based information protection and governance systems
  • Download restriction
  • Removable device restriction
• The extent and type of technical controls identified shall depend on the level of risk associated with the processing of the data, and the business, legal, regulatory, and/or contractual requirements applicable to our organisation. Data owners and administrators shall ensure the risk assessments are carried out in line with our Risk Management Process, and that suitable controls for data masking and DLP are implemented, where required.
• When determining whether additional technical controls are required, administrators shall take into consideration the access, network, and cryptographic controls already implemented in line with sections 4, 5, and 6 of this policy.
• Where it is determined that the logging and monitoring of copying or export operations associated with sensitive or confidential information is required, administrators shall ensure these activities are logged and monitored in line with section 7 of this policy.

4. Protecting Networks & Communications

Our organisation’s network is a critical part of providing information services both internally to our users, and externally to our clients and other third-parties, and can be physical, virtual, cloud-based, or a combination. Our network, and communications technologies that we may use as part of that network, shall be appropriately protected to minimise any information security risks in line with our business requirements. The following policies apply for securing our network.

4.1 Secure Network Design

When designing the network, administrators shall apply the principle of defense in depth to ensure that information systems and assets are protected according to their criticality by applying multiple security controls such as those documented in section 3 of this policy, and other network security controls such as IPS, IDS, etc.

• Administrators shall ensure that appropriate firewall and routing technologies are implemented to secure the network perimeter and restrict network traffic to only authorised traffic.
• Administrators shall ensure that all network routing rules are configured to deny traffic by default.
• Administrators shall ensure that NAT is implemented wherever possible so that internal resources are not routable from public networks such as the internet.
• Administrators shall ensure that the network is appropriately segregated so that compromise of one part of the network does not result in the entire network being compromised. For example, by using VLANs, subnets, VPCs, DMZs, multiple domains, etc.
• Administrators shall ensure that network interfaces are configured to prevent access from unapproved devices and network traffic, or that they are not reachable from network segments with lower levels of security such as public networks, DMZs, etc.
• Administrators shall ensure that industry standard cabling is used to support our organisation’s capacity and performance requirements.
• Administrators shall ensure that service providers providing internet connectivity and/or cloud-based network infrastructure meet our organisation’s performance, capacity, and availability requirements. Where necessary, secondary service providers shall be used for redundancy, and networks shall be appropriately configured to fail-over when required.
• Where a number of mobile devices are used to connect to the network, administrators should consider implementing device authentication mechanisms such as RADIUS servers and Network Access Control (NAC), where appropriate.
• Administrators shall not use deprecated and/or unsecure protocols such as telnet, SSL, and versions of SNMP prior to SNMPv3. Administrators shall maintain awareness of vulnerabilities and threats as documented in section 1 of this policy, and ensure network protocols are appropriately secured and/or disabled where necessary.

4.1.1 Using Wi-Fi

Where Wi-Fi is used in our organisation’s offices, the following policies shall apply:

• Administrators shall ensure WPA2 is used to encrypt wireless traffic.
• Administrators shall ensure that Wireless Access Points (WAPs) are placed in locations where they cannot be unplugged or damaged, which may cause disruption to users and services.
• Administrators shall ensure that wireless traffic is appropriately segmented from the network where required. For example, where guest networks are provided for visitors, or where users are not permitted to access certain services from the wireless network.
• Administrators shall ensure Wi-Fi Protected Setup (WPS) is disabled.
• Administrators shall ensure the SSID of the wireless network is appropriately controlled. Controls may include:
  • Disabling broadcast of the SSID
  • Renaming of the SSID so that it is not easily identifiable as belonging to our organisation
  • Reducing the power level of the broadcast signal so that it is not easily accessible from outside of our offices
• Administrators shall implement authentication mechanisms for wireless devices to reduce the risk of unapproved devices connecting to the network. Authentication controls may include:
  • MAC address filtering
  • Network security key rotation
  • RADIUS
  • Security certificates

4.2 External Access & Connections

• Where remote access to network resources is provided, administrators shall implement a suitable VPN for approved users and/or third-parties. The VPN shall include, but may not be limited to, the following controls:
  • Support for strong, industry standard encryption
  • Where a site-to-site VPN is used, routing and firewall rules shall be configured to deny all unapproved traffic
  • Wherever possible, 2FA should be used for authentication e.g. user credentials and security token
• Public-facing services that facilitate the transfer of data across the internet and/or uncontrolled third-party networks shall be encrypted using strong, industry standard encryption.
• Public-facing services that facilitate the transfer of data across the internet and/or uncontrolled third-party networks shall use strong authentication mechanisms such as 2FA, security tokens, cryptographic keys, etc. wherever possible to minimise the risk of unauthorised access.
• Where third-parties require access to our network, administrators shall ensure that the external access is restricted to only authorised IP addresses and ranges, where possible.

4.3 Using Encryption

• Services used on our organisation’s network shall be configured to encrypt their data in transit wherever possible. For example:
  • Where LDAP is a required service, LDAPS should be implemented
  • Where FTP is a required service, SFTP should be implemented
  • Where SNMP is required, SNMPv3 with authPriv should be implemented
• In cloud-based infrastructure, administrators shall ensure that network traffic between virtual machines, routers, data containers, backup images, etc. are encrypted in transit wherever possible.

5. Controlling Access

Implementing appropriate access controls for information and associated information assets is essential to minimising the risk of unauthorised access, data breach, accidental modification, and other malicious or damaging activities that may originate from both inside and outside of our organisation. Information and associated information assets must be protected according to their classification, our business requirements, and our legal and regulatory requirements as documented in our Information Security Policy. Access control shall be implemented so that only authorised users have access to information and associated information assets. This section sets out our requirements for access control.

5.1 Managing Passwords

One of the standard methods of authenticating access to IT systems and information is by using password management systems. The use of passwords and account controls has changed over time, and some password management systems no longer require rotation and expiry of passwords, but instead enforce passwords of greater length and complexity, along with secondary authentication such as biometrics, security tokens, device registration, etc. The following policies shall apply for our organisation.

5.1.1 Choosing a password management system

• Administrators shall ensure password management systems used for accessing an information system or service are risk assessed in line with our Risk Management Process, and that controls appropriate to the criticality of the system are identified and implemented.
• Where appropriate access controls cannot be implemented, administrators should avoid using the information system or service where possible.
• Where possible, administrators should consider the use of Single Sign-On (SSO) to ensure user account policy controls are applied consistently across information systems of similar criticalities, and to improve the security of registration and de-registration procedures.
• Where information systems are accessible from the internet, administrators shall ensure that the password management system can implement 2FA.
• At a minimum, the password management system should ensure administrators can configure the following account policy controls:
  • Passwords with a minimum number of characters
  • Passwords with a mix of numbers, uppercase, lowercase, and special symbols such as (*%!&) that prevent the use of dictionary words
  • Forced password expiry so that new passwords must be used periodically Minimum password reset time
  • A password history so that passwords cannot be re-used frequently
  • Account lockout on repeated failure attempts to prevent brute-forcing of accounts. Administrators should use caution when implementing account lockout for some services as brute-force attacks may result in DoS where multiple accounts may become locked and inaccessible.
  • One-time use passwords
• Administrators shall ensure the system masks passwords when entered so that they are not visible to other persons.
• Administrators shall ensure the system does not allow passwords to be sent in the clear across the network or public-facing networks such as the internet.
• Administrators shall ensure the system does not allow the enumeration of account usernames by allowing valid accounts to be identified. For example, where the user enters their password incorrectly, the system shall not indicate that authentication failed due to an incorrect password. In this scenario, a malicious attacker would then know that the username is valid, and may attempt to brute-force the account.
• Administrators shall ensure that the system does not store account passwords with reversible encryption.

5.1.2 Managing user accounts

• Administrators shall create, modify, or disable user accounts in line with our Joiners/Movers/Leavers Procedure (JML Procedure).
• Administrators shall assign account permissions according to the principle of least privilege, ensuring that users are only given access to information and systems they are authorised to use.
• Administrators shall use appropriate access controls to restrict user access to information in line with business requirements. Controls may include, but may not be limited to:
  • Mandatory Access Controls for restricting Highly Confidential data
  • Role-based Access Control for assigning permissions based on the user’s role and responsibilities
• Where a user requests access to a system, service, and/or information, administrators shall confirm the access request with the asset owner identified in section 3.1 of this document, or the asset owner identified in the Critical Asset Register. The asset owner assigned in the Critical Asset Register shall take precedence if ownership is unclear.
• At a minimum, administrators shall configure the user account policy to require the following:
  • Passwords with a minimum of 8 characters
  • Passwords with a mix of numbers, uppercase, lowercase, and special symbols such as (*%!&) that prevent the use of dictionary words
  • Forced password expiry of 90 days unless 2FA is required
  • A minimum password reset time of 1 day to prevent users from resetting their password too frequently
  • A password history of at least 10 passwords to prevent frequent re-use of passwords
  • Account lockout of 30 minutes on 5 failed logon attempts. The account should automatically unlock after the 30 minute period, or IT can manually unlock the account upon request
  • Password reset on first logon or following manual password reset
• Administrators shall ensure 2FA is enabled for users, where possible.
• Administrators shall assign each user with a unique ID.
• Administrators shall not re-use user IDs.
• When resetting passwords, or providing passwords to new users, administrators shall ensure a one-time password is used
• Administrators shall not request users’ passwords from them for any reason. When requiring access for support purposes, administrators shall reset the user’s account before and after use, and only with user permission.
• Administrators shall always confirm the identity of the user before responding to account reset requests.
• Administrators shall perform user account and permissions audits at planned intervals, and shall ensure that the accounts and assigned permissions are reviewed and confirmed by line managers and/or asset owners, as appropriate. All unused accounts shall be disabled.

5.1.3 Managing privileged accounts

• Administrators shall identify and document all privileged accounts used to perform administrative operations.
• Administrators shall ensure that privileged accounts do not use default account credentials.
• Administrators shall configure privileged accounts to ensure proper separation of duties. For example, a privileged account used to manage resources and data on a server shall not be able to modify log data on the same server. This ensures that the account cannot be used to hide malicious activities if compromised by a malicious attacker.
• Administrators shall ensure that privileged accounts are used only to perform their required administrative operations, and are not used for day-to-day activities.
• When creating privileged accounts, the account name shall not easily identify the purpose of the account.
• For example, ExchangeAdminAccount, ActiveDirectoryAdministrator, etc.
• Administrators shall avoid using root accounts wherever possible. Administrators should rather create new privileged accounts for the required roles and ensure root credentials are kept secure.
• Administrators shall ensure that privileged accounts are used by authorised persons only.
• Where accessing systems over the internet or other unmanaged networks using privileged accounts, 2FA shall be enabled
• At a minimum, privileged accounts shall require the following policy:
  • Passwords with a minimum of 12 characters
  • Passwords with a mix of numbers, uppercase, lowercase, and special symbols such as (*%!&) that prevent the use of dictionary words
• Where possible, administrators shall periodically reset privileged account passwords, and when persons with knowledge of privileged accounts leave the organisation.
• Administrators shall periodically audit privileged accounts to ensure these are appropriately controlled.

5.1.4 Managing generic accounts

Generic and service accounts may be used to run unattended operations, background services, provide temporary user or guest access, provide access to a shared account, etc. The following policy applies for managing generic and service accounts:

• Administrators shall not create generic accounts for guest or temporary users. Each user must be provided with an account with a unique ID so that activity is auditable.
• Where necessary, administrators can provide delegated permissions for an agreed period of time in situations where account sharing is unavoidable. This will ensure passwords and user IDs are not shared. Administrators shall confirm the request with the account and/or asset owner before delegating permissions.
• Administrators shall identify and document all service accounts used to perform service operations.
• Administrators shall ensure that each service account is only permitted to access the services and information assets it is authorised to access.
• Administrators shall ensure that service accounts are not added to security or other privileged groups with permissions higher than it requires.
• Administrators shall ensure that all unnecessary rights are removed from service accounts.
• Administrators shall periodically audit service accounts to ensure these are appropriately controlled.

6. Cryptographic Controls

Our organisation primarily uses cryptographic controls to protect the confidentiality and integrity of our data by encrypting it in transit and at rest, and to provide authentication to access IT systems and information assets by using public/private key pairs. This section sets out our requirements for managing cryptographic controls. The following policies apply:

• Administrators shall ensure all IT systems and information assets are encrypted as required by this Information Systems Security Policy. For example, section 4.1.1 of this document states that Wi-Fi shall be encrypted using WPA2. Section 4.3 requires network services to be encrypted where possible, etc.
• Where cryptographic controls are not explicitly mentioned in this document, administrators shall ensure that all IT systems and information assets are risk assessed in line with our Risk Management Process to determine whether cryptographic controls are required, and what level of control is appropriate.
• Administrators shall not use bespoke encryption or hashing algorithms. Administrators shall maintain awareness of security standards as documented in section 1 of this policy, and use only strong, industry standard algorithms. Examples may include:

• Administrators shall not use deprecated algorithms, or algorithms with known vulnerabilities.

6.1 Managing Cryptographic Keys

Our organisation may generate cryptographic keys for the following reasons, and should not be considered exhaustive:

• To provide access to information assets and IT systems such as servers, databases, networking devices, cloud-based infrastructure, etc. whether physical or virtual
• To encrypt data at rest such as with full disk encryption on laptops, data storage, backup tapes, etc.
• To encrypt individual files or emails, etc.
• Generating security certificates for protecting public-facing applications

The following policies apply:

• Administrators shall ensure that a centralised key management system (KMS) is used, where possible. When maintaining cloud-based infrastructure, administrators should use KMS services provided, where available and appropriate.
• Where keys cannot be centrally managed, administrators shall identify appropriate procedures for recording and storing keys. For example, where laptop encryption keys are generated on a per-device basis, keys shall be recorded and stored securely, and access restricted.
• Administrators shall ensure that access to key generation is restricted to authorised persons only. Administrators shall ensure that keys are stored securely with restricted access, and are appropriately backed up to ensure that loss of the key store does not result in the loss of access to critical IT systems and information assets.
• Administrators shall periodically test recovery of keys to ensure keys can be restored.
• Administrators shall implement procedures for rotating keys at regular intervals.
• Administrators shall ensure keys are revoked in situations where the key may have become compromised, or when persons with knowledge of, or previous access to, keys leave the organisation.
• Where possible, administrators shall configure keys to expire, and shall develop procedures for updating expired keys.
• Administrators shall periodically review keys to ensure they are rotated, revoked, and expired as required.
• Where using public-key infrastructure (PKI), administrators shall ensure that certificate authorities (CAs) and registration authorities (RAs) are trusted.

7. Logging and Monitoring

To assist in identifying issues such as malicious activity, misconfigurations, incidents, security incidents, service failures, etc. it is critical that our organisation ensure that activities that take place on our organisation’s network, IT systems, and information assets are appropriately logged and monitored. This section sets out our requirements for the auditing and review of logging information. The following policies apply:

• Administrators shall ensure all IT systems and information assets are audited and monitored as required by this Information Systems Security Policy. For example, section 3.1.1 of this document states that logging shall be enabled to indicate when critical resources are created, modified, or deleted. Section 3.3.1 requires anti-malware applications to generate logs, etc.
• Where requirements for logging and monitoring are not explicitly mentioned in this document, administrators shall ensure that all IT systems and information assets are risk assessed in line with our Risk Management Process to determine whether logging and monitoring is required, and what level of logging is appropriate.
• Where possible, administrators shall ensure that all IT systems and information assets are configured with a single time source. The time source shall be a trusted, external source. Ensuring system clocks are synchronised across information assets will ensure log data can be accurately compared when investigating incidents and troubleshooting issues.
• Where possible, a security information and event management (SIEM) system should be used to centralise the capture and monitoring of log data.
• The level of logging configured shall be appropriate to the criticality of the information asset. Log data should include, but may not be limited to:
  • Date and time data
  • Access control events such as log on, log off, login failure/success events, etc.
  • The use of service accounts and utility programmes that are restricted
  • Modification of particular files, services, configurations, etc.
  • Service and application faults
• Administrators shall review log data at regular intervals to minimise the risk of potential security incidents remaining unnoticed. Where possible, alerts shall be configured so that certain log events, or logs generated by critical assets, can be prioritised and responded to appropriately.
• Administrators shall ensure that only authorised persons have access to log data. Log data shall be protected from modification and/or deletion at all times.
• Administrators shall not be able to modify and/or delete any administrator or operator logs associated with their own activities.
• Log data shall be retained for a minimum of 3 months, or where our organisation’s data retention requirements may require additional retention times.

8. System Testing

As changes are made to our IT systems, services, and information assets, new vulnerabilities and weaknesses may be introduced. New threats are also emerging on a daily basis. Independent system testing at planned intervals can assist in ensuring that our IT systems and information assets continue to be adequately protected in line with our organisation’s requirements. The following policies for system testing shall apply:

• Required testing activities shall be identified based on the criticality of the system or asset. Administrators shall ensure a risk assessment is carried out in line with our Risk Management Process to ensure appropriate levels and frequency of testing are identified.
• All testing shall be appropriately planned and scoped so that business operations are not negatively impacted. System testers shall not exceed the scope of the planned testing activities.
• System testers shall be appropriately trained to carry out the testing activity. Where necessary, third-party security analysts and penetration testers should be contracted to perform testing activities.
• System testers shall be independent i.e. they shall not test information systems or assets that they are responsible for administering.
• System testers shall give asset owners advanced notice of any testing being carried out, and shall obtain permission from the asset owner.
• Where testing may include cloud-based services and infrastructure, or other third-party providers, system testers must obtain permission from the cloud-service provider and/or third-party to carry out the testing.
• System testers shall record the results of their tests, and provide recommendations for remediation.
• Where weaknesses are identified, administrators shall perform a risk assessment in line with our Risk Management Process.

9. Identifying & Reporting Incidents

Administrators play a key role in the identification and reporting of potential security incidents, and are frequently first responders. Where a potential security incident has been reported, either by a user, another administrator, or in situations where an administrator notices a potential incident themselves, the following policies shall apply:

• Administrators shall adhere to our Incident Response Procedure and alert our Incident Response Team (IRT) to the incident. The IRT will determine next steps for handling the incident.
• Administrators shall not attempt to trace or track a malicious attacker. Priority shall be given to alerting the IRT and following our Incident Response Procedure. Where an administrator prioritises catching a potential malicious attacker, this may increase the impact of the attack on our information systems and assets.
• Administrators shall assist users in performing initial containment activities such as disabling network connectivity, unplugging removable media, etc.
• Administrators shall participate in regular incident response training exercises to ensure that they are familiar with our Incident Response Procedure.

10. Performing Reviews

Like security testing, auditing and review activities are essential to ensure that the development, management, and maintenance of our IT systems and information assets remain in line with the requirements of this policy. Review activities will also assist in identifying potential improvements. The following policies apply for performing reviews:

• Administrators shall ensure all review activities are performed as required by this Information Systems Security Policy. For example, section 3.1 of this document requires the review and maintenance of an Equipment Register. Section 5.1.2 requires that user accounts be audited at regular intervals, etc.
• Where requirements for performing reviews or audits are not explicitly mentioned in this document, administrators shall ensure that all IT systems and information assets are risk assessed in line with our Risk Management Process to determine whether periodic review or auditing is required.
• Administrators shall retain evidence of review or auditing activities. Evidence may include, but may not be limited:
  • Checklists that contain the date, what was checked, and who carried out the check
  • Reports containing testing results
  • User lists with last login information and confirmation of permissions from line managers or asset owners, as appropriate
• Administrators shall ensure that evidence of review or auditing activities is controlled, and protected from unauthorised access and tampering.