Commit b64f66fe authored by Valerie Aurora's avatar Valerie Aurora
Browse files

Clause 6.2: Move guidance from Preparation to Guidance

parent 1252a88e
Loading
Loading
Loading
Loading
+14 −5
Original line number Diff line number Diff line
@@ -988,10 +988,10 @@ Secure design and development.

Identify all sources of untrusted input to the product. For each source of untrusted input, identify fields in the inputs that are used for:

  * calculation of memory accesses (e.g., length, index, hash table lookup values, etc.)
  * allocation of product resources (e.g., buffer length, number of log events, CPU-intensive operations, etc.)
  * incrementing or decrementing of cybersecurity-relevant internal counters (e.g., event counters used to generate alerts, etc.)
  * creating or populating internal data structures (e.g., parsing input to populate a log message descriptor)
  * calculation of memory accesses: length, index, hash table lookup values, packet reassembly
  * allocation of product resources: buffer length, number of packet descriptors, buffers for reassembly of fragmented packets, CPU-intensive cryptographic operations
  * incrementing or decrementing of internal counters: packet counters, event counters
  * creating or populating internal data structures: parameters for creating an array of packet descriptors

For each identified field, identify a set of inputs that contains at least one input that fulfills each of the following descriptions, if and only if the description is applicable to the field, the described values exist, and they are possible to send as input:

@@ -1034,10 +1034,19 @@ Otherwise FAIL

#### 6.2.2.6 Guidance

The list of inputs to test includes some types of input that may not exist or be possible to send. For example, if the maximum **valid** value is also the maximum **possible** value, then it is not possible to send the next value higher than the maximum value. These values do not need to be tested.
Assessment can often be done with minimal effort using commonly available fuzzer or security testing tools or adapting an existing product test suite. It can also be done by hand.

Assessment can often be done with minimal effort using commonly available fuzzer or security testing tools or adapting an existing product test suite. It can also be done by hand.

Examples of each of the types of input:

  * calculation of memory accesses: length, index, hash table lookup values, packet reassembly
  * allocation of product resources: buffer length, number of packet descriptors, buffers for reassembly of fragmented packets, CPU-intensive cryptographic operations
  * incrementing or decrementing of internal counters: packet counters, event counters
  * creating or populating internal data structures: parameters for creating an array of packet descriptors

The list of inputs to test includes some types of input that may not exist or be possible to send. For example, if the maximum **valid** value is also the maximum **possible** value, then it is not possible to send the next value higher than the maximum value. These values do not need to be tested.

Secure design and development practices such as static analysis or secure compilation flags may assist in the fulfillment of this requirement by identifying potential sources of untrusted input for review, as well as automatically validating and mitigating invalid values.

Acceptable behaviors might include: