Relational Security Assessment Model: Tactical Audit PROCESS

Performing audits regularly is an essential part of maintaining security within any organization. Audits help to find existing vulnerabilities and proactively stop others from appearing. The more often security audits are performed, the more likely it is that an organization will find its vulnerabilities before a hacker does.

An internal audit can be performed in great depth if so desired. Sometimes, the sheer critical nature of internal systems calls for extremely detailed audits that yield thousands of pages of results, diving into the minute details of every system, physical area, and corporate relationship imaginable. This form of audit, however, is not practical for the majority of today's organizations, as they are quite costly and yield complicated results. For an audit to enhance security within the average organization, it must be practical. By practical, I mean that it must:

  • Be affordable in terms of expenses, time, tools, and expertise This includes the time required for individuals to answer questions and otherwise participate in the audit process.

  • Yield accurate and useful information Audits should focus on important details, the goal being quality not quantity.

  • Produce easy-to-comprehend results Audit results should be understood by everyone, not just the group performing the audit.

The following is a tactical audit process that can be performed in a reasonable period of time, under a reasonable budget, and without consuming numerous resources. In the next section, I will discuss other important audit tasks, but they do not conform so well to a formula. A good assessment includes both the tactical audit process discussed here and the analytical process discussed in the next section.

When performing a security audit, keep in mind that the audit is a reflection of your policies. During the audit process, work to ensure that objects within the organization conform to security policies. Thus, the quality of the audit should be weighted heavily on the quality of the security policies. If no policies exist, it will be extremely difficult to perform an audit.

Audit Tools

It is recommended that a few tools be acquired when performing a security audit. These tools are used to handle many of the audit's details, leaving the organization to focus on the audit itself. Though an audit could probably be performed without any tools, the following products greatly enhance the results and end up saving a great deal of time and effort.

  • Vulnerability scanning tool This tool is used to scan for vulnerabilities within systems and devices. The tool will run against a single device or an entire network and look for thousands of potential security weaknesses. There is a variety of scanning tools available, ranging widely in capability and focus. The most popular professional tool has been ISS's Internet Security Scanner, which has numerous features (www.iss.net/). There are also a great many Open Source tools, one of the most popular being NMAP.

  • Risk analysis tool A risk analysis tool is used to collect and process various bits of information about servers, networks, and devices. Such tools are designed to record a great deal of information and draw complex security relationships that are often difficult to correlate manually. These tools will then generate executive and technical reports, making it easier to interpret, share, and archive the results. The risk analysis tool that follows the Relational Security Assessment Model described in this book is the Relational Security Audit Manager (RSAM) from Relational Security Corporation (www.relationalsecurity.com). Other risk analysis tools, including AuditIT, use different risk assessment processes.

  • Assorted hacker tools Hacker tools are often nice to use as a supplement to the vulnerability scanning product. Most of these tools are legitimately marketed as a means to audit your own organization rather than break into another. Such tools are easy to obtain and sometimes free of charge. They can be used to perform mock attacks against systems, applications, and services to further determine where vulnerabilities exist. It is important when using such tools to download them from a reputable source and to only use tools that have been tested by other organizations. (There is nothing worse than letting a hacker into your network while performing an audit.) Some important hacker tools include password crackers like L0phtCrack/LC4 (www.atstake.com) and vulnerability scanners like Nessus (www.nessus.org/).

Basic Audit Steps

Again, internal audits can range greatly in complexity of process and depth of results. In my experience, a complicated and extremely detailed audit is of little use to most organizations. The simple steps shown in Table 8.15 have been proven to have the strongest impact on security:

Table 8.15. Steps for a Practical Security Audit

Tactical Audit Tasks

Estimated Time Required

Audit preparation

N/A

Object discovery

N/A

Risk assessment and analysis for servers, WAN links, routers, devices, and rooms

15 minutes/object

Vulnerability scan on network-accessible objects

5 minutes/server

2 minutes for other objects

Basic hands-on audit of some or all objects

15 minutes/object

Hands-on sampling of desktop security

10 minutes/100 desktops

Physical inspection of rooms and closets

10 20 minutes/area

Compile and score data

N/A

Audit report and review

N/A

Step 1 Audit Preparation

