Политика обеспечения компьютерной и сетевой безопасности (IT Security Cookbook)

Администратор обеспечивает доступность системы, доступ к конфиденциальной информации только авторизованным лицам и защиту информации от неавторизованного изменения.

Следует определить:

• Кто/где обновляет административные политики?
• Кто уполномочен давать доступ и разрешать использование? Кто может иметь привилегии администратора¹⁾?
• Каковы права и обязанности администратора?
• Имеют ли пользователи административный доступ к своим рабочим станциям?
• Текущей директории не должно быть в пути поиска по каталогам для администраторов (защита от троянских коней).

Политика физической безопасности должна детально описывать меры по защите зданий в случае чрезвычайных происшествий (наводнений, пожаров, землетрясений, взрывов, отключений электроэнергии), в случае краж, нарушений прав доступа, по защите сейфов, помещений с компьютерами и коммутационных шкафов. (см. также раздел Физическая безопасность).

• Должны быть определены зоны безопасности, например:
  • Зона 1: общедоступная зона.
  • Зона 2: зона, доступная только персоналу.
  • Зона 3: закрытая зона. Доступна только после идентификации, доступ строго контролируется.
• Следует определить кто отвечает за уничтожение дефектных конфиденциальных дисков и лент.
• Необходимо определить кто отвечает за уничтожение старых серверов/дисков/лент и можно ли их отремонтировать.
• Должны быть определены правила для серверных (зона 3):
• Все компьютерные устройства должны быть правильно установлены и промаркированы.
• Коммуникации должны быть упорядочены, промаркированы. Следует обеспечить их защиту от случайного повреждения.
• Необходима схема расположения серверов с указанием ответственных лиц.
• Должны быть определены правила транспортировки электронных носителей (лент, резервных копий, дисков).

• Все пользователи должны быть авторизованы.
• Пользователи должны иметь возможность определять права доступа к принадлежащим им объектам в своём окружении.
• Пользователи не должны иметь прав на удаление объектов других пользователей в каталогах общего доступа ²⁾.
• Логин суперпользователя должен быть разрешен только через консоль (класс 3).
• Следует обеспечить контроль над правами доступа ко всем объектам системы (файлам, принтерам, устройствам, базам данных, командам, приложениями и т. д.) в соответствие с утверждённой политикой (класс 3).
• Пользователи не должны знать права доступа, предоставленные другим пользователям (класс 3).
• Следует маркировать данные в соответствие с классами от 1 до 4 (класс 4)

Необходимо обеспечить обязательный контроль доступа (класс 4).

Основные принципы:

• Давать пользователю как можно меньше прав на как можно меньший промежуток времени, достаточные для выполнения необходимой работы.
• Учетные записи должны существовать только для допущенных людей.
• Каждый пользователь должен быть идентифицирован по имени или номеру и принадлежать группе (для класса 2).
• По возможности, структура имени пользователя и названия группы должна быть унифицирована по всему предприятию (количество символов, расположение).
• Учетные записи пользователей и группы должны управляться администратором (или лицом, заменяющим его), но не пользователями самостоятельно.
• Следует избегать групповые учетные записи (класс 3 запрещен).
• Каждый пользователь должен иметь одну учетную запись в системе (для класса 3).
• Если используются гостевые учетные записи, их рабочее окружение должно быть сильно ограничено (для класса 2).
• Гостевые учетные записи запрещены.
• Имена пользователей и пароли должны быть распределены по разным средствам связи.
• Если пользователь переведен или прекратил работу, его учетная запись должна быть немедленно заблокирована или удалена. Должны существовать процедуры по автоматическому уведомлению отделом кадров системных администраторов.
• Блокировка экрана с защитой паролем должна сработать через 15 минут простоя.
• Текущая директория не должна быть включена в путь поиска пользователя (для класса 3).
• Пользовательские приложения и системную конфигурацию можно записывать только пользователю и они не должны быть доступны извне³⁾.
• Маска создания файлов пользователями («umask» на UNIX) не должна позволять чтение извне или доступ на чтение или запись для вновь созданных файлов (для класса 3).
• Пользователи должны быть уведомлены о действиях, нарушающих безопасность. Также, они должны ставить в известность системных администраторов, если они подозревают нарушение безопасности.
• Если учетная запись подвергается повторяющимся безуспешным попыткам авторизации за короткий промежуток времени (например, 20 попыток за 1 час), заблокировать учетную запись и уведомить пользователя. Не применяется для администраторских учетных записей (открывает уязвимость отказа в обслуживании)(для класса 2):
  1. официальное уведомление, информирующее пользователя о последствиях злоупотребления системой.
  2. время и устройство последних успешной и безуспешной попытки авторизации (пользователь должен проверить на правильность).
