Руководство по безопасности предприятия

Network Working Group B. Fraser
Request for Comments: 2196 Editor
FYI: 8 SEI/CMU
Obsoletes: 1244 September 1997
Category: Informational



Статус данного руководства

Это руководство предоставляет информацию для Интернет-сообщества. Оно
не определяет какого-либо стандарта Интернет. Распространение данного
документа не ограничено.

Резюме

Эта книга является руководством по созданию политики и процедур
компьютерной безопасности для организаций имеющих системы
подключенные к Интернет. Цель руководства - дать практические
инструкции для администраторов пытающихся защитить свою информацию и
сетевые службы. Затрагивается тематика содержания и формаирования
политики, широкий спектр проблем технических систем, сетевой
безопасности и ответов на инциденты.

Содержание

1. Введение
1.1 Цель этой книги
1.2 На кого рассчитан данный документ
1.3 Определения
1.4 Кроме того
1.5 Основной подход
1.6 Оценка угроз
2. Политики безопасности
2.1 Что такое политика безопасности и зачем она нужна?
2.2 Что составляет хорошую политику безопасности?
2.3 Поддержание гибкости политики
3. Architecture.................................................... 11
3.1 Objectives...................................................... 11
3.2 Network and Service Configuration............................... 14
3.3 Firewalls....................................................... 20
4. Security Services and Procedures................................ 24
4.1 Authentication.................................................. 24
4.2 Confidentiality................................................. 28
4.3 Integrity....................................................... 28
4.4 Authorization................................................... 29
4.5 Access.......................................................... 30
4.6 Auditing........................................................ 34
4.7 Securing Backups................................................ 37
5. Security Incident Handling...................................... 37
5.1 Preparing and Planning for Incident Handling.................... 39
5.2 Notification and Points of Contact.............................. 42
5.3 Identifying an Incident......................................... 50
5.4 Handling an Incident............................................ 52
5.5 Aftermath of an Incident........................................ 58
5.6 Responsibilities................................................ 59
6. Ongoing Activities.............................................. 60
7. Tools and Locations............................................. 60
8. Mailing Lists and Other Resources............................... 62
9. References...................................................... 64

Введение

В этом документе даны инструкции для системных и сетевых
администраторов о том, как решать проблемы безопасности в
Интернет-сообществе. Он построен на основах заложенных в RFC 1244 и
является коллективной работой нескольких принимавших участие авторов.
Среди этих авторов:

Jules P. Aronson (aronson@nlm.nih.gov), Nevil Brownlee
(n.brownlee@auckland.ac.nz), Frank Byrum (byrum@norfolk.infi.net),
Joao Nuno Ferreira (ferreira@rccn.net), Barbara Fraser
(byf@cert.org), Steve Glass (glass@ftp.com), Erik Guttman
(erik.guttman@eng.sun.com), Tom Killalea (tomk@nwnet.net), Klaus-
Peter Kossakowski (kossakowski@cert.dfn.de), Lorna Leone
(lorna@staff.singnet.com.sg), Edward.P.Lewis
(Edward.P.Lewis.1@gsfc.nasa.gov), Gary Malkin (gmalkin@xylogics.com),
Russ Mundy (mundy@tis.com), Philip J. Nesser
(pjnesser@martigny.ai.mit.edu), and Michael S. Ramsey
(msr@interpath.net).

Кроме основных авторов, несколько читателей добавляли различные
комментарии. Среди них:

(luiijf@fel.tno.nl), Marijke Kaat (marijke.kaat@sec.nl), Ray Plzak
(plzak@nic.mil) and Han Pronk (h.m.pronk@vka.nl).

Особые благодарности Joyce Reynolds, ISI, и Paul Holbrook, CICnet, за
их проницательность, лидерство при создании первой версии этой книги.
Рабочая группа искренне надеется, что эта версия окажется не менее
полезной для сообщества.


1.1 Цель этой книги

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

Это руководство лишь основа для создания политики и процедур
безопасности. Чтобы иметь эффективный набор политик и процедур
предприятие должно принять большое число решений, придти к согласию и
затем наладить связи и внедрить эти политики.

1.2 На кого рассчитан данный документ

Данный документ рассчитан на сетевых и системных администраторов и
людей ответственных за принятие решений (обычно руководителей
среднего звена) предприятий. Для краткости в тексте документы мы
будем использовать термин "администраторы" для обозначения сетевых и
системных администраторов.

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

К основной аудитории этой работы относятся предприятия являющиеся
членами Интернет-сообщества. В то же время этот документ будет
полезен любому предприятию имеющему контакты с другими предприятиями
и может быть полезен предприятиям имеющим изолированные системы.

