Patent Application
20080072321
The invention comprises the following components:
An intrusion detection management component (28), administrator interface component (32), and sensors (20, 22) represent the typical components of an intrusion detection system.
Prior to the start of a simulation run, it is necessary for the system to obtain a set of one or more intrusion scenarios, and have configured in its database parameters describing the local network topology. The intrusion scenarios could be obtained from a security service provider, or be developed by an intrusion simulation analyst.
If the scenarios are to be obtained from a security service provider, the organization running the system for automating network intrusion training obtains the intrusion scenarios and updates through the update receiver (12). The update receiver may at intervals poll the security service provider to check if there are recent updates, or the security service provider may send updates to each organization that is participating in the service. In order to allow the analysts to vet potential attack scenarios, for example to confirm that they are likely attacks to be encountered on their network, and that the intrusion simulation will not consume excessive resources, the intrusion scenarios are specified in a high-level specialized data description language.
The scenario is described through a specification that includes a set of parameters. Each parameter of a scenario indicates an element of data required from the local database to be used in the simulation, in order to make the simulation appear realistic. (For example, an intrusion involving a compromise of a Microsoft Windows 2000 domain controller system would only appear accurate if the sensor reporting the attack was monitoring such a system).
The specification of an intrusion scenario comprises four sections: a preamble, a resource list, a network event list, and a response list. For transfer between organizations, the specification of an intrusion scenario could be encoded into a text file using an Extensible Markup Language (XML) syntax and schema.
The preamble section specifies:
The resource list section comprises a set of resource descriptors. Each descriptor specifies a particular kind or role of a system (e.g., a Windows 2000 domain controller). The intrusion simulation analysis component will assign to each resource a system in the network being managed that has a compatible kind or role of system.
The network event list section comprises an ordered list of network events which will be simulated by the sensors involved in performing the simulation. Each event specifies:
The response list section comprises an ordered list of activities in the intrusion detection management and intrusion detection administrator interfaces. It will specify the sensors and resource systems which the administrators will be expected to evaluate in order to determine whether this was an actual or simulated attack.
The intrusion simulation analysis component (26) is responsible for updating the database (18) with the topology of sensors and resources on the network. The intrusion simulation analyst, through the analyst interface (30), may further characterize or exclude sensors. The characterization may involve adding descriptive parameters for the resources monitored by the sensors that will allow these resources to be matched with the resource descriptions in the intrusion scenario. For example, the analyst may identify a particular resource as a Microsoft Windows domain controller, so that an intrusion scenario that relies on communication with a Microsoft Windows domain controller may be tailored for the organization. Also, not all sensors are appropriate for use in a simulated attack, and thus some may be excluded. For example, the analyst may wish to exclude sensors monitoring systems which hold high-value data that would set off too many alarms if it appeared to be involved in an intrusion attempt. Also, the analyst may filter the set of potential intrusion scenarios obtained from the intrusion scenario database. In particular, those scenarios which are not applicable to the organization running the simulation or are not appropriate to the administrators being trained, can be removed.
Once the system has been configured, the simulation coordinator (24) will begin the scheduling thread of execution, as described in the flowchart of
The scheduling thread within the simulation coordinator will then contact the intrusion detection management component (28) to determine whether there is a current intrusion activity in progress (40). If so, the thread will wait until later, in order to avoid delaying an actual investigation (42). The scheduling thread will select an intrusion scenario from the database (44), and determine if it is suitable for the deployment as currently configured (46). If it is appropriate, then the scheduling thread will start the processing thread within the simulation coordinator (48).
The processing thread within the simulation coordinator is illustrated by the flowchart of
Once the start command has been sent, the processing thread will notify the intrusion detection management and intrusion simulation analysis components that a simulation has started (62), and then wait until the anticipated end of the simulation, after all the simulated traffic notifications have been sent (64).
A sensor will include an additional generation thread, as illustrated in the flowchart in
The intrusion detection management component will register when the administrators have started investigation of a potential intrusion, and track the sensors whose data the administrators monitor. Subsequent to a simulated intrusion, the intrusion simulation analysis component will fetch this information from the intrusion detection management component.
Based on this, the intrusion simulation analysis component will be able to determine whether the administrators took action in response to a simulated attack.
The resulting information of the administrator interactions with the intrusion detection system may be compared with the anticipated actions that are included in the simulated intrusion scenarios. If the administrators analyzing the output of the intrusion detection system ignore a high potential simulation attack, this may indicate a failure in the reporting or interpretation of the intrusion detection system's output. (For example, such a failure may be as simple as the email address for an administrator to which the intrusion detection system is reporting attacks is no longer active). If the administrators used incorrect methods for investigating the attack, and did not examine the correct resources, the system can suggest the recommended methods.
An alternative implementation, the intrusion simulation analysis component (26) could provide the network parameters developed by the intrusion simulation analyst to an external security service provider (10), and as a result the update receiver (12) would only receive scenarios that are appropriate to the organization, and that are already appropriately configured.
As an alternative implementation, the checks performed by the simulation coordinator component prior to starting a simulation could be removed or modified to allow certain simulations to running concurrently with other simulations or investigations in progress for non-simulated intrusions, as it will more realistically simulate Internet behavior, in which there may be multiple simultaneous coordinated or uncoordinated attacks.
Many different embodiments of this invention may be constructed without departing from the scope of this invention. While this invention is described with reference to various implementations and exploitations, and in particular with respect to intrusion detection systems, it will be understood that these embodiments are illustrative and that the scope of the invention is not limited to them.
