//
you're reading...
Security

To Patch or Not to Patch

I recently got a call from a security journalist who wanted my recommendations for the “Best Practices” in system patching. I explained patiently to Prince Wu, uh, urr, the journalist, that I don’t patch my systems at all. My home file server is still running OpenBSD from 5 years ago (and it works fine) and my Solaris machine is running some ancient version that is compatible with some of the development software I rely on. I pretty much set my network up, and don’t screw with it. In return, it pretty much just works unless a cable jiggles loose or the dogs chew on something.
-Marcus J. Ranum

This is one of the best ideas in computer security that I’ve heard in ages. It’s true that while continuously patching your programs allows you to have the latest technology, using older versions gives you better stability. Patching is an expensive and painful process. And besides, this is also one of the reasons why computers are getting out of the programmers’ control. We do not know our own systems anymore. At least not the same way that our predecessors do. What we really need is not what the market claim to be the latest and, I strongly doubt, the greatest softwares available. Patches are just proof of inperfection, which is, thinking about it, brought by patching in the first place. If we know our systems very well, we will be able to come up with better codes.

There is a reason why MJR is one of the top specialist in this field. Because he knows that the when developing a software you just have to “write it and forget it”.

Advertisements

About princess of antiquity

Abbi Cabanding is a member of the Security Bloggers Network and had been blogging on information security since 2006. She is also a member of the Association for Computing Machinery. She studied Computer Science and Fine Arts at the University of the Philippines - Diliman.

Discussion

4 thoughts on “To Patch or Not to Patch

  1. Test-Driven Development?

    Posted by nightfox | October 8, 7:55 pm, 7:55 pm
  2. No, i don’t think that’s such a good idea. Not when it comes to security, atleast.
    best explained by this BASIC code from MJR:

    10 GOSUB LOOK_FOR_HOLES
    20 IF HOLE_FOUND = FALSE THEN GOTO 50
    30 GOSUB FIX_HOLE
    40 GOTO 10
    50 GOSUB CONGRATULATE_SELF
    60 GOSUB GET_HACKED_EVENTUALLY_ANYWAY
    70 GOTO 10

    the code/systems/implementation is not better by design but merely toughened by trial and error. This is doomed to failure. I mean, if “penetrate and patch” is so effective, then we would’ve ran out of security bugs years ago. 😀

    Posted by abbi | October 8, 11:03 pm, 11:03 pm
  3. Test driven development is always a good idea but its effectivity depends on the type of tests you use. If you test for a system’s security and integrity, then chances are, your final output may very well reach a higher level of security.

    The thing is – a full secure system is impossible. There will always be flaws in systems since these systems are only created by human beings and last I’ve checked, they are not flawless.

    Ideally, an entire system is used to replace a defective one. Patches make it quite difficult to manage but it is often the most cost effective. Imagine having to release a full Windows XP version just so you can get one or two bugs fixed? Not effective.

    As long as software engineers remain imperfect, your systems will continue to be imperfect as well.

    Posted by rom | October 9, 11:42 am, 11:42 am
  4. I agree that systems will never be perfect but if we design a system that is secured by design and with flaw-handling in mind then the problems should be minimal.
    Most of the patching in software industry involves just adding a new code to mask away the flaws instead of removing the flaws itself.
    There are a handful, like PostFix, Qmail, etc, that were engineered to be compartmented against themselves, with modularized permissions and processing, and – not surprisingly – they have histories of amazingly few bugs. What I’m saying is, we have to be very vigilant when developing a software. We don’t really need to know every single buffer overruns that are being exploioted but we have to always assume that they’re there. I’ve even encountered a taunt in a sourcecode that went something like:
    /*Trying to outsmart me? Yes, I thought you might do that. -bob*/

    Posted by abbi | October 9, 5:09 pm, 5:09 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Sin of Silence E-Book


SIN OF SILENCE:
THE STORIES OF OUR DAYS
download:
single-page view
two-page view

On Wordpress

  • 94,872 readers

Subscribe via FeedBurner

Enter your email address to receive notifications by email.

Princess of Antiquity on Twitter

  • RT @AltTeamAFP: The quickest way to acquire self-confidence is to do exactly what you are afraid to do. Sleep well Philippines, we got your… 1 week ago
  • I have a limit and when you reach it I dismiss you from my life. It's that simple. 1 week ago
  • I don't get mad. I get distant. 1 week ago

RSS Princess of Antiquity on Tumblr

  • An error has occurred; the feed is probably down. Try again later.

Creative Commons

Creative Commons License
Original content in this work is licensed under a Creative Commons License.
%d bloggers like this: