FUNDAMENTAL PRACTICES FOR

SECURE SOFTWARE DEVELOPMENT

SAFECode

Oct 8 - 2008

Presented by

Hema Neelima

Software Assurance

Software functions as its intended

Reduces risks of vulnerabilities & malicious code

Harm end user

Must be addressed throughout the software development lifecycle –

not as one time event/ single box on check list

SAFECode ( Software Assurance Forum for Excellence in Code )

Non profit organization

Set of development practices - diverse environments

To improve security

INTRODUCTION

This paper – describes - Specific Security Practices at

- Requirements

- Design

- Programming

- Testing

- Code Handling &

- Documentation of Development Process

SAFECode - provides proven security practices to help the industry

Collects, Analyses & Releases

INTRODUCTION

OVERVIEW OF BEST PRACTICES for secure software development

Practices defined in this paper are as diverse as –

Spanning Web applications

Shrink wrapped applications

Database applications

Operating Systems

Embedded Systems

Paper describes –

Identified and proven security practices

Implementation advice (experiences of SAFECode members)

REQUIREMENTS

Software product :

set of activities formalize security requirements.

Practices identify –

1. Functional & non – functional requirements,

2. Conduct product/ code specific risk assessments,

3. Identify specific security requirements to address identified risks &

4. Defining security development roll – out plan for that release.

Project development team 1st identifies security requirements from –

Use cases,

Customer Inputs,

Company policy,

Best practices & security improvement goals.

Team prioritizes security requirements based on threat and risk levels, such as

Threats to –

- code integrity

- Intellectual property protection

- Sensitive data

- Features that require admin/ root privileges

- External network interfaces

Project managers and other business leaders – should be aware of

Need to account time to engage in secure development practices

In preparation for each product release, the development and QA staff members

Should be trained in secure development and testing

REQUIREMENTS

Security requirements cover areas such as – Staffing requirements ( back ground verification,

qualifications, training & education e.t.c)Policy on disclosure of information & project confidentialityAuthentication & password managementAuthorization & role managementAudit logging & analysisNetwork & data securityThird party component analysisCode Integrity & validation testingCryptography & key managementData validation & sanitizationServiceabilityOngoing education & awareness

REQUIREMENTS

DESIGN

Single software secure design practice is –

Threat analysis/ Threat modeling/ Risk modeling

Free form of discussion is better : than not thinking at all

Only brain storming, not a complete solution.

“misuse cases” – how attackers attack the system

Advantages

Can mitigate in early stages

Easy to re – architecture the code

Recommended to select standard, proven security tool kits

Advised to avoid building own security and technologies and protocols

PROGRAMMNG

Practices used by majority of SAFECode members

1. Minimise unsafe function use

2. Use latest compiler toolset

3. Use static & dynamic analysis tools

4. Manual code review

5. Validate input and output

6. Use anti – cross site scripting libraries

7. Use canonical data formats

8. Avoid string concatenation for dynamic SQL

9. Eliminate weak cryptography

10. Use logging & tracing

1. MINIMISE UNSAFE FUNCTION USE

Buffer over – run vulnerabilities : Common & easy to introduce

Primarily affects C & C++

Common cause –

Using unsafe string & buffer-copying C runtime functions

Function families to remove :

Strcpy family

Strncpy family

Strcat family

Strncat family

Scanf family

Sprint family

Gets family

1. MINIMISE UNSAFE FUNCTION USE

Development engineers - trained to avoid these function calls,

But using tools to search the code for these calls helps validate training

efforts & identify problems in code.

Building execution of these tools into “normal” compile/ build cycles

relieves developers - special efforts to find these functions.

2. USE LATEST COMPILER TOOLSET – to take advantage of compile time & run – time defenses

Easy to fix buffer overrun – by moving to other languages

But most jobs use C & C++ (Vulnerabilities serious )

Important –

to use C & C++ compilers that offer compile time and run time defenses

against buffer overrun automatically.

Microsoft Visual C++ 2005 SP1 & Later Offers :

/GS for stack based buffer overrun defenses

/DYNAMICBASE for image and stack randomization

/NXCOMPAT for CPU – Level No – execute (NX) support

/SAFESEH for exception handler protection

Warning C4996 for insecure C runtime function detection and removal

gcc 4.1.2 – 25 & Later Offers :

fstack – protector for stack based buffer overrun defenses

- Wi , -pie for image randomization

- D_FORTIFY_SOURCCE=2 and –Wformat - security for

insecure Cruntime function detection and removal

Developers can use these compiler flags on

every compile session or

selected sessions – depending on individual circumstances

Important –

Errors generated by these compilers are analyzed and addressed

2. USE LATEST COMPILER TOOLSET – to take advantage of compile time & run – time defenses

3. USE STATIC & DYNAMIC CODE ANALYSIS TOOLS – to aid code review process to find vulnerabilities

4. MANUALLY REVIEW CODE – after security education

Review - High risk code (Code that faces internet, Parses data from internet

Know what to look for.

How to fix code vulnerabilities they find?

Can help classes of Security Bugs & remedies is education –

C & C++ vulnerabilities & remedies

( most notably buffer overruns & integer arithmetic

issues )

Web – Specific vulnerabilities & remedies such as

cross site scripting

( XSS )

Data base – Specific vulnerabilities & remedies such as

SQL

injection

Common cryptographic errors & remedies

5. VALIDATE INPUT & OUTPUTto mitigate Common Vulnerabilities

Incoming data – check – reject - non – conferment data

Data validity - Non trivial

Understanding the data format is important

Text & XML - Regular expression/ String comparison

Binary data - Harder to verify

In some applications – mostly web based :-

Validating or sanitizing output is important : cross site – scripting,

Use anti – cross site scripting (XSS) libraries.

6. USE CANONICAL DATA FORMATS

Applications - Resource names” for filtering/ security defenses

should use - Canonical data formats

Canonicalization - mechanism to derive

canonical expression from polymorphic expression

“Hello World.doc” http://www.site.com/hello+world.doc

http://www.site.com/hello%20world.doc

http://www.site.com:80/hello+world.doc

Canonical expression ensures various forms of polymorphic expressions do not

bypass secretary/ filter mechanisms.

Polymorph - Representation of data : not an attack in itself

but may help to slip malicious data past a filter or defense by “disguising” it.

7. AVOID STRING CONCATENATION for dynamic SQL statements

Building SQL statements – common in DB applications.

Most common and dangerous way – Sting concatenation

concatenate un trusted data with sting constants.

Use placeholders/ parameters to build SQL statements.

8. ELIMINATE WEAK CRYPTOGRAPHY

Weakness in : Authentication

Logging

Authorization

Encryption or in

Data validation/ sanitization.

Insecure cryptographic algorithms or entities:

Embedded private data, passwords, keys/ key materials.

Symmetric keys less than 128 – bits long (DES – too weak – 56 bit).

Use of stream ciphers – subtle weakness in the way ciphers are used.

Any self invented cryptographic algorithm –

not yet subject to academic peer review.

Book ciphers using Electronic Code Book (ECB) mode.

8. ELIMINATE WEAK CRYPTOGRAPHY

Important for: Securing

Monitoring &

Debugging applications.

Logging System ( Administrators ) :

Normal operation of system,

Including successful/ failed events.

Tracing System ( Developers & Support Organizations ) :

Pinpoint bug in system.

Do not contain sensitive data.

9. USE LOGGING AND TRACING

TESTING

Validate secure implementation of product

Reduce likelihood of bugs been released or

discovered by customers/ malicious users

Goal – not to “Test in Security”

robustness & security of software products prior to release.

Fuzz testing –

Intentionally build malformed data

Make the software under test consume the data & observe the response.

Goal of Penetration testing

Applying testing techniques employed by attackers

Can use combination - in house/ external security penetration expertise

Adv of 3rd party penetration testers: Experience

Adv of in house penetration team: Maintaining product knowledge

PENETRATION TESTING & 3rd PARTY ASSESSMENT

USE OF AUTOMATED TESTING TOOLS

Important – all stages of development process

Can tirelessly augment human work

Testing tools used by SAFECode members

Fuzzing tools

Network vulnerability scanners

Web – application vulnerability scanners

Packet analyzers

Automated penetration testing tools

Network/ web proxies that manipulate network data

Protocol analyzers

Anti – malware detection on final media.

DOCUMENTATION

Administrators

Document defining software security best practices –

prime source of information

Customers requests

How to install a software securely

using “Out of Box”

or

using wizards

or

more documentation

Document – Simple DO’s & DONT’S

CONCLUSION

Improvements – software security requires development process

Throughout the software development timeline.

Not just one time event/ simple code review.