Security Assurance Requirements - commoncriteria/pp-template GitHub Wiki
Updated 6 February 2024
Security Assurance Requirements (SARs) define the approach for evaluating a product against the SFRs in a Protection Profile. The SAR section of every Protection Profile can be different, but NIAP PPs generally include the same SARs. Below is the most current version from the AppPP as of the date above. The references within the text below might not correspond to the sections of any particular PP, and there may be language specific to the AppPP that would need to be modified for use in another PP.
Of particular note is ALC_TSU, which is not uniform across all PPs. NIAP hopes to devise a uniform version of this SAR, but it might not happen.
Also, all future NIAP PPs are to include ALC_FLR.1, ALC_FLR.2, and ALC_FLR.3 as Optional SARs. For more on ALC_FLR, go farther down the page.
As usual, the Security Assurance Requirements section can be defined in one of the usual three ways:
<section title="Security Assurance Requirements" id="sec-uniqueId">
<sec:Security_Assurance_Requirements>
<sec:secareq title="Security Assurance Requirements">After the section declaration, you can throw in a bunch of text:
<section title="Security Assurance Requirements" id="sec-SARs">
<h:p>
The Security Objectives for the TOE in <xref to="Security_Objectives_for_the_TOE"/> were constructed to address
threats identified in <xref to="Threats"/>. The Security Functional Requirements (SFRs) in <xref to="SFRs"/> are a formal
instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements
(SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation
and performs independent testing.
</h:p><h:p>
This section lists the set of SARs from CC part 3 that are required in evaluations against this
PP. Individual Evaluation Activities (EAs) to be performed are specified both
in <xref to="req"/> as well as in this section. These SARs were chosen based on the notion that a hypothetical
attacker of the TOE lacks administrative privilege on its platform but otherwise has persistent access to the TOE itself
and the sophistication to interact with the platform in a way that they can attmept to access stored data without
authorization or to run tools that automate more sophisticated malicious activity.
</h:p><h:p>
The general model for evaluation of TOEs against STs written to conform to this PP is as follows:
</h:p><h:p>
After the ST has been approved for evaluation, the CCTL will obtain the TOE, supporting
environmental IT, and the administrative/user guides for the TOE. The CCTL is expected to
perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and
ALC SARs. The CCTL also performs the evaluation activities contained within <xref to="req"/>,
which are intended to be an interpretation of the other CEM assurance requirements as they
apply to the specific technology instantiated in the TOE. The evaluation activities that are
captured in <xref to="req"/> also provide clarification as to what the developer needs
to provide to demonstrate the TOE is compliant with the PP. The results of these activities will be documented
and presented (along with the administrative guidance used) for validation.
</h:p>NIAP uses this class unchanged from the CC.
<section title="Class ASE: Security Target" id="class-ase">
As per ASE activities defined in <xref to="bibCEM"/>.
</section> <!-- Class ASE -->This class defines requirements for the TOE Security Specification (TSS) that are addressed in TSS EAs. This should be pretty much the same between all PPs.
<section title="Class ADV: Development" id="class-adv">The information about the TOE
is contained in the guidance documentation available to the end user as
well as the TSS portion of the ST. The TOE developer
must concur with the description of the product that is contained in the TSS as it relates
to the functional requirements. The evaluation activities contained in
<xref to="SFRs"/> should provide the ST authors with sufficient information to
determine the appropriate content for the TSS section.
<a-component cc-id="adv_fsp.1" name="Basic Functional Specification (ADV_FSP.1)">
The functional specification describes the TSFIs. It is not necessary
to have a formal or complete specification of these interfaces. Additionally, because
TOEs conforming to this PP will necessarily have interfaces to the
Operational Environment that are not directly invokable by TOE users,
there is little point specifying that such interfaces be described in and of themselves
since only indirect testing of such interfaces may be possible. For this PP, the
activities for this family should focus on understanding the interfaces presented in the
TSS in response to the functional requirements and the interfaces
presented in the AGD documentation. No additional “functional specification” documentation
is necessary to satisfy the evaluation activities specified. The interfaces that need to be
evaluated are characterized through the information needed to perform the assurance
activities listed, rather than as an independent, abstract list.
<a-element type="D">
<title>The developer shall provide a functional specification.</title>
</a-element>
<a-element type="D">
<title>The developer shall provide a tracing from the functional specification to the SFRs.</title>
<note role="application">As indicated in the introduction to this section, the
functional specification is comprised of the information contained in the AGD_OPE and
AGD_PRE documentation. The developer may reference a website accessible to application
developers and the evaluator. The evaluation activities in the functional requirements
point to evidence that should exist in the documentation and TSS
section; since these are directly associated with the SFRs, the tracing in element
ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.
</note>
</a-element>
<a-element type="C">
<title>The functional specification shall describe the purpose and method of use for
each SFR-enforcing and SFR-supporting TSFI.</title>
</a-element>
<a-element type="C">
<title>The functional specification shall identify all parameters associated with each
SFR-enforcing and SFR-supporting TSFI.</title>
</a-element>
<a-element type="C">
<title>The functional specification shall provide rationale for the implicit
categorization of interfaces as SFR-non-interfering.</title>
</a-element>
<a-element type="C">
<title>The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall determine that the functional specification is an accurate
and complete instantiation of the SFRs.</title>
<aactivity>
<!-- <TSS>-->
There are no specific evaluation activities associated with these SARs, except
ensuring the information is provided. The functional specification documentation is
provided to support the evaluation activities described in <xref to="SFRs"/>, and
other activities described for AGD, ATE, and AVA SARs. The requirements on the content
of the functional specification information is implicitly assessed by virtue of the
other evaluation activities being performed; if the evaluator is unable to perform an
activity because there is insufficient interface information, then an adequate
functional specification has not been provided.
<!-- </TSS> -->
</aactivity>
</a-element>
</a-component>
</section> <!-- Class ADV -->This class contains requirements for the Guidance documentation referenced in the Guidance EAs.
<section id="class-agd" title="Class AGD: Guidance Documentation">
The guidance documents will be
provided with the ST. Guidance must include a description of how the IT personnel verifies
that the Operational Environment can fulfill its role for the security functionality. The
documentation should be in an informal style and readable by the IT personnel. Guidance must
be provided for every operational environment that the product supports as claimed in the
ST. This guidance includes instructions to successfully install the TSF in
that environment; and instructions to manage the security of the TSF as a
product and as a component of the larger operational environment. Guidance pertaining to
particular security functionality is also provided; requirements on such guidance are
contained in the evaluation activities specified with each requirement.
<a-component cc-id="agd_ope.1" name="Operational User Guidance (AGD_OPE.1)">
<a-element type="D">
<title>The developer shall provide operational user guidance.</title>
<note role="application">The operational user guidance does not have to be contained in a
single document. Guidance to users, administrators and application developers can be
spread among documents or web pages. Where appropriate, the guidance documentation is
expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to
support security automation. Rather than repeat information here, the developer should
review the evaluation activities for this component to ascertain the specifics of the
guidance that the evaluator will be checking for. This will provide the necessary
information for the preparation of acceptable guidance.
</note>
</a-element>
<a-element type="C">
<title>The operational user guidance shall describe, for each user role, the
user-accessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.</title>
<note role="application">User and administrator are to be considered in the definition
of user role.</note>
</a-element>
<a-element type="C">
<title>The operational user guidance shall describe, for each user role, how to use the
available interfaces provided by the TOE in a secure manner.</title>
</a-element>
<a-element type="C">
<title>The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of
the user, indicating secure values as appropriate.</title>
</a-element>
<a-element type="C">
<title>The operational user guidance shall, for each user role, clearly present each
type of security-relevant event relative to the user-accessible functions that need to
be performed, including changing the security characteristics of entities under the
control of the TSF.</title>
</a-element>
<a-element type="C">
<title>The operational user guidance shall identify all possible modes of operation of
the TOE (including operation following failure or operational
error), their consequences, and implications for maintaining secure operation.</title>
</a-element>
<a-element type="C">
<title>The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfill the security objectives for the
operational environment as described in the ST.</title>
</a-element>
<a-element type="C">
<title>The operational user guidance shall be clear and reasonable.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.</title>
<aactivity>
<!--<Guidance>-->
<h:p>
Some of the contents of the operational guidance will be verified by the
evaluation activities in <xref to="SFRs"/> and evaluation of the TOE
according to the <xref to="bibCEM"/>. The following additional
information is also required.
</h:p><h:p>
If cryptographic functions are provided by the
TOE, the operational guidance shall contain instructions for
configuring the cryptographic engine associated with the evaluated configuration of
the TOE. It shall provide a warning to the administrator that use of
other cryptographic engines was not evaluated nor tested during the CC evaluation of
the TOE.
</h:p><h:p>
The documentation must describe the process for verifying
updates to the TOE by verifying a digital signature – this may
be done by the TOE or the underlying platform.
</h:p><h:p>
The evaluator shall verify that this process includes the following steps: </h:p>
<h:ul>
<h:li>Instructions for obtaining the
update itself. This should include instructions for making the update accessible to
the TOE (e.g., placement in a specific directory).</h:li>
<h:li>Instructions for initiating the update process, as well as discerning whether the process was
successful or unsuccessful. This includes generation of the digital signature.
The TOE will likely contain security functionality that does not
fall in the scope of evaluation under this PP. The operational guidance shall make it
clear to an administrator which security functionality is covered by the evaluation
activities.</h:li>
</h:ul>
<!-- </Guidance> -->
</aactivity>
</a-element>
</a-component>
<a-component cc-id="agd_pre.1" name="Preparative Procedures (AGD_PRE.1)">
<a-element type="D">
<title>The developer shall provide the TOE, including its preparative procedures.</title>
<note role="application">
As with the operational guidance, the developer should look to
the evaluation activities to determine the required content with respect to preparative
procedures.</note>
</a-element>
<a-element type="C">
<title>The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer's
delivery procedures.</title>
</a-element>
<a-element type="C">
<title>The preparative procedures shall describe all the steps necessary for secure
installation of the TOE and for the secure preparation of the
operational environment in accordance with the security objectives for the operational
environment as described in the ST.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall apply the preparative procedures to confirm that the TOE
can be prepared securely for operation.</title>
<aactivity>
<!-- <Guidance> -->
As indicated in the introduction above, there are significant expectations
with respect to the documentation—especially when configuring the operational
environment to support TOE functional requirements. The evaluator
shall check to ensure that the guidance provided for the TOE
adequately addresses all platforms claimed for the TOE in the ST.
<!--</Guidance> -->
</aactivity>
</a-element>
</a-component>
</section> <!-- Class AGD -->This class covers requirements for evidence regarding the developer's development process and life-cycle support.
<section id="class-alc" title="Class ALC: Life-cycle Support">
At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited
to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s
development and configuration management process. This is not meant to diminish the
critical role that a developer’s practices play in contributing to the overall trustworthiness of a
product; rather, it is a reflection on the information to be made available for evaluation at this
assurance level.
<a-component cc-id="alc_cmc.1" name="Labeling of the TOE (ALC_CMC.1)">
This component is targeted at identifying the TOE such that it can be distinguished from
other products or versions from the same vendor and can be easily specified when being
procured by an end user.
<a-element type="D">
<title>The developer shall provide the TOE and a reference for the TOE.</title>
</a-element>
<a-element type="C">
<title>The application shall be labeled with a unique reference.</title>
<note role="application">
Unique reference information includes:
<h:ul>
<h:li>Application Name</h:li>
<h:li>Application Version</h:li>
<h:li>Application Description</h:li>
<h:li>Platform on which Application Runs</h:li>
<h:li>Software Identification (SWID) tags, if available</h:li>
</h:ul>
</note>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.</title>
<aactivity>
<!-- <TSS>-->
The evaluator shall check the ST to ensure that it contains an identifier
(such as a product name/version number) that specifically identifies the version that
meets the requirements of the ST. Further, the evaluator shall check the operational guidance
and TOE samples received for testing to ensure that the version
number is consistent with that in the ST. If the vendor maintains a website
advertising the TOE, the evaluator shall examine the information on
the website to ensure that the information in the ST is sufficient to distinguish the
product.
<!-- </TSS> -->
</aactivity>
</a-element>
</a-component>
<a-component cc-id="alc_cms.1" name="TOE CM Coverage (ALC_CMS.1)">
<a-element type="D">
<title>The developer shall provide a configuration list for the TOE.</title>
</a-element>
<a-element type="C">
<title>The configuration list shall include the following: the TOE
itself; and the evaluation evidence required by the SARs.</title>
</a-element>
<a-element type="C">
<title>The configuration list shall uniquely identify the configuration items.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.</title>
<aactivity>
<!-- <TSS> -->
The "evaluation evidence required by the SARs" in this PP is limited to the
information in the ST coupled with the guidance provided to administrators and users
under the AGD requirements. By ensuring that the TOE is specifically
identified and that this identification is consistent in the ST and in the AGD
guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly
confirms the information required by this component. Life-cycle support is targeted
aspects of the developer’s life-cycle and instructions to providers of applications
for the developer’s devices, rather than an in-depth examination of the TSF
manufacturer’s development and configuration management process.
This is not meant to diminish the critical role that a developer’s practices play in
contributing to the overall trustworthiness of a product; rather, it’s a reflection on
the information to be made available for evaluation.
<!-- </TSS>
<Guidance> -->
<h:p>
<!-- This is specific to App PP -->
The evaluator shall ensure that the developer has identified (in guidance documentation
for application developers concerning the targeted platform) one or more development environments
appropriate for use in developing applications for the developer’s platform. For each
of these development environments, the developer shall provide information on how to
configure the environment to ensure that buffer overflow protection mechanisms in the
environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that
this documentation also includes an indication of whether such protections are on by
default, or have to be specifically enabled. The evaluator shall ensure that the
TSF is uniquely identified (with respect to other products from the
TSF vendor), and that documentation provided by the developer in
association with the requirements in the ST is associated with the
TSF using this unique identification. </h:p>
<!-- </Guidance>-->
</aactivity>
</a-element>
</a-component>
<!-- ALC_TSU -->
<!-- ALC_TSU is not uniform across all NIAP PPs. This is specific to App PP. -->
<a-component cc-id="alc_tsu_ext.1" name="Timely Security Updates">
This component requires the TOE developer, in conjunction with any other necessary parties,
to provide information as to how the end-user devices are updated to address security issues
in a timely manner. The documentation describes the process of providing updates to the
public from the time a security flaw is reported/discovered, to the time an update is released.
This description includes the parties involved (e.g., the developer, carriers(s)) and the steps
that are performed (e.g., developer testing, carrier testing), including worst case time periods,
before an update is made available to the public.
<a-element type="D">
<title>The developer shall provide a description in the TSS of how timely
security updates are made to the TOE.</title>
<note>
Application developers must support updates to their products for purposes of
fixing security vulnerabilities.
</note>
</a-element>
<a-element type="D">
<title>
The developer shall provide a description in the TSS of how users are notified when
updates change security properties or the configuration of the product.
</title>
</a-element>
<a-element type="C">
<title>The description shall include the process for creating and deploying
security updates for the TOE software.</title>
</a-element>
<a-element type="C">
<title>The description shall express the time window as the length of time,
in days, between public disclosure of a vulnerability and the public availability
of security updates to the TOE.</title>
</a-element>
<a-element type="C">
<title>The description shall include the mechanisms publicly available for
reporting security issues pertaining to the TOE.</title>
<note role="application">
The reporting mechanism could include a website or email address as
well as a means to protect the sensitive nature of the report (e.g., public keys that could be
used to encrypt the details of a proof-of-concept exploit).
</note>
</a-element>
<a-element type="E">
<title>The evaluator <h:i>shall confirm</h:i> that the information provided meets all
requirements for content and presentation of evidence.</title>
<aactivity>
<h:p>
The evaluator shall verify that the TSS contains a description of the timely security update
process used by the developer to create and deploy security updates. The evaluator shall
verify that this description addresses the entire application. The evaluator shall also
verify that, in addition to the TOE developer’s process, any
third-party processes are also addressed in the description. The evaluator shall
also verify that each mechanism for deployment of security updates is described.
</h:p><h:p>
The evaluator shall verify that, for each deployment mechanism described for the update
process, the TSS lists a time between public disclosure of a vulnerability and public
availability of the security update to the TOE patching this vulnerability, to include any third-party
or carrier delays in deployment. The evaluator shall verify that this time is expressed in
a number or range of days.
</h:p><h:p>
The evaluator shall verify that this description includes the publicly available mechanisms
(including either an email address or website) for reporting security issues related to the TOE.
The evaluator shall verify that the description of this mechanism includes a method for
protecting the report either using a public key for encrypting email or a trusted channel for a
website.
</h:p>
</aactivity>
</a-element>
</a-component>
</section> <!-- Class ALC -->Requirements for testing. This includes the NIAP-specific requirement that at least one TOE configuration be tested completely regardless of Equivalency as defined in the Equivalency Guidelines appendix.
<section id="class-ate" title="Class ATE: Tests">
Testing is specified for functional aspects of
the system as well as aspects that take advantage of design or implementation weaknesses.
The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised
functionality and interfaces with dependency on the availability of design information. One
of the primary outputs of the evaluation process is the test report as specified in the
following requirements.
<a-component cc-id="ate_ind.1" name="Independent Testing – Conformance (ATE_IND.1)">
Testing is performed to confirm the
functionality described in the TSS as well as the administrative
(including configuration and operational) documentation provided. The focus of the testing
is to confirm that the requirements specified in <xref to="SFRs"/> are being met,
although some additional testing is specified for SARs in <xref to="SARs"/>. The
evaluation activities identify the additional testing activities associated with these
components. The evaluator produces a test report documenting the plan for and results of
testing, as well as coverage arguments focused on the platform/TOE
combinations that are claiming conformance to this PP. Given the scope of the
TOE and its associated evaluation evidence requirements, this
component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.
<a-element type="D">
<title>The developer shall provide the TOE for testing.</title>
<note role="application">The developer must provide at least one product instance of the TOE
for complete testing on at least one platform regardless of equivalency.
See the Equivalency Appendix for more details.
</note>
</a-element>
<a-element type="C">
<title>The TOE shall be suitable for testing.</title>
</a-element>
<a-element type="E">
<title>The evaluator <h:i>shall confirm</h:i> that the information provided meets all
requirements for content and presentation of evidence.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall test a subset of the TSF to confirm
that the TSF operates as specified.</title>
<note role="application">The evaluator should test the application on the most current
fully patched version of the platform.</note>
<aactivity>
<h:p>
The evaluator shall prepare a test plan and report documenting the testing
aspects of the system, including any application crashes during testing. The evaluator
shall determine the root cause of any application crashes and include that information
in the report. The test plan covers all of the testing actions contained in
the <xref to="bibCEM"/> and the body of this PP’s evaluation activities.
</h:p><h:p>
While it is not necessary to have one test case per test listed in an evaluation activity, the
evaluator must document in the test plan that each applicable testing requirement in
the ST is covered. The test plan identifies the platforms to be tested, and for those
platforms not included in the test plan but included in the ST, the test plan provides
a justification for not testing the platforms. This justification must address the
differences between the tested platforms and the untested platforms, and make an
argument that the differences do not affect the testing to be performed. It is not
sufficient to merely assert that the differences have no effect; rationale must be
provided. If all platforms claimed in the ST are tested, then no rationale is
necessary. The test plan describes the composition of each platform to be tested, and
any setup that is necessary beyond what is contained in the AGD documentation. It
should be noted that the evaluator is expected to follow the AGD documentation for
installation and setup of each platform either as part of a test or as a standard
pre-test condition. This may include special test drivers or tools. For each driver or
tool, an argument (not just an assertion) should be provided that the driver or tool
will not adversely affect the performance of the functionality by the TOE and its platform.
</h:p><h:p>
This also includes the configuration of the
cryptographic engine to be used. The cryptographic algorithms implemented by this
engine are those specified by this PP and used by the cryptographic protocols being
evaluated (e.g SSH). The test plan identifies high-level test objectives
as well as the test procedures to be followed to achieve those objectives. These
procedures include expected results.
</h:p><h:p>
The test report (which could just be an annotated
version of the test plan) details the activities that took place when the test
procedures were executed, and includes the actual results of the tests. This shall be
a cumulative account, so if there was a test run that resulted in a failure; a fix
installed; and then a successful re-run of the test, the report would show a “fail”
and “pass” result (and the supporting details), and not just the “pass” result.
</h:p>
</aactivity>
</a-element>
</a-component>
</section> <!-- Class ATE -->NIAP PPs require only that there are no known vulnerabilities in certified products. This is because NIAP believes that there is little value in evaluators spending time and money on searching for additional vulnerabilities, when everyone knows there will be more vulnerabilities no matter how many a lab may find. Also, it is unclear whether finding vulnerabilities says more about the quality of the product or about the quality of the lab. So here we are.
<section id="class-ava" title="Class AVA: Vulnerability Assessment">
For the current generation of
this protection profile, the evaluation lab is expected to survey open sources to discover
what vulnerabilities have been discovered in these types of products. In most cases, these
vulnerabilities will require sophistication beyond that of a basic attacker. Until
penetration tools are created and uniformly distributed to the evaluation labs, the
evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will
be expected to comment on the likelihood of these vulnerabilities given
the documentation provided by the vendor. This information will be used in the development
of penetration testing tools and for the development of future protection profiles.
<a-component cc-id="ava_van.1" name="Vulnerability Survey (AVA_VAN.1)">
<a-element type="D">
<title>The developer shall provide the TOE for testing.</title>
</a-element>
<a-element type="C">
<title>The application shall be suitable for testing.</title>
<note role="application">Suitability for testing means not being obfuscated or
packaged in such a way as to disrupt either static or dynamic analysis by the
evaluator.</note>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the TOE.</title>
<note role="application">Public domain sources include the Common Vulnerabilities
and Exposures (CVE) dictionary for publicly known vulnerabilities. Public domain
sources also include sites which provide free checking of files for viruses.</note>
</a-element>
<a-element type="E">
<title>The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the TOE is resistant to
attacks performed by an attacker possessing Basic attack potential.</title>
<aactivity>
<h:p>
The evaluator shall generate a report to document their findings with respect to this
requirement. This report could physically be part of the overall test report mentioned in
ATE_IND, or a separate document. The evaluator performs a search of public information to find
vulnerabilities that have been found in similar applications with a particular focus on network
protocols the application uses and document formats it parses.
</h:p><h:p>
The evaluator documents the sources consulted and the vulnerabilities found in the report.
</h:p><h:p>
For each vulnerability found, the evaluator either provides a rationale with respect to its
non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND)
to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack
vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires
expert skills and an electron microscope, for instance, then a test would not be suitable and
an appropriate justification would be formulated.
</h:p><h:p>
<h:span style="font-weight: bold; font-effect: italic">For Windows, Linux, macOS and Solaris:</h:span>
The evaluator shall also run a virus scanner with the most current virus definitions against the
application files and verify that no files are flagged as malicious.
</h:p>
</aactivity>
</a-element>
</a-component>
</section> <!-- Class AVA -->
</section> <!-- Security Assurance Requirements -->The Flaw Remediation SARs (ALC_FLR.1, ALC_FLR.2, and ALC_FLR.3) are optional in all NIAP PPs starting with CC:2022. Flaw Remediation must be claimed in order to comply with the new EUCC scheme, but is not required for NIAP certification. So it's up to the ST Author whether or not to claim these optional SARs.
In XML, these SARs should have the status attribute set to "optional." The optional SARs should be defined in the Security Assurance Requirements section with all the other SARs, but in the finished document, the framework places them in Appendix A.1 with the other Strictly Optional requirements.
It should be possible to copy and paste the below into the ALC Class of an the Security Assurance Requirements section of an XML document.
<a-component cc-id="alc_flr.1" name="Basic flaw remediation (ALC_FLR.1)" status="optional">
Flaw remediation requires that discovered security flaws be tracked and corrected by the
developer. Although future compliance with flaw remediation procedures cannot be determined
at the time of the TOE evaluation, it is possible to evaluate the policies and procedures that a
developer has in place to track and correct flaws, and to distribute the flaw information and
corrections.<h:br/>
This family provides assurance that the TOE will be maintained and supported in the future,
requiring the TOE developer to track and correct flaws in the TOE. Additionally, requirements are
included for the distribution of flaw corrections. However, this family does not impose evaluation
requirements beyond the current evaluation.
<a-element type="D">
<title>The developer shall document and provide flaw remediation procedures addressed to TOE
developers.</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures documentation shall describe the procedures used to
track all reported security flaws in each release of the TOE.</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall require that a description of the nature and effect
of each security flaw be provided, as well as the status of finding a correction to that flaw.</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall require that corrective actions be identified for
each of the security flaws.</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures documentation shall describe the methods used to
provide flaw information, corrections and guidance on corrective actions to TOE users.</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.</title>
</a-element>
</a-component>
<a-component cc-id="alc_flr.2" name="Flaw reporting procedures (ALC_FLR.2)" status="optional">
In order for the developer to be able to act appropriately upon security flaw reports from TOE
users, and to know to whom to send corrective fixes, TOE users need to understand how to submit
security flaw reports to the developer. Flaw remediation guidance from the developer to the TOE
user ensures that TOE users are aware of this important information.
<a-element type="D">
<title>The developer shall document and provide flaw remediation procedures addressed to TOE
developers.</title>
</a-element>
<a-element type="D">
<title>The developer shall establish a procedure for accepting and acting upon all reports of
security flaws and requests for corrections to those flaws.
</title>
</a-element>
<a-element type="D">
<title>The developer shall provide flaw remediation guidance addressed to TOE users.</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures documentation shall describe the procedures used to track all
reported security flaws in each release of the TOE.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall require that a description of the nature and effect of each
security flaw be provided, as well as the status of finding a correction to that flaw.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall require that corrective actions be identified for each of the
security flaws.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures documentation shall describe the methods used to provide flaw
information, corrections and guidance on corrective actions to TOE users.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall describe a means by which the developer receives
from TOE users reports and enquiries of suspected security flaws in the TOE.
</title>
</a-element>
<a-element type="C">
<title>The procedures for processing reported security flaws shall ensure that any reported
flaws are remediated and the remediation procedures issued to TOE users.
</title>
</a-element>
<a-element type="C">
<title>The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation guidance shall describe a means by which TOE users report to the
developer any suspected security flaws in the TOE.
</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
</title>
</a-element>
</a-component>
<a-component cc-id="alc_flr.3" name="Systematic flaw remediation (ALC_FLR.3)" status="optional">
In order for the developer to be able to act appropriately upon security flaw reports from TOE
users, and to know to whom to send corrective fixes, TOE users need to understand how to submit
security flaw reports to the developer, and how to register themselves with the developer so that
they may receive these corrective fixes. Flaw remediation guidance from the developer to the TOE
user ensures that TOE users are aware of this important information.
<a-element type="D">
<title>The developer shall document and provide flaw remediation procedures addressed to TOE
developers.
</title>
</a-element>
<a-element type="D">
<title>The developer shall establish a procedure for accepting and acting upon all reports of security
flaws and requests for corrections to those flaws.
</title>
</a-element>
<a-element type="D">
<title>The developer shall provide flaw remediation guidance addressed to TOE users.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures documentation shall describe the procedures used to track all
reported security flaws in each release of the TOE.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall require that a description of the nature and effect of each
security flaw be provided, as well as the status of finding a correction to that flaw.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall require that corrective actions be identified for each of the
security flaws.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures documentation shall describe the methods used to provide flaw
information, corrections and guidance on corrective actions to TOE users.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall describe a means by which the developer receives from
TOE users reports and enquiries of suspected security flaws in the TOE.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation procedures shall include a procedure requiring timely response and
the automatic distribution of security flaw reports and the associated corrections to
registered users who might be affected by the security flaw.
</title>
</a-element>
<a-element type="C">
<title>The procedures for processing reported security flaws shall ensure that any reported flaws are
remediated and the remediation procedures issued to TOE users.
</title>
</a-element>
<a-element type="C">
<title>The procedures for processing reported security flaws shall provide safeguards that any
corrections to these security flaws do not introduce any new flaws.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation guidance shall describe a means by which TOE users report to the
developer any suspected security flaws in the TOE.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation guidance shall describe a means by which TOE users may register
with the developer, to be eligible to receive security flaw reports and corrections.
</title>
</a-element>
<a-element type="C">
<title>The flaw remediation guidance shall identify the specific points of contact for all reports
and enquiries about security issues involving the TOE.
</title>
</a-element>
<a-element type="E">
<title>The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
</title>
</a-element>
</a-component>