Before beginning the audit process, there are a couple of basic tasks that need to be completed:

  1. Acquire audit tools We already reviewed some audit tools that should be used during the audit process.

  2. Define risk levels, risk factors, and auditable controls Remember, such components should be thought of in terms of the entire organization. The results of the audit process will reflect the decisions made here, so before moving forward, it is important to define each component as described in the section, The Relational Security Assessment Model.

  3. Schedule technical components In accordance with the Rule of Change, it is important that administrators and managers be aware of the technical activities being performed. Activities that will be of interest include all network scans, penetration testing, and hands-on analysis.

Step 2 Object Discovery

Before beginning an audit, we need to have an accurate view of what is out there. One major problem I commonly see in audits is that an organization will assume it knows what objects exist and where they are located before the audit process even begins. Often, the weakest links within an organization are objects that no one even knows about. Thus, it is important to start the audit by creating a current list of all objects that are going to be audited.

  1. Make a list of all facilities to be included in the audit For each facility, list important details such as:

    1. Network address ranges

    2. Rooms and closets containing servers or routers

    3. Servers, routers, and other major network devices

    4. Important contacts

  2. Attach a network scanner and perform a "discovery scan" A discovery scan is a network scan that searches a range of network addresses and returns a list of those in use. Normally, a discovery scan will also reveal information concerning the device using the address, such as the name and operating system used. If possible, perform multiple discovery scans at different times of the day and different days of the week to make sure no devices are missed.

  3. Review the known devices Compile a complete list of all devices discovered and have this list reviewed by someone who actively works in the facility. Have that individual add anything missed to the list and then sign the document.

There are other, more advanced techniques for gathering this information. Techniques such as ARP cache reading, network sniffing, and the like can also be performed, if your organization has the proper expertise. The steps above, however, should catch the majority of objects while using the least number of resources. As the audit proceeds, one of the tasks will be to continually look for devices not previously listed. The goal here is to start with as accurate a view as possible. Objects that are missed should be picked up during the remainder of the audit.

Step 3 Risk Assessment

Now that we have our complete list of objects, we need to come to an understanding of how each major object functions within the environment. Here is where we begin to conduct the audit according to the Relational Risk Assessment Model. During this step, we interview various staff members about each object. Through this process, we assign risk factors to help us determine the risk level each object holds within the organization.

  1. Understand each object For every server, router, WAN link, physical area, and other major object discovered, document information like:

    1. The purpose of the object and its function within the environment

    2. The major applications and services running on the object

    3. The data stored in or transmitted by the object

    4. The types of users with access to the object

  2. Discover the risk factors For each object, interview managers, administrators, and end-users using the list of risk factors created in Step 1. Use this interview information along with the information gathered in the previous step to determine and document the appropriate risk factors for each object.

  3. Determine the risk level Take the highest risk factor for each object and document the related risk level.

  4. Inquire about controls For each object or group of objects, ask the administrators how they were built and what security controls have been put in place. Refer back to the list of controls created in Step 1 if required. Later on, we will compare these controls against the minimum required controls to determine a score.

Step 4 Vulnerability Scanning

Now that we have discovered, verified, and assigned risks to various objects, we can begin performing vulnerability scans using our vulnerability scanning tool. Different scanners have different options, but most include probing policies based on the type of object being scanned. We would not want to scan a router, for example, looking for vulnerabilities associated with a server.

Vulnerability scanners are very powerful tools. They can be extremely helpful, and extremely destructive when used improperly. Here are some key points to consider before performing any type of vulnerability scan:

  • Get written permission before scanning any object outside your immediate authority.

  • Schedule vulnerability scans in advance and at times when no other network or system changes are occurring.

  • Make sure administrators and managers understand that the scanner could potentially have negative effects on sensitive objects.

  • Perform the proper scan for each type of object. Scanning a server with a scan intended for desktops could miss a number of vulnerabilities.

  • Vulnerability scanners normally come with the ability to perform DoS scans. Make sure you turn this feature off, or coordinate with administrators in the event that the DoS succeeds and the object goes offline.

Step 5 Hands-on Audit

The hands-on portion of the audit is where we go in and actually verify the controls we found in our interviews conducted in Step 3. This portion of the audit has the potential of consuming the most time and resources in the audit process. Different organizations choose to deal with the hands-on audit in different ways. The most accurate approach is to perform hands-on verification of each and every major object. This, however, may not be practical in many situations. As such, I have provided a list of the most common alternate approaches I have seen:

  • Perform hands-on auditing on a randomly selected sample of objects

  • Perform hands-on auditing for objects of high and critical risk levels

  • Perform hands-on auditing for a handful of systems within each department, or under each administrator

