Secure Software Secure Software EngineeringEngineering
Fangzhou LinCharles McClendon
IntroductionBuilding software is hardSecurity is hardSecure software engineering is a very
difficult problem
IntroductionWhy is building secure software hard?
Software systems have become increasingly complex
Several phases of development are requiredBreakdowns in any phase of engineering lead
to an insecure productAttacker has the advantage; Only one
vulnerability must be found to compromise the system while the engineer must stop all leaks
IntroductionAdditional problems for securing software
There are fundamental problems in Computer Science such as the “Halting Problem”
There may be competing economic factors such as whether or not it is cost effective solve a particular security problem
Few software systems are islands; typically systems are installed on top of existing software infrastructures, libraries, and operating systems that have their own security vulnerabilities
IntroductionWhat can we do?Treat security as a “first class citizen” in your
development process Ignore security at your perilThroughout each phase of development think
critically and have the goal of lessening your “attack surface”
We will examine problems and solutions in secure software engineering from perspective of a traditional “Waterfall” model of development
Requirements PhaseThe requirements phase is perhaps the most
crucial aspect of the secure software engineering process
The property of “traceability” requires that any behavior described in the requirements phase be present in the final product and vice versa
This means we must not insert security behaviors ad hoc; we must begin with security in mind
Requirements PhaseThe first order of business should be to
establish a security team, or “task force” This team could either be formed from a
group of in-house employees or a third party consultancy could be contracted
The members of this team should be well versed in security topics and undergo regular training
They will be involved in all aspects of development
Requirements PhaseThe security team will also determine what level
of security is required by the system owners
Perhaps the system will be used in situations where there are regulatory bodies and standards such as Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPPA)
Requirements PhaseAvoid the Maginot Line approach
A typical anti-pattern is simply to secure the perimeter with firewalls and network devices without spending much effort securing the system itself
This technique is fundamentally flawed as attacks have become increasingly more complex and the security demands of applications have become more sophisticated
Design PhaseThe design phase is the next most critical
phase of developmentRemember, no behavior must be added that is
not accounted for in the specifications document
There are several tools and techniques that we may use in developing secure software designs
For instance SecureUML is an extension of UML that allows us to explicitly specify security considerations into our diagrams
Design PhaseStrategies and considerations
Defense in Depth – we should layer our security measures so that if one piece fails, the risk can be avoid by a lower level of security. Thus we can avoid the Maginot Line by having perimeter security AND other defenses
Compartmentalization – similar to “defense in depth,” we should isolate modules such that if one is compromised, it does not lead to rest of the system being vulnerable
Least Privilege – perhaps the most straightforward, a user should not have more authority than is necessary
Design Phase - Threat ModelingIf you don't understand the threa
ts, how can you build a secure system?
Analyse possible attacks and how to mitigate themassess the probability, the
potential harm, the priority etc. of attacks Determine the highest security risks
try to minimize or eradicate the threats
Decompose application
Determine threats
Rank threats by decreasing risk
Choose how to mitigate the threats
Implementation PhaseMost important: Threat model – guidance for
coding and testingBest coding practice
Follow rules that prevent security-related coding errors Use safer string handling and buffer manipulation
constructs to avoid buffer overrunRobustness: check all inputs.Don’t suppose something will not happen.
Implementation PhaseStatic-analysis code-scanning tools
Detect common coding flaws Buffer overruns, integer overruns, uninitialized
variablesAdvantages
Find bugs early; Save manual audit; Unexperienced coder
PREfix, PREfastRice’s theorem – any nontrivial question about a
program can be reduced to the halting program Static analysis problems are undecidable Aim for good, not perfect
Output examined by human
Implementation PhaseCommon Security-related Code Flaws
Buffer overflow password in memory
Password is unencrypted in memoryURL manipulationSQL injectionsession hijacking
Obtain session IDs to gain unauthorized control
Implementation PhaseBuffer overflow
Attempt to store data beyond the boundaries of a fixed-length buffer extra data overwrites adjacent memory locations.
Designed inputs can execute malicious codes. Overwrite a local variable Overwrite a function pointer Overwrite the return address in a stack frame
Buffer overflow – an examplevoid foo (char *bar) { char c[12]; memcpy(c, bar, strlen(bar));}
int main (int argc, char **argv){ foo(argv[1]); }
Before bar is copied to c
"AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80"
When foo() returns, it jumps to the return address (corrupted by the attacker)
"hello"
Stack buffer overflowsThe Morris worm spread in part by exploiting a stack buffer
overflow in the Unix finger server.The Slammer worm spread by exploiting a stack buffer
overflow in Microsoft's SQL server.The Blaster worm spread by exploiting a stack buffer
overflow in Microsoft DCOM serviceThe Twilight hack was made for the Wii in The Legend of
Zelda: Twilight Princess give a very long character name for the player’s horse,
causing Wii to crash, and run any unofficial program named “boot.elf” on the SD card
Nintendo released Wii Menu update 3.3 to prevent this,but within 8 hours, two bugs was found in the update,need only minor modification for the hack to operate.
Prevent Buffer OverflowsAlways validate all the inputs
Even if you will never overflow the buffer that is used internally, other people who maintain the code may not be so careful.
While C, C++ provide no built-in boundary checking...Use standard C++ libraries (STL), avoid gets, scanf, strcpy
Use Java, .Net, …Use safe string-handling libraries like Strsafe.hTradeoff: Safety vs. Performance
SQL injection
The school lost a year's student records in the database because of a student named "Robert'); DROP TABLE Students;--"
http://xkcd.com/327/
User input is not filtered for escape characters and is then passed into a SQL statement
statement = "SELECT * FROM Students WHERE name = ('" + studentName + "');"
SELECT * FROM Students WHERE name = ('Robert'); DROP TABLE Students; --';
Implementation PhaseWhy good people write bad code?
Underlying complexity of the task itselfPsychological reasons that make it hard for
human to “think” like the computers doBudget and time constraints
Static-analysis tool – PREfastBuffer Overrun Warnings:
Precedence Warnings:
HRESULT Warnings, Typo Warnings, …
Warning DescriptionPREfast Warning 29 Possible buffer overrun in call to
<function>.
PREfast Warning 201 Buffer overrun for stack buffer <variable>.
… …
Warning DescriptionPREfast Warning 235 (<non-zero constant> ||
<expression>) is always TRUE.
PREfast Warning 290 Bitwise operation on logical result.
… …
Implementation Phase
Code reviewsSupplement to automated toolsCrucial stepFacts:
Critical flaws may not be revealed It makes the programmers more careful Opportunity to learn
Testing phaseKey Difference
Specification-based testing: focus on testing the presence of correct behaviour
Security-testing: focus on testing the absence of additional behaviour
Testing based on published attack patternsWorks for novice attackersBut not for determined ones.
Testing phaseTest cases are planned before coding starts, derived
from the designTest against threat model
Each threat at least one test caseAct like the attacker
Know the security vulnerabilities and attack patterns
Security-testing tools: Fuzzing tools (data mutation)Supplies structured but invalid inputs to APIs and
network interfacesMake sure that code correctly handles all data
entering the interfaces
Release PhaseFinal Security Review
Independent review by the central security team
Penetration testing evaluating the security by simulating an attack by a
malicious user Black box testing – the role of outside hacker White box testing – the role of insiders
Independent external security reviewProvide an overall picture, not feasible to find
all security vulnerabilities
Support and Servicing PhaseRespond to new attacksLearn from errors, understand the root
causes of the reported vulnerabilitiesAccountability: the person who wrote the flawed
code should fix itEliminate further vulnerabilities
Results of SDL at Microsoft
the number of security bulletins issued
Bulletin Identifier
Microsoft Security Bulletin MS08-054
Bulletin Title
Vulnerability in Windows Media Player Could Allow Remote Code Execution (954154)
Executive Summary
……
Maximum Severity Rating
Critical
Impact of Vulnerability
Remote Code Execution
Detection ……
Affected Software
Microsoft Windows. For more information, see the Affected Software and Download Locations section.
Security Bulletin
EffectivenessHighest priority – Threat ModelingThen
code reviewsUse of automated toolsFuzz testing
Penetration testing before release– least effective to find and fix security bugs
Complementary
Summary and future workConsider security early – not as an add-on fea
tureThreat Modeling is importantRely on best practicesFurther research on formal methods for
software security is needed.
Top Related