Datasheet

19
Chapter 1: Introduction to Ethical Hacking
Handle social engineering and DoS attacks carefully. Determine how
they affect the systems you test and your entire organization.
✓ Dates the tests will be performed and your overall timeline:
Determining when the tests are performed is something that 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 produc-
tion systems aren’t affected? Involve others to make sure they approve
of your timing.
The best approach is an unlimited attack, where any type of test is pos-
sible 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 DoS attacks, social engineering, and physical
security tests.
✓ 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 and cost more. Base the type of test you perform on your organiza-
tion or client’s needs.
✓ Actions you will take when a major vulnerability is discovered: Don’t
stop after you find one security hole. 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). If you haven’t found
any vulnerability, you haven’t looked hard enough. If you uncover some-
thing big, you do need to share that information with the key players as
soon as possible to plug the hole before it’s exploited.
✓ The specific deliverables: This includes vulnerability scanner reports
and a higher-level report outlining the important vulnerabilities to
address, along with countermeasures to implement.
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 don’t want the users aware of what you’re doing. Otherwise,
the users might catch on to you and be on their best behavior — instead of
their normal behavior.