Application Security – It’s Not Just for

Developers Anymore

Rochester Security Summit 2017Building Cyber Deterrence

Hyatt Regency, Rochester, NY

October 19 & 20, 2017

Danny HarrisSenior Security Consultant & Instructor

dharris@securityinnovation.com

Learning Objectives

• To understand that application security involves not only everyone on the development team, but also people with responsibility for enterprise risk management

– Every role has a different set of application security responsibilities

• To understand some key application security challenges and how they can impact business

– Applications pose the biggest risk to the enterprise – more than network insecurity or other technologies

• To understand some high-impact application security activities that can make a dramatic improvement in the security of applications

2

• Agenda

• Application Security Landscape

• Application Security is a Business Risk Management Concern, not Just an IT Issue

• Risk-based Approach to Application Security

• Some Application Security Challenges

• What A Mature Application Security Program Looks Like

Applications are So Vulnerable to Compromise

• Applications are enormously complex ecosystems and are found

everywhere

– Highly-connected to internal IT systems with lots of sensitive data

– Many players and lots of moving parts

• Developed in-house, outsourced, COTS

• 3rd party components, open source

• They change frequently, requiring constant adjustments to application

security

– Business demands more bells and whistles

– Feature enhancements are prioritized ahead of security fixes

• Many applications have moved to the cloud

– Results in the loss of visibility and control over business critical applications

– Applications are often initially designed for “internal use only”

• They get “web-enabled” and exposed to the Internet

• There is a rush to get software out without adequate security testing

4

“Traditionally, software is produced in this

way: write some code, maybe do some code

review, run unit-tests, and then hope it is

correct.

Hard experience shows that it is very hard for

programmers to write bug-free software.

These bugs are sometimes caught in manual

testing, but many bugs still are exposed to

users, and then must be fixed in patches or

subsequent versions."

https://blog.mozilla.org/security/2017/09/13/verified-cryptography-firefox-57/

“One of the most critical skills of a software

developer lies in his ability to decide that the

incompleteness and inefficiency of his code

has reached a level that will be tolerated by its

clients."

http://codingismycraft.com/index.php/2017/09/27/shippin

g-buggy-code-the-most-critical-skill-for-a-programmer

Some Implications of Weak Application Security

5

http://www.thewrap.com/equifax-failed-security-patch/

https://www.usatoday.com/story/money/2017/09/11/equifax-hit-least-

23-class-action-lawsuits-over-massive-cyberbreach/653909001/http://www.nytimes.com/2012/12/10/business/global/saudi-

aramco-says-hackers-took-aim-at-its-production.html

https://www.forbes.com/sites/ericbasu/2014/06/15/target-ceo-fired-can-you-be-

fired-if-your-company-is-hacked/

Breaches

Shutting down the business

Lawsuits

Loss of “C”-level Jobs

“Most software failures and data

breaches aren’t inevitable; they are

a result of neglect and

underinvestment in product

reliability and security.”

https://www.nytimes.com/2017/09/11/opinion/equifax-accountability-security.html

Application

security is a

business issue

What is Application Security?

Many People Think it Is…

• The Security team's responsibility

• SSL and a firewall

• 30 minute application security computer-based training for developers

• A set of security requirements from the InfoSec team

• A security checklist

• Testing for the OWASP Top 10

• Vulnerability scan just prior to go-live

6

People Process

Technology

Emphasis is on tools and technology Software security is fragile

What is Application Security?

What it Really Encompasses

• All of the above and much more...

7

Risk Management ProcessSource: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf

Software security is strong and robust

Secure Software Development

Lifecycle (SDLC)

People Process

Technology

A more balanced mix of People,

Process, and Technology

Policy

• Agenda

• Application Security Landscape

• Application Security is a Business Risk Management Concern, not Just an IT Issue

• Risk-based Approach to Application Security

• Some Application Security Challenges

• What A Mature Application Security Program Looks Like

Application Security is a Business Risk Management Concern, not Just an IT Issue

• Applications are a SIGNIFICANT threat vector

– Inherent security defects that can be exploited by attackers are extremely common in applications

• This is a serious exposure for businesses

– KRACK attacks against WPA2

