Version: draft
31st January,2018
Table of Contents
1. Introduction............................................................................................................................ 2
2. Glossary................................................................................................................................. 2
3. Determination of Assurance
Continuity Application............................................................ 2
4. Impact Analysis Report
Preparation..................................................................................... 3
(1) Introduction......................................................................................................................... 4
(2) Description of Changes....................................................................................................... 4
(3) Affected Developer Evidence.............................................................................................. 6
(4) Description of Developer Evidence Modifications................................................................ 7
(5) Conclusion.......................................................................................................................... 8
(6) Appendix........................................................................................................................... 10
5. Examination of the Impact
Analysis Report....................................................................... 11
1.
Introduction
This document
should be used as a reference when considering application for assurance
continuity. It contains viewpoints in determining whether changes to TOE are
within the scope of assurance continuity, and cites examples of the contents of
an “Impact Analysis Report” necessary for assurance continuity application.
2.
Glossary
The meanings of
terms used in this guidance document are equivalent to those used in “Assurance
Continuity Guideline for Information Technology Security Certification.” The
following are the meanings of main terms:
• Certified TOE
The TOE version
which has been evaluated and for which a “certificate” has already been issued.
• Changed TOE
A version of TOE
different from a certified TOE resulting from changes being applied to a certified
TOE.
• Developer Documentation
All necessary
items describing the content of changes of a changed TOE with regard to a
certified TOE. The items must be usable for verification.
3.
Determination of Assurance Continuity Application
“Changes” made to
a certified TOE subject to assurance continuity are not intended to apply to
new products and functions derived from a certified TOE. Within the scope of
security function specifications that had been evaluated for the certified TOE,
only those “changes” for which, without requiring a third-party evaluation, developers
(applicants) on their own responsibility can verify and claim that
assurance will not be adversely affected will be applicable for assurance
continuity. Such changes would include corrections to software and guidance
defects or operational environment additions which do not incur changes to TOE
functions.
There are no
absolute indicators for judging whether “changes” to a certified TOE have a
major effect or minor effect on security, including examples mentioned herein.
Basically, the conditions for assurance continuity are that the developer
him/herself analyses that the assurance of a certified TOE is not changed and
can declare as such along with the results of the analysis, and that the
contents of documentation that had been employed in the evaluation of a
certified TOE have not been changed semantically.
It is surmised
that major impacts will arise from changes to security functions provided by
TOE, security problem definitions and requirements on ST, and evaluated
security procedures. On the other hand, it is thought that corrections of typographical errors in the guidance and
object changes due to comment line additions which are not executed will have a
minor impact. In many cases, however, the question of whether changes to a
certified TOE have a major impact on security or a minor impact on security
will be determined by developer analysis.
The determination
of the impact that changes will have on security will be based on an
understanding of the assurance scope of the certified TOE and claims based on
developer analysis. If changes clearly do not affect the assurance scope of the
certified TOE, the changed TOE will be applicable for assurance continuity. If
changes clearly affect the assurance scope of the certified TOE, re-evaluation
will be necessary if impact is major. If impact is minor, it will be necessary
to make such a claim and compile an Impact Analysis Report. In all other cases
(if impact of changes is not clear), developers should conduct impact analysis
and judge the extent of impacts.
As a reference to
determine whether changes adversely affect the assurance scope of the certified
TOE, a “Checklist for Assurance Continuity Application” is provided as an
addendum to this document. The checklist provides a general summary of the kinds
of items that are evaluated and assured at each assurance level. Confirming the
degree of relevance that changes have to the assurance scope before
implementing a detailed impact analysis for each change will enable one decide
on a re-evaluation without compiling an Impact Analysis Report or to focus on
specific areas for in-depth analysis. Of course, when a re-evaluation is
decided, since an Impact Analysis Report compiled by developers will be useful
for evaluators, one can choose to compile an Impact Analysis Report
irrespective of the scope of impact on security or application for assurance
continuity.
4.
Impact Analysis Report Preparation
If the developer
judges that the changes do not adversely affect the assurance scope of the
certified TOE, the developer will conduct analysis of the content of changes,
and will examine the impact on security. To apply for assurance continuity, the
results of impact analysis must be compiled into a report. The minimum contents
which must be included in the Impact Analysis Report are indicated in chapter 4
of “Assurance Continuity Guideline for Information Technology Security
Certification.”
The Impact
Analysis Report will not be published by the certification body. It is also
possible to include non-public information. The “assurance continuity
maintenance report” which is published information relating to assurance
continuity will be prepared by the certification body based on this Impact
Analysis Report.
Examples and
points to keep in mind when preparing the Impact Analysis Report are shown
below according to the composition of the Impact Analysis Report. Note that
description formats other than the composition of the chapters can be
arbitrary, and do not need to follow the examples.
Figure 1: Composition of Impact Analysis Report
(1) Introduction
The introduction shall
describe identification information
for requisite materials. It may also contain information for which developers
have determined as particularly requiring caution, such as the handling of the
report.
1.1 Impact
Analysis Report Identification
Name of Document: JISEC
Ewallet Type C Impact Analysis Report
Version of Document: 1.0.1
Creation Date: 2007-12-11
Author: JISEC
Co., Ltd. Author Name 1, Author Name 2
1.2 TOE Identification
Name of Product: JIEC Ewallet Type C
Name of
TOE: JISEC Ewallet
SecureTrade
Version of TOE: Rev.
3
Developer: JISEC
Co., Ltd.
1.3 Certified
TOE Identification
Certification No.: C00XX
Name of Product: JISEC
Ewallet Type C/D
Name of TOE: JISEC
Ewallet SecureTrade
Version of TOE: Rev.
2
Evaluation Assurance Level: EAL3
PP Conformance: There
is no PP to be conformed.
|
(2) Description of Changes
The description of
changes shall describe all changes made to the certified TOE. Regarding changes
to the assurance scope of the certified TOE, all changes including those judged
not to affect security shall be described. It is not necessary to include those
items (package design, etc.) which are clearly unrelated to the scope of the
assurance level. However, this does not mean that impact analysis will be
confined to the scope of the assurance level. If necessary, the impact on the
assurance level of the certified TOE shall be examined through analysis which
extends beyond the assurance level.
The reason for changes,
changes to products including TOE, changes to the development environment, and changes
to the IT environment shall be described in the description of changes.
a. Purpose of changes
The description
of changes shall first explain the background for why changes to the TOE became
necessary. This section shall describe an overview of the changes with regard
to the certified TOE. The details of each change will be described in
subsequent sections.
2.1 Purpose of Changes
Additions to the guidance documentation relating to new operating
hardware, functional improvements, and flaw remediation have been performed.
The following is an overview of these changes:
1) Guidance modifications in response to new
Type D additions to JISEC Ewallet on which TOE operates. There are no changes
to the TOE program itself due to these additions.
2) Program modifications to shorten boot time
as automatic reboot was taking too long in the event of authentication
failures.
3) Program modifications in response to an
implementation bug in which log information becomes empty when the audit log
reaches the specified capacity during log information acquisition and file
renaming is conducted.
|
In the event that
there are numerous small bug fixes that do not involve specification changes,
it is acceptable to describe the overall purpose in this section (boundary
value issues in the implementation, performance improvement, etc.) and to
describe the contents of each change in subsequent sections.
b. Changes to products
These
descriptions relate to changes made to certified TOE. Regarding the level of
detail of these descriptions, the information included shall have sufficient
precision for a third party (certification body) to be able to understand the
developer’s impact analysis claims, and in some situations, to call for the
submission of additional documentation that shall be required for the judgement
of applicability of assurance continuity.
Clearly describe
in the descriptions of the assurance scope of the certified TOE, where the
changes were made (whether to the source code or to the procedure manual,
etc.), why these changes were made, and specifically how they were changed. If
the assurance level of the certified TOE was EAL2, it is sufficient to describe
changes at the level of functional specifications; descriptions at the module
or source code level will not be called for.
No.
|
Type of Change
|
Overview
|
Details
|
S2-1
|
Performance
improvement
|
Improving auto reboot time in the event of
authentication failures
|
The boot routine program was changed, and
verification of TSF parameter values, network release and network
restructuring conducted during booting are skipped if authentication failure
flag is set and the system error flag is not set.
|
c.
Changes to the development environment
These
descriptions describe changes made to the development environment. All changes
falling within the scope of assurance requirements for the certified TOE
including those points judged to have a minor impact shall be listed. All changes,
for example, such as changes to versions of TOE configuration items in
configuration management, changes to the method of identifying configuration
items, and changes to configuration management procedures, among others.
D3-1
|
Development security
|
Changes to equipment for controlling entry to the
development environment
|
Employee cards were updated, and the equipment for entry control to
the development room was changed from authentication using old employee cards
(magnetic) to authentication using new employee cards (contactless IC cards). There were no changes to entry procedures, etc.
|
d. Changes
to the IT environment
Describe the
changes to the IT environment for the certified TOE. This environment includes
hardware, firmware, and software requiring security functions which are subject
to evaluation such as external services that the TOE depends on, among others.
It also includes all hardware, firmware, and software constituting the TOE
operational environment.
E2-1
|
Operating hardware
|
Additions
to operating hardware
|
Additional operating assurances for “ISEC SS V.7”, OEM version of the
operating hardware “JISEC SecureSwitch 07”.
|
(3) Affected Developer Evidence
Identify all developer
evidence that were used in evaluating the certified TOE and which will require
changes or additions. Developer evidence refers to all elements used as useful
input in assisting the evaluator in evaluating the certified TOE. Specifically,
it refers to documentation required to be submitted or necessary for the
implementation of “developer action elements” which are identified in each
assurance element of the security assurance components of CC Part 3.
Developers shall
determine which developer evidence to update according to the changes made to
the TOE and environment indicated in the previous description of changes. This
determination shall employ a systematic method which considers the respective
assurance components of certified TOE. This section shall list only the
identification of developer evidences to be updated. The impact on each assurance
component shall be determined with reference to chapter 3 “Performing Impact
Analysis” in the “Assurance Continuity Guideline for Information Technology
Security Certification.” For example, there are methods such as identifying the
details of developer evidence associated with each developer action element as
shown in the table below, and confirming their impact.
Developer
Action Elements
|
Developer Documentation
|
ASE_INT.1
|
JISEC SmartModule Security Target Version3.1
|
ST introduction
|
|
ASE_CCL.1
|
JISEC SmartModule Security Target Version3.1
|
Conformance claims
|
|
…
|
…
|
ATE_FUN.1
|
JISEC SmartModule Functional testing
|
Of the developer evidences identified, this section calls for listing only those which need to be updated as affected developer evidence. How these changes are associated with the assurance scope of the certified TOE and what impacts they have are described in the next section.
(4) Description of Developer Evidence Modifications
Describe an overview of
the changes to all developer evidence identified in “(3) Affected Developer Evidence”.
While it is not necessary to provide a detailed description of changes to
developer evidence, describe clearly and concisely what was changed, why, and
how it was changed.
There are no common
standards for judging how changes to certified TOE affect TOE assurance. A
minor change could affect every aspect of assurance. Conversely, many
modifications to a TOE may have minor impact on the assurance of TOE. In
updating identified developer evidence, developers can judge what kinds of
updates within the assurance scope of certified TOE are necessary by
considering the “content and presentation elements” which correspond to these
developer action elements. For example, AGD_PRE.1.2C states that “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.” In other words, changes to the applicable
descriptions in ST are required to be consistent with TOE acceptance and
installation procedures. Regarding changes to certified TOE, developers can
systematically determine the assurance scope and impact, by considering how to
update developer evidence from the perspective of satisfying the corresponding
“content and presentation elements,” and not by relying on experience or
speculation.
In this section,
describe the content of the changes in appropriate units such as for each
assurance component, each change item, or each updated developer evidence,
along with their references.
JISEC
EasyLAN Functional Specifications
|
|||
Section Number
|
No
|
Content of Changes
|
Location of Change
|
S1-1(F)
|
1
|
In
response to not supporting FDDI:
• removed FDDI from installation
menu
|
2.1.2
|
2
|
• removed FDDI message for error
number [4]
|
2.5
|
|
S2-1(F)
|
1
|
Added verification logic for the code for IPA to the license key CD
verification program.
|
3.1.1
A.3
|
In updating developer evidence, it is necessary to confirm that
functions of the certified TOE other than those changed operate correctly
(regression test). Similarly, if an assurance component from the AVA class is
included in the assurance components, confirm that there were no impacts with
regard to vulnerability. These will be confirmed by re-performing the tests,
etc. that had been conducted when evaluating the certified TOE. Even if there
are no major changes to security functions, there may be cases where new tests
will be required. In such cases, it is necessary the developer include in the
Impact Analysis Report what tests were additionally implemented and for what
purpose. Also, countermeasures to new vulnerabilities after the evaluation of
the certified TOE are not included in the assurance continuity scope. It is
necessary they be “re-evaluated” to be included in the scope of assurance.
(5) Conclusion
Describe the judgements
of whether the changes have a major impact or a minor impact on developer
evidence together with the rationale for these judgements.
a.
Impact of each change
Describe the
impact of each change to developer evidence on the assurance of certified TOE.
Also with regard to the rationales for these claims, outline the developer’s
impact analysis results in relation to “(2) Description of Changes” and “(4)
Description of Developer Evidence Modifications.”
Developers shall
analyse the impacts of these changes across a broad range and at sufficient
depth. To confirm that the certified assurance scope is not affected, analysis
at a deeper level than the assurance level for the certified TOE will be
necessary. In the event that changes to the source code of a given module does
not involve direct changes to the external interface but may affect the error
code of an indirectly called security function, a review of the source code is
more efficient than confirming with a regression test using all error patterns
as parameters. From this perspective, it is desirable that analysis of the
specific impact of changes should be performed by a developer possessing
technical knowledge of the changed TOE, and that analysis of how the results
affect assurance be supported by a developer possessing knowledge of CC. TOE
engineers understand the need to be aware that even small changes to the
start-up script will affect the start-up timing and processing time assumed for
other functions. CC engineers also understand the need to determine not only
whether the message displayed by the script accurately reflects the functional
specifications, but also that they are appropriate representations in the
preparative procedures for conducting a secure installation.
Based on the
results of the analysis of the impact of changes, developers shall determine
whether these changes have a major impact or a minor impact, and shall report
it along with their rationales. There is no general method for identifying
whether impacts are major or minor. Refer to the addendum of the “Assurance
Continuity Guideline for Information Technology Security Certification” for a
general guideline.
This is a program change relating to error processing of a post-processing process for service authentication of a security
function which involves impacts to specifications and administrator guidance.
However, it is judged as follows that there are no direct impacts to the
interface relating to security function behaviour and secure management by
the administrator, and that the impacts of these changes are minor.
|
|||
S3-3(F).1
|
In the
specifications for “service authentication functions” in “Flow Manager
Utility functions specifications,” the affects of post-processing are as follows:
1) There
are no changes to the post-processing call method or to parameters.
2) During post-processing,
• There are no interactions with the users or other modules.
• There are no operations interrupted (including during the shortened 7
seconds)
3) At the completion of post-processing,
• There is no change to the error number returned. In other words, there
is no change in the specification with regard to the error number [7] of
error processing of the service authentication function.
・ There are no other processes which are dependent on post-processing
timing.
・ Although message timing displayed on the administrator interface will
be 7 seconds earlier, the impact is minor as described in S3-2(G).1.
The impact from changes to “Flow Manager Utility functions
specifications” is judged to be minor.
|
ADV_FSP.2
|
|
S3-2(G).1
|
Impacts of the change to the descriptions relating to time until error
message display (“approx.10 seconds later” → “3 seconds later”) in “Service
authentication” of “Flow Manager Utility Guidance” are as follows:
1) There
are no security management items involved during the time from service
authentication start-up until error message display.
2) There
are no changes to the content of the displayed error message, nor any changes
to the actions to be taken by the administrator after message confirmation.
Therefore, impacts from the change to “Flow Manager Utility Guidance”
are judged to be minor.
|
AGD_OPE.1
|
|
Furthermore,
describe the results of confirming (through regression tests) that security
functions operate similarly for the changed TOE as they do for the certified
TOE. It is not necessary to describe test procedures and detailed information
in the Impact Analysis Report. The developer shall describe the perspective
from which the test was implemented to confirm maintenance of assurance.
b.
Overall impact
While changes may
have little impact individually, they may have a major impact on a TOE through
accumulation or interaction. Developers shall analyse each individual change as
well as the overall impact on the TOE as a result of these changes. This section
shall determine significance of the impact from the analysis results, and shall
describe it along with its rationale.
S1-F and S2-F are changes to processing during
installation and during operation respectively. As there is no interaction
between them, TOE operation is not affected due to their combination.
Furthermore, the guidance documents which reflect the respective changes
consist of a procedure manual used at the preparation stage, and a guidance
document used during operation. They are meant to be read by the
administrator at different, independent phases and are contextually
unrelated. Therefore, their combination will have no impact on TOE assurance.
|
(6) Appendix
Describe the
identifications and list of items of the developer evidences updated by the
changes.
a.
List of updated developer evidences
Describe the
information necessary to identify developer evidence for the changed TOE as a
list including developer evidence name, issue date, and version, among others.
b.
List of updated items of developer evidences
Describe the
information necessary to identify changed items; that is, a list of the changed
items and changed areas of each updated developer evidence. It is not necessary
to include minor changes which are not related to the impact analysis (for
example, the approval date for revisions).
5.
Examination of the Impact Analysis Report
The certification
body will determine the impact that each change has on assurance based on the
submitted Impact Analysis Report. The Impact Analysis Report need not describe
the detailed steps of impact analysis or test procedures. However, in the event
the Impact Analysis Report contains non-technical analysis and enumeration of
subjective claims such as “it is thought not to have an impact” or contains
contradictory analysis results, and the certification body judges it necessary
to confirm the content of changes and rationale of the analysis, the developer
may be requested to provide development evidence or a detailed impact analysis
evidence. Impact analysis evidence may be submitted in any format, provided the
analysis process to derive the results of each impact analysis can be
understood.
