Lesson 1: Documentation

Lesson 1: Documentation

To establish your security program, you must begin with a foundation. This foundation typically comes in the form of documentation, which might be government regulations, industry standards, or other guidelines. The focus of this lesson is the information and documents required to establish your security program.


After this lesson, you will be able to

  • Select appropriate standards and guidelines from which to create your organization's policies

  • Select and create policies that make up your organization's security policy

  • Create documentation that defines the appropriate use, maintenance, and disposal of your organization's information assets

Estimated lesson time: 60 minutes


In this lesson you are introduced to some resources available on the Internet to help you formulate security policy. This lesson is not a replacement for those truly excellent resources, but the goal here is to provide enough information for you to effectively answer questions regarding organizational policy. Further, after reading this section you should have a good base of knowledge from which to research, define, improve, and maintain security policy for your organization.

Standards, Guidelines, and the Common Criteria

Standards and guidelines outline rules for governing an organization and conducting business. Standards must be complied with, whereas guidelines are generally recommendations and best practices. Standards can be driven by regulatory policy; for example, standards for public buildings codes mandate lighted exit signs, fire extinguishers, and other fire safety equipment. Compliance with guidelines is not mandatory; for example, a guideline for maintaining a Web site might be to place contact information on every page of the Web site. Organizations commonly use both standards and guidelines when developing policies.

Policies are discussed later in this lesson. Standards are sometimes called codes or regulations, as in fire safety codes or environmental regulations. Standards can also be presented as benchmarks or baselines, which were presented in Chapter 8.

A standard that is gaining popularity and importance in the world is the Common Criteria (CC), a standard for evaluating the security of computer and network devices. This standard was developed as a joint effort between organizations in France, the Netherlands, Canada, Germany, the United States, and the United Kingdom. The International Organization for Standardization (ISO) also recognizes the CC as ISO 15408.

The CC is provided in three parts, which are available at http://www.commoncriteria.org and on the companion CD-ROM. A brief description of each part follows:

  • Part 1: Introduction and general model.

    This document (approximately 60 pages) is an introduction to the CC. The document defines the concepts and principles of security evaluation.

  • Part 2: Security functional requirements.

    This document (approximately 360 pages) defines functional components and a method for expressing functional requirements. The term Target of Evaluation (TOE) is used to describe the products that are evaluated.

  • Part 3: Security assurance requirements.

    This document (approximately 215 pages) defines assurance components and a standard method for expressing assurance requirements. Part 3 also specifies the evaluation rating scale called Evaluation Assurance Level (EAL), ranging from EAL1 (functionally tested) through EAL7 (formally verified design and tested).

You can learn more about the CC by reading the 43-page users' guide titled "Common Criteria for Information Technology Evaluation User Guide" from http://csrc.nist.gov/cc/info/infolist.htm. CC documentation is also provided on the companion CD-ROM. Prior to the implementation of the CC, the United States government used the Trusted Computer System Evaluation Criteria (TSEC), which is also known as the rainbow project. Information on the project is maintained at http://www.radium.ncsc.mil/tpep. However, the United States has discontinued use of TSEC in favor of CC.

Policies and Procedures

The focus of this lesson is types of information that should be documented for your organization. For the purpose of this lesson, a policy is a document that states the goals of an organization with regard to certain areas of operation. A policy often includes procedures, which outline methods for achieving or maintaining the stated goals of the policy. A policy is a statement of what to do and a procedure is a statement of how to do it. Policies and procedures are created and used to define how organizational assets should be acquired, utilized, maintained, and discarded.

Policies regarding people as human assets typically use terms such as hired, motivated, and retired or terminated (instead of using the terms acquired, maintained, and discarded).

Security Policy

As previously mentioned, policies are often formulated in part from standards and guidelines. Policies are also derived from the business and life experience of people working with or for the organization. A security policy is a set of rules regarding access and use of an organization's technology and information assets. Security policy is often created using a series of subordinate policies.

The main purposes of security policy are the following:

  • To inform network users, technical support, and management of the requirements for protecting technology and information assets

  • To provide guidelines for acquiring, configuring, monitoring, and assessing technology assets (that is, computer systems and networking devices)

