ISO/IEC 27034-7:2018

INTERNATIONAL ISO/IEC
STANDARD 27034-7
First edition
2018-05
Information technology — Application
security —
Part 7:
Assurance prediction framework
Technologies de l'information — Sécurité des applications —
Partie 7: Cadre de l'assurance d'une prédiction
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Contents Page
Foreword .v
0 Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Prediction concepts . 3
5.1 Goal of prediction . 3
5.2 Prediction framework . 4
5.3 Expected Level of Trust . 4
5.3.1 Concept . 4
5.3.2 Expected level of trust in the ONF . 5
5.3.3 Expected level of trust in the ANF . 6
5.3.4 ASC data in the ANF . 7
5.3.5 Expected level of trust over sequence of application versions . 8
5.4 Principles .10
5.4.1 ISO/IEC 27034-1 principles .10
5.4.2 Appropriate investment for application security principle .10
5.4.3 Application security should be demonstrated principle .10
5.5 Prediction authorization .10
5.5.1 Prediction accountability .10
5.5.2 Forced authorization .11
5.6 Claims relative to the actual level of trust .11
6 Predictions .11
6.1 Prediction initiator .11
6.2 Prediction circumstances.12
6.2.1 Typical circumstance .12
6.2.2 Relationship to level of trust .12
6.3 Prediction consumer .12
7 Substantial changes .13
7.1 Definition discussion .13
7.2 Guidance for substantial changes risk analysis .13
7.2.1 General.13
7.2.2 Code change and static analysis.13
7.2.3 Architectural review .14
7.2.4 Deprecation of tests over time .14
8 Confidence .14
8.1 Confidence building blocks .14
8.2 Establishing confidence.14
9 Prediction application security rationale .15
9.1 Linkage to ASC .15
9.2 Components .15
9.3 Format .16
9.3.1 Identifiers, actors, ASCs outcomes .16
9.3.2 Rationale .16
9.3.3 Duplication of information .16
9.3.4 Assurance cases .16
9.4 Approval by ONF Committee .16
9.5 Use of RACI charts in description of activities, roles, and responsibilities .17
10 PASR audit.17
© ISO/IEC 2018 – All rights reserved iii

10.1 Auditing linkage .17
10.2 Auditing actual level of trust .17
10.3 Auditing expected level of trust .17
10.4 PASR quality .18
11 PASR Verification .18
11.1 Validation .18
11.2 Verification .18
11.3 Expected results .18
11.4 Missing state .18
11.4.1 Inability to generate verification measurements .18
11.4.2 Example .18
12 PASR implementation .19
12.1 Prediction framework .19
12.2 Steps to implement a PASR .19
12.2.1 General.19
12.2.2 Actor responsibilities .20
12.3 ONF feedback .20
13 Expected level of trust report .20
13.1 Purpose .20
13.2 Components .20
13.3 Format .21
13.4 History, assumptions and social history .21
Annex A (informative) Expected level of trust assurance case .23
Annex B (informative) Comparison of ASC to PASR .25
Bibliography .29
iv © ISO/IEC 2018 – 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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on 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 the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
A list of all parts in the ISO/IEC 27034 series can be found on the ISO website.
© ISO/IEC 2018 – All rights reserved v

