FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT SAFECode Oct 8 - 2008

1. FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT SAFECode Oct 8 - 2008 Presented by Hema Neelima

2. 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

3. 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

4. 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)

5. REQUIREMENTS • Software product : • set of activities formalize security requirements. • Practices identify – • Functional & non – functional requirements, • Conduct product/ code specific risk assessments, • Identify specific security requirements to address identified risks & • 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.

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

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

8. 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

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

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

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

12. 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

13. 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

14. 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!!!

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

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

17. 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.

18. 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.

19. 8. ELIMINATE WEAK CRYPTOGRAPHY • Weakness in : Authentication • Logging • Authorization • Encryption or in • Data validation/ sanitization.

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

21. 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.

22. 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.

23. 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

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

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

26. CONCLUSION • Improvements – software security requires development process • Throughout the software development timeline. • Not just one time event/ simple code review.