By Jared Buschkopf

homuskratΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

52 εμφανίσεις

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/