application security lessons from the pro’s how leading us online banks secured their applications...

Post on 18-Jan-2018

216 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

R 237 G 228 B 192 R 181 G 170 B 127 R 171 G 181 B 158 R 221 G 232 B 217 R 128 G 128 B 128 R 54 G 54 B 54 R 237 G 228 B 192 R 92 G 86 B 64 R 68 G 79 B 75 R 8 G 74 B 88

TRANSCRIPT

Application Security Lessons from the Pro’s

How leading US online banks secured their applications

Rob RachwaldAugust 2007

Software isn’t complete unless its secure

Wii Olympics & Free Beer(Boxing and Tennis)

Fortify & Watchfire

Tonight: 5 PMMaryland Room B & C

Prizes includeWii

iPod Shuffles

Evidence

Less HackingOnly 8% top of US banks reported external hacks

against their systems yet 2006 was the worst year for web application hacking in history. (Gartner

2007)New Forms of Attacks

Required60% of banks report suffering from phishing attacks—security burden is on authentication

and fraud detection. (Gartner 2007)

Weaker Banks Targeted

Hackers are targeting smaller banks with few resources with hacking and phishing schemes.

(Gartner 2007)

Better Perception

68 percent of respondents believe that their financial institutions’ websites are more secure.

(Comscore Networks, April 2007)

Total online banking customers at the top 10 online banks surpasses Internet growth with 44M

users. (Comscore Networks, April 2007)

Strong Growth

Banking Online is Safer than Banking Offline?

Around 75% of Fraud is

Offline

Less than 15% of Fraud is

Online

Can You Trust Your Mom?

Can You Trust Your Mom?

I want your I want your passwordpassword

The Hackers

Followers(thousands and growing)

“Oceans 1100”

Hacker Economics

“The potential gain from even one successful computer intrusion makes [hacking] an attractive,

relatively low-risk option… and the risk to sensitive information on US computer systems will increase.”

—US Defense Security Service, 2007

Defensive Economics

“If the bear continues biting you long after you assume a

defensive posture, it likely is a predatory attack.

Fight back vigorously.”

Online Banking Defensive Economics

Don’t Run Fast, Just Faster

Complex Code

Applications addressingPersonal bankingRetirement accountsStocksLoansCredit cardsLots more

BIG: Online banking apps often 10 million lines of codeLots of Java and .NETLarge attack surface

Hundreds of applicationsThousands of entry points

Other Top Hacks

Cross-Site Scripting

Biggest avenue for phishing.

SQL InjectionLarge attack surface and obtaining bits of customer data are critical in executing attacks.

Privilege Escalation

Horizontal or vertical escalations are especially pernicious. Authentication and fraud detection technologies are critical.

OWASP Top 10

They never go out of style.

The Software Security Problem

"Since most security for Web applications can be implemented by a system administrator, application developers need not pay attention to the details of securing the application…"

– BEA WebLogic Server Security Documentation

Stage 1: Reactionary

Code Developed Unit Tests Functional

Tests Production

Description

Mature SDLC for delivering functional requirements. Security=cryptography, authentication systems, etc.

Obstacles Security knew production would get hacked successfully—had a difficult time getting executive mindshare.

Approach Security and Incident Response teams conduct emergency meetings with developers, sys admins, and executives to create a tactical solution to solve the immediate threat.

Cost Most expensive security solutionLoss of revenue from system downtimeDamage to brandUnscheduled development time

Stage 2: Apply band aids

Code Developed Unit Tests Functional

Tests Pen Test Production

Description

Put in mitigating solutions before the hackers succeed.

Obstacles Pen testing did add value, but was it enough (the badness-ometer)?

Is there a clear indication of risk exposure?Is the application fundamentally more secure?Solving the illness or just treating the symptoms?Where is the application broken?How many areas are truly at risk?

Approach Security and Incident Response teams conduct pen tests, executives paying attention, but not fully involved.

Cost Still reactive and very expensiveConstantly putting out firesPagers going off constantly at 2 AMLow team morale

Stage 3: Beyond the badness-ometer

Code Developed Unit Tests Functional

TestsPen Test ProductionCode

Reviews

Description

Manual code reviews to look for problems.

Obstacles Finds useful issues, but doesn’t scale.Incomplete coverageMiss complex issues

Approach Developers finally given exact areas within the code base to fix and provided an opportunity to remediate the root cause of the vulnerabilities.Implement a gate model, secure strong executive support

Cost Expensive, still had to put out fires, but much more manageableReduced the amount of vulnerabilities discovered by pen

testing

Stage 4: Teach a Man to Fish

Code Developed

Static Analysis

Functional Tests

Pen Test ProductionCode

ReviewsUnit Tests

Description

Continued to produce vulnerabilities, only catching them earlier. Not sustainable.

Obstacles Education needed: fewer bugs are produced by smarter developers.Introduced training focused on developing software securelyThis differs from training on developing security softwareDevelopers embraced the knowledge and rarely produced the

same errors.

Approach Moved the software scanning earlier in the development cycle.

Cost Still expensive because still producing vulnerabilities.

Stage 5: Homo securus

Devs Trained

Code Developed

Code Reviews Productio

nUnit Tests

Pen & Function

al

Static Analysi

sDescription

The target SDLC was a self-sustaining system with C-level executive support.

Approach Security team moves on to:Oversee the secure SDLC processConduct periodic reviewsPerform in-depth, detailed analysis of projectsNo longer distracted by “low-hanging fruit” issues

Cost Zero S1 vulnerabilities in the system.Overhead from application security significantly reduced

Challenges Remain

New Web 2.0, SOA=Same problems all over again

Hacker sophistication continues to rise, especially phishing attacks

Keeping developer mindshare

Ensuring 3rd party code is secure (remember BEA?)

Lessons

Security requires executive initiative

Security is a programming problem

Security is a process: Define a Secure Development Lifecycle (SDL) and implement it

Don’t forget the whitepaperRob Rachwaldrr@fortify.com

(650) 213-5683

Fortify Within the Secure Software Lifecycle

Fortify SCA Dev Proactive security with targeted, accurate analysis tuned for low false positives

Fortify SCAAnalyzes code comprehensively and accurately

Developers

Fortify Tracer & Watchfire AppScanThorough black box application security testing

Fortify TracerMakes every black box security test measurable and actionable

Security Testers

Fortify DefenderMonitors and measures web applications in production

Security Ops Team

Security Leads / Auditors

Fortify ManagerCentral reporting and management of software security across the enterprise

Management

Build Server

FPR

Fortify SCA

Wii Olympics & Free Beer(Boxing and Tennis)

Fortify & Watchfire

Tonight: 5 PMMaryland Room B & C

Prizes includeWii

iPod Shuffles

Thanks

Software isn’t complete unless its secure

top related