1.3 Определения

Для целей данного руководства будем считать, что "предприятие"
означает организацию, которая владеет компьютерами или другими
сетевыми ресурсами. Эти ресурсы могут включать сетевые компьютеры,
используемые пользователями, маршрутизаторы, терминальные серверы, ПК
или другие устройства с доступом через Интернет. Предприятие может
быть конечным потребителем услуг Интернет, или поставщиком услуг
Интернет. Этот документ более предназначен для конечного пользователя
услуг Интернет. Мы надеемся, что у предприятия есть возможность
установить политики и процедуры с согласия и при помощи того, кто в
действительности владеет ресурсами. Мы будем предполагать, что
предприятия, являющиеся подразделениями более крупных организацию
знают, когда следует консультироваться, сотрудничать или принимать
рекомендации более крупной структуры.

"Интернет" это набор тысяч сетей соединенный общим набором
технический протоколов, что делает возможным для пользователей любой
из сетей связываться или использовать сетевые службы расположенные в
любой другой сети (FYI4, RFC 1594).

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

Термин "администратор безопасности" используется для обозначения
людей отвечающих за безопасность информации и информационных
ресурсов. В некоторых организациях эти функции могут сочетаться с
функциями администратора, в других - это отдельная должность.

Термин "руководитель" относится к людям в организации, которые
устанавливают или утверждают политику. Обычно (но не всегда) это люди
которым принадлежат ресурсы.

1.4 Кроме того

Рабочая группа "Руководства по безопасности предприятия" так же
работает над пользовательским руководством по безопасности в
Интернет. Оно обеспечит практические рекомендации конечным
пользователям чтобы помочь им защитить их информацию и ресурсы,
которыми они пользуются.

1.5 Основной подход

Это руководство создано, чтобы дать основные рекомендации в
разработке плана безопасности для вашей организации. Один из принятых
подходов предложен Fites, et. al. [Fites 1989] и включает следующие
шаги:

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

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


1.6 Оценка угроз

1.6.1 Общее обсуждение

Одна из наиболее важных причин создания политики компьютерной
безопасности это уверенность в том, что вложения в безопасность
принесут экономически эффективную выгоду. Хотя это может казаться
очевидным, можно ошибаться в том, где требуются вложения. Например,
большое внимание общественности уделяется внешним вторжениям в
компьютерные системы; но большая часть руководств по компьютерной
безопасности указывает на то, что действительные потери от внутренних
факторов гораздо выше.

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

Законченный процесс анализа угроз находится за пределами данного
документа. [Fites 1989] и [Pfleeger 1989] дают введение в этот
раздел. В то же время существует два элемента анализа угроз, которые
будут кратко раскрыты в следующих двух разделах:


(1) Определение ресурсов
(2) Определение угроз

Для каждого ресурса основной целью безопасности является его
доступность, конфиденциальность и целостность. Каждая угроза должна
быть рассмотрена как угроза затрагивающая эти области.


1.6.2 Определение ресурсов

Один из шагов анализа угрозы это определение всего, что требует
защиты. Некоторые вещи являются очевидными, например дорогая
информация, интеллектуальная собственность и различное оборудование;
но другие часто упускаются - например сами люди, использующие
систему. Неотъемлемой деталью является перечисление всего, что может
быть затронуто проблемой безопасности.

Один из списков категорий предложен Pfleeger [Pfleeger 1989]; этот
список разработан на основе него:

(1) Оборудование: Процессоры, платы, клавиатуры, терминалы, рабочие
станции, персональные компьютеры, принтеры, диски, линии связи,
терминальные серверы, маршрутизаторы.
(2) Программы: исходные тексты, объектные модули, утилиты,
диагностические программы, операционные системы,
коммуникационные программы.
(3) Данные: во время выполнения, хранимые в системе, хранимые
отдельно, резервные копии, журналы аудита, базы данных, во время
перемещения в среде передачи данных.
(4) Люди: пользователи, администраторы, техники.
(5) Документация: по программам, оборудованию, системам, локальным
процедурам администрирования.
(6) Расходные материалы: бумага, лотки, картриджы, магнитные
носители.

1.6.3 Определение угроз

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

(1) Несанкционированный доступ к ресурсам и/или информации
(2) Нежелательное и/или несанкционированное раскрытие информации
(3) Отказ в обслуживании

2. Политики безопасности

