Approval for ethical hacking is essential. Make what you’re doing known and
visible — at least to the decision makers. Obtaining sponsorship of the project
is the first step. This could be your manager, an executive, a customer, or
even yourself if you’re the boss. You need someone to back you up and sign
off on your plan. Otherwise, your testing may be called off unexpectedly if
someone claims they never authorized you to perform the tests.
The authorization can be as simple as an internal memo from your boss if
you’re performing these tests on your own systems. If you’re testing for a
customer, have a signed contract in place, stating the customer’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 questions what you’re doing.
You need a detailed plan, but that doesn’t mean you have to have volumes of
testing procedures. One slip can crash your systems — not necessarily what
anyone wants. A well-defined scope includes the following information:
Specific systems to be tested
Risks that are involved
When the tests are performed and your overall timeline
How the tests are performed
How much knowledge of the systems you have before you start testing
What is done when a major vulnerability is discovered
The specific deliverables — this includes security-assessment reports
and a higher-level report outlining the general vulnerabilities to be
addressed, along with countermeasures that should be implemented
When selecting systems to test, start with the most critical or vulnerable
systems. For instance, you can test computer passwords or attempt socialengineering
attacks before drilling down into more detailed systems.
It pays to 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 could
cause loss of data integrity, loss of data, and bad publicity.
Handle social-engineering and denial-of-service attacks carefully. Determine
how they can affect the systems you’re testing and your entire organization.
Determining when the tests are performed is something that you must think
long and hard about. Do you test 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.
The best approach is an unlimited attack, wherein any type of test is possible.
The bad guys aren’t hacking your systems within a limited scope, so why
should you? Some exceptions to this approach are performing DoS, socialengineering,
and physical-security tests.
Don’t stop with one security hole. This can lead to a false sense of security.
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. Simply pursue the
path you’re going down until you can’t hack it any longer (pun intended).
One of your goals may be to perform the tests without being detected. For
example, you may be performing your tests on remote systems or on a remote
office, and you don’t want the users to be aware of what you’re doing. Otherwise,
the users may be on to you and be on their best behavior.
You don’t need extensive knowledge of the systems you’re testing — just a
basic understanding. This will help you protect 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 hacking a customer’s systems, you
may have to dig deeper. In fact, I’ve never had a customer ask for a fully blind
assessment. Most people are scared of these assessments. Base the type of
test you will perform on your organization’s or customer’s needs.