collaborative Protection Profile for Database Management ... · collaborative Protection Profile for Database Management Systems v 0.15 DRAFT Page 7 of 48 183 1. Introduction 184

collaborative Protection Profile for Database Management Systems

v 0.15 DRAFT Page 1 of 48

Supporting Document 1

Mandatory Technical Document 2

3

4

5

collaborative Protection Profile for 6

Database Management Systems cPP 7

28 February 2020 8

Version 0.15 9

10

CCDB-2019-<month>-<number> 11

12



Foreword 13

This is a supporting document, intended to complement the Common Criteria version 14 3 and the associated Common Evaluation Methodology for Information Technology 15 Security Evaluation. 16

Supporting documents may be “Guidance Documents”, that highlight specific 17 approaches and application of the standard to areas where no mutual recognition of 18 its application is required, and as such, are not of normative nature, or “Mandatory 19 Technical Documents”, whose application is mandatory for evaluations whose scope 20 is covered by that of the supporting document. The usage of the latter class is not 21 only mandatory, but certificates issued as a result of their application are recognized 22 under the Common Criteria Recognition Arrangement (CCRA). 23

This supporting document has been developed by the Database Management 24 System international Technical Community (DBMS-iTC) and is designed to be used 25 to support the evaluations of products against the cPPs identified in Section 1.1. 26

Technical Editor: Database Management System Technical Community (DBMS-27 iTC) 28

Document history: 29

V0.01, July 16th, 2019 (Initial release for DBMS-iTC use) 30

V0.02, February 20th, 2019 (Updated with some Evaluation Activities) 31

V0.03, March 8th, 2019 (Updated after iTC face to face meeting) 32

V0.04-0.09 Interim updates after iTC meetings 33

General Purpose: See Section 1.1. 34

Field of special use: This Supporting Document applies to the evaluation of TOEs 35 claiming conformance with the collaborative Protection Profile (cPP) for Database 36 Management Systems [DBMScPP]. 37

Acknowledgements: 38

This Supporting Document was developed by the Database Management System 39 international Technical Community (DBMS-iTC) with representatives from industry, 40 Government agencies, Common Criteria Test Laboratories, and members of 41 academia. 42

43



Contents 44

Foreword ................................................................................................................................................. 2 45

1. Introduction ........................................................................................................................................ 7 46 1.1 Technology Area and Scope of Supporting Document ........................................................... 7 47 1.2 Structure of the Document ....................................................................................................... 7 48 1.3 Application of this Supporting Document................................................................................. 8 49

2. Evaluation Activities for SFRs ............................................................................................................ 8 50 2.1 Class: Security Audit (FAU) ..................................................................................................... 8 51

FAU_GEN.1 Audit data generation .......................................................................... 8 52 TSS 8 53 Guidance Documentation ........................................................................................... 8 54 Tests 9 55

FAU_GEN.2 User identity association ..................................................................................... 9 56 TSS 9 57 Guidance Documentation ........................................................................................... 9 58 Tests 9 59

FAU_SEL.1 Selective audit ..................................................................................................... 9 60 TSS 9 61 Guidance Documentation ........................................................................................... 9 62 Tests 9 63

2.2 Class: User Data Protection (FDP) ........................................................................................ 10 64 FDP_ACC.1 Subset access control ....................................................................................... 10 65

TSS 10 66 Guidance Documentation ......................................................................................... 10 67 Tests 10 68

FDP_ACF.1 Security attribute based access control ............................................................ 10 69 TSS 10 70 Guidance Documentation ......................................................................................... 10 71 Tests 11 72

FDP_RIP.1 Subset residual information protection ............................................................... 11 73 TSS 11 74 Guidance Documentation ......................................................................................... 11 75 Tests 11 76

2.3 Class: Identification and authentication (FIA) ........................................................................ 11 77 FIA_ATD.1 User attribute definition ....................................................................................... 11 78


FIA_UAU.2 User authentication before any action ................................................................ 11 82 TSS 11 83 Guidance Documentation ......................................................................................... 12 84 Tests 12 85

FIA_UID.2 User identification before any action ................................................................... 12 86 TSS 12 87 Guidance Documentation ......................................................................................... 12 88 Tests 12 89

2.4 Class: Security Management (FMT) ...................................................................................... 12 90 FMT_MSA.1 Management of security attributes ................................................................... 12 91


FMT_MSA.3 Static attribute initialization ............................................................................... 13 95 TSS 13 96 Guidance Documentation ......................................................................................... 13 97 Tests 13 98

FMT_MTD.1 Management of TSF data ................................................................................. 13 99 TSS 13 100



Guidance Documentation ......................................................................................... 13 101 Tests 13 102

FMT_REV.1(1) Revocation.................................................................................................... 14 103 TSS 14 104 Guidance Documentation ......................................................................................... 14 105 Tests 14 106

FMT_REV.1(2) Revocation (DAC) ........................................................................................ 14 107 TSS 14 108 Guidance Documentation ......................................................................................... 15 109 Tests 15 110

FMT_SMF.1 Specification of Management Functions .......................................................... 15 111 TSS 15 112 Guidance Documentation ......................................................................................... 15 113 Tests 15 114

FMT_SMR.1 Security roles.................................................................................................... 15 115 TSS 15 116 Guidance Documentation ......................................................................................... 16 117 Tests 16 118

FTA_MCS.1 Basic limitation on multiple concurrent sessions .............................................. 16 119 TSS 16 120 Guidance Documentation ......................................................................................... 16 121 Tests 16 122

FTA_TSE.1 TOE session establishment ............................................................................... 16 123 TSS 16 124 Guidance Documentation ......................................................................................... 17 125 Tests 17 126

3. Evaluation Activities for Optional SFRs ........................................................................................... 17 127 3.1 Class: Identification and Authentication (FIA) ....................................................................... 17 128

FIA_USB_EXT.2 Enhanced user-subject binding ................................................................. 17 129 TSS 17 130 Guidance Documentation ......................................................................................... 17 131 Tests 17 132

3.2 Class: Protection of the TSF (FPT) ....................................................................................... 17 133 FPT_TRC.1 Internal TSF consistency ................................................................................... 17 134

TSS 17 135 Guidance Documentation. ........................................................................................ 18 136 Tests 18 137

3.3 Class: TOE access (FTA) ...................................................................................................... 18 138 FTA_TAH_EXT.1 TOE access information ........................................................................... 18 139


4. Evaluation Activities for SARs .......................................................................................................... 19 143 4.1 ADV: Development ................................................................................................................ 19 144

Security architecture description (ADV_ARC.1) .................................................................... 19 145 Security-enforcing functional specification (ADV_FSP.2) ..................................................... 20 146 Basic Design (ADV_TDS.1) ................................................................................................... 22 147

4.2 AGD: Guidance Documentation ............................................................................................ 23 148 Operational User Guidance (AGD_OPE.1) ........................................................................... 23 149 Preparative Procedures (AGD_PRE.1) ................................................................................. 25 150

4.3 Class ALC: Life-cycle Support ............................................................................................... 26 151 Use of a CM System (ALC_CMC.2) ...................................................................................... 26 152 Parts of the TOE CM Coverage (ALC_CMS.2) ..................................................................... 27 153 Delivery Procedures (ALC_DEL.1) ........................................................................................ 28 154



Systematic Flaw Remediation (ALC_FLR.3) ......................................................................... 28 155 4.4 Class ASE: Security Target Evaluation ................................................................................. 31 156 4.5 Class ATE: Tests ................................................................................................................... 32 157

Evidence of Coverage (ATE_COV.1) .................................................................................... 32 158 Functional Testing (ATE_FUN.1) .......................................................................................... 32 159 Independent Testing (ATE_IND.2) ........................................................................................ 33 160

4.6 Class AVA: Vulnerability Assessment ................................................................................... 36 161 Vulnerability Analysis (AVA_VAN.2) ...................................................................................... 36 162

