System Security Policy: What it IS and Why We Need It

Our concerns about system security continually increase - and not without justification. Crimes reported to the Computer Emergency Response Team (CERT) more than doubled in each of the last three years, increasing from 252 in 1990 to 52,648 in 2001. And if the security threats from the outside aren't enough, colleges and universities face the additional challenge of protecting themselves from accidental and intentional threats posed by an exceptionally intelligent and curious internal community. The academic world promotes curiosity, fostering an environment conducive for inquiring minds to peek, poke, peer and penetrate.

What is a System Security Policy?

A System Security Policy is a document that establishes our priority for securing our systems. It prevents the loss of assets. It identifies and mitigates our risks, and minimizes the impact of security breeches on organizational assets. A security policy identifies the assets we're trying to protect, documents the vulnerabilities posed against those assets, and plots a strategy to protect those assets. To what assets do we refer? Assets refer to hardware, software, intellectual property, private information, documentation, goodwill and reputation, people and skills.

The security policy is a living document that organizations must modify as information assets change and as the threats against those assets change. It provides a framework for which we select, implement and configure our systems and networks. Finally, the security policy provides standards of use for the organization's resources, removing excuses for unacceptable behavior. A security policy is more than just a document that specifies rules and concepts of how to protect our systems. It's a process. The security policy is a series of decisions balancing the need for security versus cost, capability, and convenience.

The security policy provides a vehicle for us to make decisions with regard to other important policy matters:

  • It affects budgeting for security-related measures and all IT projects.
  • It affects how we select, configure, back up and manage our systems.
  • It determines how we react to a security breech.

Why do We Need a Security Policy?

The security policy serves as a blueprint for our security architecture. We need to make sure that our policies are followed, so we must document them. After all, an unwritten policy is no policy at all. We further need to audit practice against policy to ensure adherence, so we know our security practices are effective. Lastly, we can review the written policy to ensure that our protection is up-to-date and relevant.

How do we know our systems are secure without defining what "secure" means? An organization can say, "we've never been attacked", but how do we know? Digital assets are so extensive that there is no practical way to check them individually. Without a policy and procedures to implement it, we can't really know if we've been attacked. The security policy doesn't just define what "secure" means-it identifies how it's measured.

The security policy process requires us decide our institution's tolerance for risk. We then determine the resource commitment we're going to make to ensure we reach that level of acceptable risk. As part of this process, we balance the need for security with the need for capability; the cost of securing systems versus the cost associated with security breeches; the need to keep private information confidential, to keep systems available and data sources reliable versus the inconvenience and practicality of our security policy ramifications.

As part of the security policy process, we ask, "What are we trying to protect?" Do we have sensitive data like credit card numbers, ACH (direct deposit) numbers, patient records, social security numbers, financial records, student records, donor history, and investment information? Do we have proprietary research data or other intellectual property we must protect? Do we have information that health insurance portability and accountability act of 1996 (HIPAA) mandates us to protect?

Lastly, in a crisis, unprepared staff can make precipitous and inappropriate decisions. The security policy process not only reduces such opportunities, it also should dictate who has the autonomy to make which decisions under what circumstances.

What are the Characteristics of a Security Policy?

Most important is that the policy be both accepted and enforceable. Security breeches inevitably follow if our systems' users don't follow the rules. Furthermore, if we can't enforce policy, what makes us think that people will follow the rules?

The security policy must be useful and easy-to-understand. We want to structure the security policy so that we can easily locate important information. Top-level management must sanction the document as "official". The document must be carefully worded to avoid confusion. The policy should have definitions included to eliminate ambiguity from the document. The policy's wording can determine criminality should someone violate its precepts. The document should provide guidelines rather than procedures. (Often procedures follow naturally from the guidelines). Each revision of the security policy should have a version number and date of revision.

