Следующим шагом после оценки, как правило, является разработка политик и процедур. Они определяют предполагаемое состояние безопасности и перечень необходимых работ. Без политики нет плана, на основании которого организация разработает и выполнит эффективную программу информационной безопасности.
Необходимо разработать следующие политики и процедуры.
Разработка политик является в большей степени политическим процессом. Во многих отделах найдутся люди, которые заинтересуются политиками и захотят сказать свое слово при их разработке.
Примечание
Как было сказано в "Политика" , определение заинтересованных сторон будет ключевым моментом в создании успешной политики.
Порядок разработки политик
Итак, какая политика должна быть разработана первой? Ответ зависит от рисков, определенных в процессе оценки. Если защита информации определена как область с высоким уровнем риска, информационная политика должна разрабатываться одной из первых. Если же вероятны потери в бизнесе из-за отсутствия плана на случай чрезвычайных действий, то этот план должен быть разработан в первую очередь.
Еще одним фактором в выборе порядка разработки политик является затрачиваемое время. Планы восстановления в случае ЧП обычно представляют очень подробные документы и требуют серьезных усилий со стороны отделов и сотрудников. Этот план потребует много времени для составления; возможно, потребуется помощь стороннего исполнителя, например, компании, поставляющей резервное оборудование для целей полного восстановления на случай стихийного бедствия.
Единственная политика, которая должна быть разработана на начальной стадии процесса, - это информационная политика. Информационная политика формирует основу понимания того, почему внутренняя информация важна и насколько она должна быть защищена. Этот документ послужит основой для программы обучения специалистов по вопросам безопасности, наряду с политикой использования и политикой паролей.
В самом лучшем случае возможна одновременная разработка нескольких политик, поскольку заинтересованные стороны будут объединены общими интересами. Например, системные администраторы интересуются политикой безопасности, но информационная политика их интересует в меньшей степени. Сотрудникам более близка политика безопасности и процедуры управления пользователями, а не политика резервного копирования, и т. д. В этом случае отдел информационной безопасности становится координатором и носителем функций, облегчающих выполнение проекта. Его представители должны присутствовать на первом собрании, посвященном разработке черновой версии плана, и их предложения станут отправным пунктом.
Совет
Для начала попробуйте составить небольшой документ с небольшим числом заинтересованных сторон. Это создаст благоприятную возможность для достижения успеха, что позволит отделу безопасности прийти к соглашениям, необходимым для разработки остальных документов.
Обновление существующих политик
Если политики и процедуры уже существуют, это хорошо. Однако вероятно, что некоторые из этих документов потребуют обновления. Если в их создании принимал участие отдел информационной безопасности, то в первую очередь необходимо собрать все заинтересованные стороны, участвовавшие в работе над предыдущей версии политики, и начать работу по обновлению. Используйте как отправную точку исходный документ и выявленные неточности.
Если в разработке документа участвовал кто-то из сотрудников организации, его также нужно привлечь к работе над обновлением. Отдел информационной безопасности не должен ослаблять контроль над деятельностью бывшего владельца. В этом случае снова начните с исходного документа и выявленных неточностей.
Если разработчик исходного документа больше не числится в организации, то проще начать с чистого листа. Выявите заинтересованных лиц и пригласите их принять участие в процессе. Сообщите им, почему старый документ больше не является удовлетворительным
Вопросы для самопроверки