lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <003901c36e7f$d6c7dbf0$46145f80@crc.washington.edu>
From: cdevoney at u.washington.edu (Chris DeVoney)
Subject: Authorities eye MSBlaster suspect (long reply)

On Friday, August 29, 2003 12:22 PM, morning_wood
[mailto:se_cur_ity@...mail.com] wrote:

> shouldnt these measures been in place already?
> instead of rushing on a per-incident basis, you should be 
> implimenting these things anyway. IMHO is prudent to expend 
> some overkill during lockdown and penetration testing on a 
> system when it is deployed or periodically tested, so there 
> is a reduction during a per-incident basis.

IMHO, security is as heterogenic as the types of people or entities
connected to the Internet. Your suggestion befits a single deployment or a
range of entitles. But when adding the complexity of multiple locations,
heterogeneous systems, multiple ownership, and an open environment, security
is more complex than written policy, training, automated tools, lockdowns,
or penetration testing. 

In short, yeah, what you suggest is true but now let's talk about a part of
the real world that is examined infrequently. 

Private (and non-profit) enterprises can operate under a different set of
rules than an educational institution. By nature, a university network is an
open resource. Although segments of that network are cordoned off (and I
live in part of that cordoned segment), the vast majority are
interconnected. Additionally, faculty, staff, students, alumni, and even the
public, can use our resources. Research and sharing is a high priority.

As to the latest exploit, measures were already in place. On the medical
side, HIPAA already covers making best efforts to protect patient privacy.
For example if a machine in the medical center is compromised, it is removed
immediately from the network as soon as the compromise is discovered. 

For the remainder of university campus, if any machine compromises the
network (as in virus/worm source), its network port is disable until the
machine is repaired. But all it takes is one machine and you have generated
the incident which requires the response.

Now consider the task of maintaining patches on 20,000 hosts (5,000 in
health sciences; 15K through the rest of the Seattle campus). For those
systems running Windows, the versions ranging from Windows 95 to Win2K+3. At
best, patching is an Aegean effort. 

To complicate matters the central computing group for the university owns
only a modest fraction of this number. More than 4/5 are owned by the
various autonomous schools and departments in the university, each
responsible for their own patching and maintenance. Nor are funds available
to replace all old machines or operating systems so proclamation cannot be
issues that that the old (and normally less secure) systems shall vanish.

And just what can be locked down? Systems, both workstations and servers, in
the medical center have a strong best-practices policy. They live in a
moderately-secured area of the network. But what about anything else that
can touch them? The systems of doctors, students, and staff at home? 

How about a visiting doctor's, professor's, or even a salesman's machine?
Computers in labs where a professor and a few assistants labor on problems.
Students' notebooks? Each has been a live infection point. And I can
overwhelm this list with other actual examples that defy a homogenous
security policy.

Recall that security balances against usability and resources. While
portions of the network can be secure, an entire educational network cannot
be secured without size of an expenditures typically the domain of private
corporations. The size of expenditure well beyond the desire demonstrated by
state legislatures nationwide (and parallel government bodies worldwide).
Nor can the network be secured to an exceptionally low incident-level
without depriving your employees (faculty & staff) and customers (students
and the public) of those resources. 

And upon that subject of resources, like many other publicly-funded entities
our budget has been reduced. We are doing more with less money. No
complaint, businesses do it during downturns. So shall we. 

But my group's job enables investigators to conduct research that results in
improving medical treatment. Did I mention that every dollar spent comes
from your pocket? So, may I ask, it is more desirable to spend your money on
improving response to human disease or improving response to electronic
distress. It's strictly an allocation of finite resources, that dollar gets
spent on one thing or the other. Which do you choose?

> get educated, take some responsibility for you high paying job, 
> and quit trying to lay the blame elsewhere.

I take your statement rhetorically since zero research was conducted on my
bona fides. Nor will I breach netiquette in responding to a personal basis.

I will claim my education is expansive, I do take responsibility, my
compensation is considered moderate in the academic world.

And the blame is laid where the blame is due. No one can present
successfully to me the argument that these incidents favor us (the
corporation/institution/public/whatever) by forcing us to be secure. It is
arguing that thieves favor individuals by forcing home owners to install
locks. 

I will, however, suggest an expanded horizon in the real-world before making
blanket applications of security policy. We may be part of the same solar
system of computing but different institutions have absolutely different
orbits.


cdv

------------------------
Chris DeVoney
Clinical Research Center Informatics
University of Washington
cdevoney@...ashington.edu
206-598-6816 
------------------------






Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