Last Update: 28 Jul 2000
6 Security Policy
Footnotes
References
A security policy is a statement of management strategy as regards
security. The policy statements are grouped under the following headings:
- Corporate Policy
- Information Security Policy
- Personnel Security Policy
- Physical and environmental security policy
- Computer & Networks Security Policy
- System Administration
- Network Policy
- Application Development Policy
- 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:
- Security objectives and activities must be based on business
objectives and requirements, and led by business management.
- There must be visible support and commitment from top
management.
- There must be a good understanding of security
risks (threats and vulnerabilities) to Company assets, and the level of
security inside the organisation.
- Security must be effectively marketed to all managers and
employees.
- 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.
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.
- All major information assets shall have an owner.
- The owner shall classify the information into one of the
sensitivity levels (listed below), depending on legal obligations, costs, corporate policy
and business needs. He/she is responsible for protection of this information.
- The owner shall declare who is allowed access to the data.
- The owner is responsible for this data and shall secure it or have it
secured according to it's sensitivity.
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:
- 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.
- IT Systems susceptible to virus attacks should be regularly scanned
for viruses. The integrity of systems should be regularly monitored.
Guidelines on transmission:
- For projects involving collaboration with external partners, a
project policy document shall stipulate what information may be shared with the external
partners.
- This information shall stay within the company, if it must transit
public media (e.g. the Internet), it should be encrypted.
- 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:
- 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.
- 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.
- Information shall be kept under lock and key (e.g. documents in
locked cabinets, computers in locked rooms).
Guidelines on transmission:
- Passwords should not be transmitted in clear-text (electronically or
on paper).
- 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:
- 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:
- 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.
- 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.
- Information shall be kept under lock and key (e.g. documents in
locked cabinets, computers in locked rooms).
- Information shall be stored in encrypted format or on removable disks
which are physically secured.
Guidelines on transmission:
- 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.
See also the "Security
Mechanisms/Authentication" chapter, in Part I.
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.
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.
- Public domain software may be used on class & systems with a TCB
(i.e. not DOS/Windows), if the system administrator responsible for the installation is
convinced of the integrity of the author / sources.
- Public domain software on class systems is to be avoided. However, when necessary, it is only allowed after
either a review of the source code, or (if the source is too big) after the software is in
general use for at least a year on comparable systems in many other (well known and
trusted) companies and the software has been rigorously tested in a protected environment.
- Unlicensed software should not be used.
- Games are allowed on the system, if the system administrator can
ensure that they will not use more that 5% (for example) of resources (disk/memory/CPU)
and they are not abused.
- Unix: set-user-id (SUID) and set-group-id (SGID) scripts are not
allowed on the system. Use tainted perl or compiled programs instead.
- Confidential information:
- Confidential data transmitted over public networks shall be
encrypted.
- Connection to networks:
- A User may not connect a machine to any network except the corporate
LAN.
- Access to external (public & private) networks shall occur over a
Firewall. All Firewalls shall be installed and maintained by corporate security.
- Modems:
- Users may not have modems on their machines.
- Dial-in access to the corporate LAN is allowed for certain users. All
Dial-in access shall occur via secured Servers with one-time-password mechanisms.
- Email
- Users should be aware that conventional email systems often guarantee
neither privacy or proof of origin or receipt. In many systems the system administrator
can read all email.
- Class data may be sent
internally within the company without encryption. Class should be encrypted. Class data may
not be transmitted via email.
- Only Class data and
information specifically allowed for projects with external entities may be emailed
outside the company.
- Users should be aware of the risks of opening documents with macros,
postscript files, and installing programs received via email.
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:
- Disclosure of confidential information.
- The corporate network may be penetrated by hackers from the Internet.
- Information may be changed or deleted.
- Access to systems could be denied due to system overload.
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.
- All outgoing access to the Internet must go over approved company
gateways which have been certified as conforming to the corporate security policy.
- Who is allowed standard (WWW) Internet access? (e.g. administrators,
research units)
- Who is allowed Internet email access? (e.g. everyone!)
- When is access not allowed? (e.g. not from class servers).
- What Internet client software are allowed (e.g. corporate standards)?
- What may Internet clients not be used for? (e.g. Pornographic
material, downloading dangerous or unlicensed software, excessive private use etc.)
- Who may provide Internet services? Under what
conditions (e.g. approved Firewall policy, only publicly classified information may be
published).
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:
- Educate users as to the risks of Laptop usage.
- Password protection in office applications such as Winword is not a
protection against the informed attacker.
- Removable hard disks allow the user to easily protect the most
important component by putting it in his pocket. On the other hand, it makes it easier to
steal information.
Possible policies are:
- Have laptops prepared and installed by professional IT staff. Have
knowledgeable staff who can offer sound advice on the choice of laptop model.
- If possible install a file encryption program which provides strong
encryption[5] and is easy to use. A disk encryption program
is also an alternative, but may require more administrative overhead and affect
performance and compatibility.
- Consider using an operating system (such as UNIX or NT) where a
normal user does not have full access to the system.
- Users are responsible for their Laptops outside the corporate
buildings.
- Automatic screen locking mechanisms and boot passwords should be used
where possible. Boot passwords offer a protection against the curious, but not a informed
attacker.
- An active virus scanner must be installed (provide it free of charge
to all corporate users).
- Carry Laptops as hand baggage on public transport.
- Class data should not be
transported on laptops unless it is encrypted.
- Switch off the computer when not in use.
- Never store passwords on the Laptop which allow access to corporate
network systems.
- Communication:
- Do not transmit class
data across insecure networks (such as Internet, Mobile-GSM, Infrared etc.) unless
encrypted.
- Dial-in access to the corporate network should be specified in the
Network access policy.
- Turn off modems when not in use.
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:
- Who/where updates administration policies ?
- Who is authorised to grant access and approve usage? Who may have
system administrator privileges? [6]
- What are the rights and responsibilities of an administrator?
- Are users to be allowed root/administrator access to their
workstations?
- The current directory should never be in the directory search path
for administrative users (prevention of trojan horses).
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).
- Zones should be defined, for example:
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.
- Who is responsible for destruction of defective confidential disks
& tapes?
- Who is responsible for destruction of old servers/disks/tapes? May
they be repaired?
- Define directives for server rooms (zone 3):
- All computing devices should be cleanly installed and labelled.
- Wiring should be neat, labelled and such that connections may not be
accidentally disturbed/broken.
- A diagram of what server are installed where should be available,
along with contact persons.
- Define directives for the transport of electronic media (tapes,
backups, disks...).
- All users should be authorised.
- Users should be able to set the privileges of objects belonging to
them in their environment.
- Users should be prevented from deleting others user's files in shared
directories[7].
- Consider allowing root
login only via the console.
- It should be possible to
control user access to all objects on the system (files, printers, devices, databases,
commands, applications etc.) according to a stated policy.
- Users should not be able
to examine the Access Control granted to other users.
- It should be possible to
label data with a classification to .
- Mandatory access control
should be provided.
Basic principle: Give a User the minimum privileges for the shortest
time necessary to do their work.
- Accounts should only exist for authorised persons.
- Each user must be
identified by a name or number and belong to a group.
- Username and group name structure should be standardised enterprise
wide (number of characters, composition) if possible.
- User and groups must be managed by the administrator (or equivalent),
not by users themselves.
- Group accounts are to be avoided (class forbidden).
- Each user should have
only one account on the system.
- If guest accounts are used,
their working environment should be very restricted
- Guest accounts are not allowed.
- Usernames and passwords should not be distributed in the same
communication.
- When a user is transferred or terminates employment, his account
should be blocked or deleted immediately. Procedures should exist whereby the personnel
administration automatically informs system administrators.
- A screenlock should be activated after 15mins idle time with password
protection.
- The current directory
should not be included in the users search path.
- User application & system configuration should only be writable
by the user and not be world readable[8].
- The users file creation
mask ("umask" on UNIX) should not give world read or write access to new files
created.
- Users should be informed of actions that violate security. Likewise
they must inform their security administrator if they suspect a security violation.
- If an account is subjected
to continuous login failures in short period of time (e.g. 20 attempts in 1 hour), block
the account and notify the user. Don't do this for administrative accounts (open a denial
of service attack weakness)!
- When a user logs on the
following should be displayed:
- a legal notice informing the user of implications of system abuse.
- the time & device of last successful and unsuccessful login (user
should check that they are correct).
- Logons should only be
enabled when necessary (e.g. between 06:00 and 22:00 Monday to Friday.
- Avoid allowing direct
superuser logon, especially where more than one person administers a system.
- On Dialup systems:
- disconnect the phone line
after (say) 3 unsuccessful login attempts.
- It should be possible to
specify what ports are available at what time of day.
- If a user enters a bad
login name or password, the error message should be the same for both cases. A possible
attacker should not be informed if a user account is valid, rather that the combination of
account and password is incorrect.[9]
- If an incorrect
username/password combination is entered, wait one second before presenting the login
prompt again. If the combination is again incorrect, wait 2 seconds, the next time 3
seconds etc. This should slow (& frustrate) attackers and especially automated
logon-attack-programs.[10]
- Members of the
administrator groups should be authorised by management.
- It should be possible to
specify how many simultaneous sessions a user may have.
- It should be possible to
set an expiration date for a user account.
- Audits should be run regularly on the system ( once per year, once
every 3 months).
- New servers are installed and prepared by their system administrator.
Then they should be audited and certified to one of the sensitivity levels by security
staff. If all directives cannot be implemented for a particular system (due to OS
limitations for example), these exceptions must be clearly documented in the
Certification.
- Conformance of current operating systems to ITSEC/TCSEC requirements
is discussed the Chapter "Operating Systems Overview".
- Audit trail logs and programs/utilities must be protected. They
should only be accessible by security personnel.
- Logs should not contain passwords.
- System administrator activity (especially use of su in UNIX)
should be logged.
- Unsuccessful login attempts should be logged (and possibly notified).
- Important events should raise an alarm (high priority message)
automatically.
- It should be possible to specify auditing on a per subject and per
object basis.
- Each entry in the audit log should contain at least: Username or UID,
date & time, terminal id, error level (success or failure) and event description.
- Logs should be kept on read-only media if possible (paper, WORM).
Logs should also be forwarded to a specially secure machine instead of locally on each
machine, if possible. Avoid storing logs on shared filesystems.
- All machines should have their clocks synchronised to guarantee the
validity of audit log timestamps.
Backup & Restore Policy
- Backups should be made regularly and some
backup media should be stored regularly off-site.
- Class backups should be
stored in a locked safe. All media must be accounted for. Old tapes must be destroyed, not
thrown away.
- A backup policy must exist (documented) for each system or group of
systems, containing:
- When and how are (full or incremental) backups made, where are media
stored, for how long?
- How often are backups made, who is responsible for checking their
correct operation?
- How long are indices kept? Where are they stored? How can they be
recovered from archive media?
- A restore policy must also exist, containing:
- Who is responsible for checking correct operation?
- A detailed description of what utilities are used how to restore data
for all applications. (e.g. OS, database restore mechanisms).
- In particular a detailed description of how to restore the Operating
System after serious disk or other hardware failures is required. Use of embedded EPROM
commands, single user or diagnostic modes (where available) should be documented.
- The expected restore time for various disaster scenarios should be
documented
- Test the restore policy regularly (
yearly)!
Change Management (sw/hw
installations or updates)
- Only system administrators should install
or update software on servers. Users may not install software on class workstations.
- Systems should be cleanly installed according to vendor instructions.
- A change log, detailing all changes to a system should be kept on
EVERY server. It is suggested that as a minimum, a simple text file be created (e.g. /etc/mods)
containing: Date, sysadmin name, files changed and reason/comment.
- OS installations should include installation of all recommended
patches.
- A label containing the
following information should be stuck on all machines during installation: Hostname,
Machine manufacturer/model, IP address, MAC address, cabling node id (if network topology
allows), end of guarantee date and security/helpline telephone number.
- Servers should also have: the server name on all peripherals, disk
type/guarantee date/superblocks/configuration, console commands for stopping/rebooting
(e.g. special key sequences)
- Only patches from the original sw vendor should be applied. Patches
downloaded from public networks (e.g. Internet) should be checked for integrity using a
strong hashing mechanism (e.g. MD5). Patches should be pre-tested in a test
environment (for at least a few weeks if possible) before being applied to production
systems.
Transmitting information between computers can pose a significant
threat to security.
- Assurance: Network configuration shall be documented.
- Identification and Authentication:
- It should be possible to identify and authenticate any subject on the
corporate network.
- If possible, a single mechanism should be available to log-on users
across multiple applications and systems, therefore avoiding multiple usernames and
passwords.
- Accountability and Audit
- Users are accountable for their actions. They must observe the
"Network User Policy".
- Important network nodes should log activity. These logs should be
regularly analysed for security breaches.
- The Access Control Lists of important filters shall be audited every
6 months.
- Access Control
- Configuration of sensitive Network nodes: Unnecessary network
services shall be disabled. Network services shall be configured restrictively and have
all security bug fixes (patches) installed.
- Available networks could be labelled open access, restricted
access or highly restricted access, so that users/data owners are aware of the
protection offered. For example if a LAN is labelled open access and confidential
information needs to be transmitted over this LAN, then additional measures such as
application level encryption will be necessary to make up for the deficiency on LAN
security. Token ring and FDDI are examples of restricted access networks (if correctly
managed).
- Where restricted access networks are required, cabling should not be
passed through public areas, it should be protected in conduit and connection points
should be only be available to authorised persons. If the cabling is installed by
externals, inspect it.
- Accuracy: Important network nodes should check the integrity of their
data regularly.
- Data Exchange:
- Confidential information shall only be transmitted by approved
transport mechanisms (e.g. Email systems used for confidential data shall be approved by
security management).
- Login session information (e.g. username, password) should not be
sent over the network in clear form.
- Inter-host network services should authenticate each other.
- Networks shall be protected against information eavesdropping => Network
sniffers such as snoop, etherfind, tcpdump, iptrace etc. shall not be available to
users. Networks shall be divided up into subnets, active bridges and hubs shall be used
and unused network connection points shall be disabled.
- Encryption of Class data
before transmission on internal networks should be considered. Class data transmitted over public networks must be encrypted.
- If possible networks
should be protected against electromagnetic eavesdropping.
- When information is being transmitted (sent or received), the
sender's or receivers identity must be attached to the information and checked by the
various components responsible for the transmission.
- Class data should not be
sent to unauthorised users or to systems with a lower classification.
- In certain applications (e.g. class email), mechanisms should exist for proving that sender / receiver did
actually transmit / receive that data. (Proof of origin / receipt).
- Reliability of Service / Availability
- The network is required 24 hours, 7 days a week. Maintenance window
Wednesday 18:00-22:00. Maximum down time during office hours shall be 1 hour, maximum
frequency once every two months.
- The network shall be monitored for errors and performance problems.
Preventative action should be taken before serious network disruptions occur, where
possible.
- Change management: Updates and configuration changes shall be logged
and carried out according to Quality processes.
- A label containing the following information shall be stuck on all
nodes during installation: Hostname, Machine manufacturer/model, IP address, MAC address,
cabling node id (if network topology allows), end of guarantee date and security/helpdesk
telephone number.
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.
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:
- Assurance
- The dial-in server configuration shall be accurately documented.
- It shall be subjected to yearly audits.
- Identification and Authentication
- All incoming Dialup connections (via PSTN or IDSN) shall use a strong
authentication system: one-time passwords, challenge-response, etc..
- Administrator login shall not send passwords in clear-text.
- In addition, the call-back or closed user groups features should be
used, where possible.
- Accountability and audit
- Users shall be accountable for their actions.
- Dial-up servers shall provide detailed logging and auditing of
connections.
- Logs shall be automatically analysed, with critical errors generating
alarms.
- Logs shall be archived for at least one year.
- The non trivial log entries shall be examined daily.
- Statistics on usage should be available.
- The servers shall be subject to regular monitoring (weekly) and
yearly audits.
- Access Control
- Dial-up servers shall not share file or printer resources with other
internal machines, i.e. they shall not be file or printer servers.
- Only administrative personnel shall be allowed to log on locally.
- Users shall not be able to logon directly to these machines
(from the inside).
- Dial-up servers shall be installed in a physically secured (locked)
room.
- A list should be kept of those users with modems. If possible the
telephone network should be regularly scanned for unauthorised modems.
- Switch off modems at night if not needed (you can get a $5 timer to
do this).
- Accuracy: no requirements.
- Data Exchange
- Use encrypted password communication (e.g. encrypted Telnet, SSH) if
possible, especially for remote administrator access.
- Non repudiation of origin & receipt is not required.
- Reliability of Service
- Dial-up servers shall have all unnecessary services stopped.
- Dial-up servers shall be a robust multitasking machines (e.g. UNIX,
VAX or NT).
- 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.
- Change management: Updates and configuration changes shall be logged
and carried out according to Quality processes..
- Alerts should be raised if important processes crash.
- Regular backups shall be made where necessary.
Dial-out network connections can extend the corporate network,
creating uncontrolled points of access to the network.
- Users shall not use dial-out capability (modems) on their machines.
- If such functionality is required, it shall:
- be authorised by the concerned line manager and corporate Security
and the authorisation shall be reissued yearly.
- take place via a centralised "dial-out" server regularly
audited by corporate security.
- be recorded on a list of those users with modems.
- If possible, the telephone network should be regularly scanned for
unauthorised modems.
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.
- Assurance
- The firewall policy and configuration must be accurately documented.
- The firewall machines must be subject to regular monitoring and
yearly audits.
- Identification and Authentication
- Incoming user connections from the Internet shall use a strong
authentication system: one-time passwords, challenge-response, etc..
- Administrator accounts shall also use either a one time password
mechanisms or encrypted login sessions.
- Accountability and audit
- Firewall and proxy machines shall be securely installed. All
unnecessary services shall be stopped in the operating system.
- Detailed firewall logs shall be kept (if possible on a dedicated
server, with write-once media).
- Logs of all security audits shall be kept.
- Logs shall be automatically analysed, with critical errors generating
alarms.
- Logs shall be archived for at least on year.
- The non trivial log entries shall be examined weekly.
- Statistics on usage should be available.
- Access Control
- All Internet access from the corporate network must occur over
proxies situated in a firewall.
- Default configuration: unless otherwise specified, services are
forbidden.
- All users are allowed to exchange email with the Internet
- R&D department users are allowed to use WWW and ftp (over
proxies). Other users require authorisation.
- Users may not provide services to the Internet.
- Research departments requiring full Internet access for experimental
services should not install these services on the corporate network, but on a separate
network outside the Firewall.
- Users should not be able to logon directly onto Firewall
machines.
- Internet access to illicit material should be prevented where
possible.
- Accuracy: The firewall machines shall have the integrity of their
files regularly (every month) checked.
- Data Exchange
- All login sessions to Firewall machines shall use encrypted login or
one time passwords.
- Subversion and spoofing of network services such as routing, DNS and
email should be prevented.
- Reliability of Service
- The Firewall shall be available => 7x24h, maximum downtime 4 hours
(during office hours), maximum frequency twice per month. Maintenance slot: Wednesday
after 18:00.
- Change management: Updates and configuration changes shall be logged
and carried out according to Quality processes.
- Alerts should be raised if important services/processes crash.
- Important services (such as WWW proxy) should be configured for high
availability.
- Regular backups shall be made where necessary (e.g. configuration
files, changing data such as WWW).
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.
- A policy document should exist for each such interface outlining what
information is to be transferred, how and how this relates to the corporate security
policy.
- Such interfaces must be protected by a Firewall and be subject to
regular monitoring and auditing. (see above).
- A Service level agreement shall exist which ensure that the interface
conforms to Network policy.
- A non disclosure agreement should be signed by the customer/vendor,
ensuring that neither details of the interface, nor data accessible via the interface may
be disclosed to third parties.
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.
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
- Legal aspects are not covered in this document. They may be covered
in a later version.
Purpose
Even with a solid security policy, educated users and solid system administration, an
emergency response team is useful. Plan for a disaster!
- Who is on "Firecall", how should they react to a serious
security breach?
- If internal personnel are not expert enough, a "emergency
standby" contract could be outsourced to a specialised company.
- Decide in advance who will be in charge in the event of a security
incident. Determine the chain of command (define processes & responsibility).
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:
- Preparation: The team should have read this chapter and be aware of
the implications.
- Incident detection: quick assessment
- Immediate action: limit damage
- Public Relations / Communications
- Detailed situation analysis
- Recovery: restore data/services/systems
- Follow-up
2. Incident detection: quick assessment
What has happened? :
- Source of threat: e.g. Accidental administrator damage/mistakes,
accidental disclosure of internal or confidential documents, attack from the Internet,
attack from the telephone network, attack from inside the corporate network or a hoax.
- Result of threat: Integrity, confidentiality or availability of
systems/services/data may have been affected.
If an attack has occurred:
- Has the attacker successfully penetrated the systems. Can he re-enter
at will? Where have intruders been detected? What is the extent of the damage? What is the
principal danger posed? e.g. availability, information privacy, information integrity,
adverse publicity.
- Note that "obvious" attacks from one source may, in fact,
hide a much more subtle attack from a different source.
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:
- a restore of information,
- the concerned machine can be isolated from the network, or shutdown,
- the corporate network can be disconnected from the Internet,
- one or more Remote Access servers can be removed from the network,
switched off or shutdown,
- the network or computers are not switched off, but attempts are made
to minimise the damage without affecting user services (this may be a risky approach),
- an immediate copy of all logs/data could be made to tape or other
offline storage.
4. Public Relations / Communications
- Only the Press Responsible may contact or make statements
to the press/reporters.
- If details of an attack need to be discussed with anyone via email,
use encrypted email with signatures (e.g. via PGP).
- If deemed necessary and if authorised by the Press Responsible,
report the incident to a FIRST/CERT and/or other affected sites.
- If the immediate action will affect services to users, inform
helpdesk on what message to pass on to users.
5. Detailed situation analysis:
- Set priorities, decide what to do.
- Determine the extent of damage. E.g.
- Analyse the system(s): what files have changed? What
programs/accounts were added or modified? If modifications are found, check for these
modifications on similar systems.
- Try to confirm exactly what happened.
- Notify administrators, management and law enforcement authorities as
required.
6. Recovery: restore data/services/systems:
- Depending on the incident, the following may be necessary:
- Clean systems and restore data/programs/services.
- Fix weaknesses found in the system.
- Do not trust programs on compromised systems, compare with safe
copies (e.g. OS on CDROM).
6. Follow-up
- Have all services been restored?
- Has the weakness used by the attacker been addressed? Has the cause
been dealt with?
- Do insurance or legal claims/procedures have to be filed?
- Does this Incident Response Procedure need changing?
- If changes to the Firewall are required, active the Firewall change
procedure.
=> End of procedure.
General Guidelines:
- Keep contact names, telephone numbers, email addresses off-line. Do
not assume that your on-line address book will be available in an emergency.
- If the intruder seems very clever and difficult to stop, then it is
worthwhile calling in experts to help.
- Reliable, frequent backups going back several months are very
important.
- For UNIX systems it is highly recommended to get a copy of [unix1] and keep it at hand. It provides detailed
information of detection, monitoring, removing and cleaning up after an intruder. Detailed
technical discussions on firewall services are also available. Also [unix3] [sans3]
and
- For NT systems, the reader is referred to [sans2] for prevention of NT problems, but also [unix1] for it's general discussion on attacks.
- This incident response procedure should be tested, possibly yearly.
- Minimise the disruption to users, communicate with them. Disrupting a
major server for a week to try and track an external attack source may not be worth the
loss of time and money to users.
- All incident response team members should read [sans1].
- See also the new guidelines from CERT, not integrated above.
Responding: www.cert.org/security-improvement/modules/m06.html
, www.cert.org/security-improvement/practices/p046.html
Policies: www.cert.org/security-improvement/practices/p044.html
- Don't forget to check the technical chapters of this book also!
- The SANS Institute produce useful booklets, for example [sans1, [sans2],
[sans3], check out their site to see what other
security booklets they offer. Recommended. www.sans.org
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.
- Separate development and production environments and data.
- Consider security to be an integral part of application development.
- Test data should not contain confidential information.
- Consider using a secured language (e.g. Java rather than C, Tainted
Perl rather than Perl).
- Consider having major new
systems ITSEC approved.
What documentation is to delivered with an application? E.g.
Operating, Installation, Administration, Security, User Manuals.
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:
- The Firecall team should take charge.
- The concerned machine should be disconnected from the network.
- Document every single action taken, events, evidence found (with time
& date).
- Analyse the system: what files changed? What programs/accounts were
added or modified? If modifications are found, check for these modifications on similar
systems.
- Notify administrators, management and law enforcement authorities as
required.
- If you discuss details of the attack with anyone via email, use
encrypted email with signatures.
- Report the incident to a CERT/FIRST if necessary.
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
IT Security Cookbook,
Last Update: 28 Jul 2000