Web Engineering Security (WES) Process

Web Engineering Security (WES) Process

William Bradley Glisson and Ray Welland

Department of Computing Science, University of Glasgow, Glasgow, Scotland. G12 8QQ William Brad Glisson Page 1 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

Abstract This document explains the Web Engineering Security (WES) process for the construction of secure Web based application development projects. WES is a process neutral methodology that has been developed to address specific development issues: • • • • • •

Active organizational support for security in the Web development process Proper Controls in the development environment Security visibility throughout all areas of the development process Delivery of a cohesive system, integrating business requirements, software and security Prompt, rigorous testing and evaluation Trust and Accountability [39].

In addition, WES supports the implementation of an Application Development Methodology, a clear Web Security Development Process Definition, the acquisition of End-Users Feed Back, the Implementation & Testing of Disaster Recovery Plans, and putting into effect a Job Related Impact scheme for secure application development[41]. The identification of the project’s risk to the business, specific application security requirements, secure design and coding standards, controlled implementations and rigorous security testing practices, encourages a development environment conducive to creating and delivering increasingly secure Web applications that satisfy the needs of the end-user. Who in our global web enabled environment provides the ultimate decree on the triumph of an applications practical utilization of security.

William Brad Glisson Page 2 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

Foreword The objective of the following technical report is to present the Web Engineering Security (WES) methodology to a wider audience. Five conference papers contributed to the body of this report. The papers include: ¾ Web Development Evolution: The Assimilation of Web Engineering Security published in the 3rd Latin American Web Congress. 2005. Buenos Aires - Argentina ¾ Web Development Evolution: The Business Perspective on Security published in the Thirty-Fifth Annual Western Decision Sciences Institute (WDSI) 2006. Hawaii ¾ Web Engineering Security: A Practitioner’s Perspective published in the International Conference on Web Engineering (ICWE) 2006. Palo Alto, California ¾ Web Engineering Security: Essential Element published in the Second International Conference on Availability, Reliability and Security (ARES) 2007. Vienna, Austria. ¾ Secure Web Application Development and Global Regulation in the Second International Conference on Availability, Reliability and Security (ARES) 2007. Vienna, Austria. We also hope that other research groups will carry out experiments testing the validity of the WES methodology in industry.


Table of Contents 1.

Introduction..................................................................................................................................... 8

2.

What is the Business Incentive? .................................................................................................. 9 2.1 US Legislation....................................................................................................................... 11 2.2 US Legislation with International Impact ........................................................................... 12 2.3 UK Legal Issues .................................................................................................................... 13 2.4 International Legal Forum.................................................................................................... 15 2.5 Legal & Social Effect ............................................................................................................ 15 2.6 What is the Definition of Security? ..................................................................................... 16 2.7 What are the Effects on the Business Strategy? .............................................................. 17

3.

What is Web Engineering Security?........................................................................................... 19 3.1 Why a Web Engineering Security (WES) Methodology? .................................................. 19 3.2 Why a Process Neutral Approach?..................................................................................... 19

4.

WES Essential Elements ............................................................................................................. 21 4.1 Web Application Development Methodology .................................................................... 21 4.2 Web Security Development Process Definition................................................................. 21 4.3 End-User’s Feed Back.......................................................................................................... 21 4.4 Implement & Test Disaster Recovery Plans....................................................................... 22 4.5 Job Related Impact............................................................................................................... 22

5.

WES Foundation Principles ........................................................................................................ 23 5.1 Security Education ............................................................................................................... 23 5.2 Good Communication .......................................................................................................... 24 5.2.1 Development Team Communication........................................................................ 24 5.2.2 End-User Communication ......................................................................................... 25 5.3 Cultural Support ................................................................................................................... 26 5.4 Security (Cultural Support, Security Education and Good Communication)................. 26

6.

The WES Process Life Cycle....................................................................................................... 29 6.1 Project Development Risk Assessment ............................................................................. 31 6.2 Application Security Requirements.................................................................................... 32 6.2.1 Security Policy ........................................................................................................... 32 6.2.2 Corporate Culture ...................................................................................................... 34 6.2.3 Technology Compatibility ......................................................................................... 35 6.2.4 Security and the Human Element............................................................................. 36 6.3 Security Design / Coding ..................................................................................................... 36 6.4 Controlled Environment Implementation ........................................................................... 38 6.5 Security Testing.................................................................................................................... 38 6.6 Implementation into Production ......................................................................................... 40 6.7 End-User Feed Back............................................................................................................. 41

7.

Stakeholders ................................................................................................................................. 42

8.

Deliverables .................................................................................................................................. 43 William Brad Glisson Page 4 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

9.

Expected Effect............................................................................................................................. 44 9.1 Upfront Integration of Security ........................................................................................... 44 9.2 Security Comprehensiveness ............................................................................................. 44 9.3 Structured Security Implementation................................................................................... 44 9.4 Industrial Practicality ........................................................................................................... 44

10. Acknowledgements...................................................................................................................... 46 11. References .................................................................................................................................... 47


Figures Figure 1 - Principles.................................................................................................................23 Figure 2- WES Methodology...................................................................................................30


Tables Table 1 - Terms........................................................................................................................33 Table 2 - Legislative Guidance ................................................................................................34 Table 3 - Top Vulnerabilities in Web Applications.................................................................39


1. Introduction Current web applications face major security problems because security design is not integrated into the Web Engineering Development Process. Security needs to be built into the application design up-front by explicitly stating the security approach in the development methodology. This security integration into the software design process should take place through the implementation of an independent flexible Web Engineering Security (WES) methodology. Failure to fully integrate the security design into the application design process creates an environment that is conducive to cyber security breaches. Exploitation of these breaches translates into staggering corporate financial losses. The financial losses and trends are visible in the CSI/FBI, Deloitte, and PricewaterhouseCoopers surveys[17, 18, 42, 43, 82]. It can no longer be assumed that security will be addressed in the acquisition of the functional or non-functional requirements. These surveys indicate that there are fundamental security problems with the methodologies being used in real world web application development. Security should be designed into the development process up-front and revisited throughout the entire development process[81]. This brings up the next logical question – what is a secure application? “A secure application is well designed, well managed, well reviewed” from an application development standpoint, and “well maintained” throughout the product life cycle[29]. So how do we encourage security of the application throughout a methodology and what is the business incentive to do so? This report proposes a solution to the current security development issue through the integration of the Web Engineering Security (WES) methodology into the Web Engineering development process.


2. What is the Business Incentive? As discussed in the paper presented at the Thirty-Fifth Annual Western Decision Sciences Institute[36], some of the most precious commodities in today’s business environment include data, information and knowledge. Management of the data asset is becoming increasingly challenging as the world progressively utilizes the World Wide Web to conduct business. It has been said that “one man’s data can be another man’s knowledge, and vice versa, depending on context”[87]. Once data is collected, through a Web enabled application, then the challenge morphs into information and knowledge management as businesses take advantage of internets, intranets, extranets, and wireless connections to their networks. As Ralph Basham, the Director of the Secret Service put it "Information is the world's new currency; information has value"[45]. This point was reinforced by Thomas A. Stewart when he wrote in The Wealth of Knowledge “Knowledge is what we buy, sell, and do”[87]. “Knowledge management involves capturing, classifying, evaluating, retrieving and sharing all of a company’s information assets in a way that provides context for effective decisions and actions”[27]. As strategic alliances and partnerships develop, it will become increasingly necessary for a company’s information and knowledge to be available to all parties in the appropriate forms, at the appropriate place and time[27]. The main conduit for this transfer of knowledge, information and data is the Web. A major management issue that has become increasingly visible in today’s Web market place is the security of an organization’s data, information, and knowledge assets. Security failures cost companies staggering amounts of money and have become a global epidemic that affects everyone in the world of e-business. There are several factors that contribute to an organization’s security cost. The cost associated with application development is one of those factors. An article published in Secure Business Quarterly titled “Tangible ROI through Secure Software Engineering” (Fourth Quarter of 2001) states that “one dollar required to resolve an issue during the design phase grows into 60 to 100 dollars to resolve the same issue after the application has shipped”[51]. They also indicate that the return on investment (ROI) can be as high as 21 percent when examined during the design phase[51]. Even if the security flaw is not caught until the test phase, Gartner estimates that the cost to fix a “security vulnerability during testing to be less than 2 percent of the cost of removing it from a production system”[77]. The 2004 CSI/FBI Computer Crime and Security Survey estimates losses from internet security breaches in the US to have exceeded $141 million within the last year[42]. The PricewaterhouseCoopers (PWC) information security breaches survey estimates that the average cost, for a large company’s most serious security breach, is around $220 thousand[82, 93]. The survey indicates that organizations experience an average of fifteen breaches per year[82]. It also estimates that one-third of the breaches are serious breaches involving significant cost[82]. The PWC survey also indicates that security problems are on the rise in the United Kingdom and that malicious attacks are the primary culprits[82]. A deeper analysis of the surveys indicates that Internet probing is significantly increasing [82]. It also indicates that there are problems with web site defacement, misuse of public web applications, unauthorized access, insider net abuse, denial of service attacks and viruses[42]. This information demonstrates that there are individuals actively looking for software vulnerabilities on the web.


This point is reinforced by testimony from Robert F. Decay, Director, Information Security Issues indicating that patch management is critical in mitigating cyber vulnerabilities[15]. According to the same report, the number of security vulnerabilities reported is increasing and attacks are becoming automated[15]. Software security encompasses more than encryption and password maintenance. The ability to defend against software attacks, in the long run, will need to come from “more rigorous software engineering practices, better tools and technologies”[15]. According to Deloitte & Touche’s 2004 Global Security Survey, the number of systems being compromised in the financial sector is on the rise and attacks are on the increase[17, 19]. Now, either more companies are being more forthcoming with information, or more systems are being compromised, or possibly both. The truth of the matter is that we really do not know the exact number of systems that are truly being compromised. Most companies do not want this information made public for a variety of reasons. For example, they do not want to admit, from a reputation standpoint, that their systems have been compromised; they do not want to endure the expense necessary to rectify the problem; they do not know how to fix the problem or, even worse, they are not even aware that their systems have been compromised. These issues can be summarized in terms of the economical cost. Since bad news sells in today’s press environment, companies do not want to sustain damage to their reputations or lose public good-will which would translate into soft cost. Soft cost, also referred to in the accounting profession as indirect cost, in this instance refers to costs that are hard to quantify economically.[107] In opposition, hard cost, also referred to in the accounting profession as direct cost, refers to cost that are easily quantifiable[107]. There is some research that provides validity to company fears in terms of hard cost i.e., stock price. Telang and Wattal’s research indicates that a software vendor loses, on average, approximately 0.6% of their stock price per vulnerability announcement[89]. Granted, there appears to be a lot of contributing factors in their calculation of the estimated stock hit per vulnerability announcement. Those factors included whether the vulnerability announcement comes from the vendor or the press, if there is a patch currently available, the type of breach, and the extent of market competition[89]. The point is not to argue the economic validity of their findings but to note that there appears to be a connection between security announcements and company profitability. It is only when their security issues start to seriously interrupt business or application functionality that they will admit to having a problem. Another possible reason for not wanting to admit to security breaches on the Internet is to minimize the chance of copy cat attacks on their systems until the issue has been resolved and patched. The e-commerce environment is not the only area that is beginning to feel the presence of security issues. Several articles have been published in the Chronicle of Higher Education citing problems that U.S. academic institutions have been experiencing and their solutions. These resolutions range from technical solutions, to the adoption of tighter computer policies, to the creation of new positions such as a Chief Information Officer (CIO)[28, 56, 83]. The CIO identifies a single individual who is responsible for the overall welfare of the organization’s information. This individual is responsible for the security policy, standards and practices within the organization.


As the World Wide Web continues to become an integral part of everyday life, the demands for secure web applications in the business world will continue to grow. This societal pressure is being felt in the corporate environment through U.S. legislation.

2.1 US Legislation As discussed in the paper presented at the 2007 Second International Conference on Availability, Reliability and Security (ARES) [34], legislation exists in the US on both the Federal and the State levels. Since there are fifty states, covering the impact of all of individual state legislation is beyond the scope of this research. However, the existence of the legislation needs to be acknowledged. An example of state legislation is the Minnesota Security Brach Disclosure Act. This act requires business to contact individuals when their personal data has been released to unauthorized parties due to a security breach[91]. Federal level executive orders / legislation that have affected the computer industry include the following: • •

• • • • •

Electronic Communications Privacy Act - provided some of the foundations for investigating computer crimes[70]. Federal Information Security Act (FISA) of 2002 - “requires each agency to inventory its major computer systems, to identify and provide appropriate security protections, and to develop, document, and implement an agency-wide information security program”[70]. Executive order - National Strategy to Secure Cyberspace - makes recommendation to network operators[70]. Homeland Security Act of 2002 - provides authority to the Secretary of Homeland Security to develop Information systems to encourage the storage, analysis and exchange of information[70]. Homeland Security Presidential Directive No. 7 (HSPD-7) - stresses the improvement of protecting US critical infrastructure[70]. Cyber Security Research and Development Act - authorized the National Science Foundation to award funding for computer security related activities[70] Check Clearing for the 21st Century Act - enables banks to process checks electronically and provide substitute checks to customers[103].

As discussed in the Web Development Evolution: The Business Perspective on Security [36], societal pressure is encouraging the development of U.S. legislation. This legislation includes: • • • • • • •

The Economic Espionage Act of 1996 (EEA) The Health Insurance Portability and Accountability Act of 1996 (HIPAA) The Graham-Leach-Bliley Act of 1999 The Sarbanes-Oxley Act which was passed into law in July of 2002[113] The Fair and Accurate Credit Transaction Act of 2003 The Family Rights and Privacy Act (FERPA) Identity Theft Penalty Enhancement Act of 2004.

The EEA was the first law that explicitly makes the theft of commercial trade secrets a federal crime[20, 36, 50]. The Act defined information in very broad terms which includes William Brad Glisson Page 11 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

storage of information in intangible forms like that of a document on a computer[20, 36]. The EEA was liberal in how it defined “the phrase ‘obtaining information’ which includes merely reading it”[20, 36]. Possible penalties for violating the EEA range from fines, to imprisonment, to forfeiture of any property used to commit or facilitate the crime[11, 36, 50]. HIPAA is concerned with disclosure and transmission of healthcare information[13]. The Graham-Leach-Bliley Act focuses on how financial organizations use and distribute a customer’s personal information[36, 47]. The Sarbanes-Oxley (SOX) Act was designed to help restore confidence in publicly traded financial companies by making the chief executive officers and chief financial officers personally responsible for validating financial information[36, 53]. However, the wording in the law has a broader reach than just the financial industry. The law (Sarbanes-Oxley) states that company CEOs and CFOs establish and maintain proper “internal controls”[36, 53, 113]. This means that by signing off on the validity of the data within the system they are also signing off on its security[36, 53]. It is important to note that this is only applicable in situations where the data can have a material impact on the organization’s financial results[113]. FERPA protects the privacy of student records[102] and The Identity Theft Penalty Enhancement Act introduces stricter penalties for identity theft[71]. The legislative story continues to evolve. A ninety-one page bill was introduced in the Senate by Senator Patrick Leahy and Senator Arlen Specter[64]. The proposal is an aggressive “regulation-oriented” bill containing “an avalanche of new rules for corporate data security and stiff penalties for information burglars”[64]. The motivation for the legislation is the result of a series of high profile security problems[64].

2.2 US Legislation with International Impact It should be noted that the SOX Act has an international impact. “It is significant to note that – in contrast to the traditional accommodation provided under the Securities Exchange Commission (SEC) and national exchange rules for listed non-U.S. companies – the requirements of the Act apply to all foreign private issuers: • • •

that have securities, including American Depositary Receipts (“ADRs”), registered under section 12 of the Securities Exchange Act of 1934; that are required to file reports under section 13(a) or 15(d) of the Securities Exchange Act (including all European companies filing Form 20-F); or that have filed a registration statement that has not yet become effective (under the Securities Act of 1933) and that have not been withdrawn”[63].

This translates into the Act being applicable to non-US companies that are registered with the SEC with a few exceptions. Other acts that have international impact include: • • •

Electronic Signatures Act - grants electronic contracts the same weight as paper contracts[104]. The Computer Fraud Act of 1984 - dealt with computer violations to government computers[114]. The National Information Infrastructure Protection Act of 1996 amended the Computer Fraud Act of 1986 [101] - expanded the legal reach to include non-


• •

government computers making unauthorized access to computer, not in the same state, a federal crime[114]. The USA Patriot Act of 2001 - greatly expands the US government’s capabilities to legally intercept a multitude of communications including communications relating to computer fraud and abuse[80]. The US Safe Harbor Act - an agreement that allows US companies conducting business in the EU to conform to EU data protection laws[86].

2.3 UK Legal Issues The purpose of this section is to acknowledge the legal pressures that are mounting through the introduction of legislation throughout the world in response to computer crimes and acknowledge the importance of a stable cyber space. Cyber legislation still has many problems to address that include the common definitions on computer crimes, international relations, sovereignty and jurisdiction[109]. To win the war on cyber crime legislation must not only be enacted but enforced as well. Enforcement of legislation in computer crimes is very difficult due to an array of factors that include anonymity, global reach through multiple jurisdictions, and the retention and preservation of evidence[58]. Additional factors include resources, technical knowledge, and the speed at which technology develops on the web, coupled with the need to counteract emerging problems[66]. The authorities need to have the resources to pursue cyber crimes; they need to have the employees with the proper technical knowledge to work on the cases and to ensure the accuracy of the data that is being presented in courts. A classic example is a breached server. Standard server activity includes log updates like access logs, error logs, and script logs. The logs are being modified via the system as it supports its everyday functions. As a general rule, courts do not like modified evidence. If the server modified the evidence the logical question that follows this line of thought is did the intruder alter the logs during the breach? In addition to these concerns, there is the need for properly trained professionals to capture this information without alteration or destruction and reasonably quickly from the time of the security breach. All of these issues from both the legislative and the enforcement perspective affect the ability of a government to prosecute computer crimes. The cyber community is international by the very nature of the net. Hence, cyber crime is an international issue that affects all cyber citizens. This means that the US is not the only country that is concerned with cyber crime. Several countries have created legislation to address issues that have developed though the expansion of the net. Some of the legislation for forty-four different countries is listed in a report by Stein Schjolberg[85]. The United Kingdom laws that have impacted technology include the following: • • • • • • • •

The Theft Act 1968 - applicable to fraud The Forgery and Counterfeiting Act 1981 - applicable to obscene materials The Criminal Damage Act 1977 - applicable to physical damage of computers The Protection of Children Act 1978 - applicable to child pornography The Telecommunications Act 1984 The Public Order Act 1986 - applicable to racist materials The Criminal Justice Act 1988 The Malicious Communications Act 1988 [98]


• • • • • • • •

The Copyright, Designs and Patents Act 1988 The Computer Misuse Act of 1990 The Criminal Justice and Public Order Act 1994 The Data Protection Act of 1998 Regulation of Investigatory Powers Act(RIP) 2000 [99] Electronic Communications Act 2000 [96] The Telecommunications Regulations 2000 [100] The Electronic Signatures Regulations 2002 [97].

Several of the Acts listed above are mentioned on the Civil Society Internet Rights project Web page[10]. All of the Acts listed above have influenced the application legality of Information Communication Technology. Four commonly examined laws when discussing computer crimes and the World Wide Web include: • • • •

The Telecommunications Act 1984 The Computer Misuse Act of 1990 The Data Protection Act of 1998 Regulation of Investigatory Powers Act (RIP) 2000.

The Telecommunications Act makes it a criminal act to transmit obscene materials via a telecommunications network or to deceive a licensed telecommunications service. The Act defines a telecommunication network broadly enough to include internet traffic[69]. In August of 1990, the Computer Misuse Act became law in the United Kingdom. The Act is concerned with three specific offences that include: • • •

Unauthorised access to computer material Unauthorised access with intent to commit or facilitate commission of further offences Unauthorised modification of computer material[94].

As with any act there are always possibilities for amendments. Tom Harris has proposed an amendment to The Computer Misuse Act of 1990 that would clearly criminalise all forms of interference with computer systems and significantly lengthening the maximum imprisonment terms for offences for unauthorized access and unauthorized modification [9]. The idea is to use the increased prison times as a deterrent for future crimes[9] and increase extradition for violations of the law[61]. The reasoning behind the need to increase the prison time is to bring into line prison terms with that of other countries that were part of the Convention of Cyber-crime and make the crime serious enough to warrant extradition[110]. The Data Protection Act specifically addresses offences concerned with unauthorised procurement and / or processing of data[69]. An interesting point in the Data Protection Act is where a proven offence has taken place and the wording referencing the liability within corporate bodies in section sixty-one which states that “any person who was purporting to act in any such capacity, he as well as the body corporate shall be guilty of that offence and be liable to be proceeded against and punished accordingly”[95].


The Regulation of Investigatory Powers Act (RIP) 2000 deals with two major points. These points include the interception of data and the relinquishing of encryption keys. This means that the UK government can compel Internet Service Providers (ISP) to copy its traffic and divert this information to a government location for analysis. It also means that individuals holding encryption keys can be subject to prosecution for non-disclosure and for notifying any one that they have been served with a disclosure notice[46, 69, 99].

2.4 International Legal Forum The importance of cyber space is voiced in the US report The National Strategy to Secure Cyberspace via the statement that, in regards to the nation’s critical infrastructure, “Cyberspace is their nervous system — the control system of our country” and that “the healthy functioning of cyberspace is essential to our economy and our national security”[106]. International support for this perspective is visible through efforts attempting to address computer crime which include agreements by the G8 nations [57], the Mutual Legal Assistance Treaties (MILAT)[105], the European Union border controls (Interpol) and United Nations (UN) recommendations[12, 48]. A major event taken on the international level occurred on November of 2001 when twentytwo European countries along with Japan, Canada, South Africa and the US signed the Cyber-crime treaty[78] also referenced as the Convention on Cyber-crime. The treaty is unique in that it is “the first international treaty on crimes committed via the Internet and other computer networks”[14]. The treaty "addresses an important problem: the difficulties law enforcement has in purs(u)ing criminals across national borders, something that is common in Internet crime"[60]. The Cybercrime treaty was put into force in July of 2004 (which required five ratifications including a minimum of three member countries) and address activities like “infringements of copyright, computer-related fraud, child pornography and violations of network security”[14]. Since then it has been amended to include “an Additional Protocol making any publication of racist and xenophobic propaganda via computer networks a criminal offence”[14]. Realistically, this means that “the Convention addresses issues of substantive and procedural criminal law, which member states are obliged to take measures to implement in national law, as well as issues of international cooperation”[110]. Along with international efforts to address cyber-crime governance there are several organizations that attempt to track and provide assistance with computer crime issues. These organizations include the Computer Emergency Response Team (CERT) at Carnegie Mellon, the Center for Education and Research in Information Assurance and Security (CERIAS) at Purdue University, the Computer Incident Advisory Capability (CIAC) with the US Department of Energy, BugTraq which provides information on security vulnerabilities[48] and the Computer Crime Research Center.

2.5 Legal & Social Effect As pressure continues to escalate, in reference to application security through legislation and dissatisfied customers, not following a web application development methodology that specifically addresses security is an expensive and dangerous strategy for any business. Outside research indicates that it is cost effective to address security flaws during development [51]. In theory, the implementation of WES should translate into a higher return on investment (ROI) for the company and help improve application and application feature


time-to-market through constant and consistent security testing during application development. The implementation of security during the development process should positively impact application maintenance as well as helping to improve the overall profit for the organization. Security, from a business point of view, has become a critical issue in today’s web enabled society. The question is not whether an attack will happen to an organization’s web site, but when, and how will it be handled? The best approach to security, from a web development point of view, is to address security issues upfront in the design of the web application, mitigating both soft and hard costs. This naturally opens the door to question the definition of a secure system. The initial problem with tackling security is the terminology. Terminology in various environments has the potential to have multiple meanings. As Anderson indicated, reality is a complex environment in the real world[3]. Hence, what the terms security and vulnerabilities mean to one organization, such as a large financial institution, may or may not have the same relevance to another organization, such as a news agent or a small law firm. Logically, different organizations will require “some combination of user authentication, transaction integrity and accountability, fault-tolerance, message secrecy and covertness”[3]. So what is the definition of security?

2.6 What is the Definition of Security? For the purposes of this dialogue we will define a secure system in terms of confidentiality, integrity and availability. The system should protect confidentiality by limiting admission to the appropriate individuals[78]. The integrity of the system should be maintained by only allowing modifications to be conducted by the appropriate individuals and within established guidelines[78]. The availability of the system is defined by providing access to the appropriate parties at designated times[78]. The Organization for Internet Safety (OIS) publishes Guidelines for Security Vulnerabilities Reporting and Response. In this document they define a security vulnerability as “a flaw within a software system that can cause it to work contrary to its documented design and could be exploited to cause the system to violate its documented security policy”[73]. Hence, any flaws in the system design or application coding can potentially lead to security vulnerabilities. Using these broad definitions to understand security supports the idea that security means more than implementing encryption, Secure Socket Layer (SSL), and firewalls. It also means more than creating and maintaining secure networks, the use of digital certificates, and the different technologies used for authentication and authorization or intrusion detection systems[23, 25]. In-depth discussions on these topics and research into their improvements are occurring on a daily basis. However, a system’s security is not determined solely by the technology that is implemented. A secure system to one organization may not meet another organization’s definition of security. The definition of a secure system to a large financial organization will differ from that of a small local business, such as a law firm’s web site. The decision that an organization has to address is how much risk is it willing to accept and at what financial cost. The policy,


procedures, standards, and technical controls that are developed and implemented will define the systems confidentiality, integrity and availability. This collaborative approach defines the overall security of the system within a business. The new focus on security through legislation, which is forcing accountability and responsibility, is encouraging security to become a major factor in the new evolution of the business strategy. This overall change in the business strategy can even be seen within Microsoft when Bill Gates announced the corporate shift towards “Trustworthy Computing” in January of 2002[52]. This business strategy interaction will continually need to be accounted for in the development of new applications. As Alan Zeichick, Conference Chairman of the Software Security Summit, phrased it, "Software is vulnerable! Enterprises have spent millions of dollars installing network firewalls and Virtual Private Networks, but the real danger is in poorly written applications”[7].

2.7 What are the Effects on the Business Strategy? Due to the obvious cost advantages, the legislative pressure, pressure from news organizations, and demand from the customer, security is evolving into an issue that needs to be addressed in an organization’s business strategy. The business strategy encompasses all of the information about the overall business that ranges from defining the scope of the business, to establishing the business models, to broad marketing strategies, to the establishment of processes and policies, to the acquisition and distribution of information and to the overall approach to technology within the organization[32]. Business strategy can be examined from the corporate, the business, and the operational point of view[55]. The corporate level strategy is the high level strategy that details the organization’s purpose and scope[55]. The business level strategy deals with the competition in individual markets including market segmentation, market positioning, industry analysis, and brand value[55]. The operational strategy is concerned with the implementation aspect of the business which would include optimising web site design, hardware requirements and utilization and software requirements[55]. Legal pressure is pushing security up to the corporate strategy level. Chief Executive Officers and Chief financial Officers are potentially being held accountable for the security of their applications. From a corporate perspective, this provides a champion. Champions are critical in the corporate environment in order to implement and sustain corporate cultural changes. Realistically, high level champions within the organization are more likely to succeed in changing and sustaining changes to corporate cultures. From a corporate perspective, security needs to be viewed as a collective organizational problem. Increased security should translate into increased communication among co-workers. Increased communication should facilitate a more in-depth understanding of the business which contributes to a better working environment, ultimately affecting the organization’s bottom line. From a business strategy standpoint, companies on the web need to understand that the web site is their front door to the world. They need to strive to develop brand awareness, creative marketing advertisements, and develop an environment that capitalizes on the customer’s experience. The customer will make decisions about repeat business with a company based on their total experience. This includes, as Rick Freedman put it, “Delivering on the Click”[32]. Companies have to outline the performance standards that they are going to


provide and follow through with an effective, efficient and secure value chain while providing appropriate customer service capabilities. This basically follows the old adage “Say what you are going to do and do what you said”! Always remembering that competitors are only a click away! If customers perceive that their data is not safe and secure, this can result in lost customers, lost future revenue, lost market advantage and possibly monetary reparation. The tightly integrated web theory does place a great deal of power in the hands of the customer from a business model point of view[27]. “Overall, the business environment continues to become more inter-connected. Traditional boundaries between organizations are eroding”[82]. A customer logs onto a web site and places an order for one widget. Real time update notifies the supplier and updates his inventory; the supplier’s system then updates the manufacturer’s system, and the manufacturer’s system then updates the raw material supplier’s system. This gives everyone in the supply chain the ability to adjust their inventories very quickly in response to demand which, in turn, severely reduces costs. This tight integration, from a security view point, opens the door to a multitude of problems if an attack is successful in compromising one of the linked systems. On the other hand, as organizations become compliant, there will undoubtedly be attempts to market this value added position. An in-depth examination of the effects of security on the individual components of an organization’s business model is out of the scope of this paper. The purpose of this section is to acknowledge the fact that pressure from legislation, competitors, the press and customers will force organizations to acknowledge security as part of the business strategy. If it appeared at all, security would have traditionally fallen under the operational strategy. Unfortunately, there appears to be a lack of understanding on how to protect application code as it is developed[59]. A recent survey conducted by BZ Research substantiates this idea. Of the BZ survey respondents, “55.9 percent blamed poor programming practices” for the number of vulnerabilities in software applications[115]. The next logical question is: how does a business protect itself and capitalize on software application development in order to gain a competitive advantage for their business. A possible solution, to security issues during application development, is the integration of a process neutral Web Engineering Security (WES) methodology with customizable components.


3. What is Web Engineering Security? Competitive market pressure is forcing businesses to improve application functionality and time-to-market in the web development environment. This atmosphere has encouraged research in development methodologies in the area of Web Engineering. Web Engineering is: “the application of systematic, disciplined and quantifiable approaches to development, operation, and maintenance of Web-based applications”[21, 22]. Security is inherently not a part of ‘Vanilla - Off the Shelf’ Web engineering development processes and this inherent lack of security encourages environments that are susceptible to exploitation via potential breaches[40]. Web Engineering methodologies do not make any direct references to security, hence today’s web applications face major security problems[38]. Therefore, Web Engineering Security is the systematic, disciplined and quantifiable amalgamation of security with a Web-based application development process.

3.1 Why a Web Engineering Security (WES) Methodology? A specific methodology provides a road map for developers and management to follow during a Web-based application development project. The methodology attempts to provide guidance for all of the various aspects of security during the individual stages of the application development process. As discussed in section two, business needs support research in this area. In order to allow organizations to preserve and capitalize on existing Web application development capabilities and possible market advantages, a process neutral approach was selected.

3.2 Why a Process Neutral Approach? A process neutral approach to the implementation of security is based on the fact that organizations in industry use a variety of methodologies during their Web application development projects [39, 41]. This variety ranges from the traditional water fall approach, or some variant there of, to completely agile approaches in order to support Web application development. A process neutral approach provides an organization with the opportunity to support its existing Web application development methodology regardless of the style of the methodology. The process neutral approach provides a roadmap for organizations that are using a more traditional methodology for Web application development from a deliverable perspective. The amount of deliverables that an organization will require depends on the culture of the organization, the methodology that the culture is comfortable with implementing, and, to a large extent, the regulatory impact on the business. Businesses that are more conservative in nature and under a large amount of regulation, such as a large financial institution, are going to require deliverables at every stage of the development process. While smaller businesses are more inclined to be agile in nature and require few deliverables during each stage of the development process. WES supports agile methodologies as well. The Agile community’s manifesto states that: William Brad Glisson Page 19 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

"We are uncovering better ways of developing software by doing it and helping others do it. We value: • Individuals and interactions over processes and tools. • Working software over comprehensive documentation. • Customer collaboration over contract negotiation. • Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more"[30]. Personal experience has shown that the direct contributions of individuals involved in Web development projects provide the fundamental ingredients for a project’s ultimate success or failure. This is especially true in the security arena. Methodologies are defined as “A body of practices, procedures, and rules used by those who work in a discipline”[90]. Hence, the methodology should support the individuals involved in the development process by providing guidance so that the end product is a secure Web application, while meeting the needs of the customer / business. This necessity for versatility requires a process neutral approach in order to allow appropriate customization while meeting the needs of the individual stakeholder groups. However, there is no “silver bullet” [31], no magic spell or FEL solution (Fairies, Elves and Leprechauns) available to solve you application development security problems. However, a security methodology designed for World Wide Web application development provides guidance and support to the individuals working on Web projects.


4. WES Essential Elements There are five essential elements that define the scope of WES. The existence of the essential elements is required before undertaking a Security Improvement Initiative (SII) with WES. The establishment of the essential elements helps to alleviate terminology ambiguity and ensures that the organization has already established certain fundamental capabilities. These elements are discussed in greater detail in the Web Survey Technical Report [41] and a conference paper published in the 2007 Availability, Reliability and Security (ARES) Conference. The elements are as follows: 1. 2. 3. 4. 5.

Web Application Development Methodology Web Security Development Process Definition End-User’s Feed Back Implement & Test Disaster Recovery Plans Job Related Impact.

4.1 Web Application Development Methodology In order for security to effectively and efficiently contribute to the Web application development process, an organization has to have an application development process in place, be it either explicit or implicit. There are numerous reasons why an explicit methodology is preferred to an implicit methodology. Some of these reasons include improved process clarity among employees, employee training, and process audit-ability. If an organization does not have an application development process in place, then this issue needs to be resolved before implementing WES.

4.2 Web Security Development Process Definition To cut down on possible confusion and to ensure that everyone is communicating properly, organizations should define:

What security means to the business? What it means to a web application? What it means in the development process? What a Web Engineering Security development process entails?

Clearly defining a Web security development process clears up ambiguity among the stake holders involved in the Security Improvement Initiative (SII).

4.3 End-User’s Feed Back If a development process does not attempt to acquire feedback from the end-users and/or the organization is not receptive to acquiring end-user feedback, this could signal potentially large problems with the development process alignment with the needs of the business. Strong support for end-user participation, in Web Application development, has been previously advocated in a journal article by McDonald and Welland[65].


4.4 Implement & Test Disaster Recovery Plans Organizations need to have and test their disaster recovery plans. If the organization does not have implementable disaster recovery plans, then it is difficult to develop a cost effective secure design solution for a Web application.

4.5 Job Related Impact There needs to be a job related impact associated with security process compliancy. Employees need to understand that there is a job related impact for not following organizational processes. Web Application development takes place in a fast paced environment where business reputations, market shares, financial opportunities and losses are at risk daily. This becomes even more important when considering security.


5. WES Foundation Principles The Web Engineering Security (WES) methodology was designed to complement software development through customer communications, short development cycles, and practical security solutions to business problems.[4] WES attempts to achieve this by stressing core principles while providing a general outline with customizable sub-components. The core principles behind the development of WES include good communication, security education, and cultural support. These principles are interdependent on each other and need to work in concert in order to achieve and maximise the desired effect from a security perspective. This concept is illustrated in Figure 1 - Principles. Figure 1 - Principles

5.1 Security Education The Organization for Internet Safety (OIS) publishes Guidelines for Security Vulnerabilities Reporting and Response in which they define a security vulnerability as “a flaw within a software system that can cause it to work contrary to its documented design and could be exploited to cause the system to violate its documented security policy”[38, 72]. This translates into the fact that any flaws in the system design or application coding can potentially lead to security vulnerabilities[38]. Meaning that security education should cover an array of issues including knowledge transfer, coding practices, technical attacks, social


engineering attacks, security processes, every day activities and potential impact analysis methods, to name a few. This problem is emphasized due to the availability and accessibility of Web applications. Common Web development security problems include un-validated parameters, cross-site scripting, buffer overflows, command injection flaws, error-handling problems, insecure use of cryptography, and broken access controls [5, 38, 67]. Hence, designers and developers should be educated on common development flaws, best coding practices and the implementation of practical development solutions. Security can not be left to the acquisition of the functional and non-functional security requirements. Security is more than a technical issue; it is a people, a process and an educational issue that must be addressed in its entirety. Organizations need to encourage knowledge transfer among employees and provide for proper training. Education is an important area of the security process. Security education should not only include raising awareness of the different types of technical attacks and social engineering attacks [38, 68], but it should also include information about the current environment. Employees should know with whom they should discuss security, how it fits into their everyday work environment (i.e. their development process), and the potential impact security has on the Web application solution that they are proposing / introducing into the organization.

5.2 Good Communication Good communication is a critical component of the methodology, as it is needed to assure solution compatibility within the development team and within the organization along with providing visibility throughout the entire application development methodology. Hence, good communication should encourage security visibility through the development process, an auditable process, defined metrics, the delivery of a cohesive system and the dissemination of development and security methodologies. In order to achieve these goals, there needs to be good stakeholder communication. This includes good communication between management and the development team, among members of the development team and between the development team members and the end-users. The communication between management and the development team is needed due to the fact that management is responsible for setting the policies, standards and procedures to which the development team must adhere.

5.2.1 Development Team Communication Communication has to be encouraged and fostered in the technical side of the organization. The organization’s management, in concert with the architects, need to provide a security vision for the future. This can be communicated, in the present, through the creation of current and future standards. An excellent example of this is the development of software standards to be used for the design process. If an organization is currently on Windows XP, that standard should be published along with the expected standard for the future, such as the next version of Windows and when that standard is to become effective. Communication of this information through standards has a direct effect on the organization’s coding teams. They now know the appropriate time frames, based on the published standard, so that they can code from a compatibility perspective. This idea can be expanded to include testing environments, compatibility with specific security software such as host intrusion detections systems (HIDS) and network intrusion detection systems (NIDS). The point is that this


directional support needs to be driven by upper management and provided for by the relevant parties. This support and integration with communication is a critical component for the purpose of driving future security initiatives in an organization. The marketing and dissemination of this information is necessary to effectively implement this initiative. If your employees do not know about the tools that are available, they will not use them. It is also true that if the tools and/or methods are not effective in completing the job, are too complicated to use effectively, or are just not user friendly, then employees are likely to avoid using them. If the tools or the methods are not productive for various reasons then the individual members of the development team should suggest alternative methods for evaluation. This interaction between management and the developers provides flexibility in the process. More importantly, it gives the development team a sense of ownership in reference to the methods and the tools that are used in the development process. Along with this interaction, all of the tools and the methodologies that are used in the development process need to be reviewed frequently. This review insures that the tools and the methodologies are achieving the desired goals. Developers should also be encouraged to share technical knowledge with each other. This distribution of information encourages debate on technical solutions and distributes application knowledge through the group. This distribution of knowledge helps keep a balance in the group, thereby reducing dependency on individual employees.

5.2.2 End-User Communication Communication with the end-user is needed to acquire the appropriate application requirements. Security solutions also should be confirmed with the end-user. Does the solution meet the needs of the end-user? If not, is the end-user circumventing the security measure? The security that is implemented should meet the needs of the organization so that it adds value to the end product and to the overall business process. Essential elements that contribute to good communication include a clearly defined application development methodology and a clearly defined Web security development process. The security process should explicitly include the end-user. This communication has a direct impact on the potential effectiveness of a security solution. Actual end-users, not surrogate end-users, need to be used in the testing of the application [40]. End-users will perform operations, submit data, and interpret instructions in ways that the development team, the business team or the technical staff within an organization could never dream! This is also true from a security perspective. End-users should be observed and consulted for information on the effectiveness of the implemented security solution. Observing employees has the potential for revealing security issues and application problems that could be manipulated into contributing to a security breach [40]. It could be argued that employees are not always forth coming with information, especially if the lack of security or the potential security vulnerability either does not directly affect their duties or actually helps them to accomplish their assigned tasks. Hence, a multiple stream


approach consisting of end-user involvement in testing, end-user observation and end-user consultation is recommended when working with end-users [40].

5.3 Cultural Support The cultural support should drive the efforts in security and education along with the efforts in good communication. Cultural support for security should embrace confidentiality, integrity and availability throughout the management structure. Active organizational support for security in the Web development process is critical. Without the support of management, there is no hope for effective integration of security within the development process. Managerial support for security needs to be both proactive and reactive. Management needs to be proactive by supporting employees, hence, giving them the necessary tools and developing the necessary policies so that employees can be successful in their endeavours. This would include proper controls for the development environment such as software versioning controls, providing up-to-date code libraries, setting the policies for testing code and for establishing trust and accountability within and without the organization. Likewise, management needs to be reactive by stating and enforcing job repercussions if employees do not follow security practices within the development process or the development process in general upon which the security process depends.

5.4 Security (Cultural Support, Security Education and Good Communication) The environment that is most conducive for fostering security in the Web application development environment is the intersection of all three principles. The intersection of security education and practising good communication should help build confidence in the overall security of the organization, the general security knowledge of the employees and encourage compliance with organizational policies. The distribution of security information and how that impacts the daily activities of employees helps to provide practical solutions to security issues. The practice approach helps to propagate the concept that security needs to be viewed in the application development process as “everybody’s problem”[44]. Integrating security responsibilities and security education into the development process increases employee confidence in addressing security issues and sends the signal to the development group that security is an important issue that has to be addressed. A key component of security is education. Employees need to be formally educated on the role security plays in the development process and in the organization, i.e., all stakeholders need to understand all of the security requirements along with the role security plays in the development process. The support for this education should originate from management! Cultural support for good communication helps to provide the necessary tools to get the job done and demonstrates that the organization supports the security movement within the company. Active organizational support includes encouragement of security communication among employees. Increased communication should translate into a better working understanding of the role security plays in the development process and the organization. This better understanding should increase the overall level of security in the development process.


The incorporation of security into the development process should be as seamless as possible. This seamless integration of security into the development process should support the goals of meeting the Security Criteria for Web Application Development (SCWAD): 1. 2. 3. 4.

Active organizational support for security in the Web development process Proper Controls in the development environment Security visibility throughout all areas of the development process Delivery of a cohesive system, integrating business requirements, software and security 5. Prompt, rigorous testing and evaluation 6. Trust and Accountability These elements are discussed in greater detail in the WES Application Technical Report [39] and a conference paper published in the 2006 International Conference on Web Engineering (ICWE) Conference[37]. Active Organizational support for security in the Web development process includes the managerial support for security integration into the development process, support for developmental staff, end-user communication and security education. Having proper controls in the development environment is a very broad concept that encompasses policies, knowledge, technology, and processes. These controls help to provide structure to the development environment. Security should be visible in all steps of the development process if it is to be implemented with any success. This implies that the development process needs to be security focused. The term security focused translates into the use of effective and efficient designs, compliance with policies, standards and procedures, while implementing good coding practices, addressing security issues such as authentication and authorization issues, having specific security testing criteria, and acquiring feedback from the end-user that is security specific. Deliver a cohesive system, integrating business requirements / needs, software and security means that the security requirements of the business need to be identified as early as possible in the development process. The reason for this identification is so that these elements can be incorporated into the design and the construction in order to produce secure software. Prompt rigorous testing and evaluation should realistically include as much testing is possible from the design and programming perspectives. This would include automated and manual scripts, code reviews, and black, white and grey box testing along with as much testing and interaction with the end-user as possible. The establishment of trust and accountability is a crucial component of security. Trust is the foundation for security. The establishment of trust generally encompasses the management of risk, the implementation of appropriate controls, the education of employees and effectiveness monitoring. An accurate risk assessment is commonly a key component in establishing trust. Once trust has been established, then there has to be user accountability for actions performed in the application. Individuals have to be successfully identified and William Brad Glisson Page 27 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

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 is necessary in establishing security for an application. To support the security goal, a metric system should be developed that helps the organization measure the success of the development process security initiative. This should include issues ranging from general security education, to training, to monitoring and tracking all development bugs. This will help the organization determine if it is actually delivering a cohesive system that integrates the business, the software and the security perspectives.


6. The WES Process Life Cycle The Web Engineering Security (WES) methodology, as shown in Figure 2 - WES Methodology, starts with a Project Development Risk Assessment. This initial phase examines the security risk associated with the implementation of a project. The Application Security Requirements phase examines the requirements from the customer perspective within the frame work of organization compatibility. Security Design / Coding examine the architecture, the solution design and the coding practices that are implemented to solve the issue. A Controlled Environment Implementation scrutinizes the application’s interactions with the entire environment before specific aspects of the application are examined. Testing is critical to the success of any application. This hypothesis holds true in the area of security as well. Testing not only includes the examination of code but incident management and disaster recovery. Implementation of the application in a production environment should only take place after it has successfully completed testing. End-user evaluation is used to establish the success of the application’s security features and for security maintenance. The WES methodology implicitly supports the concept of separation of duty between everything that happens before testing and everything that happens after testing. This is demonstrated through the colour of the line, the line style and the directional arrows displayed in Figure 2 - Wes Methodology. The ideal situation is that the developers and the testers that work on the project are not the same individuals that implement the project into production. Realistically, depending on the size of the organization, this may not be possible. Regardless, once code has been moved from the test environment to the production environment it should not be allowed to return to testing without going through another iteration of the process.


Figure 2- WES Methodology


6.1 Project Development Risk Assessment The purpose of the risk assessment is to identify any risk associated with the development of the proposed application functionality. An excellent definition of risk is “…risk is a measure of the loss of what you consider valuable, the impact of losing it, the threats to those assets, and how often those threats could be successful”[92]. Broadly speaking, this would include examining appropriate data protection legislation that might apply to your organization’s application. There are several tools and suggested practices available in the market for conducting risk analysis. These tools include COBRA, the Facilitated Risk Analysis Process (FRAP) and the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)[8, 24]. The National Institute of Standards and Technology (NIST) has recommendations for conducting company wide risk analysis on their web site[76]. OCTAVE is an in-depth organization wide risk analysis approach developed at Carnegie Mellon[2]. If an organization wide risk analysis is conducted periodically, then the information in the analysis can be used as a starting point for the application risk analysis. The reverse is also true. Information from the individual application analysis can be used as an initial guide to organizational analysis. The risk assessment piece of the methodology can be customized to work in conjunction with an organization’s existing risk analysis processes. The basic idea is to: • • • • •

detail critical functions, determine the necessary service levels in doing so, identify possible threats and outline their motivating factors, estimate the probability of an attack, estimate the probability of a successful attack, outline the cost of providing protection[25] [79] [78].

The answers generated from researching the statements above should help answer the following questions: 1. 2. 3. 4.

“What could happen? (What is the threat?) How bad could it be? (What is the impact or consequence?) How often might it happen? (What is the frequency?) How certain are the answers to the first three questions? (What is the degree of confidence?) The key element among these is the issue of uncertainty captured in the fourth question. If there is no uncertainty, there is no ‘risk’, per se”[75].

Application threats can cover a wide range of possibilities including: human errors in coding, user errors, external attack, fraudulent individuals, technical sabotage, acts of God, and disgruntled employees; all of which should be accounted for in the risk assessment[25]. Once the risk assessment has taken place, the specific application security requirements need to be determined through in-depth conversations with the end-user and evaluation of organizational compatibility. Organizational compatibility determines how well security requirements fit into the frame work of an organization. The general areas that make up this category include security policy compatibility, corporate culture compatibility and technical compatibility. By conducting a Project Development Risk Assessment, the business and the information technology group can analyze each stage of the development by identifying the associated risks. This would include determining the states of the application and how they can be used or


misused as the case may be. This step provides an opportunity for the organization’s development team to understand the application from a risk point of view and helps to generate appropriate questions to address the application security requirements phase. Depending on the size of the organization and the market requirements, both the governmental and commercial perspectives, the risk analysis can be used to help identify known risks, point out new risks and ensure that these risks are acceptable. Depending on the needs of the organization, this can be either a very formal process or a very informal process. If it is a formal process, then the advantage for management is that it presents a clear understanding of the risks before a substantial investment is made in the development of the web application. The disadvantage of a highly formalized process is that it can slow down the development process. In reality, there will be a lot of cross-over communication between the Project Development Risk Assessment stage and the Application Security Requirements stage. Informal processes tend to be faster in nature but, by nature, introduce more risk through a potential lack of environmental and risk understanding. The deliverables that could possibly be generated at this stage include a formal project risk analysis document and a risk analysis document used to gather end-user requirements, a document detailing high-level issues for design and testing.

6.2 Application Security Requirements Specific application security requirements have to be acquired from the end user. Realistically, the project risk analysis should be used to help gather the security requirements by generating a series of questions and responses that filter the desires of the end-user into a list of detailed needs. The Application Security Requirements phase allows the development team to make a specific effort to acquire the security requirements through effective communication with the end-user. Hence, the stakeholders involved in this stage would probably include the business unit and the technical staff. They should coordinate these requirements with the organization’s security compatibility constraints. The security compatibility constraints encompass several important issues that include security policies, standards, baselines, procedures, guidelines, the corporate culture and existing technology. For the purposes of this report, the terms listed in Table 1 -Terms have been taken directly from The Security Policy life Cycle: Functions and Responsibilities by Patrick D. Howard. Once these requirements have been captured, they should be examined against the organizations security policy, the corporate culture, and technical compatibility.

6.2.1 Security Policy Policies, standards, baselines, procedures, and guidelines can assist in large organizations to provide cohesiveness within the organization. “The goal of an information security policy is to maintain the integrity, confidentiality and availability of information resources”[49]. In smaller organizations, where it is not mandatory through regulation, they can be implicit to the organization. The policy provides the “what” and the standards, baselines, procedures and guidelines provide the “how”[48]. They can work in concert to support the organization from a security perspective. The Security policy encompasses all business interactions providing overall guidance to protecting resources[81]. This includes acceptable computing practices, all interactions with the network, internet, messaging, and business specific applications or services.[25] Companies may need to meet security policy standards requirements like the ones put out by the


International Standards Organization (ISO)[54]. In the context of web development, the main area of concentration, with regards to the security policy, would be application compatibility within the corporation. However, all areas would need to be addressed to ensure overall compatibility. The security policy should be a living document and updated as new architectures and applications are developed[88]. If a security policy does not exist at project inception, then the organization may need to investigate the validity of creating the appropriate document. Table 1 - Terms A broad statement of principle that presents management’s Policy: position for a defined control area. Standards: Rules that specify a particular course of action or response to a given situation. A platform-specific security rule that is accepted across the Baseline: industry as providing the most effective approach to a specific security implementation. Procedures: Define specifically how policies, standards, baselines and guidelines will be implemented in a given situation. Procedures support policies, standards and baselines. Guidelines: A general statement used to recommend or suggest an approach to implementation of policies, standards, and baselines. Howard, P.D., The Security Policy life Cycle: Functions and Responsibilities, in Information Security Managment Handbook, H.F.T.a.M. Krause, Editor. c2004, Auerbach Publications: Boca Raton. Pg. 980

6.2.1.1 Legal Compliancy It is important to recognize that a company’s policies, standards, baseline, procedures and guidelines should be compliant with relevant legal obligations. Cyber-crime is a reality that cannot be ignored in today’s global business environment. The ramifications from a financial perspective and a legal perspective are potentially enormous. Hence, Web application security needs to be incorporated into the entire development methodology. This includes upfront acknowledgement of the legal ramifications involved with the development and deployment of the Web applications. Effective security resolutions need to acknowledge the legal ramifications that the application introduces to the company and the attendant risks need to be mitigated to the organization’s satisfaction. For this reason a check list of relevant legislation has been compiled from the information published in a paper in the 2007 Second International Conference on Availability, Reliability and Security (ARES) [35] and is available in Table 2 - Legislative Guidance. The purpose behind the check list is not to introduce a debate over the legislative or the legal enforcement challenges that computer crime presents. Nor is it to discuss the effectiveness of the current legislation or potential conflicts between legislation enacted in different countries. The point is to acknowledge the increasing global legislation that is developing due to the growing impact of the World Wide Web on everyday life, on business economical environments and national importance. The legislative list provides a snap shot in time of current relevant legislation. Due to the dynamic nature of legislation, it is understood that the list will continue to change over time as the Web integrates into global environment. The fact is that, economies continue to integrate with the Web to produce and/or provide goods and services. Societies continue to increase dependence on the Web to help provide basic operational economical components. This increasing dependency introduces potential national security risks. Therefore, societies are demanding a more secure World Wide Web which leads to the continued creation


of new and refinement of existing security legislation. This security legislative growth potentially has world wide ripple effects on the global economy. Table 2 - Legislative Guidance

US Legislation Electronic Communications Privacy Act Federal Information Security Act (FISA) of 2002 Executive order - National Strategy to Secure Cyberspace Homeland Security Act of 2002 Homeland Security Presidential Directive No. 7 (HSPD-7) Cyber Security Research and Development Act Check Clearing for the 21st Century Act The Economic Espionage Act of 1996 (EEA) The Health Insurance Portability and Accountability Act of 1996 (HIPAA) The Graham-Leach-Bliley Act of 1999 The Sarbanes-Oxley Act which was passed into law in July of 2002[113] The Fair and Accurate Credit Transaction Act of 2003 The Family Rights and Privacy Act (FERPA) Identity Theft Penalty Enhancement Act of 2004. Electronic Signatures Act The Computer Fraud Act of 1984 The National Information Infrastructure Protection Act of 1996 The USA Patriot Act of 2001 The US Safe Harbor Act

United Kingdom Legislation The Theft Act 1968 - applicable to fraud The Forgery and Counterfeiting Act 1981 The Criminal Damage Act 1977 The Protection of Children Act 1978 The Telecommunications Act 1984 The Public Order Act 1986 - applicable to racist materials The Criminal Justice Act 1988 The Malicious Communications Act 1988 The Copyright, Designs and Patents Act 1988 The Computer Misuse Act of 1990 The Criminal Justice and Public Order Act 1994 The Data Protection Act of 1998 Regulation of Investigatory Powers Act(RIP) 2000 Electronic Communications Act 2000 The Telecommunications Regulations 2000 The Electronic Signatures Regulations 2002

6.2.2 Corporate Culture Corporate culture needs to take everything into account, ranging from employee security awareness programs, to employee education on social engineering attacks (discussed below), to William Brad Glisson Page 34 of 51 13/03/2007 © University of Glasgow 2006, Department of Computing Science Technical Report - TR-2007-243

recognition of organizational norms. Corporations need to educate the application end-user employees and their development staff in terms of security. They also need to remind employees periodically about security policies, standards, baselines, procedures, and guidelines. One approach to this is to make the issue important to the employee by integrating it into their annual evaluation[112]. This will not solve all of an organization’s security problems; however, it does provide a practice avenue for encouraging good security practices[112]. Corporate culture needs to be examined from several different perspectives that include managerial acceptance of the importance of security, the threat of social engineering, employee perception of security and security habits, and technological acceptance of cultural norms. Managerial acceptance and habits, from a cultural stand point, are critical to the success of security within an organization. Large organizations, looking to strengthen security in their corporate cultures, need to have the highest possible ranking champion promoting the change. In small organizations, the change should be introduced by the owner. If management takes security seriously and encourages a secure environment through their actions, then the odds of this having a positive trickle down effect to employees within the organization are good. If the management does not care about security, why should the employee?

6.2.3 Technology Compatibility Existing technology needs to be examined from two view points; a compatibility point of view and a value added point of view. When an application is being proposed the solution needs to be compatible with the existing infrastructure in the organization. Does the technical expertise exist in the organization to write the application in the proposed language? Does the hardware infrastructure support the new applications? Is the existing code repository compatible with the new development of the new application? There are both hard and soft costs associated with these types of questions that need to be taken into consideration when considering any new application development. Technology needs to be examined from a value added point of view. Whether you subscribe to individual aspects or to all of the “value configuration(s)” which include the value chain, the value shop and the value network, one of the goals of the organization is to provide added value regardless of the product or service that is being offered.[1] Technology is a major contributor to this goal in today’s market place. Hence, when examining the validity in developing a new application, the organization should be asking how this will help them add value to their organization. In general, the area of technological compatibility has to do with an organization’s existing applications, software compatibility, legacy systems and the acquisition of new software and technology[6]. When considering the technical compatibility of a system, it is necessary to consider the existing employee skill set within the company. To implement a technical solution, does the necessary skill set exist within the company, can it be acquired easily through employee training or will it require the company to acquire the necessary skills though outsourcing? To answer these questions an in-depth analysis will need to be conducted and compared with the solutions requirements. Technological compatibility, from a security standpoint, needs to examine the application to see if it is compatible with existing security solutions already in production. An example would be a new application that is not compatible with the company’s existing single sign-on solution.


If a solution requires new technologies, the organization should rate the security capabilities of the new technologies and determine if they meet the company’s security standards out of the box. If they do not, can they be brought up to speed and at what cost? This does not mean that these are the only areas that can contribute to this category or that they all have to be present within this section to ensure compatibility. There are environments that may choose not to implement a security policy or to investigate corporate culture due to the size of the company. For instance, a large financial institution will probably have all three categories (security policy compatibility, corporate culture compatibility and technical compatibility) documented to some extent. However, a small family run business, like a local restaurant, probably will not have a security policy and the culture in that business will be implicit. However, more than likely, they will have technical compatibility issues that they will need to address.

6.2.4 Security and the Human Element Technical solutions alone will not provide protection against the human element. They will not provide protection against an end-user who reveals his/her passwords, users who circumvent security to complete a specific task, or insider attacks[25]. When it comes to information security “the human factor is truly security’s weakest link”[68]. This fact has spawned an area of warfare in the business world known as social engineering. Social engineering attacks take place when an outsider or insider observes an organization, gathers information and makes necessary business contacts under the premise of a legitimate purpose in order to gather information.[68] This information is then used to acquire more information until the intruder has acquired something of value.[68] The same tactics can be used by a current employee to gain unauthorized privileges. Company employees need to be educated on the existence of social engineering attacks and how to identify and prevent these attacks from occurring[68]. The perception of security, and its importance to the business, needs to be effectively communicated at an employee level. If the employees do not place a great deal of importance on security and they regularly post passwords on screens or in accessible areas, trade passwords with colleagues, or grant system access to outside vendors, then they are creating a security risk for the company. Technological acceptance of corporate norms is when a solution has been implemented in the environment, becomes accepted and then becomes expected. If an organization has implemented a single sign-on solution for several of the existing applications then it would be reasonable for employees to expect new applications to take advantage of this technology. The justification for complying with this expectation or going against the grain needs to be examined and justified to the employees. Otherwise, employees could start to circumvent security when it suits their needs.

6.3 Security Design / Coding Once the application security requirements have been determined, the next issue that needs to be addressed is security design. The design of the application needs to consider the overall architecture, the application design, and good design principles.


This information then allows the technical architect, in the Security Design / Coding phase, to pick the most appropriate technical controls from a design, risk and cost perspective. Once the high level design decisions have been made, then the coding takes place. The programmers should take into consideration coding standards, good coding practices, code reviews and appropriate security measures. Encouraging programmers to adhere to coding standards and to pursue good coding practices will increase the code readability which will inherently improve software maintenance. This improvement should be felt in both enhancement maintenance and patch maintenance. It has been estimated that maintenance accounts for an average of 60% of an application’s software expense[33]. In reality, “better software engineering development leads to more maintenance, not less”[33]. If an application meets the needs of a particular market, then the application will be enhanced through the addition of new features and improved functionality. Patch maintenance is another area that is critical to defending against cyber vulnerabilities.[15] Any improvement in an organization’s software maintenance capabilities translates into long term savings. Code reviews ensure that the code is doing what it is suppose to do, decrease errors in the code and ensure that more than one person understands the application. The implementation of the type of code review is up to the individual organization. Code reviews can encompass everything from pair programming, to design reviews, to manual reviews of code after it has been written. It is up to the organization to decide the best avenue for implementation. Hence, the organization is not dependent on a single employee for modifications and support of a specific application. Applying appropriate security measures will help ensure data security and security consistency throughout the application. The architecture needs to fit into the existing organizational environment. There are several issues that need to be addressed within the realm of architecture. Some of those issues are: • • • • • • •

application layers[26] application maintainability[44] information compatibility from a data transfer standpoint how strongly typed the language needs to be, [62] approach to privileges i.e. role based or inheritance the approach to default privileges from the application and the user’s standpoint[78] security in-depth - use passwords and another mechanism, such as an encrypted key of some sort, for determining object access[78].

The design of the application needs to address: • • • • • •

the type of language that will be used[62] ease of use – the easier security solutions are to use, the less likely that they will be circumvented,[78] authorization techniques, the use of encryption algorithms the establishment of trust the establishment of accountability.

It should be noted that the establishment of trust will link back to the project risk assessment. The amount of trust that is designed into an application is directly related to the amount of risk that an organization is willing to tolerate and the total cost that they are willing to absorb.


Accountability is essential to security. If you do not have a mechanism for identifying individuals, then you do not have security. The design will need to examine the code from common attack standpoints and implement the appropriate controls to ensure secure data. It should be noted that a professional code management system needs to be used by the development team to ensure accountability, within the team, and provide a means of roll back[29]. Once the design has been chosen, the solution is coded. During coding, the developer should be cognizant of the World Wide Web Consortium (W3C) coding standards and pursue secure coding practices[108]. The trick, when designing a secure solution, is to balance the need for a secure application with the need for a particular functionality. A good design principle is to create a simple solution that solves specific problems and fits into the applications global architecture. The design will depend on the level of security the customer is willing to accept from a risk and/or cost standpoint.

6.4 Controlled Environment Implementation Depending on the needs of the organization, the Controlled Environment Implementation can be as complex as implementing it into an environment that mirrors the production environment or it can be as simple as running the application on a desktop[38]. The goal of the environment is to minimize surprises. Basically, this phase allows the developers to test the application’s compatibility with the operating system and interfacing programs before application testing and a production release. A Controlled Environment Implementation can be as simple as implementing and running the application on a desktop to test the security controls within the application. It can also be as complex as implementing the application on a separate server that mirrors production. The point here is to release the code in a secure environment that simulates the production environment for compatibility testing before the application is made available to the general public. The controlled environment implementation should also take into consideration application compatibility, load testing and regression testing. The new application has to be compatible with the native operating system and with the other pre-existing applications. Compatibility also needs to be verified with applications on the same server and applications that live off site (internal to the organization or external to the organization) where data is being exchanged.

6.5 Security Testing Testing takes place from both the developer and the end user perspective. Programmers should be running their own battery of tests when the code is conceived. Again, it should be stressed that the methodology is designed to work in conjunction with existing organizational tools and processes. If the organization already has an investment in automated testing tools, they should be used in this stage to augment the testing process. Actual end-users should be incorporated into the testing campaign whenever possible. The endusers should be writing test scripts and actively interfacing with the application to ensure that the program is performing accordingly. End-users participation in the security testing of the Web application holds the process and the solution accountable from a practicality perspective.


Within the area of new application development, there is evidence to support the value of early integration of security into the development methodology. The National Institute of Standards and Technology (NIST) estimates that “93% of reported vulnerabilities are software vulnerabilities”[74]. The Organization for Internet Safety (OIS) publishes Guidelines for Security Vulnerabilities Reporting and Response. In this document, they define a security vulnerability as “a flaw within a software system that can cause it to work contrary to its documented design and could be exploited to cause the system to violate its documented security policy”[38, 84]. Hence, any flaws in the system design or application coding can potentially lead to security vulnerabilities[38]. The Open Web Application Security Project (OWASP) provides an excellent listing of the top ten vulnerabilities in Web Applications. The top ten vulnerabilities, listed below in Table 3, are taken directly from the OWASP report. Table 3 - Top Vulnerabilities in Web Applications Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application. Restrictions on what authenticated users are allowed to do are not properly Broken Access Control enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files, or use unauthorized functions. Account credentials and session tokens are not properly protected. Attackers Broken Authentication and Session Management that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users’ identities. The web application can be used as a mechanism to transport an attack to an Cross Site Scripting (XSS) end user’s browser. A successful attack can disclose the end user’s session Flaws token, attack the local machine, or spoof content to fool the user. Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. Buffer Overflows These components can include CGI, libraries, drivers, and web application server components. Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in Injection Flaws these parameters, the external system may execute those commands on behalf of the web application. Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application Improper Error Handling does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them Insecure Storage have proven difficult to code properly, frequently resulting in weak protection. Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can Denial of Service also lock users out of their accounts or even cause the entire application to fail. Having a strong server configuration standard is critical to a secure web Insecure Configuration application. These servers have many configuration options that affect Management security and are not secure out of the box. Unvalidated Input

The Open Web Application Security Project (OWASP). The Ten Most Critical Web Application Security Vulnerabilities. c2004 http://www.owasp.org/index.jsp


This list complements information discussed in the previous articles the “Top Web application security problems identified” and “The Bugs Stop Here” which were published in 2003[5, 67]. Only after testing has been completed should the application be moved into production. Developers need to examine their code independently and the program as a complete entity in order to determine possible misuse from a functional standpoint. That is, programs only do exactly what they are designed to accomplish. “Vulnerabilities can stem from the rapidly evolving use of software, in which programs meant for a limited purpose are applied in ways not anticipated by their developers”[111]. Hence, can the program be manipulated in a manner that might create problems and can this be stopped or mitigated? A primary example is an e-mail server that is used to propagate a virus or used in a denial of service attack. Testing is critical to the success of any application. Testing should cover application testing, incident management and disaster recovery plans. Application testing includes validation errors, program behaviour testing, and code analysis. This will involve implementing appropriate programs to test static and runtime code, penetration, and application scanning. Automation, where possible, of the testing process will help provide stability. Testing should also involve executing scripts from both the developer and the end users to test the application. An important part of the testing phase should be to decide appropriate action plans for incidences. When there is an issue, what are the procedures that need to be implemented to resolve the situation? This should also include amending the disaster recovery plan where appropriate. If the organization does not have a disaster recovery plan, then, maybe they should investigate the creation of a plan. The disaster recovery plan on the organizational level should be a living document. The disaster recovery plan for the application should be flexible enough to allow for the addition of a new functionality. Once the plan either has been created or amended then it should be tested. In short the testing should be: • • • • • • •

As prompt as is reasonably possible so that an organization is competitive in the Web application development market Testing needs to involve actual end-users, not surrogate end-users Testing should be as comprehensive as possible. This will be determined based on the amount of risk the application presents to the organization’s reputation and the organization’s core business. Testing should be tailored for security. Testing should take advantage of an organization’s existing testing infrastructure. External testing should be used to verify application security where the risk warrants the expense. A matrix should be implemented to measure the success of the testing and effectively track bugs.

6.6 Implementation into Production After testing has been completed, then and only then is the application prepared for Implementation into Production. The introduction of the application into the production environment needs to be completed with the involvement of the appropriate security personnel. The appropriate personnel need to be present to ensure that the application has been deployed properly into the production environment. If possible, this allows for immediate issues resolution at the time of implementation. If issues are discovered after the application has been


implemented into production, then the application must go through the process again and be reimplemented into production.

6.7 End-User Feed Back End-User Evaluation is critical from the standpoint of security. Whenever it is possible, actual end-users should be used in the security evaluation of a Web application. End-users are the ultimate variable in the execution of an application. If end-users are circumventing the application’s security in order to make their lives easier or perform their jobs in a timely manner, then these issues need to be investigated and resolved.[38] An efficient and effective response to application security breaches is mandatory to web based business survival. If the application has been compromised due to a flaw in the design or the code, then the security issue needs to be addressed, realistically, as rapidly as possible. If the application is not secure, businesses run the possibility that the application will be abused, corporate credibility lost, and financial consequences incurred. End-User Evaluation involves both communicating with the user to determine the success of the application’s security and security maintenance. This can range from informal communication, to surveys, to structured interviews with the end-user. Security has to find a balance between usability and providing a secure environment. Security maintenance has to do with discovering vulnerabilities after a production release. As new technologies emerge from the view point of development and maintenance, new vulnerabilities will be created and uncovered and these issues will have to be addressed to maintain application security[62, 78]. Patches will need to be tested to ensure that they resolve the newly discovered issue and to ensure that they do not create new security vulnerabilities in the application.


7. Stakeholders The stakeholders who are involved in a specific project obviously depend on several criteria ranging from resources, to project visibility, to project risk, to funding. A large organization is more likely to have the recourses available to assign different people from different areas to the project. A small company, on the other hand, may have employees conducting multiple job functions. Project visibility is a factor when considering the amount of resources that will be assigned to a specific project. If an organization has a project that is considered to be a high profile project, then the project affects many people within and/or without the organization and will probably receive more attention than a low profile project. The risk associated with the profile is another matter. If the application has a high profile and a high risk to the core business function of the organization then it stands to reason that most organizations would assign more resources to the project. An example of this is a Web site that conducts financial transactions for a banking institution. On the other hand, if a project has a high profile and a low risk, such as an intranet phone book application, then fewer resources are probably going to be assigned to the project. As always, funding is an issue with all projects. If the funding is not available, regardless of the size of the organization, then resources will simply not be assigned to the project. General stakeholder titles that would be expected to be involved in the development process would include the project manager, architect, programmer, tester, security personnel, release personnel, and the end user.


8. Deliverables After the process has been customized for needs of a specific business, then it can be documented so that it can be replicated for future projects. Depending on the needs of the organization, this can also serve as an audit trail. The amount of documentation implemented will depend on the needs of the particular organization. A financial institution, due to regulations, will probably have to provide detailed documentation of their processes. In contrast, a small local business will probably document only the bare necessities in order to conduct business. The deliverables that are required during each stage of the Web Engineering Security development process depends on two issues. The first issue that has to be recognized is the culture of the organizations, which is directly related to the industry to which the organization belongs. If the organization is in a highly regulated industry, such as banking or insurance, then there will be a greater emphasis on the individual deliverables that are required at each stage of the process. However, the converse is also true; if the organization is not in a highly regulated business then there will be fewer deliverables that are required during the various stages of the process. The second issue that has to be acknowledged is the application development methodology that the organization is implementing to create Web software. This usually will be linked, as well, to the culture and the industry to which the business belongs. An organization that uses a water fall approach will be more inclined to generate documentation and specific deliverables between the various stages. However, an organization that is implementing an agile approach to application development will, by nature, produce fewer deliverables between the various stages. Understanding the previously mentioned issues, the decision as to whether to create deliverables and to what extent the deliverables are created is left to the organization to determine.


9. Expected Effect 9.1 Upfront Integration of Security The WES methodology strives to integrate security from the beginning of the application development process. This is why security discussions are initiated during the business analysis stage of the development process. This up-front integration should help the organization reap benefits ranging from faster application development, to positive effects on budgets and time frames by proposing realistic security solutions at the onset of the project. This goal is to move security from the typical view point of an inhibitor to that of an enabler in the eyes of the enduser. Granted, this move is, to some extent, dependent on the security team that is implementing the WES methodology. They need to not only be defining what is possible in the current organization but be providing an architectural strategy for the future and providing realistic alternatives to business needs vs. stating that something is not possible, full stop.

9.2 Security Comprehensiveness The WES methodology hopes to address the questions of “How do I build application security into the fabric of my company?”[16]. The solution is to approach the problem from the idea of presenting a proactive comprehensive approach to the security development process. The security methodology should be compatible with the existing application deployment process capitalizing on current core competencies while providing a road map for improving security during the application development process.

9.3 Structured Security Implementation The WES methodology provides an overall structure that allows organizations to customize the level of security to its individual needs and implement security into their application development Process. This structure can then be hardened to provide an organization with the desired level of continuity, repeatability and audit-ability for future development projects.

