Penetration tests (pen tests) are useful tools for your organisation. They can show you comply with regulation or organisational requirements and give your clients confidence in the services you provide. This is particularly important as cloud service adoption grows: if your solution isn't demonstrably secure (at least at that point in time) your customers will go elsewhere.
Scope out the job
The first thing to do is determine what assets you want the penetration testers to focus on. This does not mean hiding all the problems you know about (if you know about them, fix them)! Some older or specialised systems do not react well to penetration tests, potentially corrupting data or becoming unavailable. If this is the case, and you can't resolve the stability issues, then it's wise to discuss with your tester - there may be other tests they can perform that are less likely to cause an outage.
But how do I know what I've got?!
You can't include something in the scope if it you don't know it's there, so if you don't already have a good idea of the assets you have you'll definitely need to run some scans. This could be as simple as using something like
nmap (https://nmap.org/) to perform a TCP SYN scan to find services running on your network (replace the IP addresses with your own):
nmap -T4 -A -v -Pn 192.168.10.0/24
This will give you a list of devices on your network and the services that responded to the scan. It'll also attempt to give you further information about the operating system and configuration of the devices. The
-Pn is there because if Nmap doesn't receive a ping response then it'll stop scanning an asset, so we override this behaviour by telling it not to ping at all.
Practising asset management is important, regardless of whether you've got a pen test coming up. I recommend a tool like LANSweeper or SpiceWorks as low cost (free in SpiceWorks' case) solutions to this problem. They take a small amount of configuration but afterwards will automatically scan your network and provide information on software installations, configuration and devices.
Don't assume you know what's on your network - I've found aged switches and PCs everyone thought were gone through relatively quick scans. In most cases I've been able to remove them straight away too! Experience has shown if you assume you know everything on your LAN, the testers will find something you weren't expecting.
That old system in the corner
I reckon every organisation has at least one "old system in the corner", that computer, server or equipment that's been there forever but perhaps isn't needed any more. Maybe the system administrator for it has long since left the organisation, the credentials have been forgotten and the system likely hasn't seen an update in years. It's the system you're scared to turn off as no-one really knows what will happen.
Now's a good time!
Start by identifying any documentation on that system (if there is any). Check your logs, firewall logs too, to see if anything's accessed it. Talk to people that have been there longer than you, even if they're now in a different team. When you realise no-one can tell you why the system should still be there it's time to arrange a brief outage (unplug the network cable, don't turn it off). That's something to agree with your manager, as you don't want to be a maverick.
Assuming nothing bad happens, leave it off the network for longer. Eventually you can be fairly sure the system isn't needed anymore and can arrange its secure disposal - one less bad thing for a tester to find.
Patch everything! That's Windows Updates, Adobe Reader, Adobe Flash, Java, Apache - if you've got it installed check for an update. When it comes to Adobe Reader and Flash it may be that you don't need them anymore anyway, and Flash will be unsupported from 2020. The number of sites using Flash has dropped dramatically in recent years and I can't think of the last time I needed it enabled. For PDF reading, if that's all you need to do, Firefox and Google Chrome both have capable PDF viewers built in. As a result of these two factors alone, my devices haven't had Flash or Adobe Reader installed for quite some time.
A good patching solution is hard to come by without spending a lot of money, but for an oraganisation a good start would be to ensure you've got Windows Server Update Services installed to keep your Windows devices up to date.
Don't forget, if you're patching a production server it's always wise to perform the patches in a test environment first.
I've done talks in the past on vulnerability management and it's certainly something that's worth building in to your organisation's processes. Through this process you're looking to identify vulnerabilities on your network (or in your code) and to apply patches. The good news is that quite often the pentesters will start by running a vulnerability scan to identify your weaknesses so having a vulnerability management programme is a great way to get ahead.
A tool like Tenable Nessus is a good way to get started and it's not too expensive, coming in at around £2,000 for a year's licence. Nessus outputs scan results like this:
The remediations tab gives an idea of the things you need to do to resolve some of the vulnerabilities:
Once you've taken remedial action it's time to scan again and you should start to see the vulnerabilities drop away. Bear in mind though that scans can have a negative impact on performance or system stability, so it's worth checking you're comfortable with the scans you're running. By default, Nessus will only run "safe scans" which should be, er, safe. It's worth checking the individual results too, as sometimes there's a patch to install and a registry key or configuration change to make.
Vulnerability Management isn't something you do once and then stop, it's a continual process. More about that another time though.
Get teams on board
Unless you're the only sysadmin or IT system owner for the organnisation, it's highly likely other people will be responsible for changs. Some penetration testers will be prepared to rescan or retest for a vulnerability if you can show you've fixed a problem so you'll need to speak to other teams. They'll need to be prepared to fix stuff quickly so having a good working relationship with them is vital. As soon as the date of your penetration test is confirmed it's worth notifying everyone in IT so teams can reserve time in their diaries.
"Low hanging fruit" problems
You don't want to pay a third party to find these easy to fix problems - find them yourself, fix and then concentrate on the more specialist stuff with your tester. By getting everything patched ahead of the test you'll have dealt with a lot of the low hanging issues so will get a good return on your investment from the test.
For source code, an example of low hanging fruit would be not sanitising user input that results in SQL or code injection. It's fairly quick to check for that via a brief code review, especially around database queries. If the system under test is your web application it's worth a quick review of your code, certainly in key areas, and the fix should be relatively simple.
A penetration test from a qualified tester is a really good investment and a great way to help sure up your defences. Given the costs involved in a test (often at least £2,000) it's important to make sure your tester only finds things you couldn't find yourself - the old adage of "why have a dog and bark yourself?". Resolving issues ahead of your test will mean more complicated issues are reported so you can solve them, increasing security for you and your customers.