Upgrade to Pro — share decks privately, control downloads, hide ads and more …

So You Want to Hire a Penetration Tester?: 10 T...

So You Want to Hire a Penetration Tester?: 10 Tips for Success

Whether due to compliance needs, best practices, or customer demand, penetration testing is an increasing requirement for many organizations. The process of hiring and working with an Ethical Hacking (EH) services company is much like every other IT contracting process at first glance, but has a number of important details to consider from company selection through post-penetration remediation.

Come learn from a penetration tester the types of information that will allow your organization to have the best experience possible when going through the sometimes agonizing, always interesting, process of a penetration test. Most importantly, questions will be highly encouraged so that your concerns and thoughts can be addressed during this presentation.

Mark Stanislav

April 18, 2013
Tweet

More Decks by Mark Stanislav

Other Decks in Technology

Transcript

  1. ME Performing ethical hacking services for MSSP: External/internal penetration testing

    External/internal vulnerability assessment Web application security review Code auditing Security architecture review Certified: CISSP, Security+, Linux+, CCSK Public web application vulnerability research
  2. #1: Credentials & Reputation Matter Hiring someone to break into

    your systems and applications can lead to very bad things if they are not knowledgable enough to handle the responsibility Don’t just hire the lowest rate if at all possible Automation of penetration testing is extremely common and can lead to data corruption, Denial of Service (DoS), and unexpected downtime Ask potential consultants what their IT experience is, what security certifications they hold, their approach to penetration testing, and to review a sample report
  3. #2: Understand What You Want Ethical Hacking (EH) services are

    very broad and different services encompass different depths and types of testing Discuss with your PCI-QSA or other compliance person which EH service will satisfy a given portion of the regulation or standard your org adheres to Asking for “Security Testing” will not help you... If you only need a vulnerability scan, don’t pay for a penetration test -- these services cost a lot of money
  4. #3: Know Why You Need It A professional security services

    company should care why you are doing what you are asking to do Be able to explain what you are trying to accomplish so that consultants are able to recommend ways to decrease potential headaches/cost overhead A few typical reasons to have EH services are: Compliance/regulation requirement A customer demands that you do it Proactive security (this doesn’t happen a lot, sadly)
  5. #4: Be Prepared For Questions Successful EH services involve a

    lot of customer interaction, especially when doing a penetration test Common questions to be prepared to answer are: Do you have any timeline required for completion? How many offices and data centers are in scope? Are you interested in physical penetration testing? Are you interested in social engineering? Do you have preferred testing time-periods/days? Are any systems delicate and/or out-of-scope?
  6. #5: Communicate To Your Teams Unless specific reasons exist, be

    sure to loop-in the following groups/people so that everyone important is on the same page: Team leads across your organization who will be directly impacted, including IT and security ops Any service providers who will be involved directly such as ISPs, data centers, or cloud providers Senior-level stakeholders to ensure that penetration testing will not interfere with any organization projects that fall along the same timeline
  7. #6: Don’t “Fix Stuff ” During Testing Ensure your developers

    and system administrators are aware of a “don’t touch things” policy during a penetration test (unless it actually breaks...) Changing web applications or systems during testing will lead to the penetration tester spending inordinate amounts of time trying to figure out why something that did work, no longer works This wastes their testing-time and your money Fixing issues during an assessment is tempting so that you don’t get blamed for a finding; this is myopic
  8. #7: Don’t Try to Hide Problems Penetration testing (and all

    other EH services) are meant to expose what you don’t want exposed Stakeholders should want to hear all results, no matter how meaningless to their individual concerns they may be; future auditing may require it! Ensure that you don’t make a large list (or any list, if at all possible) of systems or applications that are “out of scope” -- this doesn’t mesh with reality of attacks Your organization is paying good money to be told what needs help; use this for budgeting to fix issues
  9. #8: Trust But Verify All testing results should have proof

    of concept (PoC) examples and/or explicit details on the issue found There should be a narrative for all compromises: What systems were compromised and how What files were created during the compromise How did the process get from A to Z (details count) Screenshots for various vulnerabilities or compromises should be included by your consultant in the report ...but some issues just aren’t photogenic...
  10. #9: Challenge Your Consultant If you purchased a penetration test,

    don’t accept a vulnerability scan as a set of results Make the consultant explain what they did test and why they believe nothing was exploitable Your consultant should be able to make sensible recommendations for most identified issues, whether or not they directly led to a compromise If you’re unsure of why a finding was put on the report, make the consultant explain why they felt it was important to be added
  11. #10: Respect Our Ethical Duty “Can you please remove these

    [valid] results so we can show our (client|boss|agency|QSA)?” No “Would you alter the results so they are less scary?” No “If we fix these, can you delete them off the report?” No “Can you update the report to reflect a fixed issue?” Yes
  12. What Leads to a Compromise? Manual Testing 85% Automated Testing

    15% Skill 85% Luck 15% Here’s the truth... ...so make sure you hire a professional.
  13. Supporting Examples of Tips Don’t limit scope if at all

    possible Found web application via Google during testing SQL injection vulnerability found Created web-shell, allowed for code compilation Local kernel vulnerability exists, exploited for root Automated tools can’t do it all Found 0-day vulnerability on in-development blog Exploited issue for SQL access, stole password hashes Cracked password hashes, retrieved multiple accounts Logged into Intranet, full access to CEO e-mail
  14. Parting Thoughts... Assumption of security is a dangerous way to

    live Intelligent, well-seasoned developers and system administrators make mistakes, too Use assessment services to get what your team needs Show your organization the realities of not doing more (whether people or software) Having web applications tested thoroughly before they are put on the Internet is a great use of money Don’t wait until your company’s data is on Pastebin :)