previous  next  Title  Contents  Index     Last Update: 28 Jul 2000


6 Security Policy

Footnotes
References


Introduction

A security policy is a statement of management strategy as regards security. The policy statements are grouped under the following headings:

  1. Corporate Policy
  2. Information Security Policy
  3. Personnel Security Policy
  4. Physical and environmental security policy
  5. Computer & Networks Security Policy
  6. Business Continuity Planning

A policy should outline a certain Security topic, why it is needed/important and explain what is allowed and what is not allowed. It should be general enough that changes are not required too often. It should contain general directives which are not architecture or system dependant. Policy should also tackle enforcement i.e. it should be clear what disciplinary measures are to be expected if policy is breached.
Policies should be concise, a good balance of productivity and security, be backed up by appropriate security tools, easy to understand

Line Managers are responsible that the policy is adhered to and enforced.
System administrators should know the Personnel policy and developers should know both the Personnel and Administration policy.
The policy is split up into several sections so that the Personnel Policy can be small and as "user friendly" as possible, therefore maximising the chances that the Personnel will actually read it!

Critical Success factors
Successful implementation of information security [bsi1] depends on:

  1. Security objectives and activities must be based on business objectives and requirements, and led by business management.
  2. There must be visible support and commitment from top management.
  3. There must be a good understanding of security risks (threats and vulnerabilities) to Company assets, and the level of security inside the organisation.
  4. Security must be effectively marketed to all managers and employees.
  5. Comprehensive guidance on security policy and standards must be distributed to all employees and contractors.

The remainder of this chapter list items which should be considered in the development of a Policy. The symbols to , used in the following sections, indicate directives which are necessary for protection of data of a certain sensitivity class or higher.


6.1 Corporate Policy

Each business unit is responsible for creating it's own security policy. This policy should lay down rules for protection of business data and processes corresponding to the threats/risks involved and the value of those assets.

All data should be labelled according to the (corporate) Sensitivity classes.


6.2 Information Security Policy

6.2.1 Concepts

6.2.2 Classification of information

A classification system is proposed which classes information into four levels. The lowest , is the least sensitive and the highest , is for the most important data / processes. Each level is a superset of the previous level. For example, if a system is classified as class , then the system must follow the directives of class , and . If a system contains data or more than one sensitivity class, it must be classified according that needed for the most confidential data on the system.

Class : Public / non classified Information
Description: Data on these systems could be made public without any implications for the company (i.e. the data is not confidential). Data integrity is not vital. Loss of service due to malicious attacks is an acceptable danger. Examples: Test services without confidential data, certain public information services.
Guidelines on storage: none
Guidelines on transmission: none
Guidelines on destruction: none

Class : Internal Information
Description: External access to this data is to be prevented, but should this data become public, the consequences are not critical (e.g. the company may be publicly embarrassed). Internal access is selective. Data integrity is important but not vital. Examples of this type of data are found in development groups (where no live data is present), certain production public services, certain Customer Data, "normal" working documents and project/meeting protocols and internal telephone books.

Guidelines on storage:

  1. Information shall be labelled. i.e. the classification level should be written on documents, media (tapes, diskettes, disks, CD's etc), electronic messages and files.
  2. IT Systems susceptible to virus attacks should be regularly scanned for viruses. The integrity of systems should be regularly monitored.

Guidelines on transmission:

  1. For projects involving collaboration with external partners, a project policy document shall stipulate what information may be shared with the external partners.
  2. This information shall stay within the company, if it must transit public media (e.g. the Internet), it should be encrypted.
  3. Internal data shall not be transferred outside the company except as in points 1 and 2.

Guidelines on destruction: none

Class : Confidential Information
Description: Data in this class is confidential within the company and protected from external access. If such data were to be accessed by unauthorised persons, it could influence the company's operational effectiveness, cause an important financial loss, provide a significant gain to a competitor or cause a major drop in customer confidence. Data integrity is vital. Examples: Salaries, Personnel data, Accounting data, very confidential customer data, sensitive projects and confidential contracts. Datacenters normally maintain this level of security.

Guideline on storage:

  1. Information shall be labelled. i.e. the classification level should be written on documents, media (tapes, diskettes, disks, CD's etc), electronic messages and files.
  2. IT Systems susceptible to virus attacks should be regularly scanned for viruses. The integrity of systems should be regularly monitored. IT Systems shall be configured to protect against unauthorised modification of data and programs.
  3. Information shall be kept under lock and key (e.g. documents in locked cabinets, computers in locked rooms).

Guidelines on transmission:

  1. Passwords should not be transmitted in clear-text (electronically or on paper).
  2. This information shall stay within the company, if it must transit public media (e.g. the Internet), it should be encrypted. Encryption algorithms used should be strong[3]

Guidelines on destruction:

  1. Information shall be securely disposed of when no longer needed (e.g. shredders for documents, destruction of old disks and diskettes etc.).

Class : Secret Information
Description: Unauthorised external or internal access to this data could be critical to the company. Data integrity is vital. The number of people with access to this data should be very small. Very strict rules must be adhered to in the usage of this data. Examples: Military data, information about major pending contracts/reorganisation/financial transactions.

Guideline on storage:

  1. Information shall be labelled. i.e. the classification level should be written on documents, media (tapes, diskettes, disks, CD's etc), electronic messages and files.
  2. IT Systems susceptible to virus attacks shall be regularly scanned for viruses. The integrity of systems shall be regularly monitored. IT Systems shall be configured to protect against unauthorised modification of data / programs and shall be audited yearly.
  3. Information shall be kept under lock and key (e.g. documents in locked cabinets, computers in locked rooms).
  4. Information shall be stored in encrypted format or on removable disks which are physically secured.

Guidelines on transmission:

  1. This information shall be encrypted during transmission outside of secure zones. Encryption algorithms used shall be strong[4]

Guidelines on destruction: Information shall be securely disposed of when no longer needed (e.g. shredders for documents, destruction of old disks and diskettes etc.).

Adherence to corporate and legislative requirements
The local, national and international laws (e.g. on data privacy, dissemination of pornography) and must be adhered to.

Internet pornography: The Internet is now seen as a major carrier of illicit material, from soft pornography to paedophile information to nazi propaganda.
* If it is known that such material is passing over company Internet gateways, it should be blocked.
* Personnel may not use company computers or infrastructure to access such material. Users may be disciplined if this directive is contravened.

Privacy laws: Personnel data shall be protected according to the data privacy laws of the country where is stored or processed.


6.3 Personnel Security policy

See also the "Security Mechanisms/Authentication" chapter, in Part I.

6.3.1 Ethics

Users are not allowed to: share accounts or passwords with friends or relatives, run password checkers on system password files, run network sniffers, break into other accounts, disrupt service, abuse system resources, misuse email, examine other users files unless asked to do so by the file owner, download PC binaries, copy unlicenced software or allow other users to copy unlicenced software.

6.3.2 Password Policy

For a detailed discussion on password management, see the "Green Book" [green].
The combination of username and password define the identity of users on a system. Adopting a good personal password policy is the most important barrier to unauthorised access in current systems.

Content
* mixture of numbers, capital letters, small letters, punctuation.
* easy to remember (don't need to write it down).
* easy to type quickly (difficult for an observer).

Examples
* choose a line or two of a poem, song etc. and use just the first letters.
* join two small words with a strange character.
* invent an acronym.

Bad examples
* name of your spouse, parent, colleague, friend, pet, towns, months, days.
* number of car/motorbike registration, telephone.
* common dictionary words (French, German, English, Italian..).
* a series of identical numbers/letters.
* Obvious keyboard sequences.
* Any of the above in inverse or with a number before or after.

Guidelines
* don't write it down, or disclose via email.
* Default passwords should not be used.
* Don't give your password to others.
* If passwords are disclosed on a system, change them immediately.
* Avoid sharing the administrator (or root) password. Use user groups or utilities such a su instead.
* If possible synchronisation of user passwords across platforms is to be striven for. The user will probably choose better passwords if he only has to remember one single password. See also the "Security Mechanisms" chapter for a discussion of single signon.
* Inform users in detail of cracking dangers/successes. A well educated user is the best way to ensure good choice of passwords.
* All vendor defined default passwords must be changed before the system is used.
* Passwords should be stored in encrypted form. The encryption should be strong, resisting brute force decryption for at weeks on a powerful workstation.
* Passwords should not be displayed when being entered, neither should a "*" be shown for each character.
* A user should not be able to read other users (encrypted) passwords (from the password file).
* Embedding of clear-text passwords into software should be avoided at all costs. Embedded encrypted passwords are also to be avoided where possible.
* A password minimum age, maximum age, minimum length & history list should be specified. E.g.

Minimum age = 2 days, Maximum age = 6 months, Minimum length = 6 characters.
Minimum age = 2 days, Maximum age = 30 days, Minimum length = 6 characters.
Password history: the use of the last 5 passwords should be prohibited.

* The allowed password content should be specified. The system should check the password content according to these rules, before accepting the password. E.g. see section bad examples above.
* Users should not be able to change other user's passwords, but the account operator can change user passwords.
* When special application accounts (e.g. oracle under UNIX), their passwords should be blocked to prevent interactive logon.
* Force change of password on first login, if possible.
* Consider the use of stronger authentication (e.g. smart tokens, Chip Cards, biometrics etc.).
* If possible provide automatic password generation (to help the user).
* A password checker should regularly ( once per week) check for weak passwords.

6.3.3 General Software Policy

6.3.4 Networks

  1. Confidential information:
  2. Connection to networks:
  3. Modems:
  4. Email

6.3.5 Internet

Connection to the Internet is almost inevitable in today's commercial environment, especially for research departments. Due to it's lack of structure & controls, the Internet offers many risks such as:

If users are to be allowed Internet access, they must be aware of the risks involved and the corporate policy as regards Internet usage => A specific Internet policy should exist, be well known and be enforced.

6.3.6 Laptops and portable computers

Portable computers allow personnel to be more productive while "on the road". They offer flexibility as to where one can access information. From the security point of view they can create risks of information disclosure, theft and perhaps offer an unauthorised point of access to the corporate network. The mobile computing population is on the increase, so a special policy is necessary.

Some issues are:

Possible policies are:


6.4 Computer & Network Policy

6.4.1 System administration policy

The administrator ensures that the systems are available when needed, that confidential information is only available to those authorised access and that the information is not subject to unauthorised changes.
The following need to be defined:

6.4.1.1 Physical security

A Physical Security policy document should exist detailing the measures taken to protect buildings as regards disasters (flooding, fire, earthquakes, explosions, power outage), theft, access control, safes, computer rooms & wiring cabinets. (see also Physical Security chapter).

Zone 1: Areas open to the public.
Zone 2: Areas not open to the public, open to company staff.
Zone 3: Protected areas. Only accessible with identification, access strictly controlled.

6.4.1.2 Access Control

6.4.1.3 Logon Policy

Basic principle: Give a User the minimum privileges for the shortest time necessary to do their work.

6.4.1.4 Assurance

6.4.1.5 Accountability and Audit

6.4.1.6 Reliability of Service

Backup & Restore Policy

Change Management (sw/hw installations or updates)

6.4.2 Network Policy

Transmitting information between computers can pose a significant threat to security.

6.4.2.1 Network / Distributed Systems Policy

  1. Assurance: Network configuration shall be documented.
  2. Identification and Authentication:
  3. Accountability and Audit
  4. Access Control
  5. Accuracy: Important network nodes should check the integrity of their data regularly.
  6. Data Exchange:
  7. Reliability of Service / Availability

Remote Access Policy: external network interfaces
Networks (X.25, Dial-up, Internet, Vendor networks, Telephone networks, Customer networks etc.) shall not be interconnected if it results in breach of the security policy. Access to external networks must occur over a Firewall. The Firewall must have a security policy and be regularly monitor and audited.

6.4.2.2 Dial-in access

All incoming Dialup connections (via PSTN or ISDN) should use a strong one-time password authentication system (such as SecurID). S

Dial-in access to the corporate network should only be allowed where necessary and where the following conditions are met:

  1. Assurance
  2. Identification and Authentication
  3. Accountability and audit
  4. Access Control
  5. Accuracy: no requirements.
  6. Data Exchange
  7. Reliability of Service
    1. Dial-up servers shall have all unnecessary services stopped.
    2. Dial-up servers shall be a robust multitasking machines (e.g. UNIX, VAX or NT).
    3. Dial-up servers shall offer the following availability: => 7x24h, maximum downtime 4 hours (during office hours), maximum frequency twice per month. Maintenance window: Wednesday evening after office hours.
    4. Change management: Updates and configuration changes shall be logged and carried out according to Quality processes..
    5. Alerts should be raised if important processes crash.
    6. Regular backups shall be made where necessary.

6.4.2.3 Dial-out (PSTN/ ISDN)

Dial-out network connections can extend the corporate network, creating uncontrolled points of access to the network.

  1. Users shall not use dial-out capability (modems) on their machines.
  2. If such functionality is required, it shall:

6.4.2.4 Internet Firewall

The Internet is often an important tool for sharing and searching information, especially in a research environment. All Internet access from the corporate network must occur via a Firewall.

  1. Assurance
  2. Identification and Authentication
  3. Accountability and audit
  4. Access Control
  5. Accuracy: The firewall machines shall have the integrity of their files regularly (every month) checked.
  6. Data Exchange
  7. Reliability of Service

6.4.2.5 Interfaces to other networks

Likewise interfaces to other networks (SNA, Decnet, X.25, ATM etc.) required a clear policy.

Interfaces to customer/vendor networks
Access from customer or vendor sites to the corporate networks are more and more common.

Telephone networks
Phone, Fax and Voicemail systems and networks are frequent penetration points for attackers. If these system have features accessible from the outside, a policy is required to prevent abuse.

6.4.2.6 Incident Response Procedure

Scope
This procedure should detail which actions should be taken in case of a security incident on the Firewall. The Firewall is designed to protect the corporate network from unauthorised Internet access. It is regularly monitored for security breaches. When a breach is detected, one must know how to react. That is the aim of this procedure. The reaction to an incident aims to protect and restore the normal operating condition of computers, services and information

Purpose
Even with a solid security policy, educated users and solid system administration, an emergency response team is useful. Plan for a disaster!

Incident Response Team
The principal roles are indicated in italics below. For each role a backup person should be available.

Management Responsible A.Boss, (Tel. xxxx)
(Overall co-ordinator/responsible) backup: B. OtherBoss (Tel. xxxx)
Responsibility: Ensures that this document exists and is enforced. Recognising the major threats to business continuity. Prioritises activities, co-ordinates and makes key decisions during an incident. Approves exceptions to this procedure.

Technical Responsible Firewall A. Techie (Tel. xxxx),
backup B. OtherTechie (Tel. Xxx)
Responsibility: Knows how to technically administer the systems in question. Can detect incidents and can take technical measures to limit damage. A good technical understanding of the system is essential.

Press Responsible A. Prman (tel. Xxx)
backup: A. OtherPrMan (Tel. Xxx)
Responsibility: Handles interfaces to the media, public statements, co-ordinate communications.
Additional Help:
Legal Advice ?
First Response Team, See appendices.

Procedure
In case of an emergency, each of the following points should be considered and acted upon. The principal steps involved are:

  1. Preparation: The team should have read this chapter and be aware of the implications.
  2. Incident detection: quick assessment
  3. Immediate action: limit damage
  4. Public Relations / Communications
  5. Detailed situation analysis
  6. Recovery: restore data/services/systems
  7. Follow-up

2. Incident detection: quick assessment
What has happened? :

If an attack has occurred:

3. Immediate action: limit damage:
If a serious attack or disaster occurs, the Management Responsible and Technical Responsible should decide on the immediate action necessary to eliminate the threat or limit damage (depending on the gravity of the situation and user's needs).
=> It should be clear who is in charge of handling the incident in question. Define who is the overall responsible/ co-ordinator. Ensure that the chain of command is understood
=> Start an event log: Document every single action taken, events, evidence found (with time & date).

Possible immediate actions are:

4. Public Relations / Communications

5. Detailed situation analysis:

6. Recovery: restore data/services/systems:

6. Follow-up

=> End of procedure.

General Guidelines:

6.4.3 Software Development Policy

Security should be an integral part of new systems. When functional requirements are designed, security requirements should be formulated corresponding to the sensitivity and availability of data to be handled by the system.

6.4.3.1 General Guidelines

6.4.3.2 Production Guidelines

What documentation is to delivered with an application? E.g. Operating, Installation, Administration, Security, User Manuals.


6.5 Business Continuity Planning

Continuity of important business processes shall be guaranteed through disaster planning and information classification.

Availability of computerised information
Business processes which could affect Business Continuity require high availability. The owner of these processes, should define the availability required and ensure that the IT staff implement it.[11]

System Redundancy
Systems of class or higher may require some form of hardware, service or system redundancy. See the system requirements for the availability classes (chapter 5) and the Mechanisms chapter (chap. 7).

Security crisis/disasters
If a serious attack or disaster occurs:


6.6 Enforcement

Users who do not adhere to this policy shall be warned and the corresponding line manager informed. A user who continues to ignore warnings may be removed from his function.


Footnotes:
[3]  [4] i.e. RCA 1024-bit, IDEA, 3DES etc. not simple mechanisms like XOR. Note that normal DES is no longer considered strong.
[5] E.g. F-Secure Desktop or PGP desktop which has military strength encryption and secure file deletion.
[6] Who is allowed root access? On UNIX systems, it is preferable to use sudo (for example) to restrict root powers. On NT systems, user groups can be used to restrict administrative access.
[7] UNIX: The sticky bit should be set on world writeable directories.
[8] On UNIX, this means .cshrc, .mailrc, .login, .profile, .netscape etc.
[9] This is standard on UNIX systems, but not (yet) on NT.
[10] On UNIX, every 5 unsuccessful login attempts, the prompt is delayed for a few seconds.
[11] To improve availability, preventative measures reduce the probability of downtime and recovery measures reduce the downtime after an incident

Policy References:
   SANS model security policies: www.sans.org/newlook/resources/policies/policies.htm
   EFF sample policies: www.eff.org/pub/CAF/policies/
   The Site Security Handbook ds.internic.net/rfc/rfc2196.txt
   NIST csrc.ncsl.nist.gov/secplcy
   Georgia Institute of Technology COMPUTER AND NETWORK USAGE POLICY


previous  next  Title  Contents  Index    IT Security Cookbook,   Last Update: 28 Jul 2000