Secure Code Development

1. Secure Code Development • What are the risks of delivering insecure applications or software products? • How can a company ensure they produce secure code? • What strategies can be used? • What tools exist? • What departments help with this process?

2. Secure Programs • 15-50 faults per 1000 lines of code. • Fixing faults: • “penetrate and patch” search for bugs and repair. • Is conformance to specifications sufficient? • Compare requirements with behavior. • Find program security flaws. • Either human error or malicious intent. • Tester’s perspective important.

3. Security Development Lifecycle • Align the below tasks with the SDLC. • Plan: product stakeholders & security meet. • Design: identify weaknesses early. • Develop: code securely. • Test: test products against security requirements. • Document: secure configurations of product • Assess: verify product security before release. • Respond: know how to deal with customers who report security concerns with your product.

4. Threat Model (design phase)

5. Static Code Analysis Tools • Static analysis: static code analysis, data flow static analysis, and metrics analysis • Peer code review: process automation • preparation, notification, and tracking • Unit testing: JUnit and Cactus test creation, execution, optimization, and maintenance • Runtime error detection: race conditions, exceptions, resource & memory leaks, security attack vulnerabilities.

6. Quality Assurance • Systematic evaluation of the various aspects of a product to maximize the probability that minimum standards of quality are being attained by the production process. • Cannot guarantee production of quality products. • Two principles in QA: • "Fit for purpose" - suitable for the intended purpose; • "Right first time" - mistakes should be eliminated. • Quality is determined by the product users, clients or customers, not by society in general.

7. Testing • Unit: test in controlled environment. • Integration: components work together. • Functional: does it meet requirements. • Performance: measure capability. • Acceptance: check meets customer requirements. • Installation: final test during install.

8. Testing Continued • Regression: test product still meets requirements after it has been modified. • Black Box: test without knowledge of how the system was built. • White Box: test with full knowledge of the system and its expected behavior. • Independent: Outsider view • Penetration: computer security testing.

9. Figure 3-19  Fault Discovery Rate Reported at Hewlett-Packard.

10. Types of Flaws • Validation Error: permission checks. • Domain Error: controlled access to data. • Serialization and aliasing: program flow. • Inadequate identification and authentication • Authorization flaws • Boundary condition violation: exceed them • Logic errors: errors in process design.

11. Secure Software Development Practices • Peer Reviews: review, walk-through, inspection. • Hazard Analysis: expose hazardous states. • Testing: quality assurance. • Good Design: fail-safe, earlier discussion items. • Prediction: risk analysis. • Static analysis: control and data flow, structure. • Configuration management: what changes when. • Analysis of mistakes: lessons learned.

12. Nessus Vulnerability Scanner (assess phase)

13. Non Malicious Program Errors • Buffer Overflows: coding error, buffer overruns. • Attacker replaces code in the stack • Heap Overflow: dynamically allocated memory. • Corrupt this data in specific ways to cause overwriting. • Incomplete Mediation: out of range input or value injection • http://www.comesite.com/purchasing/data&parm1=(303)555-1234&price=10 • Tools: Hackbar, Tamper Data, OWASP Web Scarab, etc.

14. Figure 3-1  Places Where a Buffer Can Overflow.

15. Metasploit Pen Testing

16. Asset Management • Configuration Management • Manage updates and deliveries. • Baselining • capture a point in time. • Patch management • Verification and delivery. • Vulnerability Management • How will you respond to a customer? • Change Management • If no change will become less secure.

17. TOCTTOU/Race Condition • Time of check time of use (TOCTOU) • “Alter a condition after it has been checked”. • A state attack leveraging an OS change of state • Hacker ask for permission to file “readme”. • OS Checks permission on file, • OS does something else… • Hacker makes file a symbolic link from readme to /etc/shadow. • OS allows access to file. Hacker changes passwords.

18. Discussion Questions • The common description of a salami attack is penny shaving. • Steal small amounts that no one will notice. • How could you prevent a salami attack from being part of your software product? • Can you identify 3 controls to help?

19. Virus • Agent: virus author. • Malware that does not spread automatically. • Requires a carrier (USB, CDROM, floppy). • Macro: MS (Word, Excel). • Polymorphic: changes its signature on install. • Boot sector: loads on system startup. • Stealth: hides from anti-virus software.

20. Figure 3-4  Virus Appended to a Program.

21. Figure 3-5  Virus Surrounding a Program.

22. Figure 3-6  Virus Integrated into a Program.

23. Figure 3-7  Virus Completely Replacing a Program.

24. Figure 3-8  Boot Sector Virus Relocating Code.

25. Figure 3-9  Recognizable Patterns in Viruses.

26. Anti-Virus is Reactionary

27. Polymorphic Virus • Virus coded to modify its signature. • Insert lines containing random comments. • Scanners: remove comments, white space. • Insert junk code intermittently. • Changes the capitalization of the letters in the crucial strings. • Traditional code normalization techniques are not applicable. • Use static encryption. • Change Variable names.

28. Protection Ring Model

29. Root kits • Malware that replaces portions of an operating system at user level 3. • Unix: replace ls, ps etc. • PATH:.:/usr/bin:/usr/sbin • Hide from /proc on linux • Windows • Replace dir or task list • Kernel-mode rootkits operate in ring 0. • Hide from /proc on linux

30. Root Kit Protection (OSSEC)

31. Targeted Malicious Code • Written for a specific application or purpose • Trap doors: undocumented entry point. • Salami Attack: skimming small amounts. • Rootkits: Sony XPC example. • Privilege escalation: programs that run at a high privilege level are targets. • Keystroke loggers.

32. Figure 3-10  Stubs and Drivers.

33. Covert Channels • Definition: any communication that violates a security policy. • Storage Channel: use shared storage to communicate, /tmp filesystem. • Covert timing channel: hacker notices the difference in system response to an incorrect password vs. incorrect username.

34. Figure 3-11  Covert Channel Leaking Information.

35. Figure 3-12  Covert Channels.

36. Figure 3-13  File Lock Covert Channel.

37. Figure 3-14  File Existence Channel Used to Signal 100.

38. Figure 3-15  Covert Timing Channel.

39. Discussion Question • An electronic mail system could be used to leak information. • How could email leakage occur? • What controls could detect or prevent the leakage?

40. Modularity & Programming • Goals for a component • Have a Single purpose. • Be small: understand content and structure. • Be simple: KISS, low complexity. • Be independent: performs a task isolated from other modules.

41. Benefits of Modularity • Maintenance: easier to maintain. • Understandability: easier to comprehend smaller pieces of code. • Reuse: reuse code in other systems. • Correctness: quickly trace failures if it only performs a single task. • Testing: simplifies testing.

42. Figure 3-16  Modularity.

43. Coupling & Cohesion • Concept used to describe objects in the object oriented world. • Highly coupled = requires a lot of other objects to complete a task. • High Cohesion = very independent object • Objects with high coupling have low cohesion.

44. Figure 3-17  Coupling.

45. Object Oriented Programming • Java, PERL, Python, C++. • Programs are a series of connected objects. • Communicate via message passing. • Objects are black boxes • Have data encapsulated. • Has methods that can be called. • Design by breaking problems into objects.

46. Object Oriented Class

47. Encapsulation • Concept used to describe how object oriented design hides data. • An object is a black box. • Object provides methods to access data. • We do not know how the object performs its function. • Hide what should be hidden.

48. Figure 3-18  Information Hiding.