ISO/IEC TS 9569:2023

TECHNICAL ISO/IEC TS
SPECIFICATION 9569
First edition
2023-11
Information security, cybersecurity
and privacy protection — Evaluation
criteria for IT security — Patch
Management Extension for the ISO/
IEC 15408 series and ISO/IEC 18045
Sécurité de l'information, cybersécurité et protection de la vie
privée — Critères d'évaluation pour la sécurité des TI — Extension
pour la gestion des correctifs concernant la série ISO/IEC 15408 et
l'ISO/IEC 18045
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Overview . 4
4.1 Background information . 4
4.2 Proposed approach . 6
4.3 Non-public vulnerabilities . 6
5 Patch management family .7
5.1 General . 7
5.2 Patch management (ALC_PAM) . 7
5 . 2 .1 Obje c t i ve s . 7
5.2.2 Component levelling . 7
5.2.3 Application notes . 7
5.2.4 ALC_PAM.1 Patch management. 8
5.3 E valuation work units for ALC_PAM . 9
5.3.1 Action ALC_PAM.1.1E . 9
6 Additional guidance for evaluators .13
6.1 General .13
6.2 Class ASE . 13
6.2.1 ASE_INT .13
6.3 Class ADV . 14
6.3.1 ADV_ARC . 14
6.3.2 ADV_FSP . 14
6.3.3 ADV_IMP . 14
6.3.4 ADV_TDS . 14
6.4 Class AGD . 14
6.4.1 AGD_OPE . 14
6.4.2 AGD_PRE . 14
6.5 Class ALC . . 14
6.5.1 ALC_CMC . 14
6.5.2 ALC_CMS . 15
6.5.3 ALC_DEL . .15
6.5.4 ALC_DVS . 16
6.5.5 ALC_FLR . 16
6.5.6 ALC_LCD . 16
6.5.7 ALC_TAT . 16
6.6 Class ATE. 17
6.6.1 ATE_COV . 17
6.6.2 ATE_DPT . 17
6.6.3 ATE_IND . 17
6.7 Class AVA . 17
6.7.1 AVA_VAN . 17
Annex A (informative) Options for evaluation authorities .18
Annex B (informative) Template for the security relevance report .21
Annex C (informative) ALC_PAM PMD examples .22
Annex D (informative) Patch management functional package example .25
Bibliography .36
iii
© ISO/IEC 2023 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of
any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC
had not received notice of (a) patent(s) which may be required to implement this document. However,
implementers are cautioned that this may not represent the latest information, which may be obtained
from the patent database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall
not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
iv
© ISO/IEC 2023 – All rights reserved

