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.