WAFEC_2_Alternatives


1.1 Alternative and Complementary Solutions

 

Evaluation guidelines: This section is descriptive in nature and is provided as background only.

 

As web application security is essentially a software quality problem, resolving it require fixing the way we design, develop, deploy and operate. It is important to note that this life cycle is more comprehensive than the development life cycle (usually referred to as SDLC) as it includes also deployment and operations. The web applications threats discussed in this document span both the development and operational parts of a system’s life cycle.

 

Ideally, fixing the security of web applications should be done at all stages since vulnerabilities are introduced in all stage (including operations) lower fixing cost and vulnerability exposure. That said, any engineering process leaves issues unresolved, either because they were not found or because their priority was not deemed high enough.

 

As a result, protecting a web application will require many complementary security controls, which address the different phases in a system’s life cycle, each one also compensating on issues remaining from earlier phases.

This section is structured along the different phases of an application life cycle, discussing the controls for each phase.

 

6.2.1 DESIGN

Not all vulnerabilities are implementation bugs. Some stems from the software architecture while others are a result of insecure requirements. An example of such a vulnerability is an insecure password reminder feature. A password reminder is a necessary feature required to lower support cost, yet it is very easy to design insecurely. Two common mistakes in a password reminder feature are:

 

Such vulnerabilities, often called "business logic" vulnerabilities, are very difficult to fix in later phases making it important to design for security in the first place. Since design is still a human faculty, secure design relies primarily on the expertise of the designers. One way to avoid business logic vulnerabilities is to use existing modules that have been implemented security rather than reinvent the wheel.

 

6.2.2 DEVELOPMENT

Many if not most application vulnerabilities are introduced during development. To ensure software is developed security, developers must be trained to develop secure software. However, developers’ training is seldom effective by itself:

 

Therefore a secure development program must include direct incentives for secure development as well as repeated training. In addition, introducing early security QA cycles, for example by performing static code analysis as part of the built cycle can enhance developers’ security awareness.

 

6.2.3 QUALITY ASSURANCE

A large chunk of software security resources is invested in the quality assurance phase. There are several methods to perform security quality assurance: it can be automated or manual and can inspect either the program code (static analysis) or run time environment. Based on those classifications, security quality assurance can be divided into:

 

Focusing on security quality assurance is a double edge sword. On the one hand, vulnerabilities are bugs, and QA teams are experienced in finding them. It is also a convenient phase to involve external security experts. On the other hand, security quality assurance requires a lot of manual work, even when automated, and therefore is expensive, relies heavily on the expertise of the performer and difficult to repeat for every change, which are quite common for web applications.

 

Another issue with security QA is that it only detects issues, but they still need to be remediated, usually by regressing to the development phase, a decision hard to make at the critical phases of a project.

 

6.2.4 OPERATIONS

While WAFs are the primary tools for protecting deployed web applications, it is important to mention few other important controls: