Developing Scenarios for More Effective Penetration Testing
As someone who scopes out and performs penetration tests for a living, I always begin by asking clients: “What should we be trying to accomplish during this test?” All too often, I’m given a very short list of IP addresses and the answer is something along the lines of: “Just tell us if you can get into this network.” This is a very short-sighted approach for a something as powerful as a penetration test because the reality is that a skilled penetration tester will almost always be able to find some way into a network, so the fact that he or she can do so doesn’t give us much useful information.
Ideally a penetration test should simulate a real world attack; in the real world, the attacker will always have some objective beyond “get into the network.” They may be trying to steal credit card numbers that they can use for fraud, a password to wire money out of their target’s bank account, or valuable data they can encrypt and hold for ransom. Perhaps they’re not interested in financial gain but instead are a state-sponsored attacker more interested in eavesdropping on their target’s users, or hacktivists whose goal is to damage their target by leaking embarrassing emails and knocking systems offline.
The point is, no matter who the attacker is, they are motivated by something that they are trying to accomplish – and getting into the network is only one step in that process for the attacker. For a penetration test to have real value, the testers should be trying to accomplish the same objective that the real attackers would. The success or failure of the test team to accomplish this objective will tell you not only whether or not the network can be breached, but also how effectively internal controls will slow an attacker down once they are inside the network.
Focusing narrowly on attackers breaching a network’s perimeter also results in a test with huge blind spots in that it ignores the reality of vulnerabilities that would allow an attacker to accomplish their objective and cause damage to their target without the network itself being breached at all. One of the most common vulnerabilities of this type that we see in the wild is a SQL injection attack, which allows an attacker to directly retrieve data from a backend database by interacting with public-facing Web applications. We also regularly find source code, passwords and other data that should probably be kept confidential posted publicly on sites like GitHub. Whether an attacker’s goal is to steal customer data or retrieve source code, they will use the path of least resistance. For that reason, limiting the penetration testers to focusing on vulnerabilities in the network perimeter will only lead to an inflated false sense of security.
All that said, it is still the reality that many attacks do involve breaching a network and many of those initial breaches occur somewhere other than where sensitive data is kept. This might include breaches of third parties that share backend network connections, employees’ mobile devices, or poorly protected legacy systems. Many organizations don’t have adequate security controls within their network to stop an attacker who has gained a foothold inside the perimeter so it will only be a matter of time before that attacker’s ultimate objective is accomplished. For this reason penetration tests shouldn’t be limited to the IP addresses of your sensitive servers or known public websites. Instead they should include every address you have from your main data center down to tiny remote branch offices, and all of those cloud services that you signed up for too.
The next time your organization is due to have a penetration test conducted, spend some time thinking about what you have that might be worth something to someone else and the scenarios that would cause severe damage to your business. These might include the disclosure of confidential information, someone altering sensitive data, having critical resources taken offline, or all of the above. Tell your testers which risks keep you up worrying at night so they can play those scenarios out during your test and confirm whether or not you’re worried about the right things. Their goal should be to do things like steal your customer data, read your emails, or alter your website by any means they can find, whether it’s a direct attack or a more creative approach. After all, your outcome will be much better if your friendly neighborhood penetration tester figures out a novel way to empty out your bank account than if it’s done by an actual organized crime group.