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

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

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

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 – 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 1 st identifies security requirements from – Use cases, Customer Inputs, Company policy, Best practices & security improvement goals.

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

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

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

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.dochttp://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.  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

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

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.  Goal of Penetration testing Applying testing techniques employed by attackers  Can use combination - in house/ external security penetration expertise  Adv of 3 rd party penetration testers: Experience  Adv of in house penetration team: Maintaining product knowledge PENETRATION TESTING & 3 rd PARTY ASSESSMENT

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.