Effective Security Testing
Selecting a partner for penetration testing, assessments, or audits, defining, and initiating a test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Related Stories: Cybersecurity for Executives | Penetration Testing
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my last post on testing cybersecurity, which is part of my series of posts on Cybersecurity for Executives, I explained different types of security testing you can use to evaluate the effectiveness of your security controls. The first step to maximizing the results of your penetration test, assessment, or audit is to understand your test objectives. From there, define your scope, methods of testing, and choose a qualified partner or internal team to perform the test.
Types of pentesting
Many different types of penetration testing exist. When you want to do a pentest, the first thing you need to do is specify what type of penetration tests you want.
Social Engineering: One of my favorite examples of social engineering is demonstrated in this talk, The Spies Among Us, by my friend Ira Winkler when he used social engineering to steal plans of a nuclear reactor. Watch the video of his presentation, and you understand just how vulnerable humans are in the realm of security processes and procedures. Edward Snowden purportedly used social engineering tactics to borrow credentials used to steal national secrets according to a statement I heard by someone who worked at the NSA.
Physical Penetration Testing: This type of physical testing involves trying to break into buildings and facilities in person. Testing could involve bypassing security controls like walls, locks, cameras, and alarms. Here’s a video from someone I know (who is a talented karaoke singer as well, by the way) named Deviant Ollam called I’ll Let Myself in: Tactics of Physical Pentesters. (Warning: Strong language for those that don’t like that sort of thing, but for those making related security decisions — you want to know about these vulnerabilities!)
Network and Wireless Penetration Testing: Network penetration testing may involve things like using network scanning tools and testing network equipment. For example, a network penetration tester may try to alter network packets or leverage flaws in trunking protocols. Some types of wireless penetration testing require specialized equipment to intercept Bluetooth, Zigbee, and other wireless protocols used by car and door locks, sensors, IOT, and other devices.
Application Penetration Testing: Application penetration testing may involve testing web and compiled applications installed on computers, virtual machines, IOT, mobile devices, and other specialized equipment or vehicles for security flaws. Advanced penetration testers may leverage fuzzing, logic evaluation, and reverse-engineering skills in addition to things like scanning for CVEs and OWASP Top 10 security flaws on web applications.
Cloud Penetration Testing: Cloud penetration testing involves testing cloud-specific security controls and seeking architecture flaws that an attacker could exploit, generally in combination with web application penetration testing. Cloud penetration testing can help determine if your company is vulnerable to misconfigurations, such as those that caused the Capital One cloud breach. Those performing cloud pentests need to be continuously validating that they are only attacking the systems of their client, due to the changing nature of cloud resources.
Regardless of the terminology or category you use to define your penetration test, make sure that your most critical systems are tested for security flaws if you are trying to improve security. If you are only trying to maintain compliance, the test might involve a different set of systems and types of attacks to meet whatever the compliance standard requires. Also, make sure the person performing the test has the capabilities you require to perform an effective test.
Evaluating the evaluator
Pentesters and those performing security assessments use many different tools to perform evaluations. The tools vary depending on the type of test. Penetration testers and assessors that only know how to use automated tools and provide the reports generated by those tools have limited capacity to test systems thoroughly. Testers who have more system experience — often coming from an IT or software development background or who have been pentesting for many years and do security research — have knowledge to perform more in-depth system analysis. Some companies and pentesters specialize in researching new exploits and providing tools, blog posts, podcasts, and training to share what they have learned with others. I try to do that on this blog. Black Hills Infosec and SheHacksPurple are two other great resources.
When a particular penetration testing tool fails, the penetration tester needs to figure out how to solve the problem. For example, a lot of web sites are using technologies that aren’t captured in the typical manner by a commonly used web application penetration testing tool called Burp Suite. When I noticed that happening, I needed to come up with another way to capture all the links in a web site I wanted to test. While writing my cloud security class labs, a particular Metasploit module worked, and then failed when I got to class. Metasploit is another tool that has been around for a while and has a lot of pentesting functionality. I eventually pulled the Metasploit module out of the lab and used code and knowledge of how the underlying exploit works to demonstrate what I wanted to show my students.
Tools are incredibly helpful, and in both these cases I expect that updates are coming to resolve the issues I just mentioned. However, this is what experienced pentesters and those with software, IT, and advanced pentesting backgrounds can do — they realize when something is not working and come up with a new solution. If you are in the middle of a penetration test (or a class!) you might not have time to submit a bug report and wait for a resolution.
Penetration testers also need to be able to evaluate new technologies — as I’ll be discussing in my presentation at AWS re:Invent. Everything in the cloud is changing all the time and those testing the security of the cloud need to understand both the platform and be able to evaluate new features as services as they are released. The tools will likely not keep up with the changes in the cloud fast enough. Each customer application must be evaluated based on the particular tools and services it uses.
Are certifications necessary? Certifications are certainly not a requirement, nor do they guarantee the person doing the work is highly skilled. In some cases, people cheat or are good at taking tests, but not good at doing the work outside of the testing environment. Sometimes tests are no longer aligned with top vulnerabilities and modern mechanisms for attacking and securing systems. Some people are too busy to find the time to take tests as they already have produced enough visible work to obtain industry acknowledgment of their skills and do not need a certification to prove their knowledge.
However, it is fair to say that for a company that does not have the capability themselves to evaluate a penetration tester, auditor, or assessor, that a certification is better than nothing when trying to determine if someone has the appropriate skills. A certification shows that someone put in the time and effort and was able to pass a test that indicates they know the subject at hand. PCI version 3.2.1 compliance security controls and processes 11.3 requires an annual penetration test. The PCI Security Standards Council offers a document called Penetration Testing Guidance, which offers some recommended certifications for penetration testers, of which your author has three. I also wonder why the GSE is not on this list, which is one of the hardest certifications to obtain in cybersecurity.
Mutual NDA
Initially, a security evaluator and client may exchange a mutual NDA (non-disclosure agreement). Both the client and the penetration tester share confidential information throughout the test. The penetration tester has a particular report format, tools, and proprietary techniques. The customer does not want their system information or penetration test results exposed. The overall contractual agreements may also include confidentiality clauses.
Contracts
Before starting an engagement with an external company, both parties should sign a contract. With internal and external pen testers, each side needs to understand how pentests work, the scope, and possible outcomes. For example, allowing the tester to perform a broad array of tests provides more system coverage to find as many security problems as possible. This also could potentially lead to system downtime because security testing involves sending malicious inputs to systems. If your developers have not adequately accounted for those inputs, systems might go offline.
One of the things customers should check for in a security testing agreement that includes scanning or exploits is the appropriate level of insurance and care taken in the testing process. The contract should define the scope, process, and the type of methods of testing.
Scope
With any of these types of tests or evaluations of your cybersecurity the first step is to determine the scope. Document which systems are to be analyzed, and which systems are off-limits. Sometimes companies limit scope because they want to test for a specific scenario. In other cases, the scope is limited due to the budget. Sometimes an organization limits the scope to the systems required to be included by a particular compliance framework to focus on getting the compliance. Any findings reported may need to be mitigated, which costs time and money. Unfortunately, some companies focus on this extensively, rather than security their systems as a whole.
Pentesters and anyone performing system scans needs to be careful to only test what is in scope and allowed by any third parties involved. Third-party systems are off-limits unless the company requesting the test got permission in writing from the other party. If one system integrates with another system, and the tester has no permission to evaluate that integration point and the third-party system, the test did not evaluate the overall security of the system. A vulnerability may exist at that integration point between the two systems, which the penetration tester is not able to expose.
Permission
Any penetration tests, assessments, audits, access to systems, scans, and other types of testing require permission. As just explained, penetration tests may not only include programmatic access to systems but also logging in and performing tests, trying to break into buildings or facilities, or using social engineering to trick people into giving out information. Assessments may involve automated vulnerability scanning. Audits may involve access to sensitive data. Bug bounties specify rules for participation. All these activities require the appropriate permission. Penetration testing is the riskiest for a consultant because these activities are criminal offenses if performed without permission.
Some companies, such as cloud providers, allow penetration testing of systems hosted on their platforms without specific prior approval. However, certain features and functions of the cloud platform are off-limits to penetration testers. Anyone working in a cloud environment needs to understand what they can test and what is off-limits. Cloud penetration testing still requires permission! You need permission from the organization that owns the systems deployed on the cloud platform.
Internal and external testers should obtain permission in writing from someone at the C-Level (CEO, CISO, CIO, CTO, or other top executives with a title that starts with C and who meets with the CEO regularly) for penetration testing and any sort of automated scanning. Additionally, verify that the person providing permission to test has appropriate authorization for the systems that testers are evaluating. You need the appropriate permission in writing, and legal authorization to perform the testing in case law enforcement shows up, or something or systems go down as a result of testing (which can and does happen sometimes!)
A recent case clearly demonstrates something that can go wrong on a penetration test. A pair or physical penetration testers broke into a courthouse in Iowa. They had the appropriate documentation (or at least documentation that had worked countless times before). They broke into a building that the person authorizing the test may not have legally had permission to give them. The other problem may have been due to political rivalry within the Iowa government and judges that were unfamiliar with how penetration testing works.
Initially, the penetration testers landed in jail. Later some of the charges were reduced or dropped, but not completely. Once a penetration tester has a criminal record, it may be hard for them to find jobs or continue in their line of work. That’s why it’s always crucial to obtain appropriate permission and make sure the scope and methods of testing are clearly defined. This case is still on-going at the time of this writing. The company that employed the two penetration testers is working to have their names cleared of any civil or criminal charges. You can read more about it in the following articles:
Check the scope: Pen-testers nabbed, jailed in Iowa courthouse break-in attempt
Iowa paid a security firm to break into a courthouse, then arrested employees when they succeeded
Process
The process (sometimes called rules of engagement) by which a test is carried out is related to scope. The client and the penetration tester, assessor, or auditor should be agreed upon in advance, in writing. For example, consider people, process, and timelines.
Who? is the point of contact if something goes wrong, on both the customer and the assessor side? Who is allowed to change the scope during the test? Who is included in meetings, discussions, and receives a copy of the report?When? What is the length of time for the test? What days and times will the test take place? When will status reports be delivered? If a test is three weeks, and the start date slips, the timeframe for the test is still three weeks - from the start date.What? What testers are to evaluate was covered in the prior section about scope. Which systems and domain names are in scope for the test? What systems are off-limits?How? Will the tester or auditor provide on-going status reports, and in what format? What should the penetration tester do if he or she discovers sensitive data? Is exfiltration allowed or not?Any relevant information and expectations as to how the test will be carried out should be discussed in advance and agreed upon in writing.
Insurance
If you’re hiring a penetration tester to attack your systems, you’ll want to make sure they have an appropriate level of insurance. How much is enough? That depends on your business. How much insurance do you require other vendors to have who perform risky activities? How much would your business lose if systems go down due to negligence by the penetration tester? How long can you afford to be down? Note that systems may go down during a test. Insurance generally pays in the case of negligence on the part of the pentester. Negligence involves not taking proper care while testing. If you agree to a pentest and a person attacking your systems and an attack brings the system down due to poor programming by your developers, that is probably not negligence. If the tester performs a DDOS attack on your systems which was not allowed in the scope, that is another story. Include your insurance requirements in your contract and ask your penetration tester for a certificate of insurance to prove they have it. I am not a lawyer so please consult a legal professional for all of the aforementioned issues. Pentesters should have a good lawyer too!
Credentials
If you need to provide credentials to a tester, do it in a secure and properly encrypted manner. The pentester should be able to provide instructions. SSL or TLS for encryption in transit is not enough, as I explained in prior blog posts on encryption. Use GPG or some other security mechanism. Only give the permissions required for the test, not full root credentials to administrative systems.
Why would you need to provide credentials? When you perform a test or validate the security of systems, it’s a good idea to “assume breach” and see what data an attacker can access if they obtain credentials. Stealing credentials is the number one forms of compromise of systems according to some reports. Should it happen, you want to limit the damage by ensuring you are using zero-trust security practices.
With credentials, a security tester can perform a more comprehensive scan of systems not accessible without them, to find internal vulnerabilities. Also, when performing a web application test, providing credentials for multiple accounts allows a penetration tester to test for logic flaws in your application. Can one customer account access another account? Can an account escalate privileges and perform actions that typically require more permissions? Once a person has a login to a system, can they access functions with security flaws not exposed externally? An internal web application vulnerability was the cause, in part, of the Target Breach and eventually led to the exfiltration of credit card data.
Testing
Now the testing begins. Some companies want stealthy testing to see if their internal teams can spot it. Other companies want coverage — in which case fuzzing, a more noisy form of testing, can test possible inputs faster and more in-depth. It all depends on what you are trying to test. During the testing phase, you want to watch your logs for anything unexpected and have your penetration tester’s name, number, and email handy in case of any issues. Your tester should be providing reports as specified, or at the end, if that’s all you need.
Make sure your staff is not intentionally doing things that block the tester from finding vulnerabilities in ways that they do not normally operate. This incomplete testing can give you a false sense of security that doesn’t accurately report what attackers can do to your systems. If you want full coverage via fuzzing and other automated techniques to find vulnerabilities, which can be highly effective, make sure you turn off tools that restrict the tests via rate limiting and other auto-blocking techniques. Only turn off rate-limiting for the IP range specified by the tester. If possible, perform these types of tests on non-production systems.
Know your objectives
Different penetration testing companies may operate in different ways and offer different types of services. The main thing you want to do is make sure that your contracts and scope definition focuses on your target objectives. Hopefully, that objective is preventing data breaches by finding security gaps and fixing them — which is the subject of my next blog post.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2019
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
