Как написать политику информационной безопасности

Как я писал политику безопасности

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

А зачем, собственно?

Варианты ответа могут встречаться разные: выполнение распоряжения мудрого руководства, формальное соответствие каким-либо внешним требованиям, желание внедрить загадочные «лучшие практики» или просто давно назревшая потребность формализовать принятые в компании правила безопасности (а не объяснять их на словах каждый раз).

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

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

Дорогие читатели

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

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

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

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

Пароль должен содержать не менее 6 символов, в том числе как минимум одну заглавную букву и одну цифру.

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

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

Прежде чем спорить

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

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

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

Закон и порядок

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

В качестве примера перечислим минимальный набор тем, которые имеет смысл отразить в разрабатываемой политике:

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

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

Ну и еще одна важная со смысловой точки зрения деталь – политика безопасности может являться описательной («as is», фиксируется текущее состояние) или директивной («to be», что должно быть сделано). Директивный вариант представляется более понятным для чтения и логичным для последующего применения, так как обычно «уже сделано» гораздо меньше, чем «будет сделано».

А судьи кто?

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

Рекомендуется дать избранным коллегам ссылку на черновик документа и предложить задать вопросы про итогам прочтения, чтобы получить непосредственную обратную связь. Если свеженаписанная политика будет с пониманием воспринята, например, упертым сисадмином Сергеем, ветераном режимно-секретного отдела Игорем Степановичем и гордым обладателем сертификата PMI Иваном, то можно считать, что самая строгая проверка качества документа пройдена.

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

Согласие и примирение

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

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

1. К разработке документа в качестве консультантов привлекаются ключевые сотрудники подразделений, через которые будет проходить согласование. Это подчеркивает ощущение их вовлеченности в процесс и уменьшает риск отказа от исполнения уже принятой политики.
2. На уровне руководства обычным бумажным образом проводится договоренность о том, что согласование политик ИТ и ИБ будет осуществляться в электронном виде и фактом утверждения документа является публикация очередной версии политики на корпоративном портале. Бумажные версии при необходимости подписываются в фоновом режиме.
3. Процесс согласования переводится в режим «если нет замечаний к определенной дате, то считаем согласованным», а полученные с опозданием возражения и поправки включаются в следующую версию документа. Попутно такой подход неплохо дисциплинирует всех участников процесса.

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

Успешность внедрения

При разработке политики безопасности мы всегда должны держать в голове необходимость её последующего внедрения. Можно предложить следующие критерии успеха:

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

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

Про грабли (вместо заключения)

Еще раз кратко перечислим типовые проблемы, с которыми можно столкнуться при написании политики безопасности:

• «А это вообще про что?» – требования, не находящие своего читателя (исполнителя) или обращенные в никуда.
• «Муть какая-то…» – нечеткая терминология, непонятные формулировки требований политики.
• «Полная хрень!» – Сложности при согласовании и внедрении из-за активного противодействия ключевых пользователей, мнение которых не было учтено.
• «Разве документы так пишутся?!» – Игнорирование правил оформления, стилистические, орфографические и пунктуационные ошибки.

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

Источник статьи: http://habr.com/ru/post/275811/

Как разработать Политику информационной безопасности?

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

• Конфиденциальность — только уполномоченное лицо должно иметь доступ к информации
• Целостность — информация должна сохраняться в должной форме
• Доступность — информация должна быть доступна всякий раз, когда она требуется уполномоченному лицу

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

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

Первым шагом для обеспечения чего-либо является знание того, что вы намерены обеспечить. Да, вы хотите защитить сетевые активы компании, но какими должны быть компоненты такой сети? Какие сверхмалые ресурсы и частицы делают сеть СЕТЬЮ?

Ознакомление с деятельностью компании

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

Рекомендации:

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

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

Оценка риска

Наиболее подходящий метод оценки риска – это использование показателей ожидаемых ежегодных убытков (ALE), ожидаемого единичного случая убытка (SLE) и ежегодной частоты возникновения события (ARO).

• ALE –ожидаемая сумма убытков в течение года
• SLE – сумма, которую вы ожидаете потерять за один раз
• ARO — частота, с которой событие может произойти в течение года

Позвольте объяснить данный метод на примере:

Вы разрабатываете политику сетевой безопасности для крупной компании. Сетевой актив вашей компании, например, сервер, генерирует доход 25 000 долларов в час. Вероятность сбоя в работе для этого веб-сервера в течение года составляет 25% (вероятность может быть рассчитана на основе среднего числа подобных событий, имевших место в последние годы). Сбой в работе может привести к трёхчасовому простою и стоить 5000 долларов в расчёте на компоненты, используемые для устранения проблемы. Итак, чему будет равна ALE?

SLE составляет 80 000 $ (25 000 $ x 3 часа + 5000 $), а ARO — 0,25. Тогда ALE составляет 20 000 $ (80 000 $ x 0,25). Принимая во внимание то, что ваша компания должна ожидать 20 000 $ убытков в год.

Разработка политики

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

Область применения

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

Методы оценки риска

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

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

• Какие методы авторизации пользователя приемлемы в сети? TACACS + или RADIUS?
• Сервер Syslog всегда должен быть архивирован.
• Все сообщения должны быть зашифрованы, укажите способ шифровки.
• Сеть должна быть защищена брандмауэром и сетевыми модулями. Укажите тип брандмауэра.
• Кто является основным производителем сетевого оборудования? CISCO или Huawei? В каком сегменте сети и почему?
• Кто имеет корневой доступ или секретный доступ к маршрутизаторам и коммутаторам?
• Какие сервисы сети никогда не будут использоваться? Скажите «НЕТ» телнету и включите SSHv2, однако имейте в виду, что SSHv1 и SSHv2 не используются в комплексе. Используйте один из них.
• Все сетевые устройства должны использовать логин-баннеры. Проконсультируйтесь с юристом и подготовьте единый и понятный сетевой баннер, указав, что несанкционированный доступ к вашему оборудованию запрещён.
• Как создаются списки доступа, кто их контролирует.
• Управление IDS и IPS

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

Реализация политики

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

Мониторинг и аудиты

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

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

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

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

1. Оценка рисков — активы, риски и угрозы.
2. Политика безопасности
3. Пересмотр политики безопасности

Источник статьи: http://bizeducate.com/09/2018/kak-razrabotat-politiku-informatsionnoj-bezopasnosti/