Introduction
The ISO/IEC 15408 series is intended to be used to evaluate the assurance of IT products. While the
ISO/IEC 15408 series can be used to perform an initial evaluation of an IT product, it does not support a
differential security evaluation of that product, subsequent to one or several patches being applied to it.
Neither the ISO/IEC 15408 series nor ISO/IEC 18045 contain dedicated methods or evaluation activities
which would support the evaluation of changes or updates.
Some of these aspects were addressed by users of the ISO/IEC 15408 series, in particular evaluation
authorities, but also within the mutual recognition agreements (e.g. Common Criteria Recognition
Arrangement). In many real-world use-cases, developers provide updated or patched target of
evaluations (TOEs), but the effort to re-certify these versions has mostly been avoided.
This problem of patch management and its related components are missing from the current
ISO/IEC 15408 series and ISO/IEC 18045. To address this problem, requirements and recommendations
are needed on how to regain assurance of an updated target of evaluation in a standardized and widely
accepted way e.g. in terms of effort and costs.
This document collects discussions and experience from the experts involved in the ISO/IEC 15408
series and ISO/IEC 18045, to address the evaluation of the patch management during the evaluation of
the initial TOE in a standardized way. This document also discusses alternatives for the evaluation of
patched TOEs, although it does not provide a standardized approach.
This document is intended to be used as an extension to the ISO/IEC 15408 series and ISO/IEC 18045.
Clause 5 includes the definition of the new patch management assurance family following the structure
defined in the ISO/IEC 15408 series and ISO/IEC 18045. Clause 6 includes additional guidance for the
evaluators of the initial target of evaluation (TOE). Annex A summarizes experiences in evaluation
schemes as options for adoption.
NOTE This document uses bold and italic type in some cases to distinguish terms from the rest of the text.
The relationship between components within a family is highlighted using a bolding convention. This convention
calls for the use of bold type for all new requirements. For hierarchical components, requirements are presented
in bold type when they are enhanced or modified beyond the requirements of the previous component. In
addition, any new or enhanced permitted operations beyond the previous component are also highlighted using
bold type. The use of italics indicates text that has a precise meaning. For security assurance requirements, the
convention is for special verbs relating to evaluation.
This document follows the conventions introduced in the ISO/IEC 15408 series and ISO/IEC 18045.
v
© ISO/IEC 2023 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 9569:2023(E)
Information security, cybersecurity and privacy
protection — Evaluation criteria for IT security — Patch
Management Extension for the ISO/IEC 15408 series and
ISO/IEC 18045
1 Scope
This document specifies patch management (PAM) security assurance requirements and is intended to
be used as an extension of the ISO/IEC 15408 series and ISO/IEC 18045.
The security assurance requirements specified in this document do not include evaluation or test
activities on the final target of evaluation (TOE), but focus on the initial TOE and on the life cycle
processes used by manufacturers. Additionally, this document gives guidance to facilitate the evaluation
of the TOE, including the patch and development processes which support the patch management.
This document lists options for evaluation authorities (or mutual recognition agreements) on how to
utilize the additional assurance and additional evidence in their processes to enable the developer to
consistently re-certify their updated or patched TOEs to the benefit of the users. The implementation of
these options using an evaluation scheme is out of the scope of this document.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
activation
operation performed on a patch to transform the initial target of evaluation (TOE) (3.8) into the final
TOE (3.4)
Note 1 to entry: Activation is an atomic operation which can only be done in one step (partial activation is not
allowed).
Note 2 to entry: In addition to installing the modified functionality, this operation shall encompass a change in
TOE identification.
Note 3 to entry: The TOE shall remain in a secure state even if interruption or incident occurs during such
operation, which prevents the forming of the final TOE.
3.2
end-of-support
date until when the user can expect to receive new patches
Note 1 to entry: The end-of-support should be greater than the period of validity of the certificate.
© ISO/IEC 2023 – All rights reserved

Note 2 to entry: The period of validity of the certificate can be extended through the standard assurance
continuity.
3.3
evaluation authority
body operating an evaluation scheme
[SOURCE: ISO/IEC 15408-1:2022, 3.40]
3.4
final target of evaluation
final TOE
initial TOE (3.8) with the patches (3.11) applied
Note 1 to entry: The final TOE is obtained by combining the initial TOE and patch(es) to be loaded and activated
on the initial TOE.
Note 2 to entry: The final TOE is not necessarily evaluated but assurance is gained through ALC_PAM on the
initial TOE.
3.5
flaw remediation
assurance family ALC_FLR which provides requirements for the handling of security flaws
Note 1 to entry: This definition of flaw remediation is based on ISO/IEC 15408-3:2022, 12.1.
3.6
identification data
data that identifies the initial target of evaluation (3.8), the applied patch(es) (3.11) or the final target of
evaluation (3.4)
3.7
initial evaluation
complete evaluation of the initial target of evaluation (3.8)
3.8
initial TOE
initial target of evaluation
target of evaluation (TOE) (3.18) that supports evaluated features allowing at least to securely load,
activate and execute patch(es), without any applied patches
Note 1 to entry: The final TOE (3.4) is obtained by loading and activating the patches for the initial TOE.
Note 2 to entry: The final TOE may not be evaluated but assurance is gained through the evaluation of ALC_PAM
on the initial TOE.
3.9
loader
piece of the target of evaluation security functionality (3.19) of the initial target of evaluation (3.8) that
implements the activation (3.1) of a patch (3.11)
3.10
maintenance
process provided by an evaluation authority that recognises that a set of one or more applied patches
(3.11) made to an initial target of evaluation (TOE) (3.8) has not adversely affected the assurance
Note 1 to entry: Changes in the development environment can be considered as maintenance if they relate to the
TOE.
Note 2 to entry: Maintenance is typically applied in the context of certification.
© ISO/IEC 2023 – All rights reserved

3.11
patch
type of source code or binary code to be added to an initial target of evaluation (TOE) (3.8) in order to
introduce additions or modifications of a functional or security feature
Note 1 to entry: A patch is loaded on the initial TOE and activated to obtain the final TOE.
Note 2 to entry: Full replacement of a TOE is a possible implementation of “patchability” and a current practice
for software TOEs.
3.12
patch management
PAM
processes applied during patch (3.11) development and patch release
3.13
patch management documentation
PMD
documentation describing the policies, processes, procedures related to the patching of the target of
evaluation (3.18)
3.14
patch verification mechanism
technical mechanism to verify the integrity and/or authenticity of a patch (3.11)
3.15
re-evaluation
process of recognising that changes made to an initial target of evaluation (3.8) require independent
evaluator activities to be performed in order to establish a new assurance baseline
Note 1 to entry: Re-evaluation seeks to reuse results from a previous evaluation.
3.16
security assurance requirement
SAR
security requirement that refers to the conditions and processes for the development and delivery of
the target of evaluation (3.18), and the actions required of evaluators with respect to evidence produced
from these conditions and processes
[SOURCE: ISO/IEC 15408-1:2022, 3.76]
3.17
security relevance report
SRR
document containing the assessment of security relevance of a patch (3.11)
3.18
target of evaluation
TOE
set of software, firmware and/or hardware possibly accompanied by guidance, which is the subject of
an evaluation
[SOURCE: ISO/IEC 15408-1:2022, 3.90]
3.19
target of evaluation security functionality
TOE security functionality
TSF
combined functionality of all hardware, software, and firmware of a target of evaluation (TOE) (3.18)
that is relied upon for the correct enforcement of the security functional requirements
[SOURCE: ISO/IEC 15408-1:2022, 3.92]
© ISO/IEC 2023 – All rights reserved

3.20
transport
process of transferring patches from the developer to the user who applies the patch (3.11)
3.21
vulnerability
weakness in the target of evaluation (3.18) that can be used to violate the security functional
requirements in a specified environment
Note 1 to entry: In the definition of ALC_PAM.1 in 5.2.4, the term flaw is used to ensure consistency with ALC_
FLR components.
4 Overview
4.1 Background information
Figure 1 shows the product vulnerability timeline for the case after a new vulnerability is detected and
becomes publicly known. Until the developer releases an update that removes the vulnerability, and
that update is applied, the product will be insecure. This status is shown in black below.
Key
The product is vulnerable due to the lack of a patch.
Figure 1 — Product vulnerability timeline
Consequently, developers have a responsibility to build and release those updates in a short period of
time after the vulnerability becomes known. Developers who obtained a certificate previously may
request a re-evaluation of the TOE (for example for issuing a new certificate, or because it is mandated
by their clients). In many real-world cases, re-evaluation does not happen for every patch of the product,
mostly due to cost and delay.
Since the patched TOE has not been re-evaluated, the developer can introduce a regression defect while
deploying the vulnerability fix or in the fix itself. In the absence of evaluation by a skilled third party,
there is a general lack of assurance on the patched TOE. This transfers the decision to use either a
previously certified or a recently patched version to the user of the TOE.
Therefore, the user of the TOE should run their own risk assessment to determine which version of the
TOE to use. If users of the TOE limit themselves to evaluated versions, they therefore accept known
vulnerabilities in the TOE. Further risk mitigation should also be done, i.e. additional compensating
countermeasures against the new vulnerabilities should be implemented. Conversely, using patched
TOEs can also include flaws introduced by the developer during the patch development or deployment.
Figure 2 illustrates the timeline and relationship of a TOE when a new vulnerability occurs, a patch
becomes available and the status of the certification is not in sync.
© ISO/IEC 2023 – All rights reserved

Key
The TOE is vulnerable due to the lack of a patch.
The user is unable to decide whether it is better to use the evaluated TOE or the patched TOE.
a The user can use the (re-)evaluated TOE.
b Time for maintenance / re-certification.
Figure 2 — Timeline showing availability of patch and the corresponding new certificate
The focus is on the time for maintenance or re-certification (see Figure 2), in particular:
— how to ease re-evaluations, to optimally shorten the time for maintenance or re-certification;
— how to give some degree of assurance to the user so that, during this maintenance or re-certification
period, they can choose to deploy the patched TOE.
This proposed patch management extension has the following advantages for the different stakeholders:
— Easing the re-evaluation process, therefore helping regulatory bodies in mandating re-evaluations
when needed.
— Helping users to resolve the dilemma of whether to keep the evaluated version, or move to the
patched version, by providing some degree of assurance on the patched TOE by assessing, during
the initial evaluation that:
— the patch deployment process provides procedural security measures against the introduction
of regressions;
— the TOE security functionality, including mechanisms allowing the TOE to be patched, are
evaluated for conformity and robustness to avoid introducing vulnerabilities on the TOE.
— Helping developers by providing a standard way to assess the security of their patch development
and deployment processes, as well as standard requirements to define the patching capabilities of
their products.
— Helping evaluation authorities with a set of options they can provide within their policies to the
customers (i.e. developers) to offer flexible and modern evaluation approaches.
© ISO/IEC 2023 – All rights reserved

4.2 Proposed approach
The solution involves the following two aspects:
— Add additional functional requirements which address the patch or update functionality of the
initial TOE. This document does not define mandatory content for the security problem definition
or security functional requirements (SFRs). The security target or protection profile should contain
TOE or TOE-type specific information. To facilitate the authoring of these documents, Annex C gives
an example for a security problem definition and corresponding objectives. Additionally, Annex D
includes guidance on how to write SFRs for the patch functionality.
— Add additional life cycle requirements (ALC_PAM) to get commitment from developers to
consistently monitor for flaws or issues after release of the initial TOE, but also encourage developers
to consistently generate evidence for future re-evaluations (see 5.2).
Figure 3 shows the application of ALC_PAM, which supports the timely delivery of the patch or update,
but also the maintenance of the internal and external assurance activities.
Key
The TOE is vulnerable due to the lack of a patch.
The user is unable to decide whether it is better to use the evaluated TOE or the patched TOE.
a The user can use the (re-)evaluated TOE.
b Time for maintenance / re-certification.
Figure 3 — Timeline showing application of ALC_PAM
4.3 Non-public vulnerabilities
For many IT products, researchers discovering vulnerabilities are incentivised to not disclose the
vulnerabilities until the developers have had an opportunity to patch them. In this case, it is plausible
that the end user of the TOE is not aware of the vulnerability and the presence of the vulnerability
can be considered a residual risk inherent to the use of any IT product. Consequently, many security
patches are issued prior to end users and the public being made aware of the vulnerability.
The assurance family ALC_PAM introduced in this document provides a way to increase the assurance
on developer patching procedures. When vulnerabilities are reliably fixed by patching procedures
before the vulnerability is made public, there is less opportunity for successful attacks.
© ISO/IEC 2023 – All rights reserved

