© Fraunhofer

SECURE SOFTWARE

DEVELOPMENT LIFE-CYCLE

Dr. Lotfi ben Othmane

11 December 2015

Includes slides about SAP from

Dr. Achim Brucker

Bringing Security Testing to Development

AppSecEU 2015

© Fraunhofer

PRE-RELEASE AND POST-RELEASE

SECURITY ISSUES

Secure software continue to function correctly under malicious (intended) attacks.

[McGraw 2006]

© Fraunhofer

PRE-RELEASE AND POST-RELEASE

SECURITY ISSUES

McGraw 2006

© Fraunhofer

MICROSOFT’S SDL

© Fraunhofer

ITERATIVE SOFTWARE DEVELOPMENT

© Fraunhofer

MICROSOFT AGILE SDL

Microsoft Approach: classify security engineering activities into three categories based on completion frequency:

Every sprint activities

Bucket activities

One-time activities

[Sullivan 2010]

© Fraunhofer

OWASP APPROACH: USES EVIL USER STORIES

authentication, session management, access control, input validation, output encoding/escaping, cryptography, error handling and logging, data protection, communication security, and HTTP security features.

© Fraunhofer

SECURE COMMUNICATION BETWEEN THE TWO PARTIES-RELEASE 1

• Example of security requirements for the feature

Protect the confidentiality of data exchanged between a device

and the remote control service.

• Example of design decisions

Use SSL libraries JESS for the remote service and JESSIE for the

device

• Example of security test scenarios

Authenticate a device using an unsigned certificate stored in its

keystore

© Fraunhofer

• Example of user stories

As a user, I can send data collected by the device to a server

application in encrypted format.

As an administrator, I can identify the device that sends a

particular set of data.

SECURE COMMUNICATION BETWEEN THE TWO PARTIES-RELEASE 1-CONT.

© Fraunhofer

Scope of Release 2: Enforce liability of data senders

was not known at the project inception

Example of security requirements for the feature

Make the senders liable for the data they send using the devices.

Example of design decisions

Use the smart card for cryptographic operations.

Example of user stories

As a user, I want the smart card of the device to perform the

cryptographic functions required to communicate the device and

the remote service using locally stored keys.

SECURE COMMUNICATION BETWEEN THE TWO PARTIES-RELEASE 2

© Fraunhofer

IMPACT OF SOFTWARE CHANGES ON

THE SECURITY ASSURANCE

Code changes invalidates the security assurance

New code may include code-level vulnerabilities

The authentication test become not valid

The location of the certificates was changed

© Fraunhofer

AGILE SDLC FOR DEVELOPING SECURE SOFTWARE

© Fraunhofer

SECURITY ASSURANCE CASES

© Fraunhofer

SECURITY ASSURANCE CASES

A security assurance case is a semi-formal approach for objectively

supporting the claim that the software mitigates its risk.

A claim is high-level security

requirement

An evidence is the result

a security assessment activity

An argument is the justification

that the evidence support

the claim

© Fraunhofer

SECURE SOFTWARE DEVELOPMENT CONCEPTS

© Fraunhofer

USE OF SECURITY ASSURANCE CASES

FOR TRACEABILITY

Traceability is the ability to

describe and follow the

lifecycle of the development

artifacts

A

bstr

action

Code changes

Security Requirements and tests

Security design

Functional requirements and tests for the

security requirements

Code

Functional design

Iterations

© Fraunhofer

USE OF SECURITY ASSURANCE CASES

FOR TRACEABILITY

Security assurance cases can support traceability of security

development artifacts.

Sec. Ass. Case Artifacts Dev. Artifacts

Claims Security requirements

Context Software requirements/ Scope

Strategy Design

Evidence Assumptions, Design, Test results,

training

Argument Design decisions, test results

© Fraunhofer

EXAMPLE OF APPLICATION OF THE

METHODS

Feature: Secure the communication between devices and

a remote Web service ensuring “reliable” data.

Scope of Release 1: Secure communication between

the two parties.

© Fraunhofer

SECURITY ASSURANCE CASE –

EXAMPLE RELEASE 1

G1: The communication

between the devices and remote

service is secure

G2.1: In-transit data

confidentiality is protected

The claim is achieved by

satisfying all the sub-claims

G2.3: The remote

service authenticates

communicating devices

Stockholders define

acceptably secure as

achieving security goal G1

G2.2: Modification of data

in-transit is detected

G2.4: Each device

authenticates the

remote service

Test STS01

is positive

Test STS02

is positive

Test

STS03a is

positive

Test

STS03b is

positive

Test

STS03c is

positive

Test STS04

is positive

© Fraunhofer

SECURITY ASSURANCE CASE –

EXAMPLE RELEASE 2

G1: The communication

between the devices and remote

service is secure

G2.1: In-transit data

confidentiality is

protected

The claim is achieved by

satisfying all the sub-claims

G2.3: The remote

service authenticates

communicating devices

Stockholders define

acceptably secure as

achieving security goal G1

G2.2: Modification of

data in-transit is

detected

G2.5: Each device

authenticates the

remote service

Test STS01

is positive

Test STS02

is positive

Test

STS03a is

positive

Test

STS03b is

positive

Test

STS03c is

positive

G2.4: Keys stored in

the devices cannot be

cloned

Card does

not leak the

keys

Test STS04

is positive

© Fraunhofer

RISK BASED SECURITY TESTING AS

PART OF SAP’S S2DL

© Fraunhofer

SAP’S S2DL

© Fraunhofer

VULNERABILITY DISTRIBUTION

0

500

1000

1500

2000

2500

3000

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014

Code Execution DoS Overflow Memory Corruption Sql Injection

XSS Directory Traversal Bypass something Gain Privileges CSRF

Source: www.cvedetails.com

© Fraunhofer

SECURE AGILE DEVELOPMENT

© Fraunhofer

SAST AS BASELINE

ABAP 42%

C/C++ 13%

Java 30%

JavaScript 7%

Others 8%

Mandatory since 2010 for all products

Multiple billons lines analyzed

Constant improvements:

– tool configuration (e.g., based on feedback from

development, validation, response)

– new tools and methods

Language Tool Vendor

ABAP CVA (SLIN_SEC) SAP

C/C++ Coverity Coverity

JavaScript, Ruby Checkmarx Checkmarx

Others Fortify HP

© Fraunhofer

HOW TO SELECT THE BEST TOOLS

© Fraunhofer

SECURITY TESTING FOR DEVELOPERS

Security testing tools for

developers, need to

Be applicable from the start

of development

Automate the security

knowledge

Be deeply integrated into the

dev. env., e.g.,

IDE (instant feedback)

Continuous integration

Provide easy to understand

fix recommendations

Declare their “sweet spots”

© Fraunhofer

EXAMPLE: SECURITY TEST PLAN

Mobile Device

Risk: Attacker might inject JavaScript (XSS)

Security Control 1: Use only UI5 controls

Assumption: SAP Kapsel with SMP and Afaria

Test: Static Code Analysis using Checkmarx

Justification: recommended tool

Expected Coverage: all client-side JavaScript code

Expected Effort: 10min per development day (ramp-up not

included)

© Fraunhofer

EXAMPLE: SECURITY TEST PLAN—

CONT.

Security Control 2: use only SSL connections with valid certificates

Test 1: Static Code Analysis for finding non-https connections

Justification: low effort, already included in test for Security Control 1

Expected Coverage: all client-side JavaScript code

Expected Effort: included in effort for scans for Security Control 1

Test 2: Manual test with invalid certs (e.g., self-signed, own CA)

Justification: no automated tool available, self-signed certificates

allowed during development

Expected Coverage: all https connections used for accessing the Web Server

Expected Effort: ½ day towards the end of development

© Fraunhofer

EXAMPLE: SECURITY TEST

Mobile Device

Risk: Attacker might inject JavaScript (XSS)

Security Control 1: Use only UI5 controls

Assumption: SAP Kapsel with SMP and Afaria

Test: Static Code Analysis using Checkmarx

Result: no issues

Actual Coverage: all client-side JavaScript code

Actual Effort: total effort 2 days (15min per day, instead

of expected 10)

© Fraunhofer

EXAMPLE: SECURITY TEST—CONT.

Security Control 2: use only SSL connections with valid certificates

Test 1: Static Code Analysis for finding non-https connections

Result: exempted one issue

Actual Coverage: all client-side JavaScript code

Actual Effort: included in effort for scans for Security Control 1

Test 2: Manual test with invalid certs (e.g., self-signed, own CA)

Expected Coverage: all https connections used for accessing the Web Server

Expected Effort: ½ day towards the end of development

© Fraunhofer

SECURITY VALIDATION

Acts as first customer

Is not a replacement for security testing during development

Security Validation

Check for “flaws” in the implementation of the S2DL

Ideally, security validation finds:

No issues that can be fixed/detected earlier

Only issues that cannot be detect earlier

(e.g., insecure default configurations, missing security documentation)

Note, penetration tests in productive environments are different:

They test the actual configuration

They test the productive environment (e.g., cloud/hosting)

© Fraunhofer

OPEN QUESTIONS

How to trace security requirements to code?

How to trace the impact of code changes on the security assurance of the

software?

The big challenge in practice: Products are often offered in the cloud (SaaS)

and on premise

Does the SecDevOps model increase security awareness?

Does this impact the willingness to take (security) risks and/or the risk

assessment?

© Fraunhofer

CONCLUSIONS

Addressing security issues of released software is of high cost. Software

should be secure by design.

Developing secure software requires threat modeling, risk assessment,

security requirements elicitation, security architecture and design, secure

coding, and security assessment.

The development process of secure software shall be iterative because

software are developed through increments.