СЗПДн. Анализ защищенности

В связи с тем, что меры контроля / анализа защищённости персональных данных входят в базовые наборы мер защиты начиная с УЗ4 – УЗ3, большинство операторов персональных данных обзавелось сканерами защищенности. Иногда сталкиваюсь со следующими вопросом: а нужно ли вообще запускать этот сканер, и если да, то с какой периодичностью и что именно проверять.

Давайте попробуем разобраться:

·         сканеры используется для реализации группы мер по контролю (анализу) защищенности персональных данных (АНЗ) обязательных в соответствии с приказом ФСТЭК России №21 от 18 февраля 2013 г.

·         посмотрим, имеется ли в нормативно-правовых актах РФ какие-то обязательные требования к порядку или периодичности проведения сканирования защищенности:

Приказ ФСТЭК России №21

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

АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей

АНЗ.2 Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации

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

АНЗ.4 Контроль состава технических средств, программного обеспечения и средств защиты информации”

ГОСТ Р 51583-2014 порядок создания АС в защищенном исполнении

 Больше НПА, содержащих требования к анализу защищенности найти не удалось

Значит в нормативно-правовых актах РФ не содержится требований к порядку и периодичности проведения сканирований защищенности, соответственно параметры настройки профилей сканирования, периодичности анализа уязвимостей определяется оператором самостоятельно

·         как же ему определить этот порядок и периодичность?

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

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

·         при определении порядка и периодичности сканирования оператор информационной системы может руководствоваться собственной экспертизой в области информационной безопасности, опытом проведения мероприятий по анализу защищенности, рекомендациями внешних экспертов и лицензиатов ФСТЭК, а также документами, носящими статус “рекомендованных” или “лучших практик”

·         при этом необходимо учитывать, что меры по анализу защищенности должен быть систематическими (пункт 8.8 приказ ФСТЭК №21) и должны быть достаточными для нейтрализации актуальных угроз (пункт 2 Постановление правительства №1119)

·         посмотрим, что есть в лучших методических документах и лучших практиках:

Цитаты из ГОСТ Р ИСО/МЭК 27002-2012:

“12.6 Менеджмент технических уязвимостей
Цель: Снизить риски, являющиеся результатом использования опубликованных технических уязвимостей.

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

Мера и средство контроля и управления

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

Рекомендация по реализации

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

Аналогично, своевременное действие должно предприниматься в ответ на выявление потенциальных технических уязвимостей. Для создания эффективного процесса менеджмента в отношении технических уязвимостей необходимо выполнять следующие рекомендации:
a) в организации необходимо определять и устанавливать роли и обязанности, связанные с менеджментом технических уязвимостей, включая мониторинг уязвимостей, оценку риска проявления уязвимостей, исправление программ (патчинг), слежение за активами и любые другие координирующие функции;
b) информационные ресурсы, которые будут использоваться для выявления значимых технических уязвимостей и обеспечения осведомленности о них, следует определять для программного обеспечения и другой технологии на основе списка инвентаризации активов (см. 7.1.1); эти информационные ресурсы должны обновляться вслед за изменениями, вносимыми в опись, или когда найдены другие новые или полезные ресурсы;
c) необходимо определить временные параметры реагирования на уведомления о потенциально значимых технических уязвимостях;
d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать внесение исправлений в уязвимые системы и (или) применение других мер и средств контроля и управления;
e) в зависимости от того, насколько срочно необходимо рассмотреть техническую уязвимость, предпринимаемое действие следует осуществлять в соответствии с мерами и средствами контроля и управления, связанными с менеджментом изменений (см. 12.5.1), или следуя процедурам реагирования на инциденты информационной безопасности (см. 13.2);
f) если имеется возможность установки патча, следует оценить риски, связанные с его установкой (риски, создаваемые уязвимостью, необходимо сравнить с риском установки патча);
g) перед установкой патчи следует тестировать и оценивать для обеспечения уверенности в том, что они являются эффективными и не приводят к побочным эффектам, которые нельзя допускать; если нет возможности установить патч, следует рассмотреть другие меры и средства контроля и управления, например:
1) отключение сервисов, связанных с уязвимостью;
2) адаптацию или добавление средств управления доступом, например, межсетевых экранов на сетевых границах (см. 11.4.5);
3) усиленный мониторинг для обнаружения или предотвращения реальных атак;
4) повышение осведомленности об уязвимостях;
h) в контрольный журнал следует вносить информацию о всех предпринятых процедурах;
i) следует регулярно проводить мониторинг и оценку процесса менеджмента технических уязвимостей в целях обеспечения уверенности в его эффективности и действенности;
j) в первую очередь следует обращать внимание на системы с высоким уровнем риска.

Дополнительная информация

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

Менеджмент технических уязвимостей может рассматриваться как подфункция менеджмента изменений и в качестве таковой может воспользоваться процессами и процедурами менеджмента изменений (см. 10.1.2 и 12.5.1).

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

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

Цитаты из РС БР ИББС-2.6-2014:

“10. Стадия эксплуатации
10.1. Основными задачами на стадии эксплуатации в части обеспечения ИБ являются:
— периодическая оценка защищенности АБС (проведение мероприятий по выявлению типичных уязвимостей программных компонентов АБС, тестирование на проникновение);
10.2. Периодичность проведения работ по оценке защищенности определяется решении
ем организации БС РФ. Для АБС, используемых для реализации банковского платежного технологического процесса, рекомендуется проведение комплексной оценки защищенности не реже одного раза в год”

Цитаты из методического документа ФСТЭК России “Меры защиты информации в государственных информационных системах”, который может применяться и для обеспечения безопасности персональных данных по решению оператора:

“АНЗ.1 ВЫЯВЛЕНИЕ, АНАЛИЗ И УСТРАНЕНИЕ УЯЗВИМОСТЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Выявление (поиск), анализ и устранение уязвимостей должны проводиться на этапах создания и эксплуатации информационной системы. На этапе эксплуатации поиск и анализ уязвимостей проводится с периодичностью, установленной оператором. При этом в обязательном порядке для критических уязвимостей проводится поиск и анализ уязвимостей в случае опубликования в общедоступных источниках информации о новых уязвимостях в средствах защиты информации, технических средствах и программном обеспечении, применяемом в информационной системе.
Требования к усилению АНЗ.1:
2) оператор должен уточнять перечень сканируемых в информационной системе уязвимостей с установленной им периодичностью, а также после появления информации о новых уязвимостях;”

·         руководствуясь методическим документом ФСТЭК - анализ защищенности необходимо проводить в обязательном порядке после опубликования информации о критической уязвимости или обновлении;

·         для ОС Windows такие уязвимости появляются в среднем ежемесячно;

·         по моему мнению для обеспечения нейтрализации актуальных угроз анализ защищенности с использованием сканеров необходимо проводить не реже чем ежеквартально

·         рекомендую начинать с этой периодичности, далее смотреть по времени отработки отчетов, устранения уязвимостей, установки обновлений – увеличивать или уменьшать частоту анализа

·         в качестве старта при определении что и как проверять, можно использовать приложение 3 Рекомендации к проведению оценки защищенности к РС БР ИББС-2.6-2014 – раздел 2 “Выявление известных уязвимостей”