Secure Software Engineering

1
Secure Software Engineering

• Fangzhou Lin
• Charles McClendon

2
Introduction

• Building software is hard
• Security is hard
• Secure software engineering is a very difficult
  problem

3
Introduction

• 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

4
Introduction

• 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

5
Introduction

• 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

6
Requirements 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

7
Requirements 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

8
Requirements 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)

9
Requirements 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

10
Design 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

11
Design 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

12
Design 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
13
Implementation 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.

14
Implementation 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

15
Implementation 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

16
Implementation 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

17
Buffer 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)
19
Stack 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.

20
Prevent 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

21
SQL 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 --'
22
Implementation 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

23
Static-analysis tool PREfast

• Buffer Overrun Warnings
• Precedence Warnings
• HRESULT Warnings, Typo Warnings,

24
Implementation 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

25
Testing 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.

26
Testing 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

27
Release 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

28
Support 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

29
Results of SDL at Microsoft
Security Bulletin
the number of security bulletins issued
30
Effectiveness

• 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
31
Summary 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.