Penetration tests are a critical part of running a secure organization. Understanding system weaknesses from both an internal and external point of view can save a lot of headaches, not to mention data theft, financial loss, legal nightmares, and brand damage. The benefits of internal penetration testers vs. external, third-party testers can be argued: Internal testers are full-time, permanent employees of the company whose job it is to perform simulated attacks against corporate systems and find the vulnerabilities.
These “red teams” understand the organization’s systems and the ins and outs of what’s likely to fail, they know the company culture and who and what can more easily be breached (e.g., “Sam never changes his password”), they (should) have a firm grasp of the most important and sensitive assets and where they reside in the network, and they have a clear view of the key players in the organization who might be the targets/victims of an attack (e.g., “CEO, Bob, does a lot of shopping on Amazon. I bet he’d open an email with ‘shipment delayed’ in the subject line.”). On the other hand, external pentesters are full-time consultants hired by organizations to test information systems. External, or third-party testers, are sometimes necessary due to compliance requirements, or in some cases, the organization doesn’t have the requisite skills on staff or just wants an external perspective. Third-party pentesters work with all kinds of systems and, because they aren’t as familiar with internal systems, can focus on common vulnerabilities that a more-familiar tester might overlook or take for granted. In addition, external testers have a greater “world view” of threats because they work with many different organizations in varying geographies, which gives them a broader perspective when trying to poke holes. Finally, third-party pentesters test all. day. long. As skilled as an internal tester may be, it is highly likely that s/he also has other responsibilities within the organization (let’s hope s/he isn’t dealing with breaches and attacks all day long).
In a perfect world, both internal and external testing would be conducted every year (at least). Whatever your organization chooses and can accommodate, Rob “Mubix” Fuller, Principal Security Engineer at R5 Industries, and Tom Eston, Manager of Penetration Testing at Veracode, provide some tips that will help you and your organization prepare for a smooth test that results in actionable outcomes.
Define Scope (with your testers’ help)
Every penetration test should begin with clear and specific goals. “Find the vulnerabilities,” is not very instructive and will mean either your test will require a tremendous amount of time and money or, more likely, some area of concern will be missed while the test is conducted within a given timeframe and budget because the tester is looking elsewhere. It is important, says Eston, to have defined goals “so the tester knows what to focus on and what is of most concern to the client.” Fuller adds that organizations should, “work with the tester to figure out what the targets and outcomes should be for the test,” and to “think outside of the box.” He advises that every test doesn’t need to be “cookie cutter.” For example, most companies’ security teams know that passwords are problematic. If your organization wants the tester to audit passwords, provide access to your domain controller and ask the tester to try to crack passwords. It’s highly likely that the tester will find a few “12345678”s or “Password1”s in use for admin accounts, but you won’t know that with 100% certainty until you test. Want your pentester to evaluate a new Web app just out of production? Make sure the tester knows about it specifically (and that it is up and running, says Eston).
Pentests can be customized, and it is probable that your tester will welcome a new skew and be appreciative of the direction you provide. By definition, pentesters like a challenge, so give them one to complete. For example, explains Fuller, “’Get domain admin’ is a common crutch when testers ask for goals.” Domain admin access generally means that the user, in this case, “attacker,” can do anything s/he wants in the network, but the real goal isn’t the access; it’s what can be done with the escalated privileges after they’re retrieved. A better goal, he continues, is ““Get domain admin access and then perform some increasing steps to see if our incident response team and admins notice the use of that access. Step 1) Gain some sort of domain admin persistence. Step 2) Create a new domain admin. Step 3) Change an existing domain admin’s password.” Specific goals set in the scoping process focus tester efforts and keep the exercise on track throughout the process.
Further, a great way to scope a test is to ask your executives and IT teams for their “worst case scenarios” and include their fears as part of the test. You will likely have to remove “some unrealistic stuff,” says Fuller, but these ideas will “not only provide value to the tester and give them better goals, but it gets your entire organization involved in thinking and speaking out loud about risks.” He cautions that executives can have an inordinate number of security fears (“ghost risks”), but that’s only because they don’t have a better source of information or baseline understanding of what can actually happen during an attack. As part of the scoping process, these conversations will prove beneficial to the tester as well as the team signing the checks and those who then have to affect change based on the results of the test. Setting good goals and defining desired outcomes is a huge part of the process and shouldn’t be rushed. The effort put into scoping will be paid in spades when you receive the tester’s final report
Treat your Testers as a Partner
Penetration testers, especially consultants, need to be treated as an extension of your staff. They are, after all, working on your behalf during the process, and their success depends on cooperation with the firm. Frequently testers and defenders feel they are in adversarial roles (the tester finds a vulnerability, the defender sees the resultant exploit and tries to block it, the tester tries to “break” something else…), but creating this type of culture is detrimental to the entire process, warns Fuller. The goal of a pentest isn’t to “win;” it’s to understand the organization’s weaknesses so they can be hardened. Eston illustrates, “I often see clients wanting to ‘catch’ us and prevent us from doing our job. I actually had one client try and ‘hack’ the pentester while we were onsite to see if they could exploit our systems and prevent us from doing our job.” This scenario benefits no one and creates escalating tension as the process evolves. Treating the pentester like a trusted partner who has the same goals will diminish adversarial tendencies on their part, and creating a culture of cooperation with incident response or defense teams will do so on theirs.
Of your pentesters, Fuller advises, “Kill them with love!” Because (external) testers have only a limited time to learn about your organization, “The more you tell your pentesters, the better they can help to find the holes. ‘Bad guys’ can spend months, years doing just that, so anything you can do to shorten that learning time, the more value you'll get from their test.” If you establish this trust and communication from the get-go, defenders and testers will spend less time fighting each other and more time focusing on improving security.
Request Permission from Third-Party Providers
Cloud storage, SaaS providers, and other hosting services are a fact of life for every organization. These services are extensions of your infrastructure and, whether the security team likes to admit it or not, they contain sensitive data which needs to be properly secured. Third parties absolutely have a responsibility for securing their systems and the data or applications contained within them (that’s a whole other post for another time), but if it belongs to you, it’s your responsibility. And the data, while it lives in another off-premise place, is your organization’s and you need to test whether it’s secure.
A good rule of thumb is to include provisions for pentesting in provider contracts. Even if this is the case and all of your legal “t”s have been crossed and your “i”s dotted, “request permission to test from third-party hosting providers before the pen test starts,” Eston urges. Providers like Rackspace, Amazon, Azure and other cloud services (especially the larger providers) have robust security controls and teams. If the provider sees what appears to be an attack against their systems—and a good pentest should be a simulated attack, not a watered-down version thereof—the tester may be blocked and the tester won’t be able to complete his test. Seeing the response from the provider would, in fact, provide a certain sense of security, but no defender is bulletproof and alerts are missed. Testing for “worst case scenarios” when the controls are outside of your domain is a recommended practice, but one that can only be accomplished if the provider is in-the-know.
Prepare Test Environments Properly
In the development life cycle, a quality assurance (QA) or quality control test is part of the pre-release process. These are done to catch errors before the application or piece of software goes live. It’s a good idea, says Eston to pentest Web apps in a pre-production environment. Sometimes a lot of coordination, like obtaining VPN credentials or setting up IP whitelisting, is required to access this environment. To properly prepare for a test of the pre-production environment, “make sure the tester can access this environment if the test is being completed remotely,” Eston advises. Most pre-production environments have a different set of access rights, and a remote tester might spend more time trying obtain credentials than actually testing the environment. Ensuring this coordination happens before the test begins will allow the pentester to hit the ground running rather than waiting around and taking focus off of project scope.
Closing out the idea of properly preparing test environments, ensure changes are not underway while the pentest is being conducted. For example, explains Eston, “it might not be a good idea to give the tester access to test the application in your QA environment while QA testing is taking place. This could impact QA activities as well as the activities of the tester,” neither of which result in a good outcome for the organization. To demonstrate, Eston shares a story: “One time I found cross-site scripting (XSS) in a QA/dev environment and the next day it wasn’t there because the developer was coding and fixing things without my knowledge. This caused frustration for the tester (me) and defeats the purpose of ‘point in time’ testing.”
Keep your Incident Response Plan Up-to-Snuff
“Wait! Above didn’t you say we should NOT counter the exploits of a pentest? You’re giving me contrary advice!” While on the surface a focus on the incident response (IR) plan during the pentest may seem contradictory, the pentest is actually the perfect time during which to understand what should happen “when the $tuff hits the fan,” says Fuller. A simulated attack provides an opportunity for the incident response team to determine what actions they will take when they find a hacker lurking in the system – Do you close down the test and fix the problem? Should everyone grab a snack and watch how the “attacker” navigates through the system? Also, explains Fuller, tying into the idea of killing your pentesters with kindness, working through your IR plan as the pentest evolves allows you to acquire feedback from the tester—the “attacker,” through his eyes—as to what he would do to block and respond to the attack. “Doing this is better than waiting another year (or until the next test) to figure out if what you put in place is effective,” he says.
As you prepare for the pentest to begin, make sure the IR plan is established and that it includes clear direction on different levels of reporting, communication, and signoff from executives and the legal team. Needless to say, the activities during and the results of the pentest should be revisited once the pentest has concluded so that any new issues which arise are addressed—in writing—for when or if a real attack hits.
Socialize the plan
The preceding five sections should make clear that communication is key – with testers, internal teams, executives, and anyone else who might be affected by the test. To put a fine point on it, though, a critical step in preparing for a pentest is letting teams know it’s coming. Security experts may disagree on whether or not it’s wise to let employees know when the test is coming, but informing teams, especially IT, IR, and security teams, that “a pentest is coming, and it in no way affects—positively or negatively—on their salary, review, or any other aspect of their performance,” is highly recommended by Fuller. He, personally, is of the mindset that teams should know when the test is going to happen: “Sure, they are going to look extra hard, even if you tell them it won't affect them. As a result, they will take away any new processes that their motivation creates, and they can capture that into something repeatable after the test is over.” A pentest, after all, is designed to help your organization prepare for the future, and if they revive the extra benefit of planning their counteractions, this is a win-win for all involved.
Conclusion
Penetration tests are extremely useful exercises for uncovering vulnerabilities contained in corporate systems. While no organization can ever be 100% secure—attackers are extremely patient and persistent when a target is sufficiently attractive—penetration tests will help highlight the areas on which security, architecture, and IT teams can focus to lessen the possibility of exploit. Following the recommended steps provided by Fuller and Eston, organizations will be significantly more successful and able to affect action as soon as the pentest wheels are set in motion.
