Patent Description:
Intrusion detection systems (IDS) are used to monitor network activities for attackers. Reports are generated and alerts signalled to the owner or manager of the specific network. An intrusion detection system that responds to an attack, for example by blocking traffic using a firewall, may be referred to as an intrusion prevention system (IPS) or an intrusion detection and prevention system (IDPS). In some implementations, attacker traffic is detected by and/or routed to one or more honeypots.

Honeypots are network decoys that attract attackers with the aim of distracting the attackers from more valuable production machines on a network. Honeypots are often deployed within a network using unallocated addresses, and providing services and/or data to engage attackers. Because a honeypot has no production value and typically sits at an unallocated address, every attempt to contact a honeypot is suspect. This means that honeypots can be used to identify attacks, and consequently honeypots also enable the gathering of information about attacker behaviour and attacker identification while an attacker is exploiting a honeypot. Attackers, in turn, try to avoid honeypots by looking at behaviour (such as the services provided) to assess the likelihood of a target in a network being a honeypot.

Physical honeypots are real machines with their own IP addresses, and are therefore expensive to implement. Virtual honeypots, on the other hand, require fewer physical machines thereby reducing the cost. The operating system and services provided by a honeypot are configured according to the activity on the network and the intended purpose of the particular honeypot at that time. Because it is challenging, complex and time consuming to configure honeypots, dynamic virtual honeypots are used to automate configuration processes. Dynamic honeypots are able to discover the network (e.g. by fingerprinting), decide what honeypot configuration to use and then create and configure the honeypots.

Multiple honeypots can be combined to form a "honeynet" - a decoy network set up with intentional vulnerabilities. As with individual honeypots, the honeynet enables the owner/manager to observe and analyse an attacker's activities and use the gleaned information to strengthen the system's security mechanisms.

Background material relating in general to the technical field can be found in <CIT>, <CIT>, <CIT>, <CIT> <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT> and <CIT>.

<CIT> describes a method involving monitoring behavior of at least one node, associated with at least one user, in a network to generate a behavior profile for the user(s).

<CIT> describes a system for analysing network traffic, particularly to detect suspect packets and identify attacks or potential attacks.

<CIT> describes monitoring of malicious network traffic attaches to unused addresses and monitoring communications with an active responder that has constrained-state awareness.

According to an aspect, there is provided a method according to claim <NUM>. Further features according to embodiments are set out in the dependent claims.

With every new attacker or modified attacker behaviour, an IDPS will monitor attacker behaviour, update the logged data regarding the attacker, and also update a response strategy. For example, a certain attacker profile may result in a virtual honeypot being created for that attacker. The process is repeated for each new attacker, and may also be repeated if the attacker's behaviour or some aspect of the profile changes. This is a complex and time consuming process. It would be advantageous to have a simplified process of responding and updating a response to a detected attacker. By simplifying the process, security measures can be deployed more swiftly and in a more efficient manner. Moreover, there is a need for improved communications and transfer of data in respect of intruder detection systems. Such improvements would give rise to more effective protection systems which are better equipped to detect, prevent and respond to attacks.

Various aspects and embodiments of the invention provide such an improved security solution, resulting in enhanced protection for computer-based devices and networks, and also the data which is stored thereon. The invention may provide a reactive and pre-emptive security system. The system may be based on choice theory. It may be arranged for the protection of computing devices, networks and their associated data.

Embodiments of the disclosure are now described by way of example with reference to the accompanying drawings in which:-.

In the drawings, like reference numerals designate similar parts.

When a computer system or network is attacked, a typical response is to block the attack using a firewall, or in some instances to connect the attacker to a honeypot. The details of these attacks are not shared with other parties, so that every attack that is performed is handled independently. No information is shared with other groups, and this lack of sharing makes it simple and economical for attackers to implement the same attack strategy across multiple networks in order to find a vulnerable target.

Thus, there is a need for an improved security solution which provides enhanced protection for computer-based devices and networks, and also the data which is stored thereon.

