ISO 27001:2022 | ISO 27002:2022

ANNEX A CLAUSE 8.2 PRIVILEGED ACCESS RIGHTS

Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Confidentiality #Identity_and_acc #Protection

#Preventive #Integrity #Protect ess_management
#Availability

Control Statement
The allocation and use of privileged access rights should be restricted and
managed.

Requirement
Privileged access rights refer to the level of access granted to users, software
components or services within a system, network, or application that allows
them to perform actions beyond the scope of normal/standard users. These
rights typically include permissions to access sensitive data, modify system
settings, install software, or perform other administrative tasks. Privileged
access is often granted to individuals who require elevated permissions to
carry out their job responsibilities effectively, such as system administrators,
IT support personnel, or database administrators. However, it's crucial to
carefully manage and restrict privileged access to minimize the risk of
unauthorized actions, data breaches, or malicious activities.

Implementation
Privileged access rights are access rights that allow an identity, a role or a
process to perform an activity that is not a part of normal operations but
elevated operations. Roles like system administrator, power administrator
require privileged rights. In any information system privileged access rights
enables the user to carry out system management activities, override system
or application controls.
Intentional or unintentional Inappropriate use of privileges can lead to
failures or breaches of systems and is a major contributor to disruption.
If grant of privileged access is uncontrolled then an increasing number of
users will be using the access privileges, and the implemented access controls
will be rendered pointless. The unnecessary allocation and use of privileges is
a major contributing factor to escalation of privileges. The misuse of
privileges can lead to loss of confidentiality through exposure, loss of integrity
and unavailability of services are typical consequences. cont. ….

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.2 PRIVILEGED ACCESS RIGHTS
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Confidentiality #Identity_and_acc #Protection

#Preventive #Integrity #Protect ess_Management
#Availability

…. cont.

In any organization management of privileged access to system is politically

challenging. A typical system many need access from different entities
specially in large organizations where system, database, application
development and operations teams are different. Different administrators will
always want to do their work with minimum hindrances and as access control
can cause hinderance sometimes all different administrators (OS, Database,
Application) want to do work with maximum privileges. Different
administrators will always persuade system owners to authorise maximum
privileges that are not really always required. Privileges are seen as “cheat
codes” in a computer game that allows you to get to a higher level without
doing all the hard work. The fact is that a carefully designed RBAC will allow
all administrators to do their work in perfectly efficient manner.

The first task for system owner is to identify the required privileges. Modern
systems have built in RBAC capabilities. Any assignment of privileges should
be provided on a business justification. Hence grant of any privilege should
be done via a documented Service Request. The service request should have a
justification for privileged access and approval from requestor’s manager
and the system owner. If access is granted to third-parties to whom IT
operations are outsourced partly, or fully then special care should be taken.

There also might be a situation in which privileged access may be required to

be granted on an urgent basis such as a system outage. These situations may
require granting privileges to a normal user.

MFA should always be considered for privileged users. An organization might

not use MFA for normal users but is highly recommended for privileged
users. Also privileged users should not have properties like “password doesn’t
expire”.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.2 PRIVILEGED ACCESS RIGHTS
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities
#Confidentiality #Human_resource #Governance_and
#Preventive #Integrity #Protect _security _Ecosystem
#Availability
…. cont.

The system owner before approving the request should ensure that the
requestor has necessary competence to carry out activities that require
privileged access. A record should be maintained of all users who have been
granted privileges.
A highly recommended practice is to not grant privileges to a user’s normal
day-to-day but use different ids for privileged. As an example, if an
organization uses [Link] as normal ID then they can use
firstnameadmin or superfirstname as privileged ID ensure that users are aware
of their privileged access rights and when they are in privileged access mode.
Another recommended practice is to have authentication requirements for
privileged access rights can be higher than the requirements for
normal access rights. As an example, if normal ID requires 8-character
password then privileged ID should have 14-character password.

It is also recommended to set up privileged IDs with properties like “Do not
remember passwords” and “ask every time”.

Organizations should ensure not to generic built-in super administrators like

“Administrator” in Windows or “root” in Linux for day to day activities.
They should be reserved for emergency use only. This is often referred as
break glass procedure. Moreover, for Windows OS the Administrator should
be managed using LAPS.

Further nowadays it is always recommended to use a PIM (Privileged

Identity Manager) and PAM (Privileged Access Manager) for privileged
access. A PIM solution provides JIT (just in time) access and manages the
passwords of privileged users, thus users do not require to memorize the
passwords. Access is granted only when required and for a fixed time
interval only. A PAM solution constantly monitors & logs the privileged
access. Even if a PIM/PAM solution is not used all privileged access should be
logged.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.2 PRIVILEGED ACCESS RIGHTS
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities
#Confidentiality #Human_resource #Governance_and
#Preventive #Integrity #Protect _security _Ecosystem
#Availability
…. cont.

Privileged IDs should not be ideally shared. Avoid linking identities with
privileged access rights to multiple persons. If there are multiple
administrators. assigning each person a separate identity which allows
assigning specific privileged access rights. Such situations can be avoided by
using a PIM/PAM solution.

PIM/PAM solution helps to grant temporary privileged access just for the
time window necessary to implement approved changes or activities (e.g. for
maintenance activities or some critical changes), rather than
permanently granting privileged access rights. This is often referred as just-
in-time (JIT) access.

Using identities with privileged access rights ONLY for undertaking

administrative tasks and not for day-to-day general tasks (i.e. checking email,
accessing the web)

Finally, organizations should implement a six-monthly PAR process. PAR is

privileged access revalidation or privileged access review where the system
owner extracts all the privileged users in the system and a revalidation is
performed to determine if there is a continued business requirement of the
user to have the privileged access. This revalidation justification should be
performed by the user’s manager.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.3 INFORMATION ACCESS RESTRICTION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_man #Protection
#Integrity agement
#Availability

Control Statement
Access to information and other associated assets should be restricted in
accordance with the established topic-specific policy on access control.

Requirement
It is required that an Organization establishes an Access Control Policy. It
should determine all aspects of logical access control. The objective is to
prevent unauthorized access to information systems including business
applications.

Implementation
Every information system and business application should have an owner and
owner should determine what access rights and rules should exist for that
system. This is determined by the classification level of the information/data
contained in the system and should be in accordance with the business
requirement. For this the organization should establish and document an
access control policy (topic-specific policy) and detailed guidelines for
granting and revoking access. The policy should define who will have access,
how the access should be obtained, how access should be granted and how
level of access should be maintained.
Without a strict access control policy enforced in place there is a high
probability that users will be given access more than they require and access
to too much information or too many system privileges. The improper access
control mechanisms lead to a high risk of breach of confidentiality, loss of
integrity and loss of availability. It can also impact business in form of fraud
in financial applications or theft of intellectual property.

When developing an access control policy, we should consider below -

Avoid anonymous access, anonymous access should be granted only to
publicly available information one that would be on your public website.
Least Privileged Access - Least Privileged Access is the principle of providing
users or processes with only the minimum level of access necessary to

[Link] cont….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.3 INFORMATION ACCESS RESTRICTION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_ #Protection
management

perform their required tasks, reducing the risk of unauthorized access and
potential security breaches.

Role based access control - Role-Based Access Control (RBAC) is a security

model where access rights are assigned based on roles rather than individual
users. Users are assigned roles, and permissions are granted to those roles,
streamlining administration and enforcing the principle of least privilege.

Implement a strong password policy and multi-factor-authentication.

Mechanisms should be in place in systems, applications and IT services to

control access based in principles of least privilege. This should be
determined by the role of the user and classification of the information asset.
e.g. a database administrator should not have rights to start/stop any services
on the OS except those related to database management. A database
administrator should have rights to install database updates but not OS
updates.
For data repositories access control should be in place for controlling which
data can be accessed by which user e.g. sales team should not have access to
budget or payroll data. The data should be isolated based on its sensitivity
and classification level.
The policy should define the minimum access that every employee should
have such as read only access to Intranet, email, ESS etc and the procedures
for having the required additional access. Any privileged access should be
granted on demand via documented service requests.

Granular access control can be managed via implementing a dynamic access

management using a IAM tool. The IAM tools manage SSO (single sign on)
and grants access automatically depending on department, designation, role,
location etc. Implementation of an IAM solution is required for easy of
management in large organizations. Depending on the designation and
location and IAM solution will automatically assign the required rights &
applications in an ERP solution. An IAM solution can also centrally monitor
all access.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.4 ACCESS TO SOURCE CODE
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_man #Protection
#Integrity agement
#Availability #Application_security
#Secure_configuration

Control Statement
Read and write access to source code, development tools and software
libraries should be appropriately managed.

Requirement
If access to program source code and libraries is not restricted and properly
controlled, then an unauthorised access either intentional or unintentional
will cause tampering of the source code leading to bugs and errors. Also, in
some cases accidental deletion can cause loss of availability. Such issues in
development environment can cause not only security issues but severely
impact the deadlines of the projects. Also if production data is used in
development environment, then confidentiality can be compromised.

Implementation
Serious security problems can arise if malicious actors gain unauthorised
access to the program source code. They can modify the source code to drop
in a vulnerability or an exploit. Source code can provide an attacker with a
perfect starting point for understanding the functionality in a system or
application. Same applies to development tools, designs, plans etc. which are a
part of software development.

Proper protection of source code needs strict and effective procedures. The
first and foremost recommendation is to isolate the source code from
production applications and data. The source code should be stored in
dedicated and isolated repositories i.e. source code management system .
A centralised repository should be preferred. These centralised source code
repositories should not reside in a production environment and not accessible
from production systems.
Further for logical access control it is advisable that users from operations or
regular users are not granted access to repositories.
cont….

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.4 ACCESS TO SOURCE CODE
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_man #Protection
#Integrity agement
#Availability #Application_security
#Secure_configuration
Only authorized developers should be granted access to these that too after
proper authorization procedures.

Based on role of personnel in a development team we can give read or write

access. Only designated developers should be provided write access to source
code specially is the size of the development team is large and there is one or
more third-party developers involved in a project. In a large project with
multiple modules and different developers working on different modules the
access should be restricted to respective modules and read and write access to
source code should be based on business needs.

Plans should be in place to mitigate risks of unauthorised alteration and

misuse of source code.

Changes and updates to source code should follow a formal change

management process.

Wherever possible direct access to source code files should be avoided and
access should be via a source code management system or developer tools
only where all activities should be logged.

Finally, an audit trail of all changes to the source code should be maintained.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.5 SECURE AUTHENTICATION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_man #Protection
#Integrity agement
#Availability

Control Statement
Secure authentication technologies and procedures should be implemented
based on information access restrictions and the topic-specific policy on
access control.

Requirement
The access-control is fundamentally AAA – Authentication, Authorization,
and Accounting. Authentication is the first requirement that means Verifying
the identity of users or entities trying to access an information system or an
information resource. These three components work together to ensure that
only authorized users can access appropriate resources, and their activities
are monitored and recorded appropriately. Secure Authentication ensures
that the user attempting to access a system, application or a resource is who
they claim to be

