Beyond security testing

579 views

Published on

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
579
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Beyond security testing

  1. 1. Beyond Security Testing A Seminar C.D. Nguyen, PhD SE-Group / FBK http://selab.fbk.eu/dnguyen/ Trento, April 2013 1
  2. 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, don’t 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. 3. Agenda 1.Introduction 2.Engineering secure software systems 3.The role of a security tester
  4. 4. Part I: Introduction
  5. 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 influence today’s software development 5
  6. 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. 7. Examples
  8. 8. Security in mobile world
  9. 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. 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 It’s better to consider security right from start: • Security is a feature, it needs resource too, but it’s planned, no surprise • Require more resource at the beginning, but overall cheaper •The released product is more secure!!!
  11. 11. Part II: Engineering Secure Software Systems
  12. 12. Software Engineering (SE) Basis about: • What is software? • What is software engineering? • What is a software process?
  13. 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 specification. • New software can be created by developing new programs, configuring generic software systems or reusing existing software. Slide credit: Ian Sommerville - Software Engineering, 7th Edition
  14. 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. 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: • Specification - 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. 16. Software process models? • Are software process seen from specific perspective, e.g. workflow, role/action • Many process models exist, no “one side fit all) Example: Iterative developme nt !
  17. 17. SE for secure systems Development Activities Security Feature Requirement Specification Analysts Design Designers Implementation Dev. Testing &Validation Test engineers It’s everyone’s concerns!
  18. 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. 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. 20. Microsoft® Security Development Lifecycle (SDL) • Requirements: • Security and privacy analysis involves security experts, define security criteria • Defines 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. 21. Microsoft® Security Development Lifecycle (SDL) • Design: • Create security and privacy design specifications, specification review • Analyze attack surface • Threat modeling: understand security threats to a system, determine risks from those threats, and establish appropriate mitigations.
  22. 22. Microsoft® Security Development Lifecycle (SDL) • Verification: • Dynamic analysis, leveraging tools which monitor application behavior • Fuzz Testing • Attack surface review
  23. 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. 24. Thread modeling • How to determine threats: • Using known categories of threats (STRIDE: Spoofing identity,Tampering with data ….) • Tools: • SDL Threat Modeling Tool 3.1.8 (Microsoft) • SecureTropos • Misuse case
  25. 25. Examples of threat models A Model Transformation from Misuse Cases to Secure Tropos Naved Ahmed1 , Raimundas Matuleviˇcius1 , 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. 26. Examples of threat models A Model Transformation from Misuse Cases to Secure Tropos Naved Ahmed1 , Raimundas Matuleviˇcius1 , 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 Tropos
  27. 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, we’ve made our software and services more compelling for users by adding new features and functionality, and by making our platform richly extensible. We’ve done a terrific job at that, but all those great features won’t 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. 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: http://www.biztechmagazine.com/, http://www.techradar.com
  29. 29. Part III:The role of a security tester
  30. 30. Security testing • Security testing is an important part of the overall process • If you don’t perform security testing for your application, someone else NOT working for your company will • But, it’s different from normal testing • Security testing is to demonstrate that threat mitigation techniques work • Buy showing that user’s identify cannot be spoofed, data cannot be tampered…. • (Security) testers: • keep everyone honest • have the final STAMP as to whether your application ships • Security testers should adopt a hacker’s mindset 30
  31. 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. 32. Examples of component interfaces • TCP and UDP sockets s Wireless data • NetBIOS • Mailslots • Dynamic Data Exchange (DDE) • Named Pipes • Shared memory • Other named objects—Named Pipes and shared memory are named objects—such 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 <OBJECT> 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. 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 application’s 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. 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: http://www.phrack.org/ issues.html?issue=7&id=3&mode=txt
  35. 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. 36. Summary • Software process lifecycle with security does exist • Microsoft® SDL is a systematic and comprehensive one • Security testing is different from normal testing • It’s hard but we have to, otherwise your enemies will do • Ethical hacker’s mindset helps
  37. 37. To read more Writing Secure Code, Second Edition Michael Howard and David LeBlanc

×