Embed Size (px)
DESCRIPTION
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.
Citation preview
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
#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
#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
#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)
#4: Be Prepared For QuestionsSuccessful 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?
#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
#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
#7: Don’t Try to Hide ProblemsPenetration 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
#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...
#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
#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
What Leads to a Compromise?
Manual Testing85%
Automated Testing15%
Skill85%
Luck15%
Here’s the truth...
...so make sure you hire a professional.
Supporting Examples of Tips
Don’t limit scope if at all possibleFound web application via Google during testing
SQL injection vulnerability foundCreated web-shell, allowed for code compilation
Local kernel vulnerability exists, exploited for root
Automated tools can’t do it allFound 0-day vulnerability on in-development blog
Exploited issue for SQL access, stole password hashesCracked password hashes, retrieved multiple accounts
Logged into Intranet, full access to CEO e-mail
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 :)