4.7 Evaluation Activity .................................................................................................................. 39 163

5. References ....................................................................................................................................... 41 164

Appendix A. Vulnerability Analysis ................................................................................................ 42 165 A.1 Sources of vulnerability information ....................................................................................... 42 166 A.2 Type 1 Hypotheses—Public-Vulnerability-based .................................................................. 42 167 A.3 Type 2 Hypotheses—iTC-Sourced ........................................................................................ 43 168 A.4 Type 3 Hypotheses—Evaluation-Team-Generated .............................................................. 43 169 A.5 Type 4 Hypotheses—Tool-Generated ................................................................................... 44 170 A.6 Process for Evaluator Vulnerability Analysis ......................................................................... 44 171

A.6.1 Unavailable evidence ............................................................................................... 44 172 A.6.2 Dealing with flaws ..................................................................................................... 45 173

A.7 Reporting ............................................................................................................................... 45 174

Appendix B. Glossary .................................................................................................................... 48 175 B.1 Terms and Definitions ............................................................................................................ 48 176 B.2 Acronyms used in this SD...................................................................................................... 48 177

178



Figures / Tables 179

Table 1: Mapping of AVA_VAN.2 [CEM] Work Units to Evaluation Activities ....................................... 39 180

181

182



1. Introduction 183

1.1 Technology Area and Scope of Supporting Document 184 This Supporting Document defines the Evaluation Activities associated with the 185 collaborative Protection Profile for Database Management Systems [DBMScPP]. 186

This Supporting Document is mandatory for evaluations of products that claim 187 conformance to the following cPP: 188

a) collaborative Protection Profile for Database Management Systems 189 [DBMScPP] 190

Although Evaluation Activities (EA) are defined for the evaluators to follow, the 191 definitions in this Supporting Document aim to provide a common understanding for 192 developers, evaluators and users as to what aspects of the Target of Evaluation 193 (TOE) are tested in an evaluation against the associated cPP, and to what depth the 194 testing is carried out. 195

This common understanding contributes to the goal of ensuring that evaluations 196 against the cPP achieve comparable, transparent and repeatable results. In general, 197 the definition of Evaluation Activities will also help Developers to prepare for 198 evaluation by identifying specific requirements for their TOE. The specific 199 requirements in Evaluation Activities may in some cases clarify the meaning of 200 Security Functional Requirements (SFRs), and may identify particular requirements 201 for the content of Security Targets (ST), especially the TOE Summary Specification 202 (TSS), user guidance documentation and testing activities. 203

1.2 Structure of the Document 204 EAs can be defined for both SFRs and Security Assurance Requirements (SAR). 205 These are defined in separate sections of this Supporting Document. 206

If any EA cannot be successfully completed in an evaluation, then the overall verdict 207 for the evaluation is a ‘fail’. In rare cases there may be acceptable reasons why an 208 EA may be modified or deemed not applicable for a particular TOE, but this must be 209 agreed with the Certification Body (CB) for the evaluation. 210

In general, if all EAs (for both SFRs and Security Assurance Requirements (SARs)) 211 are successfully completed in an evaluation then it would be expected that the 212 overall verdict for the evaluation is a ‘pass’. To reach a ‘fail’ verdict when the EAs 213 have been successfully completed would require a specific justification from the 214 evaluator as to why the Evaluation Activities were not sufficient for that TOE. 215

Similarly, at the more granular level of Assurance Components, if the EAs for an 216 Assurance Component and all of its related SFR EAs are successfully completed in 217 an evaluation then it would be expected that the verdict for the Assurance 218 Component is a ‘pass’. To reach a ‘fail’ verdict for the Assurance Component when 219 these EAs have been successfully completed would require a specific justification 220 from the evaluator as to why the EAs were not sufficient for that TOE. 221



1.3 Application of this Supporting Document 222 This Supporting Document (SD) defines three types of EAs; TSS, Guidance 223 Documentation, and Tests and is designed to be used in conjunction with cPPs. 224 cPPs that rely on this Supporting Document (SD) will explicitly identify it as a source 225 for their EAs. Each security requirement (SFR or SAR) specified in the cPP could 226 have multiple EAs associated with it. The security requirement naming convention is 227 consistent between cPP and SD ensuring a clear one to one correspondence 228 between security requirements and EAs. 229

The cPP and SD are designed to be used in conjunction with each other, where the 230 cPP lists SFRs and SARs and the SD catalogues EAs associated with each SFR 231 and SAR. Some of the SFRs included in the cPP are optional. Therefore, an ST 232 claiming conformance to the cPP does not necessarily have to include all possible 233 SFRs defined in the cPP. 234

In an ST conformant to the cPP, several operations need to be performed (mainly 235 selections and assignments). Some EAs define separate actions for different 236 selected or assigned values in SFRs. The evaluator shall neither carry out EAs 237 related to SFRs that are not claimed in the ST nor EAs related to specific selected or 238 assigned values that are not claimed in the ST. 239

EAs do not necessarily have to be executed independently from each other. A 240 description in a guidance documentation or one test case, for example, can cover 241 multiple EAs at a time, no matter whether the EAs are related to the same or 242 different SFRs. 243

2. Evaluation Activities for SFRs 244

2.1 Class: Security Audit (FAU) 245

FAU_GEN.1 Audit data generation 246

TSS 247

The list of auditable events is included in FAU_GEN.1. No further TSS activities are 248 defined. 249

Guidance Documentation 250

The evaluator shall check the guidance documentation to ensure that as a minimum 251 the auditable events specified in FAU_GEN.1 are listed and the associated 252 information recorded is consistent with the definition of the SFRs. 253



Tests 254

For the events listed in the table of audit events in the ST, the evaluator shall verify 255 the TOE’s ability to correctly generate audit records and that the associated 256 information required by the ST is included in the audit record. 257

Note that the testing here may be accomplished in conjunction with the testing of the 258 security mechanisms. 259

FAU_GEN.2 User identity association 260

TSS 261

See FAU_GEN.1 262


See FAU_GEN.1 264

Tests 265

This activity is accomplished in conjunction with the testing of FAU_GEN.1.1. 266

FAU_SEL.1 Selective audit 267

TSS 268

The evaluator shall examine the TSS to verify that it identifies the attributes by which 269 the TOE can be configured to selectively enable or disable the generation of 270 auditable events. 271


The evaluator shall examine the operational guidance to verify that it provides a list 273 of the attributes that can be used to selectively enable or disable the generation of 274 auditable events as well as instructions for performing this operation. 275

Tests 276

i. The evaluator shall generate audit records for each attribute specified in 277 FAU_SEL.1. 278

ii. The evaluator shall log on to the TOE using a role that is sufficiently privileged 279 to modify the set of events that the TOE audits, and select auditable events 280 for each attribute specified by FAU_SEL.1 in the ST, including any attribute 281 included in the assignment. This shall be done for each attribute separately 282 and a combination of two or more of the attributes. 283

iii. The evaluator shall then: 284



a. Verify that audit logs are generated for the auditable events that have 285 been selected; 286

b. Verify that audit logs are not generated for the auditable events that are 287 not selected. 288

NOTE: The following testing may be done in conjunction with other assurance 289 activities since auditable events occur as a by-product of the TOE being used to 290 perform other security functions. 291

2.2 Class: User Data Protection (FDP) 292

FDP_ACC.1 Subset access control 293

TSS 294

The TSS evaluation activities are included in the FDP_ACF.1. 295


The Guidance evaluation activities are included in the FDP_ACF.1. 297

Tests 298

The test evaluation activities are included in the FDP_ACF.1. 299

FDP_ACF.1 Security attribute based access control 300

TSS 301

The evaluator shall examine the TSS and verify that an explanation of the 302 discretionary access control policy is given, and that the explanation is both clear 303 and understandable. 304


The evaluator shall examine the guidance to verify that it: 306

• Clearly states the access control rules of the TOE; 307

• Explains how the security and object attributes are used by the TOE in order 308 to achieve the desired access control; 309

• Instructs administrators on how to allow users access to objects using any 310 additional rules defined in FDP_ACF.1.3; and 311

• Instructs administrators on how to deny users access to objects using any 312 additional rules defined in FDP_ACF.1.4. 313



Tests 314

The evaluator shall devise tests that exercise each of the access control rules. 315

NOTE: It is not necessary to test every combination of the rules, but each rule must 316 be included at least once in the test cases. 317

FDP_RIP.1 Subset residual information protection 318

TSS 319

The evaluator shall examine the TSS to ensure that, at a minimum, it describes how 320 the previous information content is made unavailable. 321


There are no AGD assurance activities for this requirement beyond what is 323 necessary to satisfy the requirements in [CEM]. 324

Tests 325

There are no ATE assurance activities for this requirement beyond what is 326 necessary to satisfy the requirements in [CEM]. 327

2.3 Class: Identification and authentication (FIA) 328

FIA_ATD.1 User attribute definition 329

TSS 330

The evaluator shall check to ensure that the TSS contains a description of the user 331 security attributes that the TOE uses to implement the SFR, which is consistent with 332 the definition of the SFR. 333



Tests 337

There are no ATE assurance activities for this requirement beyond what is 338 necessary to satisfy the requirements in [CEM]. 339

FIA_UAU.2 User authentication before any action 340

TSS 341

There are no ASE assurance activities for this requirement beyond what is 342 necessary to satisfy the requirements in [CEM]. 343





Tests 347

The evaluator shall examine the guidance documentation to ensure that no TOE 348 Security Functionality (TSF) mediated actions are available before user identification 349 and authentication is completed. 350

FIA_UID.2 User identification before any action 351

TSS 352

There are no ASE assurance activities for this requirement beyond what is 353 necessary to satisfy the requirements in [CEM]. 354



Tests 358

Testing is performed in conjunction with FIA_UAU.2. 359

2.4 Class: Security Management (FMT) 360

FMT_MSA.1 Management of security attributes 361

TSS 362

The evaluator shall verify that the TSS contains a description of all of the security 363 attributes in the discretionary access control policy that can be managed by 364 authorized administrators. The evaluator shall also verify that the TSS describes how 365 these security attributes are protected from unauthorised access. 366

The evaluator shall verify that the description of security attributes includes all of 367 those given in FIA_ATD.1. 368


The evaluator shall verify that the guidance contains a description of the 370 management functionality associated with security attributes. 371



Tests 372

The evaluator shall log on as an authorized administrator and perform allowed 373 operations on the security attributes. The evaluator shall verify that the operations 374 are performed as expected. 375

The evaluator shall log on as user without the appropriate privileges and attempt to 376 perform administrator-allowed operations on the security attributes. The evaluator 377 shall verify that the operations are not permitted. 378

FMT_MSA.3 Static attribute initialization 379

TSS 380

The evaluator shall verify that the TSS describes the mechanisms to generate top 381 level security attributes and their default values. 382


The evaluator shall examine the guidance and verify that no ability to specify 384 alternative initial values as an override to the default values is found. 385

Tests 386

The evaluator shall create at least one new container object (e.g. a table) at the top-387 level. The evaluator shall check that the attributes of the container object has the 388 default value(s) described in the TSS values. 389

The evaluator shall create new lower-level objects (e.g. rows, cells). The evaluator 390 shall check that the attributes of the lower-level object(s) have the same default 391 permissions as the higher-level object. 392

FMT_MTD.1 Management of TSF data 393

TSS 394

This was performed in conjunction with FAU_SEL.1. 395


This was performed in conjunction with FAU_SEL.1. 397

Tests 398

Testing is performed in conjunction with FAU_SEL.1. 399



FMT_REV.1(1) Revocation 400

TSS 401

The evaluator shall examine the TSS to verify that it defines the revocation rules 402 associated with user security attributes and that the revocation rules are sufficiently 403 described in informal language. 404

The evaluator shall examine the TSS to verify that the timing and/or conditions of 405 revocation is specified. 406


The evaluator shall examine the guidance documentation to verify that the user 408 security attribute revocation rules are adequately described to the authorized 409 administrator. 410

Tests 411

iv. The evaluator shall log on as a user and verify that the user is able to perform 412 actions in accordance with the user security attributes, specified in 413 FMT_REV.1.1(1). If revocation is effective at the next log on then the user 414 shall log off. 415

v. The evaluator shall log on as an authorized administrator and revoke user 416 security attribute(s) in accordance with the guidance. 417

vi. The evaluator shall verify that the user is no longer able to perform actions in 418 accordance with the revoked user security attributes. 419 NOTE: any consideration of the time for the revocation to be effective shall be 420 considered appropriately by the evaluator before completing (iii). 421

NOTE: In the steps above the term “user” implies the same user throughout the test. 422

FMT_REV.1(2) Revocation (DAC) 423

TSS 424

The evaluator shall examine the TSS to verify that it defines the revocation rules 425 associated with object security attributes and that the revocation rules are sufficiently 426 described in informal language. 427

The evaluator shall examine the TSS to verify that the timing and/or conditions of 428 revocation is specified. 429




The evaluator shall examine the guidance documentation to verify that the object 431 security attribute revocation rules are adequately described. 432

Tests 433

i. The evaluator shall log on as a user with sufficient privileges to objects and 434 verify that the user is able to perform actions on objects in accordance with 435 the object security attributes, specified in FMT_REV.1.1(2). 436

ii. The evaluator shall log on as a database user with sufficient privileges as 437 allowed by the DAC policy and revoke object security attribute(s) in 438 accordance with the guidance. 439

iii. The evaluator shall verify that the user is no longer able to perform actions in 440 accordance with the revoked object security attributes. 441

NOTE: Any consideration of the time for the revocation to be effective shall be 442 considered appropriately by the evaluator before completing (iii). 443

NOTE: In the steps above the term “user” implies the same user throughout the test. 444

FMT_SMF.1 Specification of Management Functions 445

TSS 446

The evaluator shall examine the TSS and verify that the management functions 447 listed in FMT_SMF.1 are described in informal language. 448


The evaluator shall examine the guidance documentation to ensure that there is 450 appropriate guidance for configuring and using all of the management functions 451 listed in FMT_SMF.1. 452

Tests 453

The evaluator shall devise and execute tests for each of the management functions 454 listed in FMT_SMF.1. 455

NOTE: If management functions have already been tested in conjunction with other 456 SFRs in the ST then it is not necessary to repeat the testing for this evaluation 457 activity. 458

FMT_SMR.1 Security roles 459

TSS 460

The evaluator shall examine the TSS to verify that it provides a description of all of 461 the roles listed in FMT_SMR.1.1 462




The evaluator shall review the operational guidance in order to verify that it 464 discusses the listed administrative role(s), the privileges associated with each role, 465 and how users are associated with each role. 466

Tests 467

The evaluator shall associate a user with each of the listed roles and verify that the 468 user privileges are consistent with the descriptions in the TSS. 469

TOE Access (FTA) 470

FTA_MCS.1 Basic limitation on multiple concurrent sessions 471

TSS 472

The evaluator shall examine the TSS and verify that it states the default number of 473 concurrent sessions per user for the evaluated configuration. If the default number of 474 concurrent sessions can be changed then the evaluator should verify that the TSS 475 states that the default can be changed. 476


The evaluator shall examine the guidance documentation and verify that it states 478 how the default number of sessions per user is set and, if applicable, how the default 479 can be changed. 480

Tests 481

The evaluator shall establish the maximum number of concurrent sessions and verify 482 that this number of concurrent sessions is allowed. The evaluator shall attempt to 483 establish a number of sessions greater than the maximum specified and verify that 484 additional concurrent sessions cannot be established. 485

If the default number of concurrent sessions can be changed then the evaluator shall 486 change the default value and repeat the test. 487

FTA_TSE.1 TOE session establishment 488

TSS 489

The evaluator shall examine the TSS and verify that the attributes that can be used 490 to deny session establishment are listed and described. 491




The evaluator shall examine the guidance documentation and verify that a 493 description of how denial of session establishment is configured is included. 494

Tests 495

For each of the listed attributes used for denial of session establishment, the 496 evaluator shall use the guidance documentation to configure the TSF to deny 497 session establishment using that attribute. The evaluator shall verify that session 498 establishment is denied appropriately in each case. 499

3. Evaluation Activities for Optional SFRs 500

These activities are only required when the optional SFRs are claimed. 501

3.1 Class: Identification and Authentication (FIA) 502

FIA_USB_EXT.2 Enhanced user-subject binding 503

TSS 504

The evaluator shall check to ensure that the TSS contains a description of rules for 505 the assignment of security attributes associated with the users to the subjects, the 506 rules for the initial association of attributes, and how the rules are enforced. 507



Tests 511

The evaluator shall verify the association of security attributes to subjects by 512 establishing a user with a set of security attributes, changing the attributes and 513 verifying that the new attributes result in the expected change. If there are any 514 additional rules in FIA_USB_EXT.2.2, FIA_USB_EXT.2.3 or FIA_USB_EXT.2.4, the 515 evaluator must perform a test to demonstrate that each rule holds true. Where 516 practical and appropriate for the rule, the evaluator must also perform a negative test 517 that demonstrates the rule being enforced. 518

519

3.2 Class: Protection of the TSF (FPT) 520

FPT_TRC.1 Internal TSF consistency 521

TSS 522

The evaluator shall examine the TSS and verify that it includes a description of how 523 data is replicated between physically separated parts of the TOE and how 524 consistency between the TOE Security Functionality (TSF) data in the parts is 525



achieved. The description shall include how any TSF data inconsistencies are 526 corrected without undue delay. 527

Guidance Documentation. 528

The evaluator shall examine the guidance documentation and verify that necessary 529 instructions on how to properly configure the TOE for replication are included. 530

Tests 531

The evaluator shall configure the replication of a TOE with physically separated 532 parts. The evaluator shall compare the TSF data in each part of the TOE and verify 533 that they are consistent. The evaluator shall take into consideration any expected 534 differences that are described in the TSS. 535

NOTE: This could be achieved through appropriate sampling of the TSF data on 536 each part of the TOE. 537

3.3 Class: TOE access (FTA) 538

FTA_TAH_EXT.1 TOE access information 539

TSS 540

The evaluator shall examine the guidance documentation to verify that a statement is 541 included in regard to whether configuration of this function is needed. 542


The evaluator shall examine the guidance documentation to verify that if 544 configuration information is included if indicated in the TSS. 545

The evaluator shall verify that the guidance documentation includes information in 546 regard to how a user retrieves the information required in the FTA_TAH_EXT.1. 547

Tests 548

Test 1: The evaluator shall follow the guidance documentation instructions for 549 retrieving 550

a) The [date and time] of the session establishment attempt of the user. 551 b) The incremental count of successive unsuccessful session establishment 552

and verify that it can be retrieved and that the information is correct. 553

Test 2: The evaluator shall assume a user role and verify that the following 554 information can be retrieved by following the instructions given in the guidance 555 documentation. 556



a) The previous last successful session establishment, and 557 b) The last unsuccessful attempt to session establishment and the number of 558

unsuccessful attempts since the previous last successful session 559 establishment. 560

The evaluator shall verify that users can only access their own information. 561

4. Evaluation Activities for SARs 562

4.1 ADV: Development 563

Security architecture description (ADV_ARC.1) 564

In order to meet these goals some refinement of the ADV_ARC.1 [CEM] work units 565 is needed. The following table indicates, for each work unit in ADV_ARC.1, whether 566 the [CEM] work unit is to be performed as written, or if it has been clarified by an 567 Evaluation Activity. If clarification has been provided, a reference to this clarification 568 is provided in the table. 569

[CEM] ADV_ARC.1 Work Units Evaluation Activities

ADV_ARC.1-1 The evaluator shall examine the security architecture description to determine that the information provided in the evidence is presented at a level of detail commensurate with the descriptions of the SFR-enforcing abstractions contained in the functional specification and TOE design document.

The evaluator shall perform the [CEM] activity as specified.

ADV_ARC.1-2 The evaluator shall examine the security architecture description to determine that it describes the security domains maintained by the TSF.


ADV_ARC.1-3 The evaluator shall examine the security architecture description to determine that the initialisation process preserves security.


ADV_ARC.1-4 The evaluator shall examine the security architecture description to determine that it contains





information sufficient to support a determination that the TSF is able to protect itself from tampering by untrusted active entities.

ADV_ARC.1-5 The evaluator shall examine the security architecture description to determine that it presents an analysis that adequately describes how the SFR-enforcing mechanisms cannot be bypassed.


Table 1: Mapping of ADV_ARC.1 [CEM] Work Units to Evaluation Activities 570

Security-enforcing functional specification (ADV_FSP.2) 571

In order to meet these goals some refinement of the ADV_FSP.2 [CEM] work units is 572 needed. The following table indicates, for each work unit in ADV_FSP.2, whether the 573 [CEM] work unit is to be performed as written, or if it has been clarified by an 574 Evaluation Activity. If clarification has been provided, a reference to this clarification 575 is provided in the table. 576

[CEM] ADV_FSP.2 Work Units Evaluation Activities

ADV_FSP.2-1 The evaluator shall examine the functional specification to determine that the TSF is fully represented.


ADV_FSP.2-2 The evaluator shall examine the functional specification to determine that it states the purpose of each TSFI.


ADV_FSP.2-3 The evaluator shall examine the functional specification to determine that the method of use for each TSFI is given.





ADV_FSP.2-4 The evaluator shall examine the presentation of the TSFI to determine that it completely identifies all parameters associated with every TSFI.



ADV_FSP.2-5 The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all parameters associated with every TSFI.


ADV_FSP.2-6 The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes the SFR-enforcing actions associated with the SFR-enforcing TSFIs.


ADV_FSP.2-7 The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes error messages that may result from SFR-enforcing actions associated with each SFR-enforcing TSFI.


ADV_FSP.2-8 The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs.


ADV_FSP.2-9 The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs.


ADV_FSP.2-10 The evaluator shall examine the functional specification to determine that it





is an accurate instantiation of the SFRs.

Table 2: Mapping of ADV_FSP.2 [CEM] Work Units to Evaluation Activities 577

Basic Design (ADV_TDS.1) 578

In order to meet these goals some refinement of the ADV_TDS.1 [CEM] work units is 579 needed. The following table indicates, for each work unit in ADV_TDS.1, whether the 580 [CEM] work unit is to be performed as written, or if it has been clarified by an 581 Evaluation Activity. If clarification has been provided, a reference to this clarification 582 is provided in the table. 583


ADV_TDS.1-1 The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems.


ADV_TDS.1-2 The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified.


ADV_TDS.1-3 The evaluator shall examine the TOE design to determine that each SFR-supporting or SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-supporting or SFR-non-interfering.


ADV_TDS.1-4 The evaluator shall examine the TOE design to determine that it provides a complete, accurate, and high-level summary of the SFR-enforcing behaviour of the SFR-enforcing subsystems.





ADV_TDS.1-5 The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described.


ADV_TDS.1-6 The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the subsystems of the TSF described in the TOE design.


ADV_TDS.1-7 The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design.


ADV_TDS.1-8 The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements.


Table 3: Mapping of ADV_TDS.1 [CEM] Work Units to Evaluation Activities 584

4.2 AGD: Guidance Documentation 585

Operational User Guidance (AGD_OPE.1) 586

