Инструкция по контролю (анализу) защищённости персональных данных
Документ о проверке самой системы защиты: работают ли средства, которые уже куплены и установлены, устранены ли известные уязвимости, не разошлись ли настройки с тем, что было при внедрении.
Зачем нужен документ
Система защиты персональных данных строится один раз: определяется уровень защищённости, выбирается набор мер, закупаются и настраиваются средства, подписывается приказ о вводе в эксплуатацию. После этого она считается работающей — и дальше живёт своей жизнью, о которой никто специально не спрашивает.
А жизнь эта состоит из мелких изменений. Вышло обновление, закрывающее уязвимость, но его не поставили. Средство защиты перевели в режим наблюдения на время миграции и не вернули обратно. Появились новые учётные записи, часть из них — с лишними правами. Кто-то отключил одну из проверок, чтобы ускорить работу системы. Каждое изменение по отдельности выглядит невинно, а вместе они означают, что фактическая защищённость больше не равна той, которая была при внедрении.
Инструкция по контролю защищённости описывает, как эту разницу находить: какие проверки проводятся, с какой периодичностью, кем и что делается с результатами. Приказ ФСТЭК формулирует смысл группы мер прямо — систематические мероприятия по анализу защищённости системы и тестированию работоспособности системы защиты. Ключевое слово «систематические»: разовая проверка при внедрении требование не закрывает.
Чем грозит отсутствие
Своего состава у этой инструкции нет. Но именно у неё особая связь с самым тяжёлым наказанием во всей статье — оборотным штрафом, потому что он назначается не за утечку, а за повторную утечку. То есть за то, что причину первой так и не нашли.
Как ещё называют этот документ
Что должно быть в документе
Инструкция удобно строится по пяти мерам группы, которые задаёт приказ, — тогда видно, что ни одно направление проверки не выпало.
Требования законодательства
Как связан с другими документами
Этот документ проверяет то, что построено другими документами комплекта, и возвращает им обратную связь.
Когда обновлять документ
Сама инструкция меняется редко, а вот проверки по ней должны запускаться не только по календарю, но и по событиям — иначе система успевает измениться между двумя плановыми проверками.
Что спросит проверяющий
Разговор по этой теме быстро уходит от документа к системе. Инструкцию читают, чтобы узнать, что организация обещала делать, а дальше сверяют с фактом.
Разбор эксперта
Самое живучее заблуждение в этой теме звучит так: сертифицированное средство защиты нельзя обновлять, иначе слетит сертификат. Логика кажется убедительной, поэтому средство годами остаётся на той версии, под которую выдан документ, и спокойно накапливает публично известные уязвимости. Получается парадокс: организация бережёт бумагу о защищённости ценой самой защищённости. На деле производители выпускают обновления в рамках поддержки сертифицированных версий, статус проверяется по реестру ФСТЭК, и правильный ответ — обновляться по линии производителя и фиксировать это, а не отказываться от обновлений вовсе.
Второе, что я вижу постоянно, — средство защиты в режиме наблюдения. Его перевели туда при внедрении, чтобы не мешало, или во время миграции, чтобы не ломало процессы, и не вернули обратно. Формально мера реализована: средство закуплено, установлено, числится в системе защиты. Фактически оно ведёт летопись событий и не препятствует ни одному из них. Проверка занимает две минуты в консоли, а обнаруживается такая ситуация обычно уже при разборе инцидента, когда выясняется, что защита всё видела и ничего не остановила.
И третье — про периодичность. Три года из приказа ФСТЭК читают как рекомендацию, а это верхняя граница. За три года меняется всё: состав систем, персонал, версии программ, набор актуальных угроз. Я советую разделить проверки по частоте: контроль учётных записей и обновлений — ежемесячно, потому что это дёшево и приносит находки каждый раз; настройки средств защиты — ежеквартально; полную оценку эффективности — раз в год, а не раз в три года. Разница в трудозатратах невелика, разница в результате принципиальная, и именно она отделяет первую утечку от второй.
Разнесите проверки по частоте, а не сваливайте всё в одну трёхлетнюю процедуру. Заведите правило: у каждой найденной уязвимости есть срок устранения, зависящий от опасности, и ответственный. Отдельно опишите порядок для того, что устранить нельзя, — с компенсирующей мерой и обоснованием, как того требует приказ. Проверьте прямо сейчас две вещи, они дают результат почти всегда: дату последнего обновления средств защиты и список активных учётных записей на предмет уволившихся. И не поручайте проверку тому же человеку, который систему защиты настраивал.
Александр КеллерманнГенеральный директор, ведущий аудитор ISO/IEC 27001, Комитет по информационной и правовой безопасностиПодробнее об экспертеЧастые вопросы
Приказ ФСТЭК задаёт только нижнюю планку: оценка эффективности принятых мер — не реже одного раза в три года. Периодичность отдельных проверок оператор устанавливает сам. Рабочая схема: учётные записи и обновления — ежемесячно, настройки средств защиты — ежеквартально, полная оценка — ежегодно.
Нет. Приказ разрешает проводить оценку эффективности как самостоятельно, так и с привлечением на договорной основе организации или предпринимателя с лицензией на техническую защиту конфиденциальной информации. Выбор за оператором.
Оно требуется дополнительно, если в модели угроз к актуальным отнесены угрозы первого или второго типа — связанные с недекларированными возможностями в программном обеспечении. Ответ выводится из модели угроз конкретной организации, а не из общего правила.
Да, в порядке, предусмотренном производителем для сертифицированной версии. Отказ от обновлений ради сохранения сертификата — распространённая ошибка: средство остаётся формально соответствующим и фактически уязвимым, а мера АНЗ.2 прямо требует контроля установки обновлений, включая обновления самих средств защиты.
Предметом. Внутренний контроль проверяет, соблюдаются ли требования людьми и документами. Контроль защищённости проверяет технику: уязвимости, обновления, настройки, учётные записи. Это разные процедуры с разными исполнителями, и одна не заменяет другую.
Применить компенсирующую меру и обосновать её достаточность — такой порядок прямо предусмотрен приказом. Обоснование оформляется письменно и хранится вместе с документами системы защиты: при проверке спросят не только что сделано взамен, но и почему этого достаточно.
Технически можно объединить, но исполнители у этих проверок разные: одну ведёт юридическая или кадровая служба, другую — техническая. Разделение обычно оказывается практичнее, потому что каждый документ читает тот, кто по нему работает.