collaborative Protection Profile for Database Management Systems · 2020. 8. 28. · collaborative...

collaborative Protection Profile for Database Management Systems

v 0.17 DRAFT of 40

Supporting Document 1

Mandatory Technical Document 2

3

4

5

collaborative Protection Profile for 6

Database Management Systems cPP 7

7 April 2020 8

Version 0.17 9

10

CCDB-2020-<month>-<number> 11

12


v 0.17 DRAFT of 40

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 collaborative Protection Profiles 26 (cPPs) identified in Section 1.1. 27

Technical Editor: Database Management System (DBMS) international Technical 28 Community (iTC) 29

Document history: 30

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

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

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

V0.04-0.16 Interim updates after iTC meetings 34

V0.17 Changes accepted 35

General Purpose: See Section 1.1. 36

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

Acknowledgements: 40

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

45


v 0.17 DRAFT of 40

Contents 46

Foreword ................................................................................................................................................. 2 47

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

2. Evaluation Activities for SFRs ............................................................................................................ 8 52 2.1 Class: Security Audit (FAU) ..................................................................................................... 8 53

FAU_GEN.1 Audit data generation .......................................................................... 8 54 TSS 8 55 Guidance Documentation ........................................................................................... 8 56 Tests 9 57

FAU_GEN.2 User identity association ..................................................................................... 9 58 TSS 9 59 Guidance Documentation ........................................................................................... 9 60 Tests 9 61

FAU_SEL.1 Selective audit ..................................................................................................... 9 62 TSS 9 63 Guidance Documentation ........................................................................................... 9 64 Tests 9 65

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

TSS 10 68 Guidance Documentation ......................................................................................... 10 69 Tests 10 70

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

FDP_RIP.1 Subset residual information protection ............................................................... 11 75 TSS 11 76 Guidance Documentation ......................................................................................... 11 77 Tests 11 78

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


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

FIA_UID.2 User identification before any action ................................................................... 12 88 TSS 12 89 Guidance Documentation ......................................................................................... 12 90 Tests 12 91

2.4 Class: Security Management (FMT) ...................................................................................... 12 92 FMT_MSA.1 Management of security attributes ................................................................... 12 93


FMT_MSA.3 Static attribute initialization ............................................................................... 13 97 TSS 13 98 Guidance Documentation ......................................................................................... 13 99 Tests 13 100

FMT_MTD.1 Management of TSF data ................................................................................. 13 101 TSS 13 102


v 0.17 DRAFT of 40

Guidance Documentation ......................................................................................... 13 103 Tests 13 104

FMT_REV.1(1) Revocation.................................................................................................... 14 105 TSS 14 106 Guidance Documentation ......................................................................................... 14 107 Tests 14 108

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

FMT_SMF.1 Specification of Management Functions .......................................................... 15 113 TSS 15 114 Guidance Documentation ......................................................................................... 15 115 Tests 15 116

FMT_SMR.1 Security roles.................................................................................................... 15 117 TSS 15 118 Guidance Documentation ......................................................................................... 16 119 Tests 16 120

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

FTA_TSE.1 TOE session establishment ............................................................................... 16 125 TSS 16 126 Guidance Documentation ......................................................................................... 17 127 Tests 17 128

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

FIA_USB_EXT.2 Enhanced user-subject binding ................................................................. 17 131 TSS 17 132 Guidance Documentation ......................................................................................... 17 133 Tests 17 134

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

TSS 17 137 Guidance Documentation. ........................................................................................ 18 138 Tests 18 139

3.3 Class: TOE access (FTA) ...................................................................................................... 18 140 FTA_TAH_EXT.1 TOE access information ........................................................................... 18 141


4. Evaluation Activities for SARs .......................................................................................................... 19 145 4.1 ADV: Development ................................................................................................................ 19 146

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

4.2 AGD: Guidance Documentation ............................................................................................ 20 150 Operational User Guidance (AGD_OPE.1) ........................................................................... 20 151 Preparative Procedures (AGD_PRE.1) ................................................................................. 21 152

