ANTECEDENTES

The process for converting constraints/assumptions into requirements is critical to the success of vulnerability prevention. If an issue in a constraint/assumption is not correctly addressed by a set of requirements then it could result in a vulnerability. The process provided in this section created the entire list of software security requirements listed in 3.3, and must be used if any future constraints/assumptions are discovered.

A correct requirement can only be generated from a constraint/assumption if the problem is properly understood. Therefore, an assumption is made about the level of knowledge of anyone using this process; a user of the process must have enough knowledge to design and implement code that will prevent the constraint/assumption from being violated.

The process for generating software security requirements begins with a constraint/as- sumption. The process for generating a constraint/assumption is not part of this work, and is described by Bazaz [13]. Then, each constraint/assumption is given to the following process for requirements generation:

(1) Determine how to violate the constraint/assumption. This step may seem

obvious, but determining the actual process to violate the constraint/assumption is harder once attempted. The step starts by taking an adversarial view of the con- straint/assumption. Then, a methodical approach that manipulates a process into an exploitable statement is produced. Multiple approaches to violating a constraint/as- sumption may exist, in which case each of the attack approaches must be outlined. For example, the assumption “The series of random data being produced by the PRNG is unpredictable (assuming unpredictable seed)” has scenarios in which it is violated by a process. A PRNG that is not cryptographically secure could be used by the process, the process could use the PRNG before seeding, the internal state of the PRNG could be leaked by the process, and/or the process could continue using the PRNG after an additional re-seeding is required.

(2) Determine the best method(s) to prevent the constraint/assumption from

being violated. The results from the previous step must now be analyzed to

determine how the exploit is prevented in software. While the entire attack path generated in the previous step is useful to gain a good working knowledge on the subject, the most important aspect is looking at how the constraint/assumption is actually violated. Then, a statement is created about what the process must accomplish to prevent the violation from occurring. At least one statement must exist from each attack path established in the previous step, or violation scenarios will go unmitigated.

Multiple statements may be required for a single attack path, because often times the method for preventing the violation will depend on the specific instance of a process in development. For example, proper data authentication can differ depending on whether the data is encrypted. Providing multiple prevention options

allows for more flexibility so a software security requirement is tailored to a projects needs. Prevention options are only available when there is no clear indication of which option is superior, and instead is solely a matter of discretion based on the project.

(3) Based on method(s) to prevent a constraint/assumption, develop a secu-

rity software requirement that is testable and verifiable. The most important

consideration in this step is ensuring that the requirement is clearly elucidating what the process must do, and what the process must not do. For example, “The process shall ensure that all addresses placed in a pointer variable are to memory locations other than its own” is specific, and clearly states what the process must do.

The next consideration is whether to group several of the prevention statements in the previous step, into a single requirement. Two cases will dictate the need for this, when the prevention statements must be done in a specific sequence, and when a prevention statement is a secondary issue caused by the misuse of another preven- tion statement. The best example of the second case is a requirement ensuring that a NIST approved encryption algorithm is used rather than a data obscurity algo- rithm. For an encryption algorithm to work, the key used for encryption must be kept a secret. Both of the prevention statements must be covered in a single require- ment, because the second prevention statement was caused by the first prevention statement of encrypting through a NIST approved algorithm.

The final consideration is whether the requirement is testable or verifiable. A requirement is testable if output by the software process can determine that the requirement was properly implemented, and is verifiable if correct usage of the re- quirement will provide a specific artifact in the design or implementation. If the requirement is neither, it must be scrapped, and the process must start from the beginning.

(4) Refine Requirement(s)The requirement must cover exactly the prevention method

from step 2, but no more, otherwise the requirement becomes less flexible. A good example is a memory allocation assumption, where a process may incorrectly assume that all memory allocation requests are successful. The requirements do not dictate how to check for a successful memory allocation, or what to do in the event of a failed memory allocation. But the requirement must cover the two methods that will prevent the assumption from being violated, checking for failed allocations, and only using memory that has been successfully allocated. Each requirement is scrutinized to ensure it succinctly covers the prevention statements while being flexible.

Once that is finished, any language in the requirement that connects it to a specific computer language or computer platform is removed so that the requirement is usable in any development scenario. Finally, the entire set of requirements is reviewed judiciously, to ensure that all the prevention statements from step 2 are correctly covered in the set of requirements generated for the constraint/assumption.

After the process has concluded on each constraint/assumption, the entire list of require- ments are reviewed. The review process will reveal issues that are the result of a process only concerning a single requirement at a time. In many cases the requirements will be the same for different constraints/assumptions, which is perfectly acceptable. The review process must be strict to catch any conflicting requirements, which must be addressed imme- diately. The situation is rare, and is the result of inflexible requirements. In those cases, the conflicting requirements are edited to remove the conflict while still maintaining the ability to prevent the constraint/assumption violations. The completed review provides an entire set of requirements ready to prevent all constraint/assumption violations.