Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


Linux in the Enterprise

CYA for System Administrators

Things to keep in mind in our litigious society

04/19/2000

In the last Linux in the Enterprise column, Linux Tools For Network Analysis, I mentioned some things to consider when you're using network scanning systems on your company's network. Doing the wrong thing in the cause of making your network "more secure" can land an unlucky administrator in a duel with the legal system. This is more likely when your actions come as a surprise or are viewed in a bad light by others who question your authority or motives to be doing what you're doing. With all the sound and fury in media about evil hackers, it's a good idea to consider how to protect yourself ahead of time.

System Administration is a job with few parallels in the world. In many jobs, individuals have control over systems and infrastructure critical to the lives and jobs of others, including running mass transit systems, police work, air traffic control. However, in very few other professions do the people who control the infrastructure also have the ability to read the e-mail, modify the spreadsheets of, change the credit ratings, or deny access to the people using the infrastructure. Another difference is that in many of those more established fields, regulations are in place to protect the systems' users and the administrators who run the systems.

The sheer power of the systems administration function intimidates many users and management types when they stumble into the realization of just what can be done with root privileges. The question that shakes out of this is pretty simple: How can I do my job, run a system or network safely and securely without winding up on the wrong end of a subpoena?

Know your responsibilities

Some system administrators inherit large systems, others watch them grow up around them. Whichever situation you find yourself in, it's a good idea to make sure that your role and your responsibilities are fully specified.

By "fully specified" I don't mean that you should have your boss tell you what keystrokes you are responsible for typing, but your job description should be complete and list not only the hardware and software you support, but what management areas that role includes. Many administrators have a blanket job description that reads something like:

Manage and maintain workstation and server environment in support of development and production systems.

Sound familiar? Most system administrators work under this kind of job description, but it includes a lot of room for interpretation, which could mean trouble if someone decides to make you a target.

A more complete job description might be along the lines of:

Manage and maintain workstation and server environment in support of development and production systems including:

The last item might also include:

This job description spells out responsibilities clearly without tying the hands of a system administrator. By working within its limits, a system administrator guards against being criticized for over-extending their reach or activities in an unauthorized fashion.

It is important to read between the lines about things not explicitly in the job description. Left out are tasks like "enforcement of password standards" or anything about "network scanning." Of course, your job may include such activities, but it's better to have an explicit understanding between yourself and your management with regard to exactly what kinds of tasks and responsibilities are included in your job.

Know your company's policies

Even if you have a complete job description, it's a good idea to have a good understanding of your company policies about information security. Most large companies (and many startups) have such a policy, and it's usually quite detailed in terms of how information must be secured (especially for customer data like credit card information and the company's confidential documents) and what kind of firewall must be used to connect to outside networks and what kind of traffic (protocols) may transit such firewalls.

If your job description includes (or you think it should include) the responsibility to enforce password safety or the ability to look for unauthorized activities or services on your network, it's important that you check the official policies to make sure you are not going to cross one of those management lines that create legal problems. If your company doesn't have any policies in this area it doesn't mean you're off the hook and can do what you want. In the legal maze of corporate law it often is the case (especially when things get to court) that much like a well-run firewall, "that which is not explicitly permitted is denied." It's not a good idea to test the waters by doing something just because the corporate handbook doesn't explicitly state that you can't.

A better strategy is to help your management craft a well thought out policy for your company so that there is no ambiguity in what can and cannot be done on your firm's networks and systems. In doing so you will save yourself, and those who follow you, a lot of pain and suffering.

Know your limitations

"A man's got to know his limitations" is a classic line that every Clint Eastwood fan knows by heart. In the world of system administration it's a good phrase to memorize. In reality there are situations where either:

In such a case it's a good idea to know your limitations and use very conservative judgment on how far to go when your are securing your machines, looking for bad passwords, or even using network tools to fix problems. If the political situation is touchy make sure you get something in writing from a manager (the higher-ranking the better) authorizing your actions so that you can point to it if anyone makes an issue of what you are doing.

Additionally, security work should be something that you receive authorization and indemnity for from the highest level of the company for which you are consulting. I never do security work on the authorization of a mid-level manager. Having a letter of authorization from the executive office as well as the firm's corporate counsel can keep you out of the kind of hot water that can cook your goose.

If you are a consultant, all of the points mentioned here apply to you "times 100." Consultants are easy scapegoats when sacrifices are needed on company altars. Having explicitly spelled out contracts are essential to both ensuring that you know what you are supposed to be doing, as well as providing boundaries that both you and your client will be reluctant to cross.

Liability Insurance

Most major insurance companies offer some form of liability insurance to professional consultants.

The IEEE and other professional organizations also offer liability insurance to their members.

Consultants should also carry liability insurance on the order of US$1 million to $2 million, to ensure that an angry client does not financially devastate them. If you are (as I am) a security consultant, you should carry even more insurance ($5-10 million) since your work, especially in network intrusion tests and related security analysis, can cause unintended system disruptions of the client's systems and such interruptions, even though not caused maliciously, can incite some corporate lawyer to go after you -- even if you have permission for whatever tests or analyses you are performing.

Systems management can be intellectually challenging, but with the litigious climate we live in these days, we must make sure that we operate within well defined boundaries. The fallout from failing to respect those boundaries can be quite expensive both personally, financially and professionally.

David HM Spector is President & CEO of Really Fast Systems, LLC, an infrastructure consulting and product development company based in New York

Read more Linux in the Enterprise columns.


Discuss this article in the O'Reilly Network Linux Forum.

Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.