Зарубежные нормативные документы и критерии на английском / CCPART2V21

Integrity of exported TSF data

J - Protection of the TSF (FPT)

(FPT_ITI)

1203

The desired strength of modification detection is based upon a specified

modification metric that is a function of the algorithm used, which may range from

a checksum and parity mechanisms that may fail to detect multiple bit changes, to

more complicated cryptographic checksum approaches. The metric that needs to be

defined can either refer to the attacks it will resist (e.g. only 1 in a 1000 random

messages will be accepted), or to mechanisms that are well known in the public

literature (e.g. the strength must be conformant to the strength offered by Secure

Hash Algorithm).

1204

The approach taken to correct modification might be done through some form of

error correcting checksum.

Evaluator notes

1205

Some possible means of satisfying this requirement involves the use of

cryptographic functions or some form of checksum.

Operations

Assignment:

1206

For FPT_ITI.2.1, the PP/ST should specify the modification metric that the

detection mechanism must satisfy. This modification metric shall specify

the desired strength of the modification detection.

1207

For FPT_ITT.2.2, the PP/ST should specify the actions to be taken if a

modification of TSF data has been detected. An example of an action is:

“ignore the TSF data, and request the originating trusted product to send the

TSF data again”.

1208

For FPT_ITI.2.3, the PP/ST author should define the types of

modification from which the TSF should be capable of recovering.

August 1999

Version 2.1

Page 313 of 354

J - Protection of the TSF (FPT)

Internal TOE TSF data transfer (FPT_ITT)

J.6

Internal TOE TSF data transfer (FPT_ITT)

1209

This family provides requirements that address protection of TSF data when it is

transferred between separate parts of a TOE across an internal channel.

User notes

1210

The determination of the degree of separation (i.e., physical or logical) that would

make application of this family useful depends on the intended environment of use.

In a hostile environment, there may be risks arising from transfers between parts of

the TOE separated by only a system bus or an inter-process communications

channel. In more benign environments, the transfers may be across more traditional

network media.

Evaluator notes

1211

One practical mechanism available to a TSF to provide this protection is

cryptographically-based.

FPT_ITT.1 Basic internal TSF data transfer protection

Operations

Selection:

1212

In FPT_ITT.1.1, the PP/ST author should specify the desired type of

protection to be provided from the choices: disclosure, modification.

FPT_ITT.2 TSF data transfer separation

User Application Notes

1213

One of the ways to achieve separation of TSF data based on SFP-relevant attributes

is through the use of separate logical or physical channels.

Operations

Selection:

1214

In FPT_ITT.1.1, the PP/ST author should specify the desired type of

protection to be provided from the choices: disclosure, modification.

FPT_ITT.3 TSF data integrity monitoring

Operations

Selection:

1215

In FPT_ITT.3.1, the PP/ST author should specify the desired type of

modification that the TSF shall be able to detect. The PP/ST author

Page 314 of 354

Version 2.1

August 1999

Internal TOE TSF data transfer

J - Protection of the TSF (FPT)

(FPT_ITT)

should select from: modification of data, substitution of data, re-

ordering of data, deletion of data, or any other integrity errors.

Assignment:

1216

In FPT_ITT.3.1, if the PP/ST author chooses the latter selection noted

in the preceding paragraph, then the author should also specify what

those other integrity errors are that the TSF should be capable of

detecting.

1217

In FPT_ITT.3.2, the PP/ST author should specify the action to be taken

when an integrity error is identified.

August 1999

Version 2.1

Page 315 of 354

J - Protection of the TSF (FPT)

TSF physical protection (FPT_PHP)

J.7

TSF physical protection (FPT_PHP)

1218

TSF physical protection components refer to restrictions on unauthorised physical

access to the TSF, and to the deterrence of, and resistance to, unauthorised physical

modification, or substitution of the TSF.

1219

The requirements in this family ensure that the TSF is protected from physical

tampering and interference. Satisfying the requirements of these components

results in the TSF being packaged and used in such a manner that physical

tampering is detectable, or resistance to physical tampering is measurable based on

defined work factors. Without these components, the protection functions of a TSF

lose their effectiveness in environments where physical damage cannot be

prevented. This component also provides requirements regarding how the TSF must

respond to physical tampering attempts.

1220

Examples of physical tampering scenarios include mechanical attack, radiation,

changing the temperature.

User notes

1221

It is acceptable for the functions that are available to an authorised user for detecting

physical tampering to be available only in an off-line or maintenance mode.

Controls should be in place to limit access during such modes to authorised users.

As the TSF may not be “operational” during those modes, it may not be able to

provide normal enforcement for authorised user access. The physical

implementation of a TOE might consist of several structures: for example an outer

