TPR1: Web Application Security From Incident to Implementation

1. TPR1: Web Application SecurityFrom Incident to Implementation

2. What we will be talking about: • A story of unsavory events: our “security incident” • Our resultant process: what we’ve done and how we’ve gone about doing it What we won’t be talking about in great detail: • Specific examples of web application security (XSS, SQL Injection, etc.) • Security concerns for specific technologies (.NET, SQL Server, etc.)

3. Who Do We Think We Are?

5. NSIT / Web Services https://webservices.uchicago.edu/ • As the University’s central web group, we design, build, and support websites and web applications for the University community. • We design and develop usable, accessible, and attractive web sites. We provide services ranging from user-centered design to process analysis & systems architecture. • Departments (units) consult and collaborate with us to determine how web technologies can improve and expand their business processes. • We are part of the University community and use our broad perspective on University processes to produce flexible, scalable, sustainable, and secure applications. We are well positioned to facilitate connections and collaboration between departments, units, and divisions.

6. Scott Bassett Assistant Manager of Programming Cornelia Ann Bailey Assistant Director

7. A Story of Unsavory Events…

9. Mid May, 2005

10. 6/6/2005 h@x0r3d!

14. "The cost of building websites has increased." -- Our Senior Director

16. + =

17. SANS training for entire programming staff!!!!

18. Security reviewer

19. Incident like this will make it clear that security is important. Not left up to the imagination. • Focused on retooling our process. • Even though we've purchased tools to help out, education/research of the people coding and evaluating sites is key.

20. WHAT IS A SECURITY POLICY? Sans basic policy definition: “A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an "Acceptable Use" policy would cover the rules and regulations for appropriate use of the computing facilities.” • From the Sans website http://www.sans.org/resources/policies/ • So you want to write a policy: http://www.sans.org/resources/policies/Policy_Primer.pdf • Different from a “standard” or “guidelines” or “best practices”

21. WHAT IS A SECURITY POLICY? Our definition: We are still developing a formal security policy – can be a long, arduous task. An abridged approximation of our security policy would go something like: “We will use knowledge and process to ensure that our web applications are secure in how they handle data and how users interact with them. We will also strive to incorporate the best known practices and existing security standards into our development and security review processes.” • Very basic, general statement: the actual policy would obviously be more in-depth and feature sets of requirements.

22. WHY DO I NEED A SECURITY POLICY? • To have a formal collection of ideas in place regarding what is a critical aspect of your development process. • To have a clear and concise list of ideas that will help to forge best practices, coding standards and security protocols.

23. CONCEPT OF TRUST Sans talks about levels of trust: • Trust everyone all of the time • Trust no one at no time • Trust some people some of the time We have opted for the third option, but have some measures in place that lean toward the second option. We feel this is a good compromise for the second option, but, by its definition, it is an impossible standard to achieve.

24. POLICY REQUIREMENTS Straight from Sans Policy Primer (policy for policies): Policies must: • be implementable and enforceable • concise and easy to understand • balance protection with productivity Policies should: • state reasons why policy is needed • describe what is covered by the policies • define contacts and responsibilities • discuss how violations will be handled

25. POLICY REQUIREMENTS • We already have a lot of the previously mentioned ideas documented under miscellaneous security policy categories within our departmental Wiki. • This has worked well for us, but at some point, we would like to author a specific document or collection of documents that encompass the entire policy including our best practices and standards.

26. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 1 • Post-security incident, we applied quick fixes to “important sites” and did not have a chance to formally investigate a robust policy and process. We needed to hack-proof our sites as soon as possible and simply did not have the time to go through an in-depth evaluation. • We realized that eventually this would become necessary and have done our best to become educated, create documentation and enforce a loose collection of standards and policies.

27. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 2 • Initially, we began coming up with a bunch of documentation as to what specifically should be done to our web applications (checks for XSS, SQL injection, etc.) to ensure that they are as secure as we know how to make them when they are pushed into production. • Documentation started out as Word/Excel files, but became messy, disorganized and out-of-date. • We moved the documentation over to a searchable Wiki – this was a central repository with versioning that could be updated and modified at any time. This has worked out well for us thus far.

28. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 3 • In addition to the Wiki, we also have a mailing list and a “Tech note:” protocol where reminders and best practices are sent. This listhost has a high visibility for our developers and the “Tech notes” serve as constant reminders of our policy and best practices. • Eventually, we would like to come up with a more robust means of dispersing information such as policy updates, best practices and points of discussion. Our Wiki has worked out well for us, but it is still a pain to wade through documentation and we lack a good method (Tech notes are sent to a “general” mailing list) for informing our developers of updates, etc. • We believe that an RSS feed would be a good means of dispersing this information and are investigating this as a possible solution.

29. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 4 • Enforcing that policies and best practices are being implemented by developers can be a difficult task. • Levels of trust as Sans discusses can be difficult to assign and can cause a breakdown in the enforcement of policy. • We have a formal security review process in place (see diagram 1-13). This is required for all websites that undergo new development or substantial redevelopment. Incorporate both manual and automated security checks – eyeballing based on standards and Web Inspect.

30. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 5 • For sites that undergo minor changes (1 or 2 pages modified, small changes to a db proc, etc.) we have an abridged process that involves eyeballing and checking code against standards. A decision is made by the security reviewer/manager of programming. • Breakdowns in process enforcement: sometimes necessary to have overrides, exceptional cases if we are at a fixed deadline. In such cases, we’ll review the site ASAP after it goes into production and use IP restrictions on administrative sites. • Sometimes time constraints and extenuating circumstances force a breakdown in process – we try to be on top of these issues when they occur.

31. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 6 • Refactoring old/outdated code is an important issue. Being that our policies are dynamic and we have had our security review process in place for over a year now, certain sites have become “out-of-date” with our current policies and best practices. • No formal schedule for this: usually triggered by redevelopment, new development (normally triggers a new security review) or when a developer has spare time.

32. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 7 • It may seem obvious, but it is important to be knowledgeable about your specific development environments. With each new article, blurb or snippet about security issues that we come across, we must stop and ask how critical this is to our web applications. • A decent amount (but not a wealth) of information is available for web applications security. There are many general topics of which it is important to be aware, but there are also numerous platform-, os-, database-, programming language-specific concerns.

33. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY - 8 • Style versus standards: the great dilemma. We have tried to standardize on several best practices all without compromising the stylistic approaches of our developers. We realize that developers write code in different ways and we try to avoid being invasive. • However, for our security review process to work, we need to ensure that certain things are done the same way all of the time. • Dealing with outside policies: our umbrella group (NSIT) is authoring a series of global security maxims for use throughout the university. Eventually, we will incorporate the ideas from this policy into our own policies.

34. ISSUES THAT WE HAVE RUN INTO DURING OUR JOURNEY – 9 • Problems with our web applications that cannot be caught via our manual and automated security review processes. • Example: specific code logic. Fabled example – shopping cart with hidden values that store the price of an item. • Recently we had an issue that resulted in a security incident, but was not caught via our review process. It was a specific bug in our testing logic that was compensatory for the divide in our dev and prod data. We are now working to implement a check in our security review process that will account for issues of this nature.

35. GETTING STARTED • A commitment to web applications security must be made. Unfortunately, this was pretty easy for us due to our security incident. • “I AM the IT department” – not everyone has the luxury (or hindrance) of working in a large IT department. • Dollar amounts: can we afford to get hacked? Unfortunately a "security incident" usually needs to occur... • Research: staying up-to-date is critical. • Education is a must; whether you want spend $$$$$ or your spare time.

36. QUESTIONS? COMMENTS? • How can I get started? • What are good resources? • I really enjoyed/hated your presentation.