Software Security Engineering - Build Security In - US-CERT

More documents

Recommendations

Info

Attack Resistance, Attack Tolerance, and Attack Resilience • The ability of software to function in the face of attack can be broken down into three primary characteristics: attack resistance, attack tolerance, and attack resilience. • Attack resistance is the ability of the software to prevent the capability of an attacker to execute an attack against it. The most critical of the three characteristics, it is nevertheless often the most difficult to achieve, as it involves minimizing exploitable weaknesses at all levels of abstraction, from architecture through detailed implementation and deployment. Indeed, sometimes attack resistance is impossible to fully achieve. • Attack tolerance is the ability of the software to “tolerate” the errors and failure that result from successful attacks and, in effect, to continue to operate as if the attacks had not occurred. • Attack resilience is the ability of the software to isolate, contain, and limit the damage resulting from any failures caused by attacktriggered faults that the software was unable to resist or tolerate and to recover as quickly as possible from those failures. • Attack tolerance and attack resilience are often a result of effective architectural and design decisions rather than implementation wizardry. © 2008 Cigital Inc. All Rights Reserved. Thursday, November 06, 2008 26
The Attacker’s Perspective • Assuming the attacker’s perspective involves looking at the software from the outside in. • It requires thinking like attackers think, and analyzing and understanding the software the way they would to attack it. • Through better understanding of how the software is likely to be attacked, the software development team can better harden and secure it against attack. • Attack Patterns can be used to effectively capture the attacker’s perspective and share it among all members of the team • Attack Patterns can be leveraged throughout the SDLC such that decisions and actions are taken with knowledge of how the software is likely to be attacked © 2008 Cigital Inc. All Rights Reserved. Thursday, November 06, 2008 27
Page 1 and 2: Software Security Engineering Softw
Page 3 and 4: So What Is Software Security? Softw
Page 5 and 6: Build Security In: A Key Resource
Page 7 and 8: Why is Security a Software Issue?
Page 9 and 10: The Problem • Organizations incre
Page 11 and 12: Software that has been developed wi
Page 13 and 14: Software Security Always Has a Cost
Page 15 and 16: The Risk Management Framework • B
Page 17 and 18: What makes software secure? © 2008
Page 19 and 20: Core Properties of Secure Software
Page 21 and 22: Influencing the Security Properties
Page 23 and 24: Addressing the Expected: Security A
Page 25: Addressing the Unexpected: Avoiding
Page 29 and 30: Parting Thoughts on Secure Software
Page 31 and 32: SDLC With Defined Security Touchpoi
Page 33 and 34: Assess Security Risk Across the SDL
Page 35 and 36: Maturity Indicators Maturity Level
Page 37 and 38: Software Security Practices That Sp
Page 39 and 40: Software Security Practices That Sp
Page 41 and 42: Requirements Engineering Practices
Page 43 and 44: Architecture and Design Practices 2
Page 45 and 46: Coding and Testing Practices 2 Prac
Page 47 and 48: Coding and Testing Practices 4 Prac
Page 49 and 50: Security Analysis for System Comple
Page 51 and 52: Security Analysis for System Comple
Page 53 and 54: Governance and Management Practices
Page 55 and 56: Governance and Management Practices
Page 57 and 58: Recommendations Treat software secu
Page 59: Contact Information Sean Barnum Pri

Software Security Engineering - Build Security In - US-CERT

Create successful ePaper yourself

Delete template?

Save as template?