Title: Secure Software Engineering
1Secure Software Engineering
- Fangzhou Lin
- Charles McClendon
2Introduction
- Building software is hard
- Security is hard
- Secure software engineering is a very difficult
problem
3Introduction
- Why is building secure software hard?
- Software systems have become increasingly complex
- Several phases of development are required
- Breakdowns in any phase of engineering lead to an
insecure product - Attacker has the advantage Only one
vulnerability must be found to compromise the
system while the engineer must stop all leaks
4Introduction
- Additional 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
5Introduction
- What can we do?
- Treat security as a first class citizen in your
development process Ignore security at your
peril - Throughout 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 -
-
6Requirements Phase
- The 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
7Requirements Phase
- The 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
8Requirements Phase
- The 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)
9Requirements Phase
- Avoid 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
10Design Phase
- The design phase is the next most critical phase
of development - Remember, 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
11Design Phase
- Strategies 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
12Design Phase - Threat Modeling
Decompose application
- If you don't understand the threats, how can you
build a secure system? - Analyse possible attacks and how to mitigate them
- assess the probability, the potential harm, the
priority etc. of attacks - Determine the highest security risks
- try to minimize or eradicate the threats
Determine threats
Rank threats by decreasing risk
Choose how to mitigate the threats
13Implementation Phase
- Most important Threat model guidance for
coding and testing - Best coding practice
- Follow rules that prevent security-related coding
errors - Use safer string handling and buffer manipulation
constructs to avoid buffer overrun - Robustness check all inputs.
- Dont suppose something will not happen.
14Implementation Phase
- Static-analysis code-scanning tools
- Detect common coding flaws
- Buffer overruns, integer overruns, uninitialized
variables - Advantages
- Find bugs early Save manual audit Unexperienced
coder - PREfix, PREfast
- Rices 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
15Implementation Phase
- Common Security-related Code Flaws
- Buffer overflow
- password in memory
- Password is unencrypted in memory
- URL manipulation
- SQL injection
- session hijacking
- Obtain session IDs to gain unauthorized control
16Implementation Phase
- Buffer 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
17Buffer overflow an example
- void foo (char bar)
-
- char c12
- memcpy(c, bar, strlen(bar))
-
- int main (int argc, char argv)
-
- foo(argv1)
Before bar is copied to c
18"AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80"
"hello"
When foo() returns, it jumps to the return
address (corrupted by the attacker)
19Stack buffer overflows
- The 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 service - The Twilight hack was made for the Wii in The
Legend of Zelda Twilight Princess - give a very long character name for the players
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.
20Prevent Buffer Overflows
- Always 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.h
- Tradeoff Safety vs. Performance
21SQL injection
User input is not filtered for escape characters
and is then passed into a SQL statement
http//xkcd.com/327/
The school lost a year's student records in the
database because of a student named "Robert')
DROP TABLE Students--"
statement "SELECT FROM Students WHERE name
('" studentName "')"
SELECT FROM Students WHERE name ('Robert')
DROP TABLE Students --'
22Implementation Phase
- Why good people write bad code?
- Underlying complexity of the task itself
- Psychological reasons that make it hard for human
to think like the computers do - Budget and time constraints
23Static-analysis tool PREfast
- Buffer Overrun Warnings
- Precedence Warnings
- HRESULT Warnings, Typo Warnings,
24Implementation Phase
- Code reviews
- Supplement to automated tools
- Crucial step
- Facts
- Critical flaws may not be revealed
- It makes the programmers more careful
- Opportunity to learn
25Testing phase
- Key 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 patterns
- Works for novice attackers
- But not for determined ones.
26Testing phase
- Test cases are planned before coding starts,
derived from the design - Test against threat model
- Each threat ? at least one test case
- Act 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 interfaces - Make sure that code correctly handles all data
entering the interfaces
27Release Phase
- Final 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 review
- Provide an overall picture, not feasible to find
all security vulnerabilities
28Support and Servicing Phase
- Respond to new attacks
- Learn from errors, understand the root causes of
the reported vulnerabilities - Accountability the person who wrote the flawed
code should fix it - Eliminate further vulnerabilities
29Results of SDL at Microsoft
Security Bulletin
the number of security bulletins issued
30Effectiveness
- Highest priority Threat Modeling
- Then
- code reviews
- Use of automated tools
- Fuzz testing
- Penetration testing before release least
effective to find and fix security bugs
Complementary
31Summary and future work
- Consider security early not as an add-on
feature - Threat Modeling is important
- Rely on best practices
- Further research on formal methods for software
security is needed.