The 7 steps of ethical hacking

To beat hackers at their own game, you need to think like them. They’re going to probe your software systems to find security vulnerabilities; you need to do this too. 

But … how?

If you're like most people, you struggle to understand how attackers think, how they operate and how they break systems. Worst of all, you may struggle to know what to do about it.

Believe it or not, there’s a method to the madness, and I’m going to show you exactly what it is.  

Download Ted's free ebook, "How to secure your software faster and better."

Get Your Copy

Step one: Hire an external security partner

Your first step is to hire an external security partner to do the hacking. You might think “we can handle this in-house,” but your ethical hackers offer several unique benefits. 

You want complete independence. An external expert provides an unbiased view; they’ll tell you exactly how it is, even if it isn’t what you want to hear. They didn’t build your code, so they have no attachment to it. 

By hiring an external partner, you capitalize on subject matter expertise that you probably don’t have in-house. You get both the breadth and depth that come with a diverse team of experts, which most companies don’t staff in-house. And you get all of that when you need it, and don’t pay for it when you don’t. Most companies don’t need a full-time team of ethical hackers in-house, so this is a cost-efficient way to get expertise within the financial constraints of your business.

Beware, however, that not all partners are the same. Specializations and levels of skill vary widely, so make sure to vet potential security partners in order to hire the specialization and skills you need (if you struggle with this part, chapter 1 of “Hackable” explains in depth how to do this). 

Step two: Analyze the design

To understand how to break the system, your partner needs to understand how it’s supposed to work. That’s why the next step is to analyze the design. 

Your security partner should learn the fundamentals of the software: the features, how users navigate through it, how access is provisioned and where users can input values. They need to understand why it exists, what business problems it solves and what it protects. 

They’ll also want to evaluate for design flaws, which are vulnerabilities inherent in the system’s design. Give your partner time to analyze for these flaws before moving on. 

Unfortunately, many security approaches overlook this step. For example, if your partner is just running an automated scanner and that’s all, it won’t matter how the system works or why it works that way. Yet, the most important vulnerabilities tend to be impacted heavily by those factors.

Step three: Run scans

Next, your security partner should run scans, which are an efficient and inexpensive way to gain information that helps in later assessment stages. Scans quickly reveal the obvious issues that would require enormous effort to do manually. Most attackers run scans first, so it’s a good idea for you to do this, too. You want to see what they’ll see. 

Keep in mind that scanning is not a comprehensive effort to find your security vulnerabilities; it’s just one piece of the overall puzzle. However, many security approaches try to do exactly that. Reject that. 

Step four: Look for known vulnerabilities

Attackers want the best results for the effort they invest, so the logical place to start is by looking where most people make mistakes. They seek these out as a shortcut to their success. Many software systems suffer the same mistakes, and so attackers explore the likely assumption that yours did too. 

To defend successfully, your testing must check for common issues, including things like Injection Attacks, Broken Authentication and Broken Access Control. This is just a sampling of the ever-evolving types of issues your attackers know to look for. Your security partner should, too. 

Caution: There’s a capability gap

Unfortunately, most security testing calls it quits at this point. Many approaches don’t even hit all of the steps mentioned so far: they rely solely on scans and fail to analyze the design. 

The testing discussed so far requires minimal to moderate skill and experience and can be performed with heavy emphasis on automated tools. But what comes next — the stuff that really matters — requires high skill, deep experience and a manual emphasis. 

When you vet your partner — and then later agree on scope and methodology — make absolutely sure you’re going to be getting everything that comes next. If you won’t, choose a different partner. 

Your security partner should go beyond the fundamentals previously discussed and into the advanced tactics we’re about to get into. 

Step five: Abuse the system’s functionality

Now that you’ve made sure to cross the capability gap, the next thing your security partner does is abuse the system’s functionality. This uses an application’s own features in an attack. 

An example might be abusing the way a system treats integers: if the system is expecting positive integers, but negative integers are used instead, what happens? Or alternatively, can one user manipulate the password reset functionality to reset passwords for other users, thereby taking over their account? 

Attackers want to abuse your system’s functionality. That means you need to have your partner look for this too. By finding these vulnerabilities first, you can fix them and prevent abuse. 

There’s no tool for this. You can’t automate it. You must do it manually. 

Step six: Chain exploits

The next step is exploit chaining, which is combining two or more vulnerabilities in order to multiply impact. Like timing jumps on a trampoline with a friend to send each other rocketing to new heights, chaining exploits enables attackers to cause even more damage. 

In isolation, a couple of vulnerabilities might not be bad. In combination, they might be catastrophic. Vulnerabilities must be considered in the context of each other, rather than in isolation. Attackers seek to chain exploits, and you should, too. There’s no tool for this. You can’t automate it. You must do it manually. 

Step seven: Seek the “unknown unknowns”

Lastly, your security partner will want to seek out “unknown unknowns,” which are flaws so unexpected you don’t even consider them. 

This comes in numerous forms, including novel versions of common vulnerabilities and previously unknown attack methods. Dealing with unknown unknowns is the absolute pinnacle of security testing. It entails the most important issues you’ll face. 

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

To find the unknown unknowns requires skilled manual investigation. It is the only way to solve this part of the security puzzle, so vet your security partners before any of this work begins and make sure they’re up to the challenge.

Put it all together

If you have valuable digital assets that are worth protecting, then you want to make sure you fix your security vulnerabilities before your attackers exploit them. To do that, you need a skilled, external partner helping you by investigating your system with the same malicious viewpoint your attackers would have.

They need to go beyond the basics and execute the advanced tactics. All of them.

If you get the right partner and have them do the right testing, you’ll know exactly how to deal with your concerns about getting hacked.