beyond security testing

of 37 /37
Beyond Security Testing A Seminar C.D. Nguyen, PhD SE-Group / FBK Trento, April 2013 1

Author: cu-nguyen

Post on 02-Nov-2014




1 download

Embed Size (px)




  • 1. Beyond Security Testing A Seminar C.D. Nguyen, PhD SE-Group / FBK 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: 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} 2 School of Computing and Technology, University of East London, UK [email protected] 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} 2 School of Computing and Technology, University of East London, UK [email protected] 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 Tropos
  • 27. A successful story: Windows 7 Memo from Bill Gates Jan. 15, 2002 ... designed from the ground up to deliver Trustworthy Computing. What I mean by this is that customers will always be able to rely on these systems to be available and to secure their information. Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony. ! ... In the past, weve made our software and services more compelling for users by adding new features and functionality, and by making our platform richly extensible. Weve done a terrific job at that, but all those great features wont matter unless customers trust our software. So now, when we face a choice between adding features and resolving security issues, we need to choose security. Our products should emphasize security right out of the box, and we must constantly refine and improve that security as threats evolve.
  • 28. A successful story: Windows 7 Microsoft has changed radically its engineering process to include security Resulting: Windows 7 is much more secure than previous versions, more security features Address Space Layout Randomization (ASLR) PatchGuard, to prevent unauthorized programs from modifying the operating system kernel User Account Control (UAC), least privilege principle Protected Mode Internet Explorer (PMIE) Source:,
  • 29. Part III:The role of a security tester
  • 30. Security testing Security testing is an important part of the overall process If you dont perform security testing for your application, someone else NOT working for your company will But, its different from normal testing Security testing is to demonstrate that threat mitigation techniques work Buy showing that users identify cannot be spoofed, data cannot be tampered. (Security) testers: keep everyone honest have the nal STAMP as to whether your application ships Security testers should adopt a hackers mindset 30
  • 31. Security tester role Building Security Test Plans from a Threat Model 1.Decompose the application into its fundamental components. 2.Identify the component interfaces. 3.Rank the interfaces by potential vulnerability. 4.Ascertain the data structures used by each interface. 5.Find security problems by injecting mutated data. Testing (with security templates) & Finding bugs
  • 32. Examples of component interfaces TCP and UDP sockets s Wireless data NetBIOS Mailslots Dynamic Data Exchange (DDE) Named Pipes Shared memory Other named objectsNamed Pipes and shared memory are named objectssuch as semaphores and mutexes The Clipboard Local procedure call (LPC) and remote procedure call (RPC) interfaces COM methods, properties, and events Parameters to ActiveX Controls and Applets (usually tag arguments) EXE and DLL functions System traps and input/output controls (IOCTLs) for kernel-mode components s The registry HTTP requests and responses Simple Object Access Protocol (SOAP) requests Remote API (RAPI), used by Pocket PCs Console input Command line arguments Dialog boxes Database access technologies, including OLE DB and ODBC Database stored procedures Store-and-forward interfaces, such as e-mail using SMTP, POP, or MAPI, or queuing technologies such as MSMQ Environment (environment variables) Files Microphone LDAP sources, such as Active Directory Hardware devices, such as infrared using Infrared Data Association (IrDA), universal serial bus (USB), COM ports, FireWire (IEEE 1394), Bluetooth and so on
  • 33. Data mutation (Fuzz testing) Important The application has suffered a DoS attack if you can make a networked service fail with an access violation or some other exception. The development team should take these threats seriously, because they will have to fix the bug after the product ships if the defect is discovered. Figure 19-1 shows techniques for perturbing an applications environment. F19GO01 Figure 19-1 Techniques to perturb applications to reveal security vul- nerabilities and reliability bugs. Does not exist (Od) Exists (Oe)Restricted access (Or) No access (Oa) Data Long (Ll) Short (Ls) Zero length (Lz) Zero (Cz) Null (Cn) Valid + Invalid (Cv) Random (Cr) Wrong type (Ct) Replay (Nr) Out-of-sync (No) High volume (Nh) Contents Applies to on-the-wire data Size Link (Ol) Name (On)Container Security data mutation techniques Wrong sign (Cs) Out of bounds (Co) Special characters Slashes (Cps) Quotes (Cpq) HTML (Cph) Escaped (Cpe) Script (Cps) Meta (Cpm)
  • 34. Hackers' mindset See things from different perspectives, with genius and curiosity Breaking things is a nature Earn respect by solving interesting problems. Hacker's Manifesto: issues.html?issue=7&id=3&mode=txt
  • 35. Summary Security problems are on the news headlines every day Unfortunately, there is no security in the old-but-still-used software practices We need to build security in software from ground up It is a product feature, not a wrapping layer
  • 36. Summary Software process lifecycle with security does exist Microsoft SDL is a systematic and comprehensive one Security testing is different from normal testing Its hard but we have to, otherwise your enemies will do Ethical hackers mindset helps
  • 37. To read more Writing Secure Code, Second Edition Michael Howard and David LeBlanc