Software Security
Download as PPTX, PDF0 likes545 views
The document discusses seven touchpoints for building security into software systems. The touchpoints are ordered from most to least effective and include code review, architectural risk analysis, penetration testing, risk-based security testing, abuse cases, security requirements, and security operations. Conducting code reviews alone can find around 50% of security issues, so a comprehensive approach using multiple touchpoints is recommended to holistically address security risks.
Ad
More Related Content
What's hot (20)
Similar to Software Security (20)
Ad
More from Integral university, India (17)
Ad
Recently uploaded (20)
Software Security
- 1. Seven Touch points for Software Security
- 2. • The touch points are one of the three pillars of software security • You don't have to adopt all seven touchpoints to begin to build security in (though doing so is highly recommended).
- 3. • The figure above shows the seven touchpoints ordered according to effectiveness and importance • The touchpoints are designed to fill the gap between the state of the art and the state of the practice-something that can be done only through the common adoption of best practices
- 4. • Touchpoints are a mix of destructive and constructive activities. • Destructive activities are about attacks, exploits, and breaking software. • These kinds of things are represented by the black hat (offense).
- 5. • Constructive activities are about design, defense, and functionality. • These are represented by the white hat (defense). • Both hats are necessary.
- 6. • Here are the touchpoints, in order of effectiveness: • 1. Code review • 2. Architectural risk analysis • 3. Penetration testing • 4. Risk-based security tests • 5. Abuse cases • 6. Security requirements • 7. Security operations
- 7. • 1. Code Review (Tools) Artifact: Code Example of risks found: Buffer overflow on line 42 • All software projects produce at least one artifactcode. • This fact moves code review to the number one slot on our list. • At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. • Several tools vendors now address this space. • Code review is a necessary but not sufficient practice for achieving secure software. • Security bugs (especially in C and C++) are a real problem, but architectural flaws are just as big a problem. • you'll learn how to review code with static analysis tools in next upcoming units
- 8. • Doing code review alone is an extremely useful activity, but given that this kind of review can only identify bugs, the best a code review can uncover is around 50% of the security problems. • Architectural problems are very difficult (and mostly impossible) to find by staring at code. • This is especially true for modern systems made of hundreds of thousands of lines of code. • A comprehensive approach to software security involves holistically combining both code review and architectural analysis.
- 9. • 2. Architectural Risk Analysis Artifact: Design and specification • Examples of risks found: Poor compartmentalization and protection of critical data; failure of a Web Service to authenticate calling code and its user and to make access control decisions based on proper context • At the design and architecture level, a system must be coherent and present a unified security front
- 10. • Designers, architects, and analysts should clearly document assumptions and identify possible attacks. • At both the specifications-based architecture stage and at the class-hierarchy design stage, architectural risk analysis is a necessity. • At this point, security analysts uncover and rank architectural flaws so that mitigation can begin. • Disregarding risk analysis at this level will lead to costly problems down the road.
- 11. • Note that risks crop up during all stages of the software lifecycle, so a constant risk management thread, with recurring risk- tracking and monitoring activities, is highly recommended. • Chapter 2 describes the RMF process and how to apply it. Chapter 5 teaches about architectural risk analysis and will help you ferret out flaws in software architecture.
- 12. Penetration Testing Artifact: System in its environment Example of risks found: Poor handling of program state in Web interface • Penetration testing is extremely useful, especially if an architectural risk analysis informs the tests. • The advantage of penetration testing is that it gives a good understanding of fielded software in its real environment. • Software that fails during the kind of canned black box testing practiced by prefab application security testing tools is truly bad. Thus, passing a low-octane penetration test reveals little about your actual security posture, but failing a canned penetration test indicates that you're in very deep trouble indeed.
- 13. • thank you
- 14. Risk-Based Security Testing • Artifact: Units and system • Example of risks found: Extent of data leakage possible by leveraging data protection risk • Security testing must encompass two strategies: • (1) testing of security functionality with standard functional testing techniques and • (2) risk-based security testing based on attack patterns, risk analysis results, and abuse cases. • A good security test plan embraces both strategies.
- 15. • Security problems aren't always apparent, even when you probe a system directly, so standard-issue quality assurance is unlikely to uncover all critical security issues. • QA is about making sure good things happen. Security testing is about making sure bad things don't happen. • Thinking like an attacker is essential. • Guiding security testing with knowledge of software architecture, common attacks, and the attacker's mindset is thus extremely important.
- 16. Security Operations Artifact: Fielded system • Example of risks found: Insufficient logging to prosecute a known attacker • Software security can benefit greatly from network security. • Well-integrated security operations allow and encourage network security professionals to get involved in applying the touchpoints, providing experience and security wisdom that might otherwise be missing from the development team.
- 17. • Battle-scarred operations people carefully set up and monitor fielded systems during use to enhance the security posture. • Attacks do happen, regardless of the strength of design and implementation, so understanding software behavior that leads to successful attack is an essential defensive technique. • Knowledge gained by understanding attacks and exploits should be cycled back into software development.
- 18. Abuse Cases Artifact: Requirements and use cases • Example of risks found: Susceptibility to well-known tampering attack • Building abuse cases is a great way to get into the mind of the attacker. • Similar to use cases, abuse cases describe the system's behavior under attack • Building abuse cases requires explicit coverage of what should be protected, from whom, and for how long.
- 19. Security Requirements Artifact: Requirements • Example of risks found: No explicit description of data protection needs • Security must be explicitly worked into the requirements level. • Good security requirements cover both overt functional security (say, the use of applied cryptography)
- 20. • emergent characteristics (best captured by abuse cases and attack patterns). • The art of identifying and maintaining security requirements is a complex undertaking that deserves broad treatment.