• Учетные записи должны быть доступны только когда необходимо (например, между 6:00 и 22:00 с понедельника по пятницу)(для класса 2).
• Избегать разрешения явной авторизации как суперпользователь, особенно в системах, где более одного администратора (для класса 2).
• Для коммутируемых систем:
  1. отсоединиться от телефонной линии после (допустим) 3 безуспешных попыток авторизации (для класса 2).
  2. должна быть возможность указать в какое время дня какие порты доступны (для класса 3).
• Если пользователь вводит неправильный логин или неправильный пароль, сообщение об ошибке должно быть одинаково для обоих случаев. Потенциальный взломщик не должен знать правильно ли введен логин, только, что комбинации логина и пароля неверна⁴⁾(для класса 3).
• Если введен неправильный логин/пароль, подождать одну секунду перед предложением новой попытки авторизации. Если комбинация опять неверна, подождать 2 секунды, в следующий раз - 3 секунды, и так далее. Это замедлит (и сделаем тщетными попытки) атакующего и, особенно, автоматизированных программ по подбору логинов⁵⁾ (для класса 3).
• Члены группы администраторов должны быть утверждены руководством (для класса 3).
• Должна быть возможность установки максимального количество одновременных сессий для пользователя (для класса 3).
• Должна быть возможность установки срока годности учетной записи пользователя (для класса 2).

• Аудит системы должен проводиться регулярно (для класса 2 раз в год, для класса 3 - каждые три месяца).
• Новые серверы должны быть установлены и подготовлены их системными администраторами. Затем, необходимо провести аудит и сертифицировать на один из уровней защищенности службой безопасности. Если все не предписания могут быть выполнены для конкретной системы (например, из-за ограничений ОС), эти исключения должны быть четко документированы в Сертификате.
• Соответствие текущих операционных систем требованиям ITSEC/TCSEC обсуждается в части «Обзор операционных систем».

• Журнал аудита и приложения/утилиты должны быть защищены. Они должны быть доступны только службе безопасности.
• Журналы не должны содержать пароли.
• Работа системного администратора (особенно использование su в UNIX) должны быть журналирована.
• Неудачные попытки авторизации должны быть журналированы (и, возможно, доведены до сведения).
• Важные события должны поднимать тревогу (сообщение с высоким приоритетом) автоматически.
• Должна быть возможность проведения аудита по субъектному и объектному признаку.
• Каждая запись в журнале аудита должна содержать как минимум: Имя пользователя или его идентификатор, дату и время, идентификатор терминала, уровень ошибки (успех или провал) и описание события.
• Журналы должны храниться на носителям с доступом только на чтение, если возможно (бумага, единожды записываемая память). Также, журналы должны храниться на специально выделенном защищенном компьютере вместо локальных компьютеров, если возможно. Избегать хранения журналов на общедоступных файловых хранилищах.
• Часы на всех компьютерах должны быть синхронизированны для гарантии действительности временных меток журналов аудита.

Политика резервных копий и восстановления данных

• Резервное копирование должно проводиться регулярно и некоторые носители с резервными копиями должны храниться отдельно от системы.
• Резервные копии для класса 3 должны храниться в запираемом сейфе. Все носители должны быть под учетом. Старые записи должны быть уничтожены, а не выброшены.
  • Политика резервных копий должна существовать (документировано) для каждой системы или группы системы, и должна содержать:
  • Когда и как (полное или инкрементальное) сделано резервное копирование, где хранится носитель, в течение какого времени?
  • Как часто делается резервное копирование, кто ответственный за проверку корректности операции?
• Как долго хранятся индексы? Где они сохранены? Как они могут быть восстановлены с архивных носителей?
• Также должна существовать политика восстановления данных, и она должна содержать:
  • Кто ответственный за проверку корректности операции?
  • Подробное описание какие утилиты используются для восстановления данных для всех приложений (например, ОС, механизмы восстановления базы данных.
  • В частности, требуется подробное описание восстановления операционной системы после серьезного отказа диска или другого аппаратного обеспечения. Должно быть документировано использование встроенных EPROM команд, одиночного пользователя или режимов диагностики (где доступно).
  • Должно быть документировано ожидаемое время восстановления после различных сценариев выхода системы из строя.
• Регулярно проверять выполнение политики восстановления данных.

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.

Передача информации между компьютерами может оказаться серьёзной брешью в безопасности.

1. Надёжность: конфигурация сети должна быть задокументирована.

2. Идентификация и аутентификация:

• Любой субъект корпоративной сети должен быть идентифицирован и аутентифицирован.
• Если возможно, следует использовать единый механизм для входа пользователей в различные приложения и системы, избегая тем самым большого количества имен пользователей и паролей.

3. Ответственность и аудит

• Пользователи ответственны за свои действия. Они должны соблюдать «Политику использования сети».
• Важные сетевые узлы должны протоколировать свою активность. Протоколы должны регулярно анализироваться на наличие уязвимостей.
• Списки доступа важных фильтров должны подвергаться аудиту каждые 6 месяцев.

4. Контроль доступа

• Конфигурация защищаемых сетевых узлов: неиспользуемые сетевые службы должны быть отключены. Сетевые службы должны быть правильно сконфигурированы, все обновления безопасности должны быть установлены.
• Доступные сетевые ресурсы должны быть помечены как сети открытого доступа, ограниченного доступа или строго ограниченного доступа, чтобы пользователи/владельцы данных были в курсе о степени защиты. Например, если локальная сеть помечена как открытая и необходимо передавать через неё конфиденциальную информацию, то необходимо принять дополнительные меры, например, шифрование на уровне приложения, чтобы обеспечить должный уровень безопасности сети. Токен ринг и FDDI (распределённый волоконный интерфейс данных) являются примерами сетей с ограниченным доступом (в случае правильной конфигурации).
• В местах, где необходимы сети с ограниченным доступом, коммуникационные кабели не должны проходить в общедоступных зонах, они должны быть защищены кабель-каналами и сетевые розетки должны быть доступны только авторизованному персоналу.
• Если коммуникации прокладывались сторонней организацией, необходимо проконтролировать работу.

5. Важные сетевые узлы должны регулярно проверять целостность своих данных.

6.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 3 data before transmission on internal networks should be considered. Class 3 data transmitted over public networks must be encrypted.
  • If possible networks should be protected against electromagnetic eavesdropping (for class 3).
• 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 3 data should not be sent to unauthorised users or to systems with a lower classification.
• In certain applications (e.g. class 3 email), mechanisms should exist for proving that sender / receiver did actually transmit / receive that data. (Proof of origin / receipt).

7.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 Secur ID).

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

1.Assurance

• The dial-in server configuration shall be accurately documented.
• It shall be subjected to yearly audits.

2.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.

3.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.

4.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).

5.Accuracy: no requirements.

6.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.

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.

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:

• 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.

1.Assurance

• The firewall policy and configuration must be accurately documented.
• The firewall machines must be subject to regular monitoring and yearly audits.

2.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.

3.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.

4.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.

5.Accuracy

• The firewall machines shall have the integrity of their files regularly (every month) checked.

6.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.

7.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. Other_Boss (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. Other_Techie (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. Other_PrMan (Tel. Xxx).

Responsibility: Handles interfaces to the media, public statements, co-ordinate communications. Additional Help:

Legal Advice ?

First Response Team, See appendices.

Procedure

1.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? :

• 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).

7. 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.

Безопасность должна быть неотъемлемой частью новых систем. Если разработаны функциональные требования, требования безопасности должны формулироваться в соответствие с уязвимостями, а также доступностью данных, которые будут обрабатываться системой.

• Раздельные разработка и создание сред обработки и данных.
• Безопасность должна быть неотъемлемой частью разработки ПО.
• Тестовые данные не должны содержать конфиденциальной информации.
• Используйте безопасный язык (например, Java предпочтительнее С, Tainted perl предпочтительнее Perl).
• Используйте одобренные ITSEC известные системы (класс 3).

• Какая документация поставляется с ПО? Например, использование, установка, администрирование, безопасность, инструкции.

• Политика информационной безопасности (IT Security Cookbook)
• Политика информационной безопасности для персонала (IT Security Cookbook)
• Политика обеспечения физической защиты (IT Security Cookbook)
• Политика обеспечения непрерывности ведения бизнеса (IT Security Cookbook)