четверг, 19 марта 2015 г.

СОИБ. Анализ. ГосСОПКА

Вчера на сайте ФСБ была опубликована выписка из документа “Концепция государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации” утвержденного Президентом РФ 12.12.2014 № К 1274.

Давайте посмотрим, какая есть ещё публичная информация по ГосСОПКе и представим её общую картину:
·        Презентация выступления Юдина Сергея Николаевича из ФСБ на 7 уральском форуме IB-Bank от 17.02.2015 
·        Указ Президента Российской Федерации от 15 января 2013 г. N 31с г. Москва "О создании государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации"

На всякий случай взглянем на:
·        экспертное мнение Алексея Лукацкого по возможному составу федеральной системе обнаружения атак

·        замороженный проект ФЗ РФ “о безопасности критической информационной инфраструктуры Российской Федерации” в котором упоминается ГосСОПКА

В соответствии с указом №31с область защиты:
“информационные ресурсы Российской Федерации - информационные системы и информационно-телекоммуникационные сети, находящиеся на территории Российской Федерации и в дипломатических представительствах и консульских учреждениях Российской Федерации за рубежом”

В соответствии с концепцией территориальная структура ГосСОПКА имеет вид:


Область ответственности центров ГосСОПКА отображена на следующей схеме:


Сертифицированные последнее время в ФСБ средства обнаружения компьютерных атак должны иметь возможность интеграции с ГосСОПКА. В требованиях по созданию ГИС в последнее время также указывается необходимость применения СОВ с возможностью интеграции с ГосСОПКА.

Таким образом, можно предположить что в качестве так называемых “технические средства, предназначенные для поиска признаков компьютерных атак в сообщениях электросвязи” будет выступать любое сертифицированное в ФСБ  IPS, которое будет оправлять информацию об атаках и инцидентах по syslog в специальном формате, а ГосСОПКА представляет из себя в таком случае большой распределенный SOC.
С учетом этого, а так-же функций приведенных в Концепции, получается следующая схема взаимодействия ГосСОПКА




Если верить Концепции, должны быть разработаны ещё следующие нормативно-правовые акты:
·        порядок фиксации и обмена информацией между субъектами Системы о компьютерных атаках на информационные ресурсы РФ и вызванных ими компьютерных инцидентах;
·        порядок осуществления деятельности субъектов Системы в области обнаружения, предупреждения и ликвидации последствий компьютерных атак;
·        порядок и периодичность проведения мероприятий по оценке степени защищенности критической информационной инфраструктуры РФ от компьютерных атак;
·        порядок обмена информацией между органами государственной власти и международными организациями о компьютерных инцидентах.  


понедельник, 16 марта 2015 г.

СЗПДн. Анализ. Вопросы применения СКЗИ для защиты ПДн

В конце прошлого года у меня подобралось несколько вопросов в рамках защиты ПДн, по которым не было однозначного ответа. При этом ряд знакомых экспертов (Артем Агеев, Николай Домуховский и д.р.) советовали не заниматься публичными рассуждениями, а писать письма регуляторам.

Письма были написаны, давайте посмотрим что получилось с вопросами к ФСБ России:

Вопрос 1. На основании чего (какого мероприятия, документа) Оператор персональных данных должен определять необходимость использования СКЗИ или отсутствие необходимости использования СКЗИ для защиты ПДн?
(примечание автора – данный вопрос возник с связи с наличием различных трактовок ПП 1119 и приказа №378 ФСБ в части необходимости применения СКЗИ для защиты ИСПДн. Одно из мнений экспертов - необходимость применения СКЗИ остается на усмотрение Оператора который указывает, актуальная или нет угроза нарушения конфиденциальности. Другое мнение – если ПДн передаются по неконтролируемым каналам связи нужно применять СКЗИ в любом случае)
Ответ 1 Регулятора.


Вопрос 2. Если оператор определил отсутствие необходимости использования СКЗИ для защиты ПДн, должен ли он выполнять меры приведенные в приказе №378, например часть 8 пенкт а) и б)
(примечание автора – опять  имеют место разные трактовки. Одно из мнений экспертов – требования приказа №378 необходимо выполнять, даже если вы не применяете СКЗИ. Другое мнение – учитываем требования приказа №378 только если применяем СКЗИ для защиты ПДн)

Ответ 2 Регулятора.


Вопрос 3. Потенциал нарушителя и класс СКЗИ должен определяться для всей ИСПДн в целом или для каждой отдельной атаки/угрозы?
a)        Соответственно, можно ли использовать СКЗИ разных классов в рамках защиты одной ИСПДн?
(примечание автора – после выхода приказа №378 я написал в блоге небольшую заметку про возможность определения класса СКЗИ для отдельных угроз, в комментариях к которой отметились сомневающиеся специалисты)
Ответ 3 Регулятора.


