Last week I read a great article over on the ISC Diary by Rob VandenBrink that asked the question “Should We Still Test Patches?” Rob makes some excellent points! Given that Microsoft and Adobe coming out with patches tomorrow and me being on the road missing NovaHackers tonight, I thought I’d throw in my thoughts.

My personal approach is to mostly follow his auto-pilot advice however I do try to configure things to delay a day or so. This way if some bad patches slip out, I have time to manually remove them from the auto-install queue.

In an enterprise environment, I would recommend a similar approach however holding off a little longer (e.g., maybe 2 days) and intermediately deploying the patches out to a representative set of low risk guinea pig machines (e.g., 1 day as before). This way an enterprise at least gets to wait a little for others to find problems as well as get some live testing to make sure the patches don’t break any of their applications.

And here are a few points from Rob’s article that I would like to highlight.

via ISC Diary

In short, dozens (or more) critical patches per week are in the hopper for the average IT department. I don’t know about you, but I don’t have a team of testers ready to leap into action, and if I had to truly, fully test 12 patches in one week, I would most likely not have time to do any actual work, or probably get any sleep either.

Where it’s not already in place, it’s really time to turn auto-update on for almost everything, grab patches the minute they are out of the gate, and keep the impulse engines – er- patch “velocity” at maximum.

…

Going to auto-pilot is almost the only option in most companies, management simply isn’t paying anyone to test patches, they’re paying folks to keep the projects rolling and the tapes running on time (or whatever other daily tasks “count” in your organization). The more you can automate the better.

…

There are a few risks in the “turn auto-update on and stand back” approach:

• A bad patch will absolutely sneak in once in a while, and something will break. For this, in most cases, it’s better to suck it up for that one day, and deal with one bad patch per year as opposed to being owned for 364 days. (just my opinion mind you)
• If your update source is compromised, you are really and truly toast – look at the (very recent) kernel.org compromise for instance. Now, I look at a situation like that, and I figure – “if they can compromise a trusted source like that, am I going to spot their hacked code by testing it?” Probably not, they’re likely better coders than I am. It’s not a risk I should ignore, but there isn’t much I can do about it, I try really hard to (ignore it).

Read more here.

#####

Also be sure to check out the comments on the ISC Dairy post … lots of good suggestions as well. See ya!

Local security Bloggers were on a roll this week; we had so many great posts to choose from that it was definitely a challenge to pick the top three. We highly encourage you to check out the other bloggers in the NoVA/DC area that didn’t make our list this week by visiting our Blogs/Podcasts section.

#3 – iPhone Security: This week, @geminisecurity wrote an interesting post entitled “iPhone 3G S – Hardware Encryption?” that discussed—you guessed it—whether or not the iPhone 3G S will really be as secure as Apple claims. Trying to get to the bottom of just how secure the iPhone 3G S will be, @geminisecurity did a bit of research and found… well, not much really. As they point out in their post, “mentioning that a device supports hardware encryption can mean a lot of things, and Apple isn’t very clear about what they mean by this. Trying to do some further research didn’t help much either as I only ended up being further confused with all the different mentions of this ‘hardware encryption.’” Listing all of the different things they found about the iPhone 3G S’s security (or lack thereof), @geminisecurity did an excellent job of explaining what each claim meant, and why they’re still too vague to mean much of anything. Closing their post with “[i]s this how security is being treated? Apple isn’t the only company being vague about these types of issues; it rolls all across the board,”  this post is definitely one that you should check out for yourself.

#2 – PDFs FTL: It’s no secret that PDFs have been getting quite a bit of attention lately; when your security resembles a slice of swiss cheese, people are bound to notice. In all seriousness however, what makes the vulnerabilities in PDFs so dangerous is the widely accepted idea that once you put something in a PDF you can put it up on the web and it’s perfectly safe. (Which, as we all know, it’s not.) The reality is that someone could put malicious content into the PDF that will affect anyone who views it, making that person one step closer to owning you and installing a keylogger onto your computer. @carnal0wnage makes many of these points and more in his “PDF Defiling Intro” post, and even goes so far as to list all of the recent vulnerabilities found in PDFs. It’s nice to have a comprehensive list of PDF vulnerabilities, and @carnal0wnage did an excellent job compiling it. Definitely be sure to check out this post for yourself.