One feature often forgotten by security administrators is that the policy should be well advertised and well understood. We can accomplish this through publicity and training. The policy itself should document how the document should be publicized. We publish applicable sections to those entities for which those sections apply. We can do this, because we have organized the policy into discrete sections. One important component of advertising is to mandate a logon banner. A logon banner mandating appropriate use of systems eliminates the "I didn't know" excuse for security breeches. In many states, lack of a logon banner prohibiting unauthorized use limits criminal prosecution.

We should review our security policy at least once per year to ensure that it is up-to-date. We should also specify other times that would be appropriate for review-for example, it would only follow that we mandate a review of our security policy after a major security incident occurs. Of course, in our tightly worded policy, the term "major incident" would be well defined!

Who Should Get Involved?

To start, organizational leaders must embrace the concept of a security policy. Without leadership from the top, the resources and commitment necessary to implement the policy will not follow. People won't adhere to the guidelines set forth in the policy without the clout of your organization's leadership. Departmental leaders must get involved because individual departments have their individual technology requirements and their individual security requirements. Students and faculty must get involved, because they too have a stake in those security decisions.

We need to publicize the security policy to everyone. Analogously, if motorists don't know not to turn right from the left-hand lane, then wouldn't we have more accidents? Likewise, our security policy must be distributed to and understood by all levels of the organization.

Lastly, we need the organization's counsel to review and bless the document to ensure that it is both legal and consistent with the institution's other policies.

Rights and Responsibilities:

For each group involved, we need to specify rights and responsibilities. For users, we need to specify account use and software and data access. Users must also know the rules about passwords (not sharing them, not writing them down, etc). Users should also know their rights, such as their right to privacy and under what circumstances they will lose those rights (and which individuals may revoke those rights).

For system managers or network administrators, we must specify backup procedures, system configuration guidelines, authentication requirements, and auditing and monitoring requirements. Someone must be responsible for overseeing users to make sure that they live up to their responsibilities. Someone must be responsible for overseeing users to make sure that users live up to their responsibilities-we must also specify who will oversee the overseers.

So What do We Put In Our Security Policy?

Our security policy must first inventory our systems and assets. For each asset, we need to discuss the four phases of security:

  1. Vulnerability
  2. Prevention
  3. Detection
  4. Recovery

1. Vulnerability:

Discuss, in detail, the vulnerabilities that pose threats against each system. Knowing the threats, we then need to determine the methods to prevent intrusion. Normally we try to protect ourselves in the following areas:

  1. Authenticity: to ensure that whoever accesses our systems is who we think they are.
  2. Privacy: to make sure that only authorized individuals can access confidential information.
  3. Integrity: to make sure that the information is not tampered with or otherwise altered.
  4. Availability: to ensure that authorized individuals can access systems they need.

For each threat, the security policy will address the probable impact and the maximum impact of each kind of event.

As part of our vulnerability assessment, we need to identify the value of each asset, indicate what the loss of that asset would represent, and how it would be replaced.

2. Prevention:

Knowing the vulnerabilities, we can then prescribe preventive measures. Give preference to technology for preventive measures because technology is consistent in how it will deal with an issue. Then again, humans always set up technology, so there is that point of contention! We need to prescribe measures to authenticate users and systems. Notice that the other three phases of security depend on authenticity, so we must place great attention to authenticating our users. Passwords have become almost trivial to crack or intercept, so one day soon they'll be outdated altogether in favor of:

  1. Security tokens-synchronized, ever-changing passwords through password token devices; or
  2. Biometrics-authentication by use of some unique biological characteristic like fingerprints, retina scans etc; or
  3. One-time passwords-passwords used but one time and changed after each login. This makes it nearly impossible to guess passwords

As part of the prevention process, we need to specify acceptable use. Much damage is done to systems through inappropriate use. Without specifying acceptable use, Universities invite unnecessary damage to their computer systems. As implied earlier, our policies must be adhered to and enforced. Our policy must specify who will audit adherence and what penalties apply to each kind of infraction. We must always make the penalties proportionate to the infraction. We must treat accidents differently from malicious conduct. Again, we must define terms like "malicious" and "accident".

