Using the Ethical Hacking Process
Like practically any IT or security project, you need to plan your security testing. It’s been said that action without planning is at the root of every failure. Strategic and tactical issues in the ethical hacking process need to be determined and agreed upon. To ensure the success of your efforts, spend time up front planning for any amount of testing — from a simple OS password-cracking test against a few servers to an all-out vulnerability assessment of a web environment.
Formulating your plan
Getting approval for security testing is essential. Make sure that what you’re doing is known and visible — at least to the decision makers. Obtaining sponsorship of the project is the first step. This is how your testing objectives will be defined. Sponsorship could come from your manager, an executive, your client, or even yourself if you’re the boss. You need someone to back you up and sign off on your plan. Otherwise, your testing might be called off unexpectedly if someone (including third parties such as cloud service and hosting providers) claims you were never authorized to perform the tests. Even worse, you get fired or charged with criminal activity — it has happened!
The authorization can be as simple as an internal memo or an e-mail from your boss when you perform these tests on your own systems. If you’re testing for a client, have a signed contract stating the client’s support and authorization. Get written approval on this sponsorship as soon as possible to ensure that none of your time or effort is wasted. This documentation is your “Get Out of Jail Free” card if anyone such as your Internet Service Provider (ISP), cloud service provider, or related vendor questions what you’re doing, or worse, if the authorities come calling. Don’t laugh — it wouldn’t be the first time it has happened.
One slip can crash your systems — not necessarily what anyone wants. You need a detailed plan, but that doesn’t mean you need volumes of testing procedures to make things overly complex. A well-defined scope includes the following information:
Specific systems to be tested: When selecting systems to test, start with the most critical systems and processes or the ones you suspect are the most vulnerable. For instance, you can test server OS passwords, test an Internet-facing web application, or attempt social engineering via e-mail phishing before drilling down into all your systems.
Risks involved: Have a contingency plan for your ethical hacking process in case something goes awry. What if you’re assessing your firewall or web application and you take it down? This can cause system unavailability, which can reduce system performance or employee productivity. Even worse, it might cause loss of data integrity, loss of data itself, and even bad publicity. It’ll most certainly tick off a person or two and make you look bad.
Handle social engineering and DoS attacks carefully. Determine how they affect the people and systems you test.
Dates the tests will be performed and your overall timeline: Determining when the tests are performed is something you must think long and hard about. Do you perform tests during normal business hours? How about late at night or early in the morning so that production systems aren’t affected? Involve others to make sure they approve of your timing.
You may get pushback and suffer DoS-related consequences, but the best approach is an unlimited attack, where any type of test is possible at any time of day. The bad guys aren’t breaking into your systems within a limited scope, so why should you? Some exceptions to this approach are performing all out DoS attacks, social engineering, and physical security tests.
Whether or not you intend to be detected: One of your goals might be to perform the tests without being detected. For example, you might perform your tests on remote systems or on a remote office and you might not want the users to be aware of what you’re doing. Otherwise, the users or IT staff might catch on to you and be on their best behavior — instead of their normal behavior.
Knowledge of the systems you have before you start testing: You don’t need extensive knowledge of the systems you’re testing — just a basic understanding. This basic understanding helps protect you and the tested systems. Understanding the systems you’re testing shouldn’t be difficult if you’re hacking your own in-house systems. If you’re testing a client’s systems, you may have to dig deeper. In fact, I’ve only had one or two clients ask for a fully blind assessment. Most IT managers and others responsible for security are scared of these assessments — and they can take more time, cost more, and be less effective. Base the type of test you perform on your organization’s or client’s needs.
Actions you will take when a major vulnerability is discovered: Don’t stop after you find one or two security holes. Keep going to see what else you can discover. I’m not saying to keep hacking until the end of time or until you crash all your systems; ain’t nobody got time for that! Instead, simply pursue the path you’re going down until you just can’t hack it any longer (pun intended). If you haven’t found any vulnerabilities, you haven’t looked hard enough. They’re there. If you uncover something big, you need to share that information with the key players (developers, DBAs, IT managers, and so on) as soon as possible to plug the hole before it’s exploited.
The specific deliverables: This includes vulnerability scanner reports and your own distilled report outlining the important vulnerabilities to address, along with recommendations and countermeasures to implement.