5 Patch management family
5.1 General
This clause defines the new assurance family ALC_PAM.
The security assurance requirements (SARs) introduced in 5.2 are related to different evaluation
phases. During initial evaluation of the TOE, additional evaluation actions shall be introduced
(compared to the standard SAR from ISO/IEC 15408-3) to establish assurance for the future patch
generation process. The concept is to define ALC_PAM (patch management) and augment this family
during initial evaluation in the security target.
As patch management is part of the life cycle assurance, it has been introduced under the ALC class.
ALC_PAM describes how to handle patches life cycle, design, development, validation and release, but
not the remediation flow. For this reason, ALC_PAM is not part of ALC_FLR (flaw remediation) even if
a patch is a fix for a flaw managed in accordance with ALC_FLR. Both classes are closely related and
therefore the dependency with ALC_FLR.2 was defined.
ALC_PAM, contrastingly, aims to support maintenance of the TOE assurance over the product life cycle.
This family requires developers to provide a patch management policy and to follow this policy to
develop patches for the TOE at the time of evaluation. This family also requires developers to define a
procedure for the self-assessment to maintain the quality of the TOE after its evaluation. The developer
can publish the result of the self-assessment to show the current status of the latest version of the TOE
(e.g. re-evaluation is required or assurance is maintained) to the TOE users.
Annex B contains an example of a patch policy which fulfils the given requirements.
5.2 Patch management (ALC_PAM)
5.2.1 Objectives
The objective of this family is to identify the policies and procedures to be implemented in the
development process, which will be applied after the initial release of a TOE by the developer.
The application of the patch management (PAM) process cannot be always determined at the time of the
initial evaluation. Nevertheless, it is possible to evaluate the policies and procedures that a developer
has in place to perform the PAM process for a future patch release. It is also possible to obtain some
evidence of the correct application of the procedures during the patching of the problems which are
found during the evaluation of other assurance classes like AVA (vulnerability assessment) and ATE
(tests).
The written PAM policies, processes and procedures are internal documents for the developer. These
shall include instructions, among others, on how developers securely provide guarantees of authenticity
to distribute and apply patches and how the life cycle of the keys, used for providing authenticity of new
patches, is handled.
These procedures shall guarantee the secure development, the secure deployment, installation and
activation for patches. Moreover, the procedures and the set of commands supporting them shall be
described in the AGD (guidance) family.
5.2.2 Component levelling
This family contains only one component.
5.2.3 Application notes
None.
© ISO/IEC 2023 – All rights reserved

5.2.4 ALC_PAM.1 Patch management
Dependencies: ALC_FLR.2 flaw reporting procedures.
Application note: The purpose of ALC_FLR is to build assurance of the flaw remediation procedures
which are applied after security flaws were discovered. Separately, the purpose of ALC_PAM is to build
assurance of the patch management processes which are applied when the behaviour of the initial TOE
is changed independent of the type of change.
Therefore, the relationship of ALC_FLR to ALC_PAM is justified by the need to release patches to
distribute flaw corrections.
Table 1 contains the developer action elements, Table 2 contains the content and presentation elements
and Table 3 contains the evaluator action elements of ALC_PAM.1.
Table 1 — ALC_PAM.1 developer action elements
Element Definition
ALC_PAM.1.1D The developer shall provide patch management documentation (PMD) for the TOE.
ALC_PAM.1.2D The developer shall provide end-of-support information to the TOE users.
ALC_PAM.1.3D The developer shall follow the PMD on a regular basis.
ALC_PAM.1.4D The developer shall record evidence of the application of the PMD.
ALC_PAM.1.5D The developer shall release patches as defined in the PMD until the end-of-support
of the TOE.
ALC_PAM.1.6D The developer shall follow the PMD to produce an updated set of evaluation evi-
dence for each released patch at least until the stated end-of-support of the TOE.
ALC_PAM.1.7D The developer shall provide a channel used to check for the availability and/or
download of patches with means to protect the channel according to the specified
security capabilities of the TOE.
ALC_PAM.1.8D The developer shall create a security relevance report (SRR) for each patch release.
Table 2 — ALC_PAM.1 content and presentation elements
Element Definition
ALC_PAM.1.1C The PMD shall state the criteria used for the decision that a patch shall be released.
ALC_PAM.1.2C The PMD shall require the generation of an SRR and shall identify any applicable
procedure.
ALC_PAM.1.3C The SRR shall describe the flaws, changes and impact that are related to the patch.
ALC_PAM.1.4C The PMD shall describe how to update the initial TOE evidence for any applicable SAR.
ALC_PAM.1.5C The PMD shall define how to record any PAM-related decision.
ALC_PAM.1.6C The PMD shall describe the mandatory patch-specific content for the preparative
procedures and the operational user guidance.
ALC_PAM.1.7C The PMD shall describe the mandatory procedures during patch release.
ALC_PAM.1.8C The PMD shall contain rules regarding testing (using internal resources or using
external third party) before a patch is released.
ALC_PAM.1.9C The PMD shall describe how end users are notified of a new patch and correspond-
ing installation instructions.
ALC_PAM.1.10C The PMD shall describe all necessary developer procedures to support the patch
functionality of the TOE.
Table 3 — ALC_PAM.1 Evaluator action elements
Element Definition
ALC_PAM.1.1E The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
© ISO/IEC 2023 – All rights reserved

