среда, 16 марта 2016 г.

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

В связи с тем, что меры контроля / анализа защищённости персональных данных входят в базовые наборы мер защиты начиная с УЗ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 “Выявление известных уязвимостей”





3 комментария:

Александр Хонин комментирует...
Этот комментарий был удален администратором блога.
Сергей Борисов комментирует...

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

Andrey комментирует...

"большинство операторов персональных данных обзавелось сканерами защищенности" - да ну вы бросьте)