Вопрос 4. Какие меры должен принять оператор персональных данных, который определил необходимость использования СКЗИ для защиты ПДн, но на рынке отсутствуют СКЗИ подходящего класса или СКЗИ подходящие для среды Заказчика, например, VPN клиенты класса КВ1, мобильные VPN клиенты класса КС2?
a)        Может ли оператор персональных данных начинать обработку ПДн, если необходимые СКЗИ находятся в процессе сертификации?
(примечание автора – сталкивался с мнением, что если сертифицированные ФСБ решения отсутствуют для какой-то технологии, то можно спокойно обрабатывать и ждать пока появятся или пока закончится сертификация)
Ответ 4 Регулятора.




четверг, 5 марта 2015 г.

СОИБ. Внедрение. Настройка WAF, часть 2

Продолжаем предыдущую статью и настраиваем некий обобщенный WAF:
·        настраиваем политики безопасности:
o   для определенных ранее объектов защиты назначаем политику сетевой безопасности (открыты порты только связанные с web приложением, из подсети управления разрешен так-же трафик для сервисов управления)
o   для каждого web сервиса настраиваем политики защиты web сервиса (могут быть разрешены нестандартные HTTP запросы, такие как HEAD,  могут быть разрешены SQL команды и т.п.), включаем группы сигнатур и  выбираем реакцию на основные типы обнаруженных атак

o   для каждого web приложения настраиваем политики связанные с web приложением (разрешенные коды ошибок, возможность обращения к файловой системе, возможность передачи команд ОС для административных панелей и т.п.)
o   настраиваем политики агрегации обнаруженных нарушений, связанных с одним источником или одним типом нарушения
o   настраиваем политики корреляции обнаруженных нарушений на различных уровнях (например, по сигнатуре атаки определяется как shellshock + данные в переменной не соответствуют профилю web приложения)

·        для каждого параметра каждой страницы (которые мы определили ранее) желательно так-же определить разрешенные значения и возможность пользователем изменять эти данные. Например, для переменной Login нам нужно будет ограничить значения как: латинские буквы, _, цифры, длиной до 15 символов; а в пароле нам нужно будет разрешить ещё русские символы и некоторые спецсимволы


·        если предыдущий пункт в ручную выполнить будет трудоемко, то пригодятся возможности автоматического определения и обучения WAF, но и в таком случае нужно будет регулярно (раз в 2 недели) просматривать профиль и принимать найденные изменения

·        возможно наш сайт будет содержать ценные данные и нам нужно настроить дополнительные политики, контролирующие вывод информации
o   определить шаблоны для ценных данных, которые могут содержаться в приложении или в БД; как правило придется применять регэкспы типа:
rgxp="([^\d])(340\d)([-\.\s\\\/=]?)(\d{4})([-\.\s\\\/=]?)(\d{3})(\d)([-\.\s\\\/=]?)(\d{3}[^\d]{1})"
o   определить типы данных (например, номера банковских карт), которые не должны выводится никогда и ни при каких условиях
o   другие типы данных (например ПДн, такие как номер телефона или паспорта) разрешено выводить  только в определенных разделах сайта
o   так-же ценные данные не должны выводится (в место этого заменятся на *) в журналы регистрации WAF

·        создаем дополнительные реакции, кроме блокирования сессии и долгосрочного блокирования ip-адреса источника, можно определить отправку email на определенные адреса:
o   информацию по критическим нарушениям и заблокированным угрозам – на адрес группы оперативного реагирования на инциденты, владельцам web приложения
o   информацию по остальным нарушениям – на адрес администратора WAF
o   если имеется внешняя система сбора логов или управления событиями ИБ, определим информация по каким нарушениям будет передаваться по SNMP trap / syslog / другому способу интеграции с внешней SIEM

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

·        создаем дополнительные роли и пользователей:
o   операторов для мониторинга окна реагирования
o   разработчиков и владельцев web приложений для просмотра профиля web приложения и отчетов
o   администратров waf и т.п.

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


понедельник, 2 марта 2015 г.

СОИБ. Анализ. Замещение ИБ

Что делать, если для реализации меры Nx в компании хочется внедрить/купить/продать техническое решение NG, но вот незадача - в прошлом году было приобретено/продано некое техническое решение G...
Будем замещать старое G на новое и более эффективное решение NG путем демонстрации / пилота.

Программа замещения ИБ:
·        правильное подключение
·        правильный тест
·        правильные критерия сравнения

Если мы знаем, что решение G пропускает хотя бы один пакет или сообщение, которое обнаруживает NG, то подключать NG конечно же надо после G, чтобы руководству продемонстрировать – “вот она, пропущена реальная атака, которая могла бы разрушить ваш бизнес”
Схема замещения ИБ 1 (защита от внешних угроз)


Если вы не знаете каких-либо атак/угроз, которые пропускает решение G но обнаруживает NG (а это обычная ситуация при импортозамещении), смело подключайте решение NG до G. Вы легко сможете провести тест который будет обнаруживаться решением NG не хуже чем G,  а аргументировать замещение ИБ всегда можно лучшей эффективностью: “делает всё то же самое, но ещё и лампочками мигает”, “обеспечивает многопоточное пропускание того же трафика за меньшую стоимость”, “дешевле OPEX”, “сертификат на более высокие классы” и т.п.


Схема замещения ИБ 2 (защита от внутренних угроз)