Web Development Evolution: The Assimilation of Web Engineering Security

1. Web Development Evolution: The Assimilation of Web Engineering Security Brad Glisson and Ray Welland Department of Computing Science Glasgow University glisson@dcs.gla.ac.uk Department of Computing Science

2. Market Indications • The 2004 Computer Security Institute (CSI)/Federal Bureau of Investigation (FBI) Computer Crime and Security Survey estimates that losses from internet security breaches, in the US, exceeded $141 million within the last year. • The Departmentof Trade and Industry’s Information Security Breaches Survey 2004 by PricewaterhouseCoopers indicates that security problems are on the rise in the United Kingdom and that malicious attacks are the primary culprits. • The Department of Trade and Industry’s (2004) survey estimates “security breaches continue to cost” UK businesses “several billions of pounds”. • The Deloitte 2005 Global Survey estimates that identity theft cost the UK almost a billion dollars in 2003. glisson@dcs.gla.ac.uk Department of Computing Science

3. Organization for Internet Safety (OIS) • “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”. glisson@dcs.gla.ac.uk Department of Computing Science

4. Common Application Security Problems • Un-validated parameters • Cross-site scripting • Buffer overflows • Command injection flaws • Error-handling problems • Insecure use of cryptography • Broken Access Controls glisson@dcs.gla.ac.uk Department of Computing Science

5. Problem 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 upfront by explicitly stating the security approach in the methodology. This deficiency creates an environment conducive to security breaches. Exploitation of these breaches translates into staggering corporate financial losses. glisson@dcs.gla.ac.uk Department of Computing Science

6. WES Solution My PhD research has produced a possible solution, A Web Engineering Security (WES) Methodology. An independent flexible Web Engineering development methodology that is specific to security. • The process needs to be compatible with existing application development processes so that they are complementary, hence • Deliverables between phases will vary on the size of the organizational and the methodology they are implementing, and • Flexible enough to be tailored to individual companies of varying size. glisson@dcs.gla.ac.uk Department of Computing Science

7. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

8. Project Development Risk Assessment • NIST - National Institute of Standards and Technology - agency of the U.S. Commerce Department'sTechnology Administration. • COBRA - Security risk analysis application • OCTAVE - Operationally Critical Threat, Asset, and Vulnerability Evaluation - Focuses on organizational risk and strategic, practice-related issues, balancing operational risk, security practices, and technology. • FRAP - Facilitated Risk Analysis Process glisson@dcs.gla.ac.uk Department of Computing Science

9. Project Development Risk Assessment • Detail critical functions • Determine the necessary service levels. • Identify possible threats • outline their motivating factors • Estimate the probability of attack • Estimate the probability of a successful attack • Detail the cost of providing protection. glisson@dcs.gla.ac.uk Department of Computing Science

10. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

11. Application Security Requirements • Security Policy Compatibility • Acceptable application computing practices • interactions with the network, internet, messaging, and business specific applications or services • interactions with internal companies, outside communities, vendors, and customers • Corporate Culture Compatibility • General security practice education • Managerial acceptance and habits • Social engineering (human element) attacks • Technological acceptance of corporate norms • Technological Compatibility • Organization’s existing applications, software compatibility, legacy systems and the acquisition of new software and technology. • Technical Skills within the company • Existing security solutions glisson@dcs.gla.ac.uk Department of Computing Science

12. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

13. Security Design / Coding Address issues • Technology that is currently deployed in the organization • Take advantage of existing security tools within the organization • The best realistic design solution that meets the organization’s needs • Coding Standards • Secure coding practices • Implementation of time tested security functions • Data security glisson@dcs.gla.ac.uk Department of Computing Science

14. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

15. Controlled Environment Implementation • Separate PC • Complete Environment that Mirrors Production • Point is to make sure new software is compatible with the existing environment glisson@dcs.gla.ac.uk Department of Computing Science

16. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

17. Testing • Application Testing • End User Testing • Automated Scripts • Penetration Testing • Incident Management • Will / When? • How do you handle? • Disaster Recovery • News glisson@dcs.gla.ac.uk Department of Computing Science

18. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

19. Web Engineering Security (WES) Process glisson@dcs.gla.ac.uk Department of Computing Science

20. End User Evaluation • Critical to the success of the solution • Solution is too secure & end users are not using it? • Solution not secure enough? glisson@dcs.gla.ac.uk Department of Computing Science

21. Agile Web Engineering (AWE) glisson@dcs.gla.ac.uk Department of Computing Science

22. AWE & WES Comparison glisson@dcs.gla.ac.uk Department of Computing Science

23. Conclusions • Technical solutions alone will not solve current security issues in the global web environment. • Increasing business pressures will force organizations to address application security from a development perspective • The most effective way to handle security, in the application design, is to incorporate security upfront into the development methodology. glisson@dcs.gla.ac.uk Department of Computing Science

24. Contact Details Brad Glisson, Department of Computing Science, University of Glasgow E-mail: glisson@dcs.gla.ac.uk. Web: www.dcs.gla.ac.uk/~glisson/ Prof. Ray Welland, E-mail: ray@dcs.gla.ac.uk. Web: www.dcs.gla.ac.uk/~ray/ glisson@dcs.gla.ac.uk Department of Computing Science

25. Application Security Confidentiality – Proper access is restricted to the appropriate individuals. Integrity – modification of assets by the appropriate personnel & within guidelines. Availability - Access is available to the appropriate parties at designated times. [i] [i] Pfleeger, Charles P. and Shari Lawrence Pfleeger. Security in Computing Third Edition. Prentice Hall Saddle River, NJ. 2003. pg 10. glisson@dcs.gla.ac.uk Department of Computing Science

26. Relevant Work • Secure Software Comprehensive Lightweight Application Security Process (CLASP) • Microsoft’s Trustworthy Computing Security Development Lifecycle • Security Patterns - “A methodology for secure software design”.[2] [2] Fernandez, E.B. A methodology for secure software design. in Procs. of the 2004 Intl. Symposium on Web Services and Applications (ISWS'04). c2004. Las Vegas, NV. http://polaris.cse.fau.edu/~ed/EFLVSecSysDes1.pdf. glisson@dcs.gla.ac.uk Department of Computing Science

27. Definitions • Unvalidated Input 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. • Broken Access Control Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files, or use unauthorized functions. • Broken Authentication and Session Management Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users’ identities. • Cross Site Scripting (XSS) Flaws The web application can be used as a mechanism to transport an attack to an end user’s browser. A successful attack can disclose the end user’s session token, attack the local machine, or spoof content to fool the user. • Buffer Overflows 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. These components can include CGI, libraries, drivers, and web application server components. • Injection Flaws Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application. • Improper Error Handling Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. • Insecure Storage Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. • Denial of Service Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail. • Insecure Configuration Management Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box. The Open Web Application Security Project (OWASP). The Ten Most Critical Web Application Security Vulnerabilities. c2004 • http://www.owasp.org/index.jsp glisson@dcs.gla.ac.uk Department of Computing Science

28. Additional Support • R.F. Darcy’s report on Information Security indicates that: • patch management is critical in mitigating cyber vulnerabilities • number of security vulnerabilities reported is increasing and attacks are becoming automated • Conclusion • no longer be assumed that security will be addressed in the acquisition of the functional or non-functional requirements • surveys indicate that there are fundamental security problems with the methodologies being used in real world web application development glisson@dcs.gla.ac.uk Department of Computing Science