Re: Uptime vrs. security policy (Was: Re: Sun Solaris login bug patches out)

From: Cy Schubert - ITSD Open Systems Group (Cy.Schubert@uumail.gov.bc.ca)
Date: 01/03/02


From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To: bergman@merctech.com
Date: Wed, 02 Jan 2002 15:15:55 -0800

In message <23372.1009911482@piquin>, bergman@merctech.com writes:
>
>
> In your message dated: Mon, 31 Dec 2001 10:54:28 PST,
> The pithy ruminations from Cy Schubert - ITSD Open Systems Group on
> <Re: Sun Solaris login bug patches out > were:
> => In message <Pine.LNX.4.05.10112292206020.5128-100000@jp-gp.vsi.nl>,
> => Jan-Philip
> => Velders writes:
> => >
> => > > Date: Thu, 27 Dec 2001 14:24:16 -0800
> => > > From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc
> .ca>
> => > > Subject: Re: Sun Solaris login bug patches out
> => > > [ ... ]
> => >
> => > > A UNIX box with a high uptime is indicative of that box not being
> => > > maintained with the latest security patches.
> => >
> => > or in my book: a system which has been set up securely !
> =>
> => So a system that hasn't been rebooted to install kernel or libc
> => security patches is just as secure as one that does not have the
> => patches?
> =>
> => I'm excluding clustered systems from this arguemnt.
>
> Um, why? A tightly clustered system (using Sun Clustering, VCS, etc., as oppo
> sed
> to a loosely "clustered" group of machines managed via load balancers, extern
> al
> application servers, etc.) usually should have all machines at the same patch
> level, particularly for things like kernel services. In that case, you'll see
> uptime of individual machines that's not exceptional. Of course, the advantag
> e
> to clustering is that the reboots can be staged so that they don't affect
> user-visible operations.

Exactly. That's one of the reasons to cluster. I did this in a
previous life as an MVS (IBM mainframe) systems programmer. Our AIX
team does this with the AIX cluster. Our VMS group does this as well.

> =>
> => >
> => > > IMO I think it's a shame that this attitude is part of the UNIX
> => > > culture.
> => >
> => > Why ? UNIX systems have been growing into a role, where downtime (no
> => > matter what amount) is becoming more and more *unacceptable*.
> => >
>
> [SNIP!]
>
> =>
> => It's been documented that historically 80% of exploits are perpetrated
> => by insiders, e.g. employees. Your firewall protects you from the 20%
> => of the attacks that come from the outside. On the inside you need to
>
> I'm not taking issue with your numbers here, but you're confusing exploits wi
> th
> attempts. While the vast majority of successful exploits may come from inside
> rs,
> I think that an overwhelmingly greater number of exploit _attempts_ come from
> outsiders. That "20% of attacks that come from the outside" is probably the
> results of hundreds of times more attempts than the 80% of insider exploits.
> If
> not for good firewalls and security that's biased against attacks from the
> outside, we'd see the stats on external vrs. insider exploits reversed. I'm n
> ot
> saying that you can ignore the internal threat, but that should also be much
> easier to quantify, judge the risk, and manage through non-technical means th
> an
> the external threat.

You raise a good point. The only numbers I've seen are successes.
Come to think of it, worldwide it might be difficult to quantify the
number of external attempts.

Sites that do have firewalls don't normally firewall servers within
their own network, though the practice of putting sensitive servers
behind yet another firewall to protect them from "internal" threats is
growing (I do this for sensitive or mission critical servers). For
most applications, protecting internal systems is performed through
good policy and security practice. IMO this includes regularly
scheduled software maintenance + any required emergency security
patches.

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD
Ministry of Management Services
Province of BC
                    FreeBSD UNIX: cy@FreeBSD.org