Implementation
A basic authentication technique that has always exist is username and
password. The username is unique to an individual or a service which
substantiates the claimed identity of a user or a service. Password is
something that is known only to the user. Passwords should not be displayed
and should not be stored or transmitted in clear text.
Now there are several alternatives to password such as smart cards, tokens,
digital keys etc.
First the organization should implement a Password Policy some aspects of
password policy include password length, age, complexity.
Earlier it was recommended to have policies like a minimum of 8 characters,
max age of 90 days, require numerals & special characters however a modern
password policy focusses on password length & not age or complexity.
Second is to implement an account lockout policy which locks out an account
after some incorrect attempts.
The password policy can be proportional to the sensitivity or classification of
the application / data to be accesses e.g. for less sensitive data we can
implement an auto unlock after 30 mins and for more sensitive data only
cont…. [Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.5 SECURE AUTHENTICATION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_man #Protection
#Integrity agement
#Availability

an administrator should be able to unlock accounts.

Now-a-days implementation of MFA (multi-factor-authentication) is always

recommended for accessing business information systems and critical
information systems like online banking and e-commerce. MFA is simply
about a combination of something what you know (Password) and something
what you have (a token, an OTP, a certificate). MFA reduces the possibility of
unauthorised access to a great extent. Cloud applications allow you to enforce
MFA in circumstances such as logging from a new location a new device or a
new application.
Still higher degree of authentication is provided by Biometric Authentication.
However Biometric Authentication should follow all the privacy regulations
and biometric data should be secured and sharing limited to minimum e.g.
having the biometrics stored locally on device with proper encryption
techniques.

If multiple business applications are run implementation of a SSO solution

also helps to reduce risk. SSO prevents to have a single strong password
policy applied across multiple information systems.

The logon procedure should have a mechanism to terminate inactive session

after a defined period of inactivity. The ideal time is 30 minutes for low
critical systems and 10~15 minutes for high critical systems.
For passwords they should never store or transmitted in plain-text.
All login events (both successful & unsuccessful) allow, deny, lock, unlock
should be logged along with timestamp.

If possible, the last login details should be displayed however it is not always
required. It does not happen in Windows. Also, its always recommended to
have a login warning / disclaimer banner after successful login stating terms
& conditions notice warning that the system or the application or the service
should only be accessed by authorized users

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.5 SECURE AUTHENTICATION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Identity_and_access_man #Protection
#Integrity agement
#Availability

Using a mechanism like SIEM , administrators and Security team should be

alerted when there are events like a brute force attempt during logon
procedures.
Finally, a mechanism like CAPTCHA is recommended to protect against
brute-force attacks via Bots. This is required to distinguish human behavior
from a bot behavior.

Another aspect is that all the above policies can be made more stringent for
users with elevated privileges or super administrators.
e.g. if regular users require 8-character password, then administrators should
require 14-character passwords.
If regular accounts require 5 unsuccessful attempts, then administratrive
accounts should require 3 unsuccessful attempts.

For administrative users' implementation of a PIM solution is recommended

which provides a mechanism of JIT (just-in-time) access where access is
provided only on-demand for a fixed period (e.g. 4 hours)- The PIM can
incorporate an approval workflow where manager or system owner approval
may be required.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.6 CAPACITY MANAGEMENT
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Continuity #Protection
#Detective #Availability #Identify
#Detect

Control Statement
The use of resources should be monitored and adjusted in line with current
and expected capacity requirements.

Requirement
Any Information and Technology resources should adjust according to the
growth of organization and usage. This includes hardware resources, software
resources, licenses & subscriptions and human resources as well. To ensure
that the requirements are always met the capacity of the resources should be
proactively monitored. If resources are utilized beyond the capacity it can
lead to loss of availability also unwanted corruption of information leading to
loss of integrity. Hence resources should be tuned to maintain the system
performance. Also, projections should be made for future.

Implementation
The requirements for Information Technology are growing every day for
organizations with new technologies being introduced into business processes.
Hence the resources in information processing facilities should be sufficient to
support the growing business which includes both in terms of employees as
well as customers. If resources are inadequate, then there is a risk of loss of
availability of these services.
Hence first step is to identify the resources like hardware, software,
subscriptions, person, connectivity, power etc. Second step is to establish an
automated or manual monitoring of these resources both in terms of
availability and capacity. Availability checks if the resource is available or not
whereas capacity monitors the utilization of the resources. The capacity
monitoring helps to fine tune i.e increase the resources when required and
and helps to project future requirements with support of user planning
inputs. As example for an e-commerce company the capacity of the web-
server needs to be bumped up during discount events like black Friday. Also
the organization strategy will help to determine the projected increase in
employees then the additional hardware and software licenses requirement.

cont…. [Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.6 CAPACITY MANAGEMENT
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Continuity #Protection
#Detective #Availability #Identify
#Detect
For hardware resource monitoring a system which monitors hardware
utilization across the Information Processing facilities should be
implemented. This helps us detecting problems in capacity to ensure
corrective action. Sudden shoot-up in CPU or Memory utilization will result
in poor performance of the services. This is true for communication networks
as well where changes in load can be sudden and lead to unproductivity.

Another suggestion though not mandatory is to perform stress-tests of

systems and applications to confirm that the capacity is able to meet peak
performance requirements.

Cloud services provide option of on-the-fly increases and decreases in the

hardware capacity to match peaks and troughs in the demand.

Capacity Management should also be prioritised for critical systems, these

systems that support critical business processes like core banking, internet
backing in a bank should be monitored continuously and alerts sent to the
administrators for timely action. Particular attention should be paid to any
resources with long procurement lead times or high costs.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.7 PROTECTION AGAINST MALWARE
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #System_and_network_ #Protection
#Detective #Availability #Detect security #Defence
#Corrective #Confidentiality #Information_protection

Control Statement
Protection against malware should be implemented and supported by
appropriate user awareness.

Requirement
Malware has been there as long as computers have been themselves.
Commonly referred to as “Computer Viruses” malware has evolved as much
to include worms, spyware, trojans and most devastating of them all
“ransomware”. The malware remains a threat even to the present day and
poses a danger. Organizations need to ensure that information assets are
protected against malware both for servers, endpoints and data in transit.

Implementation
All operating systems are vulnerable to malware and even operating systems
running on non-computing devices like network devices, security devices,
control systems. Though some OS are inherently more vulnerable compared
to others. Malware has been there ever since the dawn of the computers and
continues to be one of the foremost cybersecurity threats. Malware exploits
vulnerabilities and it is very easy for computers to be exploited by malware,
we have observed many malware outbreaks where a malware spread across
the globe in a matter of days faster than a pandemic. Some malware are easy
to get rid of and some can be difficult and costly to get rid of. Some malware
have a low impact like causing simply a nuisance and others can knock off
systems and steal data. With computer networks and internet connecting
billions of computers across globe malware can have a devastating impact on
confidentiality, integrity and availability.

The foremost control in malware control is using an “Antivirus” software.

The use of an antivirus is necessary and should be strictly applied and
followed. Antivirus software has also evolved with the complexity of the
viruses. Early antivirus was a ‘signature-based’ antivirus and used to scan
files on a computer for any matches to “known patterns”. Modern
antimalware
[Link]
cont….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.7 PROTECTION AGAINST MALWARE
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #System_and_network_ #Protection
#Detective #Availability #Detect security #Defence
#Corrective #Confidentiality #Information_protection
Are referred to as “Endpoint Security Solutions” these solutions offer
protection not only against malware like viruses, worms, trojans, spyware etc
but also offers other features like HIPS (Host intrusion prevention), host
firewall, device control, application control etc. In addition to the “signature
based” the “Endpoint Security Solutions” are “behavior based”.

All devices should have “Endpoint Security” installed and running including
servers, smartphones and tabs.
The “Endpoint Security” should be centrally managed and signatures should
be updated regularly.
Normal users should be prevented from making any changes to the
“Endpoint Security” settings i.e. the solution should be tamper proof.
Users should be restricted if the signatures are too outdated e.g. more than 7
days old.
A solution should be in place that scans all incoming emails (including
attachments) for malware.
A solution should be in place that scans all incoming web traffic(including
downloads) for malware at the perimeter.
For file repositories or any application with file upload a solution should be in
place that scans all files for malware during uploads.
A Defence in Depth requires that every vulnerable area should be scanned for
malware in a network gateway in various application protocols such as email,
file transfer and web.

It is important that each malware protection mentioned above is up to date

with latest scan engines and signatures. All updates should be set to dynamic
or auto update. Updates are important to ensure protection remains effective.

User awareness also plays an important role in malware prevention. When

the user community is aware the probability of the failure of technical
controls is reduced. The user will be careful in what websites to visit , which
files to download, which emails to open etc.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.7 PROTECTION AGAINST MALWARE
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #System_and_network_ #Protection
#Detective #Availability #Detect security #Defence
#Corrective #Confidentiality #Information_protection
Other mechanisms other than an “endpoint security” should be implemented
Prevent installation of unauthorised software
Implement a Web Security URL filter to block malicious websites
Implement a Vulnerability Scanning solution and remediate the
vulnerabilities discovered.
Ensure that security patches are implemented timely.
Validate the software applications installed on systems periodically
Automatic scanning of external portable storage or block external portable
storage at all.

Finally, the Information Security should collect information about new

malware, such as subscribing to mailing lists or reviewing relevant websites
and ensuring that the anti-malware solution protects against these new
malware. warning bulletins relating to malware should come from suppliers
of malware detection software. It is advisable to subscribe to bulletins from
other vendors apart from the one implemented in the organization.

A malware outbreak scenario e.g. ransomware should necessarily be included

in the “Incident Response Plans” and “Business Continuity Plans” for
recovering from malware outbreaks.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.8 MANAGEMENT OF TECHNICAL VULNERABILITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Threat_and_ #Protection
#Availability #Identify vulnerability_ #Defence
#Confidentiality management

Control Statement
Information about technical vulnerabilities of information systems in use
should be obtained, the organization’s exposure to such vulnerabilities should
be evaluated and appropriate measures should be taken.

Requirement
All kind of Software suffer from vulnerabilities including Operating Systems,
Middleware, applications and even firmware. Technical vulnerabilities are
essentially weaknesses in your computer systems that attackers can exploit to
Gain unauthorized access to your systems and data , Disrupt or disable your
computer systems or Install malware or steal sensitive information. These
vulnerabilities can arise from several factors; hence it is important to have a
knowledge of all the vulnerabilities and take all steps to prevent exploitation
of the vulnerabilities.

Implementation
Most of the attacks on organization's information systems are based on
exploitation of the vulnerabilities. Most of the dangerous global malware
outbreaks have been due to exploitation of the vulnerabilities. One of the
most notorious malware SQL Slammer worm exploited a buffer overflow
vulnerability in Microsoft SQL Server. This specific vulnerability was
released six months before the worm appeared in year 2002. In 2002
organizations didn’t focus on patching, it organizations had applied the patch
timely the worm wouldn’t have caused the havoc it did. The vulnerability was
a Buffer Overflow vulnerability in SQL Server Resolution Service.

First of all, the Organization should have an inventory of all software systems
and have procedures in place to identify the technical vulnerabilities in a
timely way. Organizations should subscribe to mailing lists from the software
vendors and cybersecurity organizations as MITRE and NIST. NIST
maintains a National Vulnerability Database (NVD) at [Link]

cont….
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.8 MANAGEMENT OF TECHNICAL VULNERABILITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Threat_and_ #Protection
#Availability #Identify vulnerability_ #Defence
#Confidentiality management
Microsoft published its vulnerabilities every second Tuesday of the month,
other software vendors similarly publish vulnerabilities monthly or quaterly.

Multiple Vulnrability scanning tools are available in market and

organizations should implement a vulnerability scanning tool and run
periodic (preferably monthly) scans to identify the vulnerabilities.

Additionally organizations should implement the appropiate response to such

vulnerabilities. The foremost response is to implement a `Patch Management`
process. Please note that when a vendor announces vulnerabilities it provides
a fix in form of software patch (most of the time) or some mitigation steps.
Hence organization should implement a patch management process where
there shouls be a process in place to apply the patches timely (preferably
depending on the criticality of the patch) it is generally within 15 days after
patch was released. In some cases when a software vendor releases an
‘urgent’ patch for a vulnerability that is being activly exploited the patch
requires to be applied immidiately.

The necessary roles and responsibilities for this process should be identified ,
if an organization has hundreds of Windows server , we may need to assign a
dedicated resources for Vulnerability fixing and patch management.
Also the vulnerability scan reports give the steps for fixing the vulnerabilities.

If a vulnerability has been identified, the organization should identify the

risks related to this vulnerability e.g. the criticality, the exploitation factor,
how many systems are affected, are any internet published servers affected,
are any critical servers affected that support critical business processes etc.
According a suitable action should be decided e.g. to install the patch or not
and how soon the patch should be installed.
If the patch should be installed the organization should ensure that it is tested
prior to installation and there should be rollback procedures in place to go
back to the previous state if patch causes unforeseen problems.
cont….
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.8 MANAGEMENT OF TECHNICAL VULNERABILITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Threat_and_ #Protection
#Availability #Identify vulnerability_ #Defence
#Confidentiality management
The Patch application or any other fix that is implemented for mitigating the
vulnerabilities should follow a ‘Change Management’ process where a
Business Impact Analysis is performed.
The Vulnerability Management process also depends on the size of the
organization and the information classification, a small organization or that
handles non-sensitive information may simply choose to install the patches
without testing whereas large organizations or organizations handling
sensitive information may follow a robust vulnerability management process.

If no patch is available or patch cannot be installed, then compensating

controls should be considered. Software Vendors my provide mitigating
workarounds that can be applied. Or a “Risk Avoidance” where turning off
services or capabilities related to the vulnerability. Finally increasing
monitoring to detect actual attacks.

The vulnerability management process should be based on the Risk

Assessment that takes into account the requirements for resilience i.e.
addressing systems at high risk first .

An audit log should be kept for all steps undertaken in technical vulnerability
management process should be regularly monitored and evaluated in order
to ensure its effectiveness and efficiency.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.9 CONFIGURATION MANAGEMENT
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Secure_configuration #Protection
#Availability
#Confidentiality

Control Statement
Configurations, including security configurations, of hardware, software,
services and networks should be established, documented, implemented,
monitored and reviewed.

Requirement
Configuration Management is crucial for maintaining the security and
stability of IT systems. It ensures that systems are configured securely,
changes are controlled, and any deviations are identified and addressed
promptly to ensure hardware, software, services and networks function
correctly with standardized security settings, and configuration is not altered
by unauthorized or incorrect changes.

Implementation
“Configuration Management” is a new introduced in 2022 version of ISO
27001. Configuration management refers to the process of creating a set of
standardized security settings (configuration) for OS, Middleware, Network
devices etc. and controlling and managing changes to these standard
configurations.

The first step is to create an inventory of all IT assets, including servers

(Operating Systems), network devices, applications, middleware and
databases.
Second step is to develop a standard secure baseline configuration for each
category e.g. for each OS, middleware, database etc. It defines the desired
secure state for each IT asset's configuration. This serves as a reference point
for monitoring and ensuring systems adhere to security best practices.
These baselines should be documented and shared with administrators. These
are commonly referred to as “Hardening Checklists” or “Secure
Implementation Manuals”. Organizations should define and implement
processes and tools to enforce these baseline configurations.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.9 CONFIGURATION MANAGEMENT
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Integrity #Protect #Secure_configuration #Protection
#Availability
#Confidentiality
The source for developing “baseline” can be pre-defined templates from
vendors and from independent security organizations. CIS (Center for
Information Security) provides “benchmarks” for all common systems.
A Risk Management should always support the level of protection.

The third step is to ensure that a process is developed to ensure that every
IT system is implemented with the standard baseline before it is moved to
production. Implementing the “Hardening Checklist” at time of activation
should be a requirement. The activation of any new IT system should be via a
formal ‘Change Management’ process and the Change approvers should
ensure that the baseline has been implemented.

Further the baseline security configuration should not only be for newly
installed systems but for all operational production systems over their
lifetime. Further there should be periodic (half-yearly) monitoring and
verification procedures to revalidate that all the baseline settings are in place
and there has not been any deviation. This can involve using automated tools
to analyse the configuration and track any deviations from the security
baseline.

Finally, there may be scenarios where due to an application dependency or

other reasons a deviation from the standard baseline configuration is
necessary. These scenarios should be handled via an “Exception
Management” or “Security Override” process where the ‘Risk’ should be
accepted, and mitigations put in place.

Any proposed changes to IT system configurations should go via a formal

‘Change Management’ procedure or reviewing and approving the proposed
change to the system configuration.

The templates should be reviewed periodically and updated when new threats
or vulnerabilities need to be addressed, or when new software or hardware
versions are introduced. Changes to configurations should follow the change
management process
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.10 INFORMATION DELETION
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Preventive #Confidentiality #Protect #Information_prot #Protection

ection

Control Statement
Information stored in information systems, devices or in any other storage
media should be deleted when no longer required.

Requirement
Information stored in electronic or other format is always at risk of exposure,
theft or leakage leading to loss of confidentiality or integrity. Simply put “Do
not store the information if no longer required”. Information should be
securely deleted if no longer required except where it is required to meet
legal, regulatory or contractual requirements.

Implementation
8.10 is a new control introduced in 2022 version of ISO 27001. Organizations
tend to keep ‘stale’ information and ‘stale’ date stored in the information
systems endlessly unless it impacts the performance. This includes exited
employees' day to day data stored in file repositories, exited employees'
mailboxes etc. Some of the information may be sensitive in nature and
keeping this ‘stale’ information/data increases the risk of unauthorized
disclosure as it is obvious that controls may be ignored or weakened on the
stale data.
Hence it is important that organizations delete the data that is no longer
required and delete in a secure manner.
The deletion method employed should ensure complete erasure of the data
like zero-filling a HDD if to be reused or transferred, physical destruction of
HDD. The organization should take care of laws & regulations. Please note
that “formating” does not remove all data and it may be possible to recover
such data.
Have a employee exit process which includes purging of employee mailbox
and file repositories (e.g. OneDrive) if data is no longer required.

Physical destruction of storage media (CDs, Tapes, External HDDs,

Smartphones) if no longer required. Please note that “factory-reset” does not
remove all data and it may be possible to recover such data.
[Link]

cont. ….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.10 INFORMATION DELETION
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Preventive #Confidentiality #Protect #Information_prot #Protection

ection

If an Organization is using a third-party services e.g. a managed data-center

or cloud services , the agreements should include clauses on secure
destruction of data on demand or services are terminated. Also it is
recommended to obtain records/evidence of data destruction from the data-
center or cloud providers.

A data-retention policy should also be established (taking into consideration

business, legal and regulatory requirements) – Any data beyond the retention
period should be securely destroyed as its no longer required.

There may be other situations when data is to be destroyed

Donating old IT equipment.
Sending equipment for repairs
A contract ends.
Equipment Failure

Records of destruction should be maintained. An official record of

information deletion is useful when analysing the cause of a possible
information leakage event. For cloud service providers such records should
be obtained and maintained.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.11 DATA MASKING.

Control Type Infosec Cybersecurity Operational capabilities Security Domains

Properties concepts
#Preventive #Confidentiality #Protect #Information_protection #Protection

Control Statement
Data masking should be used in accordance with the organization’s topic-
specific policy on access control and other related topic-specific policies, and
business requirements, taking applicable legislation into consideration.

Requirement
Organizations often require to share information to stakeholders or give
access to information that contains sensitive data. The sensitive data may be
PII or PHI and it needs to be protected from exposure. This may be required
as a generic security/privacy requirement or to meet legal/regulatory
standards. In such cases the information may be shared with the sensitive
contents hidden or obfuscated.

Implementation
Data Masking is a set of procedures where sensitive data is hidden or
“masked” to protect the PII or PHI. This is true in all cases where protection
of sensitive data is a requirement either statutory or legal.
These sensitive data items may require to be concealed in special cases where
data is to be shared with third-parties e.g. an organization may be required to
share data with law enforcement agencies as a part of an investigation. Many
techniques are employed to perform this data ‘masking’ like substitution
where data is replaced with random characters or obfuscation where data is
overwritten.
Further data masking can be either static or dynamic.
 In ‘static’ masking the data is hidden in the original database or repository.
 In ‘dynamic masking the data is not touched in its original formal but its
masked in real-time and ‘on the fly’ during access e.g. via web pages,
email, document etc.
Techniques for masking also include “Anonymization” and
“Pseudonymization” where we can use algorithms in real-time to render the
PHI/PII information in data unknown in an irreversibly way
[Anonymization] or replace the PHI/PII information in data with an alias
[Pseudonymization]. In both cases the PII/PHI information cannot be
identified.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.11 DATA MASKING.

Control Type Infosec Cybersecurity Operational capabilities Security Domains

Properties concepts
#Preventive #Confidentiality #Protect #Information_protection #Protection

Additionally, even after sensitive data is masked organizations [PII

Controllers/ PII Processors] need to follow some guidelines.

 Always keep a track and record of the sharing of the masked data.
 Keep PII Principal informed and consent for data sharing even if it is
masked.
 Logical Access Controls should be applied even to the masked data.
 Employ methods that data is not shared further like restrictions on email
forwarding, uploading and printing.
 NDAs in place even if masked data is shared which ensures sufficient
restrictions requestor's further sharing with a third-party.
 A level of masking ‘strength’ i.e. obfuscation, randomization etc should be
maintained according to the sensitivity of original data and usage of
masked data i.e. reveal only the minimal ‘need-to-know’ data to the
requestor.
 Restrictions which disallow all the parties from corelating the shared
masked data.
 Ensure all legal, contractual, regulatory requirements override the data
sharing justification.
 Employ a RBAC (Role based access control) where level of masking is
determined by the requestor’s role and PII principal’s consent.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.12 DATA LEAKAGE PREVENTION
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Preventive #Confidentiality #Protect #Information_prot #Protection

#Detective #Detect ection #Defence

Control Statement
Data leakage prevention measures should be applied to systems, networks
and any other devices that process, store or transmit sensitive information.

Requirement
There can be intentional or unintentional leakage of data. Data leakage can
lead to loss of all confidentiality, integrity and availability. There can be
multiple sources of data leakage including endpoints, email or networks.
Hence it is important that appropriate measures are implemented at systems,
network levels that prevent leakage of data. In fact, just like intrusion
prevention , data leakage prevention is required at all levels where data is
stored, processes or transmitted.

Implementation
8.12 is a new control introduced in 2022 version of ISO 27001. Data Leakage
Prevention tools have been there for more than 15 years now however this has
been included as a dedicated control only in 2022 version of ISO 27001.
Data leakage prevention tools are designed to identify data, monitor data
usage and movement, and take actions to prevent data from leaking.

The first step is to classify the information as the leakage prevention controls
depend on the level of classification. The information should be labeled with
the classification.
Second step is to identify the channels of leakage, there can be multiple
channels of leakage as email, network, web, file repositories and attached
storage.
Third step is to implement the DLP at each channel like Email DLP, Web
DLP etc. These DLP solution can take appropriate steps depending on
classification of the information i.e blocking the user actions or network
transmissions that can expose sensitive information like quarantining email,
preventing web upload, block portable storage, block copy paste.

There are dedicated DLP solutions available from multiple vendors.

[Link]

cont. ….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.12 DATA LEAKAGE PREVENTION
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Preventive #Confidentiality #Protect #Information_prot #Protection

#Detective #Detect ection #Defence

In addition to implementing DLP technologies other controls are requited as

well

There can be data leakage via humans (i.e. social engineering), in this case
training & awareness helps.

Including “non-disclosure of information” as “Terms & Conditions” in

employment agreements, contracts, acceptable use policies etc.

Backups should be encrypted and logically isolated, in case of media have

strict physical access-controls.

Have proper agreements with third-party hosting providers and cloud

providers.

Holding users and data custodians accountable of actions.

In case the data is of highly secret nature , organizations can block basic
actions like copy-paste or taking screenshots.

It is the classification level of data and sensitivity of data that determines the
level of DLP controls.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.13 INFORMATION BACKUP
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Corrective #Integrity #Recover #Continuity #Protection

#Availability

Control Statement
Backup copies of information, software and systems should be maintained
and regularly tested in accordance with the agreed topic-specific policy on
backup.

Requirement
For businesses, data is often critical for operations. Accidental deletion,
hardware failure, malware attacks, or natural disasters can lead to data loss.
Loss of data can disrupt business activities, leading to financial loss, reduced
productivity, and damage to reputation. Backing up data ensures that even if
the original data is lost, a copy exists elsewhere. If data is encrypted or held
hostage by attackers, having a backup allows organizations to restore their
systems without paying ransom. Regular backups help in maintaining
business continuity by quickly restoring data after an incident. Overall, data
backup is not only important for mitigating risks but also for ensuring the
smooth functioning and resilience of businesses and individuals in the face of
various challenges.

Implementation
Information stored in digital format is always at risk of loss or corruption.
There can be partial or total loss of information and there are several threat
vectors that can cause this from malware, hardware failure to a fire or
sudden loss of utilities. In order to maintain integrity and availability of
important data the simplest control for a long time has been to make a
duplicate copy of data which is called ‘backup’.
Backup can be offline where the copy of data is made on media like tape.
[Tape based backup has been most popular since ages and Tape technology
has evolved] and the media is stored securely.
Backup can be online where a copy of data is made over a network and stored
on a different device at the same location or at an alternate location. The
alternate location should be at sufficient distance from the main site.

[Link]

cont. ….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.13 INFORMATION BACKUP
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Corrective #Integrity #Recover #Continuity #Protection

#Availability

The backup frequency, technology and location can be determined by the

sensitivity of data. More sensitive data should be backed up more frequently.

First of all, the organization should develop a Backup documented policy and
guidelines. A documented policy is to ensure that all essential information and
software can be recovered following an incident or failure or loss of server.

The backup cycle should be determined by Risk Assessment and Business

Impact Assessment (BIA). The BIA will help to determine the RTO & RPO of
applications which in turn determines the backup frequency,
Highly sensitive applications may require a real-time redundancy where data
is written simultaneously to two locations. Other sensitive applications may
require a daily backup and less sensitive applications a weekly backup.

A backup strategy is designed with resource optimization where we use a

combination of weekly full backups and daily incremental backups and
differential backups.

For offline backups care should be taken to secure media, Media should be
stored in a fireproof cabinet. For greater security backup copies should be
transported to an alternate location. The backup copies require the same of
protection as original data. Appropriate physical and environmental
protection should be ensured for storage of the backup media.
Storage media deteriorates with time hence media should be replaced timely
and disposed in a secure manner.
Also it is important to perform restoration test periodically and with rotation
of different backups. The results of all tests should be recorded. Failure to
recover data could leave the organization in breach hence restoration testing
is important. Regularly testing backup media also ensures that they can be
relied on for emergency use when necessary.
For highly confidential data it is preferred to encrypt the backups. Specially
in case of online backups it should be preferred to encrypt the backups. Also
isolate the backups virtually i.e. the backup storage should be in an isolated
VLAN which is not connected to Internet or User VLANs.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.13 INFORMATION BACKUP
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Corrective #Integrity #Recover #Continuity #Protection

#Availability

These are called air-gapped backups, backups can be air-gapped at network

level, also technologies are available to provide air-gapping at storage level
where Air gap backups are backup stored in air-gapped volumes. Air-gapped
volumes are “turned-off” by default and are inaccessible to applications,
databases, users, and workloads running on the production environment. Air-
gapped data storage only becomes accessible when it is “turned-on”.

The backup procedures should meet the objectives of incident response plan,
business continuity plan and disaster recovery plan. The testing should ensure
that IRP, DRP and BCP requirements are met. The backup restoration testing
can be a part of IRP, DRP testing exercises.

With popularity of cloud computing , cloud backups are also popular. Users
can choose to backup on-premises information to a cloud service called BaaS
(Backup as a Service). In case of SaaS ensure that cloud provider should
ensure redundancy and as “owner” you can choose to back up the SaaS data
to an alternate cloud storage.

A related topic is archiving and retention, it is not always possible to keep all
old data online. Organizations may choose to archive the old data and archive
retention may require regulatory requirements. Archives are a form of
backup where the objective is not redundancy but retention and meeting
regulatory requirements.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.14 REDUNDANCY OF INFORMATION PROCESSING
FACILITIES
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Preventive #Availability #Protect #Continuity #Protection

#Resilience

Control Statement
Information processing facilities should be implemented with redundancy
sufficient to meet availability requirements.

Requirement
Information processing facilities need redundancy to ensure continuation of
operations in case of an incident. Redundancy provides fault-tolerance,
reliability, availability. Additionally, redundancy helps in performance and
scalability. Redundancy is an important aspect of Disaster-Recovery &
Business Continuity.

Implementation
Availability is a core aspect of information security, along with confidentiality
and integrity. In order to ensure availability, the first step is is to do a risk
assessment to identify the assets that need to be prioritized for continuous
availability. Depending upon the sensitivity the hardware & software need to
be architected with redundancy.
The organization has to determine if it can tolerate any loss of availability
time and data and depending on these organization needs to implement
additional measures to ensure adherence to tolerable loss.

Redundancy is closely related to disaster-recovery and business-continuity

and is 1st step for ISO 27001 requirements of DRP & BCP.
The aim of redundancy is that if a primary asset fails (due to any reason) , a
secondary asset should be activated.
It all starts with continuous monitoring of all assets & services and the
organization should be alerted in case of any failure.
The redundancy can be in terms of hardware where two similar hardware are
provided and in case of failure of one of them the other can continue to
function. The redundancy can be either an active-passive fault tolerance pair
or an active-active load-balancing pair. These two pieces of hardware are at
same physical location.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.14 REDUNDANCY OF INFORMATION PROCESSING
FACILITIES
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Preventive #Availability #Protect #Continuity #Protection

#Resilience

There can be redundancy across multiple physical locations which can be

miles away. In such cases the alternate site can be always active or activated
only in case of emergency.

• In terms of network the Organization should consider having redundancy

at core-level by having a pair of two core switches in high-availability.
• For access-level redundancy may not be required in end-user networks but
is important in data-centers.
• For WANs organizations should consider redundant links and for Internet
connectivity having links from two different ISPs.
• It is recommended to have redundancy for power supply as well having
two power networks along with redundant power backup facilities like
redundant generators.
• Redundant hardware at same location to be installed in two different
racks.
• Geographic redundancy is equally important having geographically
separated primary and secondary data-centers.
• With Virtualization being the norm , the available fault-tolerance & high-
availability features in the hypervisor should be enabled and configured.
• Perimeter Firewalls should be in redundancy.

Depending on the requirement the redundancy can be in active-passive or

active-active mode. The active-active mode provides performance as well.

Ensure that the redundancy systems have the same level of security as the
primary systems.
For redundancy across different locations organizations should ensure that
the data at primary location is replicated without loss to the secondary
location.

Finally, organizations should do periodic tests to ensure that failover is

happening as intended. The results of tests should be documented.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.15 LOGGING
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Detective #Confidentiality #Detect #Event_managem #Protection

#Integrity ent #Defence
#Availability

Control Statement
Logs that record activities, exceptions, faults and other relevant events should
be produced, stored, protected and analysed.

Requirement
All activities occurring on information systems, both user activities and
system activities, should be monitored and recorded by organizations. In
addition to helping administrators troubleshoot the system during an
incident, these logs also facilitate the generation of evidence and assist with
investigations when an event impacts the confidentiality, integrity, or
availability of the information system. We must ensure that logs are kept
secure, prevent unauthorized access to logs, and maintain their integrity.
When there is proper logging, we can identify what events could result in an
information security incident and affect the organization's operations. Logs
are critical for investigations / forensics if necessary.

Implementation
This control in 2022 version of ISO 27001 replaces three controls in 2013
version.
 Event logs recording user activities, exceptions, faults and information
security events should be produced, kept and regularly reviewed.
 Event logs recording user activities, exceptions, faults and information
security events should be produced, kept and regularly reviewed. Logging
facilities and log information should be protected against tampering and
unauthorized access.
 System administrator and system operator activities should be logged and
the logs protected and regularly reviewed.

It is recommended that organizations should develop a topic specific policy on

logging and reporting.
First ‘event logging’ should be enabled on all information systems specially on
production systems. System logs often contain a large volume of information

[Link]

cont. ….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.15 LOGGING
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Detective #Confidentiality #Detect #Event_managem #Protection

#Integrity ent #Defence
#Availability
And all information is not relevant to information security hence it is
important that specific logs should be identified that impact the
confidentiality, integrity, availability, privacy of the information.
The event logs should mandatorily contain
o Timestamp
o System Identifier e.g. IP Address, Hostname
o Location
o Network Protocols
o User IDs
o Activity happening.
Some events that quality as security events , the list can be exhaustive
o Creation and deletion of identities
o Successful user log-on and log-off events (Authentication Logs)
o Rejected user log-on and log-off events (Authentication Logs)
o Changes to system configuration
o Use of privileges (Authorization of Logs)
o Access to files, programs , deletion of files, programs (Access Logs)
o Events of Security Systems as endpoint security, IDS, IPS etc

The management of logs from multiple systems can be very time consuming,
particularly in large organizations with thousands of systems. Thus, the
concept of centralized logging is essential. All logs need to be sent to a
centralized repository with strict access control. SIEM is an excellent
example of a centralized repository. A SIEM tool or equivalent service can be
utilized for storing, correlating, normalizing and analyzing log information,
as well as generating alerts. The SIEM operates as an automated system that
generates consolidated reports and alerts regarding the security of a system.
It is essential for SIEMs to have synchronized time sources as this facilitates
cross-correlation of logs between systems for analysis, alerting, and
investigation of incidents. SIEMs require careful configuration in order to
maximize their effectiveness. The SIEM should only be accessible by security
administrators, and system administrators should have limited access to
maintain the integrity of log files.
[Link]

cont. ….
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.15 LOGGING
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Detective #Confidentiality #Detect #Event_managem #Protection

#Integrity ent #Defence
#Availability
A key aspect of log management is maintaining log integrity, as it is one of the
most important aspects of maintaining log integrity to ensure the integrity of
logs. Those with privileged access privileges have full control over
information systems under their direct control and can manipulate system
logs on purpose or unintentionally. In order to maintain accountability, it is
necessary to prevent the manipulation of logs and protect the logs in order to
prevent the manipulation of logs.

In addition to protecting the logs from unauthorized tampering, controls

should also be implemented to ensure their availability, such as preventing
their partial removal or deletion.

A control that supports this is centralized logging. All systems, such as

network devices, servers, and applications, should forward logs to a
centralized repository, such as SIEM, and system administrators should not
have full access to the SIEM. Moreover, you can encrypt and maintain the
SIEM repository logs as read-only. It is also advisable to take offline backups
of the SIEM repository logs.

It is not unusual for regulatory requirements to require the retention of logs

for an extended period of time. Typically, logs are retained on systems for 30
to 90 days and on a centralized repository for 365 days. Logs can also be
archived on an offline medium for longer retention requirements.

There are times when event logs may contain sensitive data and personally
identifiable information. It is very important to ensure that this information
remains private and secure by taking appropriate privacy protection
measures.

Not just logging and having the logs there is not enough it is important that
log analysis is carried out both in a proactive manner and reactive manner.
There should be people with expertise to understand and analyse the logs.
cont. ….
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.15 LOGGING
Control Type Infosec Properties Cybersecurity Operational Security Domains
concepts capabilities

#Detective #Confidentiality #Detect #Event_managem #Protection

#Integrity ent #Defence
#Availability

Using log analysis, information security events can be analyzed and

interpreted to assist in identifying unusual activity or anomalous behavior,
which could indicate compromise. Identifying and analysing anomalous
behavior should be supported by specific monitoring activities. Correlating
logs to facilitate efficient and accurate analysis.

When logs are properly analyzed, they are able to identify potential
incidents of information security (for example, infection of a computer with
malware or probing of a firewall) and must be subjected to further
investigation through Incident Response Plans.

When a SIEM tool is equipped with SOAR and UEBA features, most of the
tasks, such as correlating logs from multiple sources, can be automated, so
that an efficient and highly accurate analysis can be performed.

Through the use of predetermined rules, SIEM assists in the identification

of exceptions.

A SIEM compares normal network traffic with anomalous behavior and

activity, based on known behavior patterns, results of trend analysis, and
results of pattern analysis.

In order to enhance and identify threats and vulnerabilities, SIEM makes

use of available threat intelligence.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.16 MONITORING ACTIVITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Detective #Integrity #Detect #Event_management #Defence
#Corrective #Availability #Respond
#Confidentiality

Control Statement
Networks, systems and applications should be monitored for anomalous
behaviour and appropriate actions taken to evaluate potential information
security incidents.

Requirement
Identifying anomalous behavior in an Information System, such as a server,
network, application, etc., can only be done by continuously monitoring it,
which is imperative to the confidentiality, integrity and availability of the
system.
The monitoring process ensures that any security events are detected at an
early stage and are prevented from escalating into a full-blown information
security incident. Monitoring detects any event that exceeds the baseline
threshold and prevents them from escalating.

Implementation
“Monitoring Activities” is a new introduced in 2022 version of ISO 27001.
Monitoring refers to the process of analysing the behavior and operation of
information systems and flag any behavior or operation that is indicative of
an attempt to compromise confidentiality, integrity and availability of the
system. Monitoring (8.16) includes Logging (8.15) and Capacity Management
as well.

It is possible to adopt a proactive defense strategy with continuous

monitoring that is more effective than reacting to incidents as they happen.
By anticipating potential threats and mitigating them before they are
exploited, organizations gain a greater level of security.
A continuous monitoring program provides early detection of suspicious
activities, anomalies, and security breaches, allowing organizations to
respond promptly before these threats have the chance to cause significant
damage.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.16 MONITORING ACTIVITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Detective #Integrity #Detect #Event_management #Defence
#Corrective #Availability #Respond
#Confidentiality
As part of monitoring information systems, the requirements and scope
should be determined based on the business and information security
requirements (i.e. monitoring the confidentiality, integrity, availability and
privacy of information) as well as the applicable laws and regulations. It is
important to maintain monitoring records for defined retention periods.
Monitoring is not simply about security; it also helps manage and optimize
the performance of IT systems (Capacity Management). Monitoring the
performance of an organization's systems can assist in ensuring that it is
operating efficiently as well as detecting and resolving performance problems
as soon as they arise.

During monitoring, all activities within a data system are recorded as an

audit trail during the monitoring process. As a result of this, organizations
are able to determine who performed what actions and when, enabling
organizations to conduct forensic investigations following security incidents.
The security team is capable of understanding the nature and scope of an
incident quickly and effectively if they have logs and alerts as they can
quickly get to the bottom of the situation. As a result of further monitoring,
we will be able to provide the necessary information to respond to security
incidents in a timely and effective manner.

In order for monitoring to be effective, the following areas should be included

in the process:

Utilization of hardware resources, such as CPU performance, memory, disk

space, etc.
• The logical access to information system components, such as servers,
applications, networks, etc.,
• Events and logs generated by firewalls and other security solutions such as
intrusion prevention systems and so forth
• Logs of event activity from servers and systems
• The physical access to the offices and facilities of the company
• Email and other collaboration systems.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.16 MONITORING ACTIVITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Detective #Integrity #Detect #Event_management #Defence
#Corrective #Availability #Respond
#Confidentiality
Having a baseline of normal behavior within an organization is important so
that it can be monitored for any deviation from this baseline so that
anomalous behaviors can be identified. To identify anomalous actions, the
monitoring system needs to be configured against this baseline.

The deviation from baselines is indicative of suspicious activity and some

some examples are unusual system behavior, atypical network traffic, traffic
from known bad IPs, hardware bottlenecks and unusual behavior in terms of
expected behavior.

The monitoring of system and network activity is usually achieved with the
use of specialist software i.e. a monitoring tool, which can be configured to set
up a baseline of normal, acceptable and expected system and network
activity. It can monitor thousands of systems in real time. It uses mechanisms
like SNMP, WMI, etc to gather data. Intuitive tools can set up baselines and
flag any deviations. The tools should be able to spot deviations, network
behavior patterns, and applications behavior patterns.

In organizations, monitoring can be done using multiple tools, like hardware

monitoring, network performance monitoring, application performance
monitoring, etc. It's not likely that a single tool can do all of that. Some
organizations use vendor-specific tools (Cisco tools for monitoring Cisco
Infrastructure) or vendor-agnostic tools (PRTG can monitor Cisco, Aruba,
etc.).

A monitoring tool should have alerting mechanisms, like emails. The alerts
may need to be fine tuned with the organization's baselines and thresholds.
There should be a process in place for responding to alerts, and system
administrators should be alerted via these alerts and respond to them in a
timely manner. Identifying and addressing false positives should also be part
of the procedure, as well as tuning the monitoring software to prevent them in
the future.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.16 MONITORING ACTIVITIES
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Detective #Integrity #Detect #Event_management #Defence
#Corrective #Availability #Respond
#Confidentiality

Procedures should also be established to identify and address false positives

including tuning the monitoring software to reduce the number of future false
positives.
Leveraging log analysis tool (SIEM) in combination with monitoring systems
can enhance the security monitoring. Also organizations should subscribe to
threat intelligence.

Threat Intelligence is the collection, analysis, and dissemination of

information about cyber threats to help organizations anticipate, detect, and
mitigate security risks. Threat Intelligence enhances an organization's ability
to detect, prevent, and respond to cybersecurity threats, making it a critical
component of a comprehensive security strategy.

Finally modern SIEM and monitoring tools come with machine learning and
artificial intelligence capabilities which can greatly enhance the capabilities.

Overall, monitoring is a foundational element of a robust information

security strategy, providing the visibility and insights needed to protect
sensitive data and ensure the integrity, availability, and confidentiality of
information systems. With continuous monitoring, organizations can adopt a
proactive defense strategy. Instead of reacting to incidents after they occur,
they can anticipate potential threats and mitigate them before they can
exploit vulnerabilities.

Many regulations and standards (such as GDPR, HIPAA, and PCI-DSS)

require organizations to monitor their information systems to ensure
compliance. Failure to do so can result in legal penalties and damage to the
organization's reputation.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.17 CLOCK SYNCHRONIZATION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Detective #Integrity #Detect #Event_management #Defence
#Protect #Protection

Control Statement
The clocks of information processing systems used by the organization should
be synchronized to approved time sources.

Requirement
It is important to have an accurate computer clock to ensure that event logs
are accurate, because they can be used as evidence for investigations and for
legal or disciplinary actions. Inaccurate audit logs have the potential to hurt
investigations and damage credibility as well. There must be synchronization
between all information systems in order to collect, analyze, and investigate
information security events as well as to support investigations into incidents
related to information security in order to ensure the success of the
investigation.

Implementation
Despite being one of the simplest controls to implement, clock
synchronization is particularly important in terms of monitoring and incident
response. In information systems, logs are always time stamped and date
stamped. The timestamp forms an important part of the audit trail. It is
important for forensic investigations and should be consistent across all
information systems within the scope of ISMS. Using local time as the base
time should be recommended for organizations. If an organization has
locations in multiple time zones, devices should use the local time based on
their physical location; however, organizations may opt to use GMT/UTC as
the base time across the globe and then convert the time during
investigations.

Information systems, both active and passive, as well as servers, endpoints,

network appliances, and security appliances, should be able to use a standard
reference time within the organization. In most organizations, an NTP server
or dedicated NTP server is used. Active-Directory Domain Controllers or
dedicated NTP servers are generally used. Domain Controllers / NTP servers
should be synced with external internet-based NTP services.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.17 CLOCK SYNCHRONIZATION
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Detective #Integrity #Detect #Event_management #Defence
#Protect #Protection

It is recommended to sync physical access systems (Door Access, CCTV, etc)

and building management systems with the NTP Server. It may be
advantageous for some organizations that are time-sensitive (Airlines, etc.) to
use a precision time protocol (PTP) through an atomic clock or GPS. To
ensure accurate time stamps, dedicated appliances are available that are
synchronized with GPS and provide a reliable, consistent time and date
source. NTP and PTP can both be used to ensure that all information systems
are in sync with a reference time.

Time synchronization may be required by law or regulation in some cases,

such as in the case of banks, telecoms, etc. In today's age of cloud-based
services, it is imperative that both cloud infrastructure and on-premise
infrastructure are in sync.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.18 USE OF PRIVILEGED UTILITY PROGRAMS
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability #Secure_configuration

Control Statement
The use of utility programs that can be capable of overriding system and
application controls should be restricted and tightly controlled.

Requirement
The majority of information systems come with utility programs that
override system and application controls. Examples include diagnostics,
patching, antivirus, disk defragmenters, debuggers, backups, and network
tools. Some of these tools can be run without administrative privileges. These
system utilities provide an opportunity for misuse.

It is paramount to ensure that system and application security controls

mustn't be adversely affected by the use of these utility programs. It is
essential that all such system utilities are identified, that the associated risks
are assessed and some controls are applied.

Implementation
It has been observed that utility programs in the majority of information
systems are designed to override the system and application controls of the
system. It is possible to run some of these system utilities without requiring
administrative privileges. Some of these tools include diagnostics, patching,
antivirus, disk defragmenters, debuggers, backups, and network tools.

System utilities such as these can be misused and damage the integrity of the
security controls on an operating system or application. The use of these
utilities may be necessary to resolve control problems in some cases, but the
use of them should be tightly controlled and should only be approved and
justified after sufficient authorization and justification have been obtained.

Some of the controls that can be considered are -

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.18 USE OF PRIVILEGED UTILITY PROGRAMS
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability #Secure_configuration

 Ideally the use of all utility programs should be logged so that it is possible
to track their usage and accountability is ensured.

 It is recommended that all unnecessary utility programs be removed or

disabled.

 A procedure for providing authorization for the ad hoc use of utility

programs on a temporary basis should be developed ideally via privileged
access management program.

 In order to ensure the best possible and secure use of utility programs, the
number of trusted authorized users must be limited to the smallest
practical number.

 It is essential to keep utility programs logically separate from application

software, and when practical, to separate network communications for
these programs from traffic flowing through applications.

 For utility programs, it is important for authorization levels to be defined

and documented and ideally made available on-demand basis only.

 It is essential that utility programs must follow procedures for

identification, authentication, and authorization, including a unique
identification number for the person using the utility program.

 In situations where segregation of duties is required, utility programs

should not be made available to users who have access to applications on a
system.

 Programs that are restricted from being available at any time during a
period with an authorized change (e.g. for the duration of the change)

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.19 INSTALLATION OF SOFTWARE ON OPERATIONAL SYSTEMS
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #Secure_configuration
#Availability

Control Statement
Procedures and measures should be implemented to securely manage
software installation on operational systems.

Requirement
It is important that only authorised software are permitted to be installed on
the operational systems. There exists an inherent vulnerability where users
can install unauthorised software or make unauthorised changes to the
operational software. This can result in loss of system and data integrity.
Unauthorised software can lead to possibility of fraud or even system failure.
Hence there should be strict controls against installation of software.

Implementation
This control in 2022 version replaces two controls in 2013 version
A.12.5.1 – Installation of Software on Operational Systems
A.12.6.2 – Restriction on Software Installation

Organization do not permit privileged rights to common users hence common

users cannot install software on endpoints i.e. The principle of least privilege
should be applied to software installation on operational systems.

This should not be limited to PCs but extended to smartphones and tablets as
well.
First organizations should have a centralized procurement of software where
all software undergoes a security testing on test system before deployment on
production systems. It should be ensured that all software procured should be
properly licensed.
Freeware and Community ware should undergo security testing as well.
The organization should define and enforce strict rules on which types of
software users can install. It is important that Organizations setup a software
‘whitelist’ – Only software in whitelist should be allowed to be installed .

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.19 INSTALLATION OF SOFTWARE ON OPERATIONAL SYSTEMS
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #Secure_configuration
#Availability

Every organization will have groups of users with privileges that allow them
to install or alter software relevant to their positions. It is essential that these
privileges be strictly controlled and that appropriate uses be monitored.

Software installation on servers should be subject to change control,

including impact analysis, business justification, and testing prior to
installation. All change management procedures should be followed during
the installation process.

Generally, client-side software installation does not require change control if

the software is installed on a limited number of endpoints, but if the software
is required to be installed on a large number of endpoints, then change
control is required.

The acquisition of new software should be based on a business requirement

and appropriately authorized. It is imperative that all licensing requirements
are met and that adequate support is available to meet the organization's
needs. Over time, vendors will cease to support older versions of software.
It is important for organizations to consider the risks associated with relying
on unsupported software.
Additionally, when upgrading to a new version, the business requirements for
the change as well as the security of the release should be considered (such as
introducing new information security functionality or addressing the number
and severity of security vulnerabilities affecting the current version).

Ensure that software patches are applied on a timely basis - these patches
resolve software bugs and vulnerabilities.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.19 INSTALLATION OF SOFTWARE ON OPERATIONAL SYSTEMS
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #Secure_configuration
#Availability

Moreover, the IT department should make sure that only approved

executable code, rather than development code or compilers, is installed on
operational (production) systems, this is specially in case of bespoke and
internally developed software applications.
Furthermore, controls should be established to prevent the development and
use of bespoke software. Configuration control and release management are
important to maintaining control of all bespoke software.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.20 NETWORKS SECURITY
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Detective #Integrity #Detect urity
#Availability

Control Statement
Networks and network devices should be secured, managed and controlled to
protect information in systems and applications.

Requirement
Networks are one of the most important component in Information systems.
Most of the attacks involving compromise to confidentiality, integrity and
availability start with network. Hence it is very essential that network devices
and networks both LAN and WAN are secured and protected. Protection of
networks ensures protection of systems, application and data.

Implementation
Networks represent the most vulnerable part of the entire information
technology infrastructure. In terms of unauthorized access and unintentional
failures of technology, they are impaired, and their configuration can be
easily miscontrolled and protected. Furthermore, networks are particularly
prone to abuse and misuse.
Therefore, network integrity and availability may be compromised as a
result. Additionally, it is important to ensure that information that passes
over networks is secure and confidential, and to implement appropriate
controls to protect that information as well as the organization's connected
networks and systems, as well as the information that passes through them.

The reduction of these risks can only be achieved through effective

management and security controls, as well as sound procedures. Taking
network security into consideration is crucial in the design, implementation,
operation, management, and monitoring of a network, as well as the
implementation, operation, and monitoring of the network itself. For
organizations, managing the network information security activity has
become an increasingly important component of their overall security
management activities, which requires specialized knowledge of each
communication technology.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.20 NETWORKS SECURITY
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Detective #Integrity #Detect urity
#Availability

Additionally, there are day-to-day security controls that can be used in a

variety of ways to protect networks, and the implementation of these controls
should be carefully considered before implementation in order to ensure their
effectiveness.

The majority of these controls can only be implemented by establishing

policies and procedures at the organizational level. These techniques require
comprehensive authorization documentation for their implementation,
operation, change management, and monitoring, as well as comprehensive
authorized documentation for the implementation of these techniques. In
order to keep track of network activities as well as security status constantly,
in addition to keeping appropriate records for faults, problems and corrective
actions as they occur, it is imperative to continuously monitor network
activities and security status.

Some of the controls that can be implemented:-

 Establish SOPs for day to day management of network devices including
wired and wireless networks.
 Ensure up-to-date Network Diagrams are maintained.
 Backup and secure Network Devices Configuration Files
 Maintain segregation of Networks including internal segmentation.
 Ensure availability by implementing Edge, Core and Data-Center network
equipment in redundancy.
 Ensure confidentiality of data passing over networks by implementing
technologies like VPN and strong wireless encryption like WPA2/WPA3
 Ensure network monitoring is constant with implementing network
monitoring solutions based on syslog to check availability and capacity and
faults.
 Implement Network Performance Management (NPM)
 Ensure up-to-date contacts with Service Providers.
 Ensure all Network devices are hardened
 Ensure only authorised systems connect to network by implementing a
NAC solution.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.20 NETWORKS SECURITY
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Detective #Integrity #Detect urity
#Availability

 Ensure critical segments of Network (e.g. OSS Networks and Data

Centers) are logically separated.
 Ensure a firewall is implemented, Having a firewall between VLANs for
Internal Segmentation is highly recommended.
 Ensure all vulnerable network protocols are disabled and discouraged.
 Ensure prevention of installation of rouge network devices like a rouge hub
or a rouge wireless access point.
 Ensure prevention against APT (Advanced Persistent Threats) by
implementing NGFWs.
 Ensure Intrusion Prevention by implementing IPS at edge and Data Center
Edge.

This is not a complete set of controls. Depending on organization and

sensitivity these controls can be selected. A Risk Assessment should determine
the same.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.21 SECURITY OF NETWORK SERVICES.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability

Control Statement
Security mechanisms, service levels and service requirements of network
services should be identified, implemented and monitored.

Requirement
Networks are one of the most important component in Information systems
and many network related services are managed by third-party (especially
WAN services) and it's important to ensure confidentiality, integrity and
availability in acquisition, implementation and use of these services.

Implementation
Organizations depend on third-party service providers for Network Services
particularly wide-area-networks (WAN) services. Only limited organizations
with sufficient infrastructure can afford dedicated private fiber optic
connections over large distances, for remaining organizations they have to
depend on telecom service providers for wired services like MPLS, P2P,
Metro Ethernet etc. and wireless services like microwave and satellite links.

The use of third party supplied network services can increase the
opportunities for unauthorized access by other parties leading to loss of
confidentiality and integrity. Availability should also be given special
attention checking on the resilience of supplier’s failover provision in the
event of power connection or equipment failure the organization should
establish security standards that will be maintained when the supplier is
experiencing or recovering from a failure and which should identify the
security features service levels and controls required by the services being
consumed.

Organization when they are in process of acquisition of network services

should identify security requirements in addition to service levels and service
requirements. These requirements should be mandated to be implemented by
the service providers and should be part of SLA measurements.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.21 SECURITY OF NETWORK SERVICES.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability

The organization should regularly monitor the agreed to security

requirements and have KPIs which are agreed by both parties.

The service providers can provide their security certifications like ISO 27001
to prove their security credentials and the agreements can include a ‘right to
audit’ where the organization can perform an audit on the provider. The
provider has to periodically provide evidence on how it is managing agreed
services in an secure manner ensuring confidentiality, integrity and
availability.

With growing dependency on cloud services, a number of Network Services

have been moving to cloud and provided as managed services like ‘Managed
NOC’, ‘Managed Firewall’, ‘Managed DDoS Prevention’ etc. All these
complex value-added network service offerings should be covered by similar
security requirements link in case of bandwidth services and VPN services.

Some of the security requirements that should be considered are

 Encryption of Data in Transit e.g. use of VPNs over MPLS networks.
 Authentication Controls for accessing the management of the services
including prevention of unauthorised access and inclusion of authorization
procedures only authorised users should have access to modify the
Network Services with a least-privilege mechanism.
 Restriction of application and unsecured protocols
 Implementation of Network Management Solutions and Network
Performance Management Solutions
 Logging of all security (login/logoff) & Non-Security (changes) activities
and events with proper timestamp and user attributes
 24x7 monitoring of the services

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.22 SEGREGATION OF NETWORKS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability

Control Statement
Groups of information services, users and information systems should be
segregated in the organization’s networks.

Requirement
Networks are one of the most important component in Information systems
and it's important to ensure confidentiality, integrity and availability. Based
on business requirements the network should have boundaries with
controlled egress and ingress traffic with a principle of least access allowing
only necessary traffic.

Implementation
There is always a risk of unauthorized excess attempts on networks, which
could lead to loss of confidentiality and integrity for the network or the
systems attached to the network.

A large network presents an increased risk of security breaches, especially for

large organizations with multiple geographical locations. First it is important
to isolate the organizational network from the public network (i.e. the
Internet). Security can be more easily managed if the organizational network
is divided into physical or logical domains; tight security can then be
provided by implementing firewalls between the domains. The most common
method is to segment the network into VLANs. (logical domains). These
VLANs can be classified based on department (most common) or physical
locations like floors in a building which have different levels of criticality and
sensitivity. e.g. Finance department systems have a higher criticality than
Customer Service department.

Creating VLANs helps manage the network easily. Security can be enhanced
by implementing internal segmentation firewalls in addition to the perimeter
firewalls which are used to segment the organizational network from the
Internet.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.22 SEGREGATION OF NETWORKS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability

Perimeter firewalls can be utilized to protect the organization’s networks

against unapproved ingress traffic while at the same time allowing only
required egress traffic like public access to organizational services and staff
the ability to browse the internet and receive email from the organization.

The critical network domains e.g. the Data Center, the OT Networks should
be segregated from the general user networks for additional security using a
Core Firewall. NGFW features such as IPS (Intrusion Prevention) should be
included in Core firewalls to protect critical networks from user networks.

Wired and wireless networks should be segregated as well i.e. have different
VLANS for Wi-Fi networks. Wi-Fi networks cross physical boundaries hence
it is important to implement secure Wi-Fi access protocols like WPA2 &
WPA3 with authentication based on identities rather than a pre-shared key.

Guest networks should be isolated from other networks and should have
minimal access (Internet access only). Guest users should not be able to access
the Internal Networks. Employees should be discouraged from using Guest
Networks.

An organization should utilize network modeling to determine the individual

network zones required by the organization. A risk assessment will determine
what level of security needs to be applied to each area. A sufficient separation
of networks should be achieved through the implementation of network
connection and routing controls.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.23 WEB FILTERING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability

Control Statement
Access to external websites should be managed to reduce exposure to
malicious content.

Requirement
Web browsing still remains a significant source of malware and other cyber
attacks and uncontrolled/unauthorized web traffic can compromise security.
Organizations should prevent users from accessing malicious websites and
control web browsing traffic using enforced security policies

Implementation
A.8.23 is a new control introduced in ISO 27001:2022. Organizations should
control the web browsing from its networks and beyond network as well
where users use Organizational devices beyond the organizational networks.
Many websites contain unauthorised material (e.g. pirated movies/music),
illegal information (unlicensed software), unapproved content (Pornography
etc). Depending on business and information sensitivity organizations may
need to control access to Social Media, Web based free email etc as well.

Organizations may need to block access to websites which are a distraction to

increase staff productivity. Restricting access works to increase productivity
significantly. Non-work-related internet usage like online streaming
(including Youtube) significantly saps your network bandwidth. By limiting
access to these sites, you achieve increased network bandwidth efficiency with
faster connections.
There can be divisions within an organization , Marketing teams may require
access to Social Media and Online Streaming for their work so Organization
may choose to block a web category for one department and blocking it for
other department at the same time.

The most popular solution is to use a Gateway URL Filtering solution, some
endpoint security solutions provide URL filtering capabilities as well.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.23 WEB FILTERING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #System_and_network_sec #Protection
#Integrity urity
#Availability

Large Organizations with thousands of users may need a dedicated URL

Filtering solution for efficiency however small and medium organizations can
use a UTM Firewall which acts as an all-in-one device providing features like
URL Filtering, Gateway antivirus, IPS and Firewall in a single device.

First of Additionally, an Organization should define its URL Filtering Policy,

most of the solutions filter based on categories like Pornography, Social
Media, News, Entertainment, IT, Government, Education etc. Organization
should define which category should be allowed and which should be blocked.
Then policies should be configured in URL Filter to allow or block categories.
There can be different policies for different user groups.

Organizations can choose to allow or block different categories depending on

business requirements.

Additionally, organizations can configure whitelists and blacklists to have

websites as ‘allow always’ and ‘block always’. Organizations can subscribe to
Threat Intelligence to update the ‘blacklists’ in real time – This ensures that
malicious websites are always blocked. Most of the URL filtering solutions
have their URL databases updated in real time.

One important ‘additional’ component here is user awareness. Users should

be made aware that accessing illegal websites is against the organizational
policies. This clause can be included in “Acceptable Use of Technology” or an
equivalent policy. Organizations should have a procedure where users can
request access to a ‘blocked’ website if it is required for legitimate business
reasons.

Some organizations choose not to implement a legacy URL Filtering and

depend on employee discretion still such organizations should implement a
web security solution to block web malware, illegal content, C&C websites,
malicious websites.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.24 USE OF CRYPTOGRAPHY.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Secure_configuration #Protection
#Integrity
#Availability

Control Statement
Rules for the effective use of cryptography, including cryptographic key
management, should be defined and implemented.

Requirement
Cryptography is employed to protect the confidentiality and integrity of
information. Both information at rest and in transit needs to be protected.
Additionally, it provides non-repudiation and authenticity. It is important
that organizations employ an effective and standardised use of cryptography.
In addition to security requirements the cryptography should consider
business requirements and regulatory requirements as well.

Implementation
This control combines two controls from 2013 version. 2013 has separate
controls on use of cryptography and management of keys. The 2022 version
combines the two controls into one.

Cryptography is used to protect the confidentiality and integrity of the

information. In addition it provides ‘non-repudiation’ and in some cases
authentication as well.
 Confidentiality- The purpose of cryptographic encryption is to protect
readable data from unauthorized access by transforming it into an
unreadable format (ciphertext). The information remains confidential as
only authorized users have the decryption key to regain its original form.
 Integrity- This process helps to ensure that the data remains unaltered.
Hash functions generate unique fixed-size digests for data, enabling data
integrity to be verified. If even a single bit changes, the hash output
changes significantly, allowing detection of tampering.
 Non-repudiation- Digital signatures are created by using a sender's private
key, so they provide evidence that a message or transaction came from that
sender and was not altered. Because only the sender has the private key,
they have no ability to deny authorship.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.23 USE OF CRYPTOGRAPHY.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Secure_configuration #Protection
#Integrity
#Availability

 Authenticity- In public key infrastructure (PKI), digital certificates are

verified as a means of authenticating users. The authentication process
verifies the identity of users before granting them access by requiring them
to present cryptographic proofs, such as private-public key pairs.

Organizations should identify, agree and apply defined principles related to

cryptography. This will ensure effective use of cryptographic controls.
Though it is recommended to have a policy on use of cryptography it is not
mandatory, a policy can maximize the benefits. The cryptographic controls
are determined by the business requirements, regulatory requirements and
sensitivity/classification of the data.
Certain parameters that are influenced are the encrypting algorithms, key
size, hash function, key-exchange algorithm, cipher-suites etc.
It is recommended that Organizations maintain a consistent cryptography
throughout the organization where controls are applied.
A risk assessment will be able to determine the requirements related to
confidentiality, integrity, non-repudiation and authenticity.
In case a policy is documented it should be communicated as well.

Key management is an important aspect of this control. A dedicated key

management system is recommended which is used for generating, storing
and distributing cryptographic keys and certificates.
This key management system should be strictly access-controlled. All the
cryptographic keys and should be stored in the system securely. A key
management software can be used as well. Only authorised users should have
access.
Public Keys & Certificates may not require the protection that is required by
private keys.
The keys should be shared in a secure manner and secured file formats
should be used. The lifetime of keys and certificates should be determined by
business requirements and security requirements. The maximum age of keys
should be determined. It is recommended to have a maximum age of three
years.
. [Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.23 USE OF CRYPTOGRAPHY.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Secure_configuration #Protection
#Integrity
#Availability

There should be process for deactivation and disposition of the cryptographic

keys. There should be processes around compromised keys and deactivation
of keys.
Server keys may require deactivation in case of a compromise and client keys
in case a user leaves the organization.
A key management solution will prevent against unauthorised modification
and provide necessary protection to private keys.
Organizations employ Certificate Authorities for signing their keys. The
authenticity of public keys is usually addressed by public key infrastructure
processes using certificate authorities. CAs issue digital certificates, which are
electronic documents that contain a public key along with identifying
information (e.g., the owner’s name or organization). This certificate links the
entity’s identity to its public key, enabling others to verify it.
Organizations should maintain relationship with Certificate Authorities and
manage trust.

Encryption also applied to data at rest, its recommended to implement a

whole disk encryption (WDE) to the endpoints (smartphones & laptops).
Additionally, servers and databases and other data storage repositories
should have encryption enabled as well. The encryption & decryption keys
should be properly managed using endpoint encryption solutions.

Cryptographic controls may involve regulations. Different governments and

their bodies may have certain rules or restrictions related to use of
cryptography (both for data at rest and data in transit) and cross-border
transfer of encryption. These regulations should be taken into consideration.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.25 SECURE DEVELOPMENT LIFE CYCLE.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Control Statement
Rules for the secure development of software and systems should be
established and applied.

Requirement
It is important that security practices are integrated into each phase of the
SDLC irrespective of waterfall or agile methodology. Integrating security in
SDLC helps in detecting and identifying vulnerabilities early and thereby
mitigating the risks pre-production. It helps to reduce costs and improve the
overall security of the software application.

Implementation
The Software Development Life Cycle (SDLC) is a structured process used
for planning, creating, testing, and deploying software applications. It serves
as a guideline for systematic software development and aims to improve
quality and efficiency throughout the process. Various models such as
Waterfall, Agile, or DevOps, each providing different approaches to improve
flexibility, speed, or efficiency in delivering high-quality software products.

 Planning: Security requirements are defined and compliance standards are

considered. A risk assessment may be conducted to understand potential
threats.

 Requirements Analysis: Security-specific requirements are identified, such

as authentication, authorization, and data protection needs. Threat
modeling might also be introduced here to identify vulnerabilities and
attack vectors early.

 Design: Security architecture is created to incorporate controls such as

secure coding standards and encryption. Security reviews are conducted
for system design, data flow, and database architecture.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.25 SECURE DEVELOPMENT LIFE CYCLE.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

 Development: Developers follow secure coding practices to avoid common

vulnerabilities like SQL injection and cross-site scripting (XSS). Code
review tools and static analysis can be used to catch vulnerabilities in real
time.

 Testing: In addition to standard functional testing, security-specific tests

are conducted. These include penetration testing, vulnerability scanning,
and code analysis to catch security issues before deployment.

 Deployment: Security configurations for the production environment are

set up, and access controls are tightened. Security audits or checklists
ensure that the application meets all security standards.

 Maintenance: Regular security updates, monitoring, and vulnerability

assessments are conducted to manage emerging threats. Patches are
applied as needed, and the security posture is continuously reviewed.

This control is actually an umbrella control for controls A.8.27 to A.8.32 and
the controls are detailed in detail
 Secure Software Development Methodology
 Secure Coding Guidelines
 Security Testing including code testing and pre-deployment Pen Testing
 Vulnerability Fixing
 Secure Outsourced Development
 Separate Test and Development Environments
 Use of open source and maintaining licensing

Developers should be trained in Secure programming techniques. Secure

programming techniques should be used for all developments. Secure coding
standards should be considered and mandated for use.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.25 SECURE DEVELOPMENT LIFE CYCLE.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Where software applications or application services are being developed it is

necessary for the organization to consider the information security of these
environments to prevent the intentional or accidental inclusion of
inappropriate functionality (which can lead to vulnerabilities) and that could
be used later indie production system to compromise it.

It is also important to protect the intellectual property of the organization

both embodied in the materials being developed and in the tools and systems
being used for development.

Often organizations neglect the security of test and development

environments. Test and Development environments have lower impact of the
risk but if the controls are neglected it can lead to higher probability of the
compromise. The compromise of a test/development environment itself may
impact the confidentiality integrity and availability not only of the
environment but of the production environment in the future.

It is important though not necessary that a topic specific policy could be

developed which will be the software development security policy to ensure
that development is carried out to the standards that are suitable to the
organizations information security risk profile.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.26 APPLICATION SECURITY REQUIREMENTS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #Defence
#Availability

Control Statement
Information security requirements should be identified, specified and
approved when developing or acquiring applications.

Requirement
Organizations may choose to develop bespoke applications internally
organizations may choose COTS applications and customize them. In either
case the security requirements should be identified and addressed prior the
applications are rolled out to production. The requirements should be a part
of entire acquisition and development cycles.

Implementation
This control combines and then expands two controls from ISO 27001:2013
A.14.1.2 – Securing Application services on Public Networks
A.14.1.3 – Protecting Application Services transactions

If an organization is using IT Applications for transactions (e.g. online

Payments, eCommerce, Finance both B2B & B2C) and these applications are
accessible over a public network e.g. Internet then controls should be put in
place to ensure confidentiality and integrity of the transactional applications
and prevent instances like unauthorised disclosure, alteration, duplication,
incomplete transmission etc. This can be achieved using a Risk Assessment
methodology. A Risk Assessment will determine the level of protection
required. Some controls that are recommended are use of cryptographic
controls like TLS that provide confidentiality via encryption, integrity via
hashing and digital signatures for authenticity. Also additional methods like
mandatory MFA during login and secondary authentication mechanism like
an OTP for transaction.
One standard that mandates this the PCIDSS that is to be used by all
merchants that deal in online payments via payment cards (Visa/Mastercard).
Both visa and Mastercard have implemented features like “Verified By Visa”
and “Mastercard Securecode”. Organizations may be subject to additional
regulations from the governments for all transactional services.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.26 APPLICATION SECURITY REQUIREMENTS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #Defence
#Availability

Some requirements that can be considered and according needs controls are –
 Classification Level of the Information
 Information contains PII or PHI
 Encryption Requirements – Does application need to be encrypted
internally as well.
 Requirements as per legal and regulatory standards like HIPPA , GDPR
etc.
 Logging and Monitoring Requirements
 Privacy Requirements
 Data Protection & Data Leakage Prevention
 Encryption Requirements (At Rest and In Transit)
 Protection against malware and other attacks like XSS & SQL Injection
 Input & Output Controls
 Storage Requirements- Data Localization and Data Retention.

There can be multiple other controls that might be required. e, detailed risk
assessments and careful determination of controls are indispensable.

Applications that involve electronic ordering & payments (Commercial &

Financial Applications) may require additional controls determined by local,
provincial and federal laws around electronic payments and other regulations
like PCIDSS.
One of the important control is verification of the transactional information
and payment information in addition to maintaining confidentiality, Integrity
and Availability.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.27 SECURE SYSTEM ARCHITECTURE AND
ENGINEERING PRINCIPLES.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Control Statement
Principles for engineering secure systems should be established, documented,
maintained and applied to any information system development activities.

Requirement
Organizations may choose to develop bespoke applications internally
organizations may choose acquiring COTS applications and customize them.
In either case these information systems should be securely designed, built,
implemented and operated during entire software development life cycle for
both acquisition and development procedures. This includes the
establishment of secure system architectures, engineering principles and
secure design practices.

Implementation
Secure system engineering principles are foundational guidelines and
practices aimed at designing, developing, and maintaining systems that are
resilient to threats, ensuring data integrity, confidentiality, and availability.
These principles help create robust systems that can withstand cyberattacks,
human errors, and system failures. 8.27 specifies that organisations must
implement secure system architecture and engineering principles to ensure
that the design, implementation and management of the information system
are appropriate to the organisation’s security requirements.

Incorporating secure architecture principles such as “Zero-Trust”, “security

by design”, “defence in depth”, “fail securely”, “distrust input from external
applications”, “assume breach”, “least privilege”, “usability and
manageability” and “least functionality”, “Accountability” is paramount.

By adhering to these principles during the system development lifecycle,

organizations can build systems that are both functional and secure,
minimizing the risk of breaches and ensuring compliance with regulatory
standards.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.27 SECURE SYSTEM ARCHITECTURE AND
ENGINEERING PRINCIPLES.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Some areas that are covered by Secure engineering principles are Identity &
Access Management, Data validation, session management etc.

Secure Engineering Principles should be based on other ISO27001 controls

that are required to protect confidentiality and integrity of the information to
protect the systems against threats, to prevent , detect and correct any
security incidents that may occur during software development life cycle.
The secure engineering principles should be based on the accepted industry
best practices and be integrated with the security architecture.
The principles should help identify threats and vulnerabilities and the
controls are implemented to mitigate the threats and vulnerabilities and meet
the requirements of the established Information Security Policy.

The secure engineering principles should be applied to all projects that

involve third-parties and should be extended to all the partners and suppliers
involved in outsourced developments.

Below are some secure system engineering principles

1. Security by Design
Incorporate security requirements and controls during the design phase, not as an
afterthought.
2. Least Privilege
Ensure that users, processes, and applications operate with the minimum
permissions required to perform their tasks, reducing exposure to risks.
3. Defense in Depth
Layer security controls at different levels (e.g., network, application, and data) to
provide multiple barriers against attacks.
4. Fail-Secure Defaults
Configure systems and software to default to a secure state in case of failure. For
example, deny access unless explicitly granted.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.27 SECURE SYSTEM ARCHITECTURE AND
ENGINEERING PRINCIPLES.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability
5. Secure Defaults
Ship software with secure settings enabled by default. Users should need to opt-in
for less secure configurations, not the other way around.
6. Complete Mediation
Validate every access request, ensuring that permissions are checked every time a
resource is accessed.
7. Open Design
Avoid relying on the secrecy of the system's design for security. Use proven, peer-
reviewed security algorithms and frameworks.
8. Secure Dependencies
Use trusted third-party libraries and frameworks.
Regularly audit and update dependencies to mitigate risks from known
vulnerabilities.
9. Least Common Mechanism
Minimize shared resources between components to prevent the unintended
propagation of security vulnerabilities.
10. Separation of Duties
Ensure critical processes are divided among multiple entities or components to
reduce the likelihood of fraud or abuse.
11. Secure Communication
Use encryption (e.g., TLS/SSL) for all data in transit.
Use strong encryption algorithms and ensure proper key management practices.
12. Input Validation
Validate and sanitize all user inputs to prevent injection attacks such as SQL
injection or cross-site scripting (XSS).
13. Output Encoding
Encode outputs to prevent unintended data exposure or attacks when data is
rendered in web pages or other interfaces.
14. Accountability and Auditability
Implement robust logging and monitoring systems to track user and system
actions.
Ensure logs are secure, tamper-proof, and reviewed regularly.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.27 SECURE SYSTEM ARCHITECTURE AND
ENGINEERING PRINCIPLES.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability
15. Principle of Modularity
Design systems in modular components, making it easier to isolate, test, and
secure individual parts of the software.
16. Secure State Management
Manage states securely to prevent session hijacking, replay attacks, or other
session-based vulnerabilities.
Use techniques like tokenization and secure session cookies.
17. Resilience to Failure
Design software to gracefully handle errors and recover without exposing
sensitive information or entering insecure states.
18. Avoid Security Through Obscurity
While obscurity can be an additional layer, never rely solely on hiding system
details for security. Instead, use robust security mechanisms.
19. Proactive Updates
Plan for regular updates and patches to address vulnerabilities.
Automate testing and deployment processes for secure updates.
20. User-Centric Security
Design security features that are intuitive for users, reducing the likelihood of
misconfigurations or circumventions.
21. Continuous Security Testing
Perform regular static and dynamic code analysis, penetration testing, and fuzz
testing.
Use automated tools to identify and fix vulnerabilities during development.
22. Incident Response Planning
Include mechanisms to detect, respond to, and recover from security breaches.
Ensure clear processes for reporting vulnerabilities and incidents.
23. Secure Decommissioning
Implement secure processes for retiring or decommissioning software systems,
including data wiping and certificate revocation.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.28 SECURE CODING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Control Statement
Secure coding principles should be applied to software development.

Requirement
When an organization develops it own principle, software application it is
important that software coding is done in a secure manner so that the
vulnerabilities are mitigated in software. By adhering to secure coding
standards, developers can mitigate these risks, reducing the likelihood of
breaches. principle, ensure a reliable, safe, and trustworthy software product,
the security of that software has an important role to play, and it is directly
affected as a result.

Implementation
A.8.28 is a new control introduced in ISO 27001:2022
There is a wide range of vulnerabilities affecting software applications which
are introduced by poor design and coding. Examples of these vulnerabilities
include database injection attack and cross-site scripting attack, where
requests can be modified to take advantage of the functionality of the
software. Hence it is important that some best practices are adopted during
the software coding itself. As a best practice it is required to adopt a “zero-
trust” which has a principle of “always assume breach”. Using this principle
it is assumed that all software is inherently vulnerable to attack either
intentionally or unintentionally. Hence it is important that developers should
adopt some practices during coding to prevent these vulnerabilities and
prevent the software from tampering.

Latest industry SDLC frameworks mandate secure coding as well and code
analysis tools are available to detect if the software code has vulnerabilities.
Secure Development Lifecycle (SDLC) frameworks integrate security
practices into each phase of the software development lifecycle, ensuring
vulnerabilities are identified and addressed early.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.28 SECURE CODING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability
Microsoft SDL is a process that introduces security and privacy
considerations throughout all phases of development. Agile Secure
Development Lifecycle incorporates security tasks into sprints and integrates
security directly into DevOps workflows. By adopting a secure SDLC
framework, organizations can ensure that security is not an afterthought but
an integral part of the software development process.

Both NIST and ISO provide NIST Secure Software Development Framework
(SSDF) and ISO/IEC 27034 Application Security Framework that provides a
high-level approach to secure software development and provides guidelines
for incorporating security into the SDLC.

OWASP, the Open Web Application Security Project, is a global, non-profit

organization dedicated to improving software security. It provides tools,
resources, guidelines, and knowledge to help developers, organizations, and
security professionals build and maintain secure applications. It Offers freely
available tools, documentation, and methodologies for secure application
development. OWASP has a wide range of projects, including guidelines,
tools, and checklist such as OWASP Top 10; OWASP SAMM (Software
Assurance Maturity Model), OWASP Cheat Sheet Series and OWASP ASVS
(Application Security Verification Standard).

The organization should establish organization-wide processes to provide

guidelines for secure coding. The organization should monitor real world
threats and up-to-date advice and information on software vulnerabilities to
guide the organization’s secure coding principles through continual
improvement and learning

ISO 27002 mandates that secure coding practice should be used for both new
and reuse software development senarios. ISO 27002 gives some guidelines
for secure coding during SDLC cycles during planning; before coding, during
coding, during review and post deployment maintenance.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.28 SECURE CODING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability
Development tools should be configured to support creation of secure code
and guidance should be followed (provided by above mentioned frameworks)
to write secure code. If required, the development staff should be trained on
writing secure code and organizations should use controlled development
environments.

During coding the developers should be mandated to use development tools

that support secure development and adopt best practices specific to the
programming language being used. All code and code changes should be
documented. Further there should be peer review of the code to identify the
programming errors and defects and ensure that these programming errors
and defects are mitigated. Finally insecure software programming practices
like ‘hard-coded passwords’ should be avoided.

Developers should secure the “Source Code” and protect the same against
breach of confidentiality (unauthorized access to the code) breach of integrity
(tampering of the code). Strict version control should be maintained.

External libraries if used should be sourced from trusted, reputable and

managed sources that are secure and reliable and ensure license compliancy.

Before software is deployed Application Security Testing should be done using

tools like Burp or AppScan. Application Security Testing helps to identify the
vulnerabilities in the software.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.29 SECURITY TESTING IN
DEVELOPMENT AND ACCEPTANCE.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Identify #Application_security #Protection
#Integrity #Information_security_ass
#Availability urance

Control Statement
Security testing processes should be defined and implemented in the
development life cycle.

Requirement
During the entire SDLC the security testing should be an integral part of
every stage , in addition to other testing. Before deployment in production all
security testing should be completed including code testing, application
security testing and penetration testing.

Implementation
A .8.29 control combines two controls from ISO 27001:2022 –
14.2.8 - system security testing
14.2.9 – system acceptance testing
In order to ensure that vulnerabilities and inappropriate functionality are
removed from the code as soon as possible, and not left until the end of the
software development life cycle, security testing should be conducted prior to
system deployment. Security testing should be an integral part of the testing
for systems.
As a means of identifying vulnerabilities and inappropriate functionality as
early as possible during the entire software development life cycle, systems
should be continuously tested throughout the entire software development life
cycle. A variety of test methods can be employed, including vulnerability
scanning, source code analysis, penetration testing, and manual code reviews.
These methods should be appropriate and relevant to the context of the test.
The best methodology to incorporate security testing in development life
cycle is to express them as functional / non-functional requirements.
Appropriate test plans should be developed. Testing should be proportional to
the criticality of the system. There are automated tools that can be used by
the organization in order to analyze code and identify vulnerabilities. These
tools should be used in conjunction with testing to make sure that security
related defects have been repaired.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.29 SECURITY TESTING IN
DEVELOPMENT AND ACCEPTANCE.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Identify #Application_security #Protection
#Integrity #Information_security_ass
#Availability urance

Introducing new application systems, upgrades of existing systems, or new

versions of application software must be carefully managed in order to
prevent any loss of service or compromise of security to the application
software. These introductions. upgrades of existing systems, and new versions
of application software should be managed carefully so that there will be no
service loss or compromise when production systems or operational systems
are involved.

When a new application system is introduced, it may result in the emergence

of vulnerabilities that have not yet been fully recognized as a result of its
introduction, and these vulnerabilities may not yet have been fully recognized
yet. Before introducing a new system, acceptance criteria must be established,
these criteria need to be checked, and testing must be conducted in order to
identify and eliminate potential vulnerabilities and threats prior to the
introduction of the system. A similar control can also be used when new
subsystems or devices are added or alterations are made to existing systems,
in addition to introducing new subsystems or devices.

Prior to acceptance into production, special consideration should be given to

identifying any adverse effects that could affect existing systems in order to
make sure that these effects can be controlled. When any new facilities are
connected to communication networks, the security of those facilities should
be considered before they are connected in order to ensure their safety. The
documentation of all acceptance tests is essential for ensuring that all levels of
acceptance testing are documented and approved by the appropriate
individuals within the organization to ensure that all acceptance testing takes
place at the appropriate levels.

When developing major new applications, the operations function and other
relevant stakeholders should be consulted at every step to make sure the
proposed security design is actually implemented.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.29 SECURITY TESTING IN
DEVELOPMENT AND ACCEPTANCE.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Identify #Application_security #Protection
#Integrity #Information_security_ass
#Availability urance

Engaging users is important because they are responsible for making sure the
system is running securely. During testing, make sure all acceptance criteria
related to confidentiality and integrity of the information they contain are
fully satisfied. If there are any that aren't, they should be rejected.

In-house development should first be tested by the development team, then

independently by acceptance testers. For outsourced development and
purchasing components, you should follow an acquisition process. A product
and service should be evaluated against these criteria before it is purchased.
These criteria should be considered when selecting a product or service.

In order to ensure that the system does not introduce vulnerabilities into the
company's environment and that testing is reliable, the test environment
should be as close as possible to the production environment in order to
ensure no vulnerabilities are introduced into the company's environment.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.30 OUTSOURCED DEVELOPMENT.

Control Type Infosec Cybersecurity Operational capabilities Security Domains

Properties concepts
#Preventive #Confidentiality #Identify #Application_security #Protection
#Detective #Integrity #Protect #Supplier_relationships_se #Governance_and
#Availability #Detect curity _Ecosystem

Control Statement
The organization should direct, monitor and review the activities related to
outsourced system development.

Requirement
Often organizations outsource software/application development to software
services providers. It is important that adequate information security is
incorporated in the relationship. The requirements according to
organization’s information security policy and other controls should be
implemented by the service provider in the outsourced application
development projects.

Implementation
Often organizations outsource software/application development to software
services providers. The organization should document and communicate the
information security requirements to the deponents as part of RFQs/RFPs.
The information security requirements should be agreed upon as part of legal
contracts. Organizations can develop a checklist of security cases, and the
providers should comply with the checklists. The Organization should
continually monitor and review if the requirements are being met. For long
term projects the organizations may choose a perform an ‘internal audit’ on
the providers environments. In most cases only the organizational portion of
the provider that is engaged in the deliverables is in scope, while in other
cases the entire organization may be in scope e.g. that there may be a
requirement that the provider is ISO 27001 certified, e.g. the US DOD
requires entire organization to meet CMMC requirements.

First of all the two parties should sign an NDA as part of engagement. It is
preferable to sign an NDA for each project depending on the sensitivity of the
information. Further all requirements should be agreed upon via a legal
binding.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.30 OUTSOURCED DEVELOPMENT.

Control Type Infosec Cybersecurity Operational capabilities Security Domains

Properties concepts
#Preventive #Confidentiality #Identify #Application_security #Protection
#Detective #Integrity #Protect #Supplier_relationships_se #Governance_and
#Availability #Detect curity _Ecosystem

Some aspects that can be included in the agreements are as follows

 The security requirements of the infrastructure at provider's premises.

 The data transfer requirements i.e. use of VPN etc.
 The security requirements for providers to access the Organization's
environment and data.
 The applicable regulations like GDPR, PCIDSS and any laws of the land.
 The right to audit provider's environment.
 The security requirements required at provider's side.
 Provider to provide evidence that security & privacy requirements are
met.
 IRP and Licensing rights agreement and ownership and who should
procure.
 The development environment's security requirement and the human
security requirements. (security clearances in certain cases).
 Provider to implement required security controls and provide evidence of
the same on demand.
 agreements on Vulnerability scanning, Application security testing and
penetration testing.
 Escrow agreements.
 Agreements related to identity & access management e.g. MFA etc.
 agreements related to data security e.g. Data labelling and DLP.
 Penalties and fines in case of security breach / regulation non-compliance.

Further information on supplier relationships can be found in the ISO/IEC

27036 series.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.31 SEPARATION OF DEVELOPMENT, TEST AND
PRODUCTION ENVIRONMENTS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Control Statement
Development, testing and production environments should be separated and
secured.

Requirement
Production data and systems require the strictest controls. The test and
development data and systems do not require the strictest controls hence it is
recommended to separate the test and development environment from the
production environment. The production systems and data is critical and
should be protected from any test and development activities that may cause
problems and outages.

Implementation
Separating test and development from production ensures data security,
stability, compliance, and reduced risk of unintentional disruptions.

It's important that operational systems are reliable and have utmost integrity.
Using the same equipment and software to build and test new systems makes
the organization vulnerable to integrity failures and availability issues.
Development or testing of known operational software, network equipment,
or services, or cloud services carries a lot of risk. The use of errors and
omissions may result in unauthorized access, malicious code, data tampering,
and other issues related to security, which can be caused by errors or
omissions.

The test/development environment is not as secure as the production

environment, since you are testing something that may have security flaws.
The test environment should not contain any security controls from the
application or other entity being tested. It is therefore highly recommended
that you do not put sensitive production data into a test environment unless it
is as secure as the production environment.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.31 SEPARATION OF DEVELOPMENT, TEST AND
PRODUCTION ENVIRONMENTS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Separate development, testing, and production facilities should have strong

access controls. If possible, use completely independent systems or at least
separate firewall segmented network domains that are totally separated
from one another. Whenever such a separation isn't possible, separate log-
on procedures can be implemented to make sure access control and
monitoring work. To prepare for production acceptance, finalized and
tested developments should be fed into change control.

An organization needs policies and a secure development environment to

support its development activities in order to ensure the success of its
development activities. In the event that the technology isn't chosen and
configured correctly, as well as the actions of those who have access to the
test or development environment, a high degree of risk could be present. In
order to separate sensitive work from work that is less sensitive, it may be
necessary to separate the work from more sensitive work into multiple test
and development environments. In fact, it is possible for an organization to
decide to maintain an entirely segregated environment for every project it
undertakes in order to reduce any risk of cross contamination occurring.

Below are certain risks related to the development environment-

• Production environments often contain sensitive or real user data.
Developers or testers may unintentionally mishandle or expose sensitive
production data.
• If developers or testers have direct access to production, accidental
changes or errors (e.g., deploying untested code or misconfigurations)
can disrupt services and impact users.
• Development and testing often involve frequent code changes,
experiments, or debugging activities, which can destabilize the
environment. Keeping production separate ensures its stability and
availability for end-users.
• Developers may run scripts, use tools, or install libraries in test
environments that are insecure or unpatched.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.31 SEPARATION OF DEVELOPMENT, TEST AND
PRODUCTION ENVIRONMENTS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

• Test data or development configurations (e.g., hardcoded credentials,

incomplete code) can inadvertently leak into production if environments
are not separated.
• Developers or testers typically require broader permissions and privileged
access in non-production environments for their tasks.
Some of the considerations are as below –
 Test & Development systems have lenient controls to provide flexibility to
Developers
 There should be no testing carried out in production environment.
 There should be no exchange of data between production & test environment.
(Only in special circumstances)
 All development tools should be accessible and installed only in Test environment
 And development tools should not be installed on production systems.
 Production data should not be copied to test or development environments.
 It is recommended to add visible labels to UI of the test or development environments.
 There should be a documented procedure for movement of a system from
Development To Production/Operational.
 All changes should be tested in test environment prior to deployment in prod.
 All patches should be tested in test environment prior to deployment in prod.
 Development & Testing tools should be patched as well.
 Test/Dev environments may have lenient firewall rules hence firewall rules should
be periodically validated.
 Test/Dev environments may have lenient logical access-controls [e.g. No MFA]
hence the access should be periodically revalidated.
 The source code should be adequately protected.
 Test/Dev environment is often exempted from change management but should
not be exempted from monitoring.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.31 SEPARATION OF DEVELOPMENT, TEST AND
PRODUCTION ENVIRONMENTS.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity
#Availability

Developers and testers have access to production systems, so if they don't do

anything right, they could end up in trouble (as in, unwanted modification of
files or system environment, system failure, running untested code in
production, divulging confidential info, data integrity problems).
It's important to have a stable and known testing environment when
performing tests, and developers shouldn't have access to the production
Environment unless that's appropriate.

Test, Development and Production environments should have SoD [Segregation

Of Duties] implemented i.e. Developers and Testers should be different from
Operational personnel.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.32 CHANGE MANAGEMENT.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #System_and_network_sec
#Availability urity

Control Statement
Changes to information processing facilities and information systems should
be subject to change management procedures.

Requirement
Change Management is an important component of IT IS processes. Change
Management is crucial in IT processes to ensure that changes are
systematically planned, evaluated, and implemented, minimizing disruption
to services and reducing risks to system stability and security. It is important
that security is considered in change management. Confidentiality, Integrity
and Availability is preserved during execution of changes.

Implementation
This control replaces 4 controls in 2013 version of ISO 27001.
12.1.2- Change Management
14.2.2- System change control procedures
14.2.3- Technical review of applications after operating platform changes
14.2.4- Restrictions on changes to software packages

Organizations should have a documented change management process which

is both an IT Service Management and IT Security process. The process
should be approved and communicated. A change not only includes changes
to the existing systems but introduction of new systems as well. A change
management process requires documenting changes, testing changes,
ensuring quality, conducting impact analysis (both in terms of security and
business operations), taking approvals etc. This is to ensure changes are
implemented in a controlled manner. From an ISMS perspective Change
control procedures ensure that confidentiality, integrity, availability and
privacy of information in information processing facilities and information
systems is maintained during changes.
In the absence of proper control, changes to an organization's information
processing facilities, systems, and information processing processes may

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.32 CHANGE MANAGEMENT.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Application_security #Protection
#Integrity #System_and_network_sec
#Availability urity
disrupt business operations. In addition to installing new hardware,
deploying software, modifying a business process or operating environment,
acquiring a new cloud service, or connecting new systems to information
processing facilities, there may be problems associated with these activities.

For the purpose of preventing interruptions to the business activities, any

changes that are made to the operational systems should only be made after
they have been tested and a business impact analysis has been performed in
order to prevent interruptions of business activities. Prior to making any
changes, a documented change management procedure must also be followed.
The changes should also be approved by all stakeholders in a formal manner.
During the change management process, all approvals should be included,
and all potential consequences should be taken into account, such as
impacting on confidentiality, integrity, accessibility, and privacy, as well as
taking these considerations into account.
For application development a change management process should be
followed during entire system development life cycle whenever dealing with
production systems or production data.
Change management is not required in test or development environment. But
the “productionization/operationalization” of systems when applications are
migrated from a development environment to production environment for
operations should follow a strict change management process as it can impact
the confidentiality, integrity and availability of the information.
It is a best practice to test the proposed changes and components in a ‘test’
environment segregated from both the production and development
environments.
If changes do not take effect, a change management procedure should also
include the ability to roll back or reverse them. A company needs to use
change management software/trackers if they want to keep track of all the
changes it makes to its information systems. Changes need to be approved,
impact assessed, and reversed in order for them to be successful. For a change
to succeed, it must have the correct approvals, impact analysis, and
procedures to reverse it.
[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.33 TEST INFORMATION.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Information_protection #Protection
#Integrity

Control Statement
Test information should be appropriately selected, protected and managed.

Requirement
It is recommended that production information should not be used for
testing. However, if a need arises organizations need to insure protection of
this data in test and development environments from breaches of
confidentiality and integrity.

Implementation
The data or information which is used for testing during the software
development process should normally be synthetic/fictitious, however many a
times there is a need where operational or production data needs to be used
for testing and generally testing can require substantial volumes of test data
that is as close as possible to production data. Whenever such a situation
arises the data which is used during testing should be appropriately
protected. As a generic practice the test environments are not controlled as
strictly as the production environment because of which there is a risk of
breach of confidentiality when the test data is being used by the software
developers and testers.
First and foremost it is recommended that production data should not be
used in test environment, the use of production data for testing should be a
last resort option. The organization is vulnerable to breaches of
confidentiality when such data is used and it should be avoided as far as
possible. If the use of production data for test cannot be avoided then it is
mandatory that the test environment/system should have the same controls to
protect the data as the production environment/system.

The use of production data in test environment should be authorised by

appropriate management. In such cases the logical access controls in the test
system should be same as that of the production system. If possible
production data should be anonymised or tokenized. If possible the sensitive
data fields which contain PII or PHI information should be obfuscated.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.33 TEST INFORMATION.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Information_protection #Protection
#Integrity

The use of production data in test and development environments should be

logged so that there will be an audit trail of the way the data was used.

In order to ensure the results of a test are accurate, it is recommended to store

the test information securely (to avoid tampering that may invalidate the
results and compromise integrity) and to only use it for testing purposes.

Finally, when the tests are completed and the data is no longer needed, the
data should be securely erased from the test environments and test systems.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.34 PROTECTION OF INFORMATION SYSTEMS
DURING AUDIT TESTING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Information_protection #Protection
#Integrity #Governance_and
#Availability _Ecosystem

Control Statement
Audit tests and other assurance activities involving assessment of operational
systems should be planned and agreed between the tester and appropriate
management.

Requirement
Audits and assessments are vital to IT security and important to ISO27001.
Audits and assessments involve collection of substantial data in a short
amount of time with multiple stakeholders (including external audit parties).
It is important that there is minimal impact of internal/external audit
activities and other assessments on information systems/data and business
processes.

Implementation
Before any internal audit or external audit/assessment of information systems
takes place the audit requirements should be carefully assessed, and if an
audit is deemed required it should be carefully planned and agreed among all
the stakeholders.

As a best practice an internal audit should be conducted annually. Audit

activity on production systems may require the use of special programs that
access the data files used by the system or its applications. The use of systems
during audit by internal or external auditor should be planned to avoid any
destructions to the systems. It is recommended to have internal audit planned
in advance documented and authorised by the senior management.
Organizations generally have internal auditors who are different from the IT
operations, when internal auditors required access to the information systems
to gather artifacts it should always be performed under the supervision of IT
operations team. Dedicated repositories should be set up where all the
artifacts related to the audit can be stored and logical access control should
be managed. Any access given to the auditor should be a read only access.

[Link]
 ISO 27001:2022 | ISO 27002:2022
ANNEX A CLAUSE 8.34 PROTECTION OF INFORMATION SYSTEMS
DURING AUDIT TESTING.
Control Type Infosec Cybersecurity Operational capabilities Security Domains
Properties concepts
#Preventive #Confidentiality #Protect #Information_protection #Protection
#Integrity #Governance_and
#Availability _Ecosystem

All external auditors (or audit agencies) are third-parties and there should be
legal contracts and NDAs. All third-party controls related to access-control &
data security should be followed.
All internal & external audits should have a defined and ‘agreed to’ scope.
The scope should be signed off by management. The auditee should not share
any artifacts or data from Information systems that are not in scope of the
audit.

Only read-only access should be granted to the auditors/testers. Preferably

that auditee should collect the evidence with time-stamp to be shared with
auditor.
It is recommended that audit tests (using automated tools) should be
conducted during non-business hours.
If auditors are planning to use automated audit tools then the same should be
documented and agreed upon. The automated access tools should be first
tested on ‘test’ environment.

When auditors require access to information systems , dedicated ids should

be created for them and all the access should be logged. The auditors should
not be granted admin rights. All access rights should have the necessary
approvals. Auditors should be considered as a third-party and necessary
controls for third-parties should be followed for auditors as well.

When audit activities are completed all the necessary access given to auditors
should be revoked. All the data collected during audit should be archived.
All the audit activities should be carried out as per audit plan/workflow and
all these activities should be monitored and logged with accountability.

[Link]