На протяжении данного документа будет много упоминаний политик.
Обычно эти упоминания будут связаны с рекомендациями для определенных
политик. Чтобы не повторять рекомендации о том, как создавать и
передавать такую политику, читатель должен применять советы этого
раздела при разработке любой политики, рекомендуемой в дальнейшем в
этой книге.

2.1 Что такое политика безопасности и зачем она нужна?

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

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

Ваши цели будут во многом определены следующими ключевыми
противоречиями:

(1) предлагаемые услуги против обеспечиваемой безопасности -
Каждая услуга, предлагаемая пользователям вносит собственные
угрозы безопасности. Для некоторых услуг угроза перевешивает
преимущества услуги и администратор может принять решение
исключить услугу, вместо того, чтобы пытаться сделать ее
безопасной.

(2) простота использования против безопасности -
Самая простая в использовании система это та, которая позволяет
доступ пользователю и не требует пароля; т.е. в которой не может
быть безопасности. Необходимость пароля делает систему чуть
менее удобной, но более защищенной. Необходимость одноразового
сгенерированного пароля делает систему еще менее удобной, но еще
более повышает безопасность.

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


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

2.1.1 Определение политики безопасности

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

2.1.2 Задачи политики безопасности

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

Политика правильного использования (Appropriate Use Policy, AUP) так
же может быть частью политики безопасности. В ней должно быть
заявлено, что пользователи должны и чего не должны делать с
различными компонентами своей системы, включая типы трафика
разрешенные в сети. AUP должна быть настолько подробной, насколько
это возможно, чтобы исключить неопределенность или недопонимание.
Например, AUP может перечислить недопустимый группы конференций. (В
некоторых организациях AUP так же может быть Acceptable Use Policy -
политика допустимого использования).

2.1.3 Кто должен привлекаться к формирования политики?

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

(1) администратор безопасности предприятия
(2) технический IT-персонал (т.е. персонал вычислительного центра)
(3) администраторы больших групп пользователей внутри организации
(т.е. подразделений, информационных отделов университетов и
т.д.)
(4) команда реагирования на происшествия связанные с безопасностью
(5) представители групп пользователей затронутых политикой
безопасности
(6) ответственный руководитель
(7) юрисконсультант (если требуется)

Этот список достаточно представителен для большинства предприятий, но
не обязательно полон. Основная идея - чтобы представлены были все -
учредители, руководители отвечающие за бюджет и подписывающих
политику, технический персонал, знающий что может и что не может быть
реализовано и юрист, который знает побочные явления различных
вариантов политики. В некоторых организациях может потребоваться
подключение внешних аудиторов. Подключение этой группы может быть
важным если требуется достичь общего приятия политики. Нужно
отметить, что роль юриста будет сильно зависеть от страны.

2.2 Что составляет хорошую политику безопасности?

Характеристики хорошей политики безопасности следующие:

(1) Она должна быть реализуема через процедуры системного
администрирования, публикацию руководств по использованию или
другими допустимыми методами.

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

(3) Она должна четко определять области ответственности
пользователей, администраторов и руководителей.

Компоненты хорошей политики безопасности включают:

(1) Руководство закупки вычислительных технологий, которое
определяет требуемые или желательные возможности безопасности.
Оно должно дополнять существующие политики и руководства
закупок.

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

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

(4) Политика учета, которая определяет ответственности
пользователей, операторов и руководства. Она должна определять
возможности аудита и предоставлять руководства по обработке
происшествий (например что делать и с кем связываться если
обнаружено возможное вторжение).

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

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

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

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

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

Могут быть регулируемые законом требования, которые затрагивают
некоторые аспекты вашей политики безопасности (например прослушивание
линий). Создатели политики безопасности должны рассмотреть
привлечение юрисконсультанта к созданию политики. Как минимум
политика должна быть просмотрена юристом.

После того, как ваша политика установлена она должна быть четко
доведена до пользователей, сотрудников и руководства. Важной частью
процесса является подписание сотрудниками соглашения, что они
прочитали, поняли и согласны выполнять политику. Наконец, ваша
политика должна регулярно пересматриваться на предмет полного
соответствия вашим требованиям безопасности.


2.3 Поддержание гибкости политики

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

Важно так же отметить, что из любого правила бывают исключения.
Везде, где это возможно, политика должна указывать какие
существуют исключения из общей политики. Например условия, при
которых администраторы имеют право обратиться к пользовательским
файлам. Или когда несколько пользователей могут использовать одну
учетную запись - например "root", несколько системных администраторов
могут знать пароль учетной записи супер-пользователя.

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

http://securityvulns.ru/articles/RFC2196/

Обновлено: 11.03.2015