Building an Application Security ProgramMike SpauldingDirector of Security Strategy & Architecture*Company Confidential*

Disclaimer

All information within this session is presented AS-IS, if you do something foolish with the

presented material resulting in your termination of employment, imprisonment, etc –

THAT IS FULLY YOUR BURDEN

THINK BEFORE YOU ACT!

The path of least resistanceMalicious users exploit flaws that are not discovered during development and attempt to bypass security controls in order to gain access to systems and services to steal data, disrupt operations, extort money, etc.

Application Security Threats

The following are examples of known security threats:

• Connected Car Vulnerabilities• Attacks on Critical Infrastructure• Attacks on the Internet of Things• Cyber Attacks on

Smart Manufacturing Systems• OWASP Top 10 Web Vulnerabilities• Watering Hole Attack• External Hostile Attacks• Internal Malware Attacks• Cryptography Vulnerabilities• DoS and DDoS Attacks• Buffer Overflows• etc., etc., etc.

4

OWASP Top 10 Vulnerabilities

A1 Injection

A2 Broken Authentication and Session Management

A3 Cross-Site Scripting (XSS)

A4 Insecure Direct Object References

A5 Security Misconfiguration

A6 Sensitive Data Exposure

A7 Missing Function Level Access Control

A8 Cross-Site Request Forgery (CSRF)

A9 Using Known Vulnerable Components

A10 Unvalidated Redirects and Forwards

AppSec Objective

It seems simple, but too many security peeps over think this and let scope creep destroy their program.

The goal of Application Security is to reduce the risks within an

application!

Methods of AppSecDynamic Assessment

Static Assessment

It is important to understand the difference between application security, penetration testing, and vulnerability management. Too often, others

blur these areas.

Static Analysis (Code Testing)The objective of performing a code scan/assessment is to locate portions of the code where common secure coding errors exist. The truth is that most developers are never shown how to code securely. In many situations, developers are being pushed to complete too much too fast and mistakes are made.

Static code analysis should not only pinpoint the issue but suggest most optimal solution to resolve the issue. This approach will also be used as a training method for developers.Sanitizing data input from end users is

critical. The less restrictive the data input, the greater the opportunity for

abuse.

Dynamic AnalysisThe objective of performing a dynamic test is to attempt to verify the effectiveness of the secure coding testing. This verification step is necessary in order to ensure that sections of code were not assessed or code that is ‘assumed’ to be clean is verified.This testing is partially interactive, the goal is to

complete this testing as automated as possible and to investigate the delta between dynamic and static

testing.

The vulnerability testing ensures that no two components, along with the application when

placed together do not create known vulnerabilities.

Components of AppSecWeb Applications

Client Server Applications

Mobile Applications

Middleware Applications

Cryptographic Analysis

Manual testing is in many cases what slows down the assessment process. Overtime, as the developers get

better conditioned on expectations, this time will decrease.

Manual VerificationThe objective of performing a final manual test is to ‘smoke-test’ the final product and ensure that any anomalies discovered during prior assessment phases are verified to be closed, corrected, and no longer pose a threat.

AppSec KPIs & metrics define critical feedback information to check the status of a program and make further decisions on improvements actions.

Kaizen: Continuous ImprovementAnnual Assessments:

• Internet Facing Apps• RTO 0 Apps• Apps containing

PII/PHI/PCI/IP

Adhoc Assessments:• New Applications• Apps going through

significant upgrades• Emerging

Technology

We could spend another hour just talking about these topics, but unfortunately we do not have the time. These topics are just as important as those covered

more in-depth today.

Additional ConsiderationsStaffing:

• Training• Liaison, Lead Analysts, Security Testers• Resource Management

Operational Security• Application Firewall• Data Loss Prevention

Vendor Management• Application Security Tools• Consulting Services

4 Steps to AppSecStart Simple, Start Small

Set Policies & Standards, Start Metrics

Scale AppSec to your SDLC

Scan Third Party Applications

Stolen from Chris Wysopal of Veracode

http://www.darkreading.com/application-security/simplifying-application-security-4-steps-/a/d-id/1324254?_mc=RSS_DR_EDT

Start Simple, Start SmallThe vast majority of companies simply do not understand what many of us (Security People) do.

Most CISO’s don’t get it!

Too often IT peeps think technical and cannot convey the risks well enough to the business.

* Remember the business wants to reduce costs and sell more ‘widgets’ they don’t care about security until it is too late!

Your greatest ability to influence a project starts here – the business does not like surprises – do not tell them at the 11th hour (Implementation):

“Hey NASA, we have a problem”!

Why Policies & Standards MatterDuring two phases, AppSec will have it’s greatest influence:Project DefinitionSystem Overview

Too many security/IT peeps underestimate the power of metrics. Metrics or reporting show

effort (and hopefully a reduction in risk!Remember the arrow should go down to the

right!

Why Metrics MatterFrom a budget standpoint you have to show a Return On Investment (ROI)

Define your security ROI with AppSecProduce metrics consistently – weekly, monthly

Align AppSec with SDLC

Align AppSec with SDLCAppSec process defines a set of activities at each phase of SDLC

1. Assistance during architectural solution definition

2. Assistance during high-level and low-level design

3. Static code (application) security scanning

4. Dynamic application security scanning

5. Web/mobile vulnerability security scanning

6. Manual testing

Align AppSec with SDLC• It is critical that your alignment with the SDLC is

practical – it is far worse to over-engineer!

• Of course under-engineering is bad, but over-engineering can lead to your program getting canceled.

3 4

5 6

1 2 2 4

All too often third parties do not perform the necessary security verification that we all

assume that they do.Again, AppSec is an expense – unless you care,

they won’t perform this function.

Trust but Verify …Once your program is off and running assessing your internal applications .. Where will the risk move to?Ask for the opportunity to assess (always ask – as you could get sued – See Slide 2!)Require that the vendor perform verification (build this into your procurement process – business function)

There is (perceived) significant overlap between QA and AppSec – it is vital to differentiate this and advise management that their objectives

are entirely different!

AppSec Program ExpansionConsiderations:

If you do not have a formal Quality Assurance Program, stand one up!If you do not have an internal Red Team (PenTest), stand one up!

Shameless Plug:

BSides Columbus 2017

January 2017 (intentionally will avoid ShmooCon weekend)• Three Tracks of Security Goodness

Sweet Badges, Food, Much Fun!Doge Approved!

Upcoming Talks:• BSides Charm 2016 (Baltimore):

- Security Automation• Somewhere later this Summer, who

knows!

Feel free to get LinkedIn or hit me up on Twitter: @fatherofmaddog