create code confidence for better application security

Create code confidence for better application security

June 11, 2015

SC Congress Toronto 2015

Jeff Hildreth, Automotive Account Manager

Rogue Wave Software

Presenter

How many people are

ready for a sales pitch?

Agenda

• We’re all saying the same thing

• Wrangling order from chaos

• A holistic approach to cybersecurity

• Take action!

• Conclusions: Managing your Supply Chain

• Q&A

We’re all saying the same thing

Network intrusions

6© 2015 Rogue Wave Software, Inc. All Rights Reserved.

Information theft


Outside reprogramming of systems


Code vulnerabilities


© 2014 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS RESERVED 10

“We all clearly created these presentations in a vacuum because we’re all using the same material.”

IQPC Automotive Cyber Security Summit, two months ago

Develop a specific strategy that fits into what we’re already doing

Be different

You have the tools already


Wrangling order from chaos

Look at the data you’re already faced with:

1000s of bugs

How do you handle this information overload?

Run time simulation

testing

Customer defects

Avg. number of security

risks:

22.4

Safety requirements


Security overload

News

Blogs, social media

conferences

Security standards

OWASP, CWE, CERT, etc.

Senator Markey report

NVD, White Hat, Black Hat OEMs, internal

Media More and more software running inside your car

Standards and legislation

Research Requirements

Developers don’t know security(80% failed security knowledge survey)

Where do organizations fail?

Organizations have failed to prevent attacks

Lack of time Lack of focus/ priority

Lack of tools/proper

tools

Survey:1700 developers,

80% of them incorrectly answered

key questions surrounding the

protection of sensitive data

SQL injectionUnvalidated

input Cross-site scripting

Most breaches result from input trust issues

Heartbleed: buffer overrun

BMW patch: HTTP vs. HTTPS

© 2015 Rogue Wave Software, Inc. All Rights Reserved. 9

What are the risks?

• Risks

include

Network intrusion

Information theft

Outside reprogramming of systems

Code vulnerabilities


All of the supply chain needs to be secure, not just your code but the code of the packages included in your software

Follow a well-known security standard applicable to your domain

What can you do?

Need to “bake in” security

Educate the development team, provide security based training, guidance and checklists

Automate!

15

Perform Threat Assessment

© 2015 Rogue Wave Software, Inc. All Rights Reserved.

Do you agree that

security testing adds 25%

of time to your release

schedule?

Accept

Sprint 1

Sprint 2

Sprint n Release

ChangeAdjust and Track

FeedbackReview

Next Iteration

No!

Yes!Release

to Market

Integrate and Test

Integrate and Test

Integrate and Test

Agile Development – Integrated Security

Characteristics• Multiple testing

points• Rapid feedback

required• “Outside” testing

does not meet agile needs

Idea proposed

Understand Needs & Invent

Solutions

Develop, Commit &

Build

Functional Testing

Deploy Solution

Customer Value

Load, Performance,

Security, … Testing

UAT/ Exploratory

Testing

Release

Decision

• Too Much WIP

• Inability to quickly try out ideas

Lack of access to dev & test environments

• Lack of effective build/integration automation

• Manual testing• Design complexity

Lack of effective API-driven test automation

Lack of effective release candidate quality information

Manual environment management and deployment

Lack of effective customer insight

Ever-present bottlenecks: hand-offs and wait time

Typical bottlenecks

Smaller batches/ payload (Agile)

Infrastructure As Code, Environments On Demand, Cloned/ TemplatedEnvironments

• Continuous Integration

• Continuous Testing• Loose architectural

coupling

Continuous Testing

Sufficient test data to make decisions

• Infrastructure as Code

• Release Automation

Application analytics, CX data

Everywhere: Cross-functional teams, simplified roles

Idea proposed


Solutions

Develop, Commit &

Build

Functional Testing

Deploy Solution

Customer Value

Load, Performance,


UAT/ Exploratory

Testing

Release

Decision

Enablers

A holistic approach to cybersecurity

© 2014 ROGUE WAVE SOFTWARE, INC. ALL RIGHTS

RESERVED

20

Threat Model

Internal Threat Metric

External Data

Action

Information overload Develop an adaptive threat model


Threat model

Scanning to discover open

Threat modelling identifies, quantifies, and addresses security risks by:

1. Understanding the application & environment2. Identifying & prioritizing threats3. Determining mitigation actions

Identify Assets

System Overview

Decompose

ApplicationIdentify Threats

Prioritize

Threats

External data sources


Standards• Common Weakness

Enumeration (MITRE)• Open Web Application

Security Project (OWASP)• CERT (Carnegie Mellon

University)

National Governing Bodies

CVE database National Vulnerability

Database OEM RFP requirements

ResearchWhite Hat/Black Hat

University studies

Media

Development Team

Would you agree that

customer requirements

have the biggest

influence on your

decisions on security

requirements?

Internal metrics


Testing

Automated unit testsHardware in the Loop (HIL) testing

Security Team

Penetration tests

Open source scanning

Software Tools

Static Code Analysis (SCA)Compiler warnings

Requirements

Development Team

Developing a Threat Metric


RESERVED25

Build Score

• Automated and functional testing can give you a pass fail metric on

every run of the test suite

• A metric can be generated from penetration testing based on the

number of exploitable paths in your code base

• Software quality tools can give you a count of critical static analysis

and compiler warnings

• A metric can be developed based on the presence of snippets of open

source code previously undetected or open source with new known

vulnerabilities

• All of these metrics can be generated on every build of your software

Smaller batches/ payload (Agile)

Infrastructure As Code, Environments On Demand, Cloned/ TemplatedEnvironments

• Continuous Integration

• Continuous Testing• Loose architectural

coupling

Continuous Testing

Sufficient test data to make decisions

• Infrastructure as Code

• Release Automation

Application analytics, CX data

Everywhere: Cross-functional teams, simplified roles

Idea proposed


Solutions

Develop, Commit &

Build

Functional Testing

Deploy Solution

Customer Value

Load, Performance,


UAT/ Exploratory

Testing

Release

Decision

Enablers

Standards

Governing bodies OEM RFP requirements

Research

Media

Continuous metric updates


Testing

Pen testsOSS

scanning

Software tools

Requirements

Development Team

Accept

Sprint 1

Sprint 2

Sprint n Release

ChangeAdjust and Track

FeedbackReview

Next Iteration

No!

Yes!Release

to Market

Integrate and Test

Integrate and Test

Integrate and Test

Agile Development – Integrated Security

Characteristics• Multiple testing

points• Rapid feedback

required• “Outside” testing

does not meet agile needs

Example: ECU


Front ADAS

Gateway Infotainment

Rear distribution

amplifier

Camera

RadarX by wire

Telematics

Power train

Camera

Radar

API Enabled Metrics

Producers

Static code analysis


RESERVED31

Static code analysis

Traditionally used to find simple, annoying bugs

Modern, state-of-the-art SCA

Sophisticated inter-procedural control and

data-flow analysis

Model-based simulation of runtime expectation

Provides an automated view of all possible

execution paths

Find complex bugs and runtime errors, such as

memory leaks, concurrency violations,

buffer overflows

Check compliance with internationally

recognized standards:

MISRACWE

OWASPISO26262

Static Code Analysis


RESERVED32

How to keep your metric up to date

• Standards: Rely on your static code analysis vendor to provide updates

to the latest security standards

• Research: Rely on your vendor to develop custom rules based on

research shared by security analysts

• OEM Requirements: prove that standards have been enforced

Take action


RESERVED33

Check code faster

• Issues identified at your desktop

– Correct code before check-in

– All areas impacted by a given

defect are highlighted

– After system build, the impact of

other developers’ code is also

delivered to the desktop for

corrective action

• Create custom checkers to meet specific

needs

• Debugger-like call-stack highlights the

cause of the issues

• Context-sensitive help provides industry

best-practices and explanations

50% of defects

introduced here

Build Analysis /

Test

Open source scanning


RESERVED34

How to keep your metric up to date

• Deploy a governance and provisioning platform to white list/black list

open source packages

• Be informed when new vulnerabilities are published through the

National Vulnerability Database

• Know what is in your source code by scanning for source code

snippets that have been copied and pasted

Measuring open source risks


RESERVED35

• Know your inventory with OSS scanning

– Automated, repeatable way to locate OSS packages (and

packages within packages!) and licensing obligations

– Look for scanning tools that:

• are SaaS – easier to set up and maintain

• Protect your IP by not requiring source code upload

• Maintain OSS support

– Get notified of latest patches, risks, bugs

• Establish an OSS policy to minimize risk

– Use only trusted packages

– Notify and update security fixes

Scan results example



Conclusions

The application security world is fluid

Create concrete, actionable strategies

(Threat Metric, analysis & scanning)

Delivery cycles are short

Update regularly with well-defined process

(Agile, CI)

See us in action:

www.roguewave.com

Jeff Hildreth | [email protected]