Assure IT

1

• Assure ITs Quality, Assure ITs Security, or
  Throw IT Out!
• Joshua Drummond, Security Architect
• Katya Sadovsky, Application Architect
• Marina Arseniev, Associate Director of Enterprise
  Architecture
• University of California, Irvine

2
University of California, Irvine

• Located in Southern California
• Year Founded  1965
• Enrollment over 24K students
• 1,400 Faculty (Academic Senate)
• 8,300 Staff
• 6,000 degrees awarded annually
• Carnegie Classification  Doctoral/Research
  Extensive
• Extramural Funding - 311M in 2005-2006
• Undergoing significant enrollment growth

3
Do you know?

• 75 of attacks today happen at the Application
  (Gartner). Desktop augmented by Network and then
  Web Application Security.
• Many easy hacking recipes published on web.
• 3 out of 4 vendor apps we tested had serious SQL
  Injection bugs!
• The cost of correcting code in production
  increases up to 100 times as compared to in
  development...
• (1) MSDN (November, 2005) Leveraging the Role
  of Testing and Quality Across the Lifecycle to
  Cut Costs and Drive IT/Business Responsiveness
• http//msdn.microsoft.com/vstudio/why/testingquali
  ty/default.aspx
• The cost and reputation savings of avoiding a
  security breach are priceless

4
Do you know?
5
Do you know?
6
Higher-Ed Security Incidentshttp//www.privacyrig
hts.org

• People Date Type
• 178,000 April 2004 Hacking
• 380,000 May 2004 Hacking
• 207,000 May 2004 Stolen laptop/Hack
• 600,000 Sept 2004 Hacking
• 98,400 March 2005 Stolen laptop
• 59,000 March 2005 Hacking
• 120,000 March 2005 Hacking
• 106,000 April 2005 Hacking
• 40,000 April 2005 Hacking
• 150,000 June 2005 Dishonest Insider
• 72,000 June 2005 Hacking
• 15,000 June 2005 Stolen laptop
• 27,000 July 2005 Hacking
• 42,000 July 2005 Hacking
• 270,000 July 2005 SQL Injection
• 31,077 July 2005 Hacking

• People Date Type
• 36,000 August 2005 Hacking
• 61,709 August 2005 Hacking
• 100,000 August, 2005 Hacking
• 49,000 August 2005 Hacking
• 100,000 Sept 2005 Stolen computer
• 21,762 Sept 2005 Exposed Online
• 2,800 October 2005 Exposed Online
• 9,100 October 2005 Exposed Online
• 93,000 March 2006 Stolen laptop
• 38,941 April 2006 Exposed Online
• 197,000 April 2006 Exposed Online
• 300,000 April 2006 Exposed Online
• 41,000 March 2006 Hacking
• 60,000 May 2006 Hacking
• 180,000 June 2006 Exposed Online
• 14,500 Sept 2006 Hacking

7
Agenda

• Hacking 101
• 7 Steps to Assure Software Quality by Integrating
  Security into the SDLC
• Sample Checklists
• Useful URLs and QA

8
What do Hackers do?

• A few examples of Web application hacks
• File Query
• Browser caching
• Cookie and URL hacks
• SQL Injection
• Cross-site Scripting ( 1 threat today!)

9
Web File Query

• A hacker tests for HTTP (80) or HTTPS (443)
• Does a View Source on HTML file to detect
  directory hierarchy
• Checks for directory listings or enumeration
• Can view sensitive information inadvertently left
  by system administrators or programmers
• Database passwords in /include files
• Data files with SSNs in /data directories

10
Web File Query

• Directory listing http//site.com/include/file.js
  
• Truncation http//site.com/include

11
Browser Page Caching

• Be aware of differences between browsers!
• Pages with sensitive data should not be cached
  page content is easily accessed using browsers
  history
• Use the following tags to disable page
  cachingltMETA HTTP-EQUIV"Pragma"
  CONTENT"no-cache"gtltMETA HTTP-EQUIV"Cache-Contro
  l" CONTENTno-store, no-cache"gtltMETA
  HTTP-EQUIV"Expires" CONTENT"-1"gt
• - Do-not-cache tags do not apply to binary content

12
Browser Page Caching
13
Cookies and URLs

• Sensitive data in cookies and URLs?
• Issues that arise are
• Information is stored on a local computer (as
  files or in the browsers history)
• Unencrypted data can be intercepted on the
  network and/or logged into unprotected web log
  files
• To prevent unauthorized data access
• Do NOT store sensitive data of any kind in
  cookies or URLs
• Use non-persistent cookies (that disappear once a
  browser is closed) instead of persistent ones.
• Use HTTP POST instead of GET when submitting data

14
SQL Injection Attacks

• SQL injection is a security vulnerability that
  occurs in the database layer of an application.
  Its source is the incorrect escaping of
  dynamically-generated string literals embedded in
  SQL statements. (Wikipedia)

15
SQL Injection Attacks

• Example of attack
• SQL Query in Web application code
• SELECT FROM users WHERE login userName
  and password password
• Hacker logs in as or --
• SELECT FROM users WHERE login or
  --' and password
• Hacker deletes the users table with or
  DROP TABLE users --
• SELECT FROM users WHERE login or
  DROP TABLE users --' and password
• SQL Injection examples are outlined in
• http//www.spidynamics.com/papers/SQLInjectionWhit
  ePaper.pdf
• http//www.unixwiz.net/techtips/sql-injection.html

16
SQL Injection Attacks Demo
17
SQL Injection Attacks Demo
18
SQL Injection Attacks Demo
19
Cross-Site Scripting (XSS) Attacks

• Malicious code can secretly gather sensitive data
  from user while using authentic website (login,
  password, cookie)

20
Cross-Site Scripting (XSS) Attacks

• Modified URL
• URL parameters are modified on the URL to contain
  script code
• Input is not validated and displayed as entered
  on the resulting dynamic webpage

21
Cross-Site Scripting (XSS) Attacks
22
Cross-Site Scripting (XSS) Attacks

• Script Injection
• Same as before, but instead of placing code in
  URL, script code is saved on the application
  website and stored in database using their own
  non-validated forms
• When that data is retrieved from database and
  users load that webpage the code executes and
  attack occurs
• User would never know the code was executed
  without viewing the source of each webpage, since
  the link looks valid
• The application website owner is potentially
  liable since the attack code is stored on their
  site

23
XSS Script Injection Demo
24
XSS Script Injection Demo
25
Preventing SQL injection and XSS

• SCRUB Error handling
• Error messages divulge information that can be
  used by hacker
• VALIDATE all user entered parameters
• CHECK data types and lengths
• DISALLOW unwanted data (e.g. HTML tags,
  JavaScript)
• ESCAPE questionable characters (ticks,
  --,semi-colon, brackets, etc.)

26
Agenda

• Hacking 101
• 7 Steps to Integrate Security into SDLC
• Sample Checklists
• Useful URLs and QA

27
Integrating Security into SDLC Step 1 Training

• If users are not educated on security concerns,
  regulations, and laws, any system will fail.
• Email will be unintentionally used to transmit
  regulated or confidential information
• Private data will be entered into a text field
• Train Project Leaders, Programmers and Business
  units on data security and policy.
• Dont assume technical staff and vendors are
  aware of all security issues.
• Assign appropriately trained staff,
  mentors/reviewers

28
Integrating Security into SDLC Step 2
Requirements

• Acquisition or development
• Identify Security requirements at requirements
  gathering phase
• Examples of questions to ask and put into formal
  template?
• Any personal or confidential data?
• Compliance requirements PCI, SB1386, FERPA,
  HIPAA?
• If 24/7 uptime is required with clustering and
  load balancing, think about logging requirements
• do logs need to be centralized? easily audited
  for forensics analysis?
• Retention period? Tamper-proof?
• Risk assessment normal or high risk
  application?

29
Requirements Template

• 1.1     User Classes and Characteristics
• ltIdentify the various user classes that you
  anticipate will use this product (i.e. users
  doing updating vs. users with browse access
  only). User classes may be differentiated based
  on frequency of use, subset of product functions
  used, technical expertise, security or privilege
  levels, educational level, or experience...gt
• 2.5     Design and Implementation Constraints
• ltDescribe any items or issues that will limit
  the options available to the developers. These
  might include corporate or regulatory policies
  interfaces to other applications specific
  technologies, tools, and databases to be used
  communications protocols security
  considerations.gt
• 3.4     Communications Interfaces
• ltDescribe the requirements associated with any
  communications functions required by this
  product, including e-mail, web browser, network
  server communications protocols, electronic
  forms, and so on. Define any pertinent message
  formatting. Identify any communication standards
  that will be used, such as FTP or HTTP. Specify
  any communication security or encryption issues,
  data transfer rates, and synchronization
  mechanisms.gt
• 5.3     Security Requirements
• ltSpecify any requirements regarding security or
  privacy issues surrounding use of the product or
  protection of the data used or created by the
  product. Define any user identity authentication
  requirements. Refer to any external policies or
  regulations containing security issues that
  affect the product. Define any security or
  privacy certifications that must be satisfied.gt

30
ASP Vendor Security Checklist

• What certification or audits does the University
  have that the system will be managed per our
  guidelines and contract agreement?
• How do you manage the system for detection of
  intrusion.
• How often is the system patched, by whom and
  when?
• How are we notified if system security is
  breached? Notification handling?
• How is data purged from the vendor's hardware?
• How are disks, tapes, or computers that might
  store sensitive data disposed of? Are the media
  erased before disposal or reuse?
• Where is the hardware location? Is it inside or
  outside of the United States? Is it subject to
  our laws?
• Are the personnel who administer and use the
  hardware located within the United States and
  subject to our laws?

• Is data encrypted?
• If private data is transmitted, either via
  Internet, on CD-ROM or file transfer, is it
  encrypted?
• Is SSL enabled to the application so that traffic
  over the Internet, including authentication is
  secure and private?
• Data loss, data backups what are the guarantees?
  Are backups stored offsite? If backups have
  sensitive data, are the backups encrypted? Can we
  store the backup at UCI? How about disaster
  recovery planning?
• How is the hardware or database distributed by
  the vendor among customers? Is one hardware used
  for all customers? Is a single database used for
  all customers or does each customer have a
  private database?
• How are user accounts managed?

31
Integrating Security into SDLC Step 3
Architecture and Design

• Dedicate a Security role in your organization
• Security Architecture must
• address and support multiple layers of
  protection, including database, network level,
  operating system, and application level security
• be flexible to support the introduction and/or
  integration of new technologies
• provide a modular approach to authentication,
  authorization, and audit

32
Security Architecture Multi-layer
33
Security Architecture Lifecycle focus on
Standardization
34
Security Architecture Design

• Consider security during initial system design
• Delegate access control as appropriate
• Centralize security policy, maintenance operation
  and oversight functions
• Assign security levels consistently and at the
  lowest level of access required by the individual
  
• Identify vulnerable points. Design and reuse
  common and tested components
• Consolidate storage of sensitive data
  important!

35
Storing sensitive data

• AVOID storing sensitive data if at all possible!
• If you have to store sensitive data
• Encrypt table records and/or files that contain
• password, SSN, home phone/address, credit card,
  bank account, Driver's License, non-public
  student or employee data, or FERPA blocked
  student data
• Encrypt storage at database/file and application
  layer
• Database encryption is not enough! Protects from
  lost/stolen disk or backup, not from
  SQL-Injection hack attack
• Multi-layer security protection - User account
  breach wont allow decryption
• Use encrypted transmission for data retrieval and
  modification

36
Data modelling

• When designing database tables
• No confidential data elements should be used as
  keys in tables (e.g. SSN)
• Normalize to consolidate confidential data into a
  single table
• Audit ONE table, not many
• Encrypt ONE table, not many
• Mock intruder alert drills and prepare!
• Review logs for forensics capability

37
Integrating Security into SDLC Step 4
Implementation

• Implementation/Acquisition make security
  routine
• Require code reviews of all security and database
  code
• Require developers to build unit test harnesses
• Junit
• Require developers to reuse security components
• Single-signon, authorization API, user identity
  objects
• Automate nightly code and application security
  scanning
• Jtest, AppScan, WebInspect, Nessus, database
  security scanning
• Schedule network configuration vulnerability
  scanning
• Foundstone, Sophos virus scans, Tripwire
• De-identify confidential test data
• Write and use manual security test procedures
• Perform concurrency and stress testing
• Jmeter, OpenSTA (100s of concurrent virtual test
  user load)

38
File and directory security risks

• Use operating system encryption capabilities to
  protect files with private data
• Make sure that
• Read/Write/Execute access on Files and
  Directories is correct
• Sensitive files (i.e. passwords, SSN) are not
  world readable and are not located in Web
  accessible directories or sub-directories
• Sensitive data such as passwords, SSN, account
  number is encrypted in files and/or databases
• Log files are not world readable (keep in mind
  that URL query strings from GET requests are
  logged to a file)

39
Communication between distributed components

• Document how the data is used by each component
• Transmissions/exchanges of private information
  must be encrypted using protocols like
• HTTPS
• SFTP
• SSH
• STunnel
• VPN
• How does an application or component authenticate
  to another service?
• Always use a POST method when your forms submit
  any private information

40
Functional Testing

• Do you use formal Test Plans or AdHoc? Tied to
  Security Requirements?
• Done by developers and end users?
• Do Pilot Users test methodically using Test
  Plans?
• How do you ensure testing coverage is adequate?
• SQL Injection and XSS testing
• Browser Compatibility Testing (ex browser cache)
• Regression testing

41
Sample Checklists

• Portal (SNAP) SDLC Documentation
• SDLC Process
• Requirements Sections of our template address
  specific security requirements.
• Project Plan includes review schedule.
• Development / Vendor Selection Guidelines
• Database Review, SQL Server Setup Checklist
• Code Review Checklist, Test Templates
• Security Manual Test Procedure
• Security Assessment and Checklists
• Architecture Review

42
(No Transcript)
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
Integrating Security into SDLC Step 5 Deployment

• Create secured test and production environment
• Cross train Helpdesk, Sys Admin, support staff
• Market Application security risks and policy
• Consider policy to disallow confidential data on
  laptops or other portable devices
• Professionally administered system and data
  backups?
• backups identify compromised individuals
• Off-site backups? Where? At home?
• Disaster recovery plans?

47
Integrating Security into SDLC Step 6
Operations/Maintenance

• Catalogue and inventory use of personal data
• Repeated routine reviews and scanning
• Apply all security patches at all architectural
  layers in a timely manner
• OS, Firewall, Database, Platform
• Audit/log access to confidential data
• Change control
• Weekly meeting for all developers and
  administrators
• 2 week notice of all turnovers/change required
  and plans
• Oracle Calendar used to publish schedule. Reduced
  collisions
• Fewer emergency changes means fewer security
  vulnerabilities

48
Integrating Security into SDLC Step 7
Decommissioning

• Decommissioning of Application and Data
• Data
• Retention/preservation compliance?
• Properly dispose hardware and software
• Does data retention period collide with a
  software end-of-life? Clipper/DOS 6.2?
• Can OS and hardware run it today if necessary to
  restore data? Is data warehousing required?
• Sanitize media professionally, including backups
• Update catalogue of personal data!

49
Our Change Control Process

• Coordinate and schedule changes in network,
  database, applications, OS, firewalls and
  configurations
• avoid downtime due to collisions
• avoid accidental security exposures
• We use Oracle Calendar
• All developers, system and network admins meet
  every Tuesday morning for at least 15 minutes!
• 2 week notice of all planned changes
• Test Plan and security checklist required
• High/low risk identified on all changes
• Changes recorded in ServiceDesk

50
Summary of Tools to Try

• Unit Test
• Junit for Java, Integrated with Eclipse
• Code Scanning
• JTest
• Application/Network/Web Scanning Tools
• Foundstone, SiteDigger, AppScan, Nessus
• Load/Stress Test
• OpenSTA, JMeter
• Database Scanning
• Microsoft Analyzer
• Wiki

51
Agenda Summary

• Hacking 101
• 7 Steps to Assure Software Quality by Integrating
  Security into SDLC
• Sample Checklists
• Useful URLs and QA

52
QA

• Useful Links
• Campus security site http//www.security.uci.edu
• AdCom's application security checklist
  http//snap.uci.edu/viewXmlFile.jsp?resourceID144
  0
• AdCom's Java code review checklist
  http//snap.uci.edu/viewXmlFile.jsp?resourceID152
  9
• Open Web Application Security Project (OWASP)
  http//www.owasp.org