Determining What Systems to Hack

Determining What Systems to Hack
You probably don’t want — or need — to assess the security of all your systems
at the same time. This could be quite an undertaking and could lead to
problems. I’m not saying you shouldn’t eventually assess every computer and
application you have. I’m just suggesting that whenever possible, you should
break your ethical hacking projects into smaller chunks to make them more
manageable. You may decide which systems to test based on a high-level risk
analysis, answering questions such as:
What are your most critical systems? Which systems, if hacked, would
cause the most trouble or the greatest losses?
Which systems appear to be most vulnerable to attack?
Which systems are not documented, are rarely administered, or are the
ones you know the least about?
After you’ve established your overall goals, decide which systems to test.
This step helps you carefully define a scope for your ethical hacking so that
you not only establish everyone’s expectations up front, but also better estimate
the time and resources for the job.
The following list includes systems and applications that you may consider
performing your hacking tests on:
Routers
Firewalls
Network infrastructure as a whole
Wireless access points and bridges
Web, application, and database servers
E-mail and file/print servers
Workstations, laptops, and tablet PCs
Mobile devices (such as PDAs and cell phones) that store confidential
information
Client and server operating systems
Client and server applications, such as e-mail or other in-house systems
32 Part I: Building the Foundation for Ethical Hacking
What specific systems you should test depends on several factors. If you have
a small network, you can test everything from the get-go. You may consider
testing just public-facing hosts such as e-mail and Web servers and their
associated applications. The ethical hacking process is flexible. Base these
decisions on what makes the most business sense.
Start with the most vulnerable systems, and consider the following factors:
Where the computer or application resides on the network
Which operating system and application(s) it runs
The amount or type of critical information stored on it
If you’re hacking your own systems or a customer’s systems, a previous
security-risk assessment or vulnerability test may already have generated
this information. If so, that documentation may help identify systems for
more testing.
Ethical hacking goes a few steps beyond the higher-level information risk
assessments and vulnerability testing. As an ethical hacker, you first glean
information on all systems — including the organization as a whole — and
then further assess the systems that appear most vulnerable. I discuss the
ethical hacking methodology in more detail in Chapter 4.
Another factor to help you decide where to start is to assess the systems that
have the greatest visibility. For example, focusing on a database or file server
that stores customer or other critical information may make more sense — at
least initially — than concentrating on a firewall or Web server that hosts
marketing information about the company.
Creating Testing Standards
One miscommunication or slip-up can send your systems crashing during
your ethical hacking tests. No one wants that to happen. To prevent mishaps,
develop and document testing standards. These standards should include
When the tests are performed, along with the overall timeline
What tests are performed
How the tests are performed, and from where
How much knowledge of the systems you acquire in advance
What you do when a major vulnerability is discovered
This is a list of general best practices. You can apply more standards for your
situation.
Chapter 3: Developing Your Ethical Hacking Plan 33
Timing
You know they say that it’s “all in the timing.” This is especially true when
performing ethical hacking tests. Make sure that the tests you’re performing
minimize disruption to business processes, information systems, and people.
You want to avoid situations like miscommunicating the timing of tests and
causing a DoS attack against a high-traffic e-commerce site in the middle of
the day, or forcing yourself or others to perform password-cracking tests in
the middle of the night. It’s amazing what a 12-hour time difference can make!
Everyone in the project should agree on a detailed timeline before you begin.
This puts everyone on the same page and sets correct expectations.
Notify any Internet Service Providers (ISP) or Application Service Providers
(ASPs) involved before performing any tests across the Internet. This way,
ISPs and ASPs will be aware of the testing going on, which will minimize the
chance that they will block your traffic if they suspect malicious behavior
that shows up on their firewalls or Intrusion Detection Systems (IDSs).
The timeline should include specific short-term dates and times of each test,
the start and end dates, and any specific milestones in between. You can
develop and enter your timeline into a simple spreadsheet or Gantt chart, or
you can include the timeline as part of your initial customer proposal and
contract. For example, you could use a timeline similar to the following:
Test Performed Tester Start Time Projected End Time
War dial Tommy Tinker July 1, 6:00 a.m. July 1, 10:00 a.m.
Password cracking Amy Trusty July 2, 12:00 p.m. July 2, 5:00 p.m.
This timeline will keep things simple and provide a reference during testing.