#1 – And the List Goes On: As we found out two weeks ago, @mubix is becoming the go-to for security resources. In his latest post “Getting your fill of Reverse Engineering and Malware Analysis,” he provides an extensive list of individuals, groups, and companies that people who are interested in reverse engineering and malware analysis should check out. This is the absolute best resource list we’ve seen for this topic, so be sure to bookmark it for future reference or add it to your RSS feed.

Well, that’s all for this week. Be sure to follow me @grecs during the week for more great posts from local bloggers.

o o o o o

Speaking of great local bloggers… we’re looking for some great guest bloggers to feature on NovaInfosecPortal. If you’re interested, feel free to contact us or send us a tweet.

So, what was on everyone’s minds this week? Spam… and the Swine Flu, apparently. Leave it to the spammers to take advantage of a horrible situation.

• Spammers will def b doing. RT @mckeay srt planning 4 the impact of the swine flu, as well as the spam that will inevitably srt circulating #
• Here comes the spam. RT @mckeay Just found the first swine flu spam in my own mailbox. What a surprise. Not. #
• Here’s the official US CERT warning. RT: @uscert_gov: Swine Flu Phishing Attacks and Email Scams http://tinyurl.com/cnjgne #
• SWINE FLU SPAM: @mckeay called it first about the forthcoming barrage of spam. http://tinyurl.com/d2cknl #
• MORE SWINE FLU: Then it started happening. Others tweeted it & several articles were written about it. Here’s one. http://tinyurl.com/dj6l88 #
• SWINE … FINAL: Ok, just one more comment. Spammers are very smart for doing this but it’s wrong! #commentary #
• SWINE SPAM: Not to much news today except a few articles on an increase in swine-related spam as expected. http://tinyurl.com/cw5kao #
• LOL RT @BrickandClick Want To Avoid Swine Flu? There’s An App For That Too -> http://bit.ly/t4Q9n #

As if the Swine Flu spam wasn’t bad enough, it turns out that the vulnerabilities in Adobe Reader are bigger than we thought.

• ADOBE VULN (CONT): Another article from The Register going into JavaScript issues in their products. http://tinyurl.com/cb4rhw #commentary #
• ADOBE VULN (CONT): As I noted earlier, scripting needs 2 b off by default! Or u can just use FoxIt as suggested by @jack_daniel. #commentary #
• ADOBE VULN: Another vulnerability caused by scripting. Geez, this needs to be off by default! http://tinyurl.com/ca44ys #commentary #
• New comment on “Another Adobe Reader security hole emerges” http://bit.ly/WmLrR #

When you pair both problems with the biggest security vulnerability of all time, it’s not pretty.

• CORE INFOSEC PROBLEM: Once again here is another story that shows people are the primary problem. http://tinyurl.com/d4p7uc #
• PEOPLE PROBLEMS: It all comes back 2 awareness training – and making it exciting and interesting. I know … this is hard to do. #commentary

But, on a more positive note, SANS held its AppSec Summit this week…

• RT: @IBMFedCyber: Anyone else going to the SANS AppSec Summit on Wednesday? I will be there.. would love to tweetup. #SANS #infosec #

And OWASP has officially announced AppSecDc 2009!

• RT @mubix RT @securitycfp: RT @AppSecDC09: AppSecDC 2009 Call 4 Papers & Call 4 Trainers now Open! Details hre: http://bit.ly/ZVgpO #CFP #
• RT @AppSecDC09 AppSecDC 2009 is looking 4 Volunteers. If interested join R mailing list! http://bit.ly/16CPc Or reply or DM yr interest hre #

But depending on what happens with some of the major cybersecurity acts in the next few months, AppSecDc might offer some different topics than normal.

• RT: @danphilpott: RT @ITCompliance: BREAKING: ICE Act would restructure #cybersecurity rule, create WH post http://bit.ly/JzYmC … #
• RT @danphilpott Washington Post has a link to a draft copy of the ICE Act: http://is.gd/v5UU (with a hat tip to @ITCompliance) #
• RT @danphilpott First article I’ve seen for yesterday’s ISC2 report on Fed CISO Cybersecurity perspective: http://is.gd/vQAP #
• OMG, work tgthr. RT @danphilpott Whole new cybersec bill: Critical Electric Infrastructure Protection Act was introd 2day: http://is.gd/vqLU #
• LOL. RT @danphilpott The first rule of Cloud club is, you have to make ObMatrix references. #totw #
• RT @danphilpott Unfortunately, no one can be told what The Cloud is. You have to verify it for yourself. #totw #
• RT @rybolov @danphilpott Carper’s supposed to (re)introduce his new(old) FISMA (2008|9) bill. #

