1.
Building an Application
Security Program
Mike Spaulding
Director of Security Strategy & Architecture
*Company Confidential*

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

3.
The path of least resistance
Malicious 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.

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

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

6.
Methods of AppSec
Dynamic Assessment
Static Assessment
It is important to understand the difference between
application security, penetration testing, and vulnerability
management. Too often, others blur these areas.

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

8.
Dynamic Analysis
The 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.

9.
The vulnerability testing ensures that no two
components, along with the application when placed
together do not create known vulnerabilities.
Components of AppSec
Web Applications
Client Server Applications
Mobile Applications
Middleware Applications
Cryptographic Analysis

10.
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 Verification
The 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.

11.
AppSec KPIs & metrics define critical feedback information to
check the status of a program and make further decisions on
improvements actions.
Kaizen: Continuous Improvement
Annual Assessments:
• Internet Facing Apps
• RTO 0 Apps
• Apps containing
PII/PHI/PCI/IP
Adhoc Assessments:
• New Applications
• Apps going through
significant upgrades
• Emerging Technology

12.
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 Considerations
Staffing:
• Training
• Liaison, Lead Analysts, Security Testers
• Resource Management
Operational Security
• Application Firewall
• Data Loss Prevention
Vendor Management
• Application Security Tools
• Consulting Services

13.
4 Steps to AppSec
Start 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

14.
Start Simple, Start Small
The 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!

15.
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
Matter
During two phases, AppSec will
have it’s greatest influence:
Project Definition
System Overview

16.
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 Matter
From a budget standpoint you have to show
a Return On Investment (ROI)
Define your security ROI with AppSec
Produce metrics consistently – weekly, monthly

17.
Align AppSec with SDLC

18.
Align AppSec with SDLC
AppSec 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

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

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

21.
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
Expansion
Considerations:
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!

22.
Shameless Plug:
BSides Columbus 2017
January 2017
(intentionally will avoid ShmooCon weekend)
• Three Tracks of Security Goodness
Sweet Badges, Food, Much Fun!
Doge Approved!

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