Beyond security testing

  • View
    90

  • Download
    1

Embed Size (px)

DESCRIPTION

 

Text of Beyond security testing

  • 1. Beyond Security Testing A Seminar C.D. Nguyen, PhD SE-Group / FBK http://selab.fbk.eu/dnguyen/ Trento, April 2013 1
  • 2. Before we start About the presenter: A security-enthusiastic SE researcher: work to improve software quality promote to build secure softwares, because security is a feature, not an afterthought About this seminar Open, dont hesitate to interrupt Love to discuss & learn your white-hat hacking experience Last but not least good news: No exam related to this seminar
  • 3. Agenda 1.Introduction 2.Engineering secure software systems 3.The role of a security tester
  • 4. Part I: Introduction
  • 5. The need of secure systems The good old days, 1990s, PCs are isolated, with little (or no) connectivity Security is not a problem, as long as Apps work No security concern in most of the engineering books!!! However, old practices still inuence todays software development 5
  • 6. The need of secure systems In the Internet era: All devices are connected, virtually This gives a huge opportunity to attackers have assess to target devices systems are not designed with security The Internet was not designed with security in mind (CERT)
  • 7. Examples
  • 8. Security in mobile world
  • 9. Security is a product feature Security is a feature, just like other feature in the product Ensure availability Secure customer information Help gain users trust Do not treat security as an afterthought People often add security as a wrapping layer around other features and consider security only when it needs to: when having resource or after being attacked This is wrong!!!
  • 10. Security is a product feature Adding security as an afterthought is wrong, why? Late addition of any feature, including security, is expensive Might impact & change other features, expensive too Break the current interfaces Its better to consider security right from start: Security is a feature, it needs resource too, but its planned, no surprise Require more resource at the beginning, but overall cheaper The released product is more secure!!!
  • 11. Part II: Engineering Secure Software Systems
  • 12. Software Engineering (SE) Basis about: What is software? What is software engineering? What is a software process?
  • 13. What is software? Computer programs and associated documentation such as requirements, design models and user manuals. Software products may be developed for a particular customer or may be developed for a general market. Software products may be Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word. Tailored - developed for a single customer according to their specication. New software can be created by developing new programs, conguring generic software systems or reusing existing software. Slide credit: Ian Sommerville - Software Engineering, 7th Edition
  • 14. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available. Slide credit: Ian Sommerville - Software Engineering, 7th Edition
  • 15. What is a software process? A set of activities whose goal is the development or evolution of software. Generic activities in all software processes are: Specication - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands Slide credit: Ian Sommerville - Software Engineering, 7th Edition
  • 16. Software process models? Are software process seen from specic perspective, e.g. workow, role/action Many process models exist, no one side t all) Example: Iterative developme nt !
  • 17. SE for secure systems Development Activities Security Feature Requirement Specication Analysts Design Designers Implementation Dev. Testing &Validation Test engineers Its everyones concerns!
  • 18. SE for secure systems Team training Security knowledge is essential: secure design, secure coding, and more thorough testing Often team members are not security-equipped, pre-training is needed Security experts can take part in security reviews Software process model with security by default Embody security engineering aspects in every activity
  • 19. Microsoft Security Development Lifecycle (SDL) More info: http://www.microsoft.com/security/sdl/default.aspx The most comprehensive & systematic process model publicly available.
  • 20. Microsoft Security Development Lifecycle (SDL) Requirements: Security and privacy analysis involves security experts, dene security criteria Denes the severity thresholds of security vulnerabilities for example, no known vulnerabilities in the application with a critical or important rating at time of release Security risk assessments (SRAs) and privacy risk assessments (PRAs) identify functional aspects of the software that require closer review
  • 21. Microsoft Security Development Lifecycle (SDL) Design: Create security and privacy design specications, specication review Analyze attack surface Threat modeling: understand security threats to a system, determine risks from those threats, and establish appropriate mitigations.
  • 22. Microsoft Security Development Lifecycle (SDL) Verication: Dynamic analysis, leveraging tools which monitor application behavior Fuzz Testing Attack surface review
  • 23. Thread modeling Formally specify: Potential enemies attackers Security threats Risks from those threats Mitigation solutions Done at design phase, used in all sub-sequence phases, including testing
  • 24. Thread modeling How to determine threats: Using known categories of threats (STRIDE: Spoong identity,Tampering with data .) Tools: SDL Threat Modeling Tool 3.1.8 (Microsoft) SecureTropos Misuse case
  • 25. Examples of threat models A Model Transformation from Misuse Cases to Secure Tropos Naved Ahmed1 , Raimundas Matulevicius1 , and Haralambos Mouratidis2 1 Institute of Computer Science, University of Tartu, Estonia {naved,rma}@ut.ee 2 School of Computing and Technology, University of East London, UK h.mouratidis@uel.ac.uk Fig. 2. Misuse Case Diagram A resource (e.g., Account) is an entity required by actors. In Secure Tropos, se- curity constraint (e.g., Only by bank customer and Only by bank officer) Threat modeled as Use Cases & Misuse Cases
  • 26. Examples of threat models A Model Transformation from Misuse Cases to Secure Tropos Naved Ahmed1 , Raimundas Matulevicius1 , and Haralambos Mouratidis2 1 Institute of Computer Science, University of Tartu, Estonia {naved,rma}@ut.ee 2 School of Computing and Technology, University of East London, UK h.mouratidis@uel.ac.uk A resource (e.g., Account) is an entity required by actors. In Secure Tropos, se- curity constraint (e.g., Only by bank customer and Only by bank officer) is a constraint that the system must possess. A threat (e.g., Money stolen) rep- resents an event that endangers the security features of system. Additionally, vulnerability point is represented by a black circle in Fig.3 (adapted from [5]). Fig. 3. Secure Tropos Diagram Secure Tropos uses relationships to connect constructs. Dependency link shows that one actor (depender) depends on another actor (dependee) to attain Threat modeled with Secure Trop