Secure Software

Engineering

Jolly Shah

09/03/09 1
Agenda

 Review of different modules

 Why security?
 What are problems?
 Why good software engineering practice
often do not produce secure software?
 Example problems & solutions
 Who should create more secure software?

09/03/09 2
Course modules
 The Need for Security in SDLC
 Threats
 Current software development methods
 The Secure Software Development lifecycle
(SSDLC) process
 Education & Project inception
 Design practices for security
 Product risk assessment & analysis
 Secure coding and testing policies
 The final security review & Product release
 Security response planning and execution

09/03/09 3
Cont..
 Cryptography standards for SSDLC
 Minimum Cryptographic Standards, Invoking JAVA
security APIs.
 Threat tree pattern
 Threat modeling process.
 Addressing STRIDE using threat trees.
 Other Aspects of Software Security
 Addressing DBMS, Network ,OS and Compiler
Vulnerabilities
 UML Sec & software security assessment tools
 Adding secure design features to UML.
 Automated Tools for Software Assessment

09/03/09 4
Why to bother security?

 The answer is world is more connected now

than it has been before and there is no doubt
that it will become more connected over time.
 Necessity is the mother of invention

09/03/09 5
The problem is software

75% of hacks happen at the application.”

-
Theresa Lanowitz, Gartner Inc.
“92% of reported vulnerabilities are in apps, not
networks.”
-
NIST
“64% of developers are not confident in their ability to
write secure code.”
-
Bill Gates

09/03/09 6
A Growing Problem

S o ftw a r e V u ln e r a b ilitie s
9000

8000

7000

6000
V u ln e r a b ilitie s

5000

4000

3000

2000

1000

0
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006

Year

09/03/09 7
Motivations

09/03/09 8
Trinity of Trouble
Connectivity
 Ubiquitous Internet; wireless & mobile computing.
Complexity
 Networked, distributed code that can interact with
intermediate caches, ad proxies, etc.
Extensibility
 Systems evolve in unexpected ways, e.g. web
browsers, which support many formats, add-ons,
plugins, programming languages, etc.

09/03/09 9
SSE Objectives

1. Dependability: software functions only as

intended;
2. Trustworthiness: No exploitable vulnerabilities or
malicious logic exist in the software;
3. Resilience: If compromised, damage will be
minimized, and it will recover quickly to an
acceptable level of operating capacity;
4. Conformance: to requirements and applicable
standards and procedures.

09/03/09 10
Why Good Software Engineering
Practices Often Do Not Produce
Secure Software
 Most of the academic focus has been on cryptographic
algorithms, secure protocols and software protection
mechanisms. There is very little academic focus on the
other security relevant aspects of software applications.
 Producing non vulnerable software should be one of the
aim of software engineering. In reality, this is not much of
a concern: many software engineering books are
essentially silent about software security. Unfortunately,
good software engineering practices often do not
produce secure software.

09/03/09 11
Software security

In this presentation:
 We look at a variety of classical, well know

software security issues

 For each type of issue , we explain why we

believe that current software engineering

practices fail to address the problem
 Finally, we suggest some directions that could

help better securing software.

09/03/09 12
Example 1: problems actually
tested for
 Buffers overflow
Exploitable buffers overflow typically happen
when too much data is stored into a static array.
Consequences go from application crash to
remote code execution.
 Denials of service
(Centralized) denials of service happen when
a user of the system can render it unusable to
other users, e.g. by crashing it or by exhausting
a critical resource.

09/03/09 13
Example 1: problems actually
tested for
 “Proper testing” usually doesn’t catch buffer
overflow
Buffer overflow typically happens when the
data size is way beyond the expected size, while
typical tests stay within the expected input
boundaries.
A buffer overflow is typically
programmatically triggered while bypassing the
user interface, while typical test plan do not call
for “hacking” the system.

09/03/09 14
Example 1: problems actually
tested for
 “Proper testing” usually doesn’t prevent denial of
service attacks
The capacity of exhausting resources is what
is causing the problem. Capacity testing typically
involve measuring against worst expected load,
not worst possible load.
Remote crash typically occurs when an
unexpected input is provided. Typical test plans
usually check the application’s resistance to
wrong input, not massively corrupted input
bypassing the user interface.
09/03/09 15
Example 1: problems actually
tested for
 What is going on?
These types of software security issues do
require specialized testing, typically not in the
scope if the average test plan.
Unless this specific type of tests has been
done, there is no way to know whether an
application is vulnerable to the most basic type
of software security flaws. The application is
thus unfit to secure-sensitive environment.

09/03/09 16
Example 2: injection
scenarios
 Command injections
Un-sanitized user data is passed down to a
shell. A specially crafted input leads to the
execution of a command of the choice of the
attacker.
 SQL injections
Un-sanitized user data is used to build an
SQL command. A specially crafted input leads to
the execution of an SQL command of the choice
of the attacker.

09/03/09 17
Example 2: injection
scenarios
 Cross site scripting (XSS)
Un-sanitized user data is eventually displayed to
other users of the system. A specially crafted input leads
to the execution of a script of the choice of the attacker
on the other user’s computer.
 Second order injection
Un-sanitized user data is logged as part of the
normal system logging mechanism. A specially crafted
input lead to the execution of a command of the choice
of the attacker when the logs are checked by the
administrator.

09/03/09 18
Example 2: injection
scenarios
 “usual” software engineering methods do not
prevent injection flaws
Injection attacks use the primary system as
an attack vector to some secondary system. The
attack is harmless to the primary system, and
the secondary system behaves as per design.
Although the onus is on the primary system,
one can’t prevent the attack “locally”. You have
to protect system that are used or may be used
along with the primary system.

09/03/09 19
Example 2: injection
scenarios
 What is going on?
Injection attack prevention involve tacking
into account other systems that are more or less
related to the system being designed. This
broadens the scope of the application further
than what is typically managed. It does require a
specific “software security” mindset going
beyond the typical software engineering
exercise.

09/03/09 20
Example 3: session
management scenarios
Most web based applications require state and
session information, which is typically simulated
using client side cookies.
 Session hijacking

The attacker gets a hold on another user’s

session id (or guesses it). As far as the
application is concerned, the attacker is the
other user.

09/03/09 21
Example 3: session
management scenarios
 “usual” software engineering methods do not
typically prevent session management flaws
The problems described here are even more
remote to typical software engineering questions
than the previous ones: it is a problem with the
architecture used by the application.
Again, the onus is on the primary system,
which is the only one that can prevent session
“ridding”, even though from the primary system
viewpoint, the attack is not distinguishable from
a legitimate request.
09/03/09 22
Example 3: session
management scenarios
 What is going on?
The problem is quite disconnected from the
application itself. It is a side effect of an
architectural problem.
In order to prevent such a problem, you need
a real “software security” mindset, considering
how you application interacts with its
environment from a security viewpoint.

09/03/09 23
Towards some solutions

 Solutions do exist
None of the problems listed here are
particularly hard to solve once you are aware of
them. There does not lie the issue.

09/03/09 24
Cont..

 Education
A lack of knowledge of software security
issues is clearly the first problem. Any software
engineer and project manager should have a
basic understanding of the problem to avoid to
most obvious traps and be aware of the
necessity to look in that direction.

09/03/09 25
Solutions cont..

 Technical solutions
Some purely technical solutions can be
expected. Already, programming environments,
operating systems or better programming
languages resolve some of these issues for us.
Will technical solutions eventually take care
of the problem completely? Maybe, but not soon
enough anyway.

09/03/09 26
Solutions cont..

 Software security team

Software security must be recognized as a
topic on its own. A software security team of
experts should be incorporated to the workforce
of a software company, much like the UI team.
An expert should be associated to each security
sensitive project and that expert should follow
the project from beginning to end.

09/03/09 27
Cont..

The software security expert will be in charge of the

security aspect of the application only, including:
 Threat modeling

 Security architecture design

 Software security testing

 Code audit

 Evaluation of the security implication of bug reports

 Monitoring of new types of attacks

 …

09/03/09 28
Who should create more secure
software?
 Major software vendors
 A challenge to large ISVs
 In house software developer
 Small software developer

09/03/09 29