0 Introduction
0.1 Basic prediction
The project team declares an application secure when the supporting evidence demonstrates the
attainment of the Targeted Level of Trust (ISO/IEC 27034-1:2011, 0.4.4). A security prediction occurs
when the project team uses the supporting evidence from a previous version of the application and
provides a rationale as to why the supporting evidence is still valid for the subsequent application.
The security prediction framework is the process whereby organizations, who use ISO/IEC 27034 (all
parts), perform risk analysis and document decisions made, relative to Application Security Controls
(ASCs) performed on a previous version of an application but not performed on the current version. All
such predictions are fundamentally subjective, and at best can only express a degree of confidence.
Today, individuals and organizations already transfer their confidence in security claims between
versions of applications without any strong rationale supporting this transfer. Making a security
prediction for a subsequent application, without any rationale or justification, is inherently a bad
practice. To rectify this situation, this document establishes a framework by codifying requirements
for making security predictions between versions of an application.
This document focuses on predictions, or claim transfers, related to subsequent versions of the same
application.
0.2 Purpose
The purpose of this document is to help organizations to develop and use Prediction Application
Security Rationales (PASR) in disseminating information relative to security properties of multiple
versions of the same application by:
a) providing additional guidance to Organization Normative Framework (ONF) Committees so that
they can set up appropriate guidelines for when predictions are and are not appropriate for their
organizations;
b) providing the results of a risk analysis that contains the rationale as to why the changes in the
subsequent application are not substantial;
c) applying to application projects that are using an Application Normative Framework (ANF);
d) indicating the Actual Level of Trust for the original and subsequent applications;
e) indicating the Expected Level of Trust for the original, if used, and subsequent applications;
f) providing the rationale as to why the risk analysis, predictions for individual Application Security
Control (ASC), and the Actual Level of Trust together produce the Expected Level of Trust; and
g) verifying a PASR when the auditor chooses to rerun the corresponding ASC verification activity.
This document does not provide guidelines on:
a) what is and is not an appropriate risk;
b) what is and is not substantial change;
c) when an application owner should or should not accept a specific risk; or
d) when an acquirer should or should not accept an Expected Level of Trust.
vi © ISO/IEC 2018 – All rights reserved

0.3 Targeted audience
0.3.1 General
The following audiences find values and benefits when carrying their designated organizational roles:
a) managers;
b) ONF Committees;
c) project teams;
d) domain experts;
e) auditors;
f) application owners; and
g) acquirers.
0.3.2 Managers
The manager roles are the same as in ISO/IEC 27034-1:2011, 0.3.2.
0.3.3 ONF Committee
As described in ISO/IEC 27034-1:2011, 3.17, the ONF Committee is responsible for managing the
implementation and maintenance of the application-security-related components and processes in the
Organization Normative Framework. The ONF Committee:
a) provides guidelines to project teams as to what is and is not a substantial change;
b) evaluates, and documents, in the ASC, the risk of choosing the PASR over performing the ASC
activity;
c) reviews each ASC and determines if predictions are allowed and, if allowed, under what
circumstances predictions are appropriate;
d) documents the prediction determination in each ASC in the ONF;
e) advises the application owner, when establishing the ANF, the estimated risk of using the PASR; and
f) responds to requests from project teams to modify the prediction guidelines for specific ASC.
0.3.4 Provisioning and operation team
As described in ISO/IEC 27034-1:2011, 0.3.3, members of provisioning and operation teams (known
collectively as the project team) are individuals involved in an application’s design, development and
maintenance throughout its whole life cycle. The project manager is responsible for managing the ANF.
The project team:
a) performs a risk analysis on the proposed changes to the application to determine if the changes are
substantial;
b) creates the PASR (as defined in 3.2) for each ASC for which there is a prediction; and
c) generates the Expected Level of Trust report.
© ISO/IEC 2018 – All rights reserved vii

