Reviews To The Rescue: Using SDLC Checklists and Reviews to Avert Security Flaws

Reviews To The Rescue:Using SDLC Checklists and Reviews to

Avert Security Flaws

Katya Sadovsky, Application Architect

University of California, Irvine

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

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”

Agenda

• Hacking 101

• Using Reviews and Checklists to assure security

• Useful URLs and Q&A

Do you know?

Do you know?

Higher-Ed Security Incidentshttp://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,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

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

Web File Query

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

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:

<META HTTP-EQUIV="Pragma" CONTENT="no-cache"><META HTTP-EQUIV="Cache-Control" CONTENT=“no-store, no-cache"><META HTTP-EQUIV="Expires" CONTENT="-1">

- Do-not-cache tags do not apply to binary content

Browser Page Caching

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

SQL Injection Attacks

Web App

Hacker

Uses SQL scriptinjection to

access data

“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)

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.pdf – http://www.unixwiz.net/techtips/sql-injection.html

SQL Injection Attacks Demo

SQL Injection Attacks Demo

SQL Injection Attacks Demo

Cross-Site Scripting (XSS) Attacks

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

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

Cross-Site Scripting (XSS) Attacks

Web App

Hacker

Injects scriptinto web site

CompromisedWeb App

Retrieves compromisedpage content

Unknowinglyexecutes script

End User

XSS: Script Injection Demo

XSS: Script Injection Demo

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

Agenda

• Hacking 101

• Using Reviews and Checklists to assure software security

• Useful URLs and Q&A

Our Goal

• Make security routine– Integrate security checking into every phase of

the software development cycle

Reviews

Quality Control Steps and Reviews• Steering group review & approval• Initial architectural review before requirements are

finalized• Preliminary application review (database review,

requirements review, process flow)• GUI reviews• Design reviews• Security review• Code reviews (ongoing)• Documentation review

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

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?

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?

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

Security Architecture – Multi-layer

U serIden tity M anagem ent

A u then tica tionE duca tion

N etw ork /W ebA ccoun t A dm in

F irew a lls , E ncryp tionLogg ing/A ud iting

A p plicationA u tho riza tionLogg ing /A ud it

T est T oo ls

D ataA u tho riza tionLogg ing /A ud it

E ncryp tion ,Inven to ry

O p era tio nsB ackups ( inc l o ff-s ite)

Logg ing /A ud itD isaste r R ecove ry

P o licies , S tan d ard s , P ro ced ures , T ech n ica l R efe ren ce A rch itec tu reA pp roved T oo ls and L ifecyc le

E xcep tions by A pp rovalR egu la rly rev iew ed

Security Architecture Lifecycle – focus on Standardization

Design & 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

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?

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

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!

Useful Links

• Campus security site: http://www.security.uci.edu

• UC Irvine's business portal: http://snap.uci.edu

– Project Development main menu: http://snap.uci.edu/viewXmlFile.jsp?resourceID=1433

– AdCom's application security checklist: http://snap.uci.edu/viewXmlFile.jsp?resourceID=1440

– AdCom's Java code review checklist: http://snap.uci.edu/viewXmlFile.jsp?resourceID=1529

• Open Web Application Security Project (OWASP): http://www.owasp.org