There are plenty of proposal templates out there for information security, the purpose of this document is to draw your attention to some industry-specific issues that you might face during the process of your first engagement with a security vendor.
Even for a small amount of work, it’s a good idea to at least informally identify in writing your organization’s requirements and the reason you’re deciding to have some form of information security testing done.
Often simply letting the vendor know the driver for the assessment is the most important piece of information they need in order to respond appropriately.
Is the driver simply due diligence, or a management/operational issue that can’t be fixed internally? This information is key in making sure you actually get what you want out of your vendor.
Often, clients come to us and ask for a penetration test, but when we inquire, what they really want is an audit of various aspects of their infrastructure. Had we simply taken their request at face value, we may not have fulfilled their needs. Not to mention the costs they incur would have been greater, so it definitely doesn’t hurt to ask.
It’s usually in the vendor’s financial best interest to set the scope of an information security assessment as broadly as possible. But there are other very valid and well meaning explanations for a large scope.
Threat actors don’t have scopes.
Sure, consider breaking your project into phases, that way, if you’re not happy with the vendor, you can switch without loosing too much skin but it’s really important that when it comes to information security, those who would do you harm aren’t going to restrict themselves to a certain subdomain, application or IP range. A good vendor that you establish a relationship with and feel comfortable with is going to tell you the best place to start if you’re aren’t sure. At the end of the day, thinking like an attacker is what we are here for!
Once you’ve determined the scope, your budget and the deliverables you’re looking for, the next step is picking a penetration testing company.
When choosing a penetration testing provider, there are broad range of reasonably industry-specific steps you should take that don’t really occur in other ICT tenders and also in the broader market.
In the case of penetration testing, you’re basically looking for some demonstration that the company, and in particular the individual consultants have demonstrable skill and experience with a large variety of businesses, environments, applications and infrastructures. In particular, yours, of course!
When it comes to skill, just about every penetration test is different, so you need to make sure the consultants assigned to your project have a demonstrable background in your environment.
Context in information security is key, exploit-chains, and your specific industry, along with your environment (e.g are you predominantly Oracle or MSSQL?) mean that it’s really important your tester is switched on and ‘gets it’.
Penetration testing is almost company-specific in methodology
Unfortunately for companies that require penetration testing, there isn’t a specific framework for penetration testing that we have to follow, there are many good frameworks and most companies use a hybrid of these. It’s quite unusual for a company to rely solely on one standard. This is often due to individual styles and ideological positions about what attackers look like and how they operate. It’s important that the company outlines, and the consultant can demonstrate, a thorough understanding of the methodology in play, and why. – Otherwise it’s all just spin!
Since you’re looking for penetration testing, (which is not an audit, strictly speaking) you need to make sure the consultant understands and demonstrates an ability to match real world threats faced by your organisation, and that it mimics closely what is known about how malicious threat-actors operate. An extreme example of this would be, if the consultant is recommending you do ‘xyz thing, because the NSA might read your emails’ and you sell shoes, he might not be developing remediation advice that reflects your business interests.
There are many stories of companies sending in a high quality consultant or salesperson to work through the proposal and scoping phases then switching out to a rookie. Ask for the CV’s of the people conducting the work, and ensure they have experience with businesses similar to yours.
At the end of the day, information security companies, no matter their reputation or size, rely on the strength of their testers in order to deliver.
‘If it isn’t written down, it didn’t happen’ should be the mantra of all information security consultants.
Report writing, as anybody can testify is rather boring, but it’s really what you’re paying for. So it must be done to a high standard that reflects your requirements.
Your company requires an executive and a technical report. These can be inside the same document.
Your management wants to see the executive summary that clearly defines risk areas and any process-driven requirements or regulations they need to bring their attention to.
Your technical team needs to see a report which has detailed information on the vulnerabilities and exploits for replication and remediation. It’s also important that there is enough background information for developers to get themselves across new issues that they might not be aware of in order to save time.
The penetration test report should demonstrate a significant amount of post exploitation, which is, the efficacy and impact of a vulnerability. Findings and remediation should also include internal weaknesses that were discovered as the consultant elevates and pivots his access and privileges. Without this, it is hardly a penetration test at all.
One would also worry about a penetration test that stops after the first successful exploit…