<FIG> shows an intrusion detection and protection system (IDPS) <NUM> that addresses this shortcoming by providing a centralised database <NUM>, managed by a data manager <NUM>. Multiple users <NUM>, <NUM>, <NUM> communicate with the data manager <NUM>, for example via a network <NUM>. The centralised database <NUM> provides information, such as attacker signatures, to the individual systems of users <NUM>, <NUM>, <NUM> that are thereby able to match traffic on their networks with attacker profiles. Implementing a shared database with mutually beneficial information enables the subscribing users <NUM>, <NUM>, <NUM> to not only identify and respond to a current attacker, but also to effectively inoculate themselves against potential attackers based on data gathered by the other users.

The data manager <NUM> may be a single computing device, or may be computing network that includes multiple computing devices or processors to allow for distributed computing, grid computing or cloud computing.

The database <NUM> is shown in <FIG> as being connected to the data manager <NUM> via a communication link. However, the database <NUM> may be part of the data manager <NUM> to reduce data process time. In other examples, the database <NUM> may be connected to the data manager <NUM> via the communication network <NUM> without departing from the scope of the present disclosure.

The centralised database <NUM> operates according to a database management system (DBMS) running on the database <NUM>. The DBMS may include Microsoft SQL, Oracle, Sybase, IBM DB2, MySQL, or Orient DB. The centralised database <NUM> may include multiple sub-databases that operate based on different DBMSes.

The communication network <NUM> is typically a wide area network (WAN), and may be implemented using any suitable type of network, such as a wireline network, a cellular communication network, a wireless local area network (WLAN), an optical communication network, etc. The communication network <NUM> may be a combination of the suitable networks, for example, the Internet. The communication network <NUM> can also be a private communication network that is built specifically for the IDPS <NUM>.

<FIG> illustrates an example computer system <NUM> for data management according to the present disclosure. The computer system <NUM> represents an example structure of the data manager104 described above.

The computer system <NUM> includes a storage device <NUM>, a memory device <NUM>, a communication interface <NUM>, and a processor <NUM>. The computer <NUM> further includes a bus <NUM> that connects the storage device <NUM>, the memory device <NUM>, the communication interface <NUM>, and the processor <NUM>.

The storage device <NUM> is configured to store traffic data, the traffic data including normal user and attacker traffic data received from multiple users. Although the storage device <NUM> is shown as part of the computer system <NUM>, the storage device <NUM> may be a separate entity that is connected to the computer system <NUM>, for example, the centralised database <NUM> shown in <FIG>.

The memory device <NUM> is configured to store instructions in relation to the operation of the data manager <NUM>, as described elsewhere herein with reference to <FIG> and <FIG>. These instructions are implemented as machine-readable instructions included in a computer software program, when executed by the processor <NUM>, causes the processor <NUM> to perform these methods of operating and using an IDPS.

The communication interface <NUM> is configured to connect to a communication network, particularly, the communication network <NUM> as shown in <FIG>, via the link between the computer system <NUM> and the communication network <NUM>.

The processor <NUM> is connected to the memory device <NUM>, the storage device <NUM>, and the communication interface <NUM>. The processor <NUM> is configured to obtain the instructions from the memory device <NUM> in operating and using an IDPS.

In the example shown in <FIG>, the storage device <NUM>, the memory device <NUM> and the processor <NUM> are configured to operate according to a computer operating system, for example, Windows Server, Mac OS X Server, Linux, Unix, Windows, and Mac OS.

The processor <NUM> may be a general purpose Central Processing Unit (CPU), and the instructions stored in the memory device <NUM> are defined by one or more of the following programming languages: HyperText Markup Language (HTML), HTML5, JavaScript, and JQuery. The instructions may also be defined by one or more of the following programming languages: JAVA, Python, and PHP. The instructions may also be defined by one or more of the following programming languages: Objective-C, C++, C, and Swift.

<FIG> shows an example of a computer network <NUM> that uses an IDPS service as described above with reference to <FIG>. In this example, user requests received from a network <NUM> pass via a server protection system (SPS) <NUM> to the computer network <NUM> where a real server <NUM> provides access to a production database <NUM>. Of course many different types of networks offering different types of services can make use of an SPS in communication with an IDPS.

The SPS <NUM> may be implemented on a computer system like the example computer system <NUM> described above with reference to <FIG>. The memory device <NUM> is then configured to store instructions in relation to the operation of the SPS <NUM>. These instructions are implemented as machine-readable instructions included in a computer software program, when executed by the processor <NUM>, causes the processor <NUM> to implement the SPS <NUM> as described below.