An excellent resource for learning about and implementing security policy is RFC 2196, "Site Security Handbook" You should take time to read RFC 2196 while preparing for the Security+ exam. This RFC should also be considered required reading for anyone who is responsible for establishing or maintaining the security of a network. The following sections describe the type of policies that you might expect to find in a security policy. (RFC articles can be found at http://www.icann.rfceditor.org.)

NIST Special Publication 800-12, "An Introduction to Computer Security: The NIST Handbook" covers security policy in Chapter 5, "Communications Security." (NIST articles can be found at http://www.csrc.nist.gov/publications.)

Computer Technology Purchasing Guidelines

Computer technology purchasing guidelines are used to protect the organization from equipment that could lead to a security breach. These guidelines specify security features that are required or preferred by the organization. For example, an organization might decide to require that all new systems have built-in smart card readers. These guidelines should supplement the existing purchasing policies and guidelines.

Access Policy

An access policy provides guidelines for all personnel regarding the rights, privileges, and restrictions for using the organization's technology and information assets. As an example, the access policy might define a warning message that should be displayed when a user logs on to a system belonging to the organization. The warning message might state that all information accessed, sent, or received through devices belonging to the organization can be monitored.

Accountability Policy

An accountability policy indicates the responsibilities of people in the organization. The policy explains that audits of information assets can and will be conducted. The responsibilities and capabilities of personnel designated to conduct the audits should also be described. The accountability policy might also include guidelines for handling incidents, such as who to contact, what to do, and what not to do when a possible intrusion or inappropriate use of equipment is discovered. If incident response is not addressed in this policy, it should refer to the official incident response policy (discussed later in this lesson).

Authentication Policy

An authentication policy describes the acceptable methods, equipment, and parameters for allowing access to resources. For example, the policy might specify which types of users are allowed to remotely access the organization's internal network. The policy might also establish the equipment necessary to connect to the organization, such as a modem and a smart card. Refer to Chapter 7 for more information on authentication types.

Password Policy

The password policy might be included in the authentication policy or it could be a separate document. The password policy describes how passwords should be managed. This policy establishes the following:

  • Password length.

    The minimum (and possibly maximum) acceptable password length.

  • Password complexity.

    The types of characters that can be used for passwords; for example, uppercase and lowercase letters and numbers, including the use of special characters such as @, #, $, %, ^, &, and *.

  • Password expiration.

    The length of time a password can be used before it must be changed to something else.

  • Password uniqueness.

    The number of unique passwords that a person must set before being able to use a previously used password.

  • Account lockout threshold.

    The number of incorrect logon attempts permitted before an account is locked out.

  • Account lockout duration.

    How long a locked out account remains locked out. This is typically an automated setting available in some operating systems. An account might be locked out for a certain number of minutes or indefinitely, requiring an administrator to reset the account.

Availability Statement

The availability statement sets expectations for the availability of organizational resources. The document should define hours of operation, times when the resources are scheduled for maintenance (down time), and the availability of redundant resources. The document should also describe shutdown, startup, and recovery procedures for organizational equipment.

Information Technology System and Network Maintenance Policy

An information technology (IT) system and network maintenance policy describes how maintenance personnel are allowed to handle and access the organization's equipment. Both internal and external personnel should be considered. The extent to which external maintenance is to be utilized should also be defined. The policy should determine whether remote maintenance is allowed and how it is to be controlled. Outsourcing and the management of outsourcing agreements, access, and partners should also be addressed in the policy.

Violations Reporting Policy

The violations reporting policy defines violations and how they should be reported. Violations should be defined and might include privacy issues, proper use of equipment, and information security. Include contact information for reporting each type of violation. You might consider setting up an anonymous reporting system to encourage violation reporting.

Firewall Policy

Firewall policy describes the type of network traffic and data that is and is not allowed to traverse the firewall. Firewall policy is typically created before or immediately following the acquisition of a firewall product because it is typically customized to address the specific capabilities of that product. If the policy is not created after the firewall product is purchased, it is often necessary to modify the policy to address specific settings and capabilities of the new firewall product. Further, if additional firewall products are added or capabilities are enhanced, the firewall policy should be updated to reflect the changes and new capabilities.

Some organizations create separate policies for each portion of the network instead of using a single firewall policy. For example, an organization might specify policy for the internal network, the perimeter network, and test labs with different firewall configurations for each area. Whether documented as separate policies or created as a single firewall policy, the types of network traffic allowed in each area of the network should be specified.

NIST Special Publication 800-41, "Guidelines on Firewall and Firewall Policy," provides more detailed information on establishing a firewall policy.

Antivirus Policy

The antivirus policy describes the organization's efforts to reduce the exposure to, damage from, and spreading of malicious software. The policy should state requirements of personnel to implement, update, and appropriately utilize antivirus software. Common countermeasures such as not opening suspicious attachments in e-mail messages, not downloading programs from unauthorized sources, and scanning all removable media before using it should also be part of the policy.

Privacy Policy

An organization's privacy policy explains reasonable expectations of privacy for clients, customers, and partners. This policy should detail such issues as monitoring of e-mail, maintaining logs of Web sites visited, and restrictions and exceptions for accessing users' files. If you don't define a privacy policy, people in the organization might assume they have privacy, which could result in managerial or legal conflicts in the future.

Protecting Confidential Data

The privacy policy should also address the confidentiality of client and employee records and all other data that could be considered personal or private. The policy should give specific examples of private information, such as client medical records or employee personnel files. The privacy policy should include general guidelines for how to identify private information. The proper handling and storage of private information should also be specified in the privacy policy.

Platform for Privacy Preferences (P3P)

The World Wide Web Consortium (W3C) developed the Platform for Privacy Preferences (P3P) as a way to standardize the presentation and evaluation of privacy policy over the Web. P3P allows client Web browsers to access, display, and automatically evaluate the privacy policy of a Web site and its pages. P3P-enabled client Web browsers can be used to display the privacy policy of a Web site or its pages. These client Web browsers can also be configured to block cookies based on the user-defined settings. P3P requires both P3P-enabled Web browsers and Web sites. Web site publishers can configure their Web pages to support P3P using a P3P editor that converts a written privacy policy into P3P-formatted code.

For more information on P3P, including links to tools, instructions, and software for downloading, visit http://www.w3.org/P3P.

Acceptable Use Policy

An acceptable use policy might be part of a security policy or a separate document. This policy defines the ways in which personnel might use the organization's equipment. The acceptable use policy should also clearly define ways in which equipment should not be used. Prohibited uses should be clearly stated in this policy, such as specific activities like playing computer games or browsing pornographic Web sites on company systems. Some organizations even list prohibited and authorized Web sites and newsgroups.

Alternate names for the acceptable use policy include appropriate use policy or authorized use policy. You can find sample policies through the "The SANS Security Policy Project" at http://www.sans.org/newlook/resources/policies/ policies.htm. There are more than 20 different sample policies that you can download and customize for your organization.

Incident Response Policy

A computer security incident is an actual, suspected, or attempted compromise of any IT system. Any activity that threatens a computer system or violates a security policy can lead to an incident, including the following:

  • System changes (hardware, firmware, or software) without the owner's consent. This includes viruses, automated attacks, and manual attacks.

  • A denial of service (DoS) attack that disables a computer system, router, or some other infrastructure device or when the network bandwidth is overwhelmed due to a malicious activity.

  • An attempted or successful unauthorized access of a system or its data.

  • Unauthorized processing, storage, alteration, or destruction of data.

These incidents can cause confusion and some people might be inclined to panic in reaction to such events. An incident response policy is a document that helps people respond appropriately to an incident. The policy defines an incident and gives examples of incident types (as just shown). The policy also designates people who are primarily responsible for handling security incidents and how they can be contacted. Further, the policy should provide step-by-step instructions for dealing with, documenting, and disseminating incident-related information.

Chapter 11, "Incident Detection and Response," provides additional information on incident handling. For more information on developing an incident response policy, read NIST Special Publication 800-3 titled "Establishing a Computer Security Incident Response Capability (CSIRC)." RFC 2196 and RFC 2350 also provide guidelines for developing an incident response policy. For links to sample incident response policies, visit http://www.all.net/books/ir.

Service Level Agreement

A service level agreement (SLA) is a contract that defines business or technical support parameters that an IT outsourcing firm agrees to provide to its clients. SLAs usually indicate agreed-on levels of performance and consequences for failing to maintain them. Some examples of SLAs include the following:

  • Internet service provider SLA.

    Specifies bandwidth and connection availability guarantees.

  • Local area network (LAN) SLA.

    Defines the availability of LAN connectivity equipment and a response time for resolving issues.

  • Application service provider SLA.

    Covers the hosting of a specific application or service, such as a Web application, database application, or e-commerce service. These agreements typically have provisions for server up time, availability, and recovery or replacement times. Sometimes these agreements are referred to as colocation or hosting services.

  • Data center SLA.

    An agreement that covers the availability of the organization's data. This agreement typically specifies backup frequency, time to restore, and guarantees concerning the availability of the systems holding the data.

  • Hardware SLA.

    Covers repairing, replacing, or restoring computers and other covered equipment within a specified period of time.

Each service provider can negotiate, name, and create SLAs for their organization. Specific agreements might not always be presented as shown here. Instead, the individual SLAs might be combined (or even further subdivided), depending on the service provider.

Human Resources Policy

The human resources (HR) department of most organizations manages the hiring, training, and termination of personnel. For the employees who require access to computers and the network, the IT department must be involved. The HR policy describes how the HR and IT departments work together to coordinate the activation, deactivation, group memberships, and privileges of user accounts based on employment status and job function. Many situations might require coordinated efforts between the HR and IT departments, especially the following:

  • New employee hired.

    A user account with appropriate access and group memberships must be created. Employees might also be asked to review the organization's policies, including the security policy.

  • Employee terminated.

    A user account should be deactivated or removed before the employee is terminated to prevent a disgruntled employee from damaging or deleting information. Many software vendors produce provisioning software that creates and activates user accounts for new employees and deactivates user passwords and accounts and quarantines files when employees leave the organization. An example of such software is Business Layers' eProvision Day One software.

  • Employee vacation or leave of absence.

    A user account should be disabled when an employee is expected to be absent for an extended period.

  • Employee status change.

    When an employee is transferred or has some other type of job function or reclassification, user account permissions or group membership changes might be required.

  • Employee education and training.

    HR is often responsible for employee education and training. The IT department must typically work with HR to educate all employees on basic IT security.

HR might also have employees read and sign a code of ethics that describes how employees should behave on the job and perform their duties. In part the code of ethics informs and reminds employees that they must help maintain the security of the organization. The following statements related to the security of the organization might be part of the code of ethics:

  • I agree to protect the security of proprietary and private information that I handle.

  • I agree to promote and follow organizational and informational security policies.

  • I will report all suspected breaches of security.

You can see an example of a code of ethics at the Information Systems Security Association (ISSA) Web site at http://www.issa.org/codeofethics.html.

Due Care

Due care describes a minimum or customary practice of reasonably protecting assets. For example, a network security professional should know that a computer with active file shares and no firewall protection is likely to get a computer virus. The security professional would violate due care if he or she plugged that computer directly into the organization's production network without first performing a virus scan.

Due care can vary by industry and business. For example, an advertising agency would not typically have the same due care responsibilities as an organization that handles medical billing. Protecting competitive information and advertising plans of client companies is due care to an advertising agency; maintaining privacy of medical records is due care to a medical billing company.

Due diligence and due professional care are other terms associated with due care. Due diligence is considered implementation and exercise of due care. In this chapter no distinction is drawn between due care and due professional care. However, other texts might choose to equate due care with commonsense behavior expressed by a certain group of people, whereas due professional care is related to the common practices and knowledge of professionals in a specific occupation.

The concept of due care should be included in your organization's documented policies. You can document it separately or even make it part of other policies. For example, the following information could be added to the privacy policy to explain due care when handling confidential client information:

  • Encrypt confidential data on fixed and removable media.

  • Never transmit confidential data over unencrypted connections.

  • Never leave confidential information easily accessible to unauthorized personnel. For example, do not leave a client's medical records displayed on your workstation while away from your desk.

Potential consequences of not exercising due care should be outlined in your security policy as well. Typical consequences for due care violations include termination of employment and possible legal action against all responsible parties.

Separation of Duties

Separation of duties is a security concept advocating that it is more difficult for multiple people (as opposed to an individual) to successfully commit and conceal an unethical, fraudulent, or illegal act. This concept is commonly applied in the separation of the accounting function into two parts: accounts payable and accounts receivable. The idea is that there is reduced chance of fraud if the duty of generating an invoice and receiving payment on that invoice is separated. If one person generates and collects payments on invoices, that person could potentially modify figures on both sides to generate and steal excess revenues. Such deception would be more difficult to coordinate, achieve, and conceal if two or more people are involved in this process.

Separation of duty should be part of your organizational policies and structure. You could introduce the concept as part of your security policy, but you must build it into systems and processes throughout the company. For example, your organization might specify that no one can be allowed to access areas that contain sensitive or critical information alone.

Need to Know

Need to know is a basic security concept that holds that information should be limited to only those individuals who require it. The measure is to determine whether a person needs to know certain information to perform his or her job function appropriately. For example, if a storage room contains new PCs, only those people responsible for deploying the new PCs have a need to know those items are in the storage room. Of course, the storage room should also be locked and monitored.

Need to know also applies to requests for information, which should be documented and justified. This is especially true when the request for information is outside of normal business practices, such as the HR department requesting copies of invoices from the accounting department.

Systems Architecture Documentation

System architecture refers to the hardware and software that a computer uses. When systems are configured on a network, the systems architecture also refers to the network architecture. As stated in Chapter 4, you should document your network layout, connections, and system configuration so that you can identify suspicious changes to that structure. This also applies to individual hosts on your network. Your organization's documentation should include descriptions of how every system is configured. This allows people (especially auditors) to identify nonstandard configurations and potential security violations.

Items that should be documented for each system include the following:

  • Operating system.

    This includes operating system version or revision, service packs or security updates applied, and any modifications to the default configuration.

  • Hardware.

    This includes specifications of processor, motherboard, RAM, hard disk, and all attached peripheral devices.

  • Applications.

    This includes all authorized applications. If your organization prohibits the use of certain applications, those applications should be specifically documented as well. Some organizations require that any application not specifically allowed be prohibited.

Change and Configuration Management Policy

A change and configuration management (CCM) policy is often part of a security policy, but it might be a separate document. The CCM policy should specify who is allowed to make changes to systems architecture. The policy should also specify how those changes should be documented and justified, and who must be notified. Everyone in the organization should be made aware of this policy so that there is no confusion of how such things should handled.

Logs

Your organizational security policy should require the use of logs to track equipment and maintenance and to ensure warranty and service agreement compliance. Logs help to ensure that required tasks are accomplished on a regular basis. They can also be used to track the movement of organizational assets. For example, a log could be used to track the possession of classified information (sign-in/sign-out log).

Inventories

Inventories verify the physical existence and availability of the organization's assets. During an inventory (or inventory documentation process) people walk around the organization and actually verify that assets are physically present. Some inventories are also used to evaluate condition and assign asset values. Inventories can also be a deterrent to theft and misuse. Consequently, inventories of valuable and classified information should be conducted frequently.

Classification Policy

A classification policy describes the appropriate handling and protection of your organization's information assets. Many organizations classify technology and documents into secret, confidential, private, and public categories. Such classifications are usually accompanied by appropriate policies, procedures, and handling instructions. The following items provide some example policy statements concerning classification:

  • Secret.

    A compromise of secret information is likely to seriously hinder business operations, reduce competitive advantages, and result in significant financial cost to the organization. All secret information and systems used to access secret information should be clearly marked. Secret information must be encrypted when stored or transmitted electronically. Only personnel with an established need to know and appropriate security clearance should access secret information or utilize systems with access to secret information. Personnel responsible for the compromise of secret information will be terminated and criminally prosecuted.

  • Confidential.

    A compromise of confidential information might hinder business operations, reduce competitive advantages, and result in financial loss to the organization. All confidential information and systems used to access confidential information should be clearly marked. Confidential information must be encrypted when stored or transmitted electronically. Only personnel with an established need to know should access confidential information or utilize systems with access to confidential information. Personnel responsible for the compromise of confidential information will be terminated and can be criminally prosecuted.

  • Private information.

    A compromise of private information could damage the reputation of the organization, its clients, and its employees. This might also result in legal action against the organization and those individuals responsible for the compromise of private information. All private information should be clearly marked and private information should not be accessible on public terminals. Only personnel with an established need to know should access private information or utilize systems with access to private information. Personnel responsible for the compromise of private information can be terminated and criminally prosecuted.

  • Public information.

    Access and distribution of public information is not restricted.

  • Notification.

    Any compromise of classified information (secret, confidential, private) should be reported immediately to the appropriate security personnel. The contact information of the appropriate security personnel should be provided as part of your classification program.

These are not the only classifications that an organization can use to control access to information. For example, classifications such as "For Internal Use Only" and "Eyes Only" might be used to restrict documents to internal personnel or specific personnel, respectively. The classification program of the organization should clearly specify the classification types, classification authorities, who to contact with questions and to report violations, and consequences of compromising classified information.

Top Secret is a classification typically used by governments when the nature of information can cause grave danger to the nation and those who protect it. If you work for an organization that accesses, maintains, or stores Top Secret information, you undoubtedly received education on the proper handling of that information.

Retention and Storage

Retention and storage policies and procedures might be established as part of the organization's classification policy or as a separate document. Government regulations often influence organizational policy in this area. Most organizations dictate that classified information is to be stored based on its classification. For example, an organization's policy might specify that secret information must be stored in a combination safe, whereas confidential and private information must be stored in a locking file cabinet or safe. The form of storage is often regulated. Data retention laws vary greatly by country and industry. For example, a health management organization might have a policy such as this one concerning patient records:

  • Original documents concerning patient cases must be maintained for two years.

  • After two years, patient records can be digitally scanned and stored on optical media.

  • Burning or pulverization can be used to destroy patient records older than seven years.

Disposal and Destruction

Disposal and destruction policies and procedures might be established as part of the classification policy or as a separate document. As with retention and storage, disposal and destruction can be influenced by government regulations. Most organizations dictate different disposal procedures based on document classifications. For example, disposal of secret information requires burning or pulverization and confidential and private information requires at least crosscut shredding. Magnetic media, such as tapes and floppy disks, can usually be degaussed (magnetically erased) before disposal. Some organizations require degaussing for confidential media and physical destruction for media used for certain data classifications.

Exercise: Policy Purposes

Match the policy descriptions in the left column with the appropriate policy in the right column.

  1. More people involved in a process reduce the likelihood that one of them will do something inappropriate.

  2. International security standard.

  3. Guidelines regarding organization's member privileges to information assets.

  4. Defines responsibilities and capabilities of information auditors.

  5. Describes hours of operation.

  6. Describes the type of network traffic that is allowed into or out of the organization.

  7. Policy explaining that employees can be held accountable for negligent actions such as transmitting patient medical records in cleartext instead of an encrypted format.

  1. Firewall policy

  2. Accountability policy

  3. Common Criteria

  4. Separation of duties

  5. Access policy

  6. Availability statement

  7. Due care

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson and then try the question again. Answers to the questions can be found in Appendix A, "Questions and Answers."

  1. List requirements you might find in a password policy.

  2. What items might be included in a privacy policy?

  3. What type of policy would typically prohibit playing of computer games on organizational computers?

  4. What is a computer security incident?

  5. If you sign an agreement with another company to host an e-commerce solution for your organization, the company you signed with is a what?

Lesson Summary

  • Documentation creates the foundation of your security plan. You can use standards, guidelines, and government regulations to help formulate your organizational policies and procedures.

  • Common Criteria is an international standard for evaluating the security of computer and network devices. This standard is supported by many different countries and has ISO equivalent standard 15408.

  • Security policy is created from multiple subordinate policies such as access policy, accountability policy, authentication policy, password policy, firewall policy, and many other policies concerning privacy, system availability, maintenance, violations reporting, and acceptable use of equipment.



Security+ Certification Training Kit
Security+ Certification Training Kit (Pro-Certification)
ISBN: 0735618224
EAN: 2147483647
Year: 2002
Pages: 55

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net