secure software development life-cycleblogs.uni-paderborn.de/sse/files/2015/08/devlifecycle.pdf ·...
TRANSCRIPT
© 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.