– The ROCA vulnerability that allows factorization of RSA keys was found in a commonly used library

• Every platform and technology carries a different set of risks

• Application security exposes the entire organization to risk

• Applications are the enterprise's biggest risk, yet less money is spent on application security

– There is little formal knowledge, expertise, and process around it

9

https://nvd.nist.gov/vuln-metrics/visualizations/cvss-severity-distribution-over-time

Distribution of Known Vulnerabilities in Software (NVD)

https://www.infosecurity-magazine.com/news/average-company-daily-web-

attacks/

Application Security Risk is Increasing

• Many organizations are unable to keep up with the increasing number of attacks and are unable to…

– Stop or curtail attacks to applications by quickly detecting vulnerabilities and threats

– Manage security of applications across the enterprise and have up-to-date visibility into what is happening in the application environment

– Ensure the protection of applications is a top security objective with an appropriate level of investment

– Respond quickly to hacker attacks against applications

– Quickly perform patches on applications in production

10

http://info.prevoty.com/hubfs/resources/Ponemon-Institute-

The-Increasing-Risk-to-Enterprise-Applications-Nov-2015.pdf

Source: Verbatim from the Ponemon study

• Why can’t organizations keep up?

– It’s really hard to write secure software

– Detection and notification of attacks is awful

• Under-trained staff

• Under-staffed organizations

• Applications and systems are not properly instrumented

– In many instances, we don’t have the data

• Attacks are fast and stealthy

– Time to compromise a system: seconds to minutes

– Time to exfiltrate data: days

– Time to discover breach: months

– There is a lack of good tools

– Policies are often weak

– People don’t know what to do or how to do it

Application Security Risk Management Challenges

• Organizations are failing to gain control over their application security risks

• Organizations follow immature risk management processes

• Accountability for the security of applications is dispersed too widely throughout the organization

• Corporate leaders underestimate application security risks

• Prevention of attacks on applications is a low priority

• Although visibility is important to securing applications, very few try to achieve it by creating an inventory of application assets

• Application security risks are not managed well

From How to Make Application Security a Strategically Managed Discipline

11

Business Responsibility for Application Security Risk

Application Security Risk Business Responsibility

12

Accountability for application security is not always clear. Who is ultimately responsible?

IT, end user, application owner

Designate an application owner who is responsible and accountable for the security of each application

Development team does not have sufficient resources to adequately design, build, test,

and deploy secure applications

Ensure that development team has sufficient resources (people, tools, training) to accomplish their goals

Network security is better funded than application security

Provide sufficient funding for application security where most of the serious vulnerabilities are found

Rapid proliferation and migration of apps to cloud and mobile reduces visibility into

application layer

Instrument and monitor cloud and mobile apps sufficiently.

Monitor runtime behavior and proactively check for attacks.

Development team does not have sufficient AppSec knowledge and skills

Provide role-based AppSec training to architects, developers, testers. Give the team the time to come up to speed. Hire staff with the right skillsets and knowledge.

Outdated or insufficiently detailed AppSec policies and standards

Ensure that current and sufficiently detailed application security policies and standards followed by the entire dev team

Insufficient application security testingConduct application security testing throughout the SDLC. Automated testing alone

does not provide sufficient code coverage. Manual security assessments are a must for any security functionality and for high risk applications.

More Application Security Risks

• Offshore, outsourced, and third-party application developers

– Do they know application security sufficiently well?

– Are there contractual requirements for them to deliver secure software?

• Third-party code, libraries, frameworks, open source software

– Legacy libraries and frameworks are often highly insecure

– Do you have a comprehensive list of what is being used and what versions?

– Security tested by your team?

– Under version control in your organization?

• Rushing to release new code

– This often results in the development team skipping or neglecting secure application development practices

• Failing to have workable and comprehensive third-party bug reporting and incident response processes

13

Why Application Security is a Business and an Information Risk Issue

• Business risk

– Operational risk

• Systems down

• Denial of service

– Financial risk

• Lost sales

• Fraud

• Regulatory and compliance fines

– Strategic risk

– Compliance/Legal risk

• PCI, General Data Protection Regulation (GDPR)

– Reputational risk

• Dealing with embarrassing breaches

• Application risk

– Fragile (insecure) code is highly prone to failure/breach

– Security debt increases without paying down the debt by fixing an ever-growing list of security defects

– Firefighting and unplanned work as a result of a breach or critical security defects in the code

– Bug fixes and patches for production applications are expensive to develop and deploy

– Data theft due to insecure applications

14

Application risk needs to

be part of the overall

business risk process

Application security is a defense against unforeseen losses that cost capital and reduce profitability

• Agenda

• Application Security Landscape

• Application Security is a Business Risk Management Concern, not Just an IT Issue

• Risk-based Approach to Application Security

• Some Application Security Challenges

• What A Mature Application Security Program Looks Like

Risk-based Approach to Application Security

Business Considerations

• Understand that it is not possible to find every security defect or keep out every attacker

– It’s about…

• Making it so challenging for attackers that they get deflated and go elsewhere

• Minimizing the impact of a breach should an attacker get through

• Detecting, responding, and cleaning up from an attack in a timely and coordinated fashion

• Security must be a topic at the corporate boardroom level

– The Board and Executives need to be security-savvy in order to make good business decisions

• Security leaders need to develop increased business literacy to more effectively communicate and understand business

leaders

– Develop an understanding application security risk and how it differs from traditional business risk

• “The risk assumed by one is shared by all” (Steve Northcutt)

– Ensure that IT and security staff effectively communicate with business leaders using familiar business language, rather than

technical jargon, abbreviations, and acronyms

• Stay out of the “weeds”

• Proactively address application security rather than just being reactive

– Conduct security activities and checks throughout the software development lifecycle

16

Risk-based Approach to Application Security

Technical Considerations

• Adopt more sophisticated security controls to help defend against threats before, during, and after

an attack

• Conduct threat modeling to find design flaws before coding begins

– Address your most critical threats which are the ones that will bring your company to it's knees

• Reduce the attack surface

– The more functionality, bloated code, and components, the greater the attack surface for attackers

• Risk rate applications

– Not all applications face the same level of risk

– Implement security controls in proportion to the risk

• Some apps only need an automated scan, others should have a comprehensive manual penetration test

– Align security efforts to application risk and criticality

17

Business Responsibility for Application Security

• Executive-level support for application security is needed to make many things happen

– Manage application security at the enterprise level as part of the overall existing enterprise risk management process and assessment programs

– Use an application risk management process to inventory and understand key information about all applications and components

– Create a budget that supports application security in proportion to the need

– Be committed to prioritize application security in proportion to the risk

– Resolve turf wars or silo issues between application development teams and IT security

– Understand current areas of high risk and what is being done to remediate it

– Prevent software with critical and high risk security defects from moving into production

– Marshall resources to help with a security incident and to fix critical security defects that are being exploited by attackers

18

Business Drivers that Impact Application Security

• Business decisions are often made without sufficient

consideration of application risk

• Functionality is prioritized over security

– User convenience and usability is often at odds

with security functionality

• Time-to-market and competitive pressures can force

the release of an application before sufficient

security testing can be done

• Application security is viewed as reducing velocity

(amount of value produced per unit time)

• The security team’s recommendations may be

ignored by the business and development teams

• Since software development is iterative, the

assumption is that security defects will eventually get

fixed at some future iteration

– Until that that time, however, the application

remains vulnerable to attack

• It is expensive and time-consuming to fix security

defects

– There is a strong incentive from the business to

let non-public security defects remain

unremediated in production systems

• This is the equivalent of a ticking time-bomb!

• Failing to really understand the full impact of security

defects in production systems

– Impact on clients, the organization, and the

application and data

19

• Agenda

• Application Security Landscape

• Application Security is a Business Risk Management Concern, not Just an IT Issue

• Risk-based Approach to Application Security

• Some Application Security Challenges

• What A Mature Application Security Program Looks Like

Some Application Security Challenges

• Organizations are trying to fight fires and fix dozens of known vulnerabilities that they know about, yet try to build

a foundation for the future

– Finding the balance is very hard

• Lack of application security training for the development team

– Most colleges don’t offer much application security education

– Stack Overflow or other similar sources do not always provide correct

information about security

• Lack of the appropriate security tools

– The right tool makes all the difference

• You can dig a ditch with a teaspoon, but it’s easier to use a shovel

– Developers and testers are prevented from using the appropriate

tools by organizational policy!

• Criminals use the same tools to attack

• Why can’t the good guys use these tools to find and fix the vulnerabilities?

– Are there enough licenses for the development team?

21

https://laurent22.github.io/so-injections/

Some Application Security Challenges

• Not doing security code reviews

– Many organizations conflate security code reviews

with standard functional code reviews

• They are very different

– Heavy reliance on just static code analysis tools

• Inadequate or no security testing

– Just testing for the OWASP Top 10

• There are hundreds of types of application security

defects

– Just running automated scans

• Automated tools cannot find certain types of serious

security defects

– Testing just before go-live

• No time to fix, or we’ll fix it later

– No security testing

• Releasing dangerous code to production

– Code with critical, high, or medium severity

security defects is a recipe for disaster

(breach)

• Bug reporting mechanism for third-parties

– Is there a documented, formal process for 3rd

parties to submit bugs?

• Security patch challenges

– Hard or impossible to do for some types of

systems (embedded)

– Fragile systems could be broken upon

installation of patches

22

How Many Security Weaknesses that Arise During Development are Your Developers Familiar With?

• The full Common Weakness Enumeration (CWE) has 1006 security weaknesses categorized and described

• 603 security weaknesses that can be introduced during development

• How many security weaknesses that can be introduced during design are your architects familiar with?

– The CWE list has 382 design security weaknesses

23

Source: https://cwe.mitre.org/data/definitions/699.html

Some Application Security Challenges

Examples of Some Common Attack Types from the Technical Perspective

• Network Attacks

– Denial-of-Service (DoS)

Attacks

– “Man in the Middle” (MITM)

Attacks

– Advanced Persistent Threat

(APT) Attacks

• Common Application Attacks

– Authentication Attacks

• Account/Session hijacking

• Default credentials

• Password cracking

• Dictionary attacks

• Credential reuse attacks

– Code Injection Attacks

• SQL injection

• Cross Site Scripting (XSS)

• XPath, XQuery and XML injection

• OS Command injection

• LDAP injection

• Null byte injection

• Buffer and memory overflows

– Privilege Escalation Attacks

24

• Weak authorization/Access Control

• Weak cryptography

• Security misconfiguration

• Parameter tampering

• Path traversal attacks

• Insecure direct object references

• Using components with known vulnerabilities

• Information leakage

• Cross-site request forgery

• Unvalidated redirects and forwards

• Denial of Service attacks

• DLL Hijacking

• Race conditions

• Buffer overflows

• Format string vulnerabilities

Examples of some of the many

technical attacks that need to be

prevented

Some Application Security Challenges

Examples of Some Common Attack Types from the Business Perspective

• Common Attacks

– “Breaking and entering”

• Stealing authentication credentials to pretend to be a legitimate user

• Gaining privileged access to the system and data

– Data attacks

• Tampering with data

• Stealing data

• Disclosing information

• Privacy violations

– Preventing legitimate users from accessing the system (Denial-of-

Service [DoS])

– Running attacker’s code on the system to force it to do the attacker’s

bidding

– Defaced website

• Business Impacts

– Data breach

• Loss of proprietary or confidential

information

– Violation of regulatory and

privacy requirements

– Lawsuits

– Loss of operational effectiveness

or disruption of operations

– Loss of business, economic loss

– Negative publicity

• Reputation impact

25

These are the kinds of attacks and impacts that business people understand

How Many Different Attack Patterns are Your Security Testers/QA Team Familiar With?

• Attack patterns are a series of repeatable steps to conduct an attack against the security of an application or system

• The full Common Attack Pattern Enumeration and Classification (CAPEC) has 566 attack patterns that are categorized and described

26

Source:

https://capec.mitre.org/data/definitions/1000.html

• Agenda

• Application Security Landscape

• Application Security is a Business Risk Management Concern, not Just an IT Issue

• Risk-based Approach to Application Security

• Some Application Security Challenges

• What A Mature Application Security Program Looks Like

What A Mature Application Security Program Looks Like

Responsibilities

• Enterprise risk management

– The application risk management process is owned by the

appropriate party (CIO, CTO, CISO, CSO, Line of Business)

– Identify all applications and assign them criticalities based on

business needs and risk

• Ensure that secure software development practices are first applied

to the highest risk applications

• Conduct security testing against the highest risk applications first

– High and medium severity security defects must get the same attention as other top priority (critical) bugs would receive

– Don’t release applications to production with serious security defects

• Insecure applications are not allowed to go live until they are fixed

• Management

– Executives

• Make application security part of the system development lifecycle, not an afterthought

– Project Managers

• Ensure development team has the appropriate resources and sufficient time to design, code, and security test (and retest) the application

28

• Everyone is responsible for application security

– Every role has a different set of application security responsibilities

What A Mature Application Security Program Looks Like

High Impact Application Security Activities by Role

• Entire Development Team

– Provide role-based application security education and training to the team

• Develop the institutional knowledge to design, build, and test secure applications

– Ensure that application security policies are current and sufficiently detailed

• Ensures team members understand expectations and know what to do

• Architects, System Designers

– Conduct security architecture reviews and threat modeling to ensure a secure

design before coding begins

– Use security story guidance from SAFECode to help integrate security stories into

sprints

29

What A Mature Application Security Program Looks Like

High Impact Application Security Activities by Role

• Software Engineers, Developers

– Ensure secure coding standards are used and enforced

– Use approved, standard security libraries, components, and frameworks for

input validation, output encoding and other security-critical activities

– Test early (while coding) to stop propagation of errors to later stages of the

SDLC where it is harder, more time consuming, and more costly to fix

– Conduct manual security code reviews and use automated static analysis

tools to find common security defects while coding

• Testers, QA

– Use the threat model to guide security testing

– Conduct application security assessments in a variety of breadth and

depth, depending on the type of application and risk

• Use tools and automation to find common security issues

• Conduct manual security testing to find complex and critical security defects

30

What A Mature Application Security Program Looks Like

Implement a Secure Software Development Lifecycle (SDLC)

• To ensure a consistent, standardized

software development process

• Example frameworks

– OpenSAMM

– Microsoft Security Development

Lifecycle (SDL)

• ISO Standards

– ISO/IEC 27034

• Information technology – Security

techniques – Application security

• Example industry guidance

– BITS Financial Services Roundtable

Software Assurance Framework

– NIST SP 800-64 Security

Considerations in the System

Development Life Cycle

31

https://www.owasp.org/index.php/OWASP_SAMM_Project#tab=Downloads

https://www.microsoft.com/en-us/sdl/

High-Impact Application Security Activities

• Incrementally add software security practices to the existing SDLC

– These are often low to moderate cost

• Implement security engineering activities

– Identify security objectives

– Apply security design guidelines

– Conduct security architecture & design reviews

– Create threat models as part of the technical risk management program

– Conduct static code analysis as part of the build process

• Security engineering activities (continued)

– Perform manual security code reviews

– Perform security testing

• Manual penetration testing

– Boundary, edge, and corner testing

• Regression tests

• Fuzzing

• Unit and integration testing

– Change and release management

• Define vulnerability (security defect) severity

• Define security release criteria (bug bar)

• Conduct security deployment reviews

• Use tools to help with automation

32

• These high-impact application security activities help to reduce application security risk

Summary

• Applications are a very significant threat vector

– Complex, with lots of components and moving parts

– Notoriously hard to secure

• Insecure applications can affect the entire organization

– Application security risk is also a business responsibility, not just an IT concern

• The business needs to support application security as a part of the organization’s risk management practice

– Be committed to providing tools, training, and resources to design, build, test, and maintain applications

– Understand application security risk and how it differs from traditional business risk

• Prevent applications from moving to production with significant security defects

• Periodically focus on reducing security defects from the backlog

• Integrate application security risk into the organization's risk management process

• Implementing a variety of security engineering practices throughout the SDLC can reduce application risk by

ensuring applications have fewer serious security defects

33

Contact Information

Danny Harris

Senior Security Consultant and Instructor

Security Innovation

dharris@securityinnovation.com

http://www.securityinnovation.com

34