shielding, cards, and chips. This set of “elements” as a whole must protect (protect,

notify and resist) the TSF from physical tampering. This does not mean that all

devices must provide these features, but the complete physical construct as a whole

should.

1222

Although there is only minimal auditing associating with these components, this is

solely because there is the potential that the detection and alarm mechanisms may

be implemented completely in hardware, below the level of interaction with an

audit subsystem (for example, a hardware-based detection system based on

breaking a circuit and lighting a light emitting diode (LED) if the circuit is broken

when a button is pressed by the authorised user). Nevertheless, a PP/ST author may

determine that for a particular anticipated threat environment, there is a need to

audit physical tampering. If this is the case, the PP/ST author should include

appropriate requirements in the list of audit events. Note that inclusion of these

requirements may have implications on the hardware design and its interface to the

software.

FPT_PHP.1 Passive detection of physical attack

User Application Notes

1223

FPT_PHP.1 should be used when threats from unauthorised physical tampering

with parts of the TOE are not countered by procedural methods. It addresses the

threat of undetected physical tampering with the TSF. Typically, an authorised user

Page 316 of 354

Version 2.1

August 1999

TSF physical protection (FPT_PHP)

J - Protection of the TSF (FPT)

would be given the function to verify whether tampering took place. As written, this

component simply provides a TSF capability to detect tampering. The dependency

on FMT_MOF.1 is required to specify who can make use of that capability, and

how they can make use of that capability. If this function is realised by non-IT

mechanisms (e.g. physical inspection) it could be justified that the dependency on

FMT_MOF.1 is not satisfied.

FPT_PHP.2 Notification of physical attack

User Application Notes

1224

FPT_PHP.2 should be used when threats from unauthorised physical tampering

with parts of the TOE are not countered by procedural methods, and it is required

that designated individuals be notified of physical tampering. It addresses the threat

that physical tampering with TSF elements, although detected, may not be noticed.

Operations

Assignment:

1225

For FPT_PHP.2.3, the PP/ST author should provide a list of TSF

devices/elements for which active detection of physical tampering is

required.

1226

For FPT_PHP.2.3, the PP/ST author should designate a user or role

that is to be notified when tampering is detected. The type of user or

role may vary depending on the particular security administration

component (from the FMT_MOF.1 family) included in the PP/ST.

FPT_PHP.3 Resistance to physical attack

1227

For some forms of tampering, it is necessary that the TSF not only detects the

tampering, but actually resists it or delays the attacker.

User Application Notes

1228

This component should be used when TSF devices and TSF elements are expected

to operate in an environment where a physical tampering (e.g. observation, analysis,

or modification) of the internals of a TSF device or TSF element itself is a threat.

Operations

Assignment:

1229

For FPT_PHP.3.1, the PP/ST author should specify tampering

scenarios to a list of TSF devices/elements for which the TSF should

resist physical tampering. This list may be applied to a defined subset

of the TSF physical devices and elements based on considerations such

as technology limitations and relative physical exposure of the device.

Such subsetting should be clearly defined and justified. Furthermore,

August 1999

Version 2.1

Page 317 of 354

J - Protection of the TSF (FPT)

TSF physical protection (FPT_PHP)

the TSF should automatically respond to physical tampering. The

automatic response should be such that the policy of the device is

preserved; for example, with a confidentiality policy, it would be

acceptable to physically disable the device so that the protected

information may not be retrieved.

1230

For FPT_PHP.3.1, the PP/ST author should specify the list of TSF

devices/elements for which the TSF should resist physical tampering in

the scenarios that have been identified.

Page 318 of 354

Version 2.1

August 1999

Trusted recovery (FPT_RCV)

J - Protection of the TSF (FPT)

J.8

Trusted recovery (FPT_RCV)

1231

The requirements of this family ensure that the TSF can determine that the TOE is

started-up without protection compromise and can recover without protection

compromise after discontinuity of operations. This family is important because the

start-up state of the TSF determines the protection of subsequent states.

1232

Recovery components reconstruct the TSF secure states, or prevent transitions to

insecure states, as a direct response to occurrences of expected failures,

1233

Note that recovery may be from either a complete or partial failure scenario.

Although a complete failure might occur in a monolithic operating system, it is less

likely to occur in a distributed environment. In such environments, subsystems may

fail, but other portions remain operational. Further, critical components may be

redundant (disk mirroring, alternative routes), and checkpoints may be available.

Thus, recovery is expressed in terms of recovery to a secure state.

1234

This family identifies a maintenance mode. In this maintenance mode normal

operation might be impossible or severely restricted, as otherwise insecure

situations might occur. Typically, only authorised users should be allowed access

to this mode but the real details of who can access this mode is a function of Class

FMT Security management. If FMT does not put any controls on who can access

this mode, then it may be acceptable to allow any user to restore the system if the

TOE enters such a state. However, in practice, this is probably not desirable as the

user restoring the system has an opportunity to configure the TOE in such a way as

to violate the TSP.

1235

Mechanisms designed to detect exceptional conditions during operation fall under

FPT_TST (TSF self test), FPT_FLS (Fail secure), and other areas that address the

concept of “Software Safety.”

August 1999

Version 2.1

Page 319 of 354

J - Protection of the TSF (FPT)

Trusted recovery (FPT_RCV)

User notes

1236

Throughout this family, the phrase “secure state” is used. This refers to some state

in which the TOE has consistent TSF data and a TSF that can correctly enforce the

policy. This state may be the initial “boot” of a clean system, or it might be some

checkpointed state. The “secure state” is defined in the TSP model. If the developer

provided a clear definition of the secure state and the reason why it should be

considered secure, the dependency from FPT_FLS.1 to ADV_SPM.1 can be argued

away.

FPT_RCV.1

Manual recovery

1237

In the hierarchy of the trusted recovery family, recovery that requires only manual

intervention is the least desirable, for it precludes the use of the system in an

unattended fashion.

User Application Notes

1238

This component is intended for use in TOEs that do not require unattended recovery

to a secure state. The requirements of this component reduce the threat of protection

compromise resulting from an attended TOE returning to an insecure state after

recovery from a failure or other discontinuity.

Evaluator application notes

1239

It is acceptable for the functions that are available to an authorised user for trusted

recovery to be available only in a maintenance mode. Controls should be in place

to limit access during maintenance to authorised users.

FPT_RCV.2

Automated recovery

1240

Automated recovery is considered to be more useful than manual recovery, as it

allows the machine to operate in an unattended fashion.

User Application Notes

1241

The component FPT_RCV.2 extends the feature coverage of FPT_RCV.1 by

requiring that there be at least one automated method of recovery from failure or

service discontinuity. It addresses the threat of protection compromise resulting

from an unattended TOE returning to an insecure state after recovery from a failure

or other discontinuity.

Evaluator application notes

1242

It is acceptable for the functions that are available to an authorised user for trusted

recovery to be available only in a maintenance mode. Controls should be in place

to limit access during maintenance to authorised users.

1243

For FPT_RCV.2.1, it is the responsibility of the developer of the TSF to determine

the set of recoverable failures and service discontinuities.

Page 320 of 354

Version 2.1

August 1999

Trusted recovery (FPT_RCV)

J - Protection of the TSF (FPT)

1244

It is assumed that the robustness of the automated recovery mechanisms will be

verified.

Operations

Assignment:

1245

For FPT_RCV.2.2, the PP/ST author should specify the list of failures

or other discontinuities for which automated recovery must be possible.

FPT_RCV.3 Automated recovery without undue loss

1246

Automated recovery is considered to be more useful than manual recovery, but it

runs the risk of losing a substantial number of objects. Preventing undue loss of

objects provides additional utility to the recovery effort.

User Application Notes

1247

The component FPT_RCV.3 extends the feature coverage of FPT_RCV.2 by

requiring that there not be undue loss of TSF data or objects within the TSC. At

FPT_RCV.2, the automated recovery mechanisms could conceivably recover by

deleting all objects and returning the TSF to a known secure state. This type of

drastic automated recovery is precluded in FPT_RCV.3.

1248

This component addresses the threat of protection compromise resulting from an

unattended TOE returning to an insecure state after recovery from a failure or other

discontinuity with a large loss of TSF data or objects within the TSC.

Evaluator application notes

1249

It is acceptable for the functions that are available to an authorised user for trusted

recovery to be available only in a maintenance mode. Controls should be in place

to limit access during maintenance to authorised users.

1250

It is assumed that the evaluators will verify the robustness of the automated

recovery mechanisms.

Operations

Assignment:

1251

For FPT_RCV.3.2, the PP/ST author should specify the list of failures or

other discontinuities for which automated recovery must be possible.

1252

For FPT_RCV.3.3, the PP/ST author should provide a quantification

for the amount of loss of TSF data or objects that is acceptable.

August 1999

Version 2.1

Page 321 of 354

J - Protection of the TSF (FPT)

Trusted recovery (FPT_RCV)

FPT_RCV.4

Function recovery

1253

Function recovery requires that if there should be some failure in the TSF, that

certain SFs in the TSF should either complete successfully or recover to a secure

state.

Operations

Assignment:

1254

In FPT_RCV.4.1, the PP/ST author should specify a list the SFs and

failure scenarios. In the event that any of the identified failure scenarios

happen, the SFs that have been specified must either complete

successfully or recover to a consistent and secure state.

Page 322 of 354

Version 2.1

August 1999