It will be an interesting time for people who are just getting into security. (Or, security internships.)

• RT: @CSOonline: 10 Dos and Don’ts for Security Job Interviews: http://www.csoonline.com/article/490926 #job #

But if we all follow some of Marcus’s excellent advice, things should be just fine.

• RT @marcusjcarey New Vlog Post – Sexism in Information Security? > http://twurl.nl/44h0rv #novablogger #
• RT @marcusjcarey New Vlog Post – Toot Your Own Horn! – http://twurl.nl/xoqotf #novablogger #
• RT @marcusjcarey New Vlog Entry – Own Your Technical Interview – http://twurl.nl/omq8u1 #novablogger #
• RT @marcusjcarey New Vlog Post – What Tool Should Everyone Know? – http://twurl.nl/286tg4 #novablogger #
• RT: @marcusjcarey: New Vlog – Hack Your Degree – http://twurl.nl/ia1xzh – How I got 4 yrs of credit in 12 months #novablogger #

Plus, we always have CharmSec…

• RT @mubix RT @charmsec: CharmSec 12 is this Wednesday at Slainte. #
• RT @mubix RT @charmsec: CharmSec Challenge: http://is.gd/u522 bring yr solution 4/29 & get free round (or something). Don’t leak yr answer! #

And, new Twitter tools to cheer us up.

• Cool new tool. Kind of like Twitpic but with voicemail. RT: @RodBeckstrom: Voice_Message_Tuesday_28_Apr_09_59PM http://tinyurl.com/db7gqz #

###

Have something to say? Then why not write about it for NovaInfosecPortal? We’re currently looking for some great guest bloggers to feature on the site. If you’re interested, drop us a line, or send us a tweet @grecs.

Somewhere, the creators of Adobe Reader are weeping.

And if they’re not, it won’t be long until they do; with all of the recent vulnerabilities swirling around Adobe Reader, things are going from bad to worse.

But just how bad is bad?

According to CNET, at the RSA security conference earlier this month, F-Secure Chief Research Officer Mikko Hypponen said that users should go so far as to switch their .PDF readers altogether due to the security issues with Adobe Reader. (You can check out a list of alternate .PDF readers here.)

While swearing off Adobe Reader altogether might seem a bit a bit extreme, it’s gotten to the pointwhere avoiding it might be the best thing to do. Since the beginning of this year, more than 47 percent of attacks exploit holes in Acrobat Reader, while six vulnerabilities target Adobe Reader specifically (CNET).

The question that many people are asking is, “how did it get this bad?” We’re going to risk beating a dead horse when answering this question, since a lot of the problems with Adobe Reader can be traced back to an issue that we’ve talked about frequently during the past few months: Disabling scripting by default. We’re constantly advocating the disabling of scripting by default, and the recent vulnerabilities found in Adobe Reader offer yet another reason why it’s a good idea to go no-script.

According to the recent advisory by US-CERT, it’s the “getAnnots()” JavaScript function in Adobe Reader that allows users to be exploited and allows attackers to execute code on the workstation remotely. 

While the obvious answer to the “getAnnots()” problem is to disable scripting, we can accept (albeit reluctantly) that having scripting disabled by default might never happen. That’s why an alternative solution would be to have a white list. Creating a white list is not only more effective, but also less time-consuming than creating a black list. Providing users with the ability to augment the white lists in their profile would afford them the flexibility to view non-mainstream sites like NovaInfosecPortal.

But this is one of those topics where we really want to put a call out to all of you about what can be done to help fix the current problems associated with scripting, and how some of these problems can be avoided in the future. What are you currently working on (whether at work or at home) to make sure that you, your family, and your workplace isn’t taken advantage of due to scripting? Leave a comment or send us a tweet @grecs.

###

If you’re looking for some additional ways to keep your company—and yourself—a little safer, we’ve put together a handy list of books that might do the trick.