SSD951: SECURE SOFTWARE

DEVELOPMENT

SECURE DEVELOPMENT
LIFECYCLE (SDL)

Dr. Shahriar Bijani

Shahed University
Fall 2016
SLIDES’ REFERENCES
 David Wheeler, Secure Software Design & Programming,
SWE 681/ISA 681, George Mason University, Jan 2015.

 SE 331- Engineering Secure Software, Rochester Institute of

Technology, May 2014.

 Dimitry Averin, Security Engineering for Software , CS996 –

Information Security Management, NYU Polytechnic School of
Engineering, 2005.

 Pascal Meunier, Secure Software Engineering, Purdue

University
 Security Development Lifecycle, Microsoft. 2
SOFTWARE SECURITY

 Softwaresecurity as part of the larger problem of

developing robust, reliable code

 Describe the relationship between software security

and:
Corporate information security policies
Corporate risk strategies
WHY IS MOST SOFTWARE INSECURE?
 Many developers don’t know how to develop secure software
 Most universities don’t have it in their syllabi
 Or it’s optional graduate level, not required in undergrad
 Programming books/courses don’t teach it
 Some common operations intrinsically dangerous (esp. C)
 Most developers don’t think like an attacker
 “How could this be attacked?”
 Developers don’t learn from others’ security mistakes
 Most vulnerabilities caused by same mistakes over 40+ years

 Customers can’t easily evaluate software security

 Managers don’t always resource/train adequately

…
5
WHAT IS “SOFTWARE SECURITY”?
 NOT just a set of features

 Secure software > Security software

 Although tools and experts are helpful,

 You can’t just deploy a magical tool and expect all
vulnerabilities to disappear
 You can’t outsource all of your security knowledge

 Even if you are using a security library, know how to use it

properly
WHAT IS “SOFTWARE SECURITY”?
 NOT just a set of features

 NOT a problem for just mathematicians

 NOT just using Cryptography

 Cryptography
 Is important and needed
 Cannot solve all of your security problems

 Proofs, access control rules, and verification are helpful,

but inherently incomplete
WHAT IS “SOFTWARE SECURITY”?
 NOT a problem for just networking and operating systems

 Software had security problems long before we had the

internet

 If you left a window open in your house, would you try to

fix the roads?
WHAT IS “SOFTWARE SECURITY”?
 A reality that everyone must face
 Not just developers, all stakeholders

 A learnable mindset for software engineers

 The ability to prevent unintended functionality

 At all layers of the stack
 In all parts of your system
MYTHS
 Security is only required in the OS
 15% are OS vulns
 I only need a good patch strategy
 Mean time to attack: 330 days -> 2 weeks
 I have a firewall, AntiVirus and IDS
 92% of vulns are software, not network
 Functional testing finds security defects
 Good practices from design to deploy are required
 I use tested components in Java (or .NET)
 Only helps with some classes of problem
 I use cryptography
 Helps with some threats, but just one tool in the toolbox
WHICH APPROACH?
 Defense in depth: Having multiple defense mechanisms
(“layers”) in place, so that an attacker has to defeat
multiple mechanisms to perform a successful attack

 Defense in breadth: Applying approaches to develop

secure software throughout the lifecycle

 Developing secure software requires actions throughout

lifecycle
 “Defense-in-breadth”

11
TRADITIONAL SOFTWARE ENGINEERING

 Many years of software development experience created a well

defined application software development lifecycle

Requirements Design Implementation Verification Deployment Maintenance

 There are many software development methodologies (ex. XP,

waterfall, etc) they all have these basic steps

 Capability Maturity Model for Software (SW-CMM), is used to

measure quality of methodologies employed

12
RESULTS FROM CURRENT SOFTWARE
ENGINEERING METHODS
 >1000 new vulnerabilities reported every year
 About 50% of vulnerabilities are commonly repeated
mistakes
 About 25% could be avoided by considering secure
design principles
 Need new methods
 “We can't solve problems by using the same kind of
thinking we used when we created them.”
(Albert Einstein)
13
ASSURANCE
 Axiom: It is impossible to demonstrate with absolute
certainty that a moderately complex application doesn't have
any vulnerabilities.

 Second Best: We can provide assurance that an application

was designed, implemented, tested in rigorous ways (and by
skilled people) that decrease the chances of having
vulnerabilities and defects.
 e.g.,training in secure programming provides assurance
 software engineering processes designed for assurance

14
HOW DO YOU MEASURE ASSURANCE?

 International Standard: Common Criteria

 Defines Evaluation Assurance Levels (EALs) 1-7

 EALs 3-4 commonly requested by governments and

security-demanding organizations
 EAL 4 evaluation typically costs $1 million

 High assurance (EALs 5-7) is out of the scope of this

tutorial
 This section provides an overview of selected topics
related to assurance

15
SECURE SOFTWARE ENGINEERING
 Goal: minimize the number of security vulnerabilities in
design, implementation and deployment
 Identify and remove vulnerabilities in the development lifecycle as
early as possible.

Three essential components

 Repeatable process
 Engineer Education
 Metrics and Accountability

 SDL – Secure Development Lifecycle

 Used along with traditional/current software development techniques
in order to introduce security at every stage of software development

16
SDL – REQUIREMENTS PHASE
Requirements Design Implementation Verification Deployment Maintenance

 Development of requirements
 Gather information about application [costumer/experience/survey]
 Analysis of requirements
 Areall the security issues addressed
 CIA (Confidentiality, Integrity, Availability)
 Verification of requirements
 Arethere are any inconsistencies / system interface / correctness
 Documentation
 Feasibility of requirements
 [repeat]

 The bottom line: Planning at this stage offers the best 17

opportunity to build secure software in the most efficient manner
[cost, time, etc]
SDL – REQUIREMENTS PHASE
Requirements Design Implementation Verification Deployment Maintenance

 Develop Security Requirements

 Security Requirements of a system/application must be
developed along with any other requirements (e.g. functional,
legal, user, etc)
 Risk analysis
 Identify all the assets at risk
 Identify all the threats

 Develop security policies

 Used as guidelines for requirements
 Develop security metrics

18
SDL – DESIGN PHASE
Requirements Design Implementation Verification Deployment Maintenance

 At this stage all design decisions are made, about

 Software Architecture
 Software components
 Programming languages
 Interfaces
…

 Develop documentation

 Confirm that all requirements are followed and met

19
SDL – DESIGN PHASE
Requirements Design Implementation Verification Deployment Maintenance

 To Do:
 Threat Models
 Input Data Types
 Security Use Cases
 Security Architecture

 How to Secure?
 SecureDesign Principles should be applied
 We may use Secure Design Patterns

 Tools
 E.g. SecureUML – Secure Unified Modeling Language

20
SECURITY DESIGN PRINCIPLES

 Despite years of research, it is still difficult to design

systems that comprehensively prevent security flaws

 But good practices for good design have been documented

(= software engineering)

21
SECURITY DESIGN PRINCIPLES
 Principle of Least Privilege
 Principle of defense in depth (Layering)

 Fail Safe Defaults

 Economy of Mechanism

 Complete Mediation

 Open Design (Avoid security by obscurity)

 Separation of Privilege

 Least Common Mechanism

 Psychological Acceptability

 Isolation

 Encapsulation
 Modularity

 Least Astonishment

 Attack Surface Reduction

22
 Keep security simple
LEAST PRIVILEGE

 "A subject should only be given those privileges it needs

in order to complete its task."
 Access control problem: how closely can (role-based,
etc...) access control or capabilities match the needed
privileges? At what cost?
 Weakness of some Microsoft Applications: IIS 5 runs
under the Local System account, equivalent to root
privileges. Apache may run as “nobody” under UNIX;
under Windows the equivalent procedure is possible but
convoluted (and rarely done).
23
DEFENSE IN DEPTH (LAYERING)
 use of multiple, overlapping protection approaches
 suggests that where one control would be reasonable, more
controls that approach risks in different fashions are better.
 Controls, when used in depth, can make severe
vulnerabilities extraordinarily difficult to exploit and thus
unlikely to occur.
 secure coding:
tier-based validation, centralized auditing controls, and
requiring users to be logged on all pages.

24
PARTITIONING (COMPARTMENTALIZATION)

 Technique to separate the code in different parts, so that

each part runs with least privilege.
 ifa part is compromised, others are still OK
 Example: Separating a user interface from the program
running with special privileges (e.g., root)
 Good implementation examples in Linux
 Bad idea: Windows task bar tray icons running with Local System

privileges
 Secunia advisory SA10949, Dell TrueMobile WLAN card utility

 tray icon launches help with SYSTEM privileges

 can be exploited to execute arbitrary code with SYSTEM privileges

25
FAIL-SAFE DEFAULTS

 "Unless a subject is given explicit access to an object, it

should be denied access to that object"
 Apache access control through .htaccess:
first (default) rule: deny from all
allow from ...
 Tied with the issue of failing “safe” vs failing
“functional”
 Switches that fail open as hubs under unusual circumstances
 “Brittle” or catastrophic failures vs graceful

26
ECONOMY OF MECHANISM
 Keep Security Simple
 Security mechanisms/measures should be as simple as possible
 Simplerto implement and to verify
 Fewer vulnerabilities

 Complex mechanisms may not be correctly:

 understood

 modeled

 configured

 implemented

 used

 Complex mechanisms may engender partial implementations and

compatibility 27
ECONOMY OF MECHANISM: FAILED EXAMPLE

 IPSEC (layer 3): Can do almost everything to secure

TCP/IP but is monstrously complex
 Sub-protocols with their own headers, which may be nested...
 Every vendor’s implementation is slightly different and often
incompatible with the others
 Design by political committee tries to be everything to
everyone!
 People switch to SSL VPNs (layer 7)
 Proven,robust
 Much more simple
 Compatible

28
COMPLETE MEDIATION

 Don’t trust services

 All accesses to objects must be checked against an

access control system to ensure that they are allowed

 Performance vs security issue

 Results of access check are often cached
 What if permissions have changed since the last check?
 Mechanisms to invalidate or flush caches after a change are
often missing
29
COMPLETE MEDIATION: FAILURE EXAMPLE

 Access is checked only when opening a file, which

returns a file descriptor
 UNIX: forked and exec’ed processes inherit file
descriptors
 Even if processes call setuid to relinquish access to a
high privilege, there may remain open files that stay
open even if the process should now not be able to
access them.
 Emacs used to have this problem

30
OPEN DESIGN

 Avoid security by obscurity

 “The security of a mechanism should not depend on the secrecy of
its design or implementation.”
 the design should be open rather than secret (e.g., encryption
algorithms)  security by obscurity

 If the details of the mechanism leaks (through reverse engineering

or social engineering), then it is a catastrophic failure for all the
users at once.
 If the secrets are abstracted from the mechanism, e.g., inside a key,
then leakage of a key only affects one user.
31
 This does not mean you should disclose source code!
OPEN DESIGN: FAILURE EXAMPLE

 Electronic voting machines! Diebold voting machines

source code analysis:
 Passwords embedded in the source code.
 Unauthorized privilege escalation and other vulnerabilities
 Incorrect use of cryptography
 Undetected, unlimited votes by voters
 Insider threats - company workers or election officials can
alter voters' ballot choices without their knowledge

(source: Kohno, Stubblefield, Rubin and Wallach, 2003 Johns Hopkins University)

32
NOTES ON OPEN DESIGN

 Some hackers would rather have the binary than the

source code when designing exploits

 Obscurity is OK if the design is secure regardless

 If details are leaked, the software is still secure

33
SEPARATION OF PRIVILEGE
 “A system should not grant permission based on a single
condition.”
 Removes a single point of failure

 Example: two-factor authentication

 Requiring both biometric and token recognition systems reduces
risks
 Similar to the separation of duty:
 By requiring multiple factors, collusion becomes necessary, and
risks due to bribery (compromise of one factor) are reduced
 Dual-signature checks

34
SEPARATION OF PRIVILEGE: SUCCESSFUL EXAMPLE

 UNIX: sudo allows the execution of commands with

root privileges
 Possible only if
 user knows the appropriate password and
 user is already member of an authorized group (e.g., wheel)

This example is from Bishop M., "Computer Security: Art and Science")

35
NOTES ON THE SEPARATION OF PRIVILEGE

 Often confused with the principle of least privilege

 e.g.,OpenSSH has a "UsePrivilegeSeparation" option which
really is an implementation of least privilege, in two parts of
the code.
 Compartmentalization is the technique used to separate code
so that the principle of least privilege can be applied on these
parts.

36
LEAST COMMON MECHANISM

 “Mechanisms used to access resources should not be

shared”
 Concept: You have two different services, of different
priorities and value, provided to two different sets of
users. The more they share resources, the more likely
one can influence the other to:
 Transmit forbidden data (covert channels issue)
 Limit availability (denial of service)

37
LEAST COMMON MECHANISM: FAILED EXAMPLE

 Microsoft NT architecture: FTP and Web services on the

same computer share a common thread pool
Exhausting the FTP thread pool will cause failed
connection requests for the Web service.
 CVE-1999-1148
IIS processes passive FTP connection requests by
assigning a thread to each port waiting for a client to
connect
 What if they never connect?

38
PSYCHOLOGICAL ACCEPTABILITY

 Security mechanisms should not make the resource more

difficult to access than if the security mechanism were
not present.
 Example: Commercial where users have lost (all?) other
hair in order to comply with a biometric authentication
mechanism requesting hair samples.
 Problem: Users looks for ways to defeat the mechanisms
and “prop the doors open”
 In practice, difficulty proportionate to the value of the
protected asset is accepted
39
ACCEPTABILITY EXAMPLE

Example mechanisms ignored for convenience

 Trusted hosts -- if you’re logged into host 'A', then you
automatically have access to host 'B'
 .rhosts mechanism bypasses password security check
 .rhosts file in / directory allows remote root access without a
password
 Authentication is based on IP addresses, which can be
mapped to a different host through ARP poisonning

40
ISOLATION
 Public access should be isolated from critical resources (no
connection between public and critical information)
 Users files should be isolated from one another (except
when desired)
 Security mechanism should be isolated (i.e., preventing
access to those mechanisms)

41
OTHER SECURITY DESIGN PRINCIPLES

Encapsulation: similar to object concepts (hide internal

structures)
Modularity: modular structure
Least astonishment: a program or interface should always
respond in a way that is least likely to surprise a user
Attack Surface Reduction
Reduce the amount of code executing by default
Reduce the volume of code that is accessible to untrusted users by
default
Close doors (access points) that can be easily opened/exploited

42
SDL – IMPLEMENTATION PHASE
Requirements Design Implementation Verification Deployment Maintenance

 This is the stage where coding is done.

 To produce secure software

 Coding Standards
 Centralized Security Modules
 Secure builds and configurations
 Known security vulnerabilities - use good programming practices
 CWE/SANS top 25…

 OWASP Top 10

 Follow Design & Develop Documentation

44
SDL – VERIFICATION PHASE
Requirements Design Implementation Verification Deployment Maintenance

 Testing of the code developed in the previous stage

 Cleared security tests

 Security vulnerability tracking

 Code Reviews

 Documentation

45
SDL – RELEASE PHASE
Requirements Design Implementation Verification Deployment Maintenance

 How To – Secure Deployment

 Deployment Principles
 Deployment Patterns

46
DEPLOYMENT PRINCIPLES
Requirements Design Implementation Verification Deployment Maintenance

 The importance of configuration

 How physical deployment impacts security

 How software design can make it easier to manage security

and detect attacks post-deployment

47
DEPLOYMENT PATTERNS
Requirements Design Implementation Verification Deployment Maintenance

 Understand the common application types:

 Mobile Client
 Rich Client
 Rich Internet Application
 Service Interfaces (SAAS)
 Web Application

 Understand the common deployment patterns:

 Singleserver, non-distributed
 Multiple server, distributed

 Understand the impact:

 Impersonation and delegation
48
 Layer interfaces
 Trust boundaries
SDL – RESPONSE PHASE
Requirements Design Implementation Verification Deployment Maintenance

 Causes:
 Costumer feedback
 Security incident details and vulnerability reports
…

 Types of maintenance
 Need to introduce new functionality
 Need to upgrade to keep up with technology
 Discovered vulnerability

49
FACTS:
 Every security vulnerability / flaw ignored in an earlier
phase will end-up at later phase[s]

 Resulting into greater

 Cost
 Time

of the software development and/or maintenance

50
 EARLIER, BETTER
Defects at Each Stage of Software Development
60
Percentage of Defects

50 Requirements

40 Design
Coding
30
Testing
20
Maintenance
10
0
Cost of Fixing Defects at Each Stage of
Software Development
$15,000
Source: TRW
$12,000
Cost Per Defect

$9,000

$6,000

$3,000
0
CASE STUDY: MICROSOFT
SD3 + C
 Secure by Design
 Software designed and implemented to “protect” itself and its
information
 Secure by Default
 To minimize the harm when vulnerabilities exploited, software’s
default state should promote security (ex. least necessary
privileges)
 Secure in Deployment
 Software accompanied by tools and guidance to assist secure use
 Communications
 Developers should be prepared for discovery of product
vulnerabilities and should communicate openly and responsibly
with end users. (e.g. patching, deploying workarounds) 52
SDL @ MICROSOFT
• the secure software development process model at
Microsoft

Training: Education and Awareness

• All members of software development teams should receive appropriate training
to stay informed about security basics and recent trends in security and privacy.
• Software programmers should attend at least one security training class each year.
SDL @ MICROSOFT

 SDL Practice #2: Establish Security and Privacy Requirements

 SDL Practice #3: Create Quality Gates/Bug Bars

 Defining minimum acceptable levels of security and privacy quality at the
start
 E.g. no known vulnerabilities in the application with a “critical” or
“important” rating at time of release

54
 SDL Practice #4: Perform Security and Privacy Risk Assessments
SDL @ MICROSOFT

 SDL Practice #6: Attack Surface Analysis/Reduction

 Reducing the opportunities for attackers to exploit a vulnerability
requires thoroughly analyzing overall attack surface and includes
disabling or restricting access to system services, applying the
principle of least privilege, and employing layered defenses
wherever possible.
 SDL Practice #7: Use Threat Modeling
 Applying a structured approach to threat scenarios during design
55
helps identify security vulnerabilities, determine risks of
threats, and establish appropriate mitigations.
SDL @ MICROSOFT

 SDL Practice #8: Use Approved Tools

 Publishing a list of updated, approved tools and associated security
checks (such as compiler/linker options and warnings)

 The Microsoft MSF for CMMI 2013 plus Security SDL is a

template that integrates the Microsoft SDL into your Visual Studio
Team Foundation Server 2013

56
SDL @ MICROSOFT

 SDL Practice #9: Deprecate Unsafe Functions

 Analyzing all project functions and APIs and banning those
determined to be unsafe helps reduce potential security bugs with
very little engineering cost.

 Using header files (e.g. Strsafe.h), newer compilers, or code

scanning tools to check code for functions on the banned list.

57
SDL @ MICROSOFT

 SDL Practice #10: Perform Static Analysis

 Analyzing the source code prior to compile provides a scalable
method of security code review and helps ensure that secure
coding policies are being followed.

 Example tools: CAT.NET, Anti-XSS, FxCop.

58
SDL @ MICROSOFT

 SDL Practice #11: Perform Dynamic Analysis

 Performing run-time verification of your software, checks
functionality using tools that monitor application behavior for
memory corruption, user privilege issues, and other critical
security problems..

 Example tools: AppVerifier, BinScope.

59
SDL @ MICROSOFT

 SDL Practice #12: Perform Fuzz Testing

 Inducing program failure by introducing malformed or random
data to an application helps reveal potential security issues prior to
release.

 Example tools: MiniFuzz File Fuzzer , SDL Regex Fuzzer.

60
SDL @ MICROSOFT

 SDL Practice #13: Conduct Attack Surface Review

 Reviewing attack surface upon code completion helps ensure that
any design or implementation changes to an application or system
have been taken into account, and that any new attack vectors
created as a result of the changes have been reviewed and
mitigated.
 Example tools: Attack Surface Analyzer

61
SDL @ MICROSOFT

 SDL PRACTICE #14: CREATE AN INCIDENT

RESPONSE PLAN
 This is crucial for helping to address new threats that can emerge
over time.
 It includes identifying appropriate security emergency contacts
and establishing security servicing plans for code inherited from
other groups within the organization and for licensed third-party
code.
62
SDL @ MICROSOFT

 Delivering security updates and security guidance

 the Microsoft Security Response Center (MSRC) working to
identify, monitor, and resolve security incidents and
Microsoft software security vulnerabilities.

63
RESEARCH TOPICS
 Secure Design: Threat Modeling methods / tools

 Software Security Risk Assessment methods/ tools

 Security Development Lifecycle: Agile Development

64