5.3 E valuation work units for ALC_PAM
5.3.1 Action ALC_PAM.1.1E
5.3.1.1 General
ALC_PAM.1.1C The PMD shall state the criteria used to decide that a patch shall be released.
5.3.1.2 Work unit ALC_PAM.1-1
ALC_PAM.1-1 The evaluator shall check for the definition of the criteria which is used to decide that a
patch shall be released, and check for the implementation as a policy. Example of a list of criteria:
— complexity of backports;
— operational stability, development teams are able to estimate effect for operational stability;
— security impact;
— customer impact (i.e. practical problems, theoretical problems);
— time impact, e.g. to address customer expectations;
— any other criteria dependent from developer business case.
5.3.1.3 Work unit ALC_PAM.1-2
ALC_PAM.1-2 The evaluator shall check the status of the implementation of the policies for patch
releases and examine if such policies are detailed enough to enable a repeatable resolution of patch
development, testing and release.
5.3.1.4 Work unit ALC_PAM.1-3
ALC_PAM.1-3 The evaluator shall examine if the following mandatory PMD content has been
implemented:
— criteria used to decide that a patch shall be released;
— unique label for each patch to identify all release items.
ALC_PAM.1.2C The PMD shall require the generation of an SRR and shall identify any applicable procedure.
5.3.1.5 Work unit ALC_PAM.1-4
ALC_PAM.1-4 The evaluator shall check that the PMD mandates the generation of an SRR prior to patch
release and that all the patching procedures are referenced unambiguously. If the policies distinguish
between different categories of a patch, then the evaluator shall check that the SRR and the associated
procedures cover each of the categories.
ALC_PAM.1.3C The SRR shall describe the flaws, changes and the impact that are related to the patch.
5.3.1.6 Work unit ALC_PAM.1-5
ALC_PAM.1-5 The evaluator shall check the format of the SRR used by the developer.
The SRR shall contain following mandatory elements:
— each flaw shall be listed and explained;
— the related changed shall be listed and explained;
© ISO/IEC 2023 – All rights reserved

— for each change, the security impact shall be given by means of security relevance criteria (e.g.
remote execution, only product type specific) or a standardized category system [e.g. common
weakness enumeration (CWE)].
Annex B includes a template for the SRR.
ALC_PAM.1.4C The PMD shall describe how to update the evidence documentation used in the initial
evaluation for any applicable SAR.
5.3.1.7 Work unit ALC_PAM.1-6
ALC_PAM.1-6 The evaluator shall check if the PMD describes how to update the evidence documentation
in a consistent way with the evaluation assurance level.
ALC_PAM.1.5C The PMD shall define how to record any PAM-related decision.
5.3.1.8 Work unit ALC_PAM.1-7
ALC_PAM.1-7 The evaluator shall check that the PMD describes how to record decisions related to the
patch delivery.
ALC_PAM.1.6C The PMD shall describe the mandatory patch-specific content for the preparative procedures
and the operational user guidance.
5.3.1.9 Work unit ALC_PAM.1-8
ALC_PAM.1-8 The evaluator shall check the PMD for instructions on how to update the initial TOE
preparative procedures and operational user guidance anytime a patch is released. For example, by
providing a checklist to cover all the steps of the patching process from loading to activation.
Application note: This work unit is different from ALC_FLR.2-5 because it requires developers to
document how to update initial TOE documentation when a patch is released, and not how to notify
users about how to fix a security flaw.
ALC_PAM.1.7C The PMD shall describe the mandatory procedures during patch release.
5.3.1.10 Work unit ALC_PAM.1-9
ALC_PAM.1-9 The evaluator shall check the PMD for mandatory patch release procedures.
ALC_PAM.1.8C The PMD shall contain rules regarding testing (using internal resources or using external
third party) before a patch is released.
5.3.1.11 Work unit ALC_PAM.1-10
ALC_PAM.1-10 The evaluator shall check the PMD for rules that require different types of testing (e.g.
by the evaluation facility, or by the developer) and what should be tested and how. For example, a rule
set for the different roles in the (patch) release procedure such as development, quality assurance
department, product owner, etc.
Evaluation authorities can define specific rules for the coverage and depth for re-testing until the TOE
end-of-support.
ALC_PAM.1.9C The PMD shall describe how end users are notified of a new patch and corresponding
installation instructions.
© ISO/IEC 2023 – All rights reserved

