180
A Practical Guide to Security Assessments
the firewall. Unless the company is a small or mid-size company where
the rule base is relatively simple, security or IT personnel will not gen-
erally know the rules that exist. In both examples, personnel are usually
not familiar with the details, and therefore detailed testing is required. In
the case of the firewall, it is probably a key component of the network
security architecture. Without reviewing the rule base, it is very difficult
to get a clear picture of what the actual rules are. The client might know
some of the rules but not know other, more obscure, rules that present
significant security risks. In fact, there are rules that the client might not
even be aware of. You would not know about this unless you look at the
details.
Test Planning and Related Considerations
As you test any type of technology, you should have some plan of what you are
testing for. In planning the test, you should consider these issues:
•
Impact on the production environment —
Much of the hands-on testing
will be conducted in a client’s production environment, which will under-
standably make some clients very nervous. They do not want their envi-
ronment to go down because of the security assessment. In consideration
of the production environment, you should properly analyze what is going
to happen on the network if you run your tests. The impacts could include
slowing down the network or generating traffic on an intrusion detection
system. Your testing might also have no impact. If an impact on the
network’s speed is expected, consider conducting the testing during off
hours if appropriate. Other considerations related to the production envi-
ronment include whether or not any agents or similar software will have
to be loaded into the production environment. Finally, when testing in the
production environment, you may have some type of administrator-type
access that allows you access to sensitive information. If the client is
nervous about this, you should encourage the client to look over your
shoulder as you perform the tests.
•
Sign-off or release from the client —
If you are working in the production
environment, you should have the client acknowledge and approve it. This
can be done via a separate form or can be covered when the initial security
assessment is signed. This process will differ if internal employees are
conducting the assessment. There might also be an internal policy that
covers this process of auditing production systems. If such a policy exists,
it should be adhered to. With the dependency on systems today, you must
protect yourself, and the client should also be aware of the responsibility
involved in making the right judgment as it relates to any testing being
done on the production system.
•
Access requirements —
Many of the tools that are used for testing require
administrator-type access on systems to run the test. With proper planning,
the client can set up temporary access for you to use. If the client knows
of this requirement in advance, the approvals required to set up this access
AU1706_book.fm Page 180 Tuesday, August 17, 2004 11:02 AM
Technology Evaluation
181
can be obtained. In many companies, there are strict requirements related
to providing this level of access.
•
Required changes to system settings —
For some of the tests you run,
temporary changes in systems settings may be required to facilitate the
testing. For example, you might run a test remotely that would require
the client to open a port on a firewall. Another example is where a
particular log might have to be enabled to capture information for the
tests. If these changes to system settings are not performed properly, you
could end up wasting some time in your testing.
•
Tool licensing issues —
For the commercial tools that you are going to
use in testing, look into how you will license them for a particular client.
Different tool vendors have different ways in which they license. Some
vendors may license by Internet Protocol (IP) addresses, but others might
ask for certain information to generate a key to use the product. In some
cases, you might be using a tool that is supplied by the client, in which
case the client must be told to take care of any licensing issues beforehand.
Tool licensing is something that might not seem critical, but if it is not
handled properly, you stand to lose significant time in working out these
issues.
•
Resources —
As with any other area of the security assessment, you must
have the right people performing the hands-on testing. Be very careful
about this because much of the testing will be performed on production
systems. People without the right skill set can improperly use the tool and
negatively impact the production system. Scheduling the right people is
something that should be addressed early in the assessment process.
The issues above are some of the issues you might face as you plan the detailed
testing. It is best to be proactive and resolve them as quickly as possible to ensure
that this testing phase runs smoothly.
Once the issues above are considered, the process for the test should be devel-
oped. The plan should be detailed and include timing, tool selections, resources
required, and any steps (e.g., changes in system settings, off-hours scheduling)
required to facilitate the testing. Because some of these tests can take time and are
potentially disruptive to the environment, it is critical to plan them properly and
communicate the plan to the client. This will help ensure that test objectives are met
and the necessary information is gathered for analysis.
Manual vs. Automated Testing
For most environments, you will do some combination of manual and automated
testing. The combination of manual and automated is required because some tests
cannot be performed using tools and others are performed more efficiently using
tools. When planning the tests, it is useful to identify what tools and related features
are going to be used. It is also useful to identify what manual procedures you will
be performing. Note that these plans are evolving and they will change based on
how the tests progress and what you find.
AU1706_book.fm Page 181 Tuesday, August 17, 2004 11:02 AM
182
A Practical Guide to Security Assessments
Both manual testing and automated testing have their uses. Tools can perform
tests and gather information that would take significant time if you tried to do the
same things manually. In addition, for information gathering that is repetitive, tools
are far more efficient. For example, if you wanted to see whether patch levels on
servers are up to date, you can use tools that scan servers and provide this informa-
tion. Another example is application security. There are tools now that can simulate
actions that hackers would take to break into an application. These tools can send
out many simultaneous commands that simulate someone trying to break in. This
would be virtually impossible to do manually.
On the other hand, tools cannot perform some tests. For example, there may be
specific checklists (e.g., Windows 2000 server), such as the best practice checklists
provided by Microsoft on its Web site. It might be easier to go through such a
checklist using manual procedures. This is where manual testing will be necessary.
In addition, manual procedures will be required to analyze information that the tools
generate. Manual testing is also more appropriate when the testing is a trial-and-
error type test where certain commands are executed and results are analyzed. The
other key area where manual testing is necessary is when information gathered from
automated testing tools needs to be analyzed. Tools are not perfect and as a result,
the results they generate sometimes have “false positives.” In addition, two different
tools performing similar tests might generate different results. To investigate this
further, manual testing is required.
Ultimately, you need to start with a clear idea of the test objectives before
deciding how to perform the testing. Using this as a basis will help you understand
what tools are necessary and what manual procedures are appropriate. As you select
tools to use, you should consider several factors. These are discussed in the next
section.
Tool Selection
Those who have been in the information security industry know that myriad testing
tools are commercially available or in the form of shareware and freeware. All of
these tools have their merits, and each is appropriate in certain circumstances. When
selecting tools to use in a security assessment, consider these factors:
•
Financial —
Depending on the environment and the funds set aside for
conducting the assessment, the cost of tools must be considered. Com-
mercial tools can be expensive, and the reality is that unless you can
spread the cost of commercial tools across assessments, you may not get
the approval to buy them. In these tight economic times, you must be able
to show return on investment (ROI) for tools. Commercial tools obviously
make more sense in larger environments or across multiple clients. They
also make sense in cases where the tools used to assess can be used as a
compliance tool going forward. In smaller environments, ROI for some
tools is more difficult to demonstrate. In these cases, freeware tools can
be very attractive. Freeware tools are widely used by security practitioners,
and many are well supported by the community. Some of the more famous
AU1706_book.fm Page 182 Tuesday, August 17, 2004 11:02 AM
Technology Evaluation
183
security tools, such as Nmap and Nessus, are very widely used by both
consultants and security operations personnel. One of the main differences
with commercial tools is the technical support and training that are typi-
cally available. Freeware tools, on the other hand, provide significant
functionality at essentially no cost. One way to combine commercial and
freeware tools is to use one to validate the results of the other. This
technique will help you identify potential false positives and areas where
more detailed manual testing is required.
•
Real-world scenario —
When assessing security, one of the main concerns
is how an unauthorized individual could find vulnerabilities to exploit.
Unauthorized individuals with these types of intentions will not typically
pay $20,000 for a tool to gather information about a company’s systems.
The reality is that these individuals will use tools that are freely available
on the Internet. For this reason, it is useful to use some freeware tools
when performing a security assessment, as this will simulate the real-
world scenario. As you perform security assessments, you will see that
many clients want this real-world simulation.
•
Reporting functionality —
Reporting functionality is a significant consid-
eration when considering what tools to use. Remember that tools are used
in the “Technology Evaluation” phase, which is primarily composed of
information gathering. To be able to properly analyze the information
generated from tools, you should ensure that the reports are adequate.
Some things to consider are whether or not you can take a vulnerability
and drill down to obtain more specific information about it. Another
consideration is how much detail the reports provide. Commercial tools
tend to have good reports; this is part of what you are paying for. Some
of the freeware tools also have excellent reporting functionality — e.g.,
Nessus provides good reporting about vulnerabilities. Reporting is critical
because it serves as the basis for analysis and the identification of findings.
•
Source —
Commercial tools come from vendors and a “controlled” envi-
ronment. One of the issues you should be aware of is where you are
obtaining freeware tools. Realizing that these tools will be deployed in a
company’s production environment, you should be careful in obtaining
tools to ensure that they come from reputable sources. Remember that
with freeware tools, no recourse exists if something goes wrong.
Tools are absolutely critical to the security assessment process, and the recom-
mendation is to use both commercially available and freeware or shareware tools.
If you use caution and clearly lay out the test objectives, the use of a combination
of tools provides the best value. The goal is to find the information necessary to
perform a quality technical analysis.
Process for Conducting Detailed Technology Testing
The process for conducting detailed testing is largely a logistical matter. The steps
include items that were discussed in the previous sections. The key steps require
AU1706_book.fm Page 183 Tuesday, August 17, 2004 11:02 AM
184
A Practical Guide to Security Assessments
consistent and regular communication with the client’s IT personnel. The high-level
steps comprising the methodology for conducting hands-on technology testing are:
1.
Inform the technology owners and schedule the test —
The technology
owners need to be aware, and you need to schedule the testing at a time
when it is appropriate. Potential impacts to the production environment
should be considered.
2.
Obtain any signoff or release process —
Depending on what type of testing
you are doing and the specific environment you are in, it may be appro-
priate to obtain official approval for conducting testing. This type of
approval could be obtained in different ways including a formal form or
an acknowledgment of electronic mail.
3.
Obtain all the necessary access —
Some of the testing that you do will
require administrator or user access to certain systems. At some compa-
nies, providing access (especially administrator-level access) can take
time. Therefore, you should determine what type of access you need and
initiate the process of receiving this access as soon as possible.
4.
Conduct testing using tools and manual procedures —
This is the actual
testing with the tools as well as the manual testing. In preparation for the
manual testing, you should ensure that you have the checklists you are
going to use in conducting the tests. When using the checklists, review
them beforehand to determine whether some items can be eliminated and
whether some things should be added.
5.
Generate information and organize for analysis —
The information from
both the manual and automated testing should be gathered and organized
for easy analysis. For the automated testing, you will have reports that
can be generated. For the manual testing, you should ensure that you have
some type of checklist or form that will make it easy to record information.
The process for hands-on testing is fairly straightforward. There might be a
tendency to try to rush through this process, but you should ensure that you follow
it. In particular, Steps 1 through 3 are critical when doing the testing because they
affect the client. If those steps do not happen properly, impacts may include:
•Revision of the timing of the security assessment — e.g., if the proper
access is not obtained or if scheduling is not performed
•Legal issues if the client is not aware of the tests or has not approved them
C
OMMON
D
ETAILED
T
ECHNOLOGY
T
ESTING
Although you will develop the list of what technology will be tested in further detail,
this section will discuss, at a high level, some of the common technology testing
that happens in virtually any security assessment. These are some distinct areas that
are present and tested in many companies:
•
Local area network —
The local area network is critical at almost any
company because it is the area that employees access and an entry point
AU1706_book.fm Page 184 Tuesday, August 17, 2004 11:02 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.