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:
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.
Audit ToolsIt 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.
Basic Audit StepsAgain, 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:
Step 1 Audit PreparationBefore beginning the audit process, there are a couple of basic tasks that need to be completed:
Step 2 Object DiscoveryBefore 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.
Step 3 Risk AssessmentNow 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.
Step 4 Vulnerability ScanningNow 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:
Step 5 Hands-on AuditThe 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:
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.
Step 6 Hands-on Sampling of Desktop SecurityAs 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 InspectionDuring 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 DataAfter 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 ReviewNow 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 ScheduleFor 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:
|