Your SlideShare is downloading. ×
Security Testing for Test Professionals
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Security Testing for Test Professionals

242
views

Published on

Your organization is doing well with functional, usability, and performance testing. However, you know that software security is a key part of software assurance and compliance strategy for protecting …

Your organization is doing well with functional, usability, and performance testing. However, you know that software security is a key part of software assurance and compliance strategy for protecting applications and critical data. Left undiscovered, security-related defects can wreak havoc in a system when malicious invaders attack. If you don’t know where to start with security testing and don’t know what you are—or should be—looking for, this tutorial is for you. Jeff Payne describes how to get started with security testing, introducing foundational security testing concepts and showing you how to apply those concepts with free and commercial tools and resources. Offering a practical risk-based approach, Jeff discusses why security testing is important, how to use security risk information to improve your test strategy, and how to add security testing into your software development lifecycle. You don’t need a software security background to benefit from this important session.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
242
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. TM PM Half day Tutorial 11/12/2013 1:00 PM "Security Testing for Test Professionals" Presented by: Jeff Payne Coveros, Inc. Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888 268 8770 904 278 0524 sqeinfo@sqe.com www.sqe.com
  • 2. Jeff Payne Coveros, Inc. Jeff Payne is CEO and founder of Coveros, Inc., a software company that builds secure software applications using agile methods. Since its inception in 2008, Coveros has become a market leader in secure agile principles and has been recognized by Inc. magazine as one of the fastest growing private US companies. Prior to founding Coveros, Jeff was chairman of the board, CEO, and cofounder of Cigital, Inc., a market leader in software security consulting. Jeff has published more than thirty papers on software development and testing, and testified before Congress on issues of national importance, including intellectual property rights, cyberterrorism, and software quality.
  • 3. Security Testing for Test Professional © Copyright 2013 Coveros Corporation. All rights reserved. 1
  • 4. About Coveros  Coveros helps organizations accelerate the delivery of secure, reliable software  Our consulting services: – – – – Agile software development Application security Software quality assurance Software process improvement Areas of Expertise  Our key markets: – – – – Financial services Healthcare Defense Critical Infrastructure © Copyright 2013 Coveros, Inc.. All rights reserved. 2
  • 5. Agenda  Introduction to Security Testing – – – – Information security Software security Risk assessment Security testing  Security Requirements & Planning – Functional security requirements – Non-functional security requirements – Test planning  Testing for Common Attacks  Integrating Security Testing into the Software Process © Copyright 2013 Coveros, Inc.. All rights reserved. 3
  • 6. Trainer Jeffery Payne jeff.payne@coveros.com Jeffery Payne is CEO and founder of Coveros, Inc., a software company that helps organizations accelerate the delivery of secure, reliable software. Coveros uses agile development methods and a proven software assurance framework to build security and quality into software from the ground up. Prior to founding Coveros, Jeffery was Chairman of the Board, CEO, and co-founder of Cigital, Inc. Under his direction, Cigital became a leader in software security and software quality solutions, helping clients mitigate the risk of software failure. Jeffery is a recognized software expert and popular speaker at both business and technology conferences on a variety of software quality, security, and agile development topics. He has also testified before Congress on issues of national importance, including intellectual property rights, cyber-terrorism, Software research funding, and software quality. © Copyright 2013 Coveros, Inc.. All rights reserved. 4
  • 7. Introduction to Security Testing © Copyright 2013 Coveros, Inc.. All rights reserved. 5
  • 8. What is Information Security? When  you  hear  the  term  “Information Security”  or   “Security Testing”  … What do you think it means? What comes to mind? © Copyright 2013 Coveros, Inc.. All rights reserved. 6
  • 9. What is Information Security? Definition of Information Security  Information Security means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction.  The key concepts of Information Security include: – – – – – Confidentiality Integrity Availability Authenticity Non-Repudiation © Copyright 2013 Coveros, Inc.. All rights reserved. 7
  • 10. The Software Security Problem Our IT systems are not castles any longer! © Copyright 2013 Coveros, Inc.. All rights reserved. 8
  • 11. Why Software Security is Important © Copyright 2013 Coveros, Inc.. All rights reserved. 9
  • 12. Understanding Risk How to Define Security Risk in Software  Common Security Nomenclature – Risk: a possible future event which, if it occurs, will lead to an undesirable outcome – Threat: A potential cause of an undesirable outcome – Asset: Data, application, network, physical location, etc. that a threat may wish to access, steal, destroy, or deny others access to – Vulnerability: Any weakness, administrative process, or act of physical exposure that makes an information asset susceptible to exploit by a threat. – An exploit is a piece of software, a chunk of data, or sequence of commands that takes advantage of a vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic. – Attack: the approach taken by a threat to exploit a vulnerability  Denial of service, spoofing, tampering, escalation of privilege © Copyright 2013 Coveros, Inc.. All rights reserved. 10
  • 13. Understanding Risk Example  Risk – SaaS product is made unavailable and causes software company to violate service agreements with customers  Threat – Competitor who wants to harm company  Asset – Web server that accepts logins  Vulnerability – Buffer overflow in login code that crashes software  Exploit – Input that exercises buffer beyond its expected length  Attack – Denial of service © Copyright 2013 Coveros, Inc.. All rights reserved. 11
  • 14. Understanding Risk Risk Assessment  A risk assessment is commonly carried out by a team of people who have subject area knowledge of the business and product. Members of the team provide a qualitative analysis based on informed opinion of threats that will later be used in a more quantitative analysis.  The team should also define what is an acceptable amount of risk that the organization can assume. We assume we can’t  identify  all  risks  nor  eliminate  them;;  this  is  often   referred to as residual risk. © Copyright 2013 Coveros, Inc.. All rights reserved. 12
  • 15. Exercise Risk Assessment  Break into teams of 2-3 people.  Each team will identify potential threats to a software application described on the next slide. – Who would want to compromise this application? – What assets would they be after if they did?  Once each threat is identified, provide impact and likelihood ratings (High, Medium, Low) for each threat. – Justify your answers  Exercise Time Limit: 15 Minutes © Copyright 2013 Coveros, Inc.. All rights reserved. 13
  • 16. Exercise Risk Assessment  Your company, SecureTelco, has developed an instant messaging program to be used for private use in customers homes and for companies and government agencies.  SecureChat requires users to sign up with an account prior to using the system. After authenticating with a username and password, each user can message other users and expect their conversations to be private.  Users have the ability to add/remove friends from their contact list, search for friends based on their email, block users from IMing them,  become  “invisible”  to  all  users  on  demand.  Messages archives and activities logs document user behavior and can be retrieved by the user or a SecreTelco Administrator through the application or by the administrative console, respectively. © Copyright 2013 Coveros, Inc.. All rights reserved. 14
  • 17. Exercise Risk Assessment Questions to Ask  Business / Mission Motivation – What is the importance/criticality of the system? – What assets exist in the system? – What is the impact if C, I, A principles violated?  User Capabilities and Exposure – How is access different for user roles? – What operations can be performed by different users?  Threat Motivation – – – – Why might someone attack the system? Who might want to attack? (insiders, outsiders) What might attackers accomplish? What’s  the  cost  of  failure? © Copyright 2013 Coveros, Inc.. All rights reserved. 15
  • 18. Exercise Threats and Critical Assets Threats Likelihood Assets Consequence © Copyright 2013 Coveros, Inc.. All rights reserved. 16
  • 19. Security Testing What? How?  Security Testing is testing used to determine whether an information system protects its data from its threats.  Security Testing is not a silver bullet for your enterprise security.    Security  Testing  doesn’t  fix  your  security,  it  only   makes you aware of it. Security must be built into your software  A sound Security Testing process performs testing activities: – – – – – Before development begins During requirements definition and software design During implementation During deployment During maintenance and operations © Copyright 2013 Coveros, Inc.. All rights reserved. 17
  • 20. Security Testing Why is it important?  Provides a level of confidence that your system performs securely within specifications.  Security Testing is a preventative way to find small issues before they become big, expensive ones. – The 2007 CSI Computer Crime and Security Survey performed an analysis of the average cost of a web security breach. The average loss reported in the survey was $350,424.  Security Testing ensures that people in your organization understand and obey security policies.  If involved right from the first phase of system development life cycle, security testing can help eliminate flaws in the design and implementation of the system. © Copyright 2013 Coveros, Inc.. All rights reserved. 18
  • 21. Security Testing Aspects of Security Testing  Major goals of security testing – Test the security features of a system – Test the security properties of a system – Test whether the system is implemented in a secure fashion  Security  features  are  controls  you’ve  implemented  to  protect   your system – Authentication, Authorization, Encryption, etc.  Security properties are closely associated with nonfunctional security requirements  Secure implementation means the software does not have embedded vulnerabilities due to poor design or coding practices © Copyright 2013 Coveros, Inc.. All rights reserved. 19
  • 22. Security Testing Testing Aspects of Security  Testing security features/controls is most akin to normal functional testing – Functional security requirements drive this testing – Integration of security features into overall application  Testing security properties requires tests that cross many features of the system – Develop tests based on non-functional security requirements and identified risks / threats – Tests that assure the implementation does not include known flaws and vulnerabilities © Copyright 2013 Coveros, Inc.. All rights reserved. 20
  • 23. Security Requirements © Copyright 2013 Coveros, Inc.. All rights reserved. 21
  • 24. Requirement Definitions Your Standard Definitions  Functional Requirements: Statements of the services a system should provide, how the system should react to particular inputs and how the system should behave in particular situations.  Non-Functional Requirements: Constraints on the services or functions offered by the system.  Availability, Reliability, Performance, Scalability, Testability, Security © Copyright 2013 Coveros, Inc.. All rights reserved. 22
  • 25. What are Security Requirements? What is a Security Requirement?  Security Requirements describe functional and non-functional requirements that need to be satisfied in order to achieve the security attributes of an IT system or application. What does that mean?  Functional Security Requirements  Functional requirements that define the security features a system needs  Additions to functional requirements that describe what a system should not do  Non-Functional Security Requirements  Non-functional requirements that define what overall security properties that must hold  Often tied to regulation, standards, industry expectations, etc. © Copyright 2013 Coveros, Inc.. All rights reserved. 23
  • 26. Functional Security Requirements Examples of Security Features (aka Security Controls)  Authentication and Identity Management – validating the legitimacy of users  Authorization and Access Control – controlling who has access to what  Input Validation & Encoding – checking system (and API!) inputs for validity  Encryption – protecting information from being see (in transit and at rest)  Error and Exception Handling – handling unexpected conditions properly  Auditing and Logging – tracking usage and other system activities © Copyright 2013 Coveros, Inc.. All rights reserved. 24
  • 27. Functional Security Requirements Using Misuse and Abuse Cases to Identify Requirements  Use cases describe functionality of how someone might use a system  Misuse cases describe how someone might (perhaps unintentionally) do something in the system with a negative security impact  Abuse cases describe how a malicious attacker might deliberately misuse your system to his advantage We use misuse and abuse cases to understand what our system must protect against, help define good security requirements, and drive effectively security testing © Copyright 2013 Coveros, Inc.. All rights reserved. 25
  • 28. Exercise Functional Security Requirements  Break into teams of 2-3 people.  Each team will identify potential misuse cases with the following security requirements, if any exist.  If a misuse case is identified, write a replacement or additional functional requirement(s). – It would be best to make sure no misuse cases can be derived from your new requirement(s).  Exercise Time Limit: 15 Minutes © Copyright 2013 Coveros, Inc.. All rights reserved. 26
  • 29. Exercise Functional Security Requirement Examples  SecureChat Authentication Functional Requirements – When a user attempts to authenticate using a username and a valid password, the application shall authenticate the user and redirect them to the homepage. – When a user attempts to authenticate with a valid username and an invalid password, the application shall not authenticate the user, pop up the message  “Invalid  Password”,    and return them to the authentication page. – When a user attempts to authenticate with a invalid username, the application shall not authenticate the user,  pop  up  the  message  “Invalid   User  ID”,  and return them to the authentication page.  SecureChat Non-Functional Requirements – – – – All communication with the SecureChat central server must be encrypted Stored SecureChat messages will not be viewable by users of the system SecureChat code shall meet company coding standards prior to release SecureChat must have 99.9% availability to its users © Copyright 2013 Coveros, Inc.. All rights reserved. 27
  • 30. Exercise Authentication Use Case Enter username and password SecureChat User User authenticated User redirected to chat screen Invalid password msg Invalid user name msg © Copyright 2013 Coveros, Inc.. All rights reserved. 28
  • 31. Exercise Authentication Use Case Enter username and password SecureChat User Attacks Guess User Accounts User authenticated User redirected to chat screen Invalid UID or Password msg Hacker Threatens Mitigates © Copyright 2013 Coveros, Inc.. All rights reserved. 29
  • 32. Exercise SecureChat Authentication Reqs (New and improved) © Copyright 2013 Coveros, Inc.. All rights reserved. 30
  • 33. Security Test Planning What goes where  Functional security tests based upon the functional security requirements should be planned, designed, and executed along with the rest of the functional testing – Typically covered by a combination of unit, feature, and integration testing activities – Don’t  forget  integration  …  COTS  security  features  are  often  integrated   incorrectly  Non-functional security tests should be planned, designed, and executed as followed: – Unit level: secure code scanning to identify vulnerabilities – Feature level: web application security testing plus any specific nonfunctional security requirements that can be performed at this level – Integration/System levels: more of the above based upon threats & risks – System level: end-to-end testing and penetration testing that must be done a production-like environment © Copyright 2013 Coveros, Inc.. All rights reserved. 31
  • 34. Testing to Mitigate Common Attacks © Copyright 2013 Coveros, Inc.. All rights reserved. 32
  • 35. Common Attacks Input Validation  Most common application security weakness: failure to properly validate input – From client – From environment (often overlooked)  Leads to many of the major vulnerabilities found in applications – – – – Interpreter  injection  (SQL,  JavaScript,  XML,  Command,  …) Locale/Unicode attacks File system attacks Buffer overflows  Data from a client application or a user should never be trusted as they are susceptible to injection attacks © Copyright 2013 Coveros, Inc.. All rights reserved. 33
  • 36. Common Attacks What are Injection Attacks?  Injection attacks result when input from a user is interpreted by a command processor or formed to manipulate the program stack/heap – These are, by far, the most rampant category of attacks over the past 20 years $name = Joe <body><p> Hi, Joe. </p></body> <body><p> <? $msg =  “Hi,  “  +  $name +  “.”;; echo $msg $name = <script src=“http://bad.com/attack.js”/> ?> <body><p> </p></body> Hi, <script src=“http://www.bad.com/attack.js”/>. </p></body> © Copyright 2013 Coveros, Inc.. All rights reserved. 34
  • 37. Common Attacks Common Input Mistakes  Input  characters  that  aren’t  expected – More input than expected – Different input than expected – Executable input that is unexpected  Input encoded strings – Automatically converted/decoded by browsers and other frameworks These  “mistakes”  are  what  attackers  leverage  to  trigger  input   vulnerabilities in our systems © Copyright 2013 Coveros, Inc.. All rights reserved. 35
  • 38. Common Attacks Types of Input Validation  Integrity Checks – Ensure that the data has not been tampered with and is the same as before. – Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return. – The type of integrity control (checksum, HMAC, encryption, digital signature) should be directly related to the risk of the data transiting the trust boundary.  Validation - Ensure that the data is strongly typed, correctly syntaxed, within length boundaries, contains only permitted characters or that numbers are correctly signed and within boundary ranges. – Validation must be performed on every tier. For example, the presentation layer should validate web related issues, persistence layers should validate for persistence issues, etc. © Copyright 2013 Coveros, Inc.. All rights reserved. 36
  • 39. Validating Input Input Validation Approaches  Accept Known Good – Check the data is one of a set of tightly constrained known good values – “Whitelist”  validation – Only works when set of good values is small or previously identified  Reject Known Bad – Reject strings that contain potentially unacceptable characters (ex. If you’re  not  expecting  JavaScript,  reject  %3f) – “Blacklist”  validation – A dangerous strategy because the possible set of bad data is infinite; causes constant maintenance of blacklist  Sanitize – Rather than accept or reject, change the input into an acceptable format – Sound software engineering practice © Copyright 2013 Coveros, Inc.. All rights reserved. 37
  • 40. Common Input Attack #1 Cross-Site Scripting  A very common vulnerability  Allows an attacker to inject script into a vulnerable web system that attacks the user  Example: http://myweb.com/index.php http://myweb.com/index.php?name=Joe Type your name: Joe Hi, Joe!  What happens if we type our name as: <script>alert(“Joe  Hacker!”)</script> © Copyright 2013 Coveros, Inc.. All rights reserved. 38
  • 41. Cross Site Scripting Reflected Cross-Site Scripting  Testing for Reflected Cross-Site Scripting – Reflected Cross Site Scripting (XSS) is another name for nonpersistent  XSS,  where  the  attack  doesn’t  load  with  the  vulnerable   web application but is originated by the victim loading the offending URI  using  the  victim’s  credentials.  Commonly, an attacker creates and tests an offending URI, in which the victim loads the URI on their browser.  Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft and change the content of the page – Testing Process  Detect Input Vectors  Analyze Each input vector to detect potential vulnerabilities. Input data is typically harmless, but triggers web browser responses.  Report on Findings  Analyze report and attempt to exploit with an attack that has a realistic impact on web application security. © Copyright 2013 Coveros, Inc.. All rights reserved. 39
  • 42. Cross Site Scripting Stored Cross-Site Scripting  Testing for Stored Cross-Site Scripting – Stored XSS is the most dangerous type. Web applications that allow users to store data are potentially exposed to this type of attack.  This occurs when a web application gathers malicious input and stores, unfiltered, that input in a data store for later use. As a consequence the malicious  data  will  appear  to  be  part  of  the  web  site  and  run  on  the  user’s   browser.  The more privileges the end user has the more dangerous this attack is. – Testing Process      Identify input forms Analyze HTML Code Test for Stored XSS Report on Findings Analyze report and attempt to exploit with an attack that has a realistic impact on web application security. © Copyright 2013 Coveros, Inc.. All rights reserved. 40
  • 43. Cross Site Scripting Cross Site Scripting  Testing for DOM-Based Cross Site Scripting – DOM-based XSS is the name for bugs which are the result of active content on a page, typically obtaining user input and doing something unsafe with it to lead to a XSS bug.  In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user  and  executed  in  the  context  of  the  user’s  browser,  a  DOM  based  cross  site   scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow. – Manual testing is almost always required for this type of XSS attack and requires knowledge of the code, especially around any use of JavaScript. © Copyright 2013 Coveros, Inc.. All rights reserved. 41
  • 44. Cross Site Scripting Cross Site Scripting  Testing for Cross Site Flashing – ActionScript is the language used by Flash applications when dealing with interactive needs due to some poor implementation patterns.  New versions of Flash player are often released to mitigate some attacks, but poor programming practices often still result in exploits. – Manual testing is almost always required for this type of XSS attack and requires knowledge of the code, especially around any use of ActionScript. © Copyright 2013 Coveros, Inc.. All rights reserved. 42
  • 45. Common Input Attack #2 SQL Injection  What is SQL Injection? – An  SQL  injection  attack  consists  of  the  insertion  or  “injection”  of  an   SQL query via input data from the client to the application. A successful exploit could read sensitive data, modify data, execute administrative operations, recover the content to a given file and, in some cases, issue commands to the operating system.  Types of SQL Injection – Inband – Data is extracted using the same channel that is used to inject SQL code. In the simplest form, the retrieved data is presented directly to the application web page. – Out-of-band – Data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester). – Inferential – Data is not transferred, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server. © Copyright 2013 Coveros, Inc.. All rights reserved. 43
  • 46. Common Attack #2: SQL Injection SQL Injection Example  Consider the following SQL query: – SELECT * FROM Users WHERE Username='$username' AND Password='$password'  Assume the values of the input fields are obtained from the user through a web form. Suppose we insert the following Username and Password values: – $username = 1' or '1' = '1 – $password = 1' or '1' = '1  The query will be: – SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1' © Copyright 2013 Coveros, Inc.. All rights reserved. 44
  • 47. SQL Injection SQL Injection Example (cont.)  Another test involves the use of the UNION operator. We suppose for our examples that the query executed from the server is the following: – SELECT Name, Phone, Address FROM Users WHERE Id=$id  We will set the following Id value: – $id = 1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable  NOTE: we have selected other two values. These two values are necessary, in order to avoid a syntax error.  We will have the following query: – SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable  The keyword ALL can be used to get around the DISTINCT keyword. © Copyright 2013 Coveros, Inc.. All rights reserved. 45
  • 48. SQL Injection Testing for SQL Injection (cont.)  Where to look for SQL Injection – Authentication forms: Chances are high that the user credentials are checked against a database that contains all usernames and passwords (or their password hashes) – Search Engines: Strings submitted could be used in a query that extracts relevant records from a database. – E-Commerce Sites: Products and their characteristics are very likely to be stored in a database. – Use your inherent knowledge of your application to pinpoint your testing efforts. © Copyright 2013 Coveros, Inc.. All rights reserved. 46
  • 49. Common Attacks Use Tools!  Testing for all cases of injection attacks can be laborious  There are lots of tools out there to help  Leverage tools but also make sure validation code is correct  Understand architecture to test unique components that include scripting / executable capabilities © Copyright 2013 Coveros, Inc.. All rights reserved. 47
  • 50. Exercise Security tests for SecureChat Authentication  Architectural Features: – SecureChat login screen is a web page – User information is stored within a mysql database on the backend – Data transmission from the front to back end is encrypted by a 3rd party library  Develop a set of tests for SecureChat Authentication that: – Cover the improved security requirements we developed – Consider the risks associated with web inputs, SQL, secure communication, etc. © Copyright 2013 Coveros, Inc.. All rights reserved. 48
  • 51. Integrating Security into Your Testing Process © Copyright 2013 Coveros, Inc.. All rights reserved. 49
  • 52. Software Development Life Cycle How do you add Security in? Define Use/Abuse cases Security requirements Design Threat modeling Security test planning Develop Static Analysis Risk-based security testing Deploy Assess threats and assets Penetration testing © Copyright 2013 Coveros, Inc.. All rights reserved. 50
  • 53. Tools to Support Security Testing Classes of Tools  Risk-based security testing tools – Proactive web app scanners – Proxies – Fuzzers  Secure code scanning tools  Threat modeling (planning tool)  Network scanning tools  Password Crackers © Copyright 2013 Coveros, Inc.. All rights reserved. 51
  • 54. Tools to Support Security Testing Web Application Scanners and Proxies  Where to use? – Looking for XSS, Injection and input validation vulnerabilities; some tools will attempt to actively exploit vulnerabilities.  Free Tools – – – – – – – Zed Attack Proxy Nikto W3af Paros Skipfish Wapiti wfuzz  Paid Tools – Netsparker – WebSecurify – Big Commercial: IBM AppScan, Cenzic Hailstorm, HP WebInspect © Copyright 2013 Coveros, Inc.. All rights reserved. 52
  • 55. Tools to Support Security Testing Password Crackers & Brute Force Tools  Where to use? – When you want to break the default credentials or test your authentication mechanisms against common security tools.  Free Tools – THC Hydra – Cain and Abel – Wfuzz  Paid Tools – John the Ripper © Copyright 2013 Coveros, Inc.. All rights reserved. 53
  • 56. Tools to Support Security Testing Network Security Tools  Where to use? – Scanning for mis-configurations – Testing for OS, application and network vulnerabilities  Free Tools – OpenVAS  Paid Tools – Nessus – Core Impact © Copyright 2013 Coveros, Inc.. All rights reserved. 54
  • 57. Wrap-Up © Copyright 2013 Coveros, Inc.. All rights reserved. 55
  • 58. References  OWASP  Foundation,  “OWASP  Testing  Guide  v3”,     https://www.owasp.org/index.php/OWASP_Testing_Project, 2008  Hope  and  Walther,  “Web  Security  Testing  Cookbook:  Systematic  Techniques  to   Find  Problems  Fast,”  O’Reilly,  2008  Whittaker  and  Thompson,  “How  to  Break  Software  Security,”  Addison-Wesley, 2003  Schneier,  Bruce,  “Secrets  and  Lies:  Digital  Security  in  a  Networked  World,”   Wiley, 2000 © Copyright 2013 Coveros, Inc.. All rights reserved. 56
  • 59. Questions? Contact Information: http://www.coveros.com info@coveros.com 703.431.2920 © Copyright 2013 Coveros, Inc.. All rights reserved. 57