1. Assure IT’s Quality, Assure IT’s 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/testingquality/default.aspx The cost and reputation savings of avoiding a security breach are “priceless”

4. Do you know?

5. Higher-Ed Security Incidents http://www.privacyrights.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,000March 2005 Hacking 120,000 March 2005 Hacking 106,000 April 2005 Hacking 40,000April 2005 Hacking 150,000 June 2005 Dishonest Insider 72,000June 2005 Hacking 15,000 June 2005 Stolen laptop 27,000 July 2005 Hacking 42,000July 2005 Hacking 270,000 July 2005 SQL Injection 31,077 July 2005 Hacking People Date Type 36,000 August 2005 Hacking 61,709August 2005 Hacking 100,000 August, 2005 Hacking 49,000 August 2005 Hacking 100,000 Sept 2005 Stolen computer 21,762Sept 2005 Exposed Online 2,800 October 2005 Exposed Online 9,100October 2005 Exposed Online 93,000 March 2006 Stolen laptop 38,941April 2006 Exposed Online 197,000April 2006 Exposed Online 300,000April 2006 Exposed Online 41,000 March 2006 Hacking 60,000 May 2006 Hacking 180,000June 2006 Exposed Online 14,500 Sept 2006 Hacking

6. Agenda Hacking 101 7 Steps to Assure Software Quality by Integrating Security into the SDLC –Sample Checklists Useful URLs and Q&A

7. 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!)

8. 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

9. Web File Query Directory listing: http://site.com/include/file.js Truncation: http://site.com/include

10. Browser Page Caching Be aware of differences between browsers! Pages with sensitive data should not be cached: page content is easily accessed using browser’s history Use the following tags to disable page caching: - Do-not-cache tags do not apply to binary content

11. Browser Page Caching

12. 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 browser’s 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

13. 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)

14. 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/SQLInjectionWhitePaper.pdfhttp://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf –http://www.unixwiz.net/techtips/sql-injection.htmlhttp://www.unixwiz.net/techtips/sql-injection.html

15. SQL Injection Attacks Demo

18. Cross-Site Scripting (XSS) Attacks Malicious code can secretly gather sensitive data from user while using authentic website (login, password, cookie)

19. 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

20. Cross-Site Scripting (XSS) Attacks

21. 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

22. XSS: Script Injection Demo

24. 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.)

25. Agenda Hacking 101 7 Steps to Integrate Security into SDLC –Sample Checklists Useful URLs and Q&A

26. 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. Don’t assume technical staff and vendors are aware of all security issues. –Assign appropriately trained staff, mentors/reviewers

27. 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?

28. Requirements Template 1.1 User Classes and Characteristics 2.5 Design and Implementation Constraints 3.4 Communications Interfaces 5.3 Security Requirements

29. 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?

30. 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

31. Security Architecture – Multi- layer

32. Security Architecture Lifecycle – focus on Standardization

33. 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!

34. 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! SQL-Injection? –Use encrypted transmission for data retrieval and modification

35. 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

36. 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

37. 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)

38. 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

39. 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

40. 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

45. 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

46. 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 –2 week notice of all turnovers/change required and plans –Fewer “emergency” changes means fewer security vulnerabilities

47. Integrating Security into SDLC Step 7: Decommissioning Decommissioning of Application and Data Data –Retention/preservation compliance? –Sanitize media professionally, including backups 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? Update catalogue of personal data!

48. 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

49. 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

50. Agenda Summary Hacking 101 7 Steps to Assure Software Quality by Integrating Security into SDLC –Sample Checklists Useful URLs and Q&A

51. Q&A Useful Links Campus security site: http://www.security.uci.edu http://www.security.uci.edu AdCom's application security checklist: http://snap.uci.edu/viewXmlFile.jsp?resourceID=1 440 http://snap.uci.edu/viewXmlFile.jsp?resourceID=1 440 AdCom's Java code review checklist: http://snap.uci.edu/viewXmlFile.jsp?resourceID=1 529 http://snap.uci.edu/viewXmlFile.jsp?resourceID=1 529 Open Web Application Security Project (OWASP): http://www.owasp.orghttp://www.owasp.org