0.3.5 Domain experts
An individual who is an expert in a particular domain, area, or topic that provides specific knowledge
or expertise to the project team. These experts:
a) assist the project team in making an accurate risk assessment; and
b) assist the project team in making the determination if the changes to the application represent a
substantial change.
0.3.6 Auditors
As described in ISO/IEC 27034-1:2011, 0.3.6, auditors are personnel performing roles in the audit
process who participate in application verification.
0.3.7 Application owners
Based on the definition in ISO/IEC 27034-1:2011, 3.6, the application owner is the organization’s
representative who is responsible and accountable for the security and the protection of an application.
Application owners make the final decisions on:
a) acceptance of the project team risk analysis that the changes to the application are not substantial;
b) approval of a set of ASCs for which the project team generates PASRs; and
c) acceptance of the Expected Level of Trust.
0.3.8 Acquirers
This includes all individuals involved in acquiring a product or service. Acquirers:
a) perform actions as per ISO/IEC 27034-1:2011, 0.3.4;
b) evaluate if the Actual Level of Trust for the original application is appropriate to mitigate the risks
the acquirer anticipates for the expected contexts the acquirer will use the application in;
c) evaluate if the Expected Level of Trust for the subsequent application is appropriate to mitigate the
risks the acquirer anticipates for the expected contexts the acquirer will use the application in; and
d) evaluate if the rationale that changes to the subsequent application are not substantial and, if not in
agreement with the rationale, determine if additional verification is necessary.
viii © ISO/IEC 2018 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 27034-7:2018(E)
Information technology — Application security —
Part 7:
Assurance prediction framework
1 Scope
This document describes the minimum requirements when the required activities specified by an
Application Security Control (ASC) are replaced with a Prediction Application Security Rationale
(PASR). The ASC mapped to a PASR define the Expected Level of Trust for a subsequent application. In
the context of an Expected Level of Trust, there is always an original application where the project team
performed the activities of the indicated ASC to achieve an Actual Level of Trust.
The use of Prediction Application Security Rationales (PASRs), defined by this document, is applicable
to project teams which have a defined Application Normative Framework (ANF) and an original
application with an Actual Level of Trust.
Predictions relative to aggregation of multiple components or the history of the developer in relation to
other applications is outside the scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 27000, Information technology — Security techniques — Information security management
systems — Overview and vocabulary
ISO/IEC 27034-1, Information technology — Security techniques — Application security — Part 1:
Overview and concepts
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 27000, ISO/IEC 27034-1
and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
prediction
statement or estimate that a specific thing will happen in the future or will be a consequence of
something
Note 1 to entry: The origin of the word is early 17th century: from Latin praedict-“made known beforehand,
declared”, from the verb praedicere from prae-“beforehand” + dicere “say”.
Note 2 to entry: The use in this document reflects the expectation that, if the security and verification
measurement activities are executed, they will match the results from the original application.
© ISO/IEC 2018 – All rights reserved 1

3.2
prediction framework
process that performs a risk analysis, establishes an Expected Level of Trust (3.8), assigns Application
Security Control verification to a PASR (3.7), and then creates an Expected Level of Trust Report (3.9)
3.3
original application
application that establishes the baseline Actual Level of Trust
Note 1 to entry: The original application is not necessarily version 1.0 and, hence, can have an associated
Expected Level of Trust.
3.4
subsequent application
application related to the original application (3.3) through versioning
EXAMPLE Version 1 to version 1.1.
3.5
predictive security
transfer of confidence in the security claims (3.6) of the original application (3.3) to the security claims
of the subsequent application (3.4)
3.6
security claim
specific claim that security properties are present in an application
Note 1 to entry: Under the ISO/IEC 27034 frameworks (all parts), it is the claim that the activities specified by an
Application Security Control mitigate specific security risks to an acceptable level.
Note 2 to entry: In the context of a PASR, it is the claim that verification of the Application Security Control
activities, which were predicted by the PASR, would produce the same results as if the Application Security
Control activities were performed.
3.7
Prediction Application Security Rationale
PASR
rationale for a prediction (3.1), supported by risk analysis documents, approved by the application
owner, explaining that performing the verification activities of a specific Application Security Control
is not necessary
Note 1 to entry: Use of PASR requires approval of both application owner and the inclusion of the PASR guidelines
in the Application Security Control by the Organization Normative Framework Committee.
3.8
Expected Level of Trust
level of trust, defined in the Organization Normative Framework, where the activities of some of the
Application Security Controls are satisfied through the creation of a PASR (3.7)
Note 1 to entry: This document describes the minimum requirements applicable to the Application Security
Controls used in an Expected Level of Trust for a subsequent application (3.4). In the context of an Expected
Level of Trust, there is always an original application (3.3) where the project team performed the activities of the
indicated Application Security Controls.
3.9
Expected Level of Trust Report
document presenting and supporting the risk analysis in support of predictions (3.1) made for a
subsequent application
2 © ISO/IEC 2018 – All rights reserved

