By Jared Buschkopf

By Jared Buschkopf


The Problem

◦
Who needs to worry about security?


Why?

◦
Types of security issues

◦
Examples



The Solution

◦
Principles of Software Security

◦
Software Security vs. Application Security

◦
Secure Software Development Life Cycle

◦
Awareness

◦
Duty




Who should be concerned?

◦
Software Engineers / Programmers

◦
EVERYONE


Anyone with a computer, or who has some kind of valuable
information stored on a computer somewhere


Bank Records


Medical Records


Credit Card information


Technical Project Data


Etc.


Defects in software are inevitable

◦
As the complexity of software increases so does the
number of defects

◦
Defects are exploited




Result of unsecure software

◦
Identity Theft

◦
Access confidential information

◦
Loss of Data

◦
Slow computer

◦
Denied Service

◦
Injury or Death

◦
Financial loss


Types of security problems

◦
Malware


Viruses


Worms


Trojans


Spyware

◦
Denial of Service Attack

◦
Salami Attack

◦
Linearization Attack

◦
Teardrop Attack

◦
Software Vulnerabilities


Malware
–

malicious software

◦
Virus


“Malware that relies on someone or something else to
propagate from one system to another.”
–

Mark Stamp


Example: attaches itself to an email


Usually also carries out some destructive objective

◦
Worm


“Like a virus except that it propagates by itself without the
need for outside assistance.”
–

Mark Stamp

◦
Trojan


“Software that appears to be one thing but has some
unexpected functionality.”
-

Mark Stamp

◦
Spyware


Malware which collects information about the users of the
computer that it is installed on without their knowledge


Morris Worm (1988)

◦
A.k.a. the Internet worm

◦
One of the first worms distributed using the
internet

◦
Originally intended to measure size of the Internet

◦
Exploited vulnerabilities in common software


Unix
sendmail


Finger


Others

◦
Could infect a computer multiple times


Made systems unusable


Denial of Service attack

◦
Overwhelm target server or the target’s network
communication lines (“Flooding”)

◦
One
–

to
–

one


Hacker’s system vs. target server or network

◦
Many
–

to
–

one (Distributed Denial of Service
Attack)


Zombie hosts vs. target server or network



Salami attack

◦
“Slice off” small amounts of money from
transactions

◦
Usually an inside job

◦
Attack used in Office Space


Create a virus


Collect fractions of a cent left over from bank
transaction calculations


Deposit the money in an account


Linearization attack

◦
Use processing time to get past security measures

◦
Password validation


Check each character


Exit when incorrect character found


Correct input takes longer to process than incorrect


Can be cracked easily


Vary the first character until the processing time is longer


Continue by doing the same for each of the remaining
characters



Teardrop Attack (Type of
DoS

attack)

◦
Takes advantage of the IP implementation

◦
Packet is too large for router to handle

◦
Break into smaller packets with offset values to
facilitate reassembly

◦
Attacker uses an incorrect offset

◦
Target system crashes



Vulnerabilities

◦
Buffer overflows

◦
Format string problems

◦
Integer Overflows

◦
SQL injection

◦
Failure to handle errors


Zero
-
day vulnerabilities


Many of these problems are brought about by
a failure to validate user input


Buffer overflows

◦
Program allows user to input more data than the
buffer can hold

◦
Result


System crash


Attacker can craft input to include code which will be
executed when it overflows onto the stack

◦
Problematic languages: C, C++



Format String Problems

◦
Unchecked user input is allowed to pass through a
format string

◦
Result


Attacker can execute malicious code

◦
Problematic languages: C, C++


Integer Overflows

◦
Failure to perform range checking on integers

◦
Result


System crash


In C/C++ can be turned into a buffer overrun


Arbitrary code execution can occur

◦
Problematic languages: All


SQL injection

◦
SQL statements are formed with unchecked user
input

◦
User can place their own SQL commands inside your
SQL statements

◦
Result


Confidential data compromised


Entire network can be compromised

◦
Problematic Languages: All



Failure to handle errors

◦
Problem occurs during execution

◦
Developer did not account for it

◦
Result


System crash

◦
Anything that causes a crash is a possible denial of
service issue

◦
Problematic Languages: Most


Zero
-
day vulnerabilities

◦
Vulnerability is discovered and exploited

◦
No patch or fix available

◦
Maintenance team


Race to produce a fix to prevent as much harm as
possible


Examples of Security Problems

◦
Microsoft


Poor design


Constant updates


Costly


Annoying to users


Internet Explorer exploit caused by a misplaced “&”

◦
Credit Card Information stolen


Personal examples


Milwaukee PC


TCF Bank

◦
Some of the most commonly exploited software


