Так получилось, что за последние несколько лет мне довелось несколько раз написать «с нуля» и внедрить в разных компаниях политику информационной безопасности, а также понаблюдать, как это делают коллеги по цеху. В предлагаемой заметке делается попытка обобщить полученный опыт и упомянуть про грабли, оставившие наиболее заметный след на лбу автора. Сразу оговоримся, что далее речь пойдет не о рекомендациях по защите от вирусов или выбору стойкого пароля, а в основном о логике, структуре и назначении подобных документов.
Варианты ответа могут встречаться разные: выполнение распоряжения мудрого руководства, формальное соответствие каким-либо внешним требованиям, желание внедрить загадочные «лучшие практики» или просто давно назревшая потребность формализовать принятые в компании правила безопасности (а не объяснять их на словах каждый раз).
Будем считать, что политика безопасности – это фиксирование внутренних договоренностей между фунциями ИТ, ИБ и ключевыми пользователями от бизнеса о том, что и как необходимо защищать. Под этой простой формулировкой скрывается несколько важных тем, в том числе – расстановка приоритетов, планирование ресурсов, согласие по поводу практических методов реализации и механизмов контроля (не)сделанного. Напомню, что нам нужно не только написать красивую и правильную политику, но и добиться её внедрения на практике.
Другими словами, политика безопасности устанавливает «единые правила игры», является ориентиром для всех вовлеченных товарищей, при этом закрывает ряд формальных требований законодательства и любых внешних проверяющих, а также радует руководство очевидными доказательствами бурной деятельности подразделения по ИБ.
Во время разработки политики безопасности крайне важно представлять себе целевую аудиторию. Маловероятно, что у нас получится написать документ, одинаково пригодный для зампреда правления, начальника отдела системного администрирования и рядового сотрудника склада.
Обычно для руководства готовится презентация (если нужно предложить план действий, варианты решения проблемы или проинформировать о результате), поэтому структура такого документа ничем не отличается от материалов других функциональных подразделений. Когда речь идет о правилах безопасности для пользователей, то это либо памятка на страничку с полем для подписи после ознакомления, либо материалы для системы дистанционного обучения с красивыми картинками.
Целевая аудитория политики безопасности – это руководители и специалисты ИТ-службы, отдела по защите информации, проектного офиса, ключевые пользователи и все прочие обитатели офиса, так или иначе связанные с разработкой, внедрением и поддержкой ИТ-систем. Также не стоит забывать о подрядчиках и консультантах, выполняющих схожие функции по заказу нашей организации.
Точное понимание целевой аудитории дает отличный фильтр, влияющий на то, какое требование включить в политику безопасности, а какое – отбросить; какую формулировку использовать, чтобы впоследствии заставить это требование работать. Проиллюстрируем это на классическом примере с парольной политикой, попутно проигнорировав возможные возражения по поводу качества требуемого пароля:
Термины и определения – один из самых важных разделов нашей будущей политики. Хорошие определения нужны для того, чтобы дать читателю (и по совместителю – исполнителю) четкое представление о предмете и сделать более понятными все выдвигаемые в тексте требования.
Определения проще всего взять из законодательства, стандартов или Википедии, но не факт, что они будут легко читаться и отвечать особенностям той организации, для которой мы разрабатываем политику безопасности. Поэтому для ключевых терминов может оказаться проще и лучше написать определения самостоятельно, сверяясь с упомянутыми выше источниками.
Практика показывает, что после нескольких итераций разработки политики глоссарий содержит примерно 30-40 жизненно необходимых терминов, включая как и узкоспециальные понятия (двухфакторная аутентификация, например), так и более универсальные сущности (сервер, мобильный компьютер, и т.п.), если они не были определены ранее в других политиках или общем глоссарии организации.
Разобравшись с терминами и определениями, самое время посмотреть на структуру содержательной части документа. Общепринятым подходом является брать состав разделов международного стандарта ISO 27002 (или соответствующего ему ГОСТа) или базироваться на любом другом источнике, комплексно описывающем основные принципы защиты информации. Понятно, что и структура, и содержание разделов могут сильно отличаться в зависимости от профиля деятельности нашей организации.
В качестве примера перечислим минимальный набор тем, которые имеет смысл отразить в разрабатываемой политике:
Очевидно, что список разделов можно разбить на менее крупные части и дополнить другими важными темами, но одним из достоинств приведенного выше варианта представляется именно минимальность и достаточность.
Ну и еще одна важная со смысловой точки зрения деталь – политика безопасности может являться описательной («as is», фиксируется текущее состояние) или директивной («to be», что должно быть сделано). Директивный вариант представляется более понятным для чтения и логичным для последующего применения, так как обычно «уже сделано» гораздо меньше, чем «будет сделано».
Хорошо, если в организации есть отдел ведения нормативно-справочной информации или другие ребята, помогающие в нелегком деле разработке нормативных документов. Если же их нет, хорошо бы не забыть о едином хранилище для черновиков и уже утвержденных политик, порядке присвоения версий и, конечно же, типовом шаблоне для документа. Все это поначалу может показаться немного лишним, но при разработке последующих версий политики окажет неоценимую помощь.
Рекомендуется дать избранным коллегам ссылку на черновик документа и предложить задать вопросы про итогам прочтения, чтобы получить непосредственную обратную связь. Если свеженаписанная политика будет с пониманием воспринята, например, упертым сисадмином Сергеем, ветераном режимно-секретного отдела Игорем Степановичем и гордым обладателем сертификата PMI Иваном, то можно считать, что самая строгая проверка качества документа пройдена.
И еще один момент. Как только основная работа над политикой будет закончена, нас ждет проверка орфографии и правил пунктуации. Наверняка в организации найдется хотя бы один сотрудник, который знает их лучше вас и не упустит шанс с удовольствием рассказать всем о найденных в тексте ошибках.
Как известно, процесс согласования любого нормативного документа – отдельная песня, начиная со словесных баталий за отдельные неудобные формулировки и заканчивая квестом по кабинетам с целью получения необходимого набора подписей. Отметим, что косвенным образом трудоемкость этого этапа влияет на частоту обновления политики безопасности и, следовательно, на практическую пользу написанного текста. Так как никому не хочется лишний раз участвовать в этом действии, документ зачастую устаревает раньше, чем его успевают полностью согласовать и утвердить.
Чтобы сократить бессмысленные телодвижения на этом этапе и упростить процедуру согласования политики безопасности, была предложена и затем успешно обкатана примерно следующая схема:
Ну и отдельно отметим, что в перечень согласующих лиц должны быть включены руководители всех подразделений, сотрудники которых и будут исполнять описанные в политике требования. Как правило, это будут ИТ, безопасники, юристы и кадровики.
При разработке политики безопасности мы всегда должны держать в голове необходимость её последующего внедрения. Можно предложить следующие критерии успеха:
Рассмотрение процедуры обработки исключений выходит за рамки этого материала, но отметим самое важное. Наличие универсального механизма принятия решений в ситуациях, не описанных в политике безопасности или противоречащих ей (при невозможности устранить нарушения), является крайне полезным инструментом управления безопасностью.
Еще раз кратко перечислим типовые проблемы, с которыми можно столкнуться при написании политики безопасности:
Ну и, конечно же, автор будет рад любым вопросам и замечаниям, которые могут возникнуть после прочтения этой заметки.
А зачем, собственно?
Варианты ответа могут встречаться разные: выполнение распоряжения мудрого руководства, формальное соответствие каким-либо внешним требованиям, желание внедрить загадочные «лучшие практики» или просто давно назревшая потребность формализовать принятые в компании правила безопасности (а не объяснять их на словах каждый раз).
Будем считать, что политика безопасности – это фиксирование внутренних договоренностей между фунциями ИТ, ИБ и ключевыми пользователями от бизнеса о том, что и как необходимо защищать. Под этой простой формулировкой скрывается несколько важных тем, в том числе – расстановка приоритетов, планирование ресурсов, согласие по поводу практических методов реализации и механизмов контроля (не)сделанного. Напомню, что нам нужно не только написать красивую и правильную политику, но и добиться её внедрения на практике.
Другими словами, политика безопасности устанавливает «единые правила игры», является ориентиром для всех вовлеченных товарищей, при этом закрывает ряд формальных требований законодательства и любых внешних проверяющих, а также радует руководство очевидными доказательствами бурной деятельности подразделения по ИБ.
Дорогие читатели
Во время разработки политики безопасности крайне важно представлять себе целевую аудиторию. Маловероятно, что у нас получится написать документ, одинаково пригодный для зампреда правления, начальника отдела системного администрирования и рядового сотрудника склада.
Обычно для руководства готовится презентация (если нужно предложить план действий, варианты решения проблемы или проинформировать о результате), поэтому структура такого документа ничем не отличается от материалов других функциональных подразделений. Когда речь идет о правилах безопасности для пользователей, то это либо памятка на страничку с полем для подписи после ознакомления, либо материалы для системы дистанционного обучения с красивыми картинками.
Целевая аудитория политики безопасности – это руководители и специалисты ИТ-службы, отдела по защите информации, проектного офиса, ключевые пользователи и все прочие обитатели офиса, так или иначе связанные с разработкой, внедрением и поддержкой ИТ-систем. Также не стоит забывать о подрядчиках и консультантах, выполняющих схожие функции по заказу нашей организации.
Точное понимание целевой аудитории дает отличный фильтр, влияющий на то, какое требование включить в политику безопасности, а какое – отбросить; какую формулировку использовать, чтобы впоследствии заставить это требование работать. Проиллюстрируем это на классическом примере с парольной политикой, попутно проигнорировав возможные возражения по поводу качества требуемого пароля:
Пароль должен содержать не менее 6 символов, в том числе как минимум одну заглавную букву и одну цифру.и альтернативный вариант:
Необходимо реализовать проверку, что выбранный пользователем пароль содержит не менее 6 символов, в том числе как минимум одну заглавную букву и одну цифру.Первое утверждение отлично подойдет для правил по безопасности для пользователей, и то скорее в справочном (а не директивном) порядке, а вот второе прекрасно может быть реализовано как техническое требование безопасности к ИТ-системе.
Прежде чем спорить
Термины и определения – один из самых важных разделов нашей будущей политики. Хорошие определения нужны для того, чтобы дать читателю (и по совместителю – исполнителю) четкое представление о предмете и сделать более понятными все выдвигаемые в тексте требования.
Определения проще всего взять из законодательства, стандартов или Википедии, но не факт, что они будут легко читаться и отвечать особенностям той организации, для которой мы разрабатываем политику безопасности. Поэтому для ключевых терминов может оказаться проще и лучше написать определения самостоятельно, сверяясь с упомянутыми выше источниками.
Практика показывает, что после нескольких итераций разработки политики глоссарий содержит примерно 30-40 жизненно необходимых терминов, включая как и узкоспециальные понятия (двухфакторная аутентификация, например), так и более универсальные сущности (сервер, мобильный компьютер, и т.п.), если они не были определены ранее в других политиках или общем глоссарии организации.
Закон и порядок
Разобравшись с терминами и определениями, самое время посмотреть на структуру содержательной части документа. Общепринятым подходом является брать состав разделов международного стандарта ISO 27002 (или соответствующего ему ГОСТа) или базироваться на любом другом источнике, комплексно описывающем основные принципы защиты информации. Понятно, что и структура, и содержание разделов могут сильно отличаться в зависимости от профиля деятельности нашей организации.
В качестве примера перечислим минимальный набор тем, которые имеет смысл отразить в разрабатываемой политике:
- Организационная структура ИБ и объекты защиты (кто, что и почему защищает – про риски, классификацию активов, распределение ролей и обязанностей).
- Контроль доступа (по сути, правила взаимодействия участников процесса и объектов защиты).
- Управление изменениями (про то, как наши системы должны безопасно и контролируемо переходить из одного состояния в другое).
- Мониторинг и аудит (способы оценки и подтверждения текущего состояния защищенности).
Очевидно, что список разделов можно разбить на менее крупные части и дополнить другими важными темами, но одним из достоинств приведенного выше варианта представляется именно минимальность и достаточность.
Ну и еще одна важная со смысловой точки зрения деталь – политика безопасности может являться описательной («as is», фиксируется текущее состояние) или директивной («to be», что должно быть сделано). Директивный вариант представляется более понятным для чтения и логичным для последующего применения, так как обычно «уже сделано» гораздо меньше, чем «будет сделано».
А судьи кто?
Хорошо, если в организации есть отдел ведения нормативно-справочной информации или другие ребята, помогающие в нелегком деле разработке нормативных документов. Если же их нет, хорошо бы не забыть о едином хранилище для черновиков и уже утвержденных политик, порядке присвоения версий и, конечно же, типовом шаблоне для документа. Все это поначалу может показаться немного лишним, но при разработке последующих версий политики окажет неоценимую помощь.
Рекомендуется дать избранным коллегам ссылку на черновик документа и предложить задать вопросы про итогам прочтения, чтобы получить непосредственную обратную связь. Если свеженаписанная политика будет с пониманием воспринята, например, упертым сисадмином Сергеем, ветераном режимно-секретного отдела Игорем Степановичем и гордым обладателем сертификата PMI Иваном, то можно считать, что самая строгая проверка качества документа пройдена.
И еще один момент. Как только основная работа над политикой будет закончена, нас ждет проверка орфографии и правил пунктуации. Наверняка в организации найдется хотя бы один сотрудник, который знает их лучше вас и не упустит шанс с удовольствием рассказать всем о найденных в тексте ошибках.
Согласие и примирение
Как известно, процесс согласования любого нормативного документа – отдельная песня, начиная со словесных баталий за отдельные неудобные формулировки и заканчивая квестом по кабинетам с целью получения необходимого набора подписей. Отметим, что косвенным образом трудоемкость этого этапа влияет на частоту обновления политики безопасности и, следовательно, на практическую пользу написанного текста. Так как никому не хочется лишний раз участвовать в этом действии, документ зачастую устаревает раньше, чем его успевают полностью согласовать и утвердить.
Чтобы сократить бессмысленные телодвижения на этом этапе и упростить процедуру согласования политики безопасности, была предложена и затем успешно обкатана примерно следующая схема:
- К разработке документа в качестве консультантов привлекаются ключевые сотрудники подразделений, через которые будет проходить согласование. Это подчеркивает ощущение их вовлеченности в процесс и уменьшает риск отказа от исполнения уже принятой политики.
- На уровне руководства обычным бумажным образом проводится договоренность о том, что согласование политик ИТ и ИБ будет осуществляться в электронном виде и фактом утверждения документа является публикация очередной версии политики на корпоративном портале. Бумажные версии при необходимости подписываются в фоновом режиме.
- Процесс согласования переводится в режим «если нет замечаний к определенной дате, то считаем согласованным», а полученные с опозданием возражения и поправки включаются в следующую версию документа. Попутно такой подход неплохо дисциплинирует всех участников процесса.
Ну и отдельно отметим, что в перечень согласующих лиц должны быть включены руководители всех подразделений, сотрудники которых и будут исполнять описанные в политике требования. Как правило, это будут ИТ, безопасники, юристы и кадровики.
Успешность внедрения
При разработке политики безопасности мы всегда должны держать в голове необходимость её последующего внедрения. Можно предложить следующие критерии успеха:
- Целевая аудитория знакома с текстом документа и понимает изложенные в политике требования.
- Большая часть требований политики выполняется на практике, а для невыполненных требований внедрена процедура обработки исключений.
- Существует возможность объективно и независимо проверить предыдущие два утверждения.
Рассмотрение процедуры обработки исключений выходит за рамки этого материала, но отметим самое важное. Наличие универсального механизма принятия решений в ситуациях, не описанных в политике безопасности или противоречащих ей (при невозможности устранить нарушения), является крайне полезным инструментом управления безопасностью.
Про грабли (вместо заключения)
Еще раз кратко перечислим типовые проблемы, с которыми можно столкнуться при написании политики безопасности:
- «А это вообще про что?» – требования, не находящие своего читателя (исполнителя) или обращенные в никуда.
- «Муть какая-то…» – нечеткая терминология, непонятные формулировки требований политики.
- «Полная хрень!» – Сложности при согласовании и внедрении из-за активного противодействия ключевых пользователей, мнение которых не было учтено.
- «Разве документы так пишутся?!» – Игнорирование правил оформления, стилистические, орфографические и пунктуационные ошибки.
Ну и, конечно же, автор будет рад любым вопросам и замечаниям, которые могут возникнуть после прочтения этой заметки.