3. Detection:

Network administrators often forget that detection is just as important as prevention. If someone is in the process of attacking our systems, what will we do? If we determine that someone has already compromised our systems, what will we do to limit the damage? Once damage is mitigated, how do we prevent further damage? How will we prevent future attacks? None of these questions can be answered, or even asked, without detection methods. We should define how we monitor our systems.

System logs are critical to detecting security breeches. Logging of exceptional events will allow system administrators to determine "normal" patterns of use, so that when abnormal patterns start, a security breech might have occurred. The security policy must specify how detection is to be accomplished, usually through logging and alerts. Furthermore, the policy must specify who is responsible for monitoring the logs and the alerts. Lastly, we should add failsafes to ensure that those responsible, are checked up on.

4. Recovery:

We must be prepared for times of crisis. Our security policy dictates how we handle these crises. First of all, who should we notify and by what means? Have we documented important personnel's home and mobile phone numbers?

Some of the questions we must ask ourselves:

  1. Do we let an event continue in order to catch the culprit?
  2. Have we secured the log files to preserve an audit trail of what happened? Better yet, do we ensure that an attacker cannot destroy log files?
  3. Do we shut down some critical services to prevent further damages?
  4. Do we contact legal authorities?
  5. What type of backups must be maintained to ensure a full (or at least acceptable) recovery? Better yet, have we tested our recovery procedures to ensure acceptable recovery?

Answering these questions is part of the process that the security policy takes us down. Having prepared the answers avoids precipitous, if not inappropriate, action during the time of a crisis.

Once we recovery from an incident, we need to use the information gathered in the recovery and detection phase to improve our understanding of the vulnerability phase. As part of this feedback loop, we need to ask the following questions:

  1. Was the policy followed?
  2. How can the policy be changed to prevent similar events in the future?

What are the Special Challenges Facing Academic Institutions?

Academic institutions face special challenges not faced by commercial or government entities, including:

  1. They are comprised of many autonomous entities who have complex trust relationships with each other.
  2. They have difficulty in controlling end users.
  3. The culture cultivates freethinking and "open" access to information.
  4. They have a "network anarchy"-that is, just about anyone can attach to the network at any time. Furthermore, students have little organized supervision to control inappropriate behavior.
  5. The university serves as a(n):
    a. Research body
    b. Corporation
    c. Internet Service Provider
  6. Colleges and universities must analyze each of these functions to determine the proper stance to take with regard to security.
  7. On top of all that, most universities have pretty rigid security requirements.

Answering the questions involved in developing a sound security policy that balances security with cost, capability, and convenience is easier in less complex organizations.

Conclusion:

The security policy is both a journey and a destination and this journey leads to the destination of more secure systems. The security policy process involves everyone, especially top management, and all levels of the organization. It must be adhered to and enforceable. It lists our information assets through four phases of the security process (1) vulnerability, (2) prevention, (3) detection, and (4) recovery. It protects our assets in the areas of (1) authenticity, (2) privacy, (3) integrity and (4) availability.

Resources on the Web:

The following are resources that you can find on the web:

http://www.sans.org/newlook/resources/policies/policies.htm: from the System Administration, Networking and Security Institute-probably the best resource for security policies. Provides dozens of resources and links to sites that instruct on how to write an effective security policy.

http://www.brown.edu/Research/Unix_Admin/cuisp/: A compilation computer policies from institutions of higher education-a "must" resource for colleges and universities.

http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2196.html: An official Internet request for comment, a guide to developing computer security policies and procedures for sites connected to the Internet.

http://secinf.net/info/policy/AusCERT.html: Site security policy development-outlines issues one should consider when writing a security policy.

http://downloads.securityfocus.com/library/Why_Security_Policies_Fail.pdf: A white paper from Control Data Corporation on "Why Security Policies Fail," or better named, the characteristics of successful security policies.

http://secinf.net/info/policy/netsec1.htm: How to develop a Network Security Policy