Our analog world is full of vulnerabilities. I enjoy watching shows like Tiger Team and The Real Hustle because they offer good examples of their great numbers, and how easily they can be exploited. Interestingely enough, we don’t put alot of effort into minimising them either. Instead we accept risks, or transfere them with for instance insurance. We are more focused on detection and response rather than prevention. Likely because it’s evolved as the most cost effective method.

I believe paramount to why this works in the analog world, is because incidents are naturally detectable. If someone steals your juwelery you’ll eventually miss it. We know how much the loss cost, and since all of us have insurance we (or at least the insurance companies) have good averages on what a normal person is likely to loose per year and bases their premiums on that.

But a digital asset can be stolen in a number of ways without the owner knowing about it. Digital incidents aren’t naturally detectable, and we have no real numbers on the number of incidents and the average costs associated with them. In fact, there are insurances for digital security breaches and issues, but if we fail to detect them, when are we ever going to make us of our insurance? It will never be the most cost effective method. It seems like we have no option other than employing prevention and chasing vulnerabilities. But then again, since there are no perfect security, this approach will always leave us with an inaccurate view of incidents and no other options. Just another hamster wheel of pain. Find vulnerability, Patch and Proceed.

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.

I favor the idea of trying to measure progress and success of the security process - Any security investment should have a quantifiable outcome in terms of risk reduction. Related to this, some months ago I read Security Metrics by Andrew Jaquith, and somewhere around the same time I read Measuring the Return on IT Security Investments authored by Intel researcher Matthew Rosenquist. The later defines a methodology for measuring the return of a security investment (ROSI) which involves the following steps,

• Evaluating cyber-attack incident data averages over time.
• Measuring the reduction of incidents from implementing new security programs.
• Valuating the impact of avoided incidents.
• Applying the results to similar areas to estimate future value.

The first step involves comparing incident counts between different months, years etc. Security is about avoiding bad things to happen, so a decrease of bad things happening must mean progress. Well, that is only true if we have an accurate value of the number of incidents. Our method of detecting incidents must be exactly as effective and accurate as last year, even though threats targeting us, vulnerabilities in our defences and assets of importance might have completely changed. If our defences (more specifically the detection process) doesn’t follow this change, we will have a inaccurate value of the number of incidents. Without measuring the accuracy of the detection process the “Number of Incidents” comparison is irrelevant. It becomes an oxomoron where we are measurably secure while being insecure.

The “number of incidents” dilemma also haunts the second step which involves measuring the reduction of incidents from implementing new security investments (technical, processes, people etc). So if we make an investment and our incident count drops then that’s considered a success, right? What if that security investment causes incidents to go undetected? Perhaps turning on IPSEC between all our servers and clients are considered a security investment - but what happened with all the alerts from IDSs that contributed to defining incidents when all traffic flyes by encrypted? Again, the model must take detection accuracy as a parameter.

The second and third step involves “valuing impact of avoided incidents” and “estimate future value” of investments. These steps aim to define how much the investments have really paid of in terms of loss avoidance. But seriously, how do you define the cost coming from an incident when it has not yet happend? Take a malware infection as an example: you can define the potential loss to be anything from the consumption of 10% cpu and memory at an individual workstation to information disclosure and theft of scetches for the next stealh aircraft. This calculation allows anyone to creatively come up with numbers that are favorable for the situation.

Measuring security progress and how security investments actually pays of is an excellent idea. But it’s difficult since both good and bad security might equal zero incidents. Somehow we must also measure how well we detect incidents and malicious activity. 

A couple of days ago I learnt from IDG about the disclosure of 100 e-mail accounts from parlaments and other high profile targets world-wide. The incident is also covered in international zines like the Register and Vnunet.

Whats interesting about this is the decision made by the consultant to disclose the information, and his reasoning,

“Here is a list with working passwords to exactly 100 email-accounts to Embassies and Governments around the world. Yes it’s the real deal and still working when we are posting this. So why in the world would anyone publish this kind of information? Because seriously, I’m not going to call the president of Iran and tell him that I got access to all their embassies.

Leaving the ethical and moral discussion aside, which in fact is to obvious to warrant discussion, and instead focusing on the difficulty of disclosing this kind of information. Lets identify the difficulties of informing 100+ victims having their e-mail accounts compromised:

1. Who do we inform of the compromised accounts? We can try the accounts themselves, but we can’t be sure that someone using the credentials removes the e-mail. Does all parlaments have a website? Do they have a technical contact? Just searching for a e-mail adress to target the information with might be very time consuming.
2. Who would understand what we were saying? Even though saying “I have login credentials to your e-mail and can read your e-mail” would likely catch anyones attention, few would understand the extent and seriousness of this. Just getting the attention might be time consuming.
3. Who would believe what you were saying? Prove it, they would say. Yeah, on 100+ accounts.

So what should you do?

• Contact and inform your national incident response team of the situation. Hand them the information and let them own the case. The have the time and resources, and will likely be very keen to help , especially in this case since it is of national interest. I, for instance, would contact SITIC.
• Another possibility is to work with a security partner who have contacts, experience and resources to notify the customers.

This is an example of why we need the security industry.