The SPS <NUM> has access to information from the centralised database <NUM>. As indicated in <FIG>, the centralised database <NUM> is updated using data from a community of users <NUM> as described above. The traffic pattern data from the database <NUM> is used by the SPS <NUM> to determine whether user requests received are from normal users or from attackers. If a user request is from an attacker, then the SPS <NUM> generates a virtual honeypot <NUM> and a transformed database <NUM>, and directs the attacker to this honeypot <NUM> and a false database <NUM> that appears to be real.

Where more than one attacker is identified, more than one honeypot <NUM>, <NUM> and respective transformed database <NUM>, <NUM> may be generated. The parameters used to create and/or configure the honeypots may be determined locally by the SPS, based on attacker information received from the database <NUM>. Alternatively or additionally honeypot parameters may be obtained from the database <NUM> together with the other attacker profile data.

The SPS <NUM> may communicate directly with the database <NUM> in order to retrieve information as required, as shown in the example illustrated in <FIG>. In the example shown in <FIG> (described in more detail elsewhere herein), communication between the database <NUM> and the SPS <NUM> is via the data manager <NUM>, and the data manager <NUM> manages the content and format in which information is provided to the SPS <NUM>. One way of managing the services provided to the SPS <NUM> is according to a subscription service profile that the subscribing user (SPS owner) is associated with.

<FIG> is a flow diagram describing an example of a method <NUM> for providing an IDPS as shown in <FIG>. At step <NUM> the data manager <NUM> receives a connection request from an authorised user, for example a subscribing SPS that is identified and authorised when the connection is made.

The data manager <NUM> manages the centralised database <NUM> by providing a number of services that include:.

At step <NUM>, the data manager <NUM> determines whether the connection request from the authorised user relates to a request for traffic profile data <NUM>, or whether traffic data is being provided for processing and logging <NUM>.

At step <NUM> raw traffic data <NUM> is received by the data manager <NUM>. This raw data may be logged as is, but this data is also processed to determine a number of things.

Firstly, the data is analysed in order to classify the traffic as relating to normal user traffic or attacker traffic. Intrusion detection systems may rely on any number of detection methods and tools, including signature-based or anomaly-based detection, stateful detection and application-level detection. Anomaly-based detection may rely on thresholds selected to describe the local network environment, e.g. relating to network traffic volume, packet count, IP fragments, IPID, IP options, IP header information etc. For example, a typical indicator of attacker traffic is if the traffic is directed to an IP address that is not used or is restricted, or if a service is requested that is restricted or not provided by the targeted network. Other information extracted from the traffic data to determine whether the source is from an attacker may include one or more of the following: an IP address known from an IP address blacklist, code signatures associated with attackers, and network scan behaviour.

If it is determined that traffic is associated with an attacker, in some implementations it may also be possible to further analyse the data to ascertain the type or classification of an attacker. The classification may be a risk or severity classification associated with the sophistication of the attacker. For example, certain behaviour may be associated with a reduced threat attacker (e.g. a script kiddie if a vulnerability known to the owner is not exploited by the attacker), whereas more sophisticated behaviour may be associated with a more dangerous attacker (e.g. skilled hackers that uncover hidden indicators such as code signatures).

Determining the attacker classification may include classifying the type of traffic generated, or the type of attacker depending on a threshold associated with the attacker's behaviour, for example where the threshold is based on which services are requested by the attacker.

Additionally or alternatively, the risk characteristics of a particular computing system or local network may be determined from the network traffic, i.e. the risk of an attack given the system/network configuration in view of the network traffic characteristics.

Classification may be rule based, or may be done by processing the raw traffic data with a learning method such as a neural network, perceptrons, or a tree learning method e.g. using a random forest algorithm. For example, when using supervised learning pattern recognition based on a perceptron based neural network (e.g. multi-layer perceptrons MLP), an input layer with one neuron for each input is used to map for IP Options, Malware and Buffer overflow conditions, selected attacks etc. The system of perceptrons is processed using a hidden neuron layer in which each neuron represents combinations of inputs and calculates a response based on current data coupled with expected future data, a prior data and external systems data. Data processed at this level feeds into an output layer. The result of the neural network supplies the output, e.g. as a risk function. The perceptron is the computational workhorse in this system, and can be used to model the selected risk factors for the system and calculate a base risk that is trained and updated over time.

