В конце квартала системный администратор открывает папку «Документы ИБ» и создает новый файл. Название старое: «Политика_информационной_безопасности_v3.2». Он копирует текст из предыдущей версии, меняет дату, обновляет номер приказа. Потом отправляет на согласование. Все подписывают без правок. Через три дня документ ложится в сеть, где его никто не откроет.
Политики безопасности никто не читает. Регламенты работы с данных открывают один раз, когда расписываются в ознакомлении. Инструкции по реагированию на инциденты лежат в корпоративной папке, и про них вспоминают только когда инцидент уже случился.
Внутренние документы по информационной безопасности существуют в параллельной реальности. Их пишут, утверждают, версионируют. Но применять не применяют. Не потому что сотрудники безответственные. А потому что прочитать 40 страниц про "порядок обеспечения конфиденциальности при обработке сведений ограниченного распространения" физически невыносимо.
Тот, кто пишет, знает, что не будут читать. Тот, кто утверждает, знает, что документ останется формальностью. Аудитор знает, что проверяет наличие, а не применимость. Но система продолжает работать именно так.
Почему политики безопасности никто не читает
Локальные нормативные акты по безопасности часто пишутся не для того, чтобы человек понял, что делать. А чтобы компания могла сказать: мы предупреждали. Если сотрудник скачает вирус, откроет фишинговое письмо или сольёт базу клиентов, есть пункт 8.4.3, который запрещал так делать.
Такие документы перестали быть инструкциями. Они стали амулетами. Их печатают, подписывают, хранят в красных папках не для применения, а для защиты. От аудиторов, регуляторов, случайных проверок.
Формулировка "запрещается использование незащищённых каналов передачи данных при работе с конфиденциальной информацией" юридически корректна. Но что такое "незащищённый канал" для бухгалтера? Telegram? Gmail? Корпоративная почта через публичный Wi-Fi? Непонятно. Зато если что-то случится, виноват сотрудник. Ведь написано же.
Внутренние документы превращаются в инструмент перекладывания ответственности. Компания снимает с себя риски, перенося их на людей. Но если человек не понимает требование, он его не выполнит. И тогда весь смысл документа сводится к одному: зафиксировать вину после происшествия.
Защита не строится на том, чтобы потом кого-то обвинить. Она строится на том, чтобы предотвратить. Но предотвращать сложнее, чем зафиксировать требование и ждать.
Что проверяют аудиторы информационной безопасности
Когда проверяющий приходит с чек-листом, он смотрит не на то, работает ли система безопасности. Он смотрит, есть ли политика управления доступом. Есть ли регламент резервного копирования. Есть ли инструкция по реагированию на инциденты.
Если документ на двух страницах, возникают вопросы. Где детализация процессов? Где матрица ответственности? Где ссылки на нормативные акты? Если документ на 50 страниц, хорошо. Значит, подошли серьёзно.
Регуляторные требования построены на допущении: чем больше задокументировано, тем лучше контроль. Но контроль не в количестве страниц. Контроль в том, что люди знают, как действовать, и действуют правильно. Документ на 50 страниц, который никто не открывает, не создаёт контроль. Он создаёт иллюзию.
Проверяющий не будет спрашивать сотрудников, понимают ли они политику безопасности. Он проверит, утверждена ли она приказом, есть ли подписи, соответствует ли структура стандартам. Формальное соответствие закрывает вопрос. Реальное применение нет.
И компании подстраиваются. Пишут не для людей, а для галочки. Потому что галочка решает, пройдёт проверка или нет. А понятность документа на результат проверки не влияет.
Почему документы по информационной безопасности написаны сложным языком
Человек, который отвечает за информационную безопасность, говорит на языке стандартов, технологий, процедур. Ему понятно, что такое "средства криптографической защиты информации" и "контроль целостности при передаче данных". Он привык к этим терминам. И переносит их в документы.
Получатель документа (маркетолог, который должен понимать, можно ли отправлять таблицу с email-адресами клиентов через Яндекс.Диск) терминам не помогают. Ему нужен ответ: можно или нельзя. И если нельзя, как тогда.
Но вместо ответа он читает про "обеспечение защищённого обмена информацией с применением средств, сертифицированных в соответствии с требованиями законодательства". Что делать с этой фразой, непонятно.
Профессиональный жаргон полезен, когда общаются профессионалы. Но внутренние документы не пишутся для узкого круга. Они пишутся для всех сотрудников. И если половина терминов требует отдельного словаря, документ перестаёт быть инструкцией. Он становится экзаменом.
Ещё хуже, когда за терминами скрывается отсутствие конкретики. Легко написать "применять меры защиты в соответствии с классом информационной системы". Сложнее объяснить, какие именно меры и в какой ситуации. Термины заполняют пустоту там, где должно быть понимание процесса.
Как пишутся регламенты информационной безопасности в компании
Внутренние документы часто появляются не потому, что процесс отлажен и его нужно описать. А потому что процесса нет, но аудитор требует документ. Тогда пишут то, как должно быть. А как есть на самом деле, остаётся за кадром.
Политика резервного копирования описывает ежедневные автоматические бэкапы с хранением в двух географически распределённых точках. На практике бэкапы делаются вручную, когда системный администратор об этом вспоминает, и лежат на том же сервере, что и рабочие данные. Но документ есть. И формально всё правильно.
Регламент управления доступом прописывает, что права выдаются по заявке, согласованной с руководителем подразделения и службой безопасности. На практике права даются устно, по запросу в мессенджере, и никто не проверяет, нужен ли доступ. Но документ утверждён. И в нём всё логично.
Разрыв между написанным и реальностью создаёт фиктивную безопасность. Компания думает, что защищена, потому что есть документы. Но документы описывают идеальный мир, который не существует. И когда случается инцидент, выясняется, что ни один из прописанных процессов не работал.
Писать документы проще, чем выстраивать процессы. Поэтому сначала пишут. Потом забывают про реальность.
Зачем юристы усложняют политики безопасности
Каждая формулировка во внутренних документах проходит через юристов. И юристы делают свою работу: добавляют оговорки, уточнения, ссылки на законодательство. Чтобы не было двусмысленности. Чтобы не было риска неправильного толкования.
Фраза "не передавайте рабочие пароли третьим лицам" превращается в "запрещается передача аутентификационных данных лицам, не имеющим соответствующих полномочий в рамках исполнения служебных обязанностей, за исключением случаев, предусмотренных отдельными распорядительными документами".
Смысл тот же. Но теперь нужно три раза прочитать, чтобы понять. И речь только об одной фразе. Когда таких фраз 200, документ превращается в юридический текст. Читать его невозможно. Применять тем более.
Юридическая корректность защищает компанию от претензий. Но убивает применимость документа. Если выбор между "понятно" и "юридически безопасно", выбирают второе. Потому что непонятный документ не приведёт к иску. А упрощённый может, если кто-то истолкует неправильно.
Но если документ настолько перегружен оговорками, что его никто не читает, он не защищает. Он просто существует.
Почему все компании используют одинаковые шаблоны документов ИБ
Новый сотрудник отдела безопасности получает задачу: написать политику обработки персональных данных. Он открывает папку с прошлыми документами, берёт шаблон, меняет дату и название компании. Структура остаётся той же. Формулировки те же. Логика та же.
Никто не задаёт вопрос: а почему так? Так писали до него. Так будут писать после. Традиция закрепляется не потому, что она работает. А потому, что её не ставят под сомнение.
Откуда взялась эта система? Давно, когда в компаниях впервые начали думать о защите данных, документы были простыми. «Не открывай письма от незнакомых». «Пароль не менее восьми символов». Потом пришел первый аудит. И сказал: «Где риски? Где матрица ответственности? Где ссылки на закон?»
Специалисты открыли стандарты. ISO, COBIT, 152-ФЗ. Там было много слов. Они скопировали их. Аудитор оценил. В следующий раз они скопировали еще больше.
Шаблоны удобны. Они экономят время. Но они консервируют проблемы. Если изначальный шаблон был нечитаемым, все последующие документы будут такими же. Если в нём были избыточные требования, они перейдут во все версии. Если формулировки были оторваны от реальности, оторванность сохранится.
Год за годом слои текста оседали одни на других. Появились шаблоны. Сначала их делили внутри отрасли. Потом продавали. Теперь новичок получает не задачу «напиши политику», а задачу «возьми шаблон и адаптируй». Шаблон не старт. Он потолок. Он не дает думать. Он дает делать.
Шаблонный подход убивает адаптацию. Документ пишется не под задачу компании, а под стандартную структуру. Даже если у компании специфика, которая требует другого подхода, шаблон сильнее. Потому что так проще. И так безопаснее с точки зрения соответствия стандартам.
Почему короткие политики безопасности вызывают недоверие
Простой документ вызывает недоверие. Если политика безопасности умещается на пяти страницах и написана понятно, что-то не так. Где глубина проработки? Где детализация?
Документ на 60 страниц с разделами, подразделами, приложениями и ссылками на десяток других регламентов выглядит убедительно. Даже если половина текста вода. Объём создаёт впечатление тщательности.
Простой текст выглядит подозрительно. Как будто автор не потрудился. Как будто он не профессионал. Профессионал должен писать сложно. Потому что сложность маркер труда.
Руководство одобряет толстые документы. Аудитор принимает толстые документы. Специалисты по безопасности пишут толстые документы, потому что тонкие не воспринимают всерьёз.
Но толщина не показатель качества. Документ на 60 страниц, который никто не читает, хуже документа на пяти страницах, который все понимают и применяют. Но система оценивает наоборот.
Мы путаем сложность с качеством. Но сложность не качество. Иногда просто бесполезность, которую трудно распознать. Проще всего замаскировать отсутствие мысли под сложность формы.
Сложность становится самоцелью. Чем запутаннее структура, чем больше терминов, чем длиннее формулировки, тем "профессиональнее". Хотя профессионализм в умении объяснить сложное просто. А не в умении запутать простое.
Кому выгодны непонятные документы по информационной безопасности
Все участники процесса получают то, что им нужно, при текущем положении дел. Кому нужен этот бесполезный документ? Всем.
Аудитор ставит галочку за наличие документов. Ему не нужно проверять, работают ли они.
Специалист по безопасности выполняет требования регулятора. Ему не нужно доказывать, что сотрудники документы понимают.
Руководство видит, что формальные обязательства выполнены. Ему не нужно вникать, как обстоят дела на практике.
Юристы защищают компанию от юридических рисков через оговорки. Им не нужно думать об удобстве применения.
Он не должен работать. Он должен существовать. Его функция быть. Не действовать. Существование документа стало метрикой безопасности. И эта метрика удобна всем.
Все делают свою работу. И все заинтересованы в сохранении системы. Потому что менять её требует усилий. А текущая схема позволяет закрыть требования.
Если документ вдруг начнет работать, если сотрудники начнут его читать и спрашивать вопросы, появятся проблемы. Появятся исключения. Непонятные ситуации. Потребуется дорабатывать процессы. Сложно.
Поэтому все тихо согласны, что документ будет фикцией. Фикция удобна. Она не требует внимания. Она не создает работы. Она просто есть.
Но эта система держится до первого серьёзного инцидента. Когда данные утекают, систему взламывают или происходит сбой, выясняется, что документы были, а защиты не было. Потому что люди не понимали, что делать. И делали как привыкли. Или как проще.
Формальное соответствие не равно безопасности. Но пока проверки проходят, никто не задаёт вопрос.
Что происходит после инцидента информационной безопасности
Внутренние документы описывают идеальный процесс. Реальность работает иначе. Инцидент. Утечка данных. Вирус. Взлом. И тут все открывают политику. И видят: она не помогает. Она описывает мир, которого нет.
Политика запрещает использовать личные устройства для рабочих задач. Сотрудники читают рабочую почту с телефонов.
Регламент требует согласования доступа через заявку. Доступ дают по звонку.
Инструкция предписывает немедленно сообщать о подозрительных письмах в службу безопасности. Сотрудники просто удаляют и забывают.
Сотрудник говорит: «Я не знал, что нельзя». Ему показывают пункт 8.4.3. Он говорит: «Я не понял, что значит». Его винят. Но в чем вина? Что он не расшифровал шифр?
Разрыв возникает не потому, что люди игнорируют правила специально. А потому что правила написаны без учёта того, как люди работают. Идеальный процесс требует времени, усилий, дополнительных действий. Реальный процесс требует скорости и простоты.
После инцидента создают комиссию. Комиссия пишет отчет. Отчет рекомендует «усилить контроль применения политики». Никто не говорит: «Давайте напишем политику заново, чтобы она была понятна». Потому что звучит как признание ошибки. А ошибку признавать нельзя.
Поэтому добавляют еще один абзац. Еще одну оговорку. Еще одну страницу. Проблему закрывают объемом. И цикл повторяется.
Когда документ противоречит логике работы, побеждает логика работы. Документ остаётся в папке.
Как сделать документы по информационной безопасности понятными
Внутренние документы по информационной безопасности существуют параллельно безопасности. Их пишут не для того, чтобы защитить. А для того, чтобы соответствовать требованиям.
Система создания документов построена на формальности. Регулятор требует наличие, компания обеспечивает наличие. Аудитор проверяет структуру, компания создаёт структуру. Юристы требуют оговорки, компания добавляет оговорки.
Никто в этой цепочке не отвечает за то, чтобы сотрудник прочитал документ и понял, что делать. Потому что входит в критерии проверки.
Проблема не в том, что люди не хотят читать. Проблема в том, что документы написаны так, будто их читать и не должны. Их должны утвердить, подшить, показать аудитору. Остальное не важно.
Понимание, что документ ритуал, а не инструмент, освобождает. Если вы специалист по ИБ, вы можете перестать писать для галочки. Можете написать два документа. Один для аудитора, с терминами и объемом. Второй для людей, с понятными правилами. Двойная работа. Но единственный способ, когда оба документа работают.
Можно создать чат-бота, который отвечает на вопросы «можно ли?» вместо того, чтобы заставлять читать 40 страниц. Можно сделать видеоинструкцию на две минуты. Можно проводить пятиминутные тренинги у кофемашины. Главное перестать мерить работу количеством страниц.
Но система сопротивляется. Потому что двойная работа двойные ресурсы. А ритуальный документ один. Пока компании не начнут платить за реальную безопасность, а не за видимость, ничего не изменится.
И пока система оценивает формальное соответствие, а не реальную безопасность, ничего не изменится. Документы будут создаваться для галочки. Сотрудники будут их игнорировать. Инциденты будут происходить. И все будут удивляться почему.
Потому что безопасность не в документах. Она в том, что люди делают. А люди делают не то, что написано. Они делают то, что понимают. И если документ непонятен, делают как считают правильным. Или как проще.
Политика информационной безопасности [организации]
1. Общие положения
Раздел описывает назначение документа, область применения и нормативные ссылки. Здесь указывается, что политика распространяется на всех сотрудников, подрядчиков и партнеров, имеющих доступ к информационным ресурсам организации. Перечисляются законы и стандарты, на которые опирается документ (152-ФЗ, ГОСТ Р ИСО/МЭК 27001, отраслевые требования).
2. Термины и определения
Расшифровка основных понятий, используемых в документе. Информационная система, конфиденциальная информация, персональные данные, инцидент информационной безопасности, владелец информации, пользователь. Без этого раздела невозможно единообразное толкование требований.
3. Принципы обеспечения информационной безопасности
Базовые принципы, на которых строится защита информации в организации: конфиденциальность, целостность, доступность. Принцип разграничения доступа, минимизации привилегий, непрерывности защиты. Декларация подхода к управлению рисками.
4. Цели и задачи политики
Формулировка того, чего организация хочет достичь через внедрение политики. Защита информационных активов, обеспечение непрерывности бизнес-процессов, соблюдение законодательных требований, минимизация рисков утечки или повреждения данных.
5. Область применения
Уточнение, на какие информационные системы, процессы и подразделения распространяется политика. Исключения, если они есть. Границы ответственности.
6. Роли и ответственность
Описание ролей участников процесса обеспечения безопасности. Руководство организации, служба информационной безопасности, владельцы информационных систем, системные администраторы, пользователи. Распределение зон ответственности между ними.
7. Классификация информации
Категории информации по уровню конфиденциальности: открытая, для служебного пользования, конфиденциальная, персональные данные. Критерии отнесения к каждой категории. Требования к маркировке и обработке информации разных уровней.
8. Управление доступом
Правила предоставления, изменения и отзыва прав доступа к информационным ресурсам. Процедура согласования доступа, принцип минимальных привилегий, регулярный пересмотр прав. Требования к аутентификации и авторизации пользователей.
9. Защита от несанкционированного доступа
Технические и организационные меры по предотвращению НСД. Использование средств защиты информации, антивирусного ПО, межсетевых экранов, систем обнаружения вторжений. Требования к защите периметра сети, сегментации, мониторингу.
10. Криптографическая защита
Требования к использованию средств шифрования при передаче и хранении конфиденциальной информации. Применение сертифицированных средств криптографической защиты в соответствии с законодательством. Управление ключами шифрования.
11. Физическая безопасность
Меры по защите физической инфраструктуры: контроль доступа в помещения с серверным оборудованием, видеонаблюдение, системы охранной сигнализации. Требования к размещению и защите оборудования, уничтожению носителей информации.
12. Безопасность при работе с персональными данными
Специфические требования к обработке персональных данных в соответствии с 152-ФЗ. Согласие субъектов, цели обработки, сроки хранения, права субъектов, уведомление регулятора. Требования к защите ПДн на всех этапах жизненного цикла.
13. Резервное копирование и восстановление
Требования к организации резервного копирования информации. Периодичность создания резервных копий, места хранения, сроки хранения, процедуры восстановления. Регулярное тестирование процедур восстановления.
14. Управление инцидентами информационной безопасности
Процедуры выявления, регистрации, расследования и устранения инцидентов. Классификация инцидентов по степени критичности. Порядок оповещения, реагирования, документирования. Анализ причин и меры по предотвращению повторения.
15. Обеспечение непрерывности бизнеса
Требования к планированию непрерывности деятельности при сбоях в работе информационных систем. Планы аварийного восстановления, альтернативные площадки, резервирование критически важных систем.
16. Защита при работе в сети Интернет
Правила безопасного использования интернет-ресурсов. Контроль посещаемых сайтов, фильтрация веб-трафика, защита от фишинга и вредоносного ПО. Требования к использованию облачных сервисов и внешних ресурсов для рабочих целей.
17. Использование мобильных устройств и удаленный доступ
Политика BYOD (Bring Your Own Device) или запрет использования личных устройств. Требования к защите корпоративных мобильных устройств, шифрованию данных, удаленному управлению. Правила организации удаленного доступа через VPN, двухфакторная аутентификация.
18. Работа с электронной почтой
Правила использования корпоративной электронной почты. Запрет на передачу конфиденциальной информации через незащищенные каналы. Требования к защите от спама, фишинга, вредоносных вложений. Контроль использования личной почты в рабочих целях.
19. Использование съемных носителей
Политика применения USB-накопителей, внешних жестких дисков, оптических дисков. Регистрация разрешенных носителей, шифрование данных на съемных носителях. Запрет на использование личных устройств для переноса рабочей информации.
20. Разработка и сопровождение информационных систем
Требования безопасности на этапах разработки, внедрения и эксплуатации ИС. Безопасность кода, тестирование на уязвимости, управление изменениями. Контроль версий, документирование, передача систем в промышленную эксплуатацию.
21. Управление уязвимостями
Процедуры выявления и устранения уязвимостей в программном обеспечении и оборудовании. Регулярное сканирование, установка обновлений безопасности, приоритизация критичных уязвимостей. Взаимодействие с вендорами.
22. Обучение и повышение осведомленности сотрудников
Программа обучения персонала основам информационной безопасности. Регулярные тренинги, тестирование знаний, информирование об актуальных угрозах. Ознакомление новых сотрудников с политикой при приеме на работу.
23. Аудит и мониторинг
Требования к проведению внутренних и внешних аудитов системы информационной безопасности. Мониторинг событий безопасности, анализ логов, контроль соблюдения политики. Регулярность проверок, документирование результатов.
24. Взаимодействие с третьими сторонами
Требования безопасности при работе с подрядчиками, партнерами, облачными провайдерами. Соглашения о конфиденциальности, требования к уровню защиты у контрагентов. Аудит безопасности партнеров при обработке критичных данных.
25. Ответственность за нарушение политики
Виды нарушений требований политики и меры ответственности. Дисциплинарные взыскания, материальная ответственность, уголовная ответственность в случаях, предусмотренных законодательством. Порядок расследования нарушений.
26. Пересмотр и актуализация политики
Периодичность пересмотра документа (не реже одного раза в год или при значительных изменениях в законодательстве, структуре организации, появлении новых угроз). Процедура внесения изменений, согласования и утверждения новой версии.
27. Заключительные положения
Дата вступления политики в силу, порядок ознакомления сотрудников, хранение документа. Контактная информация службы информационной безопасности для консультаций и сообщений об инцидентах.
Приложения
- Приложение 1. Форма заявки на предоставление доступа к информационным ресурсам
- Приложение 2. Классификатор информации организации
- Приложение 3. Форма регистрации инцидентов информационной безопасности
- Приложение 4. Матрица ответственности за обеспечение информационной безопасности
- Приложение 5. Перечень нормативных документов
#информационнаябезопасность #кибербезопасность #киберзащита #безопасностьданных #защитаинформации #киберугрозы #инфобезопасность