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



Relevant Pages

  • Re: Building high available and high performance web sites with MS
    ... clustering is just for failover? ... Would have lets say 3 servers, ... have 3 sql servers with the same info and then a high available distributer. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Exchange Server 2003 Front-End Back-End Deployment
    ... Hehe - the old replication bit. ... You have to wait for Exchange ... I'll roll out the servers as previously stated. ... I'm personally not a big fan of clustering (even though ...
    (microsoft.public.exchange.admin)
  • Re: New To Clustering - Please help
    ... You have a client with under 75 users. ... They have a domain with Exchange 2000 ... but nobody beats HP for servers and support. ... MVP - Windows Server - Clustering ...
    (microsoft.public.windows.server.clustering)
  • Re: Synch / Cluster as Disater revover opt?
    ... Actually you can do geographically dispersed clustering across a WAN, ... Over a WAN, you would need to use VLAN hardware ... Windows clustering and geographically separate sites ... To lesson the cost I figured I would upgraded my live servers then send ...
    (microsoft.public.windows.server.general)
  • Re: SQL 2005 servers with multiple instances
    ... Have you checked out the latest possible hardware configurations for SQL ... I have built two-node clusters with dual-proc dual core brand name servers ... Clustering is no ... controller is being shared for the Live data and the Redundant data/logs. ...
    (microsoft.public.sqlserver.setup)