CCSP SelfStudy CCSP CSI: Exam Certification Guide, Second Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

CCSP SelfStudy CCSP CSI: Exam Certification Guide, Second Edition [Electronic resources] - نسخه متنی

Tebyan

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید











  • Security Policy Characteristics, Goals, and Components


    A security policy defines the framework that is used to protect the assets that are connected to a network. RFC 2196, "Site Security Handbook," defines a security policy as ". . .a formal statement of the rules by which people who are given access to an organization's technology and information assets must abide."

    Without a security policy, the availability of a network can be compromised. By defining the basis with which the information assets and the systems connected to the network are used and protected, the security policy helps to reduce the risk of systematic security failure within the network.

    A policy is a document or set of documents that defines the specific requirements or rules that must be met to reach a particular goal. In many instances, a security policy is a collection of shorter documents that are point-specific; that is, each covers a specific topic. In the case of IT and network security, such policies can include an acceptable-encryption policy that defines the requirements for the use of encryption within an organization. More commonly, security policies include an acceptable-use policy that might cover the rules and regulations for appropriate use of the computing facilities. In every case, the policy considers only one topic and addresses the uses of that topic within the context of the overall security of the network.

    The main goal of a security policy is to ensure that system users, staff, and managers are informed of their responsibilities for protecting corporate technology and information assets. The security policy should specify the mechanisms through which these responsibilities can be met while also providing a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the policy.

    There are two general types of network security policies:

    • Permissive
      Based on the assumption "everything that is not expressly prohibited is permitted."

    • Restrictive
      Based on the assumption "everything that is not expressly permitted is prohibited."


    A permissive security policy is the equivalent of an access control list with the permit ip any any command as the last statement. A restrictive security policy is better than a permissive policy because it allows the administrators and managers to more easily define the proper use of the network and its assets.

    Security Policy Components


    A successful security policy can be subdivided into smaller subpolicies, each of which covers a specific topic related to the overall security of the network. The breadth and scope of each subpolicy can vary according to the needs of administrators and managers. Each subpolicy can be referenced as a standalone document as well as function as part of an overall security policy. Section 2.2 of the "Site Security Handbook" lists several elements of an overall security policy, including:

    • Computer technology purchasing guidelines that specify required, or preferred, security features. These should supplement existing purchasing policies and guidelines.

    • A privacy policy that defines reasonable expectations of privacy regarding such issues as monitoring of e-mail, logging of keystrokes, and accessing users' files.

    • An access policy that defines access rights and privileges to protect assets from loss or disclosure by specifying acceptable-use guidelines for users, operations staff, and management. It should provide guidelines for external connections, data communications, connecting devices to a network, and adding new software to systems. It should also specify any required notification messages (for example, connect messages should provide warnings about authorized usage and line monitoring and not simply say "Welcome").

    • An accountability policy that defines the responsibilities of users, operations staff, and management. It should specify an audit capability and provide incident-handling guidelines (that is, what to do and who to contact if a possible intrusion is detected).

    • An authentication policy that establishes trust through an effective password policy and by setting guidelines for remote-location authentication and the use of authentication devices (for example, one-time passwords and the devices that generate them).

    • An availability statement that sets users' expectations for the availability of resources. It should address redundancy and recovery issues and specify operating hours and maintenance downtime periods. It should also include contact information for reporting system and network failures.

    • An IT system and network maintenance policy that describes how both internal and external maintenance people are allowed to handle and access technology. One important topic to be addressed is whether remote maintenance is allowed and how such access is controlled. Another area for consideration is outsourcing and how it is managed.

    • A violations-reporting policy that indicates which types of violations (for example, privacy and security, internal, and external) must be reported and to whom the reports are made. Providing a nonthreatening atmosphere and the possibility of anonymous reporting results in a greater probability that a violation will be reported if it is detected.

    • Supporting information that provides users, staff, and management with contact information for each type of policy violation; guidelines on how to handle outside queries about a security incident, or information that may be considered confidential or proprietary; and cross-references to security procedures and related information, such as company policies and governmental laws and regulations.


    It is possible to further subdivide the preceding policies to provide a greater degree of granularity on specific topics. The SysAdmin, Audit, Network, Security (SANS) Institute defines 27 possible policies, some of which focus on very specific topics. Among the 27 SANS Institute polices are the following:

    • Acceptable-encryption policy
      Defines requirements such as cipher type, key length, and appropriate use of encryption algorithms for the communication channels used within the organization, such as host-to-host connections and e-mail.

    • Acceptable-use policy
      Defines the boundaries of acceptable use of corporate resources (whether they be physical equipment or network services) as well as the responsibilities of the user in protecting corporate assets and equipment. Additionally, an acceptable-use policy may specify the boundaries of acceptable behavior of users on the corporate network.

    • Antivirus policy
      Defines guidelines for effectively protecting the organization's network from the threat and the effects of computer viruses and worms.

    • Extranet policy
      Defines the requirements that third-party organizations must meet to connect to the corporate network. These requirements should include the necessary security obligations that the third party must comply with. Although this policy should also require the signing of a third-party connection agreement in order to access the organization's networks, it need not include the specific wording of such an agreement.

    • Information-sensitivity policy
      Defines classification levels for the organization's information. Classification should be based on the sensitivity of the information. This policy should also provide for the mechanisms to secure that information.

    • Remote-access policy
      Defines the methods that authorized users can use to access the network from an offsite or remote location. This policy ties into the VPN policy described later in this list and covers additional topics such as dial-in access and security.

    • Internal-lab security policy
      Defines the security requirements for internal labs, such as development labs and quality assurance (QA) labs. This policy covers how confidential information and technology (typically considered intellectual property, such as source code) is to be protected. In addition, this policy should provide guidelines that define how to prevent the activities of the lab from endangering production facilities on the network.

    • Internet DMZ equipment policy
      Provides the standards and the guidelines to be used to secure systems located outside the organization's firewalls. These systems typically exist in areas between the corporate firewalls and the edge devices such as routers. These areas are considered "dirty" or "semitrusted."

    • Password-protection policy
      Provides definitions for the composition and characteristics of passwords and how they are to be stored and protected.

    • Audit policy
      Defines the requirements and the standards through which network security audits are performed. This document is also used as a source of authority for the network security staff to conduct audits, investigate any incidents, and monitor user and system activity. It also defines the requirements for conforming to stated security policies.

    • VPN security policy
      Defines the requirements for remote access to the organization's networks using VPN technology. The document defines which VPN technologies are appropriate (such as IPSec, PPTP, and L2TP) and the range of internal networks visible to users of the VPN.

    • Wireless networking and communication policy
      Defines the standards and requirements to connect to the corporate network using a wireless technology, such as 802.11 or Bluetooth.


    This is by no means an exhaustive list of all the possible policies that can be part of an overall security policy. The references at the end of this chapter provide a good starting point with which to develop a sound security policy.

    Characteristics of a Good Security Policy


    There are three primary characteristics of a good security policy:

    • Most important, the policy must be enforceable and it must apply to everyone.

    • The policy must be capable of being implemented through system administration procedures and through the publication of acceptable-use guidelines or other appropriate methods.

    • The policy must clearly define the areas of responsibility and the roles of users, administrators, and management.


    Failure to meet these three requirements seriously weakens the effectiveness of a security policy and calls into question its role in defining the overall security of the network.

    Security Policy Goals


    Without an overall design, network security can become a hodge-podge of rules and guidelines that can easily contradict each other. Any and all security-related decisions that are made affect the security level of the network as well as its functionality and ease of use. Good decisions regarding security cannot be made without first defining the overall goals and a roadmap to attain those goals. Without this roadmap, using security tools is meaningless, because it is impossible to determine what to check for and what restrictions should be imposed.

    Security goals are determined mainly by working through the following key trade-offs:

    • Services offered versus security provided
      Each network service offered, such as Telnet, Simple Mail Transfer Protocol (SMTP), and the web, carries a security risk. In some cases these risks are outweighed by the benefits that the service provides.

    • Ease of use versus security
      Providing users with a system that is easy to use and that requires little or no training is very convenient. However, the reality is that such systems sometimes also bring with them significant security risks. Requiring security usually results in a loss of convenience.

    • Cost of security versus risk of loss
      Security has a variety of costs: expenses for personnel, equipment, and software; decreased ease of use; and decreased performance. However, the costs of security systems must be weighed against the potential cost of the loss of confidential information, loss of privacy, and loss of service. A risk assessment is essential to understand the cost-benefit trade-offs of implementing a security policy.


    Some motivating factors for the establishment of a security policy include:

    • Security posture baseline
      Without knowing the current state of the security on the network, it is impossible to determine how to improve it.

    • Security implementation framework
      A security policy provides a roadmap for implementing and improving network security.

    • Defining appropriate behavior
      A security policy can provide guidelines for proper behavior on the corporate network and consequences for inappropriate behavior.

    • Identification of the necessary tools and procedures
      The security policy can help to define which tools and procedures are needed to implement the desired security on the network.

    • Defining roles and communicating consensus
      The security policy defines roles for users, managers, and administrators and helps to communicate consensus among decision makers.

    • Incident-handling framework
      The policy needs to provide the definition of an incident-handling process and procedures for disaster recovery.


    A key motivating factor in creating and implementing a security policy is to ensure that the or-ganization realizes the benefits of the cost and effort spent on security. Risk assessment or analysis is used as a guide toward this end. A security risk assessment identifies the risk to an organization of its current security posture. Assessing risk involves determining two basic elements:

    • Which assets need to be protected

    • What the threats are to those assets


    For each asset, the basic aim is to assure confidentiality,integrity,and availability (CIA). Threats to assets can be further defined by identifying the following threat elements:

    • Consequences of the threat if nothing is done

    • How often the threat may occur

    • A measure of the likelihood that the threat will occur


    Once the risks associated with various threats have been identified, they can be ranked according to their severity and impact to the enterprise.

    Risk Assessment


    Risk assessment is a method that enables an organization to quantify the level of risk inherent in a system. For computer networks, it is a way to identify, analyze, and determine how to control and minimize losses that may be associated with events on the network. Although there is no possible way to ever reduce the level of risk to zero (that would entail ceasing network operations), a risk assessment enables network managers and security personnel to identify risks in the network and their location and methods to eliminate or reduce their impact on network operations.

    Asset Identification

    The first step in a risk assessment is to identify the assets that need to be protected. Without this first step, there is no logical way to proceed to define the threats. Assets include both tangible and intangible property. Examples of tangible property include computer hardware, network equipment, and phone systems. Intangible property includes intellectual property and data. The following list of asset categories is paraphrased from Charles Pfleeger's 1996 book Security in Computing:

    • Hardware items such as computers, printers, routers, switches, firewalls, and other devices that exist physically on the network

    • Software such as operating systems, programs (both commercial and home grown), and utilities

    • Information stored both on line and off line in any format as well as audit log information and all network security logs

    • Users, administrators, and managers

    • Documentation of programs, hardware, and corporate policies

    • Supplies such as magnetic media, forms, and office supplies


    Threat Identification

    After the assets are identified, threats to those assets can be identified. When you are conducting a risk assessment or analysis, it is necessary to consider the nature of the threats. Some of the more common threats mentioned in RFC 2196 include

    • Unauthorized access to resources and information

    • Unintentional or unauthorized disclosure of information

    • Denial of service (DoS)


    While this is certainly not a comprehensive list, it does provide a starting point for security personnel to identify threats to corporate assets.


  • / 290