Lesson 18-Software Development

1
Lesson 18-Software Development
2
Background

• Software engineering is the systematic
  development of software.
• There is a universal requirement that the
  software works properly and performs the desired
  functions.

3
Background

• Software engineering fits as many requirements as
  possible into a project management schedule
  timeline.
• Analysts and developers work hard to get the
  functional elements correct. However, the issue
  of non-functional requirements gets neglected
  entirely.

4
Background

• Security has been described as a non-functional
  requirement.
• It is usually placed into a category of secondary
  importance.
• Trust is built upon an expectation that the
  software will work and continue to meet the
  requirements, and not change its behavior or
  functionality because of outside influences.

5
Objectives

• Upon completion of this lesson, students will be
  able to
• Describe how security should be incorporated into
  the software development process.
• List the types of coding errors.
• Describe the root causes of coding errors.
• Describe good software development practices.
• Explain good software development practices that
  impact application security.
• Describe how using a software development process
  enforces security inclusion in a project.

6
Software Engineering Process

• Traditionally, security is an add-on item
  incorporated after the functional requirements
  have been met.
• It is not viewed as an integral part of the
  software development lifecycle process.
• The challenge lies in how to achieve this goal.
• There are two elements to achieve this objective.
  
• First, the inclusion of security requirements and
  measures into the specific process model being
  used.
• Second, the use of secure coding methods to
  prevent any possibility of security failures in
  the software being designed.

7
Process Models

• The waterfall model.
• The spiral model.

8
Process Models

• All process models have similar components.
• The waterfall software engineering process model
  is characterized by a multistep process where the
  steps follow each other in a linear, one-way
  fashion, like water over a waterfall.
• The spiral model has steps in phases that execute
  in a spiral fashion, repeating at different
  levels with each revolution of the model.
• From requirements to system architecture to
  coding to testing, security is an imbedded
  property in all aspects of the process.

9
Process Models

• Requirements should define specific security
  requirements if there is any expectation of them
  being designed into the project.

10
Process Models

• There are four primary areas of interest,
  independent of the model or method employed
• System architecture acts to design a system that
  will meet the requirements that are identified at
  the requirements process.
• The division of the overall requirements of the
  software into systems and subsystems also maps
  the requirements to these systems and subsystems.
  
• The coding process for each component can have a
  significant impact on the security response of a
  system.
• The testing phase of the project is the
  opportunity to determine compliance with
  requirements and, even, discover unexpected
  behavior that may result in security issues.

11
Process Models

• Independent of the method used, the process is
  about completing the requirements.
• Opportunities exist independent of the model used
  to include security in the requirements process
  and security awareness during architectural
  design, coding, and testing.

12
Process Models

• The requirements process is key to including
  security in software development.
• Security-related items enumerated during the
  requirements process are visible throughout the
  rest of the software development process.

13
ROI and Error Correction

• Developing a set of security requirements has a
  secondary result in the overall process
  improved total cost of development.
• Correcting errors results in additional work and
  expense and the level of rework and extent of
  extra work are direct functions of how late in
  the development process the errors are detected.

14
ROI and Error Correction

• Developing a software engineering process that
  detects errors as early as possible is critical.
• This detection implies a level of testing that is
  distributed throughout the development process.
• This distributed testing is guided by specific
  requirements to test against at each step of the
  development process.
• From a cost point of view, it does not matter
  what the source or the classification of an error
  is, but the cost to rework is critical.

15
Secure Code Techniques

• Implementation of designs leads to the coding
  step in the software development process.
• Instantiation of an idea in code is where errors
  enter the process. These errors are of two types
  
• The failure to include the desired function.
• Testing for the first type of error is easy if
  the requirements are enumerated.
• The inclusion of undesired behavior in the code.
• Testing for the undesired behavior is more
  difficult since testing for an unknown unknown
  is an impossible task.

16
Buffer Overflows

• The CERT/CC at Carnegie Mellon University
  estimates that nearly half of all software
  exploits stem from buffer overflow.
• Buffer overflow classes include
• Static buffer overruns
• Indexing errors
• Format string bugs
• Unicode and ANSI buffer size mismatches
• Heap overruns

17
Buffer Overflows

• These vulnerabilities are relatively simple. The
  buffer used to hold program input is overwritten
  with data larger than the buffer.
• The root cause of this vulnerability is a mixture
  of two things
• Poor programming practice
• Programming language weaknesses

18
Buffer Overflows

• The first step to counter buffer overflow is to
  write solid code.
• Regardless of the language used or source of
  input, treat all input from outside a function as
  hostile.
• Validate all inputs as if they were hostile or
  were an attempt to force a buffer overflow.

19
Buffer Overflows

• The second step is proper string handling.
• String handling is common in programs and is the
  source of a large number of known buffer overflow
  vulnerabilities.

20
Buffer Overflow Sample Code

• Replace the following code
• char buf512
• gets( buf )
• / ... The rest of your code ... /

21
Buffer Overflow Sample Code

• With the following code
• char buf512
• fgets( buf, sizeof(buf), stdin )
• / ... the rest of your code ... /

22
Code Injection

• Code injection is a technique where rather than
  the input being appropriate for the function, a
  piece of code is input that causes the function
  to act in an unintended way.
• The primary defense for this vulnerability is
  similar to that for buffer overflows validate
  all inputs.
• Rather than validating just the length, the
  inputs also need to be validated for content.

23
Code Injection Sample

• In this example, the function takes the
  user-provided inputs for username and password
  and substitutes them into a where clause of a SQL
  statement.
• Assume the desired SQL statement is
• select count() from users_table where username
  JDoe and password newpass

24
Code Injection Sample

• The values JDoe and newpass are provided by the
  user and simply inserted into the string
  sequence. Though this seems functionally safe, it
  can be easily corrupted by using the sequence
• or 11 --
• Since this changes the where clause to one that
  returns all records
• select count() from users_table where username
  JDoe and password or 11 --

25
Code Injection Attack (Java)

• Imagine that the user puts the text for a
  JavaScript function in the middle of an input
  sequence with a call to the script.
• Now, the generated Web page has an added
  JavaScript that is called when displayed.
• Passing the user input through an HTML encode
  function before use can prevent such attacks.

26
Code Injection

• Good programming practice prevents these types of
  vulnerabilities.
• This places the burden not just on the
  programmers but on
• The process of training programmers.
• The software engineering process that reviews
  code.
• The testing process to catch programming errors.

27
Code Injection

• The software development process accounts for the
  types and causes of these errors and have
  safeguards in place to prevent their propagation.

28
Least Privilege

• A central paradigm of security is the notion of
  processes running with the least required
  privilege.
• Least privilege requires the developer to
  understand what privileges are required
  specifically for an application to execute and
  access its required resources.

29
Least Privilege

• As developers move from developing in an
  environment where there is no security to an
  operating system with built-in security, the
  natural tendency is to code around new security
  requirement and programmers develop in the same
  way as before.
• This is manifested as a program that runs only
  under an administrative level account, or runs as
  a service utilizing the SYSTEM account for
  permissions in Windows.

30
Least Privilege

• Designing and coding software with respect to
  access level controls is to plan and understand
  the nature of the softwares interaction with the
  operating system and system resources.
• Whenever the software accesses a file, a system
  component, or other program, access control must
  be addressed.

31
Least Privilege

• Determine what needs to be accessed and what is
  the appropriate level of permission.
• Use that level in design and implementation.
• Repeat this for every item accessed.
• When the application is designed, the process
  needs to be repeated with the installation
  procedure.
• Frequently installing software needs a higher
  level of access than executing the software.

32
Least Privilege

• The cost of least privilege failure is two-fold.
• First, there are expensive, time-consuming access
  violation errors that take a lot of time and
  effort to trace and correct.
• Second is when an exploit is found that allows
  some other program to use portions of the code in
  an unauthorized fashion.

33
Least Privilege Exploitation

• The Sendmail exploit in the UNIX environment.
• Sendmail requires root-level access for some
  functions.
• This exploit inserts foreign code into the
  process stream and executes its code at
  root-level access.

34
Cryptographic Failures

• Proper use of cryptography can provide various
  functionalities such as
• Authentication
• Confidentiality
• Integrity
• Non-repudiation

35
Cryptographic Failures

• A common mistake is the decision to develop your
  own cryptographic algorithm.
• Cryptographic algorithms become trustworthy after
  years of scrutiny and attacks.
• New algorithms take years to join the trusted
  set.
• Deciding to use a trusted algorithm is a proper
  start, but there still are several major errors
  that can occur.
• The first is an error in instantiating the
  algorithm.
• An easy way to avoid this type of error is to use
  a library function that has been properly tested.

36
Cryptographic Failures

• Randomness
• Once you have an algorithm, and have chosen a
  particular instantiation, you need a random
  number to generate a random key since
  cryptographic functions use an algorithm and a
  key, the later being a digital number.
• There are random functions built into the
  libraries of most programming languages.
• These are pseudorandom number generators.
• Although the distribution of output numbers
  appears random, it produces a reproducible
  sequence.
• Using a cryptographic random number generator
  resolves this problem.

37
Cryptographic Failures

• Storing keys
• Storing private keys in areas where they can be
  recovered by an unauthorized person is the next
  source of potential failure.
• Tools have been developed that can search code
  for random keys and extract the key from the
  code or running process.
• The bottom line is simple do not hard code
  secret keys in the code, as then they can be
  discovered.
• Keys should be generated, and then passed by
  reference, minimizing the transfer of copies
  across a network or application.

38
Cryptographic Failures

• Storing keys
• Storing them in memory in a non-contiguous
  fashion is also important to prevent external
  detection and, again, trusted cryptographic
  library functions come to the rescue.

39
Additional Failure Modes

• Making a security decision based on the name of a
  resource is dangerous.
• There is more than one way to represent the name
  of an object.
• A rose may always be a rose, but the same can be
  said of r6fse, where one or more characters of
  the flowers name are represented by hexadecimal
  escape code representations.
• One defense is Canonicalization
• Canonicalization is the conversion of a name to
  its simplest form.
• Program errors from canonicalization errors can
  result in unexpected behaviors.

40
Additional Failure Modes

• Examples of this vulnerability include the IIS
  DATA error, and a host of Unicode exploits to
  bypass checking based on URLs.
• The best method to avoid these errors is not to
  trust filenames when making decisions.
• If a filename needs to be used, the resource
  should be run through a canonicalization routine
  first.

41
Additional Failure Modes

• The failure mode may not cause a program to
  operate differently. It may tie it up so inspite
  of running, it may not be functioning this is
  known as a Denial-of-Service (DOS) attack.
• Denial-of-Service attacks come in many types and
  each has its own mode of operation.
• Defending against Denial-of-Service attacks is
  complex.
• It requires determining how the code is
  vulnerable and what safeguards will prevent the
  code from running forever.
• One major rule is not to trust input validate
  all input before using in a module.

42
Good Practices

• A software development process that has security
  planning built-in will make a difference in the
  end result.
• The process begins with requirements and ends
  with testing.
• Enumerating and defining the specific security
  requirements and how they are tested is a key
  element in building security into code.

43
Requirements

• Security requirements are often included at the
  end in a project.
• Putting the security requirements in an overhead
  role and having the corporate backing to maintain
  an acceptable level of security functionality as
  a baseline solves many problems.

44
Requirements

• For example, making system requirements such as
  Never trust input to a function, and validate
  all buffer lengths can be built into a template
  for all modules that are developed.

45
Requirements

• Making a code review requirement, where a
  second programmer is walked through the
  functionality of code before release to testing
  can catch many errors.

46
Requirements

• The requirements phase is the first step in a
  software development process model.
• The details for all endproduct requirements are
  documented.
• Since it occurs at the beginning of the model, it
  ensures all future steps are aware of the
  specific requirements.

47
Testing

• The testing phase is the last opportunity to
  determine that software performs properly before
  the end user experiences problems.
• Testing can occur at each level of development,
  module, subsystem, system, and complete
  application.
• The sooner errors are discovered and corrected,
  the lower the cost and the impact to project
  schedules.

48
Testing

• The use of use cases to compare program responses
  to known inputs and comparison of the output to
  the desired output is a time-proven method of
  testing software.
• The design of use cases to test specific
  functional requirements occurs based on the
  requirements determined in the requirements
  phase.
• Providing additional security related to use
  cases is the process-driven way to ensure that
  the security specifics are also tested.