Formal Assessment of Nonfunctional Requirements and Software Assurance Policy

Software systems engineering processes separate requirements into two categories: functional and nonfunctional. Functional requirements are the specific things the system must do-it must correctly process a purchase transaction, for example. Software must be written to accomplish these functions. By contrast, nonfunctional requirements are characteristics of overall form, or attributes of behavior, that result from the way it is designed and built.

Security requirements are often classified as nonfunctional because they describe system characteristics and qualities rather than explicit functions.

Software assurance is often described as encompassing both the process to achieve confidence in software and the results of that process:

• As a process, it is the planned and systematic set of activities, processes, or steps used by an organization to gather data about the software in question, evaluate that data, and determine the overall quality of that software.
• As a result, software assurance expresses the confidence that stakeholders, systems owners, and users can have in that software's ability to fulfill their needs safely and securely.

This confidence is comparable to a warranty of fitness—it states to what degree, or within what limits, that the results of using that software can be relied on to be correct.

In this context, correctness refers to how well the software meets its stated functional requirements. Proactively addressing input data quality during the Requirements Analysis phase is important to ensuring the software not only performs as expected, but also delivers meaningful, reliable output that is fit for the intended business purpose.

Effective software security assessment and software quality assurance processes are commonly structured around well-defined workflows. Such workflows can cover any span of activities during any phase of the systems life cycle; they can and should reflect whether software and systems elements are built in-house, acquired as freeware, or licensed or purchased as commercial products. These workflows are also vital in managing security assessment testing, operational evaluation, regression testing, and ethical penetration testing activities.

Workflows that incorporate meaningful security metrics aligned with use cases can significantly enhance an organization's understanding of its application and related business process security posture.

Use cases are tangible outcomes of a program and can be useful in applications security testing. They provide standard benchmarks of security performance in known, well-understood situations. By measuring the quality of each use case, organizations can see how well the applications provide security.

It is imperative that all security assessment activities promptly provide effective feedback to stakeholders and users alike, whether the findings are positive or not. Positive results reassure everyone affected by a system that their trust in it is justified, and their efforts to keep it secure are having a payoff. Negative findings need to be promptly triaged to assess which of them need urgent action.

As with any other important security initiative, the organization needs to ensure that a well-documented, wellwritten, well-communicated, and well-understood policy and process is in place for software assurance.

Without the benefits of such a policy, the enterprise faces risks and dangers from acquiring and deploying software that is full of errors, exploitable vulnerabilities, or malicious software.