Audit Data Sources

Audit sources are inputs that can be used for valuation and analysis, and can be gathered from a multitude of locations. Typical data collection points for audit data sources include:

  • Human resources organization charts

  • Network topology diagrams from the IT department

  • Business process and software development (if applicable) methodology documentation

  • Hardware and software inventory lists from IT or facilities management

  • Conversations/interviews with employees of organization being audited

  • Previous audit reports conducted or third-party assessments of security controls

The auditor should consider the objectivity of the information source. If an interview with a person is used to gather information on organizational security posture, what other information corroborates the information provided? Is there any objective third-party assessment that was previously conducted that can be used to verify the information provided?

Audit Subsystem

The audit subsystem involves more technical expertise that provides low level reporting of security events on the operating system level. Most of this information can be examined through log file analysis.

The audit subsystem consists of five major components:

  1. The Kernel Audit Mechanism

    The kernel audit mechanism is central to the audit subsystem. This mechanism generates audit records based on user process activity through kernel system calls. Each kernel system call has a corresponding entry in a subsystem table that indicates whether the call is security-relevant and, if so, to what event type the system call corresponds. Additionally, a table of error codes further classifies the system calls into specific security events. The kernel audit mechanism makes an internal call to the audit device driver to write a record to the audit trail.

    For example, the open system call is classified as a make object available event. If an user admin performs an open on /admin and it succeeds, an audit record is generated indicating that event. However, if the system call fails because the admin requested write access on the open but does not have write permission on the file, the action is classified as a DAC Denial event for admin with object /admin. Consequently, a system call can map to a number of event types, depending on the object accessed and/or the result of the call. It is possible that a system call might be audited selectively, depending on the event types that you enable.

    Some system calls are not considered relevant to security. For example, getpid retrieves the process ID of a process and does not constitute an event of security relevance. Thus, that system call is never audited.

  2. The Audit Device Driver

    The audit device driver is responsible for:

    • Accepting audit records from the kernel audit mechanism and from trusted utilities.

    • Creating and writing the intermediate audit trail files.

    • Providing audit trail data to the audit daemon for compaction.

    • Providing for selective audit record generation based on event types, user IDs, and group IDs.

    The device driver provides open, close, read, write, and ioctl interfaces, like many other character devices. However, the audit device can only be opened by processes having configaudit or writeaudit privileges. This limits access to the audit device only to trusted utilities such as the audit daemon and the audit administrator interfaces. The audit device can be written to by many processes at the same time. The device handles the merging of the records into the audit trail. The device can only be read by a single process-the audit daemon.

    The audit device driver maintains the audit trail as a set of "audit collection files." Each time auditing is enabled, a new audit session is begun. As the session starts, the subsystem creates a collection file into which audit records are written. When the collection file reaches a certain size, the subsystem creates a new configurable collection file and begins writing to it. The audit trail could, therefore, be viewed as a continuously growing sequential file even though many collection files are used.

  3. The Audit Compaction Daemon

    The audit daemon is a trusted utility that runs as a background daemon process whenever auditing is enabled. The daemon is the sole reader of the audit device, which in turn provides the daemon with blocks of records from the audit collection files. The daemon is not concerned that the audit trail is spread over numerous collection files. The audit device driver satisfies the read requests from the daemon and handles the switching and deletion of collection files as needed.

    The main purpose of the daemon is to provide a compaction and logging mechanism for the audit session. Depending on the audit record generation criteria selected, a large amount of audit data can be generated on the system. For a typical single-user system, it would not be uncommon to generate 200KB of audit data per hour. The daemon provides a compaction mechanism, compressing the audit data into a packed record format that is stored in an audit compaction file. The compaction algorithm provides for an average 60 percent reduction in file space, greatly reducing the disk space used to store audit records.

    A second function of the daemon is to provide a log file describing the current audit session. The log file contains information about the number of audit records available in the compacted file's output for the session, the start and stop times of the session, and other indicators pertaining to the audit session state. Just as the audit device driver opens a new collection file when the current one reaches a specified size, the daemon can create multiple compaction files to avoid growing a single file too large to be manageable. Compaction files written by the daemon may also be located in a variety of administrator-specified directories. For these reasons, the log file is maintained to provide a trail of compaction files that can be used for subsequent data reduction.

    A third function of the audit daemon is to serve as an interface program to the audit device driver for the writing of audit records from protected subsystems that do not have the write audit privilege. Because these subsystems cannot access the audit device driver directly but can interface to the daemon in a trusted manner, the daemon handles the writing of the application audit record to the subsystem.

  4. The Audit Manager Interface

    The audit manager allows the administrator to handle set up and initialization, modify subsystem parameters, maintain the subsystem (backup, restore, and so on), and reduce both general and selective audit data.

  5. The Data Reduction and Analysis Facility

    The audit subsystem also includes a data reduction and analysis facility to examine audit trails from previous audit sessions or from the current audit session. By using the log file produced by the audit daemon, the reduction utility can identify all of the compaction files needed to reduce an audit session. Because the compaction files are in a compressed format, the reduction program contains the necessary routines to uncompress the data.

    To provide effective analysis of audit data, the reduction utility lets the administrator specify certain event types, user IDs, group IDs, and object names to reduce the data selectively. In addition, they can specify a time interval to be applied while searching for records to match the specified criteria. If a record is not within the specified time interval, it is ignored for the purpose of that reduction.

    As an example, the administrator may reduce the data selecting the DAC Denial event with user ID admin looking for the object /admin. Only records that reflect an access attempt to /admin by an administrator that was denied because of lack of permission are printed. This provides a powerful mechanism for identifying security events of immediate interest without having to analyze the entire audit trail.

