The SANS Internet Storm Center has announced a podcast feed. If you don’t follow the ISC Handler’s Diary, you really should check it out. If the podcast meets the content of the Diary, it should be a winner.
For quite a while I’ve been keeping several items rolling forward in my blog reader, simply as reminders or bookmarks. I am dumping them here to clean out my Reblog and to ensure I don’t lose them. Some are rather old, some aren’t.
I have been queueing up the last couple of Richard Bejtlich’s Snort Reports in my blog reader, so I decided to hunt up and notate the link for the list of Snort Reports.
There is a good whitepaper over at Adobe about Deploying Adobe Reader 8 that goes into details about unpacking and deploying the Adobe Reader via automated methods, including GPO assignment.
I’ve been holding on to a link to this posting for quite a few months, and I’ve decided to put it up here for my future reference (and possibly your’s)
Marc Andreessen posted The Pmarca Guide to Career Planning, part 2: Skills and education back in October last year. I honestly don’t remember what rabbit trail led to it, but many parts of it resonated with me. Definitely worth a re-read in the future or a reference to others.
As you may well know by now, Apple recently decided that they would “leverage” their existing client base to their advantage. If you didn’t know, check Martin McKeay’s post about this. If you are running Apple’s software updater, they decided you need to bloat your system some more by installing Safari, whether you want to use it or not. Now if you’ve consumed the Apple Kool-Aid, you might not mind, and that’s your business.
I do have a big problem with this though. A vendor using an update conduit to install new software is just plain wrong. As network and security professionals, we generally preach the need to keep systems up-to-date. Generally we endorse the need to run update conduits and keep patches current. It becomes much harder to endorse this though when a vendor expands the updater outside of updates. There’s a bit of a paradox here. On the one hand, if you have something like QuickTime that seems to frequently hang in the vulnerability wind, you probably want to stay current with patches. On the other hand, if that patching process injects new software onto your system and therefore increases your potential attack surface area, you really don’t want to run that patching process. Hmmmm….
Now in the Microsoft world, I generally deal with this kind of thing on the corporate network by using WSUS. With WSUS, you can act as the informed filter for your users. If something comes down from Redmond that you don’t like, simply don’t approve it. I like that kind of control. Is there something similar for Apple updates? I don’t know, but you can bet this will lead to some checking into it.
What do you think? Is this abusive by Apple? Does this set a bad precedent? Is this a harbinger of Armageddon? (Just checking if you’re still awake.)