4.3 Class ALC: Life-cycle Support ............................................................................................... 21 153 Use of a CM System (ALC_CMC.2) ...................................................................................... 21 154 Parts of the TOE CM Coverage (ALC_CMS.2) ..................................................................... 21 155 Delivery Procedures (ALC_DEL.1) ........................................................................................ 21 156


v 0.17 DRAFT of 40

Systematic Flaw Remediation (ALC_FLR.3) ......................................................................... 21 157 4.4 Class ASE: Security Target Evaluation ................................................................................. 24 158 4.5 Class ATE: Tests ................................................................................................................... 24 159

Evidence of Coverage (ATE_COV.1) .................................................................................... 24 160 Functional Testing (ATE_FUN.1) .......................................................................................... 24 161 Independent Testing (ATE_IND.2) ........................................................................................ 25 162

4.6 Class AVA: Vulnerability Assessment ................................................................................... 27 163 Vulnerability Analysis (AVA_VAN.2) ...................................................................................... 27 164

4.7 Evaluation Activity .................................................................................................................. 31 165

5. References ....................................................................................................................................... 32 166

Appendix A. Vulnerability Analysis ................................................................................................ 33 167 A.1 Sources of vulnerability information ....................................................................................... 33 168 A.2 Type 1 Hypotheses—Public-Vulnerability-based .................................................................. 33 169 A.3 Type 2 Hypotheses—iTC-Sourced ........................................................................................ 34 170

A.3.1 SQL Injection ............................................................................................................ 34 171 A.4 Type 3 Hypotheses—Evaluation-Team-Generated .............................................................. 35 172 A.5 Type 4 Hypotheses—Tool-Generated ................................................................................... 35 173 A.6 Process for Evaluator Vulnerability Analysis ......................................................................... 36 174

A.6.1 Unavailable evidence ............................................................................................... 36 175 A.6.2 Dealing with flaws ..................................................................................................... 36 176

A.7 Reporting ............................................................................................................................... 37 177

Appendix B. Glossary .................................................................................................................... 39 178 B.1 Terms and Definitions ............................................................................................................ 39 179 B.2 Acronyms used in this SD...................................................................................................... 39 180

181


v 0.17 DRAFT of 40

Figures / Tables 182

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

Table 2: Mapping of ALC_FLR.3 [CEM] Work Units to Evaluation Activities ....................................... 24 184

Table 3: Mapping of ATE_IND.2 [CEM] Work Units to Evaluation Activities ........................................ 27 185

Table 4: Mapping of AVA_VAN.2 [CEM] Work Units to Evaluation Activities ....................................... 31 186

187

188


v 0.17 DRAFT of 40

1. Introduction 189

1.1 Technology Area and Scope of Supporting Document 190 This Supporting Document (SD) defines the Evaluation Activities associated with the 191 collaborative Protection Profile for Database Management Systems [DBMScPP]. 192

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

a) collaborative Protection Profile for Database Management Systems 195 [DBMScPP] 196

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

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

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

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

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

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


v 0.17 DRAFT of 40

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

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

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

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

2. Evaluation Activities for SFRs 250

2.1 Class: Security Audit (FAU) 251

FAU_GEN.1 Audit data generation 252

TSS 253

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

Guidance Documentation 256

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


v 0.17 DRAFT of 40

Tests 260

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

Note that the testing here may be accomplished in conjunction with the testing of the 264 security mechanisms. 265

FAU_GEN.2 User identity association 266

TSS 267

See FAU_GEN.1 268


See FAU_GEN.1 270

Tests 271

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

FAU_SEL.1 Selective audit 273

TSS 274

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


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

Tests 282

i. The evaluator shall generate audit records for each attribute specified in 283 FAU_SEL.1. 284

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

iii. The evaluator shall then: 290


v 0.17 DRAFT of 40

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

b. Verify that audit logs are not generated for the auditable events that are 293 not selected. 294

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

2.2 Class: User Data Protection (FDP) 298

FDP_ACC.1 Subset access control 299

TSS 300

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


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

Tests 304

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

FDP_ACF.1 Security attribute based access control 306

TSS 307

The evaluator shall examine the TSS and verify that an explanation of the 308 discretionary access control policy is given, and that the explanation is both clear 309 and understandable. 310


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

Clearly states the access control rules of the TOE; 313

Explains how the security and object attributes are used by the TOE in order 314 to achieve the desired access control; 315

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

Instructs administrators on how to deny users access to objects using any 318 additional rules defined in FDP_ACF.1.4. 319


v 0.17 DRAFT of 40

Tests 320

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

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

FDP_RIP.1 Subset residual information protection 324

TSS 325

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


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

Tests 331

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

2.3 Class: Identification and authentication (FIA) 334

FIA_ATD.1 User attribute definition 335

TSS 336

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



Tests 343

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

FIA_UAU.2 User authentication before any action 346

TSS 347

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


v 0.17 DRAFT of 40



Tests 353

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

FIA_UID.2 User identification before any action 357

TSS 358

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



Tests 364

Testing is performed in conjunction with FIA_UAU.2. 365

2.4 Class: Security Management (FMT) 366

FMT_MSA.1 Management of security attributes 367

TSS 368

The evaluator shall verify that the TSS contains a description of all of the security 369 attributes in the discretionary access control policy that can be managed by 370 authorized administrators. The evaluator shall also verify that the TSS describes how 371 these security attributes are protected from unauthorized access. 372

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


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


v 0.17 DRAFT of 40

Tests 378

The evaluator shall log on as an authorized administrator and perform allowed 379 operations on the security attributes. The evaluator shall verify that the operations 380 are performed as expected. 381

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

FMT_MSA.3 Static attribute initialization 385

TSS 386

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


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

Tests 392

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

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

FMT_MTD.1 Management of TSF data 399

TSS 400

This was performed in conjunction with FAU_SEL.1. 401


This was performed in conjunction with FAU_SEL.1. 403

Tests 404

Testing is performed in conjunction with FAU_SEL.1. 405


v 0.17 DRAFT of 40

FMT_REV.1(1) Revocation 406

TSS 407

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

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


The evaluator shall examine the guidance documentation to verify that the user 414 security attribute revocation rules are adequately described to the authorized 415 administrator. 416

Tests 417

i. The evaluator shall log on as a user and verify that the user is able to perform 418 actions in accordance with the user security attributes, specified in 419 FMT_REV.1.1(1). If revocation is effective at the next log on then the user 420 shall log off. 421

ii. The evaluator shall log on as an authorized administrator and revoke user 422 security attribute(s) in accordance with the guidance. 423

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

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

FMT_REV.1(2) Revocation (DAC) 429

TSS 430

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

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


v 0.17 DRAFT of 40


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

Tests 439

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

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

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

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

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

FMT_SMF.1 Specification of Management Functions 451

TSS 452

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


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

Tests 459

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

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

FMT_SMR.1 Security roles 465

TSS 466

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


v 0.17 DRAFT of 40


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

Tests 473

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

TOE Access (FTA) 476

FTA_MCS.1 Basic limitation on multiple concurrent sessions 477

TSS 478

The evaluator shall examine the TSS and verify that it states the default number of 479 concurrent sessions per user for the evaluated configuration. If the default number of 480 concurrent sessions can be changed then the evaluator should verify that the TSS 481 states that the default can be changed. 482


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

Tests 487

The evaluator shall establish the maximum number of concurrent sessions and verify 488 that this number of concurrent sessions is allowed. The evaluator shall attempt to 489 establish a number of sessions greater than the maximum specified and verify that 490 additional concurrent sessions cannot be established. 491

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

FTA_TSE.1 TOE session establishment 494

TSS 495

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


v 0.17 DRAFT of 40


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

Tests 501

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

3. Evaluation Activities for Optional SFRs 506

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

3.1 Class: Identification and Authentication (FIA) 508

FIA_USB_EXT.2 Enhanced user-subject binding 509

TSS 510

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



Tests 517

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

525

3.2 Class: Protection of the TSF (FPT) 526

FPT_TRC.1 Internal TSF consistency 527

TSS 528

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


v 0.17 DRAFT of 40

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

Guidance Documentation. 534

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

Tests 537

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

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

3.3 Class: TOE access (FTA) 544

FTA_TAH_EXT.1 TOE access information 545

TSS 546

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


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

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

Tests 554

Test 1: The evaluator shall follow the guidance documentation instructions for 555 retrieving: 556

a) The date and time of the session establishment attempt of the user, and 557 b) The incremental count of successive unsuccessful session establishment, 558

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

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


v 0.17 DRAFT of 40

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

unsuccessful attempts since the previous last successful session 565 establishment. 566

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

4. Evaluation Activities for SARs 568

In order to meet the goals of the evaluation, some of the [CEM] work units have been 569 refined. Otherwise, the evaluator shall perform the CEM activity as specified. 570

4.1 ADV: Development 571

Security architecture description (ADV_ARC.1) 572

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

[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.



v 0.17 DRAFT of 40

[CEM] ADV_ARC.1 Work Units Evaluation Activities

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.

The evaluator shall verify that the evidence indicates whether or not the TOE dynamically creates Structured Query Language (SQL) code, or another query language code for databases that do not use SQL, using supplied input. If dynamic code is used, the evaluator shall verify that the evidence describes the mechanisms that have been implemented to prevent or to mitigate the possibility of SQL injection using dynamic code. (e.g. prepared statements, filtering mechanisms, privilege reduction).

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

Security-enforcing functional specification (ADV_FSP.2) 579

The evaluator shall perform the [CEM] activity as specified for ADV_FSP.2. 580

Basic Design (ADV_TDS.1) 581

The evaluator shall perform the [CEM] activity as specified for ADV_TDS.2. 582

4.2 AGD: Guidance Documentation 583

Operational User Guidance (AGD_OPE.1) 584

Specific requirements and checks on the user guidance documentation are identified 585 (where relevant) in the individual Evaluation Activities for each SFR. Additionally, the 586 evaluator is expected to ensure that the [CEM] requirements of AGD_OPE.1 [CEM] 587 are met. 588


v 0.17 DRAFT of 40

Preparative Procedures (AGD_PRE.1) 589

Specific requirements and checks on the user guidance documentation are identified 590 (where relevant) in the individual Evaluation Activities for each SFR. Additionally, the 591 evaluator is expected to ensure that the [CEM] requirements of AGD_OPE.1 [CEM] 592 are met. 593

4.3 Class ALC: Life-cycle Support 594

Use of a CM System (ALC_CMC.2) 595

The evaluator shall perform the [CEM] activity as specified for ALC_CMC.2. 596

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

The evaluator shall perform the [CEM] activity as specified for ALC_CMS.2. 598

Delivery Procedures (ALC_DEL.1) 599

The evaluator shall perform the [CEM] activity as specified for ALC_DEL.2. 600

Systematic Flaw Remediation (ALC_FLR.3) 601

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

The following table indicates, for each work unit in ALC_FLR.3, whether the [CEM] 607 work unit is to be performed as written, or if it has been clarified by an Evaluation 608 Activity. If clarification has been provided, a reference to this clarification is provided 609 in the table. 610

[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



v 0.17 DRAFT of 40


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 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

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


v 0.17 DRAFT of 40


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.

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



v 0.17 DRAFT of 40


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 2: Mapping of ALC_FLR.3 [CEM] Work Units to Evaluation Activities 611

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

4.5 Class ATE: Tests 617

Evidence of Coverage (ATE_COV.1) 618

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

Functional Testing (ATE_FUN.1) 621

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


v 0.17 DRAFT of 40

Independent Testing (ATE_IND.2) 625

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

[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


v 0.17 DRAFT of 40


this document. This does not preclude the evaluators 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;



v 0.17 DRAFT of 40


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 shall report in the ETR1 the evaluator testing effort, outlining the testing approach, configuration, depth and results.


Table 3: Mapping of ATE_IND.2 [CEM] Work Units to Evaluation Activities 633

4.6 Class AVA: Vulnerability Assessment 634

Vulnerability Analysis (AVA_VAN.2) 635

While vulnerability analysis is inherently a subjective activity, a minimum level of 636 analysis can be defined and some measure of objectivity and repeatability (or at 637 least comparability) can be imposed on the vulnerability analysis process. In order to 638 achieve such objectivity and repeatability it is important that the evaluator follows a 639 set of well-defined activities, and documents the findings so others can follow these 640 arguments and come to the same conclusions as the evaluator. While this does not 641 guarantee that different evaluation facilities will identify exactly the same type of 642 vulnerabilities or come to exactly the same conclusions, the approach defines the 643 minimum level of analysis and the scope of that analysis, and provides CBs a 644 measure of assurance that the minimum level of analysis is being performed by the 645 evaluation facilities. 646

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

1 Evaluation Technical Report


v 0.17 DRAFT of 40

[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 ETR2 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

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

2 Evaluation Technical Report


v 0.17 DRAFT of 40


search for potential vulnerabilities.

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 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.

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

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.


v 0.17 DRAFT of 40


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 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.

This work unit is replaced by the 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

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


v 0.17 DRAFT of 40


perform the identified vulnerabilities, and the corresponding values using the tables 3 and 4 of Annex B.4.

Table 4: Mapping of AVA_VAN.2 [CEM] Work Units to Evaluation Activities 652

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

4.7 Evaluation Activity 656 The evaluator formulates flaw hypotheses in accordance with process defined in A.6. 657 The evaluator documents the flaw hypotheses generated for the TOE in the report in 658 accordance with the guidelines in Appendix A.7. The evaluator shall perform 659 vulnerability analysis in accordance with Appendix A.6. The results of the analysis 660 shall be documented in the report according to Appendix A.7. 661


v 0.17 DRAFT of 40

5. References 662

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

[CC2] Common Criteria for Information Technology Security 666 Evaluation, 667 Part 2: Security Functional Components, 668 CCMB-2017-049-002, Version 3.1 Revision 5, April 2017 669

[CC3] Common Criteria for Information Technology Security 670 Evaluation, 671 Part 3: Security Assurance Components, 672 CCMB-2017-04-003, Version 3.1 Revision 5, April 2017 673

[CEM] Common Methodology for Information Technology Security 674 Evaluation, 675 Evaluation Methodology, 676 CCMB-2017-04-004, Version 3.1, Revision 5, April 2017 677

[CCADD] CC and CEM Addenda, 678 Exact Conformance, Selection-Based SFRs, Optional SFRs 679 CCMB-2017-05-XXX, Version 0.5, May 2017 680

[DBMScPP] collaborative Protection Profile for Database Management 681 Systems, 682 Version 0.06, 28 February 2020 683

684


v 0.17 DRAFT of 40

Appendix A. Vulnerability Analysis 685

A.1 Sources of vulnerability information 686

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

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

2. A list of flaw hypotheses contained in this document that are derived from 701 lessons learned specific to that technology and other iTC input (for example, 702 potential flaws that might be derived from other open sources and vulnerability 703 databases) as documented in Appendix A.3. At this time, the iTC has 704 identified one Type 2 flaw (SQL Injection). Additional Type 2 flaws may be 705 identified for subsequent versions of this cPP. 706

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

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

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

The following list of public sources of vulnerability information was selected by the 716 iTC: 717

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

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

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

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

https://nvd.nist.gov/

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


v 0.17 DRAFT of 40

d) Search CVE3 Details: https://www.cvedetails.com/ 721

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

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

Product name 726

If specific platform libraries are included in the evaluated configuration (as 727 specified in the administrator guidance) then the search terms should include 728 those items and their specified version 729

Keywords associated with the TOE 730

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

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

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

A.3 Type 2 Hypotheses—iTC-Sourced 745

A.3.1 SQL Injection 746

SQL Injection is a security vulnerability that allows an attacker to manipulate queries. 747 Typically, these queries are made by an application to a database; however, if the 748 database creates SQL code dynamically, or includes a client that creates SQL code 749 dynamically, then this vulnerability may exist within the DBMS TOE. 750

3 Common Vulnerabilities and Exposures

https://www.cvedetails.com/

https://packetstormsecurity.com/


v 0.17 DRAFT of 40

The result of such a query may allow an attacker to view data that would not 751 normally be available to that user, may allow the user to infer information about the 752 database structure or content, or may allow the attacker to modify or delete data. 753

If the information presented for ADV_ARC.1-5 indicates that the DBMS dynamically 754 creates queries from user input, the evaluator must test the effectiveness of the 755 mitigation mechanisms. The evaluator must devise and execute at least one test 756 case to demonstrate this function. It is recommended, but not required, that the test 757 case be based on one of the attacks described by the Open Web Application 758 Security Project (OWASP). 759

The evaluator must also devise a test for SQL vulnerabilities if the public vulnerability 760 search results indicate that recent (within two years) versions of the TOE were 761 susceptible to an SQL Injection attack. Additional client or environmental 762 components that may be described in public vulnerabilities only need to be tested if 763 they are part of the DBMS TOE, or the operational environment described in the ST. 764

If no relevant public vulnerabilities are found, and the evaluator determines that the 765 DBMS does not dynamically create SQL queries (or any other query language code), 766 then the evaluator will not be required to perform SQL Injection testing. 767

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

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

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

A.5 Type 4 Hypotheses—Tool-Generated 780

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

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


v 0.17 DRAFT of 40

A.6 Process for Evaluator Vulnerability Analysis 789

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

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

A.6.1 Unavailable evidence 799

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

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

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

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

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

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

A.6.2 Dealing with flaws 815

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

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

b) If the developer, the evaluator, and the CB agree that the flaw is exploitable 821 only above Basic Attack Potential and does not require resolution for any 822


v 0.17 DRAFT of 40

other reason, and no change is made, then the flaw is noted as a residual 823 vulnerability in the proprietary ETR. 824

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

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

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

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

A.7 Reporting 840

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

This report must contain: 844

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

• A statement that the evaluators have examined the Type 1 flaw 848 hypotheses specified in this SD in Appendix A.2 (i.e. the flaws listed in the 849 previous bullet) and the Type 2 flaw hypotheses specified in this SD by the 850 iTC in Appendix A.3; 851

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

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

• All documentation used to generate the flaw hypotheses (in identifying the 855 documentation used in coming up with the flaw hypotheses, the evaluation 856 team must characterize the documentation so that a reader can determine 857 whether it is strictly required by this SD, and the nature of the 858 documentation (design information, developer engineering notebooks, 859 etc.)); 860


v 0.17 DRAFT of 40

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

• The evaluator shall report all exploitable vulnerabilities and residual 865 vulnerabilities, detailing for each: 866

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

• The SFR(s) not met; 869

• A description; 870

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

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

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

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

• Instructions to connect and setup all required test equipment as 883 required to conduct the penetration test; 884

• Instructions to establish all penetration test pre-requisite initial 885 conditions; 886

• Instructions to stimulate the TSF; 887

• Instructions for observing the behaviour of the TSF; 888

• Descriptions of all expected results and the necessary analysis to be 889 performed on the observed behaviour for comparison against expected 890 results; 891

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


v 0.17 DRAFT of 40

Appendix B. Glossary 894

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

B.1 Terms and Definitions 898

Term Meaning

Administrator The term ‘Administrator’ refers to a user who has been specifically granted the authority to manage some portion or the entire TOE and whose actions may affect the DAC. Administrators may possess special privileges that provide capabilities to override portions of the access control policy.

Application An executable program.

Database Management System (DBMS)

A suite of programs that typically manage large structured sets of persistent data, offering ad hoc query facilities to many users. They are widely used in business applications.

Discretionary Access Control (DAC)

A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. Those controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject.

899

B.2 Acronyms used in this SD 900

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

OWASP Open Web Application Security Project

SAR Security Assurance Requirement

SD Supporting Document

SFR Security Functional Requirement

SQL Structured Query Language


v 0.17 DRAFT of 40

ST Security Target

TCP Transmission Control Protocol

TOE Target of Evaluation

TSF TOE Security Functionality

TSS TOE Summary Specification

UDP User Datagram Protocol

901

collaborative Protection Profile for Database Management Systems · 2020. 8. 28. · collaborative...

Documents

Transcript of collaborative Protection Profile for Database Management Systems · 2020. 8. 28. · collaborative...