* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Chapter 03
Survey
Document related concepts
Transcript
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? 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. 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. Threat Model (design phase) 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. 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. 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. 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. Figure 3-19 Fault Discovery Rate Reported at Hewlett-Packard. 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. 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. Nessus Vulnerability Scanner (assess phase) 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)5551234&price=10 ◦ Tools: Hackbar, Tamper Data, OWASP Web Scarab, etc. Figure 3-1 Places Where a Buffer Can Overflow. Metasploit Pen Testing 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. 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. 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? 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. Figure 3-4 Virus Appended to a Program. Figure 3-5 Virus Surrounding a Program. Figure 3-6 Virus Integrated into a Program. Figure 3-7 Virus Completely Replacing a Program. Figure 3-8 Boot Sector Virus Relocating Code. Figure 3-9 Recognizable Patterns in Viruses. Anti-Virus is Reactionary 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. Protection Ring Model 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 Root Kit Protection (OSSEC) 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. Figure 3-10 Stubs and Drivers. 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. Figure 3-11 Covert Channel Leaking Information. Figure 3-12 Covert Channels. Figure 3-13 File Lock Covert Channel. Figure 3-14 File Existence Channel Used to Signal 100. Figure 3-15 Covert Timing Channel. 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? 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. 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. Figure 3-16 Modularity. 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. Figure 3-17 Coupling. 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. Object Oriented Class 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. Figure 3-18 Information Hiding.