Hackers can wear hats in many shades of grey. But how can you work with them and turn ethical hacking to your advantage?

The best way of dealing with vulnerabilities is through prevention – by developing software in a secure manner. Despite all the efforts, some vulnerabilities may still slip through, and hackers will find them. At this time it is a “zero-day”: known by some hackers, but not by the developer. This is the worst possible state for a vulnerability. If you’re unlucky, the hacker will be a “black-hat” who proceeds to exploit this vulnerability for their own gain or sells it to criminals. However, it is possible that they will be an ethical hacker – and they’ll give you the details of the vulnerability instead.

In a best-case scenario, they are basically doing penetration testing for you for free.

The many shades of grey hats

Hackers are categorized into three main groups: white hats, grey hats and black hats. Let’s ignore criminals or “black hats” for a moment and talk about those who consider themselves ethical hackers or security researchers.

White hats are your internal security team, or a third party you ask to find vulnerabilities for you. If you have a so-called bug bounty program, the hacker reporting a vulnerability to you is a white hat, assuming they followed your rules (e.g. only target a dedicated test server for vulnerability research).

In most cases, the hacker will be a grey hat: a security researcher who may have broken the law (e.g. by gaining admin access to your production server). However, they are not exploiting their position, and not acting with malicious intent. The legality of ethical hacking – when done without prior authorization – varies from country to country, but prosecuting hackers is generally counterproductive. Especially if you can’t prove they have done measurable harm. The video game company ArenaNet’s failed crusade against a hacker in Germany is a good cautionary tale here.

These hackers may not be doing this kind of security research out of the goodness of their hearts. They may want to sell you security consulting or penetration testing (as a white hat), or just hope to be paid for their time. You can incentivize ethical hackers directly by paying them, or – even better – setting up a bug bounty program.

An important part in the ethical hackers’ motivation is disclosure: how (or if) they can share the details of the vulnerability and/or its exploitation. Typical reasons for disclosure are:

• Prestige: Improving the hacker’s reputation in the community, or adding a new line under ‘Accomplishments’ in a CV.
• Technical: Sharing the details of a technically challenging, tricky, or just interesting vulnerability or novel exploit technique with the application security community in write-ups, publications, or presentations.
• Activism: If the hacker feels it’s in the public’s best interest to know about the vulnerability.

There are three general models of disclosure:

• No disclosure: no details are disclosed whatsoever. This can be expected in internal penetration tests and security evaluation, or arrangements where the hacker signs an NDA. Also common in some domains such as medical devices, where disclosure could generate an unacceptable risk of physical harm.
• Responsible disclosure: details are only disclosed once the vulnerability has been fully addressed and patched. Since sometimes this can take a very long time, some security researchers set deadlines to incentivize developers to fix the vulnerabilities quickly (e.g. 90 days for Google’s Project Zero).
• Full disclosure: details – including exploitation – are immediately disclosed to the public based on a belief that it may already be actively used by criminals, and also forcing the vendor to take action. This is a controversial option that inevitably produces friction, and – arguably – moves away from the concept of ethical hacking. Sometimes, full disclosure can be triggered by frustration on the hacker’s side, such as the VirtualBox sandbox escape from November 2018.

Turning the three-edged sword of ‘ethical hacking’ to your advantage

So how do you make good use of ethical hackers? Simple – have a contact point for vulnerability reports, be responsive in your communication with security researchers, and don’t insist on non-disclosure. Alternately, set up a bug bounty program and use security researchers as a freelancer extension of your own security team and a security sanity check. It can have a better cost/benefit ratio than regular penetration tests (see An Empirical Study of Web Vulnerability Discovery Ecosystems).

However, keep in mind that while ethical hacking may be considered a kind of penetration test, it is NOT a comprehensive security test. Ethical hackers are not a substitute for secure software development. Instead, you should consider ethical hacking as an added layer of security to build into DevOps – and that is always a good thing!

Of course, nobody knows your software better than your developers – it’s a good idea to have them act as the first line of defense by teaching them the mindset and skills required to do security testing. We offer several training courses to help you with this, whether your language of choice is Java, Python, C#, or C/C++.