Specific requirements and checks on the user guidance documentation are identified 587 (where relevant) in the individual Evaluation Activities for each SFR. Additionally, the 588 evaluator is expected to ensure that the [CEM] requirements of AGD_OPE.1 [CEM] 589 are met, with any refinements noted in the table below. The following table indicates, 590 for each work unit in AGD_OPE.1, whether the [CEM] work unit is to be performed 591 as written, or if it has been clarified by an Evaluation Activity. If clarification has been 592 provided, a reference to this clarification is provided in the table. 593


AGD_OPE.1-1 The evaluator shall examine the operational user guidance to determine that





it describes, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.

AGD_OPE.1-2 The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the secure use of the available interfaces provided by the TOE.


AGD_OPE.1-3 The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the available security functionality and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.


AGD_OPE.1-4 The evaluator shall examine the operational user guidance to determine that it describes, for each user role, each type of security-relevant event relative to the user functions that need to be performed, including changing the security characteristics of entities under the control of the TSF and operation following failure or operational error.


AGD_OPE.1-5 The evaluator shall examine the operational user guidance and other evaluation evidence to determine that the guidance identifies all possible modes of





operation of the TOE (including, if applicable, operation following failure or operational error), their consequences and implications for maintaining secure operation.

AGD_OPE.1-6 The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST.


AGD_OPE.1-7 The evaluator shall examine the operational user guidance to determine that it is clear.


AGD_OPE.1-8 The evaluator shall examine the operational user guidance to determine that it is reasonable.


Table 4: Mapping of AGD_OPE.1 [CEM] Work Units to Evaluation Activities 594

Preparative Procedures (AGD_PRE.1) 595

Specific requirements and checks on the user guidance documentation are identified 596 (where relevant) in the individual Evaluation Activities for each SFR. Additionally, the 597 evaluator is expected to ensure that the [CEM] requirements of AGD_OPE.1 [CEM] 598 are met, with any refinements noted in the table below. The following table indicates, 599 for each work unit in AGD_OPE.1, whether the [CEM] work unit is to be performed 600 as written, or if it has been clarified by an Evaluation Activity. If clarification has been 601 provided, a reference to this clarification is provided in the table. 602

[CEM] AGD_PRE.1 Work Units Evaluation Activities

AGD_PRE.1-1 The evaluator shall examine the provided acceptance procedures to determine that they describe the steps necessary for secure acceptance of the TOE in




[CEM] AGD_PRE.1 Work Units Evaluation Activities

accordance with the developer's delivery procedures.

AGD_PRE.1-2 The evaluator shall examine the provided installation procedures to determine that they describe the steps necessary for secure installation of the TOE and the secure preparation of the operational environment in accordance with the security objectives in the ST.


AGD_PRE.1-3 The evaluator shall perform all user procedures necessary to prepare the TOE to determine that the TOE and its operational environment can be prepared securely using only the supplied preparative procedures.


Table 5: Mapping of AGD_PRE.1 [CEM] Work Units to Evaluation Activities 603

4.3 Class ALC: Life-cycle Support 604

Use of a CM System (ALC_CMC.2) 605

In order to meet these goals some refinement of the ALC_CMC.2 [CEM] work units 606 is needed. The following table indicates, for each work unit in ALC_CMC.2, whether 607 the [CEM] work unit is to be performed as written, or if it has been clarified by an 608 Evaluation Activity. If clarification has been provided, a reference to this clarification 609 is provided in the table. 610

[CEM] ALC_CMC.2 Work Units Evaluation Activities

ALC_CMC.2-1 The evaluator shall check that the TOE provided for evaluation is labelled with its reference.


ALC_CMC.2-2 The evaluator shall check that the TOE




[CEM] ALC_CMC.2 Work Units Evaluation Activities

references used are consistent.

ALC_CMC.2-3 The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified.


ALC_CMC.2-4 The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation.


Table 6: Mapping of ALC_CMC.2 [CEM] Work Units to Evaluation Activities 611

Parts of the TOE CM Coverage (ALC_CMS.2) 612

In order to meet these goals some refinement of the ALC_CMS.2 [CEM] work units 613 is needed. The following table indicates, for each work unit in ALC_CMS.2, whether 614 the [CEM] work unit is to be performed as written, or if it has been clarified by an 615 Evaluation Activity. If clarification has been provided, a reference to this clarification 616 is provided in the table. 617

[CEM] ALC_CMS.2 Work Units Evaluation Activities

ALC_CMS.2-1 The evaluator shall check that the configuration list includes the following set of items:

a) the TOE itself;

b) the parts that comprise the TOE;

c) the evaluation evidence required by the SARs.


ALC_CMS.2-2 The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item.


ALC_CMS.2-3 The evaluator The evaluator shall perform the [CEM]



[CEM] ALC_CMS.2 Work Units Evaluation Activities

shall check that the configuration list indicates the developer of each TSF relevant configuration item.

activity as specified.

Table 7: Mapping of ALC_CMS.2 [CEM] Work Units to Evaluation Activities 618

Delivery Procedures (ALC_DEL.1) 619

In order to meet these goals some refinement of the ALC_DEL.1 [CEM] work units is 620 needed. The following table indicates, for each work unit in AGD_PRE.1, whether 621 the [CEM] work unit is to be performed as written, or if it has been clarified by an 622 Evaluation Activity. If clarification has been provided, a reference to this clarification 623 is provided in the table. 624

[CEM] ALC_DEL.1 Work Units Evaluation Activities

ALC_DEL.1-1 The evaluator shall examine the delivery documentation to determine that it describes all procedures that are necessary to maintain security when distributing versions of the TOE or parts of it to the consumer.


ALC_DEL.1-2 The evaluator shall examine aspects of the delivery process to determine that the delivery procedures are used.


Table 8: Mapping of AGD_PRE.1 [CEM] Work Units to Evaluation Activities 625

Systematic Flaw Remediation (ALC_FLR.3) 626

A DBMS is often a key component in a larger infrastructure. Therefore, the response 627 to potential security flaws must be clearly established, and comprehensive. There 628 must be a means of providing information and solutions to users in a timely manner, 629 using automated means. ALC_FLR.3 has been mandated to meet these 630 requirements. 631

The following table indicates, for each work unit in ALC_FLR.3, whether the [CEM] 632 work unit is to be performed as written, or if it has been clarified by an Evaluation 633



Activity. If clarification has been provided, a reference to this clarification is provided 634 in the table. 635

[CEM] ALC_FLR.3 Work Units Evaluation Activities

ALC_FLR.3-1 The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the procedures used to track all reported security flaws in each release of the TOE.


ALC_FLR.3-2 The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would produce a description of each security flaw in terms of its nature and effects.


ALC_FLR.3-3 The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would identify the status of finding a correction to each security flaw.


ALC_FLR.3-4 The evaluator shall check the flaw remediation procedures to determine that the application of these procedures would identify the corrective action for each security flaw.


ALC_FLR.3-5 The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a means of providing the TOE users with the necessary information on each security flaw.


ALC_FLR.3-6 The evaluator The evaluator shall perform the [CEM]




shall examine the flaw remediation procedures to determine that the application of these procedures would result in a means for the developer to receive from TOE user reports of suspected security flaws or requests for corrections to such flaws.


ALC_FLR.3-7 The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in a timely means of providing the registered TOE users who might be affected with reports about, and associated corrections to, each security flaw.

The evaluator shall perform the [CEM] activity as specified. The evaluator must ensure that the vendor has a defined set of timeframes for response to vulnerabilities. The evaluator must ensure that the vendor has rationale for those timeframes.

ALC_FLR.3-8 The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in automatic distribution of the reports and associated corrections to the registered TOE users who might be affected.


ALC_FLR.3-9 The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure that every reported flaw is corrected.


ALC_FLR.3-10 The evaluator shall examine the flaw remediation procedures to determine that the application of