3.10
predicted Application Security Control
predicted ASC
Application Security Control in which security activities are replaced by a PASR (3.7)
3.11
prediction consumer
anyone that relies on an Expected Level of Trust (3.8)
Note 1 to entry: Mainly application consumers, application acquirers, and application owners.
3.12
prediction initiator
entity that selects an Expected Level of Trust (3.8) for an application
Note 1 to entry: Typically, the project team with approval by the application owner.
3.13
verification measurement
activity provided by an Application Security Control to verify if its security activity was correctly
implemented and works as expected by producing required evidence/outcomes
3.14
substantial change
change that causes sufficient impact to the risk assessment so that the application owner no longer
permits predicted Application Security Controls (3.10), resulting in the project team performing the
necessary Application Security Control activities in the Actual Level of Trust
3.15
regression testing
testing required to determine that a change to a system component has not adversely affected
functionality, reliability or performance and has not introduced additional defects
4 Abbreviated terms
AS Application Security
ASC Application Security Control
ASCs Application Security Controls
ANF Application Normative Framework
ONF Organization Normative Framework
5 Prediction concepts
5.1 Goal of prediction
Predictive security occurs on a daily basis. The goal of this document is to make Application Security
(AS) predictions explicit rather than implicit and to document consistently the prediction. When
predictions are consistent, and correctly documented using the Expected Level of Trust Report,
prediction consumers have a much better basis to make risk decisions based on the Expected Level of
Trust Report. All predictions are inherently subject to uncertainty, and the accuracy of any prediction
is unlikely to be any more accurate than the least accurate source.
AS predictions focus on the AS risks that exist in both original and subsequent application versions.
The AS prediction is as follows: the prediction initiator believes that the subsequent application has an
equivalent Level of Trust to the original application even though some of the ASC activities indicated
© ISO/IEC 2018 – All rights reserved 3

by the Level of Trust are not completed by the project team; rather the ASC activities are replaced by
a PASR. Without predictions, the only way to believe that equivalent Levels of Trust are present in the
two applications is to perform all of the activities for all of the ASCs identified by the Level of Trust.
The prediction framework is one technique for gaining assurance in an application, and needs to be
considered holistically with other approaches to achieving assurance, such as Regression Testing as
[1] [2]
defined in ISO/IEC/IEEE 29119-1 and ISO/IEC 90003 . This document provides assurance efficiency
to the application security confidence. The efficiency comes at a cost, as there is a replacement of the
activities of some of the enumerated ASCs in the Expected Level of Trust with PASRs. The application
owner should be aware of this cost and should make an appropriate risk decision to accept the PASR
using ONF Committee advice.
Under the application security concern perspective, the default without any guidance from the ONF
Committee and approval by the application owner is that predictions are not permissible. Without
predictions, the only way to have equivalent “Levels of Trust” confidence between the original and
subsequent applications is for the Actual Level of Trust to be the same for both applications.
NOTE Annex B provides a comparison between an ASC and a PASR.
5.2 Prediction framework
The definition of a secure application, defined in ISO/IEC 27034-1, is when the Actual Level of Trust is
equal to the Targeted Level of Trust. The prediction framework cannot and should not change the Actual
Level of Trust definition. The prediction framework adds the Expected Level of Trust as a mechanism to
indicate the project teams belief regarding the security properties of the subsequent application.
The prediction framework includes the following concepts:
a) An original application where the Actual Level of Trust was equal to the Targeted Level of Trust
resulting in, per the ISO/IEC 27034-1 definition, a secure application.
b) A subsequent application where the Targeted Level of Trust contains a subset of the original
applications Actual Level of Trust.
c) A risk analysis, documented in the PASR, as to why the subsequent application does not have a
substantial change and performance of an ASC would generate the same result as during execution
of the security and verification measurement activities in the original application.
d) For the subsequent application, a claim that the application has an Actual Level of Trust and a belief
that the subsequent applications Expected Level of Trust is equivalent to the original applications
Actual Level of Trust.
5.3 Expected Level of Trust
5.3.1 Concept
This document adds the definition of the Expected Level of Trust, which indicates that the project team
does not perform the activities of specific ASCs, rather predicts that if the project team performed the
ASC activities the results would match the results from the original application.
Figure 1 illustrates the basics of the Expected Level of Trust.
4 © ISO/IEC 2018 – All rights reserved

