W16 INTEGRATING SECURITY INTO THE DEVELOPMENT LIFECYCLE. Ryan English SPI Dynamics Inc BIO PRESENTATION 6/28/2006 3:00 PM

(1)

BIO

PRESENTATION

Better Software Conference June 26 – 29, 2006 Las Vegas, NV USA

W16

6/28/2006 3:00 PM

I

NTEGRATING

S

ECURITY INTO

THE

D

EVELOPMENT

L

IFECYCLE

Ryan English SPI Dynamics Inc

(2)

Ryan English

Ryan English is the group product manager for SPI Dynamics' QAInspect(tm) Quality Assurance Security testing product line, overseeing product strategy and direction for the company's five Quality Assurance products. Prior to joining SPI Dynamics, Ryan was responsible for product management at Live Oak Technologies, a quality assurance software company. In addition, Ryan was a project manager for the supply chain software company VerticalNet, where he assisted in the strategic growth and

development of their consulting division. Ryan has also led project management teams with MCI Worldcom and DayNine. Ryan is a seasoned speaker on the topic of security testing Web applications in QA and has spoken at several Quality Assurance industry events including Mercury World 2005.

(3)

Ryan English – Group Product Manager

ASAP – Integrating Security

into the Development

(4)

History of Web Applications

Web Server HTML

Browser

(5)

Web Application Architecture

Browser Web Servers Presentation Layer Media Store Database Server Customer Identification Access Controls Transaction Information Core Business Data Wireless Web Services Application Server Business Logic Content Services

(6)

Web Applications Breach the Perimeter

Internet

DMZ

Trusted

Inside

Corporate

Inside

HTTP(S) IMAP FTP SSH TELNET POP3 Firewall only allows PORT 80 (or 443 SSL) traffic from the Internet to the web server. Any – Web Server: 80 Firewall only allows applications on the web server to talk to application server. Firewall only allows application server to talk to database server. IIS SunOne Apache ASP .NET WebSphere Java SQL Oracle DB2

(7)

The State of Application Security

2000 ₂₀₀₆

Web application security programs

– Enabled across the software development lifecycle (SDLC)

– Leverage automated assessment software

– Involve cross functional teaming

– Require executive sponsorship

Networks Secured, Applications Vulnerable Early Adopters Begin Manual Application Testing Certain industries make automated application assessments standard practice

These early adopter industries establish application security

(8)

The State of Application Security

“Over 70 percent of security vulnerabilities exist at the application

layer, not the network layer”

Gartner

“The battle between hackers and security professionals has moved

from the network layer to the Web applications themselves“

Network World

“Hacking has moved from a hobbyist pursuit with a goal of notoriety

to a criminal pursuit with a goal of money”

Counterpane Internet Security

“64 percent of developers are not confident in their ability to write

secure applications”

(9)

The State of Application Security

Britain warns of

major e-mail attack

Hackers seen aiming at

government, corporate networks

The Associated Press

Updated: 1:42 p.m. ET June 16, 2005

40M cr

edit

cards h

acked

Breach at third p

arty payment processor

affects 22 million Visa cards and 14 mil lion MasterCards. June 20, 2005: 3 :18 PM EDT By Jeanne Sahadi,

CNN/Money seni

or writer

In 2004, 78% of enterprises hit by viruses, 49% had laptops stolen, 37% reported

unauthorized access to information

(10)

Web Application Vulnerabilities

Administration

Platform

Application

Web application vulnerabilities

occur in three major areas:

(11)

Web Application Vulnerabilities

Platform

Platform:

• Known vulnerabilities can be exploited immediately with a minimum amount of skill or experience – “script kiddies” • Most easily defendable of all web

vulnerabilities

• Must have streamlined patching procedures

• Must have inventory process

Examples:

IIS UNICODE

(12)

Administration:

• More difficult to correct than known issues

• Require increased awareness

• More than just configuration, must be aware of security flaws in actual content • Remnant files can reveal applications and

versions in use

• Backup files can reveal source code and database connection strings

Web Application Vulnerabilities

Administration

Examples:

Extension Checking

Common File Checks Data Extension Checking

Backup Checking

Directory Enumeration

Path Truncation

Hidden Web Paths

(13)

Web Application Vulnerabilities

Application

Examples:

Application Mapping

Cookie Manipulation

Custom Application Scripting

Parameter Manipulation

SQL Injection

Hidden Web Paths Forceful Browsing

Application:

• Coding techniques do not include security • Input is assumed to be valid, but not tested • Inappropriate file calls reveal source code &

system files

• Unexamined input from a browser can inject scripts into page for replay against later visitors

• Unhandled error messages reveal application and database structures • Unchecked database calls can be