these procedures would help to ensure that the TOE users are issued remediation procedures for each security flaw.

ALC_FLR.3-11 The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in safeguards that the potential correction contains no adverse effects.


ALC_FLR.3-12 The evaluator shall examine the flaw remediation guidance to determine that the application of these procedures would result in a means for the TOE user to provide reports of suspected security flaws or requests for corrections to such flaws.


ALC_FLR.3-13 The evaluator shall examine the flaw remediation guidance to determine that it describes a means of enabling the TOE users to register with the developer.


ALC_FLR.3-14 The evaluator shall examine the flaw remediation guidance to determine that it identifies specific points of contact for user reports and enquiries about security issues involving the TOE.


Table 9: Mapping of ALC_FLR.3 [CEM] Work Units to Evaluation Activities 636

4.4 Class ASE: Security Target Evaluation 637 When evaluating a Security Target, the evaluator performs the work units as 638 presented in the CEM. In addition, the evaluator ensures the content of the TSS in 639 the ST satisfies the EAs specified in Section 2 (Evaluation Activities for SFRs) and 640 Section 3 (Evaluation Activities for Optional SFRs). 641



4.5 Class ATE: Tests 642

Evidence of Coverage (ATE_COV.1) 643

644

The developer is expected to provide evidence of functional testing of the DBMS, at 645 a level consistent with ATE_COV.1. 646

OR 647

In order to meet these goals some refinement of the ATE_COV.1 [CEM] work units is 648 needed. The following table indicates, for each work unit in ATE_COV.1, whether the 649 [CEM] work unit is to be performed as written, or if it has been clarified by an 650 Evaluation Activity. If clarification has been provided, a reference to this clarification 651 is provided in the table. 652

[CEM] ATE_COV.1 Work Units Evaluation Activities

ATE_COV.1-1 The evaluator shall examine the test coverage evidence to determine that the correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification is accurate.


Table 10: Mapping of ATE_COV.1 [CEM] Work Units to Evaluation Activities 653

Functional Testing (ATE_FUN.1) 654

The developer is expected to provide evidence of functional testing of the DBMS, at 655 a level consistent with ATE_FUN.1. Automated testing may be used in whole or in 656 part to satisfy the developer test requirements. 657

[CEM] ATE_FUN.1 Work Units Evaluation Activities

ATE_FUN.1-1 The evaluator shall check that the test documentation includes test plans, expected test results and actual test results.


ATE_FUN.1-2 The evaluator shall examine the test plan to

The evaluator shall perform the [CEM]



[CEM] ATE_FUN.1 Work Units Evaluation Activities

determine that it describes the scenarios for performing each test.


ATE_FUN.1-3 The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the ST.


ATE_FUN.1-4 The evaluator shall examine the test plans to determine that sufficient instructions are provided for any ordering dependencies.


ATE_FUN.1-5 The evaluator shall examine the test documentation to determine that all expected tests results are included.


ATE_FUN.1-6 The evaluator shall check that the actual test results in the test documentation are consistent with the expected test results in the test documentation.


ATE_FUN.1-7 The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and results.


Table 11: Mapping of ATE_FUN.1 [CEM] Work Units to Evaluation Activities 658

Independent Testing (ATE_IND.2) 659

Testing is performed to confirm the functionality described in the TSS, and that this 660 functionality can be exercised in accordance with the guidance documentation. The 661 focus of the testing is to confirm that the requirements specified in the SFRs are 662 being met. The Evaluation Activities within this document identify the specific testing 663 activities necessary to verify compliance with the SFRs. The evaluator must produce 664 a test report documenting the plan for and results of testing. The test report must 665 also ensure that all the requirement of ATE_IND.2 have been met, as noted below. 666



[CEM] ATE_IND.2 Work Units Evaluation Activities

ATE_IND.2-1 The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST.


ATE_IND.2-2 The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state.


ATE_IND.2-3 The evaluator shall examine the set of resources provided by the developer to determine that they are equivalent to the set of resources used by the developer to functionally test the TSF.


ATE_IND.2-4 The evaluator shall conduct testing using a sample of tests found in the developer test plan and procedures.

The evaluator shall perform the [CEM] activity as specified. Each of the TSFIs must be exercised.

ATE_IND.2-5 The evaluator shall check that all the actual test results are consistent with the expected test results.


ATE_IND.2-6 The evaluator shall devise a test subset.

The test subset shall be comprised of a sample of the developer test cases plus all of the Test EAs noted within this document. This does not preclude the evaluator from adding their own tests.

ATE_IND.2-7 The evaluator shall produce test documentation for the test





subset that is sufficiently detailed to enable the tests to be reproducible.

ATE_IND.2-8 The evaluator shall conduct testing.


ATE_IND.2-9 The evaluator shall record the following information about the tests that compose the test subset:

a) identification of the interface behaviour to be tested;

b) instructions to connect and setup all required test equipment as required to conduct the test;

c) instructions to establish all prerequisite test conditions;

d) instructions to stimulate the interface;

e) instructions for observing the interface;

f) descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results;

g) instructions to conclude the test and establish the necessary post-test state for the TOE;

h) actual test results.


ATE_IND.2-10 The evaluator shall check that all actual test results are consistent with the expected test results.


ATE_IND.2-11 The evaluator The evaluator shall perform the [CEM]




shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, depth and results.


Table 12: Mapping of ATE_IND.2 [CEM] Work Units to Evaluation Activities 667

668

4.6 Class AVA: Vulnerability Assessment 669

Vulnerability Analysis (AVA_VAN.2) 670

While vulnerability analysis is inherently a subjective activity, a minimum level of 671 analysis can be defined and some measure of objectivity and repeatability (or at 672 least comparability) can be imposed on the vulnerability analysis process. In order to 673 achieve such objectivity and repeatability it is important that the evaluator follows a 674 set of well-defined activities, and documents their findings so others can follow their 675 arguments and come to the same conclusions as the evaluator. While this does not 676 guarantee that different evaluation facilities will identify exactly the same type of 677 vulnerabilities or come to exactly the same conclusions, the approach defines the 678 minimum level of analysis and the scope of that analysis, and provides CBs a 679 measure of assurance that the minimum level of analysis is being performed by the 680 evaluation facilities. 681

In order to meet these goals some refinement of the AVA_VAN.2 [CEM] work units is 682 needed. The following table indicates, for each work unit in AVA_VAN.2, whether the 683 [CEM] work unit is to be performed as written, or if it has been clarified by an 684 Evaluation Activity. If clarification has been provided, a reference to this clarification 685 is provided in the table. 686

[CEM] AVA_VAN.2 Work Units Evaluation Activities

AVA_VAN.2-1 The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST.


AVA_VAN.2-2 The evaluator shall examine the TOE to determine that it has been installed properly and is in a





known state

AVA_VAN.2-3 The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE.

Replace [CEM] work unit with activities outlined in Appendix A.2.

AVA_VAN.2-4 The evaluator shall conduct a search of the ST, guidance documentation, functional specification, TOE design and security architecture description evidence to identify possible potential vulnerabilities in the TOE.


AVA_VAN.2-5 The evaluator shall record in the ETR1 the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment.

Replace the [CEM] work unit with the analysis activities on the list of potential vulnerabilities in Appendix A.1 through A.6 and documentation as specified in Appendix A.7.

AVA_VAN.2-6 The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities.

Replace the [CEM] work unit with the activities specified in Appendix A.6.

AVA_VAN.2-7 The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include:

a) identification of the potential vulnerability the TOE is being

The [CEM] work unit is captured in Appendix A.7 there are no substantive differences.

1 Evaluation Technical Report




tested for;

b) instructions to connect and setup all required test equipment as required to conduct the penetration test;

c) instructions to establish all penetration test prerequisite initial conditions;

d) instructions to stimulate the TSF;

e) instructions for observing the behaviour of the TSF;

f) descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results;

g) instructions to conclude the test and establish the necessary post-test state for the TOE.

AVA_VAN.2-8 The evaluator shall conduct penetration testing.

The evaluator shall perform the [CEM] activity as specified. See, Appendix A.6 for guidance related to attack potential for confirmed flaws.

AVA_VAN.2-9 The evaluator shall record the actual results of the penetration tests.


AVA_VAN.2-10 The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results.

Replace the [CEM] work unit with the reporting called for in Appendix A.7.

AVA_VAN.2-11 The evaluator This work unit is replaced by the




shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a Basic attack potential.

activities defined in Appendix A.6 and A.7.

AVA_VAN.2-12 The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each:

a) its source (e.g. [CEM] activity being undertaken when it was conceived, known to the evaluator, read in a publication);

b) the SFR(s) not met;

c) a description;

d) whether it is exploitable in its operational environment or not (i.e. exploitable or residual).

e) the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using the tables 3 and 4 of Annex B.4.

Replace the [CEM] work unit with the reporting called for in Appendix A.7.

Table 13: Mapping of AVA_VAN.2 [CEM] Work Units to Evaluation Activities 687

Because of the level of detail required for the evaluation activities, the bulk of the 688 instructions are contained in Appendix A, while an “outline” of the evaluation activity 689 is provided below. 690

691

4.7 Evaluation Activity 692 The evaluator formulates flaw hypotheses in accordance with process defined in A.6. 693 The evaluator documents the flaw hypotheses generated for the TOE in the report in 694



accordance with the guidelines in Appendix A.7. The evaluator shall perform 695 vulnerability analysis in accordance with Appendix A.6. The results of the analysis 696 shall be documented in the report according to Appendix A.7. 697



5. References 698

[CC1] Common Criteria for Information Technology Security 699 Evaluation, Part 1: Introduction and General Model 700 CCMB-2017-04-001, Version 3.1 Revision 5, April 2017 701

[CC2] Common Criteria for Information Technology Security 702 Evaluation, 703 Part 2: Security Functional Components, 704 CCMB-2017-049-002, Version 3.1 Revision 5, April 2017 705

[CC3] Common Criteria for Information Technology Security 706 Evaluation, 707 Part 3: Security Assurance Components, 708 CCMB-2017-04-003, Version 3.1 Revision 5, April 2017 709

[CEM] Common Methodology for Information Technology Security 710 Evaluation, 711 Evaluation Methodology, 712 CCMB-2017-04-004, Version 3.1, Revision 5, April 2017 713

[CCADD] CC and CEM Addenda, 714 Exact Conformance, Selection-Based SFRs, Optional SFRs 715 CCMB-2017-05-XXX, Version 0.5, May 2017 716

[DBMScPP] collaborative Protection Profile for Database Management 717 Systems, 718 Version 0.03, 18 June, 2019 719

720



Appendix A. Vulnerability Analysis 721

Editor's Note: This text has been brought in from the FDE 2.0 AA Supporting 722 document. The editor has updated Table 1. And replaced 723 AVA_VAN.1.* with AVA_VAN.2.* appropriately (There is one more 724 work unit in AVA_VAN.2 However this needs thorough review by the 725 DBMS SMEs!) 726

A.1 Sources of vulnerability information 727

[CEM] Work Unit AVA_VAN.2-3 has been supplemented in this SD to provide a 728 better-defined set of flaws to investigate and procedures to follow based on this 729 particular technology. Terminology used is based on the flaw hypothesis 730 methodology, where the evaluation team hypothesizes flaws and then either proves 731 or disproves those flaws (a flaw is equivalent to a “potential vulnerability” as used in 732 the [CEM]). Flaws are categorized into four “types” depending on how they are 733 formulated: 734

1. A list of flaw hypotheses applicable to the technology described by the cPP 735 derived from public sources as documented in Appendix A.2 – this fixed set 736 has been agreed to by the iTC. Additionally, this will be supplemented with 737 entries for a set of public sources that are directly applicable to the TOE or its 738 identified components (Type 1 flaws, as defined by the process in Appendix 739 A.2); this is to ensure that the evaluators include in their assessment 740 applicable entries that have been discovered since the cPP was published; 741

2. A list of flaw hypotheses contained in this document that are derived from 742 lessons learned specific to that technology and other iTC input (for example 743 that might be derived from other open sources and vulnerability databases) as 744 documented in Appendix A.1. At this time, the iTC has not identified any of 745 these Type 2 flaws. Type 2 flaws may be identified for subsequent versions of 746 this cPP. 747

3. A list of flaw hypotheses derived from information available to the evaluators; 748 this includes the baseline evidence provided by the developer described in 749 this SD (documentation associated with EAs, documentation described in 750 Section Error! Reference source not found.), as well as other information 751 (public and/or based on evaluator experience) as documented in Appendix 752 A.1; and 753

4. A list of flaw hypotheses that are generated through the use of iTC-defined 754 tool types and their application is specified in Appendix A.5. 755

https://www.commoncriteriaportal.org/files/ppfiles/CPP_FDE_AA_V2.0E_supporting_doc.pdf

https://www.commoncriteriaportal.org/files/ppfiles/CPP_FDE_AA_V2.0E_supporting_doc.pdf



A.2 Type 1 Hypotheses—Public-Vulnerability-based 756

The following list of public sources of vulnerability information was selected by the 757 iTC: 758

a) Search Common Vulnerabilities and Exposures: https://cve.mitre.org/cve/ 759

b) Search the National Vulnerability Database: https://nvd.nist.gov/ 760

c) Search US-CERT: https://www.kb.cert.org/vuls/search/ 761

d) Search CVE Details: https://www.cvedetails.com/ 762

e) Search Packet Storm: https://www.packetstormsecurity.org/ 763

At minimum, the search terms should include software identifier (e.g. name) and 764 version and will be used by the evaluators in formulating hypotheses during their 765 analysis. The list of sources above was searched with the following search terms: 766

• Product name 767

• If specific platform libraries are included in the evaluated configuration (as 768 specified in the administrator guidance) then the search terms should include 769 those items and their specified version 770

• Keywords associated with the TOE 771

The evaluator will also consider the requirements that are chosen and the 772 appropriate guidance that is tied to each requirement. 773

In order to supplement this list, the evaluators shall also perform a search on the 774 sources listed above to determine a list of potential flaw hypotheses that are more 775 recent than the publication date of the cPP, and those that are specific to the TOE 776 and its components as specified by the additional documentation mentioned above. 777 Any duplicates – either in a specific entry, or in the flaw hypothesis that is generated 778 from an entry from the same or a different source – can be noted and removed from 779 consideration by the evaluation team. 780

As part of type 1 flaw hypothesis generation for the specific components of the TOE, 781 the evaluator shall also search the developer’s websites to determine if flaw 782 hypotheses can be generated. For instance, if security patches have been released 783 for the version of the component being evaluated, the subject of those patches may 784 form the basis for a flaw hypothesis. 785

A.3 Type 2 Hypotheses—iTC-Sourced 786

At this time, the iTC has not identified any Type 2 flaws. Type 2 flaws may be 787 identified for subsequent versions of this cPP. 788

https://cve.mitre.org/cve/

https://nvd.nist.gov/

https://www.kb.cert.org/vuls/search/

https://www.cvedetails.com/

https://packetstormsecurity.com/



A.4 Type 3 Hypotheses—Evaluation-Team-Generated 789

The iTC has leveraged the expertise of the developers and the evaluation labs to 790 diligently develop the appropriate search terms and vulnerability databases. They 791 have also thoughtfully considered the iTC-sourced hypotheses the evaluators should 792 use based upon the applicable use case and the threats to be mitigated by the 793 SFRs. Therefore, it is the intent of the iTC, for the evaluation to focus all effort on the 794 Type 1 and Type 2 Hypotheses. 795

