Which hosts running older OSes will be blocked by min. stds?

Hi Craig,

At 01:34 -0700 2004-06-23, Craig Lant wrote:
>Our current standard for what we block includes only hosts that pose
>a threat. This policy changes that standard slightly to include
>hosts that are *likely* to pose a threat. Who makes that judgment
>call? Ultimately, the CISC does. Though in an emergency, I would
>make it with input from SNS, CNS, and others.
>...
>What this means in practice is that, if a particularly nasty worm is
>released that includes code to attack older/unpatched versions of
>Windows, Mac OS, Linux, or whatever, we could immediately block all
>vulnerable hosts until they can be secured. Many security experts
>would change that "if" to "when". But, the point is that we would
>rather block a thousand hosts until they're patched or upgraded than
>wait and block a thousand hosts until they're rebuilt.

   In the hopes of clarifying this further ...

   Craig (and all): what might this mean in practice for hosts running
older versions of Windows, Mac OS, and various Unix and Linux
distributions for which security patches are no longer available from
their respective vendors?

   Will all of these hosts be:

   1. Allowed to operate 'as is' on the campus network after May 1, 2005?

   2. Globally blocked from operating, and thus required to be upgraded or
      replaced ... ideally prior to that date :-)?

    or

   3. Either allowed or blocked, based on some determination of the
      risk they pose (e.g. "hosts that are *likely* to pose a threat")?

      And if so, will this determination be based:

      a. Generically on the OS they're running, perhaps due to
         vulnerabilities for which no patches are currently available?
      or
      b. Specifically for individual hosts that pose a threat?

   My reading of your wording above is that it's closest to 3.a. ...

Thanks!

Aron Roberts
Workstation Software Support Group

--
Date: Wed, 23 Jun 2004 01:34:26 -0700
From: Craig Lant <craig@ack.berkeley.edu>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: micronet-list@listlink.berkeley.edu
Subject: Re: [Micronet] Upgrades and Security Requirements...
Sender: owner-micronet-list@lists.berkeley.edu
Precedence: bulk
Status: RO
OK.  First, I think I can safely speak for both SNS and CISC when I 
say that no one is suggesting that it would be at all useful for SNS 
to implement mass blocking based purely on software versions or patch 
levels.  Yes, the policy says we can and under extraordinary 
circumstances we might have to do that.  But, that's not the plan.
The first step in our plan is to start scanning more aggressively as 
soon as we get some of the technical issues worked out of that.  As 
we discover hosts that are out of compliance with the standards, we 
will notify departments through their security contacts as well as 
individual users of AirBears, SHIPS, and LIPS.  As we identify areas 
that are particularly bad, we will try to work with those responsible 
and find ways to help them improve their security profile.
Our current standard for what we block includes only hosts that pose 
a threat.  This policy changes that standard slightly to include 
hosts that are *likely* to pose a threat.  Who makes that judgment 
call? Ultimately, the CISC does.  Though in an emergency, I would 
make it with input from SNS, CNS, and others.
What this means in practice is that, if a particularly nasty worm is 
released that includes code to attack older/unpatched versions of 
Windows, Mac OS, Linux, or whatever, we could immediately block all 
vulnerable hosts until they can be secured.  Many security experts 
would change that "if" to "when".  But, the point is that we would 
rather block a thousand hosts until they're patched or upgraded than 
wait and block a thousand hosts until they're rebuilt.
As to the idea that "no network-accessible vulnerabilities requiring 
patches are likely" for <such and such>, so we should give a blanket 
exception to <such and such>, I don't see that as valid.  But again, 
it's ultimately up to the CISC to grant exceptions.  So, give it a 
shot.  See what they say.
Now, all this upgrading will certainly cost money.  IS&T is doing 
their best to minimize that cost.  But, it will still be non-trivial 
for many departments and units across campus.  As Gordon pointed out, 
the drafters of this policy, along with literally hundreds of others 
from across campus, agonized over this.  The key question is: Which 
costs more, upgrading and securing our computers or not doing that. 
With cost estimates for dealing with some of the more recent worms in 
the hundreds of thousands of dollars, the answer seems obvious.  We 
simply can't afford to continue ignoring this and we have taken what 
we believe is the most appropriate next step with this policy.
	Thanks,
		Craig
                           Craig Lant
-------   Campus Information Systems Security Officer   -------
     -----     University of California, Berkeley     -----
               510-643-0596    craig@Berkeley.edu
------------------------------------------------------------------------
The following was automatically added to this message by the list server:
For information about Micronet, including subscribing to
or unsubscribing from its mailing list and finding out
about upcoming meetings, please visit the Micronet Web site:
<http://micronet.berkeley.edu/>.
------------------------------------------------------------------------
The following was automatically added to this message by the list server:
For information about Micronet, including subscribing to
or unsubscribing from its mailing list and finding out
about upcoming meetings, please visit the Micronet Web site:
<http://micronet.berkeley.edu/>.