Figure 1 — Expected Level of Trust
For version 1.0, the Targeted Level of Trust was Blue and the application successfully implemented the
6 ASCs so the Actual Level of Trust was Blue. As this was the first instantiation of the application, there
were no predictions and no Expected Level of Trust.
For version 1.1, the project team successfully implemented the 3 ASCs so the Actual Level of Trust is Red.
The Expected Level of Trust is Blue as the project team predicts that performing the 3 ASCs activities is
not necessary for version 1.1. The project team can then state that the team knows that the application
is secure at the Red Level of Trust, and believes that the application is secure at the Blue Level of Trust
as the remaining ASCs have an associated PASR.
An Expected Level of Trust contains an Actual Level of Trust, which is a subset of the Expected Level of
Trust, and the remaining ASCs not contained in the Actual Level of Trust have an associated PASR. As a
result, this complements the definition of ‘secure application’.
5.3.2 Expected level of trust in the ONF
The ONF committee establishes the guidelines for when a PASR is appropriate for each ASC in the ASC
library. Figure 2 documents an ONF that contains three levels of trust and is the source of the Levels of
Trust in Figure 1.
© ISO/IEC 2018 – All rights reserved 5

Figure 2 — ONF
The Green and Red Levels of Trust contain separate ASCs, while the Blue Level of Trust is the
combination of Red and Green.
There is no special Expected Level of Trust. As Figure 1 demonstrates, for version 1.0 the Targeted and
Actual Level of Trust were Blue and for version 1.1 the Expected Level of Trust is Blue. This is intentional
as using the same Levels of Trust allow acquirers to compare versions of the same application with the
same Level of Trust. The difference is that if the two versions have the same Actual Level of Trust the
acquirer knows that the versions are equivalent due to both completing the same ASC. If the subsequent
version uses an Expected Level of Trust, the acquirer knows that the prediction initiator believes the
two versions are equivalent, but the evidence of that equivalence is a rationale statement.
5.3.3 Expected level of trust in the ANF
After the AS risk assessment indicates that predictions are appropriate and the application owner
approves the use of predictions, the project team establishes the ANF for the application. Figure 3
shows the ANF for both version 1.0 and 1.1.
6 © ISO/IEC 2018 – All rights reserved

Figure 3 — ANF
For version 1.0, the Targeted and Actual in the ANF are both Blue. For version 1.1, the Targeted Level of
Trust is Red, the Actual is Red, and the Expected is Blue.
All ASCs identified in an Expected Level of Trust, including those with a PASR, may be verified during
an Application Security verification with an Application Security audit.
5.3.4 ASC data in the ANF
The Application Normative Framework is the repository for all data associated with an application
Expected Level of Trust.
The default, without any guidance from the application owner, is that all ASC activities should occur
and predications are not permissible.
For an ASC that the project team performs the activities associated with the ASC, in the ANF there is
data that references the ASC and allows for the verification and auditing of the project team’s execution.
With a prediction, there are no activities but there is still data that references the ASC in the ANF.
Figure 4 illustrates the both types of data.
Figure 4 — ASC data
For version 1.0, each ASC has the activity data associated with the ASC stored in the ANF. For version 1.1,
the project team only performs the activities for ASCs 4, 5, and 6, hence only those ASCs have associated
© ISO/IEC 2018 – All rights reserved 7

