Secure Software Development

Chris Herrick

01/29/2007

Why is Security in Software Important?

• Affects all software on the user’s machine

• Cost of fixing a security defect is very expensive

Costs of Fixing a Security Defect

• Cost of Fix Planning• Cost of Locating Defect• Cost of Fixing and Testing Defect• Cost of Writing Fix Documentation• Cost of Fix Deployment• Cost of Public Relations Fix (if possible)• Cost of Lost Productivity

Howard, Michael, and David LeBlanc. Writing Secure Code. pp 9-10.

Business Environment Prerequisites

• People who are aware and/or have been trained in security issues

• Environment which places importance on the security of products produced

Requirement Phase

• What level of security do the end users expect?

• What can not be sacrificed for the security?

• What account types or privileges must the system run under?

• What types of peripherals does the system connect or interface with?

Analysis Phase Activities

• Threat Modeling• Determine what Account level and

Privileges are required• Determine if an Access Control List

(ACL) required and if so, what are the rules of the ACL?

Threat Modeling

• Draw up a list of components and protocols the system will use and how the system will use them

• Apply different classifications of attacks that can be made against or through the components or protocols

• Design threat mitigations into the system.

Threat Modeling – Classifying Threats

• S – Spoofing: Acting as some other entity• T – Tampering: Altering data, either in

persistent storage or in transmission• R – Repudiation: Doing an action that has no

traceability to the actor• I – Information Disclosure: revealing data to

those who should not see it• D – Denial of Service• E – Elevation of Privilege: Raising a user’s

rights or privileges

Threat Modeling – Classifying Threats

• For each component and protocol in the system, devise threats that could be made against the system.

• A list of possible threats should be kept along with all relevant data regarding the threat (type, target, likelihood, possible damage to the system as a result, etc).

• Further Analysis & Design considerations may result from creating the list of threats.

Threat Modeling – Classifying Threats (con’t)

• Likelihood of threat should be rated from 1 to 10 (greatest to least).

• Possible damage should be rated from 1 to 10 (least to greatest).

• Threat Risk Rating = Possible Damage Rating / Threat Likelihood Rating.

• The higher the risk rating, the higher the threat, and the sooner the threat should be mitigated.

Least Privilege

• The application will execute as the user logged on at the time.

• If that user is an Administrator (Windows) or root (Unix), so is the appllication.

• If the application is hacked, the hacker runs at the application’s privileges.

What is an ACL?

• Mechanism which provides controlled access to system resources

• Generally implemented at the operating system level but not necessary

• Consist of a series of Access Control Elements (ACEs)

ACE Elements

• ACEs have two primary parts (at least as regards to the permissions): the Security Identifier (SID) and the permissions

• The SID can be a user or a group (including Everyone or World)

• Permissions range from Deny All to Full Control (Read, Write, Delete, Create, etc)

• The lowest of a user’s permissions for a given resource are used.

Design Phase Activities

• How to more securely store secrets (passwords, keys, etc)

• Use of Cryptography

Storing Secret Data

• Secret Data can be login IDs, passwords, cipher keys, personal data, etc.

• The safest way to store secret data is NOT to store secret data. If it is possible to not store secret data, do it!

• Users normally expect that some secret data be stored for convenience (login ID and password are common if the system has a use for it later).

What to do if Storing Secret Data must be Done

• Store a hash or a salted-hash near the point where it will be used. The more a hash is used and/or the farther a hash is used from where it is stored, the more likely an attacker will find it.

• If the hash is stored on disk, set appropriate ACEs on it. If there is not an ACL at the operating system level, the hash cannot be kept secure. The best you can do is make it difficult to access.

Cryptography Topics

• What is entropy?• Properties of Good Pseudo-Random

Number Generators• Reasons for Avoiding the Creation of

Cryptographic Functions

Cryptographic Entropy

• Mathematic Entropy is the measure of how random a sequence is.

• Calculating the entropy on a password can indicate how many bits it will store as.

• # of bits = log2(n^m) where n is number of available characters and m is the length of the password (in characters)

• This is important to know if the password is used to create a key.

Properties of Good Pseudo-Random Number Generators

• Properties:1. Generates evenly distributed numbers

2. Values are unpredictable

3. It has a long and complete cycle

• A number generator for cryptographic purposes must be carefully chosen.

Howard, Michael, and David LeBlanc. Writing Secure Code. p 160.

Reasons for Avoiding the Creation of Cryptographic

Functions• Creating a good cipher is not easy.• The “obscure” cipher is not obscure.• The client may specify how secure data

has to be stored.• Encryption is only effective where

encryption is useful.

Implementation Considerations

• Buffer Overruns• Conditional Testing Order

Buffer Overruns

• A buffer overrun occurs when more data is written to a buffer than the buffer is large. The excess data overwrites the following memory cells.

• If it can occur is normally an unintended attribute of the language.

• It can be prevented by checking the bounds on buffers before writing to them.

Conditional Testing Order

If( actionAllowed( … ) == NOT_ALLOWED )// Do not allow access

else// Allow access

If( actionAllowed( … ) == ALLOWED )// Allow access

else// Do not allow access

What is the difference between these blocks of code?

What if actionAllowed( … ) returns an error message instead of ALLOWED or NOT_ALLOWED?

Testing Security Issues

• Generating data to test for security defects

• How do you know when a test failed?

Generating Test Data

• The most effective test data is partially correct data.

• Write a script to generate the data according to specific conditions (i.e. bad headers in packets, input with control characters, data designed to buffer overflow, etc)

How to Tell when a Test Failed

• Attach a debugger to the process. If you are handling errors, the error handler may have acted on an error you caused, but the debugger will likely get the error before the handler will.

• Monitor the instruction pointer register. If the test executed a buffer overrun the register may have been overwritten.

• Check the log files. These can indicate if a denial-of-service has been successfully executed (there will be a large number of similar events generated in rapid succession).

A Few Last Notes

• Tools are beginning to become available that check for security bugs at or before compile time.

• Unfortunately, the overall state of these tools is still inadequate.

Works Cited

• Chandran, Roshen. “Catch’em Young – How to discover vulnerabilities early.” Palisade. Nov 2004. 28 Jan 2007. <http://palisade.plynt.com/issues/2004Nov/software-bugs/>

• Howard, Michael, and David LeBlanc. Writing Secure Code. United States: Microsoft Press, 2002.

• “Security Concerns.” The Okopipi Wiki. 28 Jan 2007. <http://wiki.okopipi.org/wiki/Security_concerns>

• Thompson, Herbert H., and James A. Whittaker. The Business Case for Software Security. Dr. Dobbs. 02 Feb 2004. 28 Jan 2007. <http://www.ddj.com/dept/security/184405588>