Page 1 2 3 4 5 6 7 8

  Interest Notes Home
       
  Part 3: Gramm-Leach-Bliley Act: Creating a Security Policy
By Paul Gilliam, Vice President Information Security
Boulder Technology Partners, Inc.

Twenty-five years ago, most computers were centralized, maintained in specialized, secured rooms and technical support personnel made sure they were carefully managed and physically secured. Computer security threats were rare and were more concerned with authorized users misusing accounts, theft and vandalism. These threats were well understood and dealt with using standard techniques: computers behind locked doors and accounting for all resources.

Today’s computing is radically different. Many systems are in private offices often managed by individuals or persons employed outside a computer center. Most systems are connected into the Internet, and from there around the world. Also, security threats are different today. Security professionals have always advised "don't write your password down and put it in your desk". While that is still true, with world-wide Internet connections, someone can get into your system from the other side of the world and steal your password in the middle of the night when your office is locked up. Viruses and worms can be passed from machine to machine. The Internet allows the electronic equivalent of the thief who looks for open windows and doors; now a person can check hundreds of machines for vulnerabilities in a few hours.

Decision makers have to understand the security threats that exist, what the risk and cost of a problem would be, and what kind of action they want to take (if any) to prevent and respond to security threats. The security related decisions you make, or do not make, will determine to what extent your network is secure, how much functionality your network provides, and how easy your network is to use in support of your core business. However, you cannot make good decisions about security without first determining what your security goals are. Until you determine what your security goals are, you cannot make effective use of any collection of security tools and processes because you will not know what to check for and what restrictions to impose.

For example, your goals will probably be very different from those of a university. Universities generally make operation of their systems as simple as possible, which implies that the network will often be as open as possible. While this does make it easier to use, it also leaves access to those systems, and others through them, potentially open to any authorized or unauthorized user who wants access. So the first step is: What are your goals towards securing your network? What security risks are you willing to accept or not accept to provide services to your clients as well as protect the data that is on your network?

In determining your goals for security the following should be carefully considered:

  1. Each service offered to your clients and users carries its own security risks. As a result of your risk assessment you may determine that for some services the risk outweighs the benefit. You may choose to eliminate the service rather than try to secure it.
  2. The level of security will affect how easy it is to use. The system that is the easiest to use provides access to any user without any security. Requiring passwords makes the system a little less convenient, but more secure. Requiring a high-tech device to monitor and grant access makes the system even more difficult to use, but much more secure.
  3. There are many different costs to security. Some are directly related to the amount of funds such as the cost of purchasing security hardware and software. There are other costs that are related to performance such as encryption and decryption mechanisms as they may affect the response time. There are also many levels of risk: loss of privacy, loss of data, and the loss of service and resources. Each type of cost must be carefully considered against each type of loss.

Once your goals for security have been identified they should be communicated to all users and support personnel through a security policy. A security policy is a formal statement of the rules that are to be followed by users who are given access to your technology and information. The main purpose of a security policy is to inform users of the requirements for protecting technology and information assets. To be effective, as a minimum the security policy should address the following items:

  1. Guidelines which specify required, or preferred, security features. These should supplement existing purchasing policies and guidelines.
  2. A Privacy Policy which defines reasonable expectations of privacy regarding such issues as monitoring of electronic mail, logging of keystrokes, and access to users' files.
  3. An Access Policy which defines access rights and privileges and specifies acceptable use guidelines for all users.
  4. An Accountability Policy which defines the responsibilities of users and provide incident handling guidelines to inform users what to do and who to contact if a possible intrusion is detected.
  5. An Authentication Policy which establishes trust through an effective password policy, and by setting guidelines for remote location authentication and the use of authentication devices.
  6. An Availability statement which includes contact information for reporting system and network failures.
  7. A Violations Reporting Policy that indicates which types of violations (e.g., privacy and security, internal and external) must be reported and to whom the reports are made.
  8. There may be other specific regulatory requirements that affect some aspects of your security policy. It is always recommended that any security policy created for your business be reviewed by legal counsel.

The goal in developing a security policy is to define and publicize to the employees your expectations of proper computer and network use and to outline the appropriate procedures to prevent and respond to security incidents. Deciding the proper procedures during the confusion of an "incident" can be a costly decision for your business.

Paul Gilliam can be contacted by email at

paul.gilliam@bouldertechnologypartners.com

Top of Page

 

Table of Contents

Celebrating Homeownership Achieved Though Integrity Based Lending
By Greg Osborne, Chairman of the Board

Governor Bill Owens Addresses May CMLA Luncheon

Chris Holbert Elected to the Board of Habitat for Humanity of Colorado

2nd Annual Northern Colorado Lending Fair Recap

Part 3: Gramm-Leach-Bliley Act: Creating a Security Policy

Marketing Tip from ALCC

Community Initiatives

Fall 2004 CCA CML course schedule

Click here to send your feedback about the CMLA e-Newsletter