How ethical hacking can prevent fraud

Those of us who work in risk management spend a large portion of our time in a theoretical world, writes Rudi Dicks, senior consultant at BDO Cyber and Forensics Lab.
However, from time to time it becomes necessary to do a practical test to see if the controls we’ve put into place are effective.
We’ve all heard horror stories where the IT team only realize that the backups they were doing religiously couldn’t be restored for a reason they never considered. This realisation usually hits too late and as a community, we’ve learnt from these mistakes and now periodically test our restores as part of the disaster recovery (DR) process.
Many companies will turn off the power to the server room to see if the UPS and generator will in-fact take over as expected.
It’s the same with security. As an ethical hacker (or penetration tester) I spend my day breaking into companies with their permission to test the real-world effectiveness of the controls that you’ve implemented to keep your company safe.
My team and I (and bad guys for that matter), don’t really care that you are ISO/NIST/PCI etc. compliant, or that you have an excellent project manager who followed best practice guidelines during implementation and rollout of your new equipment. We only care about which ports are accessible from the internet and what you have running on those ports or if the default username and password was changed before the equipment went live.
We don’t care about whether you’ve spent a fortune putting technical controls in place to prevent phishing attacks. We do care about whether we can get someone to click on a link, or open an attachment they shouldn’t because if they do, we can bypass all your hard work and gain internal access to your infrastructure, and then the fun begins.
Unfortunately, almost all our attacks are at-least somewhat successful and inevitably, during the debrief meeting we have a discussion with a smart, competent, hard-working manager who feels let down by the processes that they’ve put in place.
Let me give you an example: We recently tested for a client who is very security conscious and they employ competent people who have worked very hard, both from a risk and technical perspective to keep the company safe from hackers.
They have implemented some exceptional controls and technical solutions to protect the systems from unauthorized use but unfortunately, and somewhat predictably, in a network with thousands of devices, there was one old windows XP machine that was used to run the CCTV systems. This was to save budget, and because the software of the camera systems (which worked perfectly well) wasn’t compatible with newer versions of Windows.
Once we gained access to the internal infrastructure (something that is easier than you might think) we identified and exploited that machine. Because it had been logged in by an administrator, we quickly gained access to the domain admin password and just like that we had full access to the entire company.
At this point, we can easily start up a round of “The blame game” but I can assure you, the attackers don’t care who’s fault it was. This is why vulnerability assessments and penetration tests (VAPT) are so important. If even a little of the time, energy and budget had gone into VAPT the team would have quickly identified the old machine and made a decision about the risks involved.