Transcript Using Management Information Systems Chapter 2 Information

FUNDAMENTAL PRACTICES FOR
SECURE SOFTWARE DEVELOPMENT
SAFECode
Oct 8 - 2008
Presented by
Hema Neelima
INTRODUCTION
 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
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.
REQUIREMENTS
 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 confidentiality
Authentication & password management
Authorization & role management
Audit logging & analysis
Network & data security
Third party component analysis
Code Integrity & validation testing
Cryptography & key management
Data validation & sanitization
Serviceability
Ongoing education & awareness
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
2. USE LATEST COMPILER TOOLSET –
to take advantage of compile time & run – time defenses
 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
3. USE STATIC & DYNAMIC CODE ANALYSIS TOOLS –
to aid code review process to find vulnerabilities
 Source code, binary analysis tools : highly recommended - to find –
common vulnerability types
Tools are adjunct – to manual code review, not a replacement.
 State – of – the art of these tools requires that developers analyze –
sometimes voluminous results that may contain many false positives
 Considerable tuning required to get most benefit from these tools
 Tools from different vendors catch different types of issues;
No one tool finds all faults!!!
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 & OUTPUT
to 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.
8. ELIMINATE WEAK CRYPTOGRAPHY
 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.
9. USE LOGGING AND TRACING
 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.
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.
PENETRATION TESTING & 3rd PARTY ASSESSMENT
 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
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.