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. 

Last December I ranted a bit about Swedish security politics and just a couple of days ago ENISA - the European Network and Information Security Agency - released a report with recommendations on how to structure cyber security efforts within the European Union. Below are a few points that caught my attention.

Related to our lack of information on what is really going on out there:

“We recommend that the EU introduce a comprehensive security-breach notification law.”

“We recommend that the Commission (or the European Central Bank) regulate to ensure the publication of robust loss statistics for electronic crime.”

How else are we going to get a good picture of what is actually happening to others and how much it has cost them? My experience says that companies are getting really tired at hearing fictional stories and FUD. We need this.

Related to our inability of acting on issues:

“We recommend that the European Union introduce a statutory scale of damages against ISPs that do not respond promptly to requests for the removal of compromised machines, coupled with a right for users to have disconnected machines reconnected if they assume full liability.”

Internet have no boundaries. If a computer or network in Sweden is compromised and maliciously managed from Poland their respective ISP need to be responsible for disconnecting that machine and be held liable if they don’t. Our laws need teeth.

Related to vulnerabilities and patches:

“We recommend that the EU adopt a combination of early responsible vulnerability disclosure and vendor liability for unpatched software to speed the patch-development cycle.”

“We recommend security patches be offered for free, and that patches be kept separate from feature updates.”

Without a proper picture of where our vulnerabilities are, how are we supposed to be able to define our risk? Before the patch is available, how are we supposed to be able to counter a specific vulnerability with a countermeasure? A law that requires vendors to quickly notify their customers and the public about a vulnerability will allow companies to make the strategic decisions that is necessary. And of course patches should be free.

Last but not least, we need to collaborate on cybercrime.

“We recommend the establishment of an EU-wide body charged with facilitating international co-operation on cyber crime, using NATO as a model.”

Incidents happends to everyone, it’s just a question of when. Therefor, every company needs to plan for Incident Response. So does every nation and union.

Kudos to Enisa for a good report.

Ever wondered how intrusion detection solutions and vendors are acting on current virtualisation trends?

The most obvious peril hypervisors pose to virtualized network security is simply that they take that network traffic out of the range of conventional security devices. A packet sniffing appliance can’t see packets that never leave a given physical server. V-Agent solves that problem by residing within the virtualized network. It’s a logical approach to the problem.

V-agent by Catbird  is essentially a guest system - “a virtual security appliance” - that attatches itself and runs in the virtual network provided by the host (i.e. VMWare ESX) to virtual machines. V-agent then monitors and filters traffic between other guest system as a traditional IPS. Other functionallities provided by V-agent are NAC-like features for limiting the possibilties of accidently publishing guest systems, and protection of the “hypervisor”.

This is interesting, because virtualisation certainly twists the concept of the “network”. The cloud becomes even cloudier, so to speak. But virtual systems and guest machines are still essentially the same old Windows and Unix systems, and they use the same ways of communications as they always have. What is it to say that traditional solutions won’t work? They might just have to become a bit virtual?

I’ve spent alot of time lately writing about how various security technologies fail. My idea is that the problem boils down to the fact that most of our security efforts are vulnerability oriented. Fixing the vulnerabilities seem to be the smartest thing to do, right? Problems is, we can’t keep up with patching and we aren’t aware of all our vulnerabilities, or even a small part of them. To some degree, we will always be vulnerable. In order to complement the natural patch management process I favor efforts and technologies that are threat centric instead of vulnerability centric; Meaning efforts that focus on preventing threats instead of instances of attacks at vulnerabilities.

In an attempt to make an example, have a look at authentication systems. Most of us understand that all passwords can be broken if the necessary time and resources are put into it. The security of the authentication system relies on the strength of passwords, and in order to higher the bar for brute forcing it we

• create a basic policy that defines the minimum strength of the password (eight chars, with numbers etc).
• we force the user to change the password every four, six or eight weeks.
• we only let the user make three unsuccessfull attempts before disallowing any further attempts (or we incrementaly increase the delay between each possible attempt).

The first two points are vulnerability oriented, meaning they attempt to increase the strength of the password and as such decrease the vulnerability of the password. They increase the level of effort the threat must put into brute forcing the password. The last one, however, focuses on preventing any attempts of guessing the password. It doesn’t increase the strength of the password, but drastically limits the threats possibility to repeatably try passwords. This measure is threat oriented and no matter how much money or time he or she puts into buying equipment for crunching numbers, all they have is three attempts (there are other ways of defeating authentication systems though).

This kind of threat centric approach is what most Intrusion Prevention technologies lack. Common IPS:s functions as authentication systems without the threat centric part; They block individual attacks but passively lets the intruder keep trying until he crafts an exploit that slips through. Good examples are solutions that correlates alerts with vulnerability information of the target (which ISS does) in order to decide what to block. They forget to question whether the activity itself is acceptable. Just because the webserver runs Apache, all attempts at exploiting it as an IIS is ok? Or just because a perticular vulnerability isn’t present in this version of Apache, the activity is ok? This kind of thinking is, for example, what causes IPS implementation to fail at repelling penetration tests.

To be fair, some IPS:s have the necessary functionallity for being a threat centric tool. Juniper, for instance, has the option to block individual offending packets, an offending session and ultimately an offending IP for a configurable amount of time. Other IPS:s has similar functionality. Problem is that the functionallity isn’t used in an automated fashion due to the risk of consequences from creating long lasting blocks of legitimate traffic sources. This is why I advocate the involvement of a human to make the ultimate decision to block an offending IP for a given time, or use a good SIEM system (Security Information and Event Management) that correlates alerts with other information sources to get the knowledge of context necessary to make accurate decisions.

Expect to see more posts related to threat centric security in the future.

In response to a post on risk versus uncertainty.

“people spend too much time trying to reduce uncertainty and too little time focusing on reducing risk.”

My impression is the exact opposite. Companies spend to much time (and money!) on ad-hoc attempts in reducing risk with no control of where their biggest risks are or how these countermeasures actually pays of in terms of risk reduction. There is too much focus on headline-threats and efforts resembling “fire-fighting” and “socker-goal security”. Companies buy firewalls, intrusion prevention systems, data leak prevention solutions for millions so the can put them into place and forget them. There is too much uncertainty in daily security operations, which is why I think that reducing uncertainty is crucial. Companies often can’t answer the simplest questions. I say implement solutions that give you insights in vulnerabilities, threats, assets and ultimately risks (no, the answer isn’t an annual risk-analysis paper exercise). Then (!) implement measures for risk reduction.

Related to my earlier post Future firewalls are protocol, application and identity aware, Dark Reading today has an article spinning on the same topic entitled Firewalls Ready for Evolutionary Shift. I consider Identity and Application awareness to be the two most important features in future firewalls simply because they enable firewalls to function more like they were, and are, intended. An IP no longer identifies a user and a port number or even a protocol no longer identifies an application, and firewalls need to make their decisions on other parameters that does.

The article agrees with me on Application awareness, and as I, also reference Palo Alto Networks App-ID. In addition to that, Gartner also feels that integrated IPS-functionallity will be “next-generation”, which I don’t agree with. Integrated IPS-functionallity gives no new security functionallity. It is perhaps more practical, but it doesn’t solve any problems that IPS-systems have. That the article don’t mention identity awareness is sad in an otherwise great piece.

And, sometimes I wonder what Gartner is smoking. These paragraphs got my attention

CheckPoint, Cisco, and Juniper, for instance, already have some initial basic IPS capabilities in their firewalls today, Young says. “It’s less about firewalls and more about how networks and users have changed,” he says. “As they change, the firewall is forced to change.”

Gartner, Juniper is offering their full blown IPS as a blade in their ISG-series (Integrated Security Gateway).

Related to yesterdays post on vulnerability date of birth SANS today presented annual SANS Top-20 2007 Security Risks. I like these reports because they summarizes the most critical public vulnerablities the current year, along with the vulnerability annoncement and all. But it also has some serious issues. From the reports executive summary

Just over the last year, the kinds of vulnerabilities that are being exploited are very different from the ones being exploited in the past.

Really? They are referring to vulnerabilities in client applications and web services, which are essentially just input validation flaws just as format string attacks and many buffer overflows. What is different is that the threat are targeting “very different software” but the the vulnerabilities are not “very different”.

They also doesn’t seem to understand the Date of Birth of a vulnerability:

We have seen significant growth in the number of client-side vulnerabilities, including vulnerabilities in browsers, in office software, in media players and in other desktop applications.

What they mean growth in the number of disclosed client-side vulnerabilities, because applications like Firefox, IE 6 and Acrobat Reader were all developed in 2006 and as such should be featured in those statistics if they want to express their growth. Here they suddenly get it:

Web application vulnerabilities in open-source as well as custom-built applications account for almost half the total number of vulnerabilities being discovered in the past year.

I think it’s sloppy by SANS to not take care when choosing their words. It has become something that is almost expected. Besides that, the report features some good content.

Once every now and then I see reports mentioning the decrease or increase of vulnerabilities. Most of the time, these statements are based from statistics of publically announced vulnerabilities during a specific time period, which can make you wonder - when is a vulnerability actually born, and when is it dead? I think whenever the vulnerability is fixed, i.e. patched, answers the second question and here is a good answer to the first one:

DOB = The “date of birth” of the vulnerability. For software manufacturers, this is the date of first release to users. For enterprises, this is the date of implementation of the software that has the vulnerability in question.

We shouldn’t be so focused on statistics of publicised vulnerabilities since they don’t measure the existence of vulnerabilities, but more likely the effort in finding them. The only way we can decrease the total amount of vulnerabilities are to get rid of them, i.e. by patching. Likewise, the only way we can increase the total amount of vulnerabilities is to add code with vulnerabilities, i.e. create new insecure applications (or perhaps a patch?). Since patches usually follows from vulnerability annoncements that should mean that more vulnerability disclosures means more patches which means more secure software. So, shouldn’t we be conserned if publically announced vulnerabilities drops?