Every ethical
hacker must abide by a few basic commandments. If not, bad things can happen. I’ve seen these
commandments ignored or forgotten when planning or executing ethical hacking
tests. The results weren’t positive.
Working
ethically
The word ethical in
this context can be defined as
working with high profes- sional morals
and principles. Whether you’re
performing ethical hacking tests against your own systems or for someone who has hired you, everything you do as an ethical
hacker must be aboveboard and must support the
company’s goals. No hidden
agendas are allowed!
Trustworthiness is
the ultimate tenet. The misuse of
information is absolutely forbidden. That’s what the
bad guys do.
Respecting privacy
Treat the information you gather with the utmost respect. All information you obtain
during your testing — from
Web-application log files to clear-text passwords — must be kept private. Don’t use this
information to snoop into confidential corporate information or private
lives. If you sense that someone should know there’s a problem, consider
sharing that information with the appropriate manager.
Involve others in your process. This is a “watch the watcher” system that can build trust and
support your ethical hacking
projects.
Not
crashing your systems
One of the biggest mistakes I’ve seen when people try to hack their own sys- tems is inadvertently crashing
their systems. The main reason for
this is poor planning. These testers
have not
read the documentation or
misunderstand the usage and power of the
security tools and techniques.
You can easily create DoS conditions on your systems when
testing. Running too many tests too
quickly on a system causes
many system lockups. I know because I’ve
done this! Don’t rush things and assume
that a network or spe- cific host can handle the beating that network scanners and vulnerability- assessment tools can dish out.
Many
security-assessment tools can control how many
tests are performed on a system at the
same time. These tools are especially
handy if you need to run the tests on production systems during regular
business hours.
You can even create an account or system lockout condition
by social engi- neering someone into changing a password, not realizing that doing so might create a system lockout condition.