Purpose

This document addresses the Control 8.1 of ISO 27001:2022. Control 8.1 is preventive in nature. It requires Edge Services and Solutions LLC (herein after called the ‘Company’) to implement policies, procedures, and technical measures that apply to all user endpoint devices which host or process information assets so that they are not compromised, lost or stolen. 

Scope

This policy applies to the Company that handles user endpoint devices like laptop, desktop etc., which use IT Infrastructure to provide customer services.

Ownership of Control 8.1

Company has appointed CISO, Mr. Ghazi Muhammad Abdullah as the person who oversees compliance adherence as this control deals with creation, maintenance of and adherence to Company-wide topic-specific policy, procedures and technical measures. 

Process for complying with User endpoint devices for Information Security

Control 8.1 requires Company to create a topic-specific policy that addresses how user endpoint devices should be configured securely and how these devices should be handled by users.

All personnel should be informed about this Policy and the Policy covers the following:

1. What type of information, particularly on what level of classification, can be processed, stored or used in user endpoint devices.
2. How the devices should be registered.
3. Requirements for the physical protection of devices.
4. Restrictions on the installation of software programmes on devices.
5. Rules on the installing of software on the devices and on software updates.
6. Rules on how the user endpoint devices can be connected to public networks or to networks on other off-site premises.
7. Access controls.
8. Encryption of the storage media hosting information assets.
9. How devices will be protected against malware attacks.
10.  How devices can be disabled or locked out. How information contained in the devices can be wiped off remotely.
11.  Back-up methods and procedures.
12.  Rules on the use of web applications and services.
13.  Analysis of end-user behaviour.
14.  How removable storage media such as USB drives can be used and how physical ports such as USB ports can be disabled.
15.  How segregation capabilities can be used to separate the Company’s information assets from other assets stored on the user device.

Furthermore, the General Guidance notes that Company should consider prohibiting the storage of sensitive information assets on user endpoint devices by implementing technical controls.

These technical controls may include disabling local storage functions such as SD cards.

In putting these recommendations into practice, Company should resort to Configuration Management as set out in the Control 8.9 and use automated tools.

Supplementary Guidance on Use of Personal Devices (BYOD)

While allowing personnel to use their own personal devices for work-related purposes saves Company money, it exposes sensitive information assets to new risks.

Control 8.1 lists 8 recommendations that Company should consider when allowing employees to use their own devices for work-related tasks:

1. There should be technical measures such as software tools in place to separate the personal and business use of the devices so that the Company’s information is protected.
2. Personnel should be allowed to use their own device only after they agree to the following:
3. Personnel acknowledge their duties to physically protect devices and to carry out necessary software updates.
4. Personnel agree to not claim any ownership of the Company’s information assets.
5. Personnel agree that information contained in the device can be remotely deleted when the device is lost or stolen, subject to legal requirements for personal data.
6. Establishment of policies on the ownership of intellectual property rights created via the use of user endpoint devices.
7. How the private devices of personnel will be accessed considering the statutory restrictions on such access.
8. Allowing personnel to use their private devices can lead to legal liability due to the use of third party software on these devices. Company should consider the software licensing agreements they have with their vendors.

Supplementary Guidance on Wireless Connections

Company should develop and maintain procedures for:

1. How wireless connections on the devices should be configured.
2. How wireless or wired connections with sufficient bandwidth will be used in compliance with topic-specific policies.

Additional Guidance on Control 8.1

When user endpoint devices are taken out of the Company’s premises, information assets may be exposed to heightened risks of compromise. Therefore, Company may have to establish different controls for devices used outside of premises.

Furthermore, Control 8.1 cautions Company against loss of information due to two risks related to wireless connections:

1. Wireless connections with low bandwidth may result in failure of data back-up.
2. User endpoint devices may occasionally get disconnected from the wireless network and scheduled back-ups may fail.

The below table is maintained by the Company for all it’s User Endpoint devices (Desktops, Laptops, Smartphones, Tablets, Servers, Workstations, Internet-of-things (IoT) devices etc.,).

Technological Control No. 8.2

Privileged Access Rights

1.0 Purpose

This document addresses the Control 8.2 of ISO 27001:2022. Privileged access rights allows Company to control access to their infrastructure, applications, and assets; maintain the integrity of all stored data and systems.

Control 8.2 is a preventative control that maintains risk by establishing an authorisation process that handles all requests for access across the Company’s ICT network and associated assets. 

2.0 Scope

This policy applies to the Company that handles customer projects using IT Infrastructure.

3.0 Ownership of Control 8.2

Control 8.2 deals with the Company’s ability to control access to data via user accounts that enjoy enhanced access rights.

As such, ownership should reside with the Head of IT (or Company equivalent), who holds responsibility for the Company’s ability to administer and monitor privileged domain or application user accounts. 

4.0 Process for complying with Privileged Access Rights for Information Security

As per Control 8.2 the Company follows the below points, in accordance with a “topic specific” policy on access control (see Control 5.15) that targets individual business functions.

Company will:

1. Identify a list of users who require any degree of privileged access – either for an individual system – such as a database – application, or underlying OS.
2. Maintain a policy that allocates privileged access rights to users on what is known as an “event by event basis” – users should be granted levels of access based on the bare minimum that is required for them to carry out their role.
3. Outline a clear authorisation process that deals with all requests for privileged access, including keeping a record of all access rights that have been implemented.
4. Ensure that access rights are subject to relevant expiry dates.
5. Take steps to ensure that users are explicitly aware of any period of time where they are operating with privileged access to a system.
6. Where relevant, ask the users to re-authenticate prior to using privileged access rights, in order to affect greater information/data security.
7. Carry out periodic audits of privileged access rights, especially following a period of Company change. Users’ access rights should be reviewed based upon their “duties, roles, responsibilities and competence” (see Control 5.18).
8. Consider operating with what’s known as a “break glass” procedure – i.e. ensuring that privileged access rights are granted within tightly-controlled time windows that meet the minimum requirements for an operation to be carried out (critical changes, system administration etc.,).
9. Ensure that all privileged access activities are logged accordingly.
10. Prevent the use of generic system login information (especially standardised usernames and passwords) (see Control 5.17).
11. Keep to a policy of assigning users with a separate identity that allows for tighter control of privileged access rights. Such identities can then be grouped together, with the associated group being provided differing levels of access rights.
12. Ensure that privileged access rights are reserved for critical tasks only that relate to the continued operation of a functioning ICT network – such as system administration and network maintenance.

Supporting Controls 

5.15 / Access Control

Technological Control No. 8.3

Information Access Restriction

1.0 Purpose

This document addresses the Control No. 8.3 of ISO 27001:2022. Access to information from internal and external sources is the cornerstone of  Company information security policy.

Control 8.3 is a preventive control that maintains risk by establishing a series of rules and procedures that prevent unauthorised access/misuse of Company’s information and ICT assets.

2.0 Scope

This policy applies to the Company that handles customer projects using IT Infrastructure.

3.0 Ownership of Control 8.3

Control 8.3 deals with Company’s ability to control access to information.

As such, ownership should reside with the Chief Information Security Officer (who holds responsibility for the Company’s overall information and data security practices. 

4.0 Process for complying with Privileged Access Rights for Information Security

In order to maintain effective control over information and ICT assets and in support of access restriction measures, Company ensures the following in line with a topic-specific approach to information access:

1. Prevent anonymous access to information, including far-reaching public access.
   1. Where public or third-party access is granted, Company ensures that access does not extend to sensitive or business critical data.
2. Operate with adequate maintenance measures that control systems access and any associated business applications or processes.
3. Dictate data access on a user-by-user basis.
4. Specify data access rights between groups that validate specific data operations, such as read, write, delete and execute.
5. Retain the ability to partition off business critical processes and applications using a range of physical and digital access controls.

Guidance – Dynamic Access Management

Control 8.3 advocates for a dynamic approach to information access.

Dynamic access management has numerous residual benefits for Company processes that feature the need to share or use internal data with external users, including faster incident resolution times.

Dynamic access management techniques protect a broad range of information types, from standard documents to emails and database information, and have the ability to be applied on a granular file-by-file basis, enabling tight control of data on a Company level.

Company considers such an approach when:

1. Requiring granular control over what human and non-human users are able to access such information at any given time.
2. The need arises to share information with external parties (such as suppliers or regulatory bodies).
3. Considering a “real-time” approach to data management and distribution that involves monitoring and managing data use as it occurs.
4. Safeguarding information against unauthorised amendments, sharing or output (printing etc.,).
5. Monitoring the access to and changing of information, particularly when the information in question is of a sensitive nature.

Dynamic access management is of particular use for Company that need to monitor and protect data from creation through to deletion, including:

1. Outlining a use case (or series of use cases) that apply data access rules based on the following variables:

• Identity
• Device
• Location
• Application

1. Outlining a process that covers off the operation and monitoring of data, and establishing a thorough reporting process which is in turn informed by a sound technical infrastructure.

All efforts to formulate a dynamic access management approach result in data being protected by:

1. Ensuring that access to data is the end result of a successful authentication process.
2. A degree of restricted access, based on the data type and its ability impact business continuity.
3. Encryption.
4. Printing permissions.
5. Thorough audit logs that record who access data, and how that data is being used.
6. An alerts procedure that flags up inappropriate data use, including (but not limited to) unauthorised access and distribution, and attempted deletion.

Technological Control No. 8.4

Access to Source Code

Purpose

This document addresses the Control 8.4 of ISO 27001:2022. Control 8.4 defines “source code” as the underlying code, specifications and plans used to create applications, programs, and processes that are the property of the Company. Control 8.4 gives an equal amount of importance to developmental tools (compilers, test environments etc.,) while addressing the topic of access to source code. 

Control 8.4 is a preventative control that modifies risk by establishing a set of underlying data access principles (in accordance with a Company wider set of access controls) that govern read/write access to:

1. Source code
2. Developmental tools
3. Software libraries

Scope

This policy applies to the employees who have direct access to source code in the Company.

Ownership of Control 8.4

Company has appointed CISO as the person responsible for this control because Control 8.4 deals with the Company’s ability to control access to business critical data relating to source code, development tools and commercially sensitive information such as software libraries. 

Process for complying with access to source code 

Control 8.4 advocates for a source code management system that allows Company to centrally administer access to and their amendment of source code across its ICT estate.

Control 8.4 asks Company to consider access to source code along a set of strict read and/or write privileges, based on the nature of the source code, where it’s being accessed from and who is accessing it.

When seeking to control access to source code, Company will:

1. Control access to source code in line with published procedures.
2. Provide read and/or write access to source code in conjunction with a set of clearly defined business requirements on a case-by-case or user-by-user basis.
3. Adhere to a clear set of change management procedures (see Control 8.32, Change Management) when administering access to source code, including proper authorisation based on a range of access variables (user type, business case etc).
4. Prevent the direct access of source code by developers, and instead provision access through a series of development tools that provide a top-down view of access rights and read/write privileges.
5. Provision a secure space to store program listings and read/write privileges.
6. Maintain a concurrent audit trail of all source code related activities, including user access timestamps and change-related activities.
7. Ensure that digital signatures are used for any piece of code that is to be published outside of the Company.

Supporting Control

Control 8.32 / Change Management

Technological Control No. 8.5

Secure Authentication

Purpose

This document addresses the Control 8.5 of ISO 27001:2022. Secure authentication is the primary method which human and non-human users engage with when attempting to utilise an Company Information and Communication Technology (ICT) assets.

Authentication technology has undergone a shift from traditional username/password-based validations into a variety of complementing techniques involving biometric information, logical and physical access controls, external device authentications, SMS codes and One Time Passwords (OTP).

27002:2022-8.5 puts all of this into context and advises Company on precisely how they should be controlling access to their ICT systems and assets via a secure login gateway. 

Scope

Control 8.5 is a preventative control that maintains risk by implementing technology and establishing topic-specific secure authentication procedures that ensure human and non-human users and identities undergo a robust and secure authentication procedure when attempting to access ICT resources.

Ownership of Control 8.5

Company has appointed CISO as the person responsible for this control because Control 8.5 deals with an Company’s ability to control access to its network (and the information and data contained within) at critical junctions, such as a login gateway. 

Process for complying with Secure Authentication 

Company authenticates controls that are relevant to the type and sensitivity of the data and network that’s being accessed, including:

1. Multi-factor authentication (MFA)
2. Digital certificates
3. Smart access controls (smart cards)
4. Biometric logins
5. Secure tokens

Company prevents and/or minimises the risk of unauthorised access to its protected systems by following the steps described below.

1. Restrict the display of information until after a successful authentication attempt.
2. Display a warning pre-logon which clearly states that information should only be accessed by authorised users.
3. Minimise the assistance it provides to unauthenticated users who are attempting to access the system e.g. Edge Services and Solutions LLC doesn’t not divulge which specific part of a login attempt is incorrect, such as a biometric aspect of an Multi-Factor Authentication (MFA) login and instead simply states that the login attempt has failed.
4. Validate the login attempt only when all required information has been provided to the login service, to maintain security.
5. Implement industry-standard security measures that protect against blanket access and/or brute force attacks on login portals. These measures include:
   1. CAPTCHA controls
   2. Enforcing a password reset after a set amount of failed login attempts
   3. Preventing further login attempts following a predefined number of failed attempts
6. Recording all failed login attempts for auditing and security purposes, including their use in criminal and/or regulatory proceedings.
7. Initiating a security incident whenever a major login discrepancy is detected, such as a perceived intrusion. In these cases, all relevant internal personnel should be notified, particularly those with systems administrator access or any ability to combat malicious login attempts.
8. Upon validating a login, relay certain pieces of information to a separate data source that list:
   1. The date and time of the previous successful logon
   2. A list of all login attempts since the last validated logon
9. Display passwords as asterisk’s (or similarly abstract symbols), where there is no pressing need not to do so (e.g. user accessibility).
10.  Strictly prohibit the sharing of or display of passwords as clear, legible text.
11.  Maintain a policy of terminating dormant login sessions after a specific period of time. This is particularly relevant for sessions that are active in high risk locations (remote working environments) or on user-supplied assets such as personal laptops or mobile phones.
12.  Limiting the amount of time that an authenticated session can remain open – even when active – relative to the information that’s being accessed (i.e. business critical information or financially sensitive applications).

Supporting Control

1. Control 8.32 / Change Management

Technological Control No. 8.6

Capacity Management Policy

Purpose

This policy addresses the Control 8.6 of ISO 27001:2022. The purpose of this policy is to set out Company processes for capacity management to ensure that the capacity of IT infrastructure, human resources and other facilities is able to deliver the agreed service level targets in a cost-effective and timely manner.

The objectives of the capacity management policy are to:

• Assure that required resources (IT infrastructure, human and facilities) are planned and scheduled to match the current and future needs of the business.
• Ensure the architecture of ICT infrastructure and services is appropriately designed to provide approved minimum required capacity and performance levels to the business.
• Ensure reporting and monitoring processes are in place to analyze and measure capacity levels.
• Reduce incidents caused by capacity issues.
• Apply cost effective measures and efficiencies to capacity management processes.

Scope:

The scope of this document covers Company’s ICT infrastructure capacity (network, bandwidth, storage, processor, memory, database, etc.) and the capacity of human resources as well as offices and facilities supporting Company’s business requirements and services, according to the ISMS Scope. 

Control 8.6 is a dual-purpose preventative and detective control that maintains risk by implementing detective controls which identify and maintain adequate capacity for processing information across the Company.

Ownership of Control 8.6

Control 8.6 deals with an organisation’s ability to operate as a business on an ongoing basis. As such, ownership should reside with the Chief Operating Officer (or organisational equivalent), with responsibility for the day-to-day integrity and efficiency of an organisation’s business functions.

CAPACITY MANAGEMENT POLICY

Capacity management ensures that the information technology processing and storage capacity is adequate for the evolving requirements of Company as a whole, in a timely and cost justifiable manner. Company considers the following items in capacity management: 

• Capacity requirements are identified, taking into account the business criticality of the concerned systems. 
• System tuning and monitoring are applied to ensure, and where necessary, improve the availability and efficiency of systems.
• Monitoring controls are in place to indicate problems in due time. 
• Projections of future capacity requirements take into account new business requirements, and current projected trends in information processing capabilities.
• ICT resources, including hardware, network, peripherals, software and human resources are cost effectively managed to meet current and future business requirements. 
• IT infrastructure capacity is managed to eliminate unexpected service failures within the business due to capacity outages.  
• Limits and thresholds are applied to all resources in order to trigger action for the review and update of resources to meet business requirements. Minimum configuration standards/requirements for all ICT resources are to be documented.

PROCESS DETAILS

IT Capacity Management

IT Capacity Management ensures sufficient resources are available to fulfil future business IT environment capacity requirements. Company manages its future IT environment capacity requirements by considering the following:  

• Trend analysis is performed on current resource utilization per service to model and predict future capacity requirements. 

The above findings are documented (where required) and approved by the Management to ensure sufficient budget is allocated to cater for future capacity requirements.

Company monitors infrastructure resource capacities manually. The reports include all infrastructure components such as servers, applications, bandwidth, backup and restore resources. The IT Administrator is responsible for analyzing the capacity requirements for ICT, and taking action required for changes to infrastructure resources. 

Resource Capacity Management

Resource capacity management involves managing the capacity of human resources, as well as offices and facilities (excluding IT infrastructure facilities). It ensures that all resources are monitored, reported and replenished in order to service business requirements.

The capacity required for human resources, offices and facilities is reviewed as required by Human Resources.

General guidance points:

1. Company considers business continuity as a top priority when implementing capacity management controls, including the wholesale implementation of detective controls that flag up potential issues before they occur.
2. Capacity management is based upon the proactive functions of tuning and monitoring. Both of these elements work in harmony to ensure that systems and business functions are not compromised.
3. In operational terms, Company performs regular stress tests that interrogate a systems ability to cater to overall business needs. Such tests are formulated on a case-by-case basis and be relevant to the area of operation that they are targeted at.
4. Capacity management controls should not be limited to Company’s current data or operational needs, and should include any plans for commercial and technical expansion (both from a physical and digital perspective) in order to remain as future-proof as is realistically possible.
5. Expanding organisational resources is subject to varying lead times and costs, depending on the system or business function in question. Resources that are more expensive and more difficult to expand should be subject to a higher degree of scrutiny, in order to safeguard business continuity.
6. Senior Management should be mindful of single points of failure relating to a dependency on key personnel or individual resources. Should any difficulties arise with either of these factors, it can often lead to complications that are markedly more difficult to rectify.
7. Formulate a capacity management plan that deals specifically with business critical systems and business functions.

Managing Demand

27002:2022-8.6 advocates for a dual-fronted approach to capacity management that either increases capacity, or reduces demand upon a resource, or set of resources.

When attempting to increase capacity, Company

1. Considers hiring new employees to carry out a business function.
2. Purchase, lease or rent new facilities or office space.
3. Purchase, lease or rent additional processing, data storage and RAM (either on-premises or cloud-hosted).
4. Consider using elastic and scalable cloud resources that expand with the computational needs of the organisation, with minimal intervention.

When attempting to reduce demand, Company

1. Deletes obsolete data to free up storage space on servers and attached media.
2. Securely disposes off any hard copies of information that the Company no longer needs, and is not legally required to obtain, either by law or via a regulatory body.
3. Decommission any ICT resources, applications or virtual environments that are no longer required.
4. Scrutinises scheduled ICT tasks (including reports, automated maintenance functions and batch processes) to optimise memory resources and reduce the storage space taken up by output data.
5. Optimizes any application code or database queries that are run on a regular enough basis to have an effect on the Company’s operational capacity.
6. Limits the amount of bandwidth that is allocated to non-critical activities within the boundaries of the Company’s network. This can include restricting Internet access and preventing video/audio streaming from work devices.

Evaluation

This policy will be reviewed annually by the Information Security Team to ensure compliance with applicable legal requirements and ISO 27001:2022 controls.

Technological Control No. 8.7

Protection against Malware Policy

Purpose

This Policy addresses the Control 8.7 of ISO 27001:2022. Control 8.7 is a triple-purpose preventive, detective and corrective control that maintains risk by implementing policies and procedures that ensure a Company’s information, data and assets are protected against malware.

Malware represents the single largest threat to business continuity and information security faced by businesses in the digital age.

The global commercial community faces innumerable daily threats from a broad range of attack vectors that seek to gain unauthorized access to sensitive systems and data, extract information and money, dupe unassuming employees and leverage ransomed data for extortionate sums of money. Company’s approach to malware protection should be front and centre of any information security policy.

Control 8.7 contains an array of measures that helps organizations to educate their employees as to the dangers of malicious software, and implement meaningful practical measures that stop internal and external attacks before they have a chance to cause disruption and data loss.

Scope

The Protection against Malware policy applies to Company that serves the varying demands of the IT industry that uses Company Information Resources.

Ownership

Whilst malware protection involves practical steps that need to be taken by ICT admin staff and standard users, the topic itself is wide-ranging and encompasses multiple distinct business functions with differing levels of risk and numerous additional ISO controls. As such, ownership of Control 8.7 should reside with the Chief Information Security Officer, or organizational equivalent. 

Guidance on compliance with the Policy

1. Following Control 8.7 Company has adopted an approach to malware protection that encompasses four key areas:
   1. Anti-malware software
   2. Company information security awareness (user training)
   3. Controlled systems and account access
   4. Change management

ISO categorically points out that it is a mistake to assume that anti malware software alone represents an adequate set of measures. Following the guidance provided by Control 8.7 Company has taken an end-to-end approach to malware protection that begins with user education and ends with a tightly-controlled network that minimizes the risk of intrusion across a variety of attack vectors.

To achieve this goal, Company has implemented controls that:

1. Prevent the use of unauthorized software (see Controls 8.19 and 8.32).
2. Block traffic to malicious or inappropriate websites.
3. Minimize the amount of Vulnerabilities resident on their network that have the potential to be exploited by malware or malicious intent (see Controls 8.8 and 8.19).
4. Carry out regular software audits that scan the network for unauthorized software, system amendments and/or data.
5. Ensure that data and applications are obtained with minimal risk, either internally or as an external acquisition.
6. Establish a malware detection policy that includes regular and thorough scans of all relevant systems and files, based on the unique risks of each area to be scanned. Company has adopted a ‘defence in depth’ approach that encompasses endpoint devices and gateway controls, and takes into consideration a broad range of attack vectors (e.g. ransomware).
7. Protect against intrusions that emanate from emergency procedures and protocols – especially during an incident or high-risk maintenance activities.
8. Draft a process that allows for technical staff to disable some or all anti malware efforts, especially when such activities are hampering the organization’s ability to do business.
9. Implement a robust BackUp and Disaster Recovery (BUDR) plan that allows the organization to resume operational activity as quickly as possible, following disruption (see Control 8.13). This should include procedures that deal with software which isn’t able to be covered by anti-malware software (i.e. machinery software).
10.  Partition off areas of the network and/or digital and virtual working environments that may cause catastrophic disruption in the event of an attack.
11.  Provide all relevant employees with anti-malware awareness training that educates users on a broad range of topics, including (but not limited to):
    1. Social engineering
    2. Email security
    3. Installing malicious software
12.  Collect industry-related information about the latest developments in malware protection.
13.  Ensure that notifications about potential malware attacks (particularly from software and hardware vendors) originate from a trusted source and are accurate.

Supporting Controls

• 8.13 / Information backup

• 8.19 / Installation of software on operational systems

• 8.32 / Change management.
• 8.8 / Management of technical vulnerabilities

Technological Control No. 8.8

Management of Technical Vulnerabilities Policy

Introduction

This Policy addresses the Control 8.8 of ISO 27001:2022. Control 8.8 contains a sizeable amount of advice that helps Company to prevent the internal and external exploitation of vulnerabilities across their entire network. Control 8.8 relies on supporting procedures and guidelines from numerous other ISO 27002:2022 controls, particularly those that relate to change management (see Control 8.32) and access control protocols

Control 8.8 is a preventive control that maintains risk by implementing procedures which gather information about technical vulnerabilities and allow the organization to take appropriate measures to safeguard assets, systems, data and hardware.

Scope

The Management of Technical Vulnerabilities Policy applies to Company that serves the varying demands of the IT industry that uses Company Information Resources.

Ownership of Control 8.8

Control 8.8 deals with the technical and administrative management of software, systems and ICT assets. Some of the guidelines involve deploying a highly-detailed approach to software management, asset management and network security auditing. So, ownership of Control 8.8 should reside with the individual who holds overall responsibility for maintaining the organization’s ICT infrastructure, such as the Head of IT, or organizational equivalent. 

Malware is any code or software that may be harmful or destructive to the information processing capabilities of the organization and is one of the primary tools used by attackers to circumvent security in order to make some kind of gain or to disrupt the normal operation of the business.

It is essential that effective precautions are taken by Company to protect itself against this threat which can come from a number of sources including organized gangs, competitor organizations, politically motivated groups, rogue employees, nation state sponsored “cyber-warfare” units or simply individuals exercising curiosity or testing their skills.

Whatever the source, the result of a successful security breach is that the organization and its stakeholders are affected, sometimes seriously, and harm is caused.

Malware comes in many forms and is constantly changing as previous attack routes are closed and new ones are found.

In order for malicious software to carry out its intended purpose it needs to be installed on the target device or computer. There are a number of key ways in which malware infects computers and networks, although new ways are being created all the time.

The most common infection techniques are as follows.

1. Phishing
2. Websites and Mobile Code
3. Removable Media
4. Hacking

But in order for these techniques to be used by an attacker, they must take advantage of Vulnerability in our defence.

This document sets out the Company’s policy on how it will assess and manage technical vulnerabilities within the IT environment, which includes the cloud services it uses. Its intended audience is IT and information security management and support staff who will implement and maintain the organization’s defence.

This control applies to all systems, people and processes that constitute the organization’s information systems, including top management, employees, suppliers and other third parties who have access to Company systems.

• Identifying Vulnerabilities

Prior to implementing and vulnerability controls, it’s essential to obtain a complete and up-to-date list of physical and digital assets (see Controls 5.9 and 5.14) that are owned and operated by the Company. Software asset information should include:

1. Vendor name
2. Application name
3. Version numbers currently in operation
4. Where the software is deployed across the estate?          

When attempting to pinpoint technical vulnerabilities, Company will

1. Clearly outline who (within the Company) is responsible for vulnerability management from a technical perspective, in accordance with its various functions, including (but not limited to):

• Asset management
• Risk assessment
• Monitoring
• Updating

1. Who is responsible for the software within Company?
2. Maintains an inventory of applications and resources that will be used to identify technical vulnerabilities.
3. Ask suppliers and vendors to disclose vulnerabilities upon the supply of new systems and hardware (see Control 5.20), and specify as such in all relevant contracts and service agreements.
4. Makes use of vulnerability scanning tools, including patching facilities.
5. Carries out regular, documented penetration tests – either internally or via a certified third-party.
6. Be mindful of the use of third-party code libraries and/or source code for underlying programmatic vulnerabilities (see Control 8.28).

Guidance – Public Activities 

In addition to internal systems, Company develops policies and procedures that detect vulnerabilities across all its products and services, and receive vulnerability assessments relating to the supply of said products and services.

As per the advice of ISO Company makes a public effort to track down any vulnerabilities, and encourage third-parties to engage in vulnerability management efforts through the use of bounty programs (where exploits are looked for and reported to the organisation for a reward).

Company makes itself a member of public forum, public email addresses and research activity so that the collective knowledge of the wider public can be used to safeguard products and services at source.

Where remedial action has been taken that affects users or customers, Company considers releasing relevant information to the affected individuals or organisations, and engage with specialist security organisations to disseminate information about vulnerabilities and attack vectors.

In addition, Company considers offering an automatic update procedure that customers are able to opt in or out of, based on their business needs.

Management of Technical Vulnerabilities Policy

What is a Technical Vulnerability?

A vulnerability is commonly defined as “an inherent weakness in an information system, security procedures, internal controls, or implementation that could be exploited by a threat source.”

The software development process is complicated and its output in the form of software programs is rarely bug free. Most of these bugs simply affect the functionality of the software so that it doesn’t work as intended. However, if manipulated in the correct way, some can allow an attacker to gain some form of advantage or access which was not intended by the developer. This type of bug is considered to be a software vulnerability.

These vulnerabilities are constantly being found and corrected via software updates or patches. Unfortunately it is not always the developer or user who discovers these vulnerabilities. When discovered by a potential attacker the vulnerability becomes something to be exploited for gain and kept secret for as long as possible. A newly-discovered vulnerability is often referred to as a “zero day exploit” and is difficult to defend against.

Company policy with respect to technical vulnerabilities is to be aware of them and to close them where possible, either directly or via other means.

Sources of Information

The first step in managing technical vulnerabilities is to become aware of them. Since we are talking about technical vulnerabilities these will of course depend upon the technology employed within the organization. It is necessary then to gain a full appreciation of the technology components that make up the organization’s infrastructure and their versions (since most technical vulnerabilities are very version-specific).

This should include:

• Operating systems e.g. Windows, UNIX, Cisco
• Databases e.g. SQL Server, MySQL
• Web servers e.g. IIS, Apache
• Desktop software e.g. Office, Acrobat
• Web technologies e.g. Flash, Java
• Application software e.g. SAP, Agresso (financial software)
• Hardware e.g. servers, routers

Information about vulnerabilities with any of the above components is generally available from the vendor who will issue updates and patches to fix those that it becomes aware of.

A process should therefore be put in place to ensure that all relevant information about updates is being received and reviewed by competent staff members. This will usually give guidance about the level of urgency associated with each update.

Where configuration changes are recommended to close off vulnerabilities, these should be actioned through the organization change management process so that appropriate controls are in place for testing, risks assessment and back out.

For Cloud Services, the responsibilities of the Cloud Service Provider (CSP) and Company as the Cloud Service Customer, should be defined and agreed. This may involve the CSP being responsible for vulnerability assessment and patching for some or all aspects of the service, depending on the cloud service model adopted (e.g. IaaS, PaaS or SaaS or similar service definitions).

Patches and Updates

Patches and updates will typically be issued by software vendors on a regular schedule as cumulative packages. These will be linked to the specific version of software that they relate to and may have dependencies stipulated with other software modules, products or operating systems.

Procedures should be put in place to obtain copies of the software updates electronically when they are issued by the vendor. The scheduling of the installation of updates will depend upon a number of factors including:

• The criticality of the systems being updated
• The expected time taken to install the updates (and requirements for service outages to users)
• The degree of risk associated with any vulnerabilities that are closed by the updates
• Co-ordination of the updating of related components of the infrastructure
• Dependencies between updates

An update release plan should be created and maintained to keep track of when various system will be updated, taking into account the factors listed above. The plan must be managed through the change management process. For updates that are low risk and regular, a standard change may be defined within the change management process to allow this to happen without excess administrative overhead (see Change Management Process).

Vulnerability Assessment

In addition to the regular application of vendor-supplied software updates, Company will conduct a vulnerability assessment at least once a year. The focus of the vulnerability assessment should be guided by the most recent risk assessment.

The purpose of this assessment is to identify existing vulnerabilities in systems that could be exploited by an attacker. These could include known software vulnerabilities that have not been patched, configuration errors that need to be corrected or examples of inadequate security practice that need to be addressed.

The assessment may be carried out in-house, by an external company or a combination of both and as a minimum should cover:

1. Assessment of the security of all routes into the organization’s internal network from the Internet
2. Externally-facing web servers
3. Business critical servers on the internal network
4. A selection of typical user computers

If resources permit, additional areas should be assessed such as the vulnerability of employees to phishing attacks.

It is not the organization’s policy to attempt to exploit the vulnerabilities found as a matter of course. This type of penetration test may be commissioned as required using external specialist resources as part of a carefully planned exercise performed outside of normal business hours. The permission of cloud or hosting providers must be obtained prior to testing starting.

Hardening

A further action that should be taken to reduce the number and extent of vulnerabilities within Company is the hardening of server and other device configurations. This involves the shutting down of services and protocols that are not needed so that the attack surface is reduced.

These hardening activities should be carried out according to vendors’ guidelines and under the control of the change management process.

Awareness Training

As a result of vulnerability assessment it may be necessary to increase efforts in security awareness training for employees and contract staff. This training should explain the nature of vulnerabilities and what can be done to reduce them.

Technological Control No. 8.9

Configuration Management Policy

Purpose

This policy addresses the control 8.9 of ISO 27001:2022. Control 8.9 is a preventative control that maintains risk by establishing a series of policies that govern how the Company’s documents, implements, monitors and reviews the use of configurations across its entire network. 

Scope

This policy applies to all configurations of Company’s or its customer’s configurations and that use IT Infrastructure to provide customer services.

These Configurations, whether acting as a single config file, or a group of configurations linked together, are the underlying parameters that govern how hardware, software and even entire networks are managed.

As an example, a firewall’s configuration file will hold the baseline attributes that the device uses to manage traffic to and from Company’s network, including block lists, port forwarding, virtual LANs and VPN information.

Configuration management is an integral part of Company’s broader asset management operation. Configurations are key in ensuring that a network is not only operating as it should be, but also in securing devices against unauthorised changes or incorrect amendments on the part of maintenance staff and/or vendors.

Ownership of Control 8.9

Configuration management is solely an administrative task that deals with the maintenance and monitoring of asset-side information and data that is resident on a broad range of devices and applications. As such, ownership should reside with the Head of IT, or Company’s equivalent. 

Methodology of meeting the requirements

Company drafts and implements configuration management policies for both new systems and hardware, and any that are already in use. Internal controls are included for all business critical elements such as security configurations, all hardware that holds a configuration file and any relevant software applications or systems.

As per Control 8.9 Company considers all relevant roles and responsibilities when implementing a configuration policy, including the delegated ownership of configurations on a device-by-device, or application-by-application basis.

Preparation of Standard Templates

Company uses standardised templates to secure all hardware, software and systems. Templates satisfy the following conditions:

1. Company attempts to utilise publicly available, vendor-specific and/or open source guidance on how best to configure hardware and software assets.
2. Meets minimum security requirements for the device, application or system that they are applicable to.
3. Works in harmony with the Company’s broader information security efforts, including all relevant ISO controls.
4. While developing these templates Company keeps in mind the Company’s unique business requirements – especially where security configurations are concerned – including how feasible it is to apply or manage a template at any given time.
5. Company reviews the various configuration files at appropriate intervals in order to cater for system and/or hardware updates, or any prevailing security threats.

Security Controls in Configuration Management

Security is paramount when applying configuration templates, or amending existing templates in line with the above guidance. In order to minimise any information security risks when using standard templates for use across the Company, following rules are applied.

1. Keeps the number of users with administrator privileges to a minimum.
2. Disables any unused or unnecessary identities.
3. Closely monitors access to maintenance programs, utility applications and internal settings.
4. Ensures that clocks are synchronised in order to log configuration correctly, and assist in any future investigations.
5. Immediately changes any default passwords or default security settings that are supplied with any device, service or application.
6. Implements a default logoff period for any devices, systems or applications that have been left dormant for a specified period of time.
7. Ensures that all licensing requirements have been met (see Control 5.32 / Intellectual Property Rights).

Company to showcase the configuration details of the configurable items in the IT set up.

Technological Control No. 8.10

Information Deletion

Purpose

This document addresses the control 8.10 of ISO 27001:2022. Control 8.10 is a preventative control that modifies risk by outlining an approach to data deletion that complements the Company’s existing data retention policies, and keeps them compliant with any prevailing laws or regulatory guidelines. 

Scope

This policy applies to all data stored in the various devices of Company’s or its customer’s devices and that use IT Infrastructure to provide customer services.

This policy also applies to managing the ongoing use of data and information on internal servers and storage devices (HDDs, arrays, USB drives etc.). Company’s needs to be accurately aware of their obligations towards removing and deleting any data held on employees, users, customers or organisations when it is reasonably necessary to do so (usually when it is no longer needed).

Ownership of Control 8.10

Control 8.10 largely deals with maintenance tasks relating to the deletion and destruction of data and/or IT assets, including the use of specialised software and liaising with vendors who specialise in data and device deletion. As such, ownership should reside with the Head of IT, or organisational equivalent. 

Methodology of meeting the requirements

General Guidance 

Company (as per the directions of Control 8.10) deletes data when it is no longer required or is necessary, in order to minimise what is referred to as undesirable disclosure (i.e. data being viewed by, or passed on to, individuals and organisations that are not authorised to access it).

1. Company opts for an appropriate deletion method that fulfils any prevailing laws or regulations. Techniques include standard deletion, overwriting or encrypted deletion.
2. Company logs the results of the deletion for future reference.
3. Ensures that, if a specialised deletion vendor is used, the Company obtains adequate proof (usually via documentation) that the deletion has been carried out.
4. If a third-party vendor is being used, Company stipulates their precise requirements, including deletion methods and timescales and ensures that deletion activities are covered under a binding agreement.

Guidance – Specific Deletion Methods

1. Configures internal systems to delete data and information in accordance with the Company’s topic-specific policy on retention.
2. Ensures that deletion extends to temporary files, cached information, copies of data and legacy versions.
3. Considers using specialised deletion utility applications to minimise risk.
4. Only contracts out to certified, verifiable deletion specialists, if the need arises to use a third-part service.
5. Implements physical deletion measures that are appropriate to the device in question (e.g. degaussing magnetic storage media, restoring factory settings on a smartphone or physical destruction) (see Control 7.14).
6. Ensures that cloud service providers are aligned with the Edge Services and Solutions LLC’s own deletion requirements (as far as is possible).

Supplementary Information on Control 8.10

When shipping equipment (notably servers and workstations) to vendors, Company removes any internal or external storage devices before doing so.

Supporting Guidelines

1. 7.14 / Secure disposal or re-use of equipment

Technological Control No. 8.11

Data Masking

Purpose

This policy addresses the control 8.11 of ISO 27001:2022. Data masking is a technique used to protect sensitive data, usually any data that could be deemed Personally Identifiable Information (PII) over and above the Company’s standard information security protocols such as access control etc. Control 8.11 is a preventive control that modifies risk by suggesting a series of data masking techniques which safeguard PII, and helps the Company to remain compliant with what’s asked of it by legal authorities and regulatory agencies.

Data masking is often mentioned in legal, statutory and regulatory guidelines and laws governing the storage and access of employee, customer, user and vendor information. 

Scope

This policy applies to all Personally Identifiable Information data handled by Company that uses IT Infrastructure to provide customer services.

Ownership of Control 8.11

Data masking is a complex technical process that involves altering sensitive information, and preventing users from identifying data subjects through a variety of measures.

Whilst this is itself an administrative task, the nature of data masking is directly related to Company’s ability to remain compliant with laws, regulations and statutory guidelines concerning the storage, access and processing of data. As such, ownership should reside with the Chief Information Security Officer, or Company equivalent.

Methodology of meeting the requirements

Following the direction of Control 8.11, Company considers data masking through the scope of two main techniques – Pseudonymisation and/or Anonymisation. Both of these methods are designed to disguise the true purpose of PII through disassociation – i.e. hiding the link between the raw data, and the subject (usually a person). Company takes great care to ensure that no single piece of data compromises the data subject’s identity.

When using either of these techniques, Company considers:

1. The level of Pseudonymisation and/or Anonymisation required, relative to the nature of the data.
2. How the masked data is being accessed?
3. Any binding agreements that restrict use of the data to be masked.
4. Keeping the masked data separate from any other data types, in order to prevent the data subject being easily identified.
5. Logging when the data was received, and how it has been provided to any internal or external sources.

Guidance – Additional Techniques for Pseudonymisation and Anonymisation

In addition to Pseudonymisation and Anonymisation to mask PII or sensitive data. Control 8.11 outlines 5 other methods that can be used to Bolster (Bolster is one of the few security products where we get immediate visibility of counterfeit websites and more importantly, immediate response for takedowns) data security:

1. Key-based encryption: An encryption key is typically a random string of bits generated specifically to scramble and unscramble data. Encryption keys are created with algorithms designed to ensure that each key is unique and unpredictable. The longer the key constructed this way, the harder it is to break the encryption code.
2. Voiding or deleting characters within the dataset 
3. Varying numbers and dates.
4. Replacing values across the data.
5. Hash-based value masking: Hashing is the process of transforming any given key or a string of characters into another value. This is usually represented by a shorter, fixed-length value or key that represents and makes it easier to find or employ the original string.

Guidance – Data Masking Principles

Data masking is an important part of a Company’s policy towards protecting PII and safeguarding the identity of the individuals whom it holds data on.

Company considers the below suggestions when strategizing it’s approach to data masking:

1. Implement masking techniques that only reveal the minimum amount of data to anyone who uses it.
2. ‘Obfuscating’ (hiding) certain pieces of data at the request of the subject, and only allowing certain members of staff to access the sections that are relevant to them.
3. Building it’s data masking operation around specific legal and regulatory guidelines.
4. Where Pseudonymisation is implemented, the algorithm that is used to ‘de-mask’ the data is kept safe and secure.

Methods available for data masking are Key based encryption, Voiding or deleting characters within the dataset, Cryptographic Hash Function, Counter, Random Number Generator, Message Authentication Code and Encryption.

Technological Control No. 8.12

Data Leakage Prevention

Purpose

This document addresses the control 8.12 of ISO 27001:2022. Data leakage can broadly be described as any information that is accessed, transferred or extracted by unauthorised internal and external personnel and systems, or malicious sources that target Company information operation.

Data leakage is a common problem within Company’s that deal with large amounts of data, of different classifications, across multiple standalone and linked Information and Communication Technology (ICT) systems, applications and file servers. 

Control 8.12 is a dual-purpose preventive and detective control that modifies risk by implementing technical measures that proactively detect and prevent the disclosure and/or extraction of information, either by internal and/or external personnel, or logical systems.

Scope

This policy applies to the preservation of data used by the Company and it’s employees during the services rendered to customer.

Ownership of Control 8.12

Control 8.12 deals with ICT operations that are performed using system administrator access, and fall under the umbrella of network management and maintenance. As such, ownership of Control 8.12 rests with the Head of IT, or Company equivalent. 

Methodology of meeting the requirements

Data leakage is difficult to eradicate entirely. However, to minimise the risks that are unique to their operation, Company will:

1. Classify data in line with recognised industry standards (PII, commercial data, product information) in order to assign varying risk levels across the board.
2. Closely monitor known data channels that are heavily utilised and prone to leakage (e.g. emails, internal and external file transfers, USB devices).
3. Take proactive measures to prevent data from being leaked (e.g. robust file permissions and adequate authorisation techniques).
4. Restrict a user’s ability to copy and paste data (where applicable) to and from specific platforms and systems.
5. Require authorisation from the data owner prior to any mass exports being carried out.
6. Consider managing or preventing users from taking screenshots or photographing monitors that display protected data types.
7. Encrypt backups that contain sensitive information.
8. Formulate gateway security measures and leakage prevention measures that safeguard against external factors such as (but not limited to) industrial espionage, sabotage, commercial interference, and/or IP theft.

Data leakage prevention is linked to numerous other ISO security guidelines that seek to safeguard information and data across an Company’s network, including Access Control measures (see Control 5.12 / Classification of Information) and secure document management (see Control 5.15 / Access Control).

Guidance – Data Leakage Tools

Company considers using dedicated data leakage tools and utility programs that:

1. Work in tandem with the Company’s approach to data classification, and identify the potential for leakage within high-risk data types.
2. Detect and proactively alert upon the transfer and/or disclosure of data, especially to unauthorised systems, file sharing platforms or applications.
3. Recognise the risks inherent within certain data transfer methods (e.g. copying financial information from a database into a spreadsheet).

Data leakage prevention tools are intrusive by their very nature, and should be implemented and managed in accordance with any regulatory requirements or legislation that deals with user privacy.

Supporting Controls

1. 5.12 / Classification of Information
2. 5.15 / Access Control

Examples of DLP Tools

1. Digital Guardian DLP
2. Forcepoint DLP
3. GTB Technologies DLP as a Service
4. Palo Alto Networks Enterprise DLP
5. Symantec Data Loss Prevention by Broadcom
6. Trellix Data Security (formerly McAfee)
7. Zscaler Cloud DLP

Technological Control No. 8.13

Information Backup

Purpose

This document addresses the control 8.13 of ISO 27001:2022. Control 8.13 is a corrective control that maintains risk by implementing policies which enable timely recovery from data and/or system loss or interruption.

Scope

This policy applies to the backup of data generated and used by the Company and it’s employees during the services rendered to customer.

Company backup operations encompasses a broad range of efforts that improve resilience and protect against loss of business by establishing a robust and tightly managed set of backup jobs using dedicated software and utilities with adequate retention levels and agreed upon recovery times.

Control 8.13 advocates for a topic-specific approach to backups that includes bespoke processes for each individual topic, and takes into account the different types of data (and associated risk levels) that Company’s process and access throughout their operation.

Ownership of Control 8.13

Control 8.13 deals with daily backup operations that should be handled by technical support staff with responsibility for the maintenance of the Company’s network.

As such, ownership of Control 8.13 should reside with the individual responsible for the Company’s day-to-day ICT operation, or the person who oversees an outsourced ICT contract.

Methodology of meeting the requirements

Company has drafted topic-specific policies that directly address how the Company backs up the relevant areas of its network.

Backup facilities are implemented with the primary aim of ensuring that all business critical data, software and systems are able to be recovered following the below events:

1. Data loss
2. Intrusion
3. Business interruption
4. Failure of systems, applications or storage media

Company has created a backup in accordance with Control 8.13 with the following aims.

1. Outline clear and concise restoration procedures that cover all relevant critical systems and services.
2. Produce workable copies of any systems, data or applications that are covered under a backup job.
3. Meet the unique commercial and operational requirements of the Company (e.g. recovery time objectives, backup types, backup frequency) (see Control 5.30 / ICT readiness for business continuity).
4. Store backups in an appropriate location that is environmentally protected, physically distinct from the source data in order to prevent total data loss, and securely accessed for maintenance purposes (see Control 8.1 / User endpoint devices).
5. Mandated for regular testing of backup jobs, in order to guarantee data availability should the need arise to restore files, systems or applications at a moment’s notice. Backup tests should be measured against the Company’s agreed recovery times to ensure adherence in the event of data loss or system interruption.
6. Encrypt data that has been backed up in accordance with its risk level.
7. Check for data loss before running any backup jobs.
8. Implement a reporting system that alerts maintenance staff to the status of backup jobs – including complete or partial failures – so that remedial action can be taken.
9. Include data from cloud-based platforms that are not directly managed by the Company.
10. Store backup data in line with a topic-specific retention policy that takes into account the underlying nature and purpose of the data that’s been backed up, including transfer and/or archiving to storage media (see Control 8.10).

Supporting Controls

1. 5.30 / ICT readiness for business continuity
2. 8.1 / User endpoint devices
3. 8.10 / Information Deletion

Company has a document that shows how the information is backed up.

Technological Control No. 8.14

Redundancy in Information Processing Facilities

Purpose

This policy addresses the control 8.14 of ISO 27001:2022. Control 8.14 is a preventive control that maintains risk by implementing plans and procedures that maintain the continuous operations of information processing facilities, and by proxy, Company entire ICT network.

Scope

This policy applies to the redundancy in information processing facilities of the Company for the services rendered to customer.

An ‘Information Processing Facility’ (IPF) is a broad term used to describe any piece of ICT infrastructure that’s involved in processing data, such as IT equipment, software and physical facilities and locations.

IPFs play a key role in maintaining business continuity and ensuring the smooth operation of Company’s ICT network(s). To increase resilience, Company need to implement measures that increase the redundancy of their IPFs – i.e. fail safe methodologies and processes that mitigate risk to systems and data in the event of failure, misuse or intrusion.

Ownership of Control 8.14 

Control 8.14 addresses Company’s ability to carry on doing business in the event of critical or minor failures that have the potential to impact resiliency. As such, ownership of 8.14 should reside with the Chief Operating Officer, or Company equivalent. 

Methodology of meeting the requirements

The overriding goal of Control 8.14 is to increase the availability of what ISO deems to be business services and information systems, which can be interpreted as any aspect of a network that allows the Company to conduct business.

Control 8.14 advocates for duplication as the primary methods of achieving redundancy across its various IPFs, primarily through maintaining an inventory of spare parts, duplicate components (hardware and software) and additional peripheral devices.

A redundant system is only as good as its alerting facility. As such, Company ensures that failed IPFs are detected quickly, and remedial action is taken to either fail over to standby hardware, or to repair the malfunctioning IPF in as quick a time as possible.

When designing and installing redundancy measures, Company considered the following:

1. Entering into a commercial relationship with two separate service providers, to reduce the risk of blanket downtime in the event of a critical event (e.g. an Internet Service Provider or VoIP provider).
2. Adhering to redundancy principles when designing data networks (secondary Domain Controller (DC), redundant BackUp and Disaster Recovery (BUDR) systems etc.,).
3. Making use of geographically separate locations when contracting out data services, especially in the case of file storage and/or data centre facilities.
4. Purchasing power systems that have the ability to achieve redundancy either in whole or in part as is necessary.
5. Using load balancing and automatic fail over between two identical, redundant software components or systems, to improve both real time performance and resilience following a critical event. (This is of particular importance when considering an operational model that encompasses both public cloud services and on-premises services). Redundant systems are regularly tested (where possible) whilst in production mode to ensure that fail over systems are operating correctly.
6. Duplicating physical ICT components both within servers and file storage locations (Redundancy Array of Independent Disks (RAID arrays), CPUs), and any that act as a network device (firewalls, redundant switches). Firmware updates should be performed on all linked and redundant devices, to ensure continuity.

Supplementary Guidance 

Control 8.14 acknowledges the inherent link between robust, redundant systems and business continuity planning (see Control 5.30), and asks Company’s to consider both as part of the solution to the same set of challenges.

It’s important to note that where business applications are concerned, it is extremely difficult to cater for critical errors in the application itself (particularly in the case of managed applications).

Supporting Controls

1. 5.30 / ICT readiness for business continuity

Technological Control No. 8.15

Logging

Purpose

This document addresses the Control 8.15 of ISO 27001:2022. This document is used to establish requirements for the collection, maintenance and review of audit logs for application and related network resources, in support of identity management and threat monitoring. Company has defined the frequency as yearly for Audit Logging and Monitoring. Audit logs consist of information trails that are used to track and associate user and system activity to event. In conjunction with the appropriate tools and procedures, auditing can assist in detecting security violations, as well as performance problems and application flaws.

Scope

The scope of this document applies to:

• All servers and network devices that handle or accept network connections or make access control decisions, for any Company information 
• All google accounts (gmail, drive etc)
• Applications being used 

Roles and Responsibilities

Single Point of Contact: Responsible for the ingestion, management and correction of logs within Company’s environment is CISO.

Methodology

Security Audit Log Management

• Creation and Storage of Audit Logs – Audit logs is retained in sufficient detail to facilitate reconstruction of events and determination of the causes of compromise and magnitude of damage, in response to a malfunction or a security violation.
• Review and Analysis – Timely and effective review of audit logs is required to allow identification of security incidents, policy violations, fraudulent activity, and operational problems; while providing information useful for resolving such issues. 
• Establishment of Supporting Process and Resources- Processes and resources are established to support internal investigations, forensic analysis, establishment of baselines, and identification of operational trends and long-term issues.

Auditable Events

Auditable events are those activities that can be tracked that provide information regarding system resource usage. Company identifies the systems, applications, or processes that make data vulnerable to unauthorized or inappropriate tampering, uses or disclosures. For each identified system, application, or process. Company identifies user activities that need to be tracked and audited.

1. Successful and unsuccessful access to log files
2. Successful and unsuccessful authentication events
3. Successful and unsuccessful authorization events
4. Successful and unsuccessful resource access events
5. Successful and unsuccessful privileged operations
6. Creation, modification and deletion of user accounts, group accounts and objects including files, directories and user accounts
7. Creation, modification and deletion of command line changes, batch files changes and queries made to databases
8. Creation, modification and deletion of security policy
9. Changes to logical access control authorities (e.g., rights, permissions)
10.  System and/or applications shutdowns, reboots/restarts, errors

Content of Audit Records

Company’s information system shall at a minimum record the following information:

• Timestamp
• User ID / Domain
• Source IP address or application
• Application or service accessed
• Resource or complete URL
• Module/Function accessed
• Unique Action performed (Read/Update/Create/Delete)
• Primary record identifier
• Date field accessed/ updated

References

• ISO 27001:2022 – Control 8.15

Example of Event Logging Tools

1. SolarWinds Log Analyzer 
2. ManageEngine EventLog Analyzer 
3. Site24x7 Log Management
4. ManageEngine Log360 
5. Netwrix Event Log Manager
6. LogRhythm
7. Sumo Logic
8. Datadog

Technological Control No. 8.16

Monitoring Activities

Purpose

This policy addresses the control 8.16 of ISO 27001:2022. Control 8.16 is a dual-purpose detective and corrective control that modifies risk by optimising monitoring activities to identify anomalous behaviour and assists in the prompt analysis of information security events and incidents.

Scope

This policy applies to network monitoring of a successful IT support and information security operations of the Company. This proactive approach is vitally important for Company to promote a proactive approach to monitoring that seeks to prevent incidents before they happen, and works in tandem with reactive efforts to form an end-to-end information security and incident resolution strategy. 

Ownership of Control 8.16 

Control 8.16 deals with ICT operations that are performed using system administrator access, and fall under the umbrella of network management and maintenance. As such, ownership of Control 8.16 rests with the Head of IT. 

Methodology of meeting the requirements

Monitoring should be first and foremost activity carried out in line with any regulatory requirements or prevailing legislation, and any records retained in accordance with company retention policy.

Suspect events should be reported to all relevant personnel in order to maintain network integrity and improve business continuity alongside the following processes (see Control 5.25 / Assessment and decision on information security events in Incident management policy):

1. Auditing
2. Security and risk evaluation
3. Vulnerability scanning
4. Monitoring

Company includes the following in it’s monitoring operation:

1. Both inbound and outbound network traffic, including data to and from applications
2. Access to business critical platforms, including (but not limited to):
   1. Systems
   2. Servers
   3. Networking hardware
   4. The monitoring system itself
3. Configuration files
4. Event logs from security equipment and software platforms
5. Code checks that ensure any executable programs are both authorised and temper-free
6. Compute, storage and networking resource usage

Guidance – Behavioural Analysis 

Company gains a firm understanding of normal user activity and network behaviour, and use this as a baseline to identify anomalous behaviour across the network, including: 

1. Sudden closure or termination of processes and applications
2. Network traffic that is recognised as emanating to and/or from problematic IP addresses and/or external domains
3. Well-known intrusion methods (e.g. Distributed Denial of Service)
4. Malicious system behaviour (e.g. key logging)
5. Network bottlenecks and high ping and/or latency times
6. Unauthorised or unexplainable access to and/or scanning of data, domains or applications
7. Any attempts to access business critical ICT resources (e.g. domain controllers, DNS servers (DNS server is a computer server that contains a database of public IP addresses and their associated hostnames), file servers and web portals)
8. To establish a successful baseline, Company monitors network utilisation and access times at normal working levels.

Guidance – Monitoring tools

Security monitoring is optimised through:

1. Dedicated threat intelligence systems (see Control 5.7 / Threat Intelligence) and intrusion protection platforms
2. Machine learning platforms
3. Whitelists, blacklists, block lists and allow lists on IP management platforms and email security software
4. Combining logging and monitoring activities into one end-to-end approach
5. A dedicated approach to well-known intrusion methods and malicious activity, such as the use of botnets, or denial of service attacks

Supporting Controls

1. 5.7 / Threat Intelligence
2. 5.25 / Assessment and decision on information security events
3. 5.26 / Response to information security incidents

Technological Control No. 8.17

Clock Synchronization

Purpose

This document addresses the control 8.17 of ISO 27001:2022. Being able to rely upon a pinpoint accurate synchronised time across Company information systems is of paramount importance not only for the ongoing operation of a company’s commercial systems, but also in the event of an ICT-related incident.

Accurate time representation gives the Company the ability to provide itself and any law enforcement or regulatory bodies with a reliable account of how information has been managed, along with the actions of its employees and vendors. 

Control 8.17 is a dual-purpose detective control that maintains risk by implementing controls which maintain accurate and reliable synchronisation of information system clocks, to assist in internal and external investigations, and incident monitoring.

Scope

This policy applies to the clock synchronization used by the Company and it’s employees during the services rendered to customer.

Ownership of Control 8.17

Control 8.17 primarily deals with technical matters, in the form of external data sources (atomic clocks etc.) linked to Company’s ICT systems.

As such, ownership should reside with the Head of IT (or Company equivalent), with responsibility for the day-to-day integrity and efficiency of Company’s ICT infrastructure. 

Methodology of meeting the requirements

Following the guidance given by Control 8.17 Company has established a standard reference time (which is Pacific Standard Time for the Company) that is used across all commercial, logistical and maintenance-based systems as a trusted date and time source for all the Company’s needs.

Company

1. Has drafted internal and external requirements for three aspects of clock synchronisation:
   1. Time representation
   2. Reliable synchronisation
   3. Accuracy
2. When addressing said requirements, Company has addressed its needs from 6 separate angles:

1. Legal (laws that regulate business practices)
2. Statutory (laws framed by government)
3. Regulatory (GDPR, Payment Card Industry Data Security Standard (PCIDSS), HIPAA)
4. Contractual (observance of the norms and procedures outlined in a contract)
5. Standards (practice of adhering strictly to published standards)
6. Internal monitoring (Internal audits and MRM)
7. Guidance – Data Leakage Tools

1. Makes use of a radio time broadcast linked to an atomic clock as a singular reference point, alongside the implementation of key protocols (Network Time Protocol (NTP) and Precision Time Protocol (PTP) to ensure adherence across the network.
2. Considers managing two separate time sources to improve redundancy.

Time Synchronization in three different clouds

1. Amazon Time Sync is used by EC2 instances and other AWS services. It uses a fleet of redundant satellite-connected and atomic clocks in each Region to deliver time derived from these highly accurate reference clocks. This service is provided at no additional charge. 
2. Windows Time Service is used by Microsoft; it is designed to synchronize the clocks of computers on a network. The network time synchronization process, also called time convergence, occurs throughout a network as each computer accesses time from a more accurate time server.
3. Google Public NTP used by Google cloud serves leap-smeared time. This technology is used to smoothly handle leap seconds with no disruptive events. Google cloud has implemented Google Public NTP with their load balancers and our fleet of atomic clocks in data centres across the world.

Technological Control No. 8.18

Use of Privileged Utility Programs

Purpose

This policy addresses the control 8.18 of ISO 27001:2022. A utility program is any piece of software that is designed to analyse or maintain a computer system or network. Utility programs are essential to the smooth running of any given LAN or WAN and help network administrators to improve uptime and increase resilience across a broad range of commercial functions. Given their intrusive nature, utility programs also have the potential to cause a significant amount of damage on a given network, unless their use is properly monitored.

Control 8.18 is a preventive control that maintains risk by establishing guidelines that govern the use of any utility program that has the potential to override business critical system and application controls.

Scope

This policy applies to the use of privileged utility programs used by the Company and its employees during the services rendered to customer.

Ownership of Control 8.18

Control 8.18 deals primarily with the operation of back-end networking, maintenance and diagnostic tools. As such, ownership should reside with the person responsible for the Company’s IT infrastructure, such as the Head of IT. 

Methodology of meeting the requirements

Following the guidance of 9 main points offered by Control 8.18 Company monitors the use of utility programs across it’s network.

In order to maintain network integrity and support business continuity, Company will:

1. Restrict the use of utility programs to employees and IT maintenance staff who specifically require them to carry out their job role.
2. Ensure that all utility programs are identified, authenticated and authorised in line with business requirements, and management are able to gain a top down view of their use at any given time.
3. Identify all personnel who use utility programs, either as part of their daily duties, or on an ad-hoc basis.
4. Implement adequate authorisation controls for any employee who needs to use utility programs, either as part of their daily duties, or on an ad-hoc basis.
5. Prevent the use of utility programs on any system where the organisation has deemed it necessary to segregate duties.
6. Periodically review the use of utility programs, and either remove or disable any programs as the organisation requires.
7. Partition utility programs are distinct from standard applications that the business uses on a regular basis, including network traffic.
8. Restrict the availability of utility programs, and only use them for express purposes.
9. Log the use of utility programs, including timestamps and authorised users

Technological Control No. 8.19

Installation of Software on Operational Systems

Purpose

This policy addresses the control 8.19 of ISO 27001:2022. Operational software can broadly be described as any piece of software that the business actively uses to conduct its operation, as distinct from test software or development projects.

It is vitally important to ensure that software is installed and managed on a given network in accordance with a strict set of rules and requirements that minimise risk, improve efficiency and maintain security within internal and external networks and services.

Control 8.19 is a preventive control that maintains risk by establishing a set of rules that govern the installation of software on operational systems.

Scope

This policy applies to the installation of operational software actively used to conduct operations, as distinct from test software or development projects by the Company while delivering the services to customer.

Ownership of Control 8.19

Control 8.19 deals with technical concepts relating to the maintenance and management of operational computer systems. As such, ownership should rest with the Head of IT, or organisational equivalent. 

Methodology of meeting the requirements

In order to securely manage change and installations on their network, Company will

1. Ensure that software updates are only carried out by trained and competent personnel (see Control 8.5).
2. Only install robust executable code that’s free from any bugs and has safely exited the development stage.
3. Only install and/or update software after said update or patch has been successfully tested, and the organisation is confident that no conflicts or errors will ensue.
4. Maintain an up to date library system.
5. Utilise a ‘configuration control system’ that manages all instances of operational software, including program documentation.
6. Agree upon a ‘rollback strategy’ prior to any updates or installations, to ensure business continuity in the event of an unforeseen error or conflict.
7. Keep a log of any updates performed to operational software, including a summary of the update, the personnel involved and a timestamp.
8. Ensure that unused software – including all documentation, configuration files, system logs, supporting procedures – are securely stored for further use, should the need arise.
9. Enforce a strict set of rules on the type of software packages that users can install, based on the principles of ‘least privileged’ and in accordance with relevant roles and responsibilities.

Guidance – Vendor Software

Where vendor-supplied software is concerned (e.g. any software used in the operation of machinery or for a bespoke business function) such software is always kept in good working order by referring to the vendor’s guidelines for safe and secure operation.

It’s important to note that even where software or software modules are externally supplied and managed (i.e. the organisation is not responsible for any updates), steps should be taken to ensure that third party updates do not compromise on the integrity of the organisation’s network.

Company should avoid using unsupported vendor software unless absolutely necessary, and consider the associated security risks of utilising redundant applications as opposed to an upgrade to newer and more secure systems.

If a vendor requires access to Company’s network to perform an installation or update, activity should be monitored and validated in line with all relevant authorisation procedures (see Control 5.22).

Supplementary Guidance on Control 8.19

Software is upgraded, installed and/or patched in accordance with the Company’s published change management procedures, to ensure uniformity with other areas of the business.

Whenever a patch is identified that either totally eliminates a vulnerability (or series of vulnerabilities), or helps in any way to improve the organisation’s information security operation, such changes should almost always be applied (though there is still the need to assess such changes on a case-by-case basis).

Where the need arises to use open source software, this should always be of the latest publicly available version that is actively maintained. Accordingly, Company considers the inherent risks of using unmaintained software within all business functions.

Supporting Controls

1. 5.22 / Monitoring, review and change management of supplier services
2. 8.5 / Secure Authentication

Company follows the internal guidelines for the installation of operational software.

Technological Control No. 8.20

Network Security

Purpose:

This document addresses the Control 8.20 of ISO 27001:2022. This document represents the company-wide guidelines and responsibilities required to maintain acceptable and proper use of Company network resources and services. The intent of this policy is to educate users about their responsibilities regarding computing resources and services while identifying certain unacceptable uses of network resources and services. Control 8.20 is a series of broad protocols that deal with the concept of network security as a governing principle in all its various forms, and draws on guidance from several major information security controls across ISO 27002.

Scope

This document covers all computer and communication equipment owned or operated by Company including all equipment attached to or using Company resources. Explicit in the above statement is that this document also includes ANYONE using Company computer and/or communications equipment and/or ANYONE accessing and/or using Company resources. Control 8.20 is a dual-purpose preventive and detective control that maintains risk by implementing controls that safeguard Company’s ICT network from the top down by ensuring that network activity is adequately logged, partitioned and carried out by authorized personnel.

27002:2022 – 8.20 advocates for a far more comprehensive approach to network security, and contains a number of additional guidance points that deal with several key elements of network security, including:

1. Filtering network traffic
2. Suspending protocols
3. Categorizing network information
4. Isolating sub-networks
5. Maintaining visible devices
6. Firmware (permanent software programmed into a read-only memory records)

Ownership of Control 8.20

Control 8.20 deals primarily with the operation of back-end networking, maintenance and diagnostic tools and procedures, but its broad scope encompasses far more than day-to-day maintenance operations. 

User Responsibilities

Courtesy and respect for rights of others

The Company campus community has the responsibility to foster a positive and secure campus community by respecting and valuing the right of privacy and the diversity of the population and opinion in the community. In addition, all are responsible for complying with Company policy and all laws and contracts regarding the use of information.

Guidance on Compliance

Following the guidance by Control 8.20 Company focuses on two key aspects of network security across all its general guidance points.

Information security

To protect from unauthorised access (particularly in the case of connected services)

To achieve these two goals, Company does the following:

1. Categorise information across a network by type and classification, for ease of management and maintenance.
2. Ensure that networking equipment is maintained by personnel with documented job roles and responsibilities.
3. Maintain up-to-date information (including version controlled documentation) on LAN and WAN network diagrams and firmware/configuration files of key network devices such as routers, firewalls, access points and network switches.
4. Segregate responsibilities for the Company’s network from standard ICT system and application operations (see Control 5.3), including the separation of administrative traffic from standard network traffic.
5. Implement controls that facilitate the secure storage and transfer of data over all relevant networks (including third-party networks), and ensure the continued operation of all connected applications (see Controls 5.22, 8.24, 5.14 and 6.6).
6. Log and monitor any and all actions that directly impact information security as a whole across the network, or within individual elements (see Controls 8.16 and 8.15).
7. Coordinate network management duties to complement the Company’s standard business processes.
8. Ensure that all systems and relevant applications require authentication prior to operation.
9. Filter traffic that flows through the network via a series of restrictions, content filtering guidelines and data rules.
10. Ensure that all devices that connect to the network are visible, authentic and are able to be managed by ICT staff.
11. Retain the ability to isolate business critical sub-networks in the event of a security incident.
12. Suspend or disable network protocols that are either compromised or have become unstable or vulnerable.

Supporting Controls

1. 5.3 / Segregation of Duties
2. 6.6 / Confidentiality or non-disclosure agreement
3. 5.14 / Information Transfer
4. 5.22 / Monitoring, review and change management of supplier services
5. 8.15 / Logging
6. 8.16 / Monitoring of Activities
7. 8.24 / Use of Cryptography

Use of resources

• Users are responsible for knowing what information resources are available including those shared by the campus community. Users should refrain from all acts that waste or prevent others from using these resources.
• Users have a responsibility to ensure the security and integrity of the computer and network resources and services they use or access. Responsibilities include performing regular data backups, controlling physical access to information and computer equipment, using virus protection software, and keeping the virus definition file (DAT file) up to date. Responsibilities may also include updating Windows Critical Updates as requested by Computer and Information Services.

Information Integrity

• Users are responsible for the accuracy, completeness, trustworthiness, timeliness, and relevance of the data they enter into and extract from Company information systems. Users should not unconditionally depend on information or communications to be correct when they appear contrary to expectations. It is important to verify the integrity of the data entered into Company information systems because information contained on Company information systems may be used for reporting at a future date. 
• Users shall not place confidential information on the computer’s local hard drive without protecting the information appropriately.
• Employee, Client and Vendor/Supplier details to be kept confidential.  If employee stores confidential or sensitive information on his / her computer, they are required to take all precautionary steps to safeguard the information.
• Users are responsible for adhering to the Internal Network Equipment Policy when connecting any devices to the Company.
• Devices include, but are not limited to computers, laptops, servers, routers, switches, hubs, wireless devices.

Rules

• No one shall use any Company network resources or services without proper authorization. No one shall assist in, encourage or conceal any unauthorized use or attempt at unauthorized use of any of the Company’s network resources and services.
• Use of network resources and services without permission is theft of services and is illegal under state and company law.
• Authorized use of Edge Services and Solutions LLC-owned or operated computing and network resources are in use that is consistent with the academic and service missions of the Company.
• No one shall knowingly endanger the security of any Edge Services and Solutions LLC network resource, nor wilfully interfere with others’ authorized network usage.
• No one shall use Edge Services and Solutions LLC’s network resources or services to attempt unauthorized use, nor to interfere with others’ legitimate use, of any network facility anywhere.

• The ability to use a remote computer does not constitute permission.
• Users are not permitted to run software that searches for means of obtaining unauthorized access (ie. port scans, password crackers, etc.) even if the user does not plan to make unauthorized access after finding an access point.
• Users are not permitted to run software that burdens the network with unnecessary traffic or intentionally degrades the performance of the network. (i.e., unnecessary repetitive pings and trace routes)

• No one shall connect any computer or network equipment to any of the Company’s network resources or services until the equipment has been registered with the IT Infrastructure Department.
• Users are responsible for adhering to the Internal Network Equipment Policy when connecting any devices to the Edge Services and Solutions LLC One improperly configured computer or network device on a network can cause company-wide disruption.
• Devices include, but are not limited to computers, laptops, servers, routers, switches, hubs, wireless devices.
• No one without specific authorization shall use any Company network resource or service for non-Company business.
• By law, the Company can only provide computer resources and services for its own work, not for private use. Therefore, using Company resources or services to establish, run or support a personal and/or non-Company related business venture (e.g. via email, web site, listserv, etc.) is prohibited. 
• Users in need of computing/printing resources for private or personal purposes will need to contact local computer vendors for procurement options.
• No one shall create, install or knowingly distribute a computer virus or other surreptitiously destructive program on any Edge Services and Solutions LLC network resource , regardless of whether any demonstrable harm results.
• File sharing software is not permitted.

Enforcement

These policies and procedures are designed to ensure the integrity, security, and proper effective functioning of company IT services. All policy and procedure violations will be subject to investigation and appropriate disciplinary action through established channels that may include, for serious violations, letters of reprimand and/or termination of employment.

Technological Control No. 8.21

Security of Network Services

Purpose

This document addresses the Control 8.21 of ISO 27001:2022. Control 8.21 acknowledges the important role played by Information and Communications Technology (ICT) platforms and services in maintaining business continuity, following disruption or a critical event.

In computing, a ‘network service’ can broadly be described as a system running on the ‘network application layer’, such as

1. E-mail 
2. Printing
3. File server

Network services also include managed applications and security solutions such as

1. Firewalls or gateway antivirus platforms
2. Intrusion detection systems
3. Connection services

Network services often represent the most important functional parts of a network, and are critical to the day-to-day operation of a modern commercial ICT network. Security is therefore paramount, and the use of network services needs to be closely monitored and directly managed to minimize the associated risk of failure, intrusion and business disruption.

Control 8.21 is a preventive control that maintains risk by establishing a set of rules that govern the use of both network services and, by association, the host network itself.

Scope

This policy applies to network services used by Company that use IT Infrastructure to provide customer services.

Ownership of Control 8.21

Control 8.21 deals with technical concepts relating to the maintenance and management of several key components of an organization’s ICT network. As such, ownership should rest with the Head of IT, or organizational equivalent. 

General Guidance on Compliance

Following the guidance offered by Control 8.21 Company has adapted three main security types, when addressing the broader concept of network service security:

1. Security features
2. Service levels
3. Service requirements

These three measures are taken into account by all internal and external network service providers, and the organization should take steps to ensure that providers are fulfilling their obligations at all times.

Company judges a network service providers on their ability to manage services as dictated by an unambiguous set of Service Level Agreements and monitor adherence to the best of their ability.

Part of this operational assessment includes references obtained from trusted sources that attest to a network service provider’s ability to manage services in a secure and efficient manner. Network security rules include:

1. All network services and associated networks that are allowed to be accessed.
2. The authentication requirements for accessing said network services, including who is authorized to access them, from where and when they are able to do so.
3. How personnel obtain prior authorization to access network services, including final sign-off and business case analysis.
4. A robust set of network management controls that safeguard network services against misuse and unauthorized access.
5. How personnel are allowed to access network services (i.e. remotely or exclusively onsite).
6. Logging procedures that detail key information about network service access, and the personnel who utilize them – e.g. time, location and device data.
7. Monitoring the use of network services.

Guidance – Network Service Security

Control 8.21 also features guidance notes on how to increase security across all network services, including back-end functionality and user operation.

1. Company considers security features such as authentication, encryption and connection controls.
2. Rigid parameters are established that dictate the connection to network services.
3. Users are able to choose the amount of data cached (temporarily stored) by a network service to both increase overall performance and ensure that data isn’t excessively stored to the point of it being a tangible security risk.
4. Restricting access to network services.

The Company uses MFA to log into any network.

Technological Control No. 8.22

Segregation of Networks

Purpose

This document addresses the Control 8.22 of ISO 27001:2022. Control 8.22 addresses how Company can implement and maintain appropriate network segregation techniques to eliminate risks to the availability, integrity and confidentiality of information assets. Control 8.22 enables Company to segregate their computing networks into sub-networks based on the level of sensitivity and criticality and restrict the flow of traffic between these different sub-networks. This helps Company prevent the spread of malware or viruses from compromised networks to other networks storing sensitive information assets. This ensures that Company maintain the confidentiality, integrity, and availability of information assets hosted on critical sub-networks.

Control 8.22 is preventive in nature as it requires Company to take a proactive approach and establish and implement rules, procedures, and appropriate techniques to segregate the larger computing network into smaller network domains so that compromise of sensitive networks can be prevented.

Scope

This policy applies to segregation of network used by Company that use IT Infrastructure to provide customer services.

Ownership of Control 8.22

Considering that Control 8.22 entails segmentation of networks, devices, and systems based on the level of risks involved and also the implementation of network segregation techniques and procedures, an Information Security officer should be held responsible for compliance. CISO is appointed as the person in charge of this activity

General Guidance on Compliance

When implementing network segregation measures, Company tries to strike a balance between operational needs and security concerns.

Company tries to adapt, as Control 8.22 lists, three recommendations that are considered when implementing network segregation.

Recommendation 1

Separation of a big Network into Smaller Sub-Networks based on domains

When segregating the network into smaller network sub-domains, Company considers the level of sensitivity and criticality of each network domain. Depending on this analysis, network sub-domains may be assigned to 

1. Public domains
2. Desktop domains 
3. Server domains / High-risk systems

Separation of a big Network into Smaller Sub-Networks based on departments

Furthermore, Company also tries to separate the networks based on business departments such as 

1. Human Resource 
2. Marketing
3. Finance etc.,

It is also noted that Company tries to combine these two criteria and assign network sub-domains into categories such as ‘server domain connecting to sales department’

Recommendation 2 

Separation of networks based on Security Perimeters and Access Control

Company tries to define the perimeter of each network sub-domain clearly. If there will be access between two different network domains, this access is restricted at the perimeter level via the gateway such as firewalls or filtering routers.

Company should assess the security requirements for each specific domain when implementing network segregation and when authorizing access via the gateways.

This assessment is carried out in compliance with the access control policy as required under Control 5.15 and also considers the following:

1. Level of classification assigned to information assets.
2. Criticality of information.
3. Cost, and practical considerations for use of a particular gateway technology.

Recommendation 3 

Separation of networks based on frequencies of radio waves of Wireless Networks (2.4 gigahertz and 5 gigahertz)

Considering that defining network security parameters for wireless networks is challenging, as per the recommendation of Control 8.22 Company tries to adhere to the following practices:

1. The use of radio coverage adjustment techniques to segregate wireless networks should be assessed.
2. For sensitive networks, Company can assume all wireless access attempts as external connections and prevent access to internal networks until the gateway control approves access.
3. If employees only use their own devices in accordance with the Company’s policy, the wireless network access provided for employees and for guests should be segregated.
4. Use of Wi-fi by guests should be subject to the same restrictions and controls imposed on the employees.

Supplementary Guidance on Control 8.22

Control 8.22 notes that Company often enter into various business partnerships with other businesses and share their network, IT devices, and other information facilities.

Therefore, sensitive networks may be exposed to a heightened risk of unauthorized access by other users and Company should take appropriate measures to prevent this risk.

Include the network diagram of the Company.

Technological Control No. 8.23

Web Filtering

Purpose

This document addresses the Control 8.23 of ISO 27001:2022. Control 8.23 enables Company to eliminate security risks such as malware infection that may arise as a result of access to external websites with malicious content.

If employees visit websites with malicious content, this may expose corporate networks and information systems to security risks such as malware attacks.

Cyber attackers may send a phishing email to an employee’s work email, persuade him to click on a link, and visit a website. When the employee visits this website, they may automatically upload malware on the employee’s device and then infiltrate into corporate networks. This type of attack is called drive-by download and it automatically downloads malware once an employee visits a website.

Therefore, Company should put in place appropriate web filtering controls to restrict and control access to external websites and prevent security threats.

Control 8.23 is a preventive type of control that requires Company to put in place appropriate access controls and measures to prevent access to malicious content on external websites.

Scope

This document applies to appropriate access controls and measures used by Company to prevent access to restrict and control access external websites and prevent security threats used by IT Infrastructure to provide customer services.

Ownership of Control 8.23

Considering that 8.23 involves identification of high-risk external websites and design and implementation of appropriate access and web filtering controls, the Chief Information Security Officer should be responsible to take appropriate steps for compliance.

Procedure of Compliance

Company establishes and implements necessary controls to prevent employees from accessing external websites that may contain viruses, phishing materials, or other types of illegal information.

One effective technique to prevent access to dangerous external websites is blocking the IP address or domain of websites identified as dangerous. For instance, some browsers and anti-malware tools enable Company to do this automatically.

Control 8.23 notes that Company determines which types of websites should not be accessed by employees.

In particular, the following types of websites are blocked:

• Websites with information upload functionality. Access should be subject to permission and should only be granted for valid business reasons.
• Websites that are known or suspected to contain malicious material, such as websites with malware content.
• Command and control servers.
• Malicious websites obtained from threat intelligence. Company should refer to Control 5.7 for more details.
• Websites distributing illegal content and materials.

Before designing and implementing this Control, Company puts in place rules for safe and appropriate access to and use of online resources. This should also include imposing restrictions on websites that contain inappropriate materials. 

These rules are reviewed and updated at regular intervals.

Staff Training

As per Control 8.23 all staff are provided with training on how to access and use online resources safely.

This training covers the Company’s own rules and address how staff can raise his/her security concerns by contacting the relevant individual within the Company.

Furthermore, training also addresses how staff can access restricted websites for valid business reasons and how this exception process works for such access.

Last but not the least, training address browser advisory that warns users that a website is not secure but that permits users to proceed. Staff should be instructed not to ignore such warnings.

Web filtering Techniques

There is a variety of web filtering techniques such as:

1. 1. Heuristics: Heuristics is a scanning method that looks for malware-like behavior patterns. It is commonly used to detect new or not-yet-known malware
   2. Signatures: Signature is a methodology used by many cybersecurity companies to detect malware that has already been discovered in the wild and cataloged as part of a database.

• List of prohibited and acceptable websites

1. Domain configuration: Domain configuration technique uses (when you type in a website’s domain), a filtering process that takes place between the IP address being retrieved and the page being displayed. This filtering process categorizes the site into a variety of groupings that include news and media, social networking, malicious, illegal content, and much more.

Additional Information

Policy

•  Web Site Monitoring

The Information Technology (IT) Department monitors Internet use from all computers and devices connected to the corporate network.  For all traffic the monitoring system must record the source IP Address, the date, the time, the protocol, and the destination site or server.  Where possible, the system should record the User ID of the person or account initiating the traffic.  Internet Use records must be preserved for sixty (60) days.

• Access to Web Site Monitoring Reports

General trending and activity reports will be made available to any employee as needed upon request to the Information Technology Department.  Members authorized by the Departmental Manager or Top Management for overseeing incidents under Incident Management Policy and the Information Security Coordinator shall have access to all reports and data if necessary to respond to a security incident.  Internet Use reports that identify specific users, sites, teams, or devices will only be made available to associates outside only upon written or email request to Information Systems from a Human Resources Representative.

• Internet Use Filtering System

The Information Technology Department shall block access to Internet websites and protocols that are deemed inappropriate for Edge Services and Solutions LLC India Private Limited’s corporate environment.  The following protocols and categories of websites should be blocked:

• Adult/Sexually Explicit Material
• Advertisements & Pop-Ups 
• Chat and Instant Messaging (Exempted: Skype & Google Talk)
• Gambling
• Hacking
• Illegal Drugs
• Intimate Apparel and Swimwear
• Peer to Peer File Sharing
• Personals and Dating
• Social Network Services
• SPAM, Phishing and Fraud
• Spyware
• Tasteless and Offensive Content
• Violence, Intolerance and Hate
• Web Based Email with exemption stipulated under Email Security Policy

• Internet Use Filtering Rule Changes

The Information Technology (IT) Department shall periodically review and recommend changes to web and protocol filtering rules.  Human Resources shall review these recommendations and decide if any changes are to be made.  Changes to web and protocol filtering rules will be recorded in the Internet Use Monitoring and Filtering Policy.  

• Internet Use Filtering Exceptions

If a site is wrongly categorized, employees may request the site be un-blocked by submitting a ticket to the Information Technology help desk.  An IT employee will review the request and un-block the site if it is wrongly categorized.  

Employees may access blocked sites with permission if appropriate and necessary for business purposes.  If an employee needs access to a site that is blocked and appropriately categorized, they must submit a request to their Human Resources representative.  HR will present all approved exception requests to Information Technology in writing or by email.  Information Technology will unblock that site or category for that associate only.  Information Technology will track approved exceptions and report on them upon request.  

Enforcement 

The IT Manager will periodically review Internet use monitoring and filtering systems and processes to ensure they are in compliance with this policy.  Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.   

Definitions 

Technological Control No. 8.24

Use of Cryptography

Purpose

This policy addresses the Control 8.24 of ISO 27001:2022. The use of cryptography such as encryption can be effective to protect the confidentiality, integrity, and availability of information assets when they are in transit. Furthermore, cryptographic techniques can also maintain the security of information assets when they are at rest. Control 8.24 addresses how Company can establish and implement rules and procedures for the use of cryptography. 

The purpose of this document is to establish requirements for selecting cryptographic keys, managing keys, assigning key strengths and using and managing digital certificates. The protection methods outlined will include operational and technical controls, such as key backup procedures, encryption under a separate key and the use of tamper-resistant hardware. 

Control 8.24 enables Company to maintain the confidentiality, integrity, authenticity, and availability of information assets by properly implementing cryptographic techniques and by taking into account the following criteria:

1. Business needs
2. Information security requirements
3. Statutory, contractual and Company requirements concerning the use of Cryptography

Control 8.24 is a preventive type of control that requires Company to establish rules and procedures for the effective use of cryptographic techniques and thus eliminate and minimise risks to the compromise of information assets when they are in transit or at rest.

Scope

This policy applies to the protection of confidentiality, integrity, and availability of information assets when they are in transit or at rest.

Ownership on Control 8.24

Compliance with 8.24 requires the establishment and implementation of a specific policy on cryptography, creating an effective key management process, and determining the type of cryptographic technique appropriate to the level of information classification assigned to a particular information asset.

Therefore, the Chief Information Security Officer should be responsible for setting out appropriate rules and procedures for the use of cryptographic keys. CISO is responsible for the implementation of Cryptography in the Company.

Method of Compliance

Adapting the suggestion provided by Control 8.24 Company adheres to seven requirements when using cryptographic techniques:

1. Company creates and maintains a topic-specific policy on the use of cryptography. This policy is essential for maximising the benefits of cryptographic techniques and it reduces the risks that may arise from the use of cryptography. It is also noted that this policy should cover general principles governing the protection of information.
2. Company considers the level of sensitivity of the information assets and the information classification level assigned to them when they decide on the type, strength, and quality of the encryption algorithm.
3. Company implements cryptographic techniques when information is transferred to mobile devices or to storage media equipment or when information is stored on these devices.
4. Company addresses issues related to key management, including the creation and protection of cryptographic keys and the recovery plan for encrypted data in the event that keys are lost or compromised.
5. Company sets out the roles and responsibilities for the following:
   1. Establishment and implementation of the rules on how the cryptographic techniques will be used.
   2. How keys will be handled, including how they will be generated.
6. The adoption and approval of standards across the Company for the cryptographic algorithms, cipher strength, and usage practices for cryptography.
7. Company addresses how encrypted information may interfere with the controls that entail the content inspection such as malware detection.

Furthermore, Control 8.24 highlights that Company takes into account laws and requirements that may restrict the use of cryptography, including the cross-border transfer of encrypted information.

Finally, Company addresses liability and continuity of services when they enter into service agreements with third parties for the provision of cryptographic services.

Cryptographic Controls Policy

Encryption shall always be used to protect strictly confidential or sensitive information transmitted over data networks to protect against risks of interception. This includes accessing network services requiring authentication (for example, usernames and passwords) or when otherwise sending or accessing strictly confidential information (for example, emails).

Where confidential or sensitive data is stored on or accessed from mobile devices (for example, laptops, tablets, smartphones, external hard drives, USB sticks, digital recorders), the devices themselves must be encrypted (using “full disk” encryption) irrespective of ownership.

Where strictly confidential data is stored in a public cloud-based storage facility, the data must be encrypted before storing to ensure that the cloud service provider can’t decrypt the data. Where data is subject to an agreement with an external Company, the data should be handled (stored, transmitted or processed) following the Company’s specific encryption requirements.

Encryption key lengths should use current industry-standard encryption algorithms for confidential or sensitive information.

Encryption Methods for Data at Rest

Sensitive data at rest shall be encrypted at all times.

The encryption of data at rest shall only include strong encryption methods / algorithms such as Advanced Encryption Standard (AES) or Rivest, Shamir and Adleman (RSA).

Encrypted data shall remain encrypted when access controls such as usernames and passwords fail. Increasing encryption on multiple levels is recommended.

Confidential or sensitive information at rest on computer systems owned or operated by Company is protected by one or more of the following mechanisms:

• Disk or File System Encryption.
• Sanitizing, redacting and/or de-identifying the data requiring protection during storage to prevent unauthorized risk and exposure (e.g., masking or blurring).
• Supplemental compensating or complementary security controls, including complex passwords and physical isolation/access to the data.
• Strong cryptography on authentication credentials (i.e., passwords/phrases) shall be made unreadable during transmission and storage on all information systems.
• Password protection to be used in combination with all controls, including encryption.
• File systems, disks and tape drives in servers and Storage Area Network (SAN) environments are encrypted using industry-standard encryption technology.
• Computer hard drives and other storage media that have been encrypted shall be sanitized to prevent unauthorized exposure upon return for redistribution or disposal.
• Storage systems in public cloud environments should use encryption processes provided by the cloud provider or use encryption setup and configured by Company.

Encryption Methods for Data in Transit

Company ensures that formal transfer policies, protocols, procedures and controls are implemented to protect the transfer of information through the use of all types of communication and transmission facilities.

The transfer of sensitive data shall be through a secure channel. A secure channel is an encrypted network connection.

Strong cryptography and security protocols (e.g., Transport Layer Security (TLS), Internet Protocol Security (IPSec), Secure Shell (SSH), etc.) shall be used to safeguard confidential or sensitive information during transmission over open public networks. Such controls include:

• Only accepting trusted keys and certificates, that protocols in use only support secure versions or configurations, and encryption strength is appropriate for the encryption methodology in use.
• Confidential or sensitive information transmitted in email messages is encrypted. Any confidential or sensitive information transmitted through a public network (e.g., internet) to and from vendors, customers or entities doing business with Company must be encrypted or transmitted through an encrypted tunnel virtual private networks (VPNs) or Point-to-Point Tunneling Protocols (PPTP) that includes current TLS implementations.
• Use of VPNs and firewalls with strict access controls that authenticate the identity of those individuals accessing confidential or sensitive information.
• Wireless (Wi-Fi) transmissions used to access Company computing devices or internal networks must be encrypted using current wireless security standard protocols (e.g., RADIUS, WPS private/public keys or other industry-standard mechanisms).
• Secure encrypted transfer of documents and confidential or sensitive information over the internet using current secure file transfer programs such as Secure File Transfer Protocol (SFTP) (FTP over SSH, Secure SHell) and Secure Copy Command (SCP).
• All administrative access such as browser/web-based management tools is encrypted using TLS based browser technologies using the most current security algorithm.

When possible, public cloud configurations ensure all traffic between internal systems happens only on internal networks and does not go out to the public internet and then back into the internal systems.

Encryption Standards for Devices

All new laptops, tablets and portable storage devices purchased through IT will be supplied with encryption pre-installed and enabled. All USB storage devices must have encryption applied through an appropriate software tool.

Encryption Key Management Policy

Effective enterprise public and private key management is a crucial element in ensuring system security. Key management procedures must ensure that authorized users can access and decrypt all encrypted confidential or sensitive information using controls that meet operational needs. 

Company’s key management systems shall be characterized by the following security precautions and attributes:

• • Company uses procedural controls to enforce the concepts of least privilege and separation of duties for staff. These controls apply to persons involved in encryption key management or who have access to security-relevant encryption key facilities and processes, including Certificate Authority (CA) and Registration Authority (RA) and/or contractor staff.
  • Keys in storage and transit must be encrypted.
  • Private keys must be kept confidential.
  • Application and system resource owners should be responsible for establishing data encryption policies that grant exceptions based on demonstration of a business need and assessing the risk of unauthorized access to or loss of confidential or sensitive information.
  • Decryption keys shall not be associated with user accounts to avoid issues once they have left the Company.
  • Restrict access to cryptographic keys to the fewest number of custodians necessary. Cryptographic keys are stored in the fewest possible locations.
  • Retirement or replacement (for example, archiving, destruction and/or revocation) of keys should be done when the integrity of the key has been weakened or keys are suspected of being compromised.
  • Company prevents the unauthorized substitution of cryptographic keys.
  • Archived cryptographic keys should only be used for decryption/verification purposes.

• Cryptographic key custodians shall formally acknowledge that they understand and accept their key-custodian responsibilities.

Supplementary Guidance on Key Management

Company defines and applies secure procedures for the creation, storage, retrieval, and destruction of cryptographic keys.

In particular, Company puts in place a robust key management system that includes rules, processes and standards for the following:

1. Generation of cryptographic keys for different systems and applications.
2. Issuance and acquisition of public-key certificates.
3. Distribution of keys to intended recipients, including the process of key activation.
4. Storage of keys and how authorised parties can access to keys.
5. Changing of keys.
6. Handling of compromised keys.
7. Revocation of keys for why they are compromised or when authorised persons leave the Company.
8. Recovery of lost keys.
9. Key back-up and archival.
10.  Destroying keys.
11. Keeping a log of all activities related to each key.
12. Determining activation and deactivation dates for keys.
13. Responding to legal requests for having access to keys.

Cautions against risks:

1. Secret and protected keys should be protected against unauthorised use.
2. Equipment used to create or store encryption keys should be protected via physical security measures.
3. Company should maintain the authenticity of public keys.

Requirements for Encryption Keys and Digital Certificates

Company must use industry-approved strong algorithms for encryption and/or digital signing processes. The following subsections detail requirements that also ensure an adequate level of protection. Company must protect private encryption keys to prevent their unauthorized disclosure and subsequent fraudulent use. All private keys protecting Company’s and its customer’s information are classified as per Information Sensitivity/Classification Policy.

Private Keys

Company handling private keys must:

• Be physically and logically secured.
• Be stored in/on:
  • An encrypted key store or in an otherwise encrypted form.
  • A security token.
  • An encryption keyring.
• Not be shared with anyone other than those expressly authorized.
• Never be stored on the same IT Resource as the Company information being protected at rest (e.g., encrypted storage).
• Never be reused to encrypt another set of unrelated or separate Company information.
• Maintain the records of access for users handling private keys, so the key use is auditable.
• Be encrypted with a key-encrypting key that is as strong as the data-encrypting key and is stored separately from the data-encrypting key.
• Follow Company’s disposal procedure when retiring keys.
• Use a privileged access management tool for secure handling of private keys protecting Company’s or its customer information.
• Be accessed using a privileged access management tool to ensure the secure handling of private keys while protecting Company’s or its customers’ information.

Generating Strong Keys

Company users generating private keys must:

• Select a key size using the minimum specified by the encryption method or greater when symmetric key encryption is employed.
• Generate keys on the IT Resource itself or, if transmission of a private key is required, distribute keys manually using a public key transport mechanism or using a previously distributed or agreed-upon key-encrypting key.
• Use a random key generation mechanism.

Emergency Access to Keys

The IT Ops team must have auditable procedures to provide access to private keys in an emergency and/or the passphrase holder being unavailable.

Changing Private Keys and the Private Key Lifecycle

Company must:

• Have a process to approve key changes, record dispositions and change keys when a user with access to a private key(s) separates or changes roles.
• Have a process to change keys as part of the response to an information security incident.
• For private keys protecting Company’s or its customers’ information, change keys at least once annually.
• Revoke and/or delete private keys when they are no longer needed to perform a business function.
• Not re-issue or reuse private keys.

Access to Keys

Company personnel handling private keys must be limited to those who have a need-to-know based on job responsibilities.

Personnel (key custodians) responsible for managing encryption in Company must acknowledge that they understand their roles and the key management policy and procedures.

Where applicable, the distribution/movement of keys must be done securely and transmitted by authorized key custodians.

Where manual cryptographic key-management operations are used, they must be handled using split knowledge and dual control. At least two authorized personnel who only have information of their own key components are expected to carry out any key management operations.

Encryption Methods

Company must select the stronger of the following methods:

• An encryption method based on the Risk Assessment
• Symmetric – using the minimum recommended key strength or higher or
• Asymmetric/Public-Private key pair – using the minimum recommended key strength or higher

Compromised Keys

Company must change encryption keys immediately if the key becomes compromised or is discovered by any unauthorized person or party.

Company users must report any compromised key to the senior management team member responsible for information security.

Establishing Data Key Rotation (Crypto periods)

Company must implement a complete crypto period consisting of a data key being valid for a predefined time and a maximum number of encryption events done with a specific data key. This is applicable where Company is responsible for its key management.

In the case of cloud service, the cloud service provider is responsible for automatic key rotation at defined intervals. Company must access and confirm these key policies in the cloud management console.

Web Server Certificates

Company users handling web server certificates must:

• Use digital certificates signed by a senior management team member responsible for information security approved CA.
• Select a key size of 2048 bits or greater.
• Select an expiration of not more than one year for IT Resources accessing Company and its customers’ information.
• Use a new public-private key pair when the certificate is renewed. The public key is to be sent as part of the CSR – Certificate Signing Request.

Self-signed Certificates

Company users handling self-signed certificates must:

• Not use them for any production purpose on a public network.
• Not use them for the testing of IT Resources processing, storing or transmitting Company or its customer information.
• Use IT resources with factory-installed self-signed certificates on protected private networks.

Technological Control NO. 8.25

Secure Development Life Cycle

Introduction

This policy addresses the Control 8.25 of ISO 27001:2022. Control 8.25 enables Company to design information security standards and apply these standards across the entire secure development life cycle for software products and systems. 

Control 8.25 is preventive in nature as it requires Company to proactively design and implement rules and controls that govern the whole development life cycle for every new software product and system.

The purpose of this document is to set out Company policy in the development of software applications and components in a way which maximises their inherent security.

Secure development contributes to the reliability of the IT environment by ensuring that as many vulnerabilities as possible are designed and tested out of software before it is transitioned into the live environment.

Many security breaches around the world occur due to the exploitation of such vulnerabilities in system and application software, including the use of data that was not envisaged when the software was designed and tested.

This document sets out the precautions that must be taken during the software development lifecycle to minimise the risk to the organization whilst ensuring that the benefits set out in the original business case for the software are still realised.

As such, this document will represent an initial design for the enhancement of existing development processes and will be updated on at least an annual basis thereafter as Company and its needs develop.

This policy should be read in conjunction with the following documents which give more detail in specific areas:

• Change Management Process 
• Secure Development Environment Guidelines
• Information Security Policy for Supplier Relationships
• Supplier Information Security Evaluation Process

Scope

This policy applies to software development process used by Company in a way that maximises the inherent security.

Ownership

The Chief Information Security Officer is responsible for the creation, implementation, and maintenance of rules and measures for ensuring the security of the development life cycle.

General Guidance on Compliance

As per the guidance from Control 8.25, Company complies with (following 10 requirements) to build secure software products, systems, and architecture:

1. Development, test, and production environments should be segregated as per Control 8.31.
2. Company should provide guidance on:

• Security considerations in the software development methodology in accordance with Control 8.27 and 8.28.
• Secure coding for each programming language in accordance with 8.28.

1. Company should establish and implement security requirements that apply to the specification and design phase in accordance with Control 5.8.
2. Company should define security checklists for the projects as per Control 5.8.
3. Company should perform security and system testing such as penetration tests and code scanning in accordance with Control 8.29.
4. Company should create safe repositories storing source codes and configuration in compliance with Controls 8.4 and 8.9.
5. Company should maintain security in the version control as prescribed in Control 8.32.
6. Company should ensure all personnel involved in the development has sufficient application security knowledge and are provided with the necessary training as defined in Control 8.28.
7. Developers should be capable of identifying and preventing security vulnerabilities as set out in Control 8.28.
8. Company should comply with licensing requirements and should evaluate the feasibility of alternative cost-effective methods as prescribed in Control 8.30.

Furthermore, if Company outsources certain development tasks to external parties, it must ensure that the external party adheres to the Company’s rules and procedures for the secure development of software and system.

Software Development Approaches

The process of software development fits in with the higher level process of project management of new or enhanced information systems.

This process has the following major stages in a project:

• Proposal
• Planning
• Design and Development
• Transition
• Project Closure

The software development lifecycle sits mainly within the Design and Development stage and consists of the following sub-stages:

1. Design and Development

• Business requirements specification
• System design
• Development
• Testing

The way in which the stages of the software development lifecycle are approached will depend upon the development approach used. The two main models of software development used within Company are Waterfall and Iterative. The choice of approach will be made on a project by project basis.

Waterfall Development Approach

The classic Waterfall approach to software development involves the planning and completion of each stage before moving on to the next, in a sequential manner. Functional requirements are defined in detail and signed off before the design stage may begin. In turn, design must be completed before development starts etc. This has the advantage that it is possible to ensure that adequate planning takes place and to include security checkpoints at the end of each stage. These will ensure the inclusion of adequate security criteria at the requirements stage and correct security controls at the design stage.

The common disadvantage with the Waterfall approach is that it is less flexible as circumstances and requirements change. If the project lasts for an extended period of time there is the danger that what is delivered is no longer what is required.

Similar approaches based on Waterfall include Structured Programming Development, the Spiral Method and Clean room.

Iterative Development Approach

As an alternative Waterfall, an Iterative approach may be taken. Such approaches include Rapid Application Development (RAD), Prototyping and, more recently, Agile.

The Iterative approach typically involves significant stakeholder involvement throughout the development lifecycle and concentrates on producing frequent new versions of the software that may be evaluated and tested before further functionality is added. The process loops round with each of the stages being carried out many times in small iterations (in the Agile method these are called “Sprints”).

An Iterative approach may be appropriate where exact requirements are less certain and frequent communication between developers and users (and within the development team) is possible.

The inclusion of security requirements and controls within an Iterative development approach needs to be carefully managed to ensure that functionality is not preferred to the exclusion of effective security measures. The speed involved and the potential lack of structured design documentation mean that effective training of developers in security matters and possibly the regular involvement of a security specialist are recommended.

Security in the Software Development Lifecycle

This section describes the way in which information security considerations should be incorporated into the various stages within the software development lifecycle.

Business Requirements Specification

The focus within the business requirements stage is on the functionality of the new system. This will be expressed in business rather than technical terms and should tie in with the business case that was produced prior to the initiation of the project.

The business is uniquely placed to give a clear understanding to the development team of the security requirements of the information that the new system will hold and process. In particular the business requirements should specify:

1. The value of the information involved
2. The sensitivity of the information – will personal data be held?
3. Who the information owner is or will be
4. The classification of the information according to the scheme used within the organization
5. The environment in which the information will be accessed or processed – will access be available in public areas?
6. The criticality of the new system and the information it holds – what is the business impact if it is not available?
7. The legal, regulatory and contractual environment the system must operate within

A risk assessment should be carried out as part of the project to ensure that the implications of the above issues are fully understood by all parties.

System Design

Based on the risk assessment and the classification of the information that is to be held in and processed by the new system, the design must provide for appropriate security features to be available. 

This extends not only to the creation and maintenance of user accounts and permissions but also the following areas:

1. Data input validation controls
2. Data flow
3. Data output
4. Interfaces with other systems
5. Reporting
6. Restart and recovery
7. Time stamps
8. Logging (e.g. of transactions and access)
9. Journaling of before and after images
10. Batch and transaction counters
11. Monitoring facilities
12. How non-repudiation requirements will be met
13. On-going patching arrangements
14. Use of cryptography
15. Need for digital certificates and signatures

For systems designed as part of a Waterfall approach these aspects should be included as part of the design documentation. If and Iterative approach is used, the development team will need to ensure that these areas are considered during every iteration and that changes do not invalidate controls implemented during an earlier iteration.

Development

Before starting to write code, a secure development environment should be established for the project. More detail regarding the creation and management of a secure development environment may be found in the document.

Depending on the coding environment, languages, databases, tools and other components selected, the appropriate guidelines for secure coding and configuration should be adopted. These should be evaluated to ensure they will provide adequate protection from the various types of potential attack identified in the risk assessment, such as:

1. Buffer overflow
2. Time of Check/Time of Use
3. Memory Reuse
4. Malformed input
5. SQL injection

For a lengthy project it will be necessary to obtain regular updates regarding newly identified vulnerabilities and exploits associated with the technology components in use.

Testing

During the lifecycle of a software application, many different forms of testing will be carried out, including unit, system, integration, performance, user acceptance and operational acceptance testing. Security controls will to some extent be tested as part of these exercises. However it is recommended that a separate exercise of

Security testing be carried out against the security requirements that were established during the business requirements and design stages.

Initial security testing should be carried out within the development project with the same degree of rigour and formality as other forms with a suitable range of test inputs being specified.

Once this has been completed to the development team’s satisfaction a further phase of security testing should be carried out by an independent party separate to the development team to verify correct operation of controls.

Adequate controls should be put in place to protect test data. Where appropriate (and with prior approval on each occasion), a live to test copy may be made in order to provide representative test data. However if this contains sensitive information such as personally identifiable data this should be removed or obscured before use.

Security in Outsourced Development

Where software development is wholly or partially outsourced to a third party, due care must be taken to ensure that the policies of Company are still followed where possible. Currently this is not applicable.

Company will remain legally responsible for the use of the software created and the information contained within it even though it didn’t write the software. Therefore the same level of rigour must be applied to outsourced software development as that created in-house.

Selection of Outsourced Developer

Standard procurement procedures should be used in the selection and engagement of an appropriate outsourced developer. Use of these procedures should ensure the developer:

• Is capable of delivering the software to the required standard
• Can meet the delivery timescales required
• Represents best value for the organization
• Can meet the security requirements specified

Use of sub-contractors by the outsourced developer for any aspects of the development should be understood and an assessment of these sub-contractors included.

Communication of Requirements

The contract with the outsourced developer should require compliance with this policy and include a clear statement of the requirements for secure design, coding and testing of the software. The developer should also be required to establish a secure development environment in accordance with Company standards. 

Requirements definition should be carried out by Company so that a clear definition of the software to be created (including its security features) is agreed with the business and used as a contractual starting point for development. Whilst the outsourced developer may in some circumstances assist in the definition of requirements, the exercise should be led, managed and ideally carried out by internal resources so that there is a clear separation between requirements and design/development.

A comprehensive picture of the anticipated threat model faced by the software should be provided to the outsourced developer so that a clear understanding is gained of the types of vulnerabilities that must be avoided if the software is to be secure.

Supervision and Monitoring

Measures should be put in place to ensure adequate supervision of the activities of the outsourced developer and regular monitoring of progress.

For a large project with significant time gaps between deliverables, an agreed method of verifying interim progress should be in place so that early warning is given of delays.

Reviews and Acceptance

Review points should be established as part of the project planning process to verify progress and give formal acceptance of the software deliverables created. These will involve appropriate testing activities and code reviews.

The outsourced software developer should be required to provide evidence of the security testing activities carried out during the development, including tests for concealed malware, backdoors and known vulnerabilities.

Where appropriate a security review of developed code may be engaged with a suitable third party with the relevant security expertise.

Audit of Development Methods

Company should have the contractual right to undertake a second party audit of the outsourced development provider. This may be to review whether the development methods used comply with our policies and that all information provided to the supplier is protected by appropriate security controls.

For larger projects it is recommended that an audit be carried out prior to the placing of the order for software development to ensure that assurances given during the sales process are valid.

Intellectual Property

Unless the software is licensed under a formal agreement, contractual arrangements with an outsourced software developer should state that the ownership of the code produced on our behalf rests with Company.

It is important that any software that is developed under an outsourcing contract is understood to be our intellectual property. Appropriate legal advice should be taken particularly if the outsourcer is based outside of our home country.

Escrow

Arrangements should be made for Company to be able to legally access the source code of any developments undertaken, in the event that the outsourcer ceases trading for any reason. This should be the case during development and if appropriate after the code has been delivered.

Introduce Company’s software methodology diagram here.

Technological Control No. 8.26

Application Security Requirements

Purpose

This policy addresses the Control 8.26 of ISO 27001:2022. Control 8.26 addresses how Company can establish and apply information security requirements for the development, use, and acquisition of applications.

Control 8.26 is a preventive type of control that prevents risks to the integrity, availability, and confidentiality of information assets stored on application through the use of suitable information security measures.

Scope

This policy applies to security vulnerabilities that may result in the compromise of sensitive information. 

Ownership of Control 8.26

Chief Information Security Officer with the support of information security specialists, is responsible for the identification, approval, and implementation of information requirements for the acquisition, use and development of applications.

Method of Compliance

As per general guidance notes that Company carries out a risk assessment to determine the type of information security requirements appropriate to a particular application.

While the content and types of information security requirements may vary depending on the nature of the application, the requirements should address the following:

1. The degree of trust assigned to the identity of specific entities in accordance with Control 5.17 / Authentication Information, 8.2 / Privileged Access rights and 8.5 / Secure Authentication.
2. Identification of the level of classification assigned to information assets to be stored on or processed by the application.
3. Whether there is a need to segregate the access to functions and information stored on the application.
4. Whether the application is resilient against Cyber-attacks such as SQL injections or unintentional interceptions such as buffer overflow.
5. Legal, regulatory and statutory requirements and standards applicable to the transaction processed, generated, stored, or completed by the application.
6. Privacy considerations for all parties involved.
7. Requirements for the protection of confidential data.
8. Protection of information when in use, in transit, or at rest.
9. Whether secure encryption of communications between all relevant parties is necessary.
10. Implementation of input controls such as input validation or performing integrity checks.
11. Carrying out automated controls.
12. Performing output controls, taking into account who can view outputs and the authorisation for access.
13. Need to impose restrictions on the content of “free-text” fields to protect the dissemination of confidential data in an uncontrollable manner.
14. Requirements arising out of business needs such as logging of transactions and non-repudiation requirements.
15. Requirements imposed by other security controls such as data leakage detection systems.
16. How to handle error messages.

Supplementary Guidance on Transactional Services followed by Company

As per Control 8.26 following seven recommendations are followed by the Company when an application offers transactional services between the Company and a partner:

1. The degree of trust each party in the transaction requires in the other party’s identity.
2. The degree of trust required in the integrity of data communicated or processed and identification of a proper mechanism to detect any lack of integrity, including tools such as hashing and digital signatures.
3. Establishment of an authorisation process for who is allowed to approve the content of, sign, or sign off on essential transactional documents.
4. Maintaining the confidentiality and integrity of the critical documents and proving sending and receipt of such documents.
5. Protecting and maintaining the integrity and confidentiality of all transactions such as orders and receipts.
6. Requirements for what time period transactions shall be kept confidential.
7. Contractual requirements and requirements related to insurance.

Supplementary Guidance on Electronic Ordering and Payment Applications (if applicable)

When applications include payment and electronic ordering functionality, Company should take into account the following:

1. Requirements ensure that confidentiality and integrity of order information are not compromised.
2. Determining an appropriate degree of verification to verify the payment details provided by a customer.
3. Preventing the loss or duplication of transaction information.
4. Ensuring that information related to information is stored outside of a publicly accessible environment such as on a storage media housed on the organization’s own intranet.
5. Where Company rely on a trusted external authority such as for the issuance of digital signatures, they must ensure that security is integrated across the entire process.

Supplementary Guidance on Networks

When applications are accessed through networks, they are vulnerable to threats such as contract disputes, fraudulent activities, mis-routing, unauthorised changes to the content of communications, or loss of confidentiality of sensitive information.

Control 8.26 recommends Company perform comprehensive risk assessments to identify appropriate controls such as the use of cryptography to ensure the security of information transfers.

Company to declare what methods it is using to tackle technical vulnerabilities that reduces compromises in sensitive information.

Technological Control No. 8.27

Secure System Architecture and Engineering Principles

Introduction

This policy addresses the Control 8.27 of ISO 27001:2022. Control 8.27 addresses how Company can eliminate security threats to information systems by creating secure system engineering principles (Security Foundation, Risk Based thinking, Ease of Use, Increase Resilience, Reduce Vulnerabilities and Design with Network in mind) that are applied to all phases of the information system life-cycle.

Control 8.27 is a preventive type of control that requires Company to eliminate known and potential threats to the confidentiality, integrity and availability of information assets stored on or processed through information systems such as storage media, databases, and applications via establishing principles for secure system engineering.

Control 8.27 enables Company to maintain the security of information systems during the design, deployment and operation stages by establishing and implementing secure system engineering principles that system engineers comply with.

Scope

This policy applies to Complex compositions of modern information systems and the ever-changing cyber security threat landscape make information systems more vulnerable to known and potential security threats faced by Company.

Ownership of Control 8.27

Chief Information Security Officer is responsible for the establishment, maintenance, and implementation of principles that govern secure engineering of information systems.

Method of Compliance

Control 8.27 highlights that Company should embed security into all layers of information systems, including business processes, applications, and data architecture.

Furthermore, secure engineering principles apply to all activities related to information systems and should be subject to regular review and updates taking into account emerging threats and attack patterns.

In addition to information systems developed and operated internally, Control 8.27 also applies to information systems created by external service providers.

Therefore, Company would ensure that service providers’ practices and standards comply with their own secure engineering principles.

Control 8.27 requires secure system engineering principles to cover the eight following issues: 

1. Guidance on user authentication methods.
2. Guidance on secure session control.
3. Guidance on data sanitisation and validation procedures.
4. Comprehensive analysis of all security measures needed to protect information assets and systems against known threats.
5. Comprehensive analysis on capabilities of security measures to identify, eliminate and respond to security threats.
6. Analysing security measures applied to specific business activities such as encryption of information.
7. How security measures will be implemented and where? This may include the integration of a specific security control within technical infrastructure.
8. How different security measures work together and operate as a combined set of controls.

Zero Trust Principle

Company would consider the following zero-trust principles:

1. Starting with the assumption that the Company’s systems are already compromised and the defined network perimeter security is no longer effective.
2. Adopting a “never trust and always verify” approach for providing access to information systems.
3. Providing assurance that requests made to information systems are protected with end-to-end encryption.
4. Implementing verification mechanism that assumes access requests to information systems are made from external, open networks.
5. Putting in place “least privilege” and dynamic access control techniques in accordance with Controls 5.15 / Access Control, 5.18 / Access Rights and 8.2 / Privileged Access Rights. This covers the authentication and authorisation of access requests for sensitive information and information systems considering contextual information such as user identities as defined in Control 5.16 /  and information classification as prescribed in Control 5.12 / Classification of Information.
6. Always authenticating the identity of the requester and verifying authorisation requests to access information systems. These authentication and verification procedures should be performed in accordance with authentication information in Control 5.17 / Authentication Information, User Identities in Control 5.16 / Identity Management, and Multi-Factor in Control 8.5 / Secure Authentication.

Following topics are covered in Secure System Engineering Techniques

1. Adopting and implementing secure architecture principles, including “security by design”, “defence in depth”, “fail securely”, “distrust input from external applications”, “assume breach”, “least privilege”, “usability and manageability” and “least functionality”.
2. Adopting and applying a security-focused design review process to detect information security vulnerabilities and guaranteeing that security measures are identified and satisfy security requirements.
3. Documenting and acknowledging the security measures that do not fulfil requirements.
4. System hardening.

Criteria Considered when Designing Secure Engineering Principles

Company considers the following when establishing secure system engineering principles:

1. The need to integrate controls with specific security architecture.
2. Existing technical security infrastructure, including public key infrastructure, identity management, and data leakage prevention.
3. Whether the Company is capable of building and maintaining the selected technology.
4. Cost and time required to satisfy security requirements and complexity of such requirements.
5. Existing best practices.

Technological Control No. 8.28

Secure Coding

Introduction

This policy addresses the Control 8.28 of ISO 27001:2022. Control 8.28 enables Company to prevent security risks and vulnerabilities that may arise as a result of poor software coding practices by designing, implementing and reviewing appropriate secure software coding principles.

Control 8.28 is a preventive type of control that helps Company maintain the security of networks, systems, and applications by eliminating risks that may arise out of poorly-designed software code.

Scope

This policy applies to secure coding principles followed by Company so that poor coding practices do not lead to security vulnerabilities. 

Ownership of Control 8.28

Chief Information Security Officer is responsible for the design and implementation of Company-wide secure coding principles and procedures.

Method of Compliance

Control 8.28 requires Company to establish and implement Company-wide processes for secure coding that applies to both software products obtained from external parties and to open source software components.

Furthermore, Company will keep up to date with evolving real-world security threats and with the most recent information on known or potential software security vulnerabilities. This will enable Company to improve, and implement robust secure software coding principles that are effective against evolving cyber threats.

Secure Coding principles during planning stage

Secure software coding principles are followed both for new coding projects and for software reuse operations.

These principles should be adhered to both for in-house software development activities and for the transfer of the Company’s software products or services to third parties.

When establishing a plan for secure coding principles and determining the prerequisites for secure coding, Company complies with the following:

1. Company determines security expectations tailored to it’s needs and establish approved principles for secure software coding that will apply to both in-house software development and outsourced software components.
2. Company detects and documents the most prevalent and historical poor coding design practices and mistakes that result in compromise of information security.
3. Company puts in place and configure software development tools to ensure the security of all code created. One example of such tools is Integrated Development Environments (IDE).
4. Company achieves compliance with the guidance and instructions provided by software development tools.
5. Company reviews, maintains, and securely uses development tools such as compilers.

Supplementary Guidance on Security during Coding

During Secure coding practices and procedures Company takes into account the following for the coding process:

1. Secure software coding principles should be tailored to each programming language and techniques used.
2. Deployment of secure programming techniques and methods such as test-driven development and pair programming.
3. Use of structured programming methods.
4. Proper code documentation and removal of code defects.
5. Prohibition on the use of insecure software coding methods such as unapproved code samples or hard-coded passwords.

Supplementary Guidance also notes that security testing should be performed both during and after the development in accordance with Control 8.29.

Before putting the software into actual use in the live application environment, Company considers the following:

1. What is the attack surface?
2. Is the principle of least privilege followed?
3. Carrying out an analysis of the most prevalent programming mistakes and documenting that these risks have been eliminated.

Review Process for Secure Code

After the Code is put into use in the Production Environment

1. Updates are applied in a secure manner.
2. Security vulnerabilities reported in line with Control 8.8 are addressed.
3. Suspected attacks on information systems and errors should be recorded and these records are reviewed on regular intervals so that appropriate changes to code can be made.
4. Unauthorised access to, use of, or changes to source code are prevented via mechanisms such as management tools.

If the Company Uses External Tools, it takes into account the following

1. External libraries are monitored and updated at regular intervals based on their release cycles.
2. Software components are carefully vetted, selected, and authorised especially cryptography and authentication components.
3. Licensing of external components and ensuring their security.
4. Software are tracked and maintained. Furthermore, it must be ensured that it comes from a trustworthy source.
5. Development resources are available for the long term.

When making changes to a software package, the following are considered

1. Risks that may arise out of built-in controls or compromise of integrity processes.
2. Whether the vendor gives consent to changes.
3. Whether it is possible to get consent from the software vendor for regular updates.
4. The likely impact of carrying on the maintenance of the software that arises out of changes.
5. Whether the changes would be compatible with other software components used by the Company.

Additional points considered on Control 8.28

Company ensures that security-relevant code is used when it is necessary and is resistant to tampering.

Control 8.28 also lists the following recommendations for security-relevant code:

1. While programs installed via binary code include security-relevant code, this is limited to the data stored within the application itself.
2. Concept of security-relevant code is only useful when code is run on a server that is not accessible to the user and it is segregated from the processes that use it and its data is kept securely in another database. For instance, you can run an interpreted code on a cloud service and access to code can be restricted to privileged administrators. It is recommended that you protect these access rights via methods such as just-in-time administrator privileges and robust authentication mechanisms.
3. Appropriate configurations on web servers should be implemented to prevent unauthorised access to and browsing of the directory.
4. When designing application code Company starts with the assumption that the code is vulnerable to attacks due to coding errors and actions by malicious actors. You should design critical applications in a way that they are not vulnerable to internal faults. For instance, the output produced by an algorithm can be reviewed to ensure that it complies with security requirements before it can be used in critical applications such as finance-related applications.
5. Certain web applications are highly vulnerable to security threats due to poor coding practices such as database injection and cross-site scripting attacks.

Technological Control No. 8.29

Secure Testing in Development and Acceptance

Introduction

This policy addresses the Control 8.29 of ISO 27001:2022. Control 8.29 enables Company to verify that all information security requirements are satisfied when new applications, databases, software, or code are put into operation by establishing and applying a robust security testing procedure. This helps Company to detect and eliminate vulnerabilities in the code, networks, servers, applications or other IT systems before they are used in the real world.

Control 8.29 is preventive in nature. It requires Company to subject new information systems and their new/updated versions to a security testing process before they are released into the production environment.

Scope

This policy applies to detecting and eliminating vulnerabilities in the code, networks, servers, applications and other IT systems before they are used in the real world by Company.

Ownership of Control 8.29

Considering that Control 8.29 involves establishment, maintenance and implementation of a security testing procedure that will apply to all new information systems whether developed in-house or by external parties, the Information Security Officer should be responsible for compliance. CISO will be in charge of this activity.

Method of Compliance

Company incorporates security testing into the testing process for all systems and they ensure that all new information systems and their new/updated versions satisfy the information security requirements when they are in the production environment.

As per Control 8.29 three elements are included in the security testing process:

1. Security functions as defined in Control 8.5 / user authentication, in Control 8.3 / access restriction, and in Control 8.24 / Cryptography.
2. Secure coding as described in Control 8.28.
3. Secure configurations as prescribed in Controls 8.9, 8.20, 8.22. This may cover firewalls and operating systems.

Security Test Plan includes the following

1. Establishment of a detailed schedule for the activities and the testing to be conducted.
2. Inputs and outputs expected to occur under a given set of conditions.
3. Criteria to assess the results.
4. If appropriate, decisions to take actions based upon the results.

In-House Development includes the following

When IT systems are developed by the in-house development team, this team will carry out the initial security testing to ensure the IT system satisfies security requirements.

This initial testing is then followed by an independent acceptance testing in accordance with Control 5.8.

In relation to the in-house development, the following is considered:

1. Carrying out code review activities to detect and eliminate security flaws, including expected inputs and conditions.
2. Carrying out vulnerability scanning to detect insecure configurations and other vulnerabilities.
3. Carrying out penetration tests to detect insecure code and design.

Outsourcing

Company follows a strict acquisition process when they outsource development or when they purchase IT components from external parties.

Company enters into an agreement with their suppliers and this agreement addresses the information security requirements as prescribed in Control 5.20.

Furthermore, Company ensures that the products and services they purchase are in compliance with the information security standards.

Additional compliance on Control 8.29 (if required)

Company can create multiple test environments to carry out various testing such as functional, non-functional and performance testing.

Furthermore, they can create virtual test environments and then configure these environments to test the IT systems in various operational settings.

Control 8.29 also notes that effective security testing requires Company to test and monitor the testing environments, tools and technologies.

Comprehensive Requirements Control 8.29

1. Security testing plan and what it should include.
2. Criteria for security testing for in-house development of IT systems.
3. Security testing process and what it should entail.
4. Use of multiple test environments.

Company to elaborate the method of security testing in development and acceptance testing environments.

Technological Control No. 8.30

Outsourced Development

Introduction

This policy addresses the Control 8.30 of ISO 27001:2022. Control 8.30 enables Company to ensure that the established information security requirements are adhered to when the system and software development is outsourced to external suppliers.

Control 8.30 is both detective and preventive in nature. It requires Company to supervise and monitor all outsourcing activities and to ensure that the outsourced development process satisfies information security requirements.

Scope

This policy applies to outsourcing activities pertaining to software development of the Company. 

Ownership of Control 8.30

Chief Information Security Officer should be responsible for establishing and implementing necessary procedures and controls to ensure those information security requirements are communicated to, agreed by and complied with by external suppliers.

Method of Compliance

General guidance highlights that Company should continuously monitor and verify that the delivery of outsourced development work satisfies the information security requirements imposed on the external service provider.

Following the recommendations of Control 8.30 Company takes into account the following 11 factors when outsourcing development:

1. Entering into agreements, including licensing agreements, that addresses ownership over code and intellectual property rights.
2. Imposing appropriate contractual requirements for secure design and coding in line with Control 8.25 and 8.29.
3. Establishing a threat model to be adopted by third-party developers.
4. Carrying out an acceptance testing procedure to ensure the quality and accuracy of delivered work.
5. Evidence that minimally-required privacy and security capabilities are achieved. This may be achieved via assurance reports.
6. Keeping evidence of how sufficient testing has been performed to protect the delivered IT system or software against malicious content.
7. Keeping evidence of how sufficient testing has been applied to protect against identified vulnerabilities.
8. Putting in place escrow agreements that cover the software source code. For example, it may address what will happen if the external supplier goes out of business.
9. The agreement with the supplier should entail the right of the organisation to perform audits on development processes and controls.
10. Establishing and implementing security requirements for the development environment.
11. Company also considers applicable laws, statutes and regulations.

Company to show the NDA with external service providers.

Technological Control No. 8.31

Separation of Development Testing and Production Environment

Introduction

This policy addresses the Control 8.31 of ISO 27001:2022. Control 8.31 enables Company to maintain the confidentiality, integrity, and availability of sensitive information assets by segregating developing, testing and production environments through appropriate procedures, controls and policies.

Control 8.31 is preventive in nature and it requires Company to pre-emptively establish and apply processes and technical controls to securely separate the development, testing, and production environments.

Scope

This policy applies to securely segregating development, test, and production environments to eliminate security risks pertaining to software development of the Company. 

Ownership of Control 8.31

Considering that Control 8.31 entails the establishment and implementation of organisation-wide processes and controls to segregate different software environments, Chief Information Security Officer with help of the development team, shall be ultimately responsible for compliance.

Method of Compliance

Company takes into account the potential production problems that should be prevented when determining the required level of separation between the three environments.

In particular, as per the recommendations of Control 8.31, Company considers the following seven criteria:

1. Segregation and operation of development and production systems to an adequate degree. For example, the use of separate virtual and physical environments for production could be an effective method.
2. Appropriate rules and authorisation procedures are established, documented, and applied for the use of software in the production environment after going through the development environment.
3. Company reviews and test changes made to applications and production systems in a test environment separate from the production environment before these changes are used in the production environment.
4. Testing in production environments are not allowed unless such testing is defined and approved prior to testing.
5. Development tools such as compilers and editors are not be accessible from the production environments unless this access is absolutely necessary.
6. To minimise errors, proper environment identification labels are prominently displayed in menus.
7. Sensitive information assets is not transferred into development and testing environments unless equivalent security measures are applied in the development and testing systems.

Additional practices on Protection of Development and Testing Environments

Company protects development and testing environments against security risks by taking into account the following:

1. All development, integration, and testing tools such as builders, integrators, and libraries are regularly patched and updated.
2. All systems and software are configured securely.
3. Access to environments are subject to appropriate controls.
4. Changes to environments and code stored in it are monitored and reviewed.
5. Environments should be securely monitored and reviewed.
6. Environments are backed-up.
7. No single individual is given the privilege to make changes in both development and production environments without obtaining approval first. 
8. To prevent this, Company has segregated access rights or establish and implement access controls.
9. In addition, Company has considered extra technical controls such as logging of all access activities and real-time monitoring of all access to these environments.

Further Guidance on Control 8.31 (only if required)

1. If Company fail to implement necessary measures, their information systems can face significant security risks.
2. For instance, developers and testers with access to the production environment may make unwanted changes to files or system environments, execute unauthorised code, or accidentally disclose sensitive information.
3. Therefore, Company need a stable environment to perform robust testing on the code and to prevent developers from accessing the production environments where sensitive real-world data is hosted and processed.
4. Company should also apply measures such as designated roles together with separation of duty requirements.
5. Another threat to the confidentiality of production data is the development and testing personnel. When the development and testing teams perform their activities using the same computing devices, they may accidentally make changes to sensitive information or software programs.
6. Company are advised to establish supporting processes for the use of the production data in testing and development systems in compliance with Control 8.33.
7. Moreover, Company should take into account the measures addressed in this Control when they perform end-user training in training environments.
8. Last but not the least, Company may deliberately blur the lines between development, testing, and production environments. For instance, testing can be performed in a development environment or product testing can be carried out by actual use of the product by staff in the organisation.

Company to show proof that it has separated the development, testing and production environments. (E.g., AWS agreement).

Technological Control No. 8.32

Change Management Policy

Purpose

This Policy addresses the Control 8.32 of ISO 27001:2022. Control 8.32 addresses how Company can establish and apply change management procedures to monitor, review and control changes made to the information processing facilities and systems. To define a Change as understood by the Company Name and describe the accepted Change Management procedure.

Control 8.32 enables Company to maintain the security of information assets when executing changes on the information processing facilities and systems by establishing, implementing and managing change management rules and procedures.

Control 8.32 is preventive in nature. It requires Company to define, document, specify, and enforce change control processes that govern the entire life cycle of information systems, from the initial design to the deployment and use.

Scope

This procedure is intended for all Department Managers who have identified a change requirement. Only Department Managers and the top Management may request a change.

Ownership of Control 8.32

Considering that compliance with Control 8.32 entails the establishment and enforcement of change control procedures that apply to all stages in the life cycle of information systems, Chief Information Security Officer with the support of domain experts, is responsible to design and enforce these procedures.

Method of Compliance

All major changes to information systems and the introduction of new systems should be subject to an agreed set of rules and procedures. These changes should be formally specified and documented. Furthermore, they should go through the testing and quality control processes.

To ensure that all changes comply with the change control rules and standards, Company should assign management responsibilities to appropriate management and should set out the necessary procedures.

Company has adapted Control 8.32 (nine elements that are included) in the change management procedure:

1. Company plans and measures the likely impact of planned changes, taking into account all dependencies.
2. Implementing authorization controls for changes.
3. Informing relevant internal and external parties about the planned changes.
4. Establishing and implementing testing and acceptance testing processes for changes in accordance with Control 8.29.
5. How the changes will be implemented, including how they will be deployed in practice.
6. Establishing emergency and contingency plans and procedures. This may also include setting out a fall-back procedure.
7. Keeping records of all changes and related activities, including all activities listed above (1 to 6).
8. Operating documentation as required in Control 5.37 and user procedures are reviewed and updated to reflect the changes.
9. ICT continuity plans and recovery and response procedures should be reviewed and revised to reflect the changes.
10.  Company should integrate change control procedures for software and ICT infrastructure to the maximum extent possible.

Additional points as per Control 8.32

Changes to the production environments such as operating systems, and databases may compromise the integrity and availability of applications, particularly the transfer of software from development to production environment.

Another risk is that, Company is cautious against is changing software in the production environment may have unintended consequences.

To prevent these risks, Company performs tests on ICT components in an environment isolated from the development and production environments.

This will enable Company to have greater control over new software and will provide an extra layer of protection for real-world data used for testing purposes. This extra protection can be achieved via patches and service packs.

Risk

In the Company, if the changes are not properly controlled they could negatively impact on the business and prevent people from fulfilling their roles.  It could be made by individuals who are not fully aware of the impact on other areas of the business. If change is not controlled the business could be exposed to fraudulent activities.

Responsibility

• The Department Manager ensures that changes follow the Change Management Procedure.
• On a regularly basis the CISO or ISC shall review them and ensure all changes follow as per this procedure.
• The Top Management shall review them quarterly or on a regularly basis to ensure their commitment towards application of this procedure. 

Roles

• In respect to each department within Company, the respective Department Manager shall suggest changes that are in particularly applicable.   
• They shall facilitate communications between Information Security Coordinator and the members representing Information Security Committee, referred in this document as Stakeholders. 
• The particular Departmental Manager shall co-ordinate all of the documentation, acquisition of requirements, formulations of plans and scheduling of projects and tasks. The other stakeholders shall review, comment on the changes suggested.  
• The changes along with the other reviews and comments of the Stakeholders shall be placed before the Top Management who shall authorize the same.  
• The Departmental Manager shall be responsible for implementing the changes within the organization and ensure that the change goes as smoothly as possible that compliance is retained. 

Change Procedure

For compliance purposes all communications need to be in writing, i.e. by email, meetings need to have minutes taken etc. This documentation will be retained by the Information Security Coordinator and filed with the Change Documentation relating to the change. For this reason verbal requests and authorization are not acceptable.

Submit the Change Request Form

• Complete a Change Request Form. This form and information about how to complete it can be found with the IT Manager.
• Enter as much detail as possible in the Request Details section. If this change will affect other departments please enter the names of the Department Managers in the Other Departments Affected section. 
• Once the form has been completed use the office or branch scanner to scan the authorized form and email it to the IT Help desk. They will log the form and pass it to the Information Security Coordinator so that the change can be scheduled.

Review the Specification

The Change Request form will be reviewed by the Information Security Coordinator who will gather additional information, add Department Managers deemed to be affected and arrange meetings. Then the ISC creates a Specification detailing exactly what is being changed, which is sent to all Stakeholders. The Specification should incorporate all the requirements.

• The Change Stakeholders carefully review the Specification to ensure that all the requirements and their particular interests are covered.
• The Change Stakeholders will need to approve the specification by email.

Note regarding the Change Rating

The ISC will discuss what the appropriate Change Rating should be with all the Stakeholders.  In essence the Change Rating indicates the level of compliance required by the change and the priority that the change is being given. 

The Risk Assessment

The Information Security Coordinator will conduct a risk assessment based on the agreed specification. They will check all the systems and processes affected by the proposed change and list any risk areas. The Risk Assessment is used to create a change Recommendation to ensure that any risk to the business has been identified and mitigated. The Recommendation will include items such as specific training and testing requirements. A copy of the Risk Assessment, including the recommendation, will be sent to the Stakeholders.

• Check the Risk Assessment and Recommendation carefully to make sure that nothing has been missed.
• Notify the Information Security Coordinator, by email, of any missing risks or if there are problems with the Recommendation.
• Authorize the Risk Assessment and Recommendation by email.

The Implementation Plan

The Implementation Plan details all the stages that are required in order to successfully manage the change and includes a plan outlining testing and any back-up strategy that needs to be in place. In more complicated changes this may also include a project schedule and timeline.

• Review the Implementation Plan.
• Make the Information Security Coordinator aware of any amendments or changes.
• Make note of the timeline and any training or testing and how this will affect department staff.
• Make note of any dependent tasks (i.e. if one department is unable to make a change until another has completed theirs).
• Authorize the Implementation plan by email.

Pre-Change

Once the Implementation Plan has been approved it is vital that the staff in each department are made aware of what needs to happen, when and by whom. 

The Department Manager shall:

• Notify affected staff of the change and assigns actions and makes them aware of the backup strategy.
• Ensures that staff/resources who have been assigned responsibilities in implementation shall have copies of the plans defined regarding test and are aware that all test documentation are to be retained.
• Liaises with other Stakeholders and the Information Security Coordinator to ensure that all aspects of the change are progressing as planned.

Change

To minimize unnecessary disruption ensure that the plan is followed as closely as possible and any issues are highlighted to the ISC as soon as possible. The ISC will co-ordinate communications between all the Stakeholders and ensure all staff follow the Implementation Plan.

Post Implementation Review:

• Once a change has been implemented it is important that the situation is reviewed to identify any problems that could be prevented in future or improvements that could be made. 
• The Stakeholders will carry out a Post Implementation Review one month after the change has been promoted to Live (unless problems or issues present themselves more immediately). 
• Two months after the change has been implemented the Stakeholders will conduct a further review. 
• An internal audit by Auditors shall be conducted on the reviewed Change Documentation and their comments and recommendations will be reported to the Management for review.  The minutes and action points of these reviews are held on file with the Change Documentation.

Technological Control No. 8.33

Test Information

Purpose

This document addresses the control 8.33 of ISO 27001:2022. Control 8.33 enables Company to achieve two purposes. To protect and maintain the confidentiality of information used in the testing environment. Selection and use of test information that will yield reliable results.

Control 8.33 is a preventive type of control that requires Company to select and protect the most appropriate information for the testing stage so as to maintain the confidentiality and integrity of information.

Scope

This policy applies to development of non-production test environments such as staging environments that are essential to building high-quality software products and applications free of bugs or errors, the use of real data and lack of security measures in these environments expose information assets to heightened risks.

Ownership of Control 8.33

Considering that Control 8.33 entails the selection, protection, and management of the most appropriate test information to be used for testing, Information Security Officer in cooperation with the development team, is ultimately responsible for establishing appropriate controls and procedures.

Methodology of meeting the requirements

Company doesn’t not use sensitive information, including personal data, in the development and testing environments.

To protect the test information against loss of confidentiality and integrity; Company complies with the following.

1. Access controls applied in real-world environments are also implemented in test environments.
2. Establishing and implementing a separate authorisation procedure for the copying of real information into test environments.
3. To keep an audit trail, all activities related to copying and use of sensitive information in test environments is recorded.
4. If sensitive information is used in the test environment, it is protected with appropriate controls such as data masking or data removal.
5. Once the testing is completed, information used in the test environment should be safely and permanently removed to eliminate the risk of unauthorised access.
6. Company should apply appropriate measures to ensure the secure storage of information assets.

Company to demonstrate how it protects the test data.

Technological Control No. 8.34

Protection of Information Systems during Audit Testing

Purpose

This document addresses the Control 8.34 of ISO 27001:2022. Control 8.34 enables Company to eliminate and mitigate risks to the security of information systems and to the continuity of business operations by establishing and applying suitable measures and controls such as access restrictions and read-only access limitations.

Audit tests play a critical role in detecting and eliminating security risks and vulnerabilities in the information systems. However, the audit process, whether performed in operational, testing, or development environments, can expose sensitive information to the risks of unauthorized disclosure, or loss of integrity and availability. 

Control 8.34 deals with how Company can maintain the security of information assets during audit tests.

Control 8.34 is preventive in nature as it requires the upper management and the auditor to plan and agree on audit testing procedures, restrictions, and controls prior to carrying out audits.

Scope

This policy applies to audit tests that play a critical role in detecting and eliminating security risks and vulnerabilities in the information systems.

Ownership of Control 8.34

The IT management team led by CISO is responsible to plan and agree on audit procedures and to create and apply necessary measures.

Process of Compliance

Control 8.34 lists eight specific requirements that Company will consider:

1. Appropriate management and the auditor should agree on access to systems and information assets.
2. Agreement on the scope of technical audit tests to be performed.
3. Company can only provide read-only access to information and software. If it is not possible to use the read-only technique, an administrator with necessary access rights can gain access to systems or data on behalf of the auditor.
4. If an access request is authorized, Company should first verify that devices used to access systems meet the security requirements before they provide access.
5. Access should only be provided for isolated copies of files extracted from the system. These copies should be permanently deleted once the audit is complete unless there is an obligation to retain those files. If read-only access is possible, this control does not apply.
6. Requests by auditors to perform special processing such as deploying audit tools should be agreed upon by the management.
7. If an audit runs the risk of impacting system availability, the audit should be carried out outside of business hours to maintain the availability of information.
8. Access requests made for audits should be logged for the audit trail.

When audits are performed on testing or development environments, Company should be cautious against the following risks:

1. Compromise of the integrity of code.
2. Loss of confidentiality of sensitive information.

Company to show evidence regarding how the information systems will be protected during audit testing.