Below is a brief taxonomy of various events that I like to use when thinking about security monitoring. Their naming can be questioned, but I believe they give a decent structure to various events and their relationships. It like to think that it aligns well with NSM.

Security Events

Security events are any form of warnings, or what I like to treat them as, “indications” of attacks and/or malicious activities. From a security monitoring perspective, these events can direct the analysis and response activities in a direction where it is likely that something security relevant is happening. Security events can be an IDS/IPS alert from triggered signatures indicating that someone is targeting exploits at our public web services, or a network traffic anomaly alert indicating that an unusual high amount of traffic is leaving our network in the middle of the night. Security events need not be limited to digital ones, but can also be a user calling the help desk saying that his/her computer is slow.

Typical information sources are network/host intrusion detection/prevention systems, web proxies with malware features, endpoint antivirus systems etc. Any system that “looks” for attacks.

Communication Events

Communication events are anything that tell us who is talking to who. Collecting these events allows for establishing, depending on the type events of course, granular “audit trails”. A complete picture of how a certain host has been communicating can assist the response process by limiting the scope of a possible compromise, or to completely dismiss alerts in the case no traffic or data has been exchanged between the target and the source.

Typical information sources for informing us about communication patterns are Firewalls in the forms of Accept and Deny events; and Routing and Switching infrastructure by exporting meta data about sessions and traffic in the form of traffic flow information (i.e. netflow, sflow etc). Session data and network traffic flow information is favourable before firewalls. The ultimate information source for Communication Events are systems dedicated to sampling of full content data from traffic at strategic positions in the network. Full content data offers complete transaction records of sampled traffic, and can often completely verify or dismiss a suspected attack (unless it’s encrypted), but at the cost of alot of diskspace.

Identity Events

Identity events are any form of event that ties an IP-adress to another type of identity, i.e. a user name, a mac adress, a dns-name, a physical location such as a room-numer, or even a telephone number or in the case of an external host complete whois and owner/abuse information. Identitity events allows for establishing relationships between different identities and assets. A relationsship between an IP-adress and a Username aids the analysis and response process by making it possible to ask questions to the person in question.

Typical information source for Identity events are ordinary clients and servers, central authentication systems, dhcp server and dns server.

Activity Events

Activity events are information about activities, and not necessarily strictly security related ones. If communication events informs about who is talking to who, activity events informs about what they are saying and what they are talking about. Activity events allows us to know what is happening in a given situation/session/point in time - i.e. what actions hosts, users or processes are making. Having a complete picture of the HTTP requests a client have been making towards the internet can support the reponse of a possible malware infection of a client. Having a complete picture of what the IIS- and SQL server are up to eases the investigation of a possible XSS or SQL-injection attack.

Typical informations sources for Activity events are any strategic system that has a certain service. Web Proxies tracks any web requests to the internet. A web server, or a web application firewall, tracks interactions with the web server. Collecting Event logs from a Windows server or syslog feeds from an important Solaris servers allow you to track interactions with those resources.

To summarise:

Security Events point us to likely malicious activity. Communication events tells us who is talking to who. Identity Events tells us who the source and target is and Activity events tells us what actions a system, a users or a process is doing. My experience tells me that a successfull security monitoring requires a degree of all four of these.

What many people seem to forget when thinking about IDS and especially IPS-systems is the important tie they have to performing network forensics. Not all attacks will be blocked, and the ones that are detected by other means needs to be investigated. What equipment is better suited for that than a device that sits inline, at the perimiter or core, monitors all sessions entering and leaving the premises, and that at least tries to identify possibly malicious elements of the monitored traffic. That’s right, none. The true value of a modern monitoring system is that they are a tool for investigating security incidents - not just blocking them.

Having this in mind, this puts new requirements on the IDS/IPS. Not only should they have a good detection rate and low false positive rate, they should also have the necessary information available to actually investigate the indications that alerts truly are, but also investigate traffic that isn’t tied to an alert. Further more, which is one of the crucial elements of performing forensics, is to avoid informing the potential attacker about your knowledge of an attack. This is lesson 1A in incident handling - never try to contact the source of the alerts; never visit the website that the attack is coming from etc. All these actions might inform the attacker of your knowledge of the compromise, and as such will cripple your ability to investigate it.

Related to this is the fact that most IDS/IPS systems, and some firewalls aswell for that matter, does lookups of source and target IPs in the alerts. This feature, which is intended to make the alerts more easily readable, might in fact inform the attacker that some system has processed the traffic from him. When an alert fires the system will automatically try to do a reverse lookup on the IP, the host will contact the root server and follow it’s trail down to the DNS server that has information about the IP in question. This DNS-server could very likely be run by the attacker who now sees someone doing lookups on his IP. See how the solution itself contributes to the problem?

A possible solution to this, which doesn’t involve turning of name resolution entirely, is to be able to configure the system to use 3:rd party dns-servers or dns-proxies for external IP:s. I learnt of a tool that has implemented the support for this, namely the excellent network security monitoring console Sguil.