вторник, 29 марта 2016 г.

Общее. Конференция Код ИБ в Краснодаре 31 марта

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

Если у вас есть животрепещущие вопросы и желание получить на них ответ – то отличная возможность представляется 31 марта в Краснодаре на конференции Код ИБ. Постараюсь ответить на них на вводной экспертной дискуссии, в секции по безопасным ИТ-инфраструктурам, а также в перерывах и после сессий.

Кроме меня будет отличная возможность поймать Андрея Прозорова, популярного блогера и признанного спеца по различным международным стандартам Cobit, 2700x, эффективному развитию и последнее время по российскому ПО. Илью Шабанова, одного из учредителей anti-malware, известного web ресурса по ИБ, также будет интересно послушать. Он выступает не так часто и в гостях на краснодарских мероприятиях я его еще не встречал.  

Возможно вы были на прошлом Коде ИБ или видели отзывы с предыдущих мероприятий о том, что на данной конференции много вендорских выступлений, много рекламы и т.п. Да, такой аспект у мероприятия присутствует. Но отдадим должно вендорам, в основном они рассказывают о новых возможностях своих продуктов.  И как правило за год накапливается много новой информации. Так что если вы не посещаете московских мультивендрных мероприятий по ИБ, то один раз послушать в Краснодаре о новинках СЗИ.

Возможно руководство вашей компании не выделяет достаточно средств даже на базовые подсистемы ИБ, и вам представляется, что информация о новинках типа NGFW, NGDLP, AntiAPT, PUM не пригодится вам в ближайшие 5 лет.  Не совсем так – изучайте новые технологии, формируйте свой собственный каталог решений по ИБ, все это будет повышать вашу квалификацию – прокачаете общение с руководством и решения пройдут в вашей компании или будет полезно в следующей. А может быть вы даже решите отказаться от классических подсистем (FW, IPS, VPN, AV, НСД, VA) в пользу какого-то next generation решения и выиграете на этом.

Помимо всего прочего, Код ИБ отличная возможность пообщаться с коллегами по ИБ в Краснодаре. Фактически это единственное не моновендорное мероприятие у нас.  Приходите.  


среда, 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 “Выявление известных уязвимостей”





пятница, 4 марта 2016 г.

Общее. Не все поглощения полезны или инфо с вебинара по Secret Net Studio

Не так давно, а именно в конце ноября 2015г. я писал об информации с пресс-релиза Кода Безопасности, на которой был представлено в том числе решение Secret Net Studio.

В декабре 2015 вышла новость о том, что Яндекс приобретает компанию Agnitum. А в середине января 2016 Agnitum вывесил на официальном сайте информацию о том, что прекращает поставку решений своим заказчикам и партнерам.

А ведь продукт Аgnitum составлял ядро Security Studio Endpoint Protection (модули антивирусной защиты, обнаружения вторжений и межсетевого экранирования) и занимал значимое место в Secret Net Studio (один из двух модулей антивирусной защиты и модуль обнаружения вторжений).
Несколько дней назад состоялся вебинар КБ по Secret Net Studio (SNS), на котором в том числе упоминалась озвученная проблема.

Из двух модулей антивирусной защиты остался один вариант - ядро Nod32 от ESET. Причем модуль антивирусной защиты с Nod32 не планируется сертифицировать в ФСБ, а также по высоким классам ФСТЭК. Соответственно с этим модулем не удастся заходить в защиту Гостайны, а также использовать SNS на узлах, в которых применяется криптография (я уже неоднократно писал об этом, см. документацию на криптопро)

HIPS был полностью потерян – сейчас реализуют своими силами, планируется включить в следующей версии SNS в начале зимы.

Пока не ясно, принесет ли какую-то пользу Яндексу поглощение Agnitum, но это уже явно принесло определенный вред пользователями сертифицированных СЗИ.


Ещё интересная информация с вебинара:
·         Через 2-3 недели – начинают отгрузку для продажи Secret Net Studio (несертифицированную версию)

·         Ориентировочный срок получения сертификатов (модуля защиты от НСД) ФСТЭК – сентябрь 2016 года (сертификат на антивирус и СОВ позже). Напомню, что ранее озвучивалась дата – начало 2016 г., но видимо сдвинулось из-за истории с Agnitum


·         Понравилась официальная информация о замедлении быстродействия. Многие другие производители СЗИ не занимаются такими расчетами либо не публикуют. Кстати в части работы антивирусного ядра обещают замедление меньше чем у самого антивируса Nod32


·         Опять отмечаю, что не поддерживается ОС Windows XP и 2003. А между тем некоторые наши вендоры всё ещё не поддерживают Windows 8.  Пользователи меж двух огней.

·         Интересное по лицензированию: бесплатный переход с других продуктов КБ на соответствующие модули SNS при действующей тех. поддержке. У многих других российских вендоров за такой переход приходится дополнительно доплачивать, либо покупать расширенную тех. поддержку, которая в разы дороже.


·         Интересное по лицензированию: SNS – это, наверное, первый случай, когда сертифицированное СЗИ от НСД будет возможно приобрести не только бессрочно, но и на год. Это, наверное, будет самый дешевый вариант, если вам необходимо сертифицированное СЗИ от НСД прямо здесь и сейчас.    



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

СЗПДн. Анализ. Защита публичных информационных систем

Сегодня хотелось бы поговорить о защите публичных информационных систем.

Есть большая проблема в том, что органы государственной власти, уполномоченные в области защиты информации, персональных данных, прав субъектов (ФСТЭК России, ФСБ России, Роскомнадзор) сами не выполняют те требования, которые заставляют выполнять обычные организации. А также попустительствуют нарушениям крупных корпораций.
Давайте зайдем на сайт Минкомсвязи, ФСТЭК России, ФСБ России, ФНС России, РЖД, Госуслуги – на всех собираются и передаются персональные данные, при этом нет никакой информации о применяемых сертифицированных средствах защиты информации, данные передаются без какой-либо защиты.
Получается, что там, где обычные организации тратят огромное количество средств и ресурсов –разрабатываю и внедряют документы, покупают сертифицированные СЗИ, избранные органы и корпорации могут ничего не делать?  Так давайте мы все не будем выполнять эти требования …



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

В соответствии со статьей 19 152-ФЗ
“1. Оператор при обработке персональных данных обязан принимать необходимые правовые, организационные и технические меры или обеспечивать их принятие для защиты персональных данных от неправомерного или случайного доступа к ним, уничтожения, изменения, блокирования, копирования, предоставления, распространения персональных данных, а также от иных неправомерных действий в отношении персональных данных.
2. Обеспечение безопасности персональных данных достигается, в частности:
1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных;
2) применением организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных, необходимых для выполнения требований к защите персональных данных, исполнение которых обеспечивает установленные Правительством Российской Федерации уровни защищенности персональных данных; …”

Статья 3 “10) информационная система персональных данных - совокупность содержащихся в базах данных персональных данных и обеспечивающих их обработку информационных технологий и технических средств”

1. Давайте подумаем, а что будет входить в нашу публичную информационную систему?  Будет ли входить в нашу информационную систему техническое средство, за которым работает пользователь – физическое лицо? Будет ли входить в нашу ИС – операционная система и браузер, установленные на техническом средстве пользователя? Нет, нет и нет. Это устройство, ОС и ПО, владельцем которого является стороннее физическое лицо.  Мы не имеем права включать эти компоненты в ИС оператора.

2. Давайте подумаем, попадает ли под обязательные требования ввод/просмотр своих персональных данных пользователем в своем браузере? Нет
В соответствии со статьей 2 152-ФЗ
“2. Действие настоящего Федерального закона не распространяется на отношения, возникающие при:
1) обработке персональных данных физическими лицами исключительно для личных … нужд…”
Соответственно вся обработка ПДн пользователем (когда действия – ввод, передачу, корректировка, просмотр выполняет физ. лицо) полностью выпадает из-под требований 152-ФЗ и подзаконных актов.

3. Давайте подумаем, что должен делать оператор ПДн при взаимодействии (передаче ПДн) с третьими лицами?
В соответствии со статьей 6 152-ФЗ
“3. Оператор вправе поручить обработку персональных данных другому лицу … на основании заключаемого с этим лицом договора. … В поручении оператора …должна быть установлена обязанность такого лица … обеспечивать безопасность персональных данных при их обработке, а также должны быть указаны требования к защите обрабатываемых персональных данных в соответствии со статьей 19 настоящего Федерального закона.”
То есть в договоре с пользователем мы могли бы установить требования к защите передаваемых данных, но опять же, в соответствии с предыдущим пунктом - обработка данных физическим лицом исключена из сферы 152-ФЗ, то и обязательные требования к нему предъявляться не могут.

4. Приведенный выше анализ не исключает обязанностей оператора обеспечивать безопасность персональных данных в ИС. Для всех процессов обработки ПДн выполняемых именно оператором должны приниматься необходимые меры защиты. Для всех компонентов публичных ИС – серверов, web-сервисов, web-приложений, БД, рабочих мест операторов, находящихся во владении оператора ПДн должны приниматься меры защиты, в том числе использоваться сертифицированные средства, в том числе использоваться СКЗИ при передаче информации за границами КЗ, проводится аттестация и т.п.

5. Что делать, если система имеет единый интерфейс как для подключения пользователей – физических лиц, так и для подключения сотрудников оператора. Можно ли на основе пунктов 1-3 сделать вывод о том, что на ТС сотрудников не будут распространяться обязательные требования? Нет. В данному случае обработка ПДн будет являться обработкой ПДн оператором ПДн, не попадающей под исключения 152-ФЗ, поэтому должны применяться все требуемые меры. Скорее всего интерфейсы системы придется разделять, так как при доступе к интерфейсам сотрудников оператора скорее всего будут применяться более жесткие ограничения.   


6. Хорошо, мы разобрались с обязанностями оператора, но неужели совсем не нужно думать о защите информации на стороне пользователей?  Нужно.  Пусть такая защита выпадает из обязательных требований. Но хороший оператор по собственной инициативе думает о защите пользователей. С моей точки зрения, хорошей практикой будет подготовка рекомендаций для пользователей, содержащих типовой перечень СЗИ и орг. мер, необходимый для обеспечения безопасности при обработке данных физ. лицом.  Также необходимо предусмотреть возможность применения пользователем сертифицированных СКЗИ, подсказать где можно получить такие средства, добавить опцию в договор типа “я хочу чтобы обеспечивалась криптографическая защита взаимодействия моих технических средств, на которых установлены СКЗИ, с ИС оператора”. 

Выводы:
заявления ряда экспертов и блогеров о невыполнении рядом организаций требований по защите, на том основании что они их не видят - безосновательны и рассчитаны на неопытных читателей;
и хотя оператор ИС не может навязывать защиту на местах пользователей физ.лиц, на своей стороне он должен принимать все требуемые меры защиты.