results. For ASCs 1, 2, and 3, the project team creates a PASR. Each PASR includes the rationale as to
why the activities of the ASCs are not necessary to maintain the Expected Level of Trust. The PASR also
contains a reference to the Version 1.0 ANF and the results from the project team’s performance of the
ASCs activities.
The reference from the PASR to a prior result is mandatory. If there is no reference, there is no way for
the audit team to verify the expected ASCs results when performing the audits or verifications. This
reference requirement is also the underlying reason why the project team cannot use a prediction on an
ASC that was never instantiated in a prior version.
NOTE Instead of a reference to the original application ANF, the ONF committee can require the project
team to copy into the subsequent application ANF the ASCs result data. In that case, there is no requirement to
reference the original ANF.
5.3.5 Expected level of trust over sequence of application versions
5.3.5.1 Multiple versions
The previous examples only looked at two versions of the application, but most applications have many
more than two versions. The following use case follows the application versions and discusses the
various Levels of Trust that the project team uses.
The project team uses the ONF from Figure 2.
The assumption for this use case is that the project team always successfully completes all activities
assigned for the Target Level of Trust and, therefore, all applications are secure, as Actual equals Target.
To distinguish the various versions of the application, the application requires a unique identifier.
Many schemes are available to identify and disseminate the identity. Software identifiers include ISO/
[3] [4] [5]
IEC 19770-5 and ISO/IEC 19770-2 , while hardware identifiers include ISO/IEC 20009-1 .
5.3.5.2 Version history
Subclause 5.3.5, describes the use case, discusses the choices made by the project team and approval
from the application owner, and uses Table 1 to illustrate all of the application versions.
Table 1 — Version and level history
Levels of Trust
Version
Actual Expected
Version 1.0 Blue NA
Version 1.1 Red Blue
Version 1.2 Green Blue
Version 1.3 Green Blue
Version 2.0 Blue NA
5.3.5.3 Original application – Version 1.0
The original application sets Targeted as Blue, completes the ASCs, and has an Actual of Blue. There is
no Expected Level of Trust.
The ANF contains the results of the ASCs activities for all of the ASCs identified by the Blue Level of Trust.
The project team claims that Version 1.0 is a secure application according to the Blue Level of Trust.
8 © ISO/IEC 2018 – All rights reserved

5.3.5.4 Version 1.1
For version 1.1 the project team, after performing an AS risk analysis, determines that there is a
substantial change in the area covered by the Red Level of Trust ASCs. The project team also determines
that for the other ASCs inside of Blue, there are not substantial changes. The project team wishes to
claim that the Level of Trust of version 1.1 is equivalent to that of version 1.0, so the project team sets
the Expected Level of Trust to Blue.
The ANF contains the results for the Red Level of Trust ASCs and PASRs for the remaining ASCs in Blue.
The PASRs contain references to the version 1.0 ANF so that the results of the predicted ASCs are linked
and available.
The project team claims that version 1.1 is secure according to the Red Level of Trust and they believe it
is equivalent of version 1.0 and the Blue Level of Trust.
5.3.5.5 Version 1.2
Version 1.2 is in response to a bug in version 1.1. The AS risk analysis indicates that the bug fix is only
a substantial change for the ASCs that comprise the Green Level of Trust. The project team wishes to
claim that the Level of Trust for version 1.2 is equivalent to version 1.1 and version 1.0 so the project
team sets the Expected Level of Trust to Blue.
The ANF contains the results for the Green Level of Trust ASCs and the PASRs for the remaining ASCs in
Blue. The PASRs contain references to the version 1.1 ANF, and indirectly to the version 1.0 ANF, so that
the results of the predicted ASCs are linked and available.
The project team claims that version 1.2 is secure according to the Green Level of Trust and they believe
it is equivalent of version 1.0 and the Blue Level of Trust.
5.3.5.6 Version 1.3
Version 1.3 is a quick response to an error in version 1.2. The AS risk analysis indicates that the bug
fix is again only a substantial change for the ASCs that comprise the Green Level of Trust. The project
team wishes to claim that the Level of Trust for version 1.3 is equivalent to the previous versions so the
project team sets the Expected Level of Trust to Blue.
The ANF contains the results for the Green Level of Trust ASCs and the PASRs for the remaining ASCs in
Blue. The PASRs contain references to the version 1.1 ANF so that the results of the predicted ASCs are
linked and available. I
...