ObjectOriented Software Engineering An Agile Unified Methodology by

Key Takeaway Points • Software security is a proactive, rather than reactive, approach to constructing secure software. • Consideration of software security should begin in the requirements phase and continue throughout the life cycle. 24 -2 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Security Requirements • Security requirements define the capabilities of the software system to thwart attempted attacks and recover from successful attacks. • There are many different types of security requirements (page 608). • Not all systems require all types of security requirements. • Security requirements are associated with costs to design and implement. • Which security requirements are needed for a system is a project dependent decision. 24 -3 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Secure Software Design Principles Principle 1. Secure the weakest link. Principle 2. Practice defense in depth. Principle 3. Fail securely. Principle 4. Least privilege. Principle 5. Compartmentalize. Principle 6. Keep it simple and stupid. Principle 7. Promote privacy. Principle 8. Remember that hiding secrets is hard. Principle 9. Be reluctant to trust. Principle 10. Use community resources. 24 -4 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Secure Software Design Patterns (p. 611) Architectural security patterns: • Privilege Reduction • Privilege Separation • Defer to Kernel • Single Access Point • Check Point • Secure Access Layer Design security patterns: • Roles/RBAC Implementation security patterns • Secure Pipe • Session • Input Validation • Secure Logger 24 -5 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

SAMS Example 24 -6 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All

Seven Best Practices of Software Security 1. 2. 3. 4. 5. 6. 7. Code review Architectural risk analysis Penetration testing Risk based security testing Misuse cases Security requirements Security operation 24 -7 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Attack Tree • An attack tree is an And-Or tree, each nonterminal is an AND node, or OR node. • Each non-terminal represents a problem to be solved or a goal to be accomplished. • An AND node means the problem is solved if the problems represented by its children are solved. An OR node means the problem is solved if the problem of one of its children is solved. • An attack tree describes the options to accomplish an attack. 24 -8 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Software Security in the Life Cycle domain modeling security requirements misuse cases security architectural design security test planning Planning & Architectural design modify planning and architectural design w. r. t. changes Accommodate Change modify domain model to help understand security related concepts Domain Modeling design for security apply security patterns and secure design principles review design to detect security flaws Software Design test w/security requirements apply static analysis tools perform penetration testing and misuse case testing Implementation, Test & Deployment 24 -9 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Tool Support for Software Security • Sea. Monster is a security modeling tool for threat models, namely attack trees and misuse cases, and can connect to a repository for model sharing and reuse. • PMD is a Java static code analyzer. • Find. Bugs is a Java static analyzer, and looks for bugs in Java programs. • WASSP is a “hardening” tool which identifies problems on a running system 24 -10 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.