Extending Our Goal Set

As I complete the intrusion-recovery checklist for a series of break-ins, I sit here contemplating next steps for SAGE. I am now at a university, in an environment very different from those I've been in for most of my career. In the past I have "owned" the network, servers, and clients. If any user had root access (or equivalent), the machine was on a separate firewalled segment, or I worked closely enough to trust the individual. Now, I have no access to the wiring closets nor their contents, except as a general user of network services. I have control over only a small number of machines, and access of any kind (often excluding root) to only a small percentage of the machines on my net. There are no promulgated policies; my docs are still sitting on people's desks for review.

Three machines were compromised this week, all by the same attack method, although by two unrelated groups of attackers. I had no access to any of those machines, and in fact wasn't even aware of the existence of one of them (installed on the network by the owner and the university's networking support group). The attackers in both cases also tried machines my group does control, all of which fended off the attacks and reported to us. We observed many other attacks, but these used "old" methods and failed to gain access to those machines logging the attempts.

Suddenly we were heroes. We went in and collected legal evidence, proving to the machine owners the extent of damage done, then rebuilt the boxes per industry standard. We now have "shared" control, which probably means the users do whatever they desire, and we get the blame when that causes a problem.

What exactly are the issues here, and how can SAGE help?

• How do we get policies implemented?
• What do we do if we can't get policies implemented, or in the interim while review is under way?
• How should we deal with responsibilities split between system and network admins, especially when they don't agree on requirements?
• How should we deal with responsibilities split between system administrators and user-owners who have root/administrator access?
• How do we deal with requirements for sharing facilities/services on our own networks to untrusted boxes, let alone remote nets?

I have no immediate authoritative and conclusive answers. I do think, however, that SAGE is the right place to establish those conclusive answers. Many of us are faced with similar situations, and these problems affect the industry as a whole. They are among the kinds of problems SAGE should tackle.

How? Well, thus far SAGE has been concentrating on bootstrapping itself. Current emphasis is on the advancement of the individual sysadmin through creation and operation of conferences and workshops, ethics, certification and educational projects. It is time to start looking at what we can do for the industry in addition to supplying qualified sysadmins. The Short Topics booklet, System Security: A Management Perspective, is a start in this arena, but we need to plan out a strategy for far more and bigger goals. What might those goals be? Some possibilities:

• Raising the security standard of the average site so high that "casual" cracking ceases to be of interest
• Raising the consciousness level of the average site's management regarding the requirement for an appropriate level of applied system administration resource and security effort
• Creating a trusted place that organizations or individual sysadmins might turn for immediate assistance for any form of sysadmin problem, and making it known and accepted
• Establishing minimum "standards of practice" guidelines ­ a tricky and controversial area

We have made some progress already, such as Short Topics booklet A Guide to Developing Computing Policy Documents, but we are still in the very early stages of addressing the scope of problems faced by the "average" sysadmin. Our approach so far has been to provide an overview of the methods we might apply to the "black art" of system administration, and to assume that local sysadmins will know how to follow through. Perhaps most of us old-timers can do this, perhaps not. Can newer folks do so, or are they in need of more concrete examples? The new "How-To Notes" series in ;login: should address this to some degree, but is that enough? It seems that uncountable sites out there have site sysadmins who are not SAGE members. If they don't take our soon-to-be education programs, will they be needing checklists? Is it right that we provide such a thing? I'd like to see some discussion on these questions. Don't hesitate to write for ;login:, to <sage-members>, or directly to me.

By the time you read this, another election will be behind us, and a new Executive Committee will be setting new directions. While they do so, it is not too early to begin thinking about what you might wish to do to prepare for the committee that will follow them and how to get those projects started. It might even be too late in some cases, Other organizations are attempting to make, codify,
or otherwise influence our profession from their own viewpoints, typically profit-centered rather than sysadmin-centered. We can't drop the ball for a moment, especially at this point in our development.