If the evaluators discover a Type 3 potential flaw that they believe should be 796 considered, they should work with their CB to determine the feasibility of pursuing 797 the hypothesis. The CB may determine whether the potential flaw hypotheses are 798 worth submitting to the iTC for consideration as Type 2 hypotheses in future drafts of 799 the cPP/SD. 800

A.5 Type 4 Hypotheses—Tool-Generated 801

The evaluator will determine the open Transmission Control Protocol (TCP) and 802 User Datagram Protocol (UDP) ports (e.g. by scanning of the DBMS) and verify that 803 there are no unknown open ports. All open ports must be associated with expected 804 services and protocols. 805

The evaluator will also choose a vulnerability scanning tool to scan for potential 806 vulnerabilities. Although the iTC does not intend to restrict the list of tools that can be 807 used, the tool must be able to provide up to date scanning, through updated 808 signatures, or another mechanism. 809

A.6 Process for Evaluator Vulnerability Analysis 810

As flaw hypotheses are generated from the activities described above, the evaluation 811 team will disposition them; that is, attempt to prove, disprove, or determine the non-812 applicability of the hypotheses. This process is as follows: 813

The evaluator will refine each flaw hypothesis for the TOE and attempt to disprove it 814 using the information provided by the developer or through penetration testing. 815 During this process, the evaluator is free to interact directly with the developer to 816 determine if the flaw exists, including requests to the developer for additional 817 evidence (e.g., detailed design information, consultation with engineering staff); the 818 CB may be included in these discussions. 819

A.6.1 Unavailable evidence 820

In the case that the developer objects to the information being requested as being 821 beyond that required by the evaluation activity/cPP and cannot provide other 822 evidence that the flaw is disproved, the evaluator prepares an appropriate set of 823 materials as follows: 824



• The documents used in formulating the hypothesis, and why it represents 825 a potential compromise against a specific TOE function; 826

• An argument why the flaw hypothesis could neither be proven nor 827 disproved by the evidence provided so far; and 828

• The types of information required to investigate the flaw hypothesis further. 829

The CB will then either approve or disapprove the request for additional information. 830 If approved, the developer provides the requested evidence to disprove the flaw 831 hypothesis (or, of course, acknowledge the flaw). 832

If the CB disapproves the request for additional information, the evaluator will follow 833 AVA_VAN.2.4E and devise suitable penetration tests to enable the flaw to be 834 disproved or classified as a residual vulnerability. 835

A.6.2 Dealing with flaws 836

If the evaluator finds a flaw, the evaluator must report these flaws to the developer. 837 All reported flaws must be addressed as follows: 838

a) If the developer confirms that the flaw exists and that it is exploitable at Basic 839 Attack Potential, then a change is made by the developer, and the resulting 840 resolution is agreed by the evaluator. 841

b) If the developer, the evaluator, and the CB agree that the flaw is exploitable 842 only above Basic Attack Potential and does not require resolution for any 843 other reason, and no change is made, then the flaw is noted as a residual 844 vulnerability in the proprietary ETR. 845

c) If the developer and evaluator agree that the flaw is exploitable only above 846 Basic Attack Potential, but it is deemed critical to fix because of technology-847 specific or cPP-specific aspects such as typical use cases or operational 848 environments, then a change is made by the developer, and the resulting 849 resolution is agreed by the evaluator. 850

Disagreements between the evaluator and the developer regarding questions of the 851 existence of a flaw, its attack potential, or whether it should be deemed critical to fix 852 are resolved by the CB. 853

Any testing performed by the evaluator and the results of the analysis are 854 documented as outlined in Appendix A.7 below. 855

As indicated in Appendix A.7, the public statement with respect to vulnerability 856 analysis that is performed on TOEs conformant to the cPP is constrained to 857 coverage of flaws associated with Types 1 and 2 (defined in Appendix A.1) flaw 858 hypotheses only. The fact that the iTC generates these candidate hypotheses 859 indicates that these must be addressed. 860



A.7 Reporting 861

The evaluators shall produce a report on the vulnerability assessment that is 862 delivered to the overseeing CB. This may form part of the ETR, or may be in another 863 format if so required by the CB. 864

This report must contain: 865

• The flaw identifiers returned when the procedures for searching public 866 sources were followed according to instructions in the SD per Appendix 867 A.2 (cf. AVA_VAN.2-4); 868

• A statement that the evaluators have examined the Type 1 flaw 869 hypotheses specified in this SD in Appendix A.2 (i.e. the flaws listed in the 870 previous bullet) and the Type 2 flaw hypotheses specified in this SD by the 871 iTC in Appendix A.1; 872

• A list of all of the flaw hypotheses generated (cf. AVA_VAN.2-4); 873

• The evaluator penetration testing effort, outlining the testing approach, 874 configuration, depth and results (cf. AVA_VAN.2-10); 875

• All documentation used to generate the flaw hypotheses (in identifying the 876 documentation used in coming up with the flaw hypotheses, the evaluation 877 team must characterize the documentation so that a reader can determine 878 whether it is strictly required by this SD, and the nature of the 879 documentation (design information, developer engineering notebooks, 880 etc.)); 881

• How each flaw hypothesis was resolved (this includes whether the original 882 flaw hypothesis was confirmed or disproved, and any analysis relating to 883 whether a residual vulnerability is exploitable by an attacker with Basic 884 Attack Potential) (cf. AVA_VAN.2-11); 885

• The evaluator shall report all exploitable vulnerabilities and residual 886 vulnerabilities, detailing for each: 887

• Its source (e.g. [CEM] activity being undertaken when it was conceived, 888 known to the evaluator, read in a publication); 889

• The SFR(s) not met; 890

• A description; 891

• Whether it is exploitable in its operational environment or not (i.e. 892 exploitable or residual). 893



• The amount of time, level of expertise, level of knowledge of the TOE, 894 level of opportunity and the equipment required to perform the 895 identified vulnerabilities (cf. AVA_VAN.2-12); 896

• In the case that actual testing was performed in the investigation (either as 897 part of flaw hypothesis generation using tools specified by the iTC in 898 Appendix A.5 or in proving/disproving a particular flaw) the steps followed 899 in setting up the TOE (and any required test equipment); executing the 900 test; post-test procedures; and the actual results (to a level of detail that 901 allow repetition of the test, including the following: 902

• Identification of the potential vulnerability the TOE is being tested for; 903

• Instructions to connect and setup all required test equipment as 904 required to conduct the penetration test; 905

• Instructions to establish all penetration test pre-requisite initial 906 conditions; 907

• Instructions to stimulate the TSF; 908

• Instructions for observing the behaviour of the TSF; 909

• Descriptions of all expected results and the necessary analysis to be 910 performed on the observed behaviour for comparison against expected 911 results; 912

• Instructions to conclude the test and establish the necessary post-test 913 state for the TOE. (cf. AVA_VAN.2-7). 914



Appendix B. Glossary 915

The terms, definitions and abbreviations given in [CC1] and [CEM] apply to this 916 document. Additional terms, definitions and abbreviations applicable are found in the 917 DBMS cPP. In addition, the following are used in this document: 918

B.1 Terms and Definitions 919

Term Meaning

TBD

B.2 Acronyms used in this SD 920

Acronym Meaning

CB Certification Body

CC Common Criteria

CCDB Common Criteria Development Board

CCRA Common Criteria Recognition Arrangement

CEM Common Evaluation Methodology

cPP Collaborative Protection Profile

CVE Common Vulnerabilities and Exposures

DBMS Database Management System

EA Evaluation Activities

ETR Evaluation Technical Report

iTC International Technical Community

SAR Security Assurance Requirement

SD Supporting Document

SFR Security functional requirement

ST Security Target

TCP Transmission Control Protocol

TOE Target of Evaluation

TSF TOE Security Functionality

TSS TOE Summary Specification

UDP User Datagram Protocol

921