5.3.1.12 Work unit ALC_PAM.1-11
ALC_PAM.1-11 The evaluator shall examine if the PAM processes address how patches are securely
generated and distributed, including applicable responsibilities and procedures. These processes
include:
a) how the user is notified of the availability of a new patch due to a security issue, e.g.:
— through email;
— through systematic checks to a website handled by the product.
b) how the patches are made available and securely distributed to the end user, for example:
— uploaded to a website by the developer and systematically downloaded by the TOE by using an
appropriate and declared security protocol;
— sent to the end-user using delivery services and providing installation instructions where
administrator rights shall be implemented using password/authentication codes and/or
cryptographic authentication techniques.
ALC_PAM.1.10C The PMD shall describe all necessary developer procedures to support the patch
functionality of the TOE.
5.3.1.13 Work unit ALC_PAM.1-12
ALC_PAM.1-12 The evaluator shall examine the implementation of the PMD specified by the developer.
For example, implemented procedures for using cryptographic keys or signatures for patches.
If applicable, the evaluator shall examine:
— How the cryptographic keys involved in signing and/or distributing patches are generated and
managed during its entire life-cycle so they have enough strength to protect the authenticity of
the updates?
— How the cryptographic keys are created?
— How the cryptographic keys are securely stored?
— How the cryptographic keys used to provide authenticity, integrity, confidentiality or protection
against replay or misuse of new patches have a strength commensurate with the evaluation
assurance level?
— How the cryptographic keys are destroyed or archived at the end-of-support of the product?
— Who approves the releasing of updates?
— Who can access the cryptographic keys used for signing updates?
ALC_PAM.1.2D The developer shall provide end-of-support information to the TOE users.
5.3.1.14 Work unit ALC_PAM.1-13
ALC_PAM.1-13 The evaluator shall check that end-of-support information is available to the TOE users,
e.g. in documents such as the security target (ST), guidance, release notes, and/or information on the
product (support) website.
5.3.1.15 Work unit ALC_PAM.1-14
ALC_PAM.1-14 The evaluator shall examine the end-of-support information to ensure consistency
across documents if the information is present in several documents.
© ISO/IEC 2023 – All rights reserved

5.3.1.16 Work unit ALC_PAM.1-15
ALC_PAM.1-15 The evaluator shall check that the end-of-support information is unambiguous and
complete in the sense that it allows users to determine or put in place the measures to know the date of
the end-of-support. For example, end-of-support information can contain:
— end of product maintenance;
— end of product manufacturing;
— end of general availability;
— last order date.
5.3.1.17 Work unit ALC_PAM.1-16
ALC_PAM.1-16 The evaluator shall examine the end-of-support information of the developer and any
corresponding evidence if this gives a rationale for the end-of-support date.
The rationale should allow the end user to consider the end-of-support date into his general TOE risk
management.
ALC_PAM.1.4D The developer shall record evidence of the application
...