System Events

System events provide triggers that are captured in the audit trail and used to demonstrate a pattern of activity. The level of detail should be wide enough so that general inferences can be made about host activity and granular enough to investigate further into a particular event. The following are examples of events tracked:

  • Startup and shutdown

  • Log in and log off

  • Object create, delete, and modify

  • Admin/operator actions

  • Resource access denials

  • Resource access approvals

Sampling and Data Extraction

Often, the problem being investigated is such that there is no original data available. In this case, the administrator would have to use collection techniques such as interviews or questionnaires to extract the data from a group of respondents. This is known as collecting primary data. Data sampling allows them to extract specific information from the data set of primary data. This is most often used for the detection of anomalous activity, an area of intrusion detection.

Retention Periods

Retention periods indicate how long media must be kept to comply with regulatory constraints. Retention periods vary from industry to industry, government to government, and state to state. An example of an industry-specific retention period for healthcare is outlined in the HIPAA. The retention rate of HIPAA ranges between five and six years, depending on the data in question and what organization is responsible for retaining the information.

Note 

A common method used to audit data retention periods is to tabulate a list of all data storage and backup mechanisms, and verify that all categories of data, full or partial backups, and other relevant information exist for the time periods specified in the retention policy.

Audit Trails

An audit trail is the term associated to the group of logs and relevant information that make up the set of evidence related to a particular activity. For every action taken on an information system, there should be a relevant log entry containing information about the name of the system, the name of the user (or user ID), what action was taken, and the result of that action.

Audit Trail Integrity

One of the most difficult aspects of establishing an audit trail is ensuring the integrity of the information that was collected, especially if the audit trail will be used for legal purposes.

Some considerations with respect to the audit trail are as follows:

  • What is the value of the information being protected?

  • What events will be tracked?

  • Will every successful activity be logged?

  • Will unsuccessful attempts be logged?

  • What if logs contain too much information that is irrelevant or immaterial?

  • How will distributed systems keep their time synchronized so events can be correlated across systems with a reasonable assurance of reliability?

  • What measures will protect the audit trail from accidental or malicious modification and/or destruction?

Audit trail integrity is crucial to event reconstruction of a security incident. If an audit trail cannot be reconstructed with certainty the conclusions drawn from the audit data could be subject to debate and could be rendered ineffective. It is important to protect the audit trail from unauthorized access and tampering to maintain integrity. Use of a CLF to maintain disparate system logs is recommended. Procedures that immediately send system logs to the CLF protect against log tampering and corruption, and can be used to detect log file alteration through comparison.

start sidebar
Damage & Defense…
Log Tampering

It is safe to say that systems administrators do not want unauthorized users viewing their log files, and certainly do not want log files modified by unauthorized users. If log files are discovered by an attacker, they provide an excellent source of a system's operating information. A common practice used to hide a breach in security is to turn logging off immediately after gaining unauthorized access. After the attacker completes the activities that were unauthorized, logging is turned back on and unless the proper controls are in place, the breach could go unnoticed. A good defense to protect against log file tampering is to provide a layered approach to security. A combination of controls provides a greater level of security than relying on one particular control. To protect against log file tampering a combination of preventative, detective, corrective, directive, and recovery controls is ideal.

To prevent unauthorized access from occurring in the first place, strong authentication controls should be used. Users must provide credentials based on something they are (for example, biometric identification), something they possess (for example, a cardkey or other token), and/or something they know (for example, a password) to gain access. The use of strong passwords is a relatively inexpensive approach to increasing security that can provide immediate gains but does not go far enough. Ideally, a combination of authentication controls that are complementary and redundant should be used to improve security. Each of these security aspects can be part of an audit. An item on the list of audit criteria could be, "Are strong authentication mechanisms used for each access mechanism to company information systems and related resources?." In the case of a server that requires both password and biometric authentication, the answer to that question is yes, and this server would have passed the audit of that criteria.

In the example of a remote network administrator connecting to an organization's network over a Virtual Private Network (VPN) tunnel, there is a reasonable protection from casual viewing of data passing in the clear over the Internet since the VPN tunnel can encrypt all data passing through it. In addition, if the administrator is using a Secure Shell (SSH) client, there is further assurance that transmission is encrypted from host-to-host and end-to-end and that encryption does not end at the VPN tunnel endpoints. Furthermore, if antiviral software is being used and signature files are up to date, there is greater assurance that a Trojan horse program will not be passed through the encrypted tunnels. These technical controls mesh together to provide layered security that significantly increases the attacker's level of difficulty to compromise data.

Unauthorized access should be detected and reported so appropriate reactive controls and countermeasures can be deployed. An auditing system that tracks and logs access can use detective controls to report policy violations (attempted intrusions) to appropriate personnel, so that actions can be taken to minimize damage. This is typically more expensive than preventative controls because humans must ultimately act upon information provided by detective control. An Intrusion Detection System (IDS) alert can be generated to let the operations staff know that suspicious activity is under way so that a real-time response to the activity can be initiated to mitigate potential damage.

end sidebar

Checklist Audits

Checklist audits can be fairly straightforward. Standard audit questions are organized into a template that can be used for a wide variety of organizations. A checklist audit provides a baseline understanding of the major audit functions in place. The downside of using a checklist audit is that the auditor may rely on the questions more than their own powers of observation or knowledge of a particular system or process. If an auditor relies on the checklist too much and does not perform his or her own verification of related details based on observations unique to the environment, a major security flaw could go unnoticed. The same is true of software tools that automate the audit process and/or check for security vulnerabilities.

In Exercise 4.01 we have created a sample physical security checklist audit.

Exercise 4.01: Security Checklist Audit

start example

In this exercise you will learn how to create a security checklist audit. As you will see, it provides a list of questions and provides the associated risk context. Using a risk-based approach to audit is critical to the materiality, or importance, of the resulting report.

An additional key differentiator for security checklist audits is the "level of implementation" for each control ranging from "in use, installed in production" to "not purchased, no plans to purchase." This indicator is valuable because it distinguishes organizations that may list controls on the questionnaire, but how they are used in practice is not apparent. An organization with a more mature security infrastructure is expected to be aware of information security policies, procedures, and guidelines and has controls implemented in production to mitigate the risks that are most material to that environment. For instance, if an IDS has been purchased and installed to protect highly sensitive information but is not tested, its usefulness may be in question if it has never been tuned to reduce the number of false positives or "noise."

The resulting report presented to management should categorize the risks found as high, medium, or low and provide a course of action to address audit findings and mitigate risk. The following list provides a sample security audit checklist. Remember, the answers to these questions are often yes or no. There is no qualitative measurement of the effectiveness of these controls in this audit.

Administrative Controls

Is there a documented security policy outlining roles and responsibilities?

Are there documented procedures outlining how records are received, processed, and stored?

Are document classification procedures made readily available to employees?

Do access controls policies exist that limit access to information on a "need to know" basis?

Does the company regularly conduct external or internal audits to verify security posture?

If a SAS-70 security audit has been conducted, is it Level 1?

Do audit results indicate the level of implementation for each controls (for example, production implemented, not implemented but purchased, under consideration, planned, not planned, or not applicable)?

Are security incident handling and response procedures in place?

Do security management processes exist that include prevention, detection, and containment of security breaches and clearly identifies sanctions associated with breaches?

Does the company conduct information security awareness and security policy awareness training for employees?

Does security education and training occur on a regularly scheduled basis?

Does the security policy outline termination procedures?

If so, does the procedure include the changing of locks and removal of keys or tokens that provide access?

Are employees required to turn in their badges/swipecards upon termination?

Physical Controls

Do you have personnel specifically assigned to enhance and enforce information security policies?

Do you have physical access controls that track entry into and out of the facilities? If so, is it based on sign in with a guard, a swipe card, biometric identification, or other?

Do physical access controls remain intact in a disaster recovery scenario?

Are maintenance personnel included in the access control list?

Do you have acceptable workstation use policies and procedures?

Do you have procedures for management and destruction of media?

Technical Controls

Do you employ access controls using role-based access control or user-based access control?

Are your access controls considered mandatory or discretionary?

What assurance can be provided that data in transit or at rest has not been altered or subject to manipulation by unauthorized users?

What authentication mechanisms are in use at your facility? Do you employ the use of tokens, certificates, or biometrics for authentication?

Does transmission of information provide non-repudiation controls so a recipient cannot claim later that they did not receive the transmission?

Is encryption in use? If so, what level of encryption and are the algorithms publicly known and tested?

Are firewalls in use? If so, is a DMZ configuration in use or is one layer of firewall used?

Does your organization use antivirus software? If so, how often are signature files updated?

end example

Penetration Testing

Penetration testing is a proactive measure designed to increase an organization's security posture by testing security controls via a simulation of actions that can be taken by real attackers. The benefits of performing penetration tests must be weighed against the exposure created by the test. Ideally, the benefit of performing penetration testing is that a company will discover security flaws that were not previously known and will have an opportunity to address and correct those points of exposure to improve their security posture.

A penetration test can be classified as an active security audit. When preparing for a penetration test, a list of attacks that will take place has to be generated. This list of attacks can be likened to an audit checklist. For each item on the list, there will be a pass or fail result to the test.

Penetration test procedures are very similar to the audit process itself and must included well-documented procedures to ensure consistency. This differs greatly from an irresponsible Internet user who tries a security tool out of legitimate curiosity or malice but has little or no regard for the consequences to the end system. A responsible penetration test requires careful coordination and planning to minimize the likelihood of negative impact to an organization.