‘piggybacked’ with a hacker’s own database call, giving direct access to business data through a web browser

(14)

Network

What is a Web-Based Application?

• What is the data path (Network) for web applications? • How does a web-based application work (HTTP)? • How does your application work?

HTTP

(15)

How Do Web Applications Communicate?

Network

HTTP

Web Application

(16)

Request Response Server www.mybank.com (64.58.76.230) Port: 80 Client PC (10.1.0.123)

How Do Web Applications Communicate?

Network Layer

• Client connects to the server • Client sends request to server • Server responds to client

• Connection is disconnected – HTTP is stateless

(17)

Securing the Network Layer

SSL Tunnel Server www.mybank.com (64.58.76.230) Port: 443 Client PC (10.1.0.123)

• SSL (Secure Sockets Layer)

– Provided encryption of data between a client

and server

– Typically guarantees to client that server is

who it asserts itself to be

(18)

Securing the Network Layer

SSL Tunnel Server www.mybank.com (64.58.76.230) Port: 443 Client PC (10.1.0.123) • SSL • Firewalls

– Allows or disallows traffic to pass from the external network to the internal network

– Acts as a “traffic cop”

– Port 80 (HTTP) and port 443 (HTTPS) travel freely through the firewall

(19)

Securing the Network Layer

• SSL

• Firewalls

• IDS (Intrusion Detection System)

– Monitors network for malicious activities – Typically signature based detection

(similar to virus protection) – Blind to encrypted (SSL) traffic

IDS SSL Tunnel Server www.mybank.com (64.58.76.230) Port: 443 Client PC (10.1.0.123)

(20)

What is HTTP?

Network

HTTP

(21)

(22)

People: Providing guidance on

secure application development

Tools: Providing the most

innovative tools

Process: Security cannot be an

afterthought

(23)

Education

Train every Developer and IT Professional on security

Patterns & Practices

Dedicated team focused on security guidance

MSDN and TechNet

Sharing whitepapers and “how tos”

(24)

Accountability and Incentives

• Microsoft Developer Research: Almost 40 percent of developers say that their companies do not think it is “very important” to write secure applications

• CXOs and management say it is very important • Current incentives on performance and ship dates • Must be driven top-down

(25)

Application Security Assurance Program

Maturity Model & Best Practices

(26)

Application Security Assurance Program (ASAP)

TECHNOLOGY PEOPLE PROCESS

Organizational Silos Cross-Functional Teams Management Executive Buy-in, Integrated Organization Integrated Development & QA Tools Security Department Testing Tools Policy-driven Secure SDL Developer Awareness Technical & Management Curriculum Proactive & Strategic Reactive & Tactical

• ASAP Maturity Model is about defining a roadmap and execution of the SDL

• Organizations should implement their own Trustworthy Computing Initiative tailored to their own needs

• Describes the programs needed to integrate security throughout the software development lifecycle and throughout the production lifespan of the application

• A holistic program providing end to end lifecycle coverage while spanning People, Process and Technology

(27)

Proactive & Strategic Reactive & Tactical

ASAP Maturity Model

Level 1: Reactive & Tactical

Organizational Silos Security Department Testing Tools Characterized By: • Security team finds

application vulnerabilities from initial scanning efforts • Most vulnerabilities require

development fixes

• Vulnerability reports sent to development

• Development pushes back due to short timelines & business impact of security rework

• Due to a lack of application security training, issue

acceptance and resolution is difficult

(28)

ASAP Maturity Model

Level 2: Planned & Purposeful

Organizational Silos Cross-Functional Teams Integrated Development & QA Tools Security Department Testing Tools Developer Awareness Characterized By:

• Security team conducts assessment

• Developers trained on security

• Vulnerabilities still require development fixes

• Vulnerability reports sent to development

• Now, developers understand the issues

• The development process still doesn’t include

proactive secure development.

(29)

ASAP Maturity Model

Level 3: Proactive & Strategic

Organizational Silos Cross-Functional Teams Management Executive Buy-in, Integrated Organization Integrated Development & QA Tools Security Department Testing Tools Policy-driven Secure SDL Developer Awareness Technical & Management Curriculum Characterized By: • Vulnerability management software used across SDLC • Security processes in place

across SDLC

• Security integrated into entire development lifecycle • All levels of the organization

committed to security • Complete security

(30)

Requirements Design Development QA Test Release Support & Services

Regulatory Compliance

Infrastructure assessment

Automated assessment tools

Security services Pen Testing Security training Security kickoff Infrastructure Design Development assessment tools QA assessment tools Create development standards Threat Modeling Secure code library

Source code review

ASAP Best Practices

(31)

Effective ASAP Implementations

Executive Sponsorship

• Must obtain senior level management sponsorship

• Must assess potential impacts to application development efforts

• Must clearly communicate criticality of ASAP

• Management must understand that ASAP is not a project, it will be integrated into

the existing processes in the SDLC

(32)

Security Kickoff

• Establish ASAP team – Development – Quality

– Security

– Audit, Risk, etc.

• Identify checkpoints in the SDLC where security will be reviewed • Establish rapport

– Processes are made up of people

– This is a team with common goals, not a boxing match

(33)

Security Training

• Identify development and quality team

• Define appropriate training levels for team members • Provide general secure coding training

• Provide company and department specific training • Company / department standards

• Proper use of libraries and objects

(34)

Create Development Standards

• Standards should define how critical activities are done. – Database access

– Authentication / Authorization – Encryption

– Etc.

• Standards should be:

– Clear and include specific examples

– Concise, people will read or much less follow a long winded policy

(35)

Threat Modeling

• The process of identifying critical components of a system, where and how an attack is most likely to occur and where such an attack would be the most effective

• Taking this information and using it to ensure that high risks scenarios are protected against

• Advantages

– Practical attackers view of the system – Flexible

– Early in the SDLC • Disadvantage

– Relatively new technique

– Good threat models don’t automatically mean good software

(36)

Infrastructure Design

• Infrastructure considerations – Network design – Firewalls – IDS – SSL use – Data Encryption – Authentication Infrastructure – Single sign on

• Understanding what each security measure does and does not do is critical

(37)

Infrastructure Design

• Infrastructure considerations: – Network design – Firewalls – IDS – SSL use – Data Encryption – Authentication Infrastructure – Single sign on

• Understanding what each security measure does and does not do is critical

(38)

Secure Coding libraries

• Libraries should provide a consistent method of – Validating user input

– Not limit developer functionality by changing the development process

– Detecting ongoing attacks and protecting the application from these attacks • Libraries can be either commercial or custom built

(39)

Source Code Review

• Source code review is the process of manually checking a Web applications source code for security issues

• Advantages:

– Many bus or “backdoors” can only be found via source code review – Can provide a very detailed review of application functionally

• Disadvantages:

– Requires highly skilled security developers – Can miss calls to issues in compiled libraries – Cannot detect run-time errors easily

– Time consuming and tedious

(40)

Development Assessment Tools

• Process of testing a running application

• Typically involves exercising the application in it’s normal operating mode, taking note of pages, parameters, cookies, and other data being passed to and from the application, then sending malformed versions of the information to the application to see what errors are generated • Advantages:

– Tools can be integrated directly into existing development environments – Can be done during development, test and pre-production

– Will show many “as-built” security vulnerabilities that were a result of bugs or un-designed features – Can be done rapidly with the addition of appropriate tools

• Disadvantages:

– Can miss some types of security issues that can be discovered by other means (i.e., Source code review) – When done manually, the process can be very time consuming

(41)

QA Automated Assessment Tools

• Tools should be able to leverage existing QA assets for the purposes of security testing

– Login scripts

– Functional test scripts – Defect tracking system

• Tools should integrate directly it the existing QA testing suite and compliment the existing process

• Should not overly burden the QA team with additional tests • Should not require extensive application knowledge

(42)

Penetration Testing

• Penetration testing is the practice of utilizing a specialist in the area of application security to attempt to breach an applications security measures

• The goal is to gain confidence that a hacker could not breach the security measures that have been put into place

• Penetration testing provides a “real-world” view of the application and it’s associated risks

(43)

Automated Assessment Tools

• Provides automated, ongoing assessment of web based applications to ensure that new attack methodologies will not make existing applications vulnerable.

• Ensure that applications are secure prior to going live. This is the last line of defense and is a place to “double check” the process.

• These tools should scale to handle the demand an enterprise will put on it’s web application assessment assets.

(44)

Infrastructure Assessment

• Network scanning • IDS • Database scanning • SSL • SSL accelerators • Password crackers • Etc.

(45)

Regulatory Compliance

• Compliance will effect all aspects of the SDLC

• Compliance may have specific or implied requirements that effect how software is architected and the features that must be included

– Audit requirements

– Security & Access control requirements • Regulations

– HIPAA, GLBA, SOX, CA1386, etc. – Federal Trade Commission (FTC)

(46)

Session Summary

• Effectively dealing with application security issues is a process level issue, not simply a code issue.

• Integrating security in to the SDLC (ASAP Programs) allow companies to integrate security into there processes and gain a mature level of security without undue effect on the overall process.

• ASAP must be a management level initiative due to the effect it will have on the entire SDLC.

(47)