TPR1: Web Application Security From Incident to Implementation

1
TPR1 Web Application Security From Incident to
Implementation
2

• What we will be talking about
• A story of unsavory events our security
  incident
• Our resultant process what weve done and how
  weve gone about doing it
• What we wont 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?

4
(No Transcript)
5

• NSIT / Web Services
• https//webservices.uchicago.edu/
• As the Universitys 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

8

9

• Mid May, 2005

10

• 6/6/2005 h_at_x0r3d!

11

12

13

14

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

15

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/resource
  s/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, well
  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.