Penetration testing, or “pentesting,” has become a popular approach for validating a company’s security infrastructure. This is because when you hire a pentest company to try to "break the lock" on your network and the attempt fails, you can say with some certainty that your data and IT assets are safe and secure from those malicious hackers out there on the internet.
But while there’s value in having your network security validated by an external company offering pentesting services, there are also some dangers. For as much as nature abhors a vacuum, the commercial world abhors a market opportunity that’s not being sufficiently taken advantage of. As a result, there are a plethora of so-called pentesting companies around these days with more and more of them being birthed almost weekly. And like any new market that appears, this one too is very likely composed of a combination of vendors having integrity and the usual fly-by-nighters that buzz around the moneyed carcasses of capitalism.
But let’s forget all the metaphors and focus on what really counts in any vendor/customer relationship: the contract that establishes a legal relationship between two parties.
Not too long ago a colleague who manages IT for a smaller Internet services provider (ISP) in the United States found himself approached by a company that offered to perform some pentesting. We’ll call the anonymous pentesting company “X” and my colleague’s company “Y” for lack of something better. Anyway, X told Y they could do all sorts of useful stuff like discovery scans, vulnerability scans, fake DDoS attacks using simulated botnets, fake phishing attacks using carefully crafted emails, and so on. They could test the integrity of Y’s perimeter network, and if granted limited access permissions they could perform an internal test to see whether employees might be able to sabotage or compromise internal systems. They could try to compromise SQL databases, business applications, and even network hardware devices like routers and WiFi access points. They claimed that they would be extremely careful in all their pentesting operations to ensure their actions didn’t cause any data loss or corruption, any damage to hardware and software, or any interruption to their business operations. They promised also to hold any confidential data accessed as a result of their pentesting efforts in the highest degree of confidentiality. In other words, X basically told Y not to worry.
What do you do when in this kind of situation? Well, obviously you check their references to see whether they’re really who they say they are and what their track record looks like in the security industry. And you obviously only take them up on their offer if you feel your company or organization actually has a need for and can afford such pentesting efforts.
Then you closely scrutinize the contract they offer together with someone from your company’s legal department. And in this case, it’s what Y found that X had *not* included in their contract that worried Y about whether they should accept X’s offer to pentest them.
First, since X is an ISP they were hugely concerned whether any attempts at pentesting their operations from the outside using phishing emails and other kinds of network traffic might possibly end up putting X on some blacklists against spam or black hole routing issues. To avoid this kind of thing from happening, X insisted that the contract with Y clearly specify what kinds of network traffic will be used in their pentesting efforts, where the traffic will be originating from, which specific network addresses such traffic will be sent to on Y’s network, and what the time window was for pentesting operations (when they start and when they end). Y also insisted that X spell out clearly what immediate actions they would take should their pentesting inadvertently cause Y’s network or domain to be blacklisted and how any related abuse notifications will be handled.
Y also insisted that X provide them with documentation afterward that contained detailed information about all of the traffic generated and used for X’s pentesting actions against Y’s network. The reason for asking for this is so that Y would be able to trace back any unexpected or undesirable effects on their network to see whether X’s pentesting had caused these effects.
Y also asked for a list of the IP address space that X was going to use for launching their pentesting efforts. This was requested so that Y could investigate whether any other companies or organizations had in any way previously experienced network problems associated with these addresses. This is actually pretty smart on Y’s part because pentesting is inherently a potentially destructive process even when conducted with the utmost care. I’m told by my colleague, who is pretty savvy in this security area, that there have been reports in the past of pentesting vendors who have had to change the IP address space they use for launching pentesting because of the vendor’s addresses getting blacklisted on large portions of the Internet. So the number of times a pentesting vendor has done something like this in the past may be a good indicator of how inexperienced they might be in the pentesting field. On the other hand, a legitimate pentesting vendor who has a good track record may still be using the same IP address range allocated to them when they launched their company.
Penetration testing, or “ethical hacking” as many vendors like to call it these days, is still hacking unless you have contractually agreed to it. While there may be some hazards associated with allowing another company to knock on your front door and try to pick your lock, it’s still probably a good idea for most businesses and organizations to hire the services of a reputable pentesting vendor from time to time. The most obvious reason for doing this is because technology continues to become more and more complex, and this means it’s beyond the ability of most IT departments and sysadmins to know every possible vulnerability or threat vector their network assets and data may be facing. Like most situations where you want to be more sure about something, you call in an expert.
Just be sure to call in your lawyer as well.
Featured image: Shutterstock
Here’s how to manage firewall and virtual networks in a Storage Account and how to use Azure Automation to enforce…
Microsoft exposed roughly 250 million customer service and support records last month. While the company says it secured all servers,…
If you store business data in the AWS cloud, you need to secure it against unauthorized access. A breach and…
The shift to REST APIs has an unintended consequence for DevOps: new attack vectors. A security expert walks us through…
Companies are adopting the concept of silent meetings as a way to make business meetings more productive. Does this work?