Trust and Accountability

The development process should encourage the development and maintainability of trust and accountability within the organization. Trust can be defined as “Firm reliance on the integrity, ability, or character of a person or thing” [60]. It is the foundation for a good relationship because it realistically adds value to the communication that takes place in the relationship [110]. Kaplan’s reference to Gerick’s explanation of trust is that

“trust is not transitive, distributive, associative, or symmetric except in certain instances that are very narrowly defined” [110].

This information is of key importance to understanding the overall concept of trust.

Establishing trust is the heart of security for without trust you can not rely on the information that is presented. A major component in gaining trust is to manage risk and then to implement appropriate controls, educate employees and monitor effectiveness [110]. A tried and true approach to identifying risk is a risk assessment initiative. Trust should be identified in the risk assessment and mitigated in the design to establish and maintain trust. Since nothing is truly risk free, the goal is to mitigate the risk so that it is at an acceptable level. Therefore, the development process has to take risk into consideration. This is typically done via a risk analysis.

The earlier this is completed in the development process the better.

Accountability is critical to the enforcement of security. Individuals have to be successfully identified and authenticated in order to be held accountable for their actions through the use of logs and the effective implementation of access methodologies. The effective establishment of trust and realistic implementation of accountability controls should be visible within the organization’s security policy, the application’s design, coding practices, coding standards, application testing, and project feedback, as a project progresses through the application development life cycle.

5.5 Summary

The results from the Web survey have identified five Essential Elements that can be used in a Security Improvement Approach (SIA) and, optimally, should be examined prior to conducting a Security Improvement Initiative (SII) within an organization.

The five Essential Elements identified in this survey are as follows:

1. Web Application Development Methodology 2. Web Security Development Process Definition 3. End-User’s Feed Back

4. Implement & Test Disaster Recovery Plans 5. Job Related Impact

The basic idea is that there appears to be fundamental issues with industrial Web application development that need to be addressed. The survey indicates that the elements listed above appear to be problem areas and warrant additional research.

This does not mean that the list is exhaustive or conclusive or that these elements are mandatory for an organization to function. However, their presence will potentially improve the results of the SII and/or provide a less resistant path to identified areas that need improvement. This information can also be utilized to help critique security identifying potential problem areas in a SII that is currently being executed. Once the foundational issues for conducting a SIA have been established, the next step examined where security practices have been effectively applied in a large organization.

The Global Fortune 500 financial organization demonstrates a lack of security integration in the application development process. This lack of integration is supported through deficient security discussion in the beginning of the development process, a lack of encouragement for re-usable components, a lack of follow-up after design approval, and a lack of employee understanding of the role security plays in the application development process. The results also indicate that there is a gap between the application development process and the implementation of security from an end-to-end perspective. Therefore, it is vital to develop a security process that addresses security issues throughout the entire process. Empirical evidence from the organizational survey coupled with relevant literature supports the identification of six Security Criteria for Web Application Development (SCWAD):

1. Active organizational support for security in the Web development process 2. Proper Security Controls in the development environment

3. Security visibility throughout all areas of the development process

4. Delivery of a cohesive system, integrating business requirements, software and security

5. Prompt, rigorous testing and evaluation 6. Trust and Accountability

SCWAD provides an avenue for assessing existing Web Engineering processes and a guide to future Security Improvement Approaches and Initiatives. The next chapter examines SCWAD in conjunction with Web Engineering processes and security processes.

6 Security Criteria for Web Application Development (SCWAD) Analysis

The objective of this chapter is to evaluate existing application development processes and security processes used in Web engineering via the Security Criteria for Web Application Development (SCWAD). Therefore, this chapter is based on a critical literature review that examines popular Web engineering processes and security processes assessing their compatibility with the SCWAD.

The point of this chapter is not to provide an exhaustive evaluation or to argue the validity of either Web engineering development processes or security methodologies.

The purpose of this analysis is to examine popular Web application development processes and security processes from the SCWAD perspective. The analysis at this stage of the dissertation will also assist with future process discussion throughout the remainder of the dissertation. The Web engineering processes that were chosen include both agile and traditional software engineering processes. The reason for this is twofold. First, it demonstrates that the criteria are applicable to both traditional and agile engineering approaches. Secondly, and more importantly, the Web survey discussed in chapter five indicates that both approaches to Web engineering are used in industry.

SCWAD identifies six criteria which were discussed in detail in chapter five. The rating of the various methodologies is examined from the perspective of:

• None – no direct reference was determined from the materials

• Weak – minimal indication of applicability

• Partial – indicates that there was some evidence of applicability

• Strong - clear support for the criteria.

The criteria are summarized in Table 12 - Security Criteria for Web Application Development (SCWAD).

Table 12 - Security Criteria for Web Application Development (SCWAD) No. Security Criteria for Web Application Development (SCWAD)

1 Active organizational support for security in the Web development process 2 Proper Security Controls in the development environment

3 Security visibility throughout all areas of the development process

4 Delivery of a cohesive system, integrating business requirements, software & security 5 Prompt, rigorous security testing and evaluation

6 Trust and Accountability

There are several methodologies that can be used in Web application development.

These include both traditional plan driven approaches and agile approaches. Figure 1 – Process Positions on the Web Engineering Process Spectrum presents the spectrum of Web engineering application development methodologies that are discussed in this chapter. The methodologies were chosen for discussion in this chapter for two reasons. The first reason is that they provide a good representation of methodologies

across the broad spectrum. The second reason is that they are reasonably popular in industry. The chapter briefly describes the individual processes displayed in Figure 1 - Process Positions on the Web Engineering Process Spectrum along with ranking them according to SCWAD. Section 6.1 examines plan driven processes. Section 6.2 inspects agile process. Section 6.3 looks at security methodologies and section 6.4 provides a summary of the chapter.

Figure 1 - Process Positions on the Web Engineering Process Spectrum