Internet Explorer


Microsoft Office


Adobe Flash Player


Adobe Reader


Security can be compromised at all points in the
software life cycle

◦
Development


Developers introduce defect/malicious code

◦
Deployment


Distributors don’t tamperproof software


Transmitted over unsecure communications channels


Installer not secure

◦
Operation


Vulnerabilities are discovered and made public


Programs running on any machine connected to a network are
exposed

◦
Maintenance


Root problems don’t get fixed


Takes too long to fix known problems



Properties of Secure Software

◦
Dependability


Software does only what it was intended to do


Execution is predictable

◦
Trustworthiness


No vulnerabilities


No malicious logic (intentional or not)

◦
Resilience


Software continues to run normally even when under attack


Damage is minimized


If the software cannot run normally it recovers quickly and
maintains an acceptable level of operation

◦
Conformance


Software adheres strictly to requirements


Comply with process designed to maximize quality and security


Software Security vs. Application Security

◦
Software Security


Design For Security


Reduce Vulnerabilities


Proactive

◦
Application Security


Try to make software secure after it is released


Reactive

◦
“Software Security is not Security Software”


Examples of Application Security

◦
Sandboxing Code


Programs run in some form of virtual environment (the
“sandbox”)


Detained/separated from other parts of the system


Can run
untrusted

code safely


Java Virtual Machine


Protection against malware

◦
Anti
-
Virus Software


Symantec


McAfee


Norton

◦
Anti
-
Spyware Software


Spybot

Search & Destroy

◦
Firewalls

◦
Issue: Must keep malware definitions up to date to
be protected


Software Security

◦
Incorporate Security measures into software
process

◦
Security in mind each step of the way

◦
Reduce or eliminate defects/vulnerabilities

◦
Decrease costs


Maintenance


Network security

◦
More Resilient Software

◦
More secure networks


Secure Software Development Life Cycle

◦
Requirements


Specific requirements outlining what is to be done with
regards to security

◦
Abuse Cases


Similar to Use Cases


Created with the mindset of how might someone
intentionally try to break the system


Secure Software Development Life Cycle

◦
Design


Unified security architecture


Risk Analysis


Security analysts


Should happen throughout the software life cycle


External Review


Secure Software Development Life Cycle

◦
Implementation/Coding


Use static analysis tools


Search for vulnerabilities in code


Examples of static analysis tools


Lint


Understand


Fortify


LDRA
Testbed


Secure Software Development Life Cycle

◦
Testing


Risk
-
based security testing


Attack patterns


Threat Models


Penetration testing


Security Test Plan


Should have traceability to specific security requirements


Secure Software Development Life Cycle

◦
Deployment


Monitor software in the field for security breaks


Update software as needed


Apply knowledge gained from attacks to improve
security process and risk analysis for other projects.


Secure Software Development Life Cycle


Taken from
Software Security
by Gary McGraw


Awareness

◦
Training



Need to make engineers aware of security issues


Threats


Impacts


Solutions

◦
Necessary for implementing a secure software
process

◦
Our duty as software engineers


Problem

◦
Security constantly threatened

◦
Vulnerabilities are inevitable

◦
Unsecure software can lead to disaster

◦
Trying to apply security after development is costly
and difficult


Solution

◦
DESIGN SECURITY INTO SOFTWARE

◦
Raise security awareness among engineers


Andress
, A. (2004).
Surviving Security: How to Integrate
People, Process, and Technology.

Boca Raton, Florida:
Auerbach

Publications.



DACS. (2008, October).
Enhancing the Development Life
Cycle to Produce Secure Software
. Retrieved January 31,
2010, from The Data & Analysis Center for Software:
http://www.thedacs.com/techs/enhanced_life_cycles/





Goertzel
, K. M. (2009, January 9).
Introduction to Software
Security
. Retrieved February 3, 2010, from Build Security
In: https://buildsecurityin.us
-
cert.gov/daisy/bsi/547
-
BSI.html





McGraw, G. (2004). Software Security.
IEEE Security &
Privacy

, 80
-
83.



Peltier
, T. R.,
Peltier
, J., &
Blackley
, J. (2005).
Information Security Fundamentals.

Boca Raton,
Florida:
Auerbach

Publications.





Stamp, M. (2006).
Information Security: Principles and
Practice.

Hoboken, New Jersey: John Wiley & Sons, Inc.





Summers, R. C. (1997).
Secure Computing: Threats
and Safeguards.

New York: McGraw
-
Hill.



SANS. (2009, September).
The Top Cyber Security
Risks
. Retrieved February 10, 2010, from SANS:
http://www.sans.org/top
-
cyber
-
security
-
risks/