9.4 Industrial Practicality The general categories in the WES methodology are not set in stone but are strongly recommended. The items within the categories will need to be tailored and, where necessary, expanded to meet the specific needs of the individual organization and their current policies and procedures. The methodology is designed to complement an organization’s current methodology, while providing guidance to the development process from a security perspective. The idea behind the WES methodology is to provide a roadmap for web application development that will help guide organizations to a more secure system. The goal is to proactively help developers create applications that are secure by design. Following the WES methodology means that the development process has taken into account risk analysis, application security requirements, various organizational policies, organization architecture, code design and coding practices, proper testing procedures and end-user feedback. WES provides the individuals involved in the Web development process a practical method by which to address security. There are several models in existence that tell you “what” to do to


improve general security within an organization and some within the organization’s development process. There are currently a multitude of technical solutions that offer possible solutions to very specific questions which basically answer “how” to solve specific security problems. The technical contribution is growing rapidly daily. None of the currently proposed solutions are tailored to address the needs of Web engineering development. The general models are very high level models and they do not accurately address the practical issue of “where” these actions should be performed. WES provides the Web Engineering community with a practical methodology to solve the inherent security deficiencies present within generic development life cycles.


10. Acknowledgements We take this opportunity to extend our appreciation to our families and friends for their support and cooperation throughout the development of this report. In addition, a special thank-you is extended to Dr. L. Milton Glisson, Dr. Andrew McDonald and John Wilson for their comments.


11. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

[16] [17] [18] [19]

[20] [21] [22] [23] [24] [25] [26]

[27] [28]

Afuah, A. and C.L. Tucci, Internet Business Models and Strategies, Second Edition. International Edition ed. 2003, Boston: MacGraw-Hill. 121-139. Alberts, C., Introduction to the OCTAVE® Approach, J.S. Audrey Dorofee, Carol Woody, Editor. 2003, Carnegie Mellon Software Engineering Institute: Carnegie Mellon Software Engineering Institute. p. 1-37. Anderson, R., Security Engineering: A Guide to Builidng Dependable Distributed Systems. 2001, New York: John Wiley & Sons, Inc. Beck, K., Manifesto for Agile Software Development, The Agile Alliance,, http://www.agilealliance.org/. Berinato, S., The Bugs Stop Here, in CIO. 2003. Boman, M., Conceptual Modelling. 1997, London: Prentice Hall. 269. BZ Media, IT Professionals Guard Against Disaster at First Annual Software Security Summit. c2004, Bz Media: New York and California http://www.bzmedia.com/pr/pr20041123.htm. C&A Systems Security Limited, COBRA, C&A Systems Security Limited: Cheshire http://www.riskworld.net/. Cambridge lawyers, Naked Law - UK technology law laid bare by Cambridge lawyers. 2005 http://nakedlaw.typepad.com/naked_law/computer_crime/index.html. Civil Society Internet Rights Project (CSIR), UK Internet Rights project: Fact Sheets: Computer crime, internetrights.org.uk http://www.internetrights.org.uk/. Coblenz, M., Federal Protection of Trade Secrets: The Economic Espionage Act of 1996. c1997, Washington State Bar Association http://www.wsba.org/media/publications/barnews/archives/sep-97-federal.htm. Computer Crime Research Center Staff, UN recommendations on fighting cybercrime. 2005, Computer Crime Research Center http://www.crime-research.org/news/12.05.2005/1225/. Congress, P.L.-t., HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996. c1996, Congress: Washington http://aspe.hhs.gov/admnsimp/pl104191.htm. Council of Europe, Convention on Cybercrime. 2004, Council of Europe http://conventions.coe.int/Treaty/en/Summaries/Html/185.htm. Dacey, R.F., INFORMATION SECURITY Effective Patch Management is Critical to Mitigating Software Vulnerabilities, in Testimony Before the Subcommittee on Technology, Information Policy, Intergovernmental Relations, and the Census, House Committee on Government Reform. 2003, United States General Accounting Officehttp://www.iwar.org.uk/comsec/resources/worm-virus-defense/GAO-final-testimony.pdf. deJong, J., Slipping In The Side Door With App Security Message. 2006, BZ Media LLC: Huntington NY http://www.sdtimes.com/article/special-20060815-01.html. Deloitte, 2004 Global Security Survey. 2004, Deloitte Touché Tohmatsu: London. p. 1-36 http://www.deloitte.com/dtt/cda/doc/content/GFSI%20Security%20Survey%202004%20-%20Final.pdf. Deloitte, 2005 Global Security Survey. 2005, Deloitte Touché Tohmatsu: London. p. 1-44 http://www.deloitte.com/dtt/cda/doc/content/dtt_financialservices_2005GlobalSecuritySurvey_2005-06-22b.pdf. Deloitte, Security Attacks On IT Systems More Than Double, According to Respondents of Deloitte & Touche LLP’s Global Financial Services Survey. 2004, Deloitte http://www.deloitte.com/dtt/press_release/0,1014,sid%253D2283%2526cid%253D50024,00.html. Department of Justice, U., Computer Crime and Intellectual Property Section (CCIPS), Department of Justice, USA http://www.usdoj.gov/criminal/cybercrime/ipmanual/08ipma.htm#VIII.C.3. Deshpande, Y. Web Engineering Curriculum: A Case Study of an Evolving Framework. in Web Enginering 4th international conference, ICE 2004. 2004. Munich, Germany Deshpande, Y., et al., Web Engineering. Journal of Web Engineering, 2002. 1(No. 1): p. 3-17. Dickson, J.B., Web applications have become IT's next security battleground. San Antonio Business Journal, 2004. Educause, Risk Analysis of Critical Areas and Processes. c2004, EDUCAUSE http://www.educause.edu/content.asp?page_id=1251&bhcp=1. Ellis, J. and T. Speed, The internet security guidebook: from planning to deployment, ed. E. Carrasco. 2001, San Diego: Academic Press. 1-320. Fernandez, E.B. Coordination of security levels for Internet architectures. in Procs. 10th Intl. Workshop on Database and Expert Systems Applications. 1999: Procs. 10th Intl. Workshop on Database and Expert Systems Applications http://polaris.cse.fau.edu/~ed/Coordinationsecurity4.pdf. Fingar, P. and R. Aronica, The Death of "e" and the Birth of the Real New Economy: Business Models, Technologies and Strategies for the 21st Century. 2001, Tampa, Florida USA: Meghan-Kiffer Press. 82. Foster, A.L., Colleges Face Rising Costs for Computer Security, in The Chronicle of Higher Education. 2004. p. 35,36,38.


[29]

Foster, J.C., Five hidden tactics for secure programming. c2004, Ounce Labs http://event.on24.com/eventRegistration/EventLobbyServlet?target=lobby.jsp&playerwidth=950&playerheight=680&totalwidth=800&align=left&event

[30] [31] [32] [33] [34] [35]

[36]

[37]

[38]

[39] [40]

[41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]

id=8449&sessionid=1&partnerref=SitePost&key=21A0DCD96C5F113F45DDD69439B96F46&eventuserid=3328607. Fowler, M. and J. Highsmith, The Agile Manifesto. 2001, Dr. Dobb's Portal: San Mateo, CA http://www.ddj.com/dept/architect/184414755#sidebar. Frederick P Brooks Jr, No silver bullet: essence and accidents of software engineering. Computer, 1987. 20(4): p. 10-19. Freedman, R., The econsultant: guiding clients to Net success. 2001, San Francisco :: JosseyBass/Pfeiffer,. xviii, 254 p. :. Glass, R.L., Facts and Fallacies of Software Engineering. 2003, Boston, USA: Addison-Wesley. Glisson, W.B., L.M. Glisson, and R. Welland. Secure Web Application Development and Global Regulation. 2007 Glisson, W.B., L.M. Glisson, and R. Welland. Secure Web Application Development and Global Regulation. in The Second International Conference on Availability, Reliability and Security (ARES). 2007. Vienna, Austria: IEEE http://www.ares-conference.eu/conf/index.php. Glisson, W.B., L.M. Glisson, and R. Welland. Web Development Evolution: The Business Perspective on Security. in Thirty-Fifth Annual Western Decision Sciences Institute. 2006. Hawaii: Western Decision Sciences Institute http://wdsinet.org/. Glisson, W.B., A. McDonald, and R. Welland. Web Engineering Security: A Practitioner's Perspective. in International Conference on Web Engineering. 2006. Palo Alto, California: Springer http://wwwconf.slac.stanford.edu/icwe06/default.htm. Glisson, W.B. and R. Welland. Web Development Evolution: The Assimilation of Web Engineering Security. in 3rd Latin American Web Congress. 2005. Buenos Aires - Argentina: IEEE CS Press http://www.ing.unlpam.edu.ar/laweb05/cfp.html. Glisson, W.B. and R. Welland, Web Engineering Security (WES) Application Survey Technical Report. 2006, Univeristy of Glasgow: Glasgow. p. 31 http://www.dcs.gla.ac.uk/publications/paperdetails.cfm?id=8287. Glisson, W.B. and R. Welland. Web Engineering Security: Essential Elements. in The Second International Conference on Availability, Reliability and Security (ARES). 2007. Vienna, Austria: IEEE http://www.ares-conference.eu/conf/index.php?option=com_content&task=view&id=7&Itemid=8. Glisson, W.B. and R. Welland, Web Survey Technical Report. 2006 Gordon, L.A., et al., 2004 CSI/FBI Computer Crime Security Survey. 2004, Computer Security Institute. p. 2-18 http://www.gocsi.com/. Gordon, L.A., et al., 2005 CSI/FBIComputer Crime Survey, in Tenth Annual. 2005, Computer Security Institute. p. 25 http://www.gocsi.com/. Graff, M.G. and K.R.v. Wyk, Secure Coding Principles & Practices, ed. D. Russell. 2003, Sebastopol, CA: O'Reilly & Associates Inc. 1-183. Gross, G., Secret Service head calls for cybersecurity cooperation. c2005, Computerworld http://www.computerworld.com/securitytopics/security/story/0,10801,101820,00.html?SKC=security-101820. Guardian Unlimited, The RIP Act. 2004, Guardian Unlimited http://www.guardian.co.uk/theissues/article/0,6512,334007,00.html. Guide, C.P., Financial Modernization Act (Gramm-Leach-Bliley Act). c2001, ConsumerPrivacyGuide.org http://www.consumerprivacyguide.org/law/glb.shtml. Hansche, S., J. Berti, and C. Hare, Official (ISC)2 Guide to the CISSP Exam. 2004, Boca Raton: Auerbach. Hare, C., Policy Development, in Information Security Managment Handbook, H.F. Tipton and M. Krause, Editors. 2004, Auerbach Publications: Boca Raton. p. 925-943. Hare, C., Policy Development, in Information Security Managment Handbook, H.F.T.a.M. Krause, Editor. c2004, Auerbach Publications: Boca Raton. p. 925-943. Hoo, K.S., A.W. Sudbury, and A.R. Jaquith, Tangible ROI through Secure Software Engineering. Secure Business Quarterly, 2001. 1(2). Hopper, D.I.a.T.B., Information Security News: Microsoft announces corporate strategy shift toward security and privacy. c2002, Insecure.org http://seclists.org/lists/isn/2002/Jan/0092.html. Hurley, E., Security and Sarbanes-Oxley. c2003, SearchSecurity.com http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci929451,00.html. ISO, International Organization for Standards, http://www.iso.org/iso/en/ISOOnline.frontpage. Jelassi, T., Strategies for e-Business. 2005, Harlow, England: Prentice Hall. Kierman, V., Plugging Holes in the Security Dike. The Chronical of Higher Education, 2004. Volume 51(Issue 7): p. A31. Knight, W. and J. Thorel, G8 nations team up to fight cyber-crime. 2000, ZDNet UK http://news.zdnet.co.uk/internet/security/0,39020375,2079018,00.htm.


[58]

[59] [60] [61] [62]

[63]

Landman, J., Forensic Computing: An Introduction to the Principles and the Practical applications. 2002, School of Computing and Mathematics, University of Western Sydney: Sydney, Australia. p. 15 http://www.cit.uws.edu.au/compsci/computerforensics/Online%20Materials/FC.pdf. Lee, Y.L., Software Security at the Summit. c2005, BZ Media LLC: New York- and California http://www.sdtimes.com/article/story-20050301-12.html. Lemos, R., International cybercrime treaty finalized. 2001, CNET Networks http://news.com.com/2100-1001268894.html. Leyden, J., Enforcement is key to fighting cybercrime. 2004, The Register http://www.theregister.co.uk/2004/07/02/cma_reform_analysis/. Lipner, S. The Trustworthy Computing Security Development Lifecycle. in 2004 Annual Computer Security Applications Conference. 2004. Tucson, Arizona: Annual Computer Security Applications Conference http://www.acsac.org/2004/papers/Lipner.pdf. Mayer, et al., The Sarbanes-Oxley Act of 2002 and its Impact on European Companies. 2002, Mayer, Brown, Rowe, and Maw: Washington, DC. p. 26 http://www.uschamber.com/NR/rdonlyres/eqhsxshd45j7rshkz56cv5byoqv74rw5whnjogdn7vuejkcgvooo3bswsxzrznogk2mx23hpiebt3a2ntaejkhwbxib/0 20925sarbanesoxley.pdf#search=%22Sarbanes-Oxley%20Act%20international%20impact%20%22.

[64] [65] [66] [67] [68] [69] [70]

McCullagh, D., Senators propose sweeping data-security bill. c2005, ZDNet News http://news.zdnet.com/21001009_22-5769156.html. McDonald, A. and R. Welland, Agile Web Engineering (AWE) Process: Perceptions within a Fortune 500 Financial Services Company. Journal of Web Engineering, 2005. 4(4): p. 283-312. McKemmish, R., What is Forensic Computing? 1999, Australian Institute of Criminology. p. 6 http://www.cit.uws.edu.au/compsci/computerforensics/Online%20Materials/ti118.pdf. Mimoso, M.S., Top Web application security problems identified SearchSecurity.com. 2003, SearchSecurity.com http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci873823,00.html?NewsEL=9.25. Mitnick, K., The art of deception : controlling the human element of security / Kevin D. Mitnick & William L. Simon. 2002, Indianapolis, Ind.: Wiley. 352. Mobbs, P., Computer Crime The law on the misuse of computers and networks. 2003, GreenNet Civil Society Internet Rights Project. http://www.internetrights.org.uk/briefings/irtb08-rev1-draft.pdf. Moteff, J., Computer Security: A Summary of Selected Federal Laws, Executive Orders, and Presidential Directives. 2004, Congressional Research Service [CRS]: Washington, DC. p. 16 http://www.fas.org/irp/crs/RL32357.pdf#search=%22National%20Information%20Infrastructure%20Protection%20Act%20of%201996%20computer%

[71] [72]

[73]

[74] [75] [76]

[77]

20summary%22. Office of the Press Secretary, President Bush Signs Identity Theft Penalty Enhancement Act. 2004, US Government: Washington, DC http://www.whitehouse.gov/news/releases/2004/07/20040715-3.html. Organization for Internet Safety, Guidelines for Security Vulnerability Reporting and Response. 2004, Organization for Internet Safety http://www.oisafety.org/guidelines/Guidelines%20for%20Security%20Vulnerability%20Reporting%20and%20Response%20V2.0.pdf. Organization for Internet Safety, Guidelines for Security Vulnerability Reporting and Response. c2004, Organization for Internet Safety http://www.oisafety.org/guidelines/Guidelines%20for%20Security%20Vulnerability%20Reporting%20and%20Response%20V2.0.pdf. Ounce Labs, Weapons for the Hunt: Methods for Software Risk Assessment. 2004, Ounce Labs, Inc. p. 114 http://www.ouncelabs.com/searchsecurity/WeaponsForTheHunt.pdf. Ozier, W., Risk Analysis and Assessment, in Information Security Managment Handbook, H.F. Tipton and M. Krause, Editors. 2004, Auerbach Publications: Boca Raton. p. 795-820. Peltier, T. Effective Risk Analysis. in 23rd National Information Systems Security Conference. 2000. Baltimore, Maryland: National Information Systems Security Confrence http://csrc.nist.gov/nissc/2000/proceedings/papers/304.pdf. Pescatore, J., Sanctum Buy Shows Security Is Key to Application Development. 2004, Gartner. p. 1-3 http://www.gartner.com/resources/122100/122128/sanctum_buy_sho.pdf.

[78] [79] [80] [81]

[82]

Pfleeger, C.P. and S.L. Pfleeger, Security in Computing. Third Edition ed. 2003, Upper Saddle River, NJ: Prentice Hall. Phaltankar, K.M., Practical Guide for Implementing Secure Intranets and Extranets. 2000, Boston: Artech House, Inc. 121-182. Plesser, R., J. Halpert, and M. Cividanes, Summary and Analysis of Key Sections of USA PATRIOT ACT of 2001. 2001, Center for Democracy and Technology http://www.cdt.org/security/011031summary.shtml. Premkumar T. Devanbu, S.S. Software engineering for security: a roadmap. in International Conference on Software Engineering Proceedings of the Conference on The Future of Software Engineering. 2000. Limerick, Ireland: ACM Press New York, NY, USA http://portal.acm.org/citation.cfm?id=336559. PricewaterhouseCoopers, The Information Security Breaches Survey 2004. 2004, PricewaterhouseCoopers.


[83] [84]

[85] [86] [87] [88]

[89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111]

Read, B., When Hackers Attack After a recent intrusion, Purdue took aggressive steps to secure its network. The Chronical of Higher Education, 2004. Volume 51(Issue 11): p. A29. Safety, O.f.I., Guidelines for Security Vulnerability Reporting and Response. c2004, Organization for Internet Safety http://www.oisafety.org/guidelines/Guidelines%20for%20Security%20Vulnerability%20Reporting%20and%20Response%20V2.0.pdf. Schjolberg, S., The Legal Framework - Unauthorized Access to Computer Systems. 2003, Moss District Court, Norway http://www.mosstingrett.no/info/legal.html. Steinke, G., Data privacy approaches from US and EU perspectives. Telematics and Informatics, 2002. 19(2): p. 193-200. Stewart, T.A., The Wealth of Knowledge. 2001, London: Nicholas Brealey Publishing. Symantec, Importance of Corporate Security Policy Defining corporate security policies, basing them on industry standards, measuring compliance, and outsourced services are keys to successful policy management., Symantec http://securityresponse.symantec.com/avcenter/security/Content/security.articles/corp.security.policy.html. Telang, R.a.S.W., ,, Impact of Software Vulnerability Announcements on the Market Value of Software Vendors - An Empirical Investigation. c2005, Carnegie Mellon University http://ssrn.com/abstract=677427. The American Heritage Dictionary of the English Language, Methodologies. 2000, Houghton Mifflin Company http://dictionary.reference.com/browse/methodologies. The State of Minnesota, H.F. No. 2121, 3rd Engrossment - 84th Legislative Session (2005-2006). 2005, Minnesota House of Representatives http://www.revisor.leg.state.mn.us. Tiller, J.S., Outsourcing Security, in Information Security Management Handbook, H.F. Tiption and M. Krause, Editors. 2004, Auerbach Publication: Boca Raton. p. 1061-1072. TranslatorCafe.com, Curency Converter. c2005, TranslatorCafe.com http://www.translatorscafe.com/cafe/tools.asp?pn=currency. UK Parliament, Computer Misuse Act 1990. 1990, Queen's Printer of Acts of Parliament: London http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_1.htm. UK Parliament, Data Protection Act 1998. 1998, Controller of HMSO: London http://www.opsi.gov.uk/acts/acts1998/19980029.htm. UK Parliament, Electronic Communications Act 2000. 2000, UK Government: London http://www.opsi.gov.uk/acts/acts2000/20000007.htm. UK Parliament, The Electronic Signatures Regulations 2002. 2002, UK Government: London http://www.opsi.gov.uk/SI/si2002/20020318.htm. UK Parliament, Malicious Communications Act 1988. 1988, UK Government: London http://www.opsi.gov.uk/ACTS/acts1988/Ukpga_19880027_en_1.htm. UK Parliament, Regulation of Investigatory Powers Act 2000. 2000, Queen's Printer of Acts of Parliament: London http://www.opsi.gov.uk/Acts/acts2000/20000023.htm. UK Parliament, The Telecommunications (Lawful Business Practice) (Interception of Communications) Regulations 2000. 2000, UK Government: London http://www.opsi.gov.uk/si/si2000/20002699.htm. United States Department of Justice, Computer Crime Policy & Programs. 2006, US Government: Washington, DC http://www.usdoj.gov/criminal/cybercrime/ccpolicy.html. US Department of Education, The Family Educational Rights and Privacy Act (FERPA), http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html. US Government, Check Clearing for the 21st Century Act. 2003, The Federal Reserve Board: Washington, DC http://www.federalreserve.gov/paymentsystems/truncation/. US Government, Electronic Signatures Act. 2000, US Government: Washington http://www.ecsi.net/help/help_esig.html. US Government, Mutual Legal Assistance Treaty Between the United States and Russia. 2002, US Government: Washington, DC http://www.state.gov/r/pa/prs/ps/2002/7734.htm. US Government, The National Strategy to Secure Cyberspace. 2003, US Government: Washington. p. 76 http://www.whitehouse.gov/pcipb/cyberspace_strategy.pdf. VentureLine, MBA Glossary. c1996-2005, http://www.ventureline.com/ http://www.ventureline.com/glossary.asp. W3C, W3C World Wide Web Consortium. c2005, W3C World Wide Web Consortium http://www.w3.org/. Walden, I., Crime and Security in Cyberspace. Cambridge Review of International Affairs, 2005. 18(1): p. 51-68. Walden, I., Harmonising Computer Crime Laws in Europe. Journal of Crime, Criminal Law and Criminal Justice, 2004. 12(4): p. 321-336. Williams, P., T. Shimeall, and C. Dunlevy, Intelligence Analysis for Internet Security, T.S. Casey Dunlevy, Editor. 2002, Routledge, part of the Taylor & Francis Group: London • New York • Oslo • Philadelphia • Singapore • Stockholm. p. 1-38.


[112]

[113] [114] [115]

Wylder, J.O., Towards Enforcing Security Policy: Encouraging Personal Accountability for Corporate Information Security Policy, in Information Security Management Handbook, H.F. Tipton and M. Krause, Editors. 2004, Auerbach Publications. p. 945-952. Zameeruddin, R., The Sarbanes-Oxley Act of 2002: An Overview, Analysis, and Caveats. c2003, University of West Georgia http://www.westga.edu/~bquest/2003/auditlaw.htm. Zegarelli, G.R., Computer Fraud and Abuse Act of 1986. 1991, BookRags & Macmillan Science Library: Computer Sciences http://www.bookrags.com/research/computer-fraud-and-abuse-act-of-198-csci-01/. Zeichick, A., Security: More Than Good Programming. c2005, BZ Media LLC: New York- and California http://www.sdtimes.com/printArticle/story-20050515-04.html;jsessionid=7AD21FBBABFF38D6127F61B13A239D23.


Web Engineering Security (WES) Process

Web Engineering Security (WES) Process

Suggest Documents

Web Engineering Security (WES) Application Survey Technical Report

Security in Business Process Engineering - Semantic Scholar

Agile Web Engineering (AWE) Process: Multidisciplinary ... - CiteSeerX

Web-Based Software Engineering Process Management - CiteSeerX

Towards a Quality-Aware Web Engineering Process

Web engineering security - University of Glasgow

Web Engineering Security: A Practitioner's Perspective

Web engineering security - University of Glasgow

Web Security

A Security Engineering Process based on Patterns - Semantic Scholar

Web Engineering

Towards a Process for Web Services Security - ACS

hybrid web engineering process model for the development of large ...

hybrid web engineering process model for the ... - Semantic Scholar

Design and Empirical Evaluation of an Agile Web Engineering Process

Requirements Engineering in the Development Process of Web Systems

engineering process for capacity-driven web services

Chapter 3 The Web Engineering (WebE) Process Classic Software ...

The Authoring Process of the UML-based Web Engineering Approach

hybrid web engineering process model for the development of large ...

Web Data Amalgamation for Security Engineering: Digital Forensic ...

&b ∑ 'Yesterdays' - Wes Montgomery Solo from the 'Wes ...

WES 344862.qxd - CiteSeerX

WES-Weihai Echelle Spectrograph