Following are a list of actions and activities related to the penetration test. Not all of these are required, but by considering them all one can gain a greater understanding of the issues involved in this area.

  • Establish security roles and responsibilities for the penetration test. Clearly define team members who are authorized to perform penetration tests in order to protect against the possibility of unqualified personnel running potentially destructive tools and/or exploits without a full understanding of potential impacts to business. Many employees today are curious about the hacking tools available, but are not aware of the danger of running them. Organization policy should make it clear that only authorized personnel are allowed to run any hacking software or penetration analysis test software.

  • Submit and track penetration test items through an automated tool that is capable of engaging responsible parties. If an automated tool is not used, there is greater potential for mishap in scheduling resources and generating reminders of scheduled penetration test items.

  • Engage business owners. Business owners are often responsible for income generation and must be notified in advance of any possible disruption in service that could result in monetary loss, loss of access to resources, loss of reputation, and so on.

  • Review the scope with the legal and audit departments. The nature of a penetration test is designed to discover weaknesses and then correct them. The technical nature of the test may inadvertently provide inappropriate access to data that is considered highly sensitive and could create legal exposure. The legal and audit departments must consider the ramifications of a penetration test that produces expected results and what litigation could result.

  • Obtain the approval of both the legal and auditing departments. Once the scope has been reviewed, it must be signed off on.

  • Determine the tool requirements. Choose a penetration tool that most appropriately addresses the scope and goal of the penetration test. If the target acquired for a penetration test is a Web server, then tools specific to Web testing should be selected. The administrator may be able to accomplish the goals of the penetration test with a significant discount of the tool costs by using shareware tools. If shareware tools do not accomplish the goal, purchase an off-the-shelf package to perform penetration test. Many of these tools have excellent features but are not updated frequently or support is questionable. Using off-the-shelf software with support licensing included ensures that throughout the year, the tool will be supported and can be relied upon.

  • If a shareware tool is used, ensure that the tool goes through rigorous quality control testing before use, so it works as expected. The security team responsible for performing the penetration test may be more concerned with running the tests than the quality of the product. The time it takes to test each incremental update may seem like an excessive use of time but Total Quality Control (TQC) metrics and testing ensure that the data results are reliable.

  • Check for the latest stable version of exploit signatures associated with the chosen tool. Ensure that the signature updates for the penetration testing tools have gone through a rigorous quality control test before use.

  • Determine the time of least impact to business owners and schedule resources required to perform the test. Many organizational units need to work in concert to perform a successful penetration test, and it is possible that predictable yearly, monthly, or other work cycles can be used to determine the best penetration test time with the least impact to the business.

  • Execute testing while ensuring that adequate monitoring of the resources being tested exist so that any issues that arise through the penetration test can be detected and addressed.

  • Document the findings based on a risk-based approach. The findings will typically end up in the hands of senior management, so the report should be in an executive format. The report should contain brief, high-level descriptions that are concise and highlight the material risks found and what corrective action is recommended.

  • Review the findings with key personnel. At a minimum, the report should be viewed by "another set of eyes" for accuracy and clear, concise communication. It is possible for the individual who is conducting the test to become too close to the action and therefore miss poorly worded report sections that should be rephrased to avoid misunderstanding. Before a report is sent to internal senior management (if internal auditors are preparing the report) or to external senior management (if a consultant), coworkers or peers should review the findings first to save the embarrassment of a major misstatement of fact or other easily avoidable errors.

  • Address vulnerabilities. The whole purpose of running the penetration test from an audit perspective is to find vulnerabilities and then fix them. The security patches recommended by an automated software tool must be compared against the operations department support standard. An unfixed security exploit creates exposure, but software upgrades and patches can create interoperability issues that prevent a system from operating with the rest of the network hosts.

  • Retest. The retest should demonstrate that any vulnerability previously found is now addressed.

Many applications exist to perform penetration testing and vulnerability profiling. Some common tools are Nessus, AppScan, Internet Scanner, CyberCop, and NetSonar. Figure 4.1 shows a list of items that are checked by AppScan.

click to expand
Figure 4.1: The AppScan Test Progress Screen

Upon completing a vulnerability scan or penetration test using an automated testing tool, a listing of the vulnerabilities that were found will be available. Along with this list, there will often be links and/or information related to the patches or alternate methods of addressing the vulnerabilities.

Figure 4.2 shows an example of the exploits that have been discovered during a scan.

click to expand
Figure 4.2: AppScan Vulnerability Discovery Report

Patches should be applied as per change control policies. Once patching is complete, rerunning the vulnerability scanner or penetration-testing tool can provide evidence that the vulnerability is no longer a risk.

start sidebar
Head of the Class…
The Best Laid Plans…

A well-planned penetration test can still produce unpredictable results. There have been many situations where organizations with well-established penetration testing programs still encountered unexpected results. Servers crashed, services were made unavailable, and users were unable to perform their job functions. Preventative controls were carefully planned, but downtime, although negligible, was still experienced.

In one case, processes were well documented and the required approval of parties that would be directly or indirectly affected in the event of a problem were obtained. The operational support resources, business owners, and penetration test specialists were contacted weeks ahead of the planned test and provided written authorization to conduct the tests. The test was planned during non-business hours and schedules were coordinated in advance. In short, the plan appeared to be in order. The penetration test did provide valuable information on a security weakness that could potentially be exploited. Unfortunately, the test actually "crashed" some of the systems that were being tested and the recovery time took longer than expected. Although senior management was aware of the program, the incident had to be explained in great detail and the value of the program was questioned. Unfortunately, valuable operational procedures that are performed regularly with great success the majority of the time may go unnoticed until something goes wrong (for example, tape backup failure).

Corrective controls to address the issue included extensive testing of the penetration test tools to make sure they worked as expected under a wide variety of circumstances. This included actually testing penetration test signature updates so features described as non-intrusive behaved as labeled. Bottom line: the rewards, risks, and scope of penetration testing must be clearly understood and endorsed by senior management to ensure long-term program success. In addition, any tools and signature updates used for penetration testing must be thoroughly tested on a continual basis to reduce the likelihood of future unexpected errors.

end sidebar

Wardialing

A wardialer is a program that automatically dials a preprogrammed series of telephone numbers looking for modems set to automatically answer. In addition to just dialing and looking for modems, upon finding a modem in auto-answer mode, some programs attempt to pass a set of common user IDs and passwords to the computer with the modem attached. This process can be used to gain unauthorized access to the computer. Each successful connection is logged into a database to make it easier to go back and visit compromised systems. Some war-dialers do not automatically perform penetration testing, but do allow the intruder to manually enter user IDs and passwords to gain access.

This probably seems very useful from an attackers perspective, but let us consider this from an auditor's perspective. In order to audit for the existence of modems in auto-answer mode, a wardialer is a perfect tool. Automatically doing tests for common user IDs and passwords will save time manually performing the same functions.

Most wardialers are available as freeware, but commercial versions are also available. Most commercial wardialers are called modem scanners. These products offer technical support and are typically used by organizations whose policies require that commercial support be available for all software packages in use within the organization.

In Exercise 4.02, you will be using a free, publicly available wardialer to audit a fictitious range of telephone numbers. This exercise will demonstrate how a wardialer program can automate a mundane time-consuming task in a very effective manner.

Note 

When downloading any files from the Internet, especially from sources that are not under direct control by a trusted party, make sure that all files are scanned by an antivirus software application before using or executing them.

Exercise 4.02: Using a Wardialer

start example

You will be using the Dialing Demon v1.05 which can be downloaded from http://neworder.box.sk/codebox.links.php?&key=wardil. The name of the file to download is DEMON105.exe

  1. Running the DEMON105.exe file from within a DOS window will present you with the screen showed in Figure 4.3.

    click to expand
    Figure 4.3: The Dialing Demon Splash Screen

  2. Pressing Enter at this screen walks you through a series of configuration questions to determine the COM port that your modem is on, its speed, and a few other options. A basic configuration is shown in Figure 4.4. The values used in this configuration will vary depending on your system's modem configuration and personal preferences.

    click to expand
    Figure 4.4: The Dialing Demon Configuration Screen

  3. After the application has your basic configuration information, you will be prompted for the dialing configuration you wish to use. This includes the dialing prefix and range of numbers you wish to dial. The range you use here should correlate with the phone numbers you wish to scan. Figure 4.5 shows an example configuration.

    click to expand
    Figure 4.5: The Dialing Demon Number Range Configuration Screen

  4. As seen in Figure 4.5, dialing a large range like this can take a very long time. Normally it is best to do only a small range at a time and span it over a number of days. After answering Y to the "Begin dialing sequence?" question, the dialer begins dialing every number in the range and creates a report showing which numbers have modems connected.

end example

A more recent variant on wardialing is wardriving. The targets in this case are wireless local area networks (LANs). Several security articles describe this exploit as basically driving around with a wireless network interface card (NIC) installed in a laptop to see what wireless network access points can be found. However, to truly optimize the search, they may need to extend their range with an extra antenna. This concept can apply to auditing for the existence of any unauthorized wireless networks in a company or organization.

The first defense against wardialing is to only connect the modem when it is needed. A system that only needs to have someone dial-in once a month should not have a modem in autoanswer mode on every day. Unfortunately, regulating this requires a human to turn the modem on and off based on a schedule, which is not feasible for many organizations. As such, authentication becomes more important instead. If incoming connections can be limited to a predefined range, this reduces the possibility that an unauthorized user will be allowed to connect to the host system. In addition, if the dial-up connection requires a call back, this also ensures that the host will dial out to an authorized connection since the call was initiated locally. Once connectivity is established, a strong user ID and password combination challenge and response can be further enhanced with an additional authorization key (such as a hardware token or digital certificate) to provide further assurance that the connection requestor is a legitimate user.

start sidebar
Head of the Class…
War Chalking

Another variation on war driving is called war chalking. War chalking is the practice of marking a series of symbols on sidewalks and walls to indicate nearby wireless access points (APs). In particular, public restrooms within the range of corporate wireless APs have become targets for war chalking. Where else can you sit down for a few minutes undisturbed in privacy to conduct a search for nearby unsecured access points? This practice, which has increased in popularity in New York City, is not appreciated by both the proprietors and law enforcement. The defense against wardriving and war chalking is to increase the controls that reduce the likelihood of a casual wireless network sniffing. The book Hack Proofing Your Wireless Networks (Syngress Publishing, ISBN: 1-928994-59-8) provides much more information and detail about wireless network security.

end sidebar

Social Engineering

In order to audit some aspects of policy, especially those that deal with individual user activities and their respective responses to situations, social engineering can offer an interesting perspective.

Social engineering is the art of gaining unauthorized access to information by exploiting the human trait to trust others. To perform a social engineering attack, an attacker will usually pose as someone who is authorized to access the data in question, being as the human element is often considered the weakest link in the security chain. A common ploy to turn over credentials to the attacker typically involves an "urgent issue that must be resolved immediately." If the attacker has gathered enough information to pose over the phone as a member of technical support or senior management, the average worker may not feel comfortable denying the request for access or information. Social engineering preys on the kindness and helpfulness of people who unknowingly help an attacker into the network. Sometimes the information gathered which seems innocuous, can be used as reconnaissance information for an attacker to build a profile of the organization before actually launching the attack. Excellent technology exists to provide identification, authentication, authorization, encryption, privacy, and other security elements but human beings must be comfortable with using the interface that provides these security services. For example, if strong passwords are in effect and an employee is persuaded to turn over their credentials to someone posing as a network systems administrator over the phone, then the security control has been defeated, no matter how well it was designed.

Properly structuring social engineering as part of an audit can be a very arduous task. During the test, an authorized person will be actively violating policy by asking a user for authentication information. Allowing this is a question for management, as one must also consider the user's reactions to learning that they were part of such a test. They may consider it a violation of their privacy and or integrity. One important note with respect to social engineering is that the inherent activities will only test a small sample of the total population of users. It is not statistically feasible to collect enough information in most situations to impact an impartial audit of an overall system. Social engineering can, however, identify that there is a requirement for training and education of users.

The type of control that is best associated to preventing social engineering from being effective is preventative control. The most common preventative control in this situation is in the form of training. Employees that are trained on the importance of security and the potential for social engineering scams are more likely to recognize a scam when they encounter one.

start sidebar
Notes from the Underground…
Social Engineering

A colleague of mine was asked to perform a security audit for a client in a major U.S. city who was in the process of changing their business model. He relayed the following social engineering attack story. This non-profit organization was considering offering online wire transfers as part of its service, and wanted assurance that their current HSP was up to the task of properly protecting the associated financial data. With only the HSP name to start with, the review was on, starting with physical security. My colleague was able to find the company sales contact on the HSP Internet Web site. A local visit to the office indicated that this was really a small shop located in an industrial park with standard physical security for an office building but not for an HSP. The receptionist at the front door greeted my colleague, and after a quick hello, my friend indicated that he was picking up a sales representative for lunch, and not to bother calling him because he was going down the hallway to meet him. The receptionist let my colleague through and he checked the server room door on his way down the hall. The server room door was propped open because an air conditioning unit happened to be under repair that day. This HSP failed a simple test of physical security by propping open the door, and social engineering by letting a previously unknown person walk right into the office. The security report findings were reported to the HSP, who promptly initiated actions to correct their security issues. Even so, the client chose an alternate HSP with more robust security and redundancy features.

end sidebar



SSCP Systems Security Certified Practitioner Study Guide
SSCP Study Guide and DVD Training System
ISBN: 1931836809
EAN: 2147483647
Year: 2003
Pages: 135

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