During the hands-on audit, we will work to verify the controls discussed during the interview process. Once a control level for each control type is determined, we will document it. Though types of controls will vary for each object, I have included some common controls to audit in Appendix C, Additional Recommended Audit Practices.

In addition to auditing controls, it is a good idea to assess components of security that the security scanner may not have detected. One of the most common actions performed during the hands-on assessment is to extract and crack account passwords. This can be performed easily using a variety of free extraction and cracking tools, like those already discussed.

Step 6 Hands-on Sampling of Desktop Security

As we have discussed, end-users and their desktops play an important role in the overall security of any organization. End-user desktops can have a large influence over the security of an organization. The problem with desktops is that the sheer number of them normally makes it impossible to perform a hands-on audit of each one. There is also the problem that every department will have a slightly different desktop build, thus making auditing a bit tricky.

Of course, our desktops should have already undergone a vulnerability scan, which should have revealed any immediate threats like back doors or open shares. It is, however, important to take a deeper look into desktops to make sure different individuals and groups are conforming to desktop-related security policies. Most often, the best way to perform a desktop audit is to take a random pool of systems within each department and perform a hands-on assessment. It usually becomes obvious if a particular department or facility is enforcing the desktop security policy after sampling five or six of its computers.

When performing a desktop audit, we look for any required controls as well as a wide variety of security issues that may not have been discovered through the network scan. During the hands-on audit, for example, we may look to see if the antivirus software is up-to-date, it there are active modems, or if the computer contains any unauthorized software. Each organization may have its own unique series of issues to look for with desktops. I have included common desktop auditing practices in Appendix C.

Step 7 Physical Inspection

During the physical inspection process, we look at the different areas in which servers, routers, and other important objects are stored. As we have seen, the risk level of an area is going to be determined by the risk level of the objects within that area. Our risk control policies dictate a minimum level of security control for areas based on a certain level of risk. During the physical audit, we inspect these controls and other information about the room, including the environmental conditions, fire control, power controls, and general organization and well being of systems and cables.

When auditing physical areas, it is best to address all areas that contain major objects such as servers, routers, and switches. A server may sit in someone's office, therefore, the office should be inspected. I have included some common physical auditing practices in Appendix C.

Step 8 Compiling and Scoring Data

After performing the object risk and control assessment and reviewing the security of the environment, we have a good amount of data to work with. I discussed previously how to score objects based on their control violations. Scoring our objects will help to determine where risks are and where controls do not meet the standards.

By mapping out where different risk levels exist and where different vulnerabilities and control violations were found, we will begin to see patterns emerge. It will become easier to determine which objects are more critical to the organization as well as which departments, facilities, and administrators have a higher average number of violations. Reviewing this information and these patterns will provide a stronger sense of the security of the organization.

Step 9 Reporting and Review

Now that the tactical audit has been completed, it is time to create reports and review them with the staff. By listing the scores for individual objects, factoring in some statistical averages, and documenting the findings from hands-on auditing, we will have the information needed to create a strong tactical report. Reports should be reviewed with executives and the heads of different departments, as well as the IT staff. Individuals should agree with the findings, or provide a formal dispute, and a plan should be drafted on how issues will be resolved before the next scheduled audit.

It is vital in this step that the reports are clear, concise, and geared toward the target audience. Technical individuals should receive copies of the individual object scores and vulnerability scans, while managers and senior staff should receive statistical figures and summaries. The key here to is to get everyone to read and understand the report so that corrective actions can be taken.

Tactical Audit Schedule

For the tactical audit process to become part of the three-fold process, it will need to be performed regularly. When I say "regularly," this could vary from organization to organization based on size, resources, and general IT practices. Some portions of the audit process should be repeated more often than others to maintain proactive awareness of new vulnerabilities within the environment. The schedule in Table 8.16 should fit the practices of most environments:

Table 8.16. Sample Audit Schedule

Audit Task

Schedule

Complete tactical audit and review

Once/year

Review to check on progress

6 months after original review

Follow-up vulnerability scanning on servers and desktops

Once every two or three months



Inside the Security Mind(c) Making the Tough Decisions
Inside the Security Mind: Making the Tough Decisions
ISBN: 0131118293
EAN: 2147483647
Year: 2006
Pages: 119
Authors: Kevin Day

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net