Today Telkom came to install my housemat's/our ADSL. It only took them 7 months. Now, that's what I call service.
This entry brought to you over a very expensive piece of copper and equally expensive switch port, courtesy of Telkom.
This article bugs me a bit. The writer starts with a mention of a new Firefox patch and ends up asking the question:
Windows problems are so common that even home-based users know they must pay a $50/year "user tax" in order to have an anti-virus company manage the delivery of patches to them.
Is there a way to deliver that value to open source users without delivering that cost?
Apart from the error about anti-virus vendors delivering patches. Why do people think Microsoft are the only ones patching? Between Debian's apt, FreeBSD's ports, Gentoo's portage, Fedora's yum, SuSE's YaST, Sun's Patch Manager there is more innovation in patching and updating than you could shake an uninformed stick at. What's more is these tools are good and in many cases, better than Microsoft's offering (they patch everything for a start).
The MSRC blog has an interesting post entitled "A day in the life of a Security Bulletin" which gives some insight into what happens at Microsoft from when they are notified of a vulnerability through to releasing the patch.
Okay, so fast forward a bit....after we have determined that it is a vulnerability, we then work with the product groups to build the security update. Here is where it can get tricky. Let's say you have two product groups that need to work together on a particular update because both products have the vulnerable component. Because each group may run different testing, the possibility for one group to be ready to ship before the other is increased. We also work with other groups on extensive testing of the update to test things like application compatibility. So, what do you do? Ship one update for one product groups' component, but not the other? Wait? What if the issue is 'critical' in severity? What if we find an issue in the last stages of testing that could impact customer's applications negatively? You would think that this would be an easy decision and before I came to the MSRC I would have sworn that this would be a no brainer. Well I was wrong! As with all of our security vulnerability reports, each security update gets looked over in depth and we find that it may not be in our customer's best interest to provide one update before the other. If we did provide one update before the other, then that may leave the component that we do not have an update for vulnerable, making our customer more at risk because the information is now public.
It is a little scant on details and doesn't contain anything revolutionary or surprising. However, it is interesting to look behind the curtain.
Continue reading "Microsoft's Patching, an insider's view"
CorpWatch has a link to the India Resource Centre's 'Send a Free Fax' to the CEO of Coke to ask him to stop:
- Causing Severe Water Shortages for Communities Across India
- Polluting Groundwater and Soil Around its Bottling Facilities
- Distributing its Toxic Waste as "Fertilizer" to Farmers
- Selling Drinks with Extremely High Levels of Pesticides
I'm not sure how much of an effect fax sending will have, but it is hardly any effort on your part so you might as well. If you want to find out more about what Coke is doing in India, have a look at:
I don't normally blog about stuff like this, but my cousin, Ben Lannon, and his wife, Jane, have just given birth to a daughter named Gigi. I was rather moved by a picture of a new born child I am related to. Congratulations Ben and Jane.
UPDATE: After my hosting server lost 10 days of my home directory, the picture is now MIA
I was pointed to the article OSS Means Slower Patches by Pieter Blauuw. I have had it open in my browser window for the last day or two trying to figure out what feels so wrong about it. Thankfully Jericho has put together a decent response here and here. The full Symantec report is mirrored at OSVDB.
Continue reading "OSS Patches Slower"
While reading over some NIST documents I was pointed to the National Vulnerability Database. It uses CERT/CC as a backend, but has some nice statistic generators.
Hava a look at:
The site was being difficult so you may have to click the button at the bottom of the page.There has been a surprising amount of fuss over this, so I thought I should clear some things up.
I haven't written terribly complimentary things about SATNAC or their primary Sponsor Telkom. One such entry (which has now been removed), which was just plain rude and didn't include anything relevant to back it up, made it somewhere visible when you searched for the phrase 'satnac'. This made some people at Telkom unhappy and I needed to atone.
Continue reading "Libel, Free Speech, Academic Freedom and Being Rude to Telkom"
- Honeypots
- IDS
- Software Security, ACLs
- Firewalls, Auth/Auth
- Patch management, Op. Procedures
It seems these guys have come up with some vulnerabilities in EIGRP and a theoretical algorithm of how a cross platform worm could spread across Cisco IOS based software. It seems we are moving to a place where we may soon see a Cisco worm. This post further details how this worm could be realised.
This is a scary prospect and one that needs some discussion and better patch management tools from Cisco. Replacing the entire IOS image isn't something you want done regularly.
When did you last update your router's AV?
The LOG targets in my new packet scrubbing chain have already found some misbehaving applications. If anyone is interested here's how the scrub chain looks:
Continue reading "IPTables and Netfilter"
It's about time physical locks be subjected to the same open security analysis that computer security systems have been.
Schneier
Right Oracle has it horribly wrong, they keep doing this and really should just start fixing vulnerabilities that are reported to them. You can't sit on them indefinitely. Now Microsoft doesn't sit on them indefinitely but also seems to think they can hold on to patches for a fair bit of time.
The reason why you can't do this is simple: "We don't know if determined attackers can already exploit these vulnerabilities."
There are caveats to this of course. You don't want to rush out a poor patch that breaks everything, and you don't want to encourage reverse engineering of the patch. The first problem is easier than the second, there are numerous ways big companies can throw money at testing infrastructures to make the problem more of a hiccup. The second problem however seems to degrade into a tradeoff, patch asap and risk large scale worm type situations on the increased number of unpatched machines1 or patch monthly and lower the number of mass compromises but increase the risk of determined attackers. Determined attackers are the worse kind, they are the kind who engage in espionage, sabotage and other sorts of clandestine activity.
Now in a world with on the ball security officers with decent edge defenses the second would be the best options, you would be patched before a mass compromise could occur and you could use edge defenses such as firewalls, IDS, anit-malware etc. to hold the fort during testing. I don't think that is an unattainable ideal. The other option makes it easier for your typical overworked sysadmin to patch and defend against automated exploitation, but leaves them vulnerable to the determined attacker.
If we had some knowledge of whether there are secret exploits out this would be an easier decision, but we aren't going to get hold of that information any time soon. So this leaves us in a situation where:
- Scheduled patching will result in less intrusions overall.
- ASAP patching will result in less (possibly more damaging) damaging intrusions in those organisations with good security practices.
UPDATE: Pete Finnigan, an Oracle security blogger finds this interesting. Thanks Pete.