When monitoring the operation of a system or the actions of users, thresholds are characteristically defined above or below which alerting, alarms, and exceptions are not reported. This range of activity is regarded as baseline or routine activity. In this way, a risk function can be created that not only calculates data based on existing and known variables, but also updates automatically using external sources and trends. In this example, external sources refers to data gathered from the community of users <NUM> that provides external trending and correlation points.

Secondly, at step <NUM>, in addition to determining the source of the traffic data (normal data vs. attacker data), the data manager <NUM> also determines an appropriate response, e.g. using a lookup table based on known features of the attacker behaviour. In some implementations the response includes the creation and/or configuration of a honeypot so that attacker traffic can be redirected thereby protecting the production network, and also providing an opportunity to extract more information about the particular attacker. At step <NUM>, honeypot configuration parameters are stored in the database <NUM> together with the attacker profiles.

Profiles for normal users are also stored, providing reference traffic data for bona fide users.

If the connection request from the authorised user relates to a request for traffic profile data <NUM>, then at step <NUM> the profile data is retrieved from the database <NUM> and a profile package <NUM> is provided to the authorised user.

The content of the profile package <NUM> depends on the information rights or requirements of the authorised user, as managed by the data manager <NUM>. The profile package may be a comprehensive compilation of traffic data on the database <NUM>, in which case direct access to all the information on the database may be provided to the user. Alternatively, the profile package may include only a portion of the traffic data depending on the relevance to or requirements of the particular user. For example, in one implementation, the data request may be for a particular attacker's profile (e.g. based on an originating IP address) and information associated with that attacker. For such a request, the profile package <NUM> includes information relating to the attacker identity (e.g. an attacker behaviour profile, attacker classification, code signatures etc.) and also includes attack prevention information (e.g. honeypot configuration parameters).

The data provided to the authorised user may also include other information available from the database, for example normal user profiles or attacker profiles in different formats (e.g. a specific attacker's profile or a group of attackers' profiles).

<FIG> shows a flow diagram of an example method <NUM> of implementing the IDPS <NUM>. Locally, an SPS <NUM> is responsible for interfacing between a user system (for example users <NUM>, <NUM> and <NUM> as shown in <FIG>) and the data manager <NUM> of the IDPS <NUM>. At step <NUM> the SPS <NUM> monitors the traffic, and based on the data <NUM> received from the IDPS determines the source of the traffic (normal user vs. attacker) at step <NUM>. The IDPS data received is one or more profile packages as described above with reference to <FIG> so that if an attacker is identified at step <NUM>, a protection response is implemented at step <NUM>, based on information in the profile packages. The information includes, for example, honeypot configuration parameters provided by the IDPS. Once the honeypot has been created, configured and/or reconfigured the attacker's traffic is sent to the honeypot at step <NUM>.

At step <NUM> the traffic data describing the attacker behaviour is logged by providing raw traffic data <NUM> to the IDPS. Similarly, if the source of the traffic is determined to be a normal user (and not an attacker), then this normal traffic data is logged at step <NUM>. At step <NUM> the normal traffic is forwarded to the real server (e.g. real server <NUM> in <FIG>).

Providing a central resource of shared traffic data improves the response time and efficiency of computer systems to attackers when compared to stand-alone systems reliant on a single source of information about attackers (i.e. their own network traffic).

Claim 1:
An intrusion detection and protection system (<NUM>) comprising:
a database (<NUM>), the database storing:
a plurality of profiles of legitimate users;
a plurality of profiles relating to known attackers;
attacker classification data; and
attack prevention data comprising honeypot configuration parameters; and
a data manager (<NUM>) configured to communicate with the database and a plurality of users (<NUM>, <NUM>, <NUM>) via a network (<NUM>), the data manager providing services comprising:
receiving, processing and logging network traffic data received at the data manager from the plurality of users of the intrusion detection and protection system, and updating the database with network traffic data to form a single data resource sourced from the users' traffic data;
determining protection parameters in the form of a honeypot configuration appropriate for a particular attacker; and
providing legitimate users with access to shared information on the database, enabling the users to identify attackers and implement the honeypot configuration.