Original Post Author: Don C. Weber [Twitter: @cutaway]
Original Date Published: 28 March 2013

John Sawyer pointed me to a blog post Getting the most out of your pentesting by Wendy Nather of 451 Security. I would like to provide a little bit more context in the hopes that it will help CIO’s, managers, administrators, and up-and-coming security professionals.

I think it is safe to say that no organization has an infinite security budget. In fact, most organizations have a finite security budget that varies according to business requirements and needs. An exception may be large companies that can afford to maintain a consistent and well-funded security team while smaller organizations are forced to make trade-offs. Too often, they require their already overloaded Information Technology (IT) staff to pull double duty without fully considering the risks of trading off security considerations for business needs when deciding when and where to spend critical funds. One of the first areas to get cut is validation of existing security controls through penetration testing.

Normal security controls, such as automated network and vulnerability scanning, can identify issues and help ensure that resources maintain a specific baseline implementation. However, penetration testing is a critical part to implementing a complete security framework and is intended to look beyond the limited detail provided by those controls. Penetration testing helps identify implementation issues that a human attacker may target to compromise an environment, establish a persistent foothold, and propagate to other resources to steal data. Penetration tests can also be used to validate the configuration of security controls and the organization’s incident response policies and procedures by generating the anomalous activity associated with reconnaissance, propagation, persistence, and (if a client approves and requests) data exfiltration.

For a comprehensive and effective penetration test, your organization should identify and retain an experienced, clever, and creative penetration testing team. Costs will vary associated with level-of-effort and experience, because companies providing penetration testing services are businesses just like any other. They will have information about the levels-of-effort required for a wide range of testing scenarios and are aware that funds are always limited and precious to their clients. Thus, penetration testing organizations will be willing to negotiate and come to a recommended testing scenario that meets the budget of the client and addresses their own costs for maintaining the appropriate IT staff and tools to accomplish these efforts. The penetration testing company will also help an organization prioritize tests, increasing the potential that the most effective tests are performed first, thereby reducing costs over the long run.

Of course, no matter which penetration testing team an organization chooses, the testing team will also work within a limited period of engagement. This is contrary to an attackers’ limitless allotment of time. Therefore your organization will want to make the most of the time spent working with a penetration testing team. Here are some recommendations:

  • All penetration tests should begin with a kickoff meeting. The penetration team should express their intended initial steps to the client’s team. The client’s team should be prepared to identify critical and sensitive resources so the penetration team knows where to tread lightly or avoid altogether.
  • Most penetration teams are going to ask the client about their greatest fear. If they don’t, clients should specify situations and resources that concern them the most. This shouldn’t be done to “limit” the penetration test unnecessarily. It should merely be used to help direct the effort and reduce the amount of time it may take to locate and focus on these systems and data.
  • The client should determine if they want their security team to actively monitor the penetration team’s activities or if they want them to discover the activity and follow their incident response processes. Either will work and the selection will mainly be determined by the amount of time the client’s team can devote to the efforts. Organizations that can afford it should alternate between these two scenarios.
  • Security and IT managers should be ready to step in when necessary. Limiting how many people know about a penetration test is sometimes difficult. However, escalation and knowledge of an attack can spread quickly within an organization and take on a (potentially unintended) life of its own.
  • Be prepared to prioritize and follow-up on critical issues. Many issues will not be known until the penetration testing team has generated its final report. However, some penetration tests discover previous malicious compromises or the exposure of sensitive resources or data. Depending on the situation a security team may have to quickly devote resources to address specific issues. Managers should be prepared.

One other management decision that should be made when preparing for a penetration test is to determine the total amount of information to provide to the penetration team before or at the beginning of the testing. Most penetration testing teams are going to perform external reconnaissance via the Internet before initiating an engagement with a client. It is one of the methods used to increase the effectiveness of a test with limited assessment time periods. But, unless they are supplied with additional data, they will basically be starting without any details about the network infrastructure, operational implementation, and data storage. Penetration teams refer to the amount of information they are provided using a colored box method:

  • Black Box Testing: no information outside of specific target identification is provided. Everything must be discovered by the penetration testing team.
  • Gray Box Testing: a limited amount of information about the organization, in addition to specific target identification, is provided. Network configuration, operational flow, and the location of sensitive information is either provided verbally or via specifically prepared documents. This is often augmented by one or more representatives that are available to answer questions and provide or withhold information, as they deem necessary for the engagement.
  • Crystal Box Testing: the team is provided all the information they request before and during testing. They are provided a liaison to help provide additional information about the environment as the team’s actions move them through the clients resources.

Each of these different testing methods has its weaknesses and advantages. For Black Box testing, the weaknesses are that many vulnerabilities (potentially critical) may be missed. However, when the penetration testers do compromise something, there is no denying the fact that malicious attackers could have accomplished the same thing. Gray Box testing reduces both of these cases. A few vulnerabilities may still be missed during the assessment. Additionally, some people and managers will argue that the reason the testing was successful is directly associated with the inside knowledge provided to the testing team and that attackers would not have been able to accomplish the same thing. White Box testing is performed with the expectation that most of the critical vulnerabilities will be identified during the assessment. However, some people will argue that the penetration team was basically operating as an administrator within the environment since they had access to the resources or data and certain findings are not vulnerabilities.

To conclude, Wendy stated, “If you’re serious about security, you can’t assume any part of your infrastructure is ‘safe’ or ‘out of scope.’ Because to the attacker, it isn’t.” She is absolutely correct. Attackers are never limited by where they go within an organization and what they are permitted to do. Penetration testers will ALWAYS be limited, and rightfully so. However, an organization can use this to their advantage. If you have a list of resources, services, or data that is off limits, you really need to identify “why.” If you can fix that limitation then you very well may have addressed a critical security situation. Critical resources should be robust and resistant to failure and attack.

I hope this helps.

Go forth and do good things.