August 08, 2006
Two talks for the price of one!
I gave two talks at the Vanguard Security Expo in San Diego. Get the slides by clicking the links
Resilient Infrastructure for Network Security
This covers a model that I originally wrote about in a paper in the Complexity journal (available here). I have updated the model somewhat in these slides. The talk argues that traditional security models (consisting of prevention, detection and response) fail in the face of very fast attacks (e.g. worms) or very slow ones (information stealing malware). The slides talk about possible technologies that can augment prevention, detection and response to give better performance on fast and slow attacks.
Combining Endpoint and Network Defenses
This looks at the properties of common defenses on the network and endpoint for malware, and looks at how they stack up when implemented in different places, to make sure that adding defenses in the network and the endpoint result in better security.
Posted by matt at 10:16 AM | Comments (0)February 04, 2006
Zero day for you?
The term zero-day is pretty common, and used to mean an attack which is happening before anyone in the security community knows about it. It is commonly used to talk about worms and viruses, with the meaning that a zero-day worm has no "signature".
With the recent Nyxem worm, Sana's SafeConnect detected it without signatures. By the time we had analyzed it, only one other anti-virus company had a signature for the sample that we had. Within the next 4 days, the other 22 odd anti-virus products that we test against duly added signatures for the worm.
The customers of the last product to get a signature would then have had a "zero-day" attack possibly proceeding for 4 days!
Posted by matt at 03:07 PM | Comments (0)January 30, 2006
Rootkit Webcast
Jeremy Pickett and I are giving a webcast on rootkits tomorrow. We will be giving a relatively general introduction to them, followed by a description of Sana's new product Primary Response SafeConnect. This contains our behavior based malware detection and removal technology "Active Malware Defense Technology". SafeConnect is currently in beta.
We will also be showing some information about the malware that we have found (and removed!) from the beta program.
You can sign up from http://www.sanasecurity.com.
January 24, 2006
Non corporate use of corporate machines
In a recent survey of computer use in Europe , there are some interesting statistics about the lack of perimeter around corporate machines.
21% of workers allow family and friends to access the internet.
51% of workers connect their own gadgets to their computers.
McAfee also identified 4 sterotypical types of employee that put organizations at risk
- The Security Softie – This group comprises the vast majority of employees. They have a very limited knowledge of security and put their business at risk through using their work computer at home or letting family members surf the internet on their work PC.
- The Gadget Geek – Those that come to work armed with a variety of devices/gadgets, all of which get plugged into their PC.
- The Squatter – Those who use the company IT resources in ways they shouldn’t (i.e. by storing content or playing games).
- The Saboteur – A very small minority of employees. This group will maliciously hack into areas of the IT system to which they shouldn’t have access or infect the network purposely from within
What is often lost in these types of analysis is the business benefits of more freedom, as opposed to the business losses due to security issues. There is often a knee jerk reaction to clamp down, while a bigger picture view might swallow the risk of attack in the face of happier and more productive employees.
See also Bruce Schneier's blog entry on this
Posted by matt at 10:36 AM | Comments (0)December 21, 2005
A New Group
After a little break, the nth world commentaries have undergone a change. Now some new people will be blogging, from the Sana Labs research team. This team of individuals keeps up with the latest happenings "out there" especially in relation to security and how to survive in an Internet connected world. Over the next few days, you'll hear from members on the team, speaking on current issues and new discoveries.
Posted by sana at 12:24 PM | Comments (0)June 30, 2005
Let go!
I had a conversation recently with someone about the dangers of automating too much functionality in our information technology systems. We were talking about security and he was worried that automatically stopping attacks could cause a lot of collateral damage through false positives. For this reason, he would much rather keep a human in the loop. Furthermore, he was very wary of mechanisms that he couldn't understand or see the inner workings of. He didn't want anything that would function as a "black box".
Legitimate concerns, indeed, but shortsighted none-the-less. With the growing complexity of systems we can no longer maintain fine control over them, we need systems that look after themselves, and to do that they need to be autonomous and adaptive. And as soon as they become autonomous and adaptive, they will very likely move outside the realm of being easy to understand. But I would argue that this is a good thing, not a bad thing. We have to undestand the implications, yes, but we also have to surrender control. It's the only way forward.
A good way to illustrate this is to think of how useful horses have been to humanity throughout history. We can control them and understand very well what to expect from them, but for most of our history we had no idea whatsoever of how they work inside. In future, we will have machines and computing systems that we don't understand at all, but that function much better than they do today, that repair themselves, and adapt and evolve autonomously.
When we think of this kind of future, a key question is how do we know such systems work? Well, in the same way that we know that horses work: by observation and through black-box testing. We know how fast a typical horse can run and for how long because we have "tested" so many of them. We don't have any guarantees however - we could get a horse that was lame and so would fall far outside the expected performance. But that is a chance we take, and it's a small price to pay for a horse that fights off most infections without any assistance whatsoever, that can learn and grow and survive autonomously.
We need to let go: it's time for our systems to look after themselves so that one day they may look after us.
Posted by sana at 01:23 PM | Comments (0)April 05, 2005
Red Hat Linux vs Microsoft Windows: what really matters
Many people have been talking about the recent paper that compares Microsoft Windows with Red Hat Linux. The paper does a role-based comparison of Windows Server 2003 with Red Hat Enterprise Linux ES 3, meaning that they are compared when functioning just as web-servers. The conclusion of the report is that Windows in its default installation was more secure than Red Hat during 2004, with 52 vulnerabitlities for Windows vs 132 for Red Hat during the year, and 31 days of risk vs 70.
Of course, this paper created quite a firestorm, not least because the ongoing argument of whether Linux is more secure than Windows is like a religious war, and the paper was funded by Microsoft, which only increases the controversy.
After reading the paper, I have to say that I think it is a very valuable contribution to the debate, because it tries to quantify the difference between the two systems. Perhaps the data is not accurate, as some would argue, but the paper gives a full description of the methodology used, and so should be easily replicable. I'd love to see some of the naysayers repeat the analysis with their own data and see what comes up.
I do have a few quibbles though. Firstly, this paper compares two vendors, Microsoft and Red Hat, which doesn't necessarily give a good idea of how secure Linux itself is. As the authors point out:
One interesting aspect of the challenge faced by Red Hat that is not obvious from a simple examination of the raw numbers is the delay between a fix becoming available within a product, and the inclusion of that product as an "approved" Red Hat package.
They go on to give an example of a MySQL bug that was fixed in June but only incorporated in the Red Hat package in November. And since they only look at fixes that come officially from Red Hat, this introduces a vendor specific bias. One of the reasons that this bias has an impact is that there are many vendors of Linux, but only one of Windows. With many - if not most - Windows vulnerabilities, Microsoft is given advance warning by the people who discovered the vulnerability, and given time to fix it before the vulnerability is made public. By contrast, Red Hat would not be given such advance warning, since it doesn't control the source code of Linux. Hence the task faced by Red Hat is much more daunting.
This has interesting ramifications for the security of open source. Firstly, it is potentially less secure because vulnerabilities are publically known before the community has time to fix them, unlike closed source. On the flip side, though, there is more knowledge about the existence of vulnerabilities. The thing that I find unnerving is that if a third party finds a vulnerability in Windows, and reports it to Microsoft to give them time to fix it before making it public, someone else could also have found that same vulnerability, and could be actively exploiting it without anyone knowing. How much this happens we don't know, and will probably never know, but it's certainly possible. What this could mean is that closed source will have less exposure to known vulnerabilities, but potentially more exposure to zero-day or unknown vulnerabilities, although of course this is wild speculation.
Another major potential issue with regard to the vulnerabilities count is that they only consider vulnerabilities that were fixed by the vendor during 2004. If the vulnerability existed in 2003 and was not fixed then, it is counted, and any vulnerabilities discovered in 2004 that were not fixed are not counted. To quote the paper:
we will not consider vulnerabilities announced in 2004 but fixed in 2005.
Of course, what this means is that if a vendor gets a 1000 vulnerabilities in 2004 and doesn't fix any of them, then they will not show up in the analysis. The authors try to iron out this effect by including vulnerabilities from 2003 that were not fixed in 2003, but I think what would make more sense is to consider all vulnerabilities from 2004, and make a note of which were fixed, and which weren't, including those carried over from earlier years. After all, if we want to know the days of risk during 2004, we have to include all vulnerabilities discovered during 2004 and not fixed.
And now a comment on methodology: they compared the systems in their default "out-of-the-box" configurations, without any security hardening. That is a fair way to go about it, but one objection that I have is that they totally disregarded the effect of the firewalls that exist on both these systems. I can't imagine anyone would actually deploy these servers without the firewalls turned on, especially on the Red Hat box since the firewall is on by default.
So what I'd like to see is a comparison in more meaningful terms, i.e. if I deploy these servers in default mode, connected to the internet, what are the chances that someone out there can own my box? Let's forget password stealing, and rather focus on application level vulnerabilities. Just reporting the total number of vulnerabilities, and using the ICAT severity ratings, doesn't give me much idea of the risk. In particular, ICAT calls a vulnerability severe if an attacker can remotely get root or user access, or a local user can get root access. Now these are all quite different things. If there are no remotely exploitable vulnerabilities, I don't care about local vulnerabilities. On the other hand, if there are no local rootable vulnerabilites, then the remote non-rootable vulnerabilities are so much less severe.
What I would suggest is the following metrics:
1. The total number of remote rootable vulnerabilities, assuming the firewall is on.
2. The total number of remote user access vulnerabilities, assuming the firewall is on.
3. The total number of local rootable vulnerabilities.
4. The days of risk for each category above.
These metrics would give a much more understandable idea of the risk than those in the paper. And who knows, Microsoft Windows may turn out to be more secure than Red Hat Linux...
Posted by sana at 01:00 PM | Comments (2)February 23, 2005
Welcome to the nth world commentaries
The purpose of this blog is to comment on all manner of things relating to technology and science that might grab my attention.
Although these commentaries may cover a lot of different aspects of science and technology, my expertise lies in computer security, the intersection of biology and computing, complex adaptive systems and other related topics. Hence this blog is more likely to focus on those sorts of topics.
Additionally, I intend to have guests write a post every now and then, so look out for some broader perspectives than just one man.
Posted by sana at 03:41 AM | Comments (0)