четверг, 29 декабря 2016 г.

Общее. Стоит ли пускать обычных ИБшников на ZeroNights?

Наконец у меня нашлось время написать пару слов про ИБ конференцию ZeroNights, прошедшую 17-18 ноября 2016 г.  Несомненно, это было одно из лучших практических ИБ мероприятий РФ. Со стандартным отчетом я не успел (если не считать twitter), поэтому порекомендую вам ознакомится с отчетами коллег.


Я же хотел порассуждать на следующую тему: для специалистов занимающихся исследованием безопасности ПО и ТС, пенсетеров, охотников за уязвимостями, разработчиков СЗИ это мероприятие просто не имеет альтернатив и обязательно для посещения; а что на счет обычных специалистов по ИБ? Это те, которые занимаются управлением ИБ в организации, администрированием СЗИ,  комплаенсом, внутренним аудитом и т.п.? Таких ИБшников в сотни раз больше. Стоит ли их пускать им идти на ZeroNights?

Я в лице обычного ИБшника (с опытом консультации, комплаенса, проектирования) попытался найти ответ на самом мероприятии. На первый взгляд все выступления на мероприятии сводились примерно к следующему:
·         до меня никто толком не исследовал такую-то железку / ОС / ПО/ новые функции защиты / СЗИ
·         я решил это исследовать
·         нашел одну / пачку опасных уязвимостей
·         все это позволит получить доступ к вашей системе / данным / захватить мир
·         правда работает это не всегда, а при условиях X1+X2+..+Xn
·         рекомендации в результате исследования: вендорам - внимательнее делать такие-то проверки и реализовывать такие-то функции / пользователям – выбирать производителей, которые внимательно относятся к безопасности и не допускают уязвимостей.
Ни на одном из докладов нельзя было узнать следующей информации:
·         какое волшебное средство защиты поможет мне защитится от угроз ИБ
·         как мне выбрать волшебное средство защиты
·         как мне продать руководству это средство защиты
·         какая компания поможет мне защитится если я сам не справлюсь

Так что же было делать ИБшнику?
Во-первых, можно было узнать своего врага в лицо. Конечно не в прямом смысле. Подходите к этому как к моделированию нарушителя. Большинство докладчиков offensive докладов (их можно было обнаружить по черному цвету фона презентации) качественно смоделируют для вас нарушителя. Подробно опишут этапы того как готовилась и проводилась атака. Пару месяцев назад все говорили про Attack Kill Chain. На ZN вы узнаете более 20 возможных цепочек атак. Изучайте, планируйте как вы будете противостоять им на каждом этапе.
Во-вторых, вам помогут снять розовые очки. Вы на конкретных примерах поймете, что волшебного средства, защищающего от всех угроз, не существует. Что, через небольшое врем я после выхода новой функции защиты, придумывают способы его преодоления. Что, для каждого средства защиты есть не обнаруживаемый способ антиобнаружения атаки. Что, при достаточном времени исследователь может пробраться через любую защиту.
В-третьих, можно расширять ИБ кругозор.  Например, на Offensive вы можете:
·         узнать, что у всех компонентов ваших критических ИС есть физический уровень
·         компоненты ваших ИС на физическом уровне тоже могут иметь уязвимости
·         уязвимости на физическом уровне позволяют получить доступ на любом вышестоящем уровне, а значит ко всему
·         запланировать включение анализа компонентов на физическом уровне в область управления уязвимостями и обновлениями
·         вспомнить, что в компонентах ваших ИС тоже есть UEFI и BIOS
·         понять наконец почему в БДУ ФСТЭК так много угроз связано с UEFI и BIOS
·         вспомнить что прошивки и ОС на вашем сетевом оборудовании, принтерах, периферии и другом второстепенном оборудовании не обновлялись уже как десять лет (хотя ОС на АРМ вы обновляете каждую неделю)
·         запланировать включение анализ описанных выше компонентов в область управления уязвимостями, обновлениями и контроля целостности
·         узнаете, что происходит в тот момент, когда компьютер сам разблокируется, выполняет пару команд и снова блокируется
·         узнать, что бывает разная криптография, по-разному реализованная в разных устройствах и запланировать категорирование компонентов критических ИС по степени стойкости крипты в них
·         узнать, что вредоносы могут внедряться и в ваши эталонные дистрибутивы ПО и запланировать дополнительный контроль их целостности
Ну а секция Deffensive была специально и полностью предназначена для нас – обычных ИБшников. Только по сравнению с традиционными ИБ мероприятиями обладала рядом недостатков:
·         вместо того чтобы посоветовать готовое решения или поставщика услуг нам зачем-то рассказывали про опыт построения системы обнаружения целенаправленных атак, системы мониторинга почты и системы управления уязвимостями своими силами из опенсорсных кусочков
·         вместо того чтобы рассказывать про плюшки и бонусы, нам рассказывали про сложности и ограничения применения двухфакторной аутентификации в гетерогенной linux среде
·         вместо того чтобы рассказать, как выстроить в компании эффективные из зрелые ИБ процессы, нам рассказывали, как обеспечить безопасность в условия хаоса и вседозволенности сотрудников
·         лидеры ИТ отрасли вместо того чтобы хвастать успешными внедрениями современных ИБ решений, жаловались на отсутствие денег и необходимость писать себе СЗИ самостоятельно

Конечно же никакое хорошее обучение не обойдется без практики. В рамках двух task-based CTF (от QIWI и bi.zone) был подготовлен набор практических задачек, которые можно было решать на ZN, а потом померяться с коллегами. Немалая часть задачек была подходящей для обычных ИБшников: в категориях OSINT, Forensic, MISC  на 50, 100 и 300. Если хорошо поискать, то можно было найти на ZN ещё практические задачки, посильные обычному ИБшнику.  

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

Стоит посещать ZN специалистам по ИБ компаний, которые пытаются самостоятельно реализовать некоторые меры защиты, которые самостоятельно занимаются управлением уязвимостями, обновлениями, мониторингом и расследованием инцидентов.

PS: Если бы организаторы расширили Defensive сессию на 2 дня, так было бы совсем замечательно.


вторник, 27 декабря 2016 г.

СЗПДн. Анализ. Обеспечение безопасности при использовании СКЗИ



Думаю, что многие, кто использует сертифицированные СКЗИ сталкивались с инструкцией утвержденной приказом ФАПСИ от 13 июня 2001 г. №152 (далее - Инструкция) и её не совсем удобными требованиями по обеспечению безопасности помещений и хранилищ. Хотя большинство лиц, которые обязаны выполнять требования Инструкции ничего не знают о ней.
Даже есть не трогать ОКЗИ и взять только то что касается хранилищ и помещений пользователей:

“30.        Пользователи СКЗИ хранят инсталлирующие СКЗИ носители, эксплуатационную и техническую документацию к СКЗИ, ключевые документы в шкафах (ящиках, хранилищах) индивидуального пользования в условиях, исключающих бесконтрольный доступ к ним, а также их непреднамеренное уничтожение.
Пользователи СКЗИ предусматривают также раздельное безопасное хранение действующих и резервных ключевых документов, предназначенных для применения в случае компрометации действующих криптоключей.
31.          Аппаратные средства, с которыми осуществляется штатное функционирование СКЗИ, а также аппаратные и аппаратно-программные СКЗИ должны быть оборудованы средствами контроля за их вскрытием (опечатаны, опломбированы). Место опечатывания (опломбирования) СКЗИ, аппаратных средств должно быть таким, чтобы его можно было визуально контролировать. При наличии технической возможности на время отсутствия пользователей СКЗИ указанные средства необходимо отключать от линии связи и убирать в опечатываемые хранилища.
51.          Размещение, специальное оборудование, охрана и организация режима в помещениях, где установлены СКЗИ или хранятся ключевые документы к ним, должны обеспечивать сохранность конфиденциальной информации, СКЗИ, ключевых документов.
При оборудовании спецпомещений должны выполняться требования к размещению, монтажу СКЗИ, а также другого оборудования, функционирующего с СКЗИ.
52.          Спецпомещения выделяют с учетом размеров контролируемых зон, регламентированных эксплуатационной и технической документацией к СКЗИ. Спецпомещения должны иметь прочные входные двери с замками, гарантирующими надежное закрытие спецпомещений в нерабочее время. Окна спецпомещений, расположенных на первых или последних этажах зданий, а также окна, находящиеся около пожарных лестниц и других мест, откуда возможно проникновение в спецпомещения посторонних лиц, необходимо оборудовать металлическими решетками, или ставнями, или охранной сигнализацией, или другими средствами, препятствующими неконтролируемому проникновению в спецпомещения.
62.          Размещение и монтаж СКЗИ, а также другого оборудования, функционирующего с СКЗИ, в спецпомещениях пользователей СКЗИ должны свести к минимуму возможность неконтролируемого доступа посторонних лиц к указанным средствам. Техническое обслуживание такого оборудования и смена криптоключей осуществляются в отсутствие лиц, не допущенных к работе с данными СКЗИ.
На время отсутствия пользователей СКЗИ указанное оборудование, при наличии технической возможности, должно быть выключено, отключено от линии связи и убрано в опечатываемые хранилища. В противном случае пользователи СКЗИ по согласованию с органом криптографической защиты обязаны предусмотреть организационно-технические меры, исключающие возможность использования СКЗИ посторонними лицами в их отсутствие.
63.          Режим охраны спецпомещений пользователей СКЗИ, в том числе правила допуска сотрудников и посетителей в рабочее и нерабочее время, устанавливает обладатель конфиденциальной информации по согласованию с соответствующим органом криптографической защиты. Установленный режим охраны должен предусматривать периодический контроль за состоянием технических средств охраны, если таковые имеются, а также учитывать положения настоящей Инструкции, специфику и условия работы конкретных пользователей СКЗИ.
64.          В спецпомещениях пользователей СКЗИ для хранения выданных им ключевых документов, эксплуатационной и технической документации, инсталлирующих СКЗИ носителей необходимо иметь достаточное число надежно запираемых шкафов (ящиков, хранилищ) индивидуального пользования, оборудованных приспособлениями для опечатывания замочных скважин. Ключи от этих хранилищ должны находиться у соответствующих пользователей СКЗИ.
66.          В обычных условиях опечатанные хранилища пользователей СКЗИ могут быть вскрыты только самими пользователями.

В связи с тем, что в организации может быть достаточно большой процент пользователей СКЗИ и помещений в которых используются СКЗИ. Возьмём, например, медицинские учреждения – в соответствии с распоряжением правительства РФ № 2769-р весь медицинский персонал должен быть обеспечен средствами и сертификатами ЭП, а это большая часть персонала. В организациях других отраслей также возможно обширное применение СКЗИ (удаленный доступ к корпоративной сети, работа в распределенных ИСПДн / ГИС, взаимодействие удаленных объектов, значимый электронный документооборот, передача отчетности, взаимодействие с банками и т.п.)

При реализации требований Инструкции пользователи СКЗИ сталкиваются со следующими проблемами:
·         Опечатывание индивидуальных хранилищ и замочных скважин. А это значит, что придется массово работать с пластилином, а всем пользователям придется носить индивидуальные печати (а тут те же проблемы что и с средствами двухфакторной аутентификации – нежелание пользователей носить их, неудобный форм-фактор, потери, передача, оставленные на рабочем месте печати). Пользователи в настоящее время хотят работать “без пластилина”.  Есть хранилища с кодовыми замками. Есть многошкафчики с электронными замками. Они не вписываются в Инструкцию.
·         Прочные двери с замками. Современные реалии – открытые офисы, кабинеты со стеклянными или пластиковыми перегородками. Они тоже не вписываются в Инструкцию.

·         Решетки на окнах стеклянных зданий
Некоторые пользователи и эксперты ИБ пытаются хитрить – говорят себе: “я буду выполнять только требования, указанные в эксплуатационной документации на СКЗИ, это те же самые требования Инструкции, только адаптированные производителем. Они заменяют для меня требования Инструкции”.

Чтобы разобраться с этими проблемами и спорными моментами, я отправил вопрос в ФСБ России, в котором ссылался на эксплуатационную документацию на СКЗИ КриптоПро и С-терра Шлюз



и ниже представляю их ответ.

Если кратко:
·         нужно выполнять требования документации на СЗКИ + инструкцию ФАПСИ 152 + требования иных документов (например приказа №378 для ПДн)
·         можно использовать компенсирующие меры "адекватные" заменяемым

Что такое “адекватные”? В моем понимании, это меры, которые будут решать те же задачи. Например, “опечатывание” применяется для определения фактов открытия. Нам подойдет любая мера, решающая  задачу фиксации факта открытия.

PS: компенсирующие меры - революция в подходах ФСБ России?

четверг, 22 декабря 2016 г.

СОИБ. Анализ. Вопросы для защиты клиент-банка (клиентской части ДБО)




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

Из результата анализа географии атак видно, что в России таким атакам подвергся наибольший процент пользователей.


К сожалению, нефинансовыми организациями непростительно мало внимания уделяется вопросам защиты клиентской части ДБО. Надеетесь, что банки вас защитят? По текущей практике далеко не всегда это им удается. А недавно вышедший стандарт о реагировании на инциденты ИБ при осуществлении платежей поможет банку разве что аргументировано доказать, что инцидент произошел по вашей вине, что вы не выполнили требуемые меры и т.п.

Кстати из обзора ЦБ о несанкционированных переводах денежных средств в 2015 также можно сделать вывод о том, что большинство несанкционированных платежей выявлялись всё-таки не банками, а клиентами. 

В одной из предыдущих статей я уже выкладывал обзорную презентацию по защите клиентской части ДБО. В этот раз продолжаю тему с перечнем вопросов, которые я обычно задаю в рамках консультаций по защите клиентов ДБО. Если вы также интересуетесь защитой ДБО, возможно эти эти вопросы будут вам полезны как отправная точка в повышении защиты вашего ДБО:
1.      Перечень территориально удаленных объектов, с которых ведется работа с ДБО
2.      Количество пользователей работающих с ДБО
3.      Количество помещений, в которых ведется работа с ДБО
4.      Перечень различных типов технических средств, с которых ведется работа с ДБО (АРМ, ноутбук, сервер)
5.      Перечень различных ОС (с указанием точной версии), с которых ведется работа с ДБО
6.      Перечень используемого клиентского ПО и/или браузеров для работы с ДБО 
7.      Используемые технологии усиленной аутентификации (по каждому банку, либо учесть все варианты - закрытый/открытый ключ, одноразовые пароли по СМС, одноразовые пароли на скретч карте, одноразовые пароли с использованием мобильных приложений, биометрия). Если применяются мобильные устройства (SMS или приложение для аутентификации) - личные или служебные? 
8.      Используемые при работе с ДБО ключевые носители (реестр, HDD, usb flash, usb токен, смарт-карта)
9.      Места хранения ключевых носителей в течении рабочего дня (на столе, в техническом средстве, у пользователя, в запираемом шкафу, в сейфе)  
10.   Места хранения ключевых носителей в нерабочее время (на столе, в техническом средстве, у пользователя, в запираемом шкафу, в сейфе)
11.   Выполняется ли на технических средствах, работающих с ДБО, другая деятельность сотрудников (работа с сетью Интернет, работа с электронной почтой, подготовка документов, др.)?
12.   Кем формируются долговременные пароли для работы с ДБО?
13.   Используются ли траст-скрины при работе с ДБО?
14.   Используется ли ролевая модель работы с ДБО? (формирующий платежи, подписывающий платежи, контроллер)
15.   Какие подразделения работают с ДБО? Кто принимает решение о проведении платежа? Имеется ли формализованная процедура подготовки, согласования и проведения платежей? Возможны ли исключения, например платеж по устному телефонному сообщению от руководителя, по сообщению в whatsup, по указанию, полученному по электронной почте? 
16.   Каналы по которым реквизиты и сумма платежа поступает на техническое средство, работающее с ДБО: на бумаге, файловое хранилище, флешка, электронная почта?
17.   Используемые дополнительные сервисы безопасности, предоставляемые банками (лимиты, перечни доверенных получателей, оперативное информирование о платежах). Интересуют сервисы, которые используются в обязательном порядке по всем ДБО. 1 из 5 - не показатель.  При информировании о платежах - на электронный адрес/телефон каких сотрудников (должность) заказывается информирование  
18.   Средства защиты информации, на всех технических средствах, работающих с ДБО:
·        средство антивирусной защиты
·        персональный межсетевой экран
·        средство защиты от НСД
·        другие персональные средства защиты информации
19.   Имеющиеся документы, регламентирующие работу или защиту ДБО, в том числе правила для пользователей, администраторов, правила ограничения доступа в помещения и т.п. 
20.   Требования по защите информации, предъявляемые к клиенту из всех договоров и соглашений с банками
21.   Инциденты при работе с ДБО, с которыми приходилось сталкиваться

PS: коллеги, если я что-то упустил, дополняйте


четверг, 15 декабря 2016 г.

Общее. Презентация с выступления на региональной комиссии по ЗИ

На этой неделе выступил с докладом на комиссии по защите информации одного из регионов РФ. Рассказывал про актуальное для гос. законодательство, новости, инициативы, и некоторые истории из нашего опыта работы с государственными органами и учреждениями. Выкладываю презентацию – возможно кому-то из гос. будет полезной.





В целом приятно что вопросами защиты информации в конце 2016 года активно занялись не только Государственная дума и Правительство РФ, но и государственные органы в регионах РФ. Главное, чтобы в начале 2017 года не было забыто то, о чем говорили в конце 2016-ого.  

четверг, 8 декабря 2016 г.

СОИБ. Анализ. Стандарт ЦБ РФ о реагировании на инциденты ИБ при осуществлении платежей

 
Сегодня был опубликован новый стандарт Банка России СТО БР ИББС-1.3-2016 “Cбор и анализ технических данных при реагировании на инциденты информационной безопасности при осуществлении переводов денежных средств”.  Вступает в силу с 1 января 2017 г.

Стандарт достаточно объемный – 49 страниц, при этом практический и полезный. Давайте посмотрим на основные моменты поподробнее.

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

Рассматриваются инциденты ИБ следующих типов по источникам получения информации:
·         Информация о которых получена от клиентов
·         Выявленные организацией БС РФ
·         Информация о которых получена от FinCERT и других внешних источников

Инциденты ИБ по типу воздействия:
·         Несанкционированным переводом ДС
·         Деструктивными воздействиями на инфраструктуру платежей

Инциденты ИБ, связанные с несанкционированными переводами ДС, по типам угроз
·         НСД к ИИ клиентов
·         Спам-рассылки клиентам, включая социальную инженерию и распространение вирусов
·         DDoS атаки на ИИ клиентов
·         Воздействие вирусов на ИИ клиентов
·         НСД к ИИ системы дистанционного банковского обслуживания (ДБО)
·         НСД к ИИ автоматизированной банковской системы (АБС)
·         НСД к ИИ систем обработки карточных транзакций (фронт-офис)
·         НСД к ИИ систем пост транзакционного обслуживания (бэк-офис)

Инциденты ИБ, связанные с деструктивными воздействиями на инфраструктуру платежей, по типам угроз
·         DDoS атаки на ИИ организации БС
·         Воздействие вирусов на ИИ организации БС

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

Каждое действие по сбору данных также подробно описывается.

По сути, дан концентрированный опыт которыми раньше владели только Group-IB, отдел К МВД и ещё несколько криминалистических лабораторий.

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

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

Помимо технических данных, необходимо собирать и документировать профиль инцидента ИБ:
·         способ выявления
·         источник информации
·         информация об инциденте ИБ, полученная от источника;
·         сценарий реализации
·         дату и время выявления
·         состав информационной инфраструктуры (далее - ИИ), задействованной в реализации инцидента ИБ, уровень ее критичности
·         способы подключения ИИ, к сети Интернет или сетям общего пользования;
·         контактная информация работников организации БС РФ, в зону ответственности которых входит обеспечение эксплуатации ИИ
·         информация об операторе связи и провайдере сети Интернет

Так как предполагаются достаточно объемные действия, которые надо выполнить оперативно, то рекомендуется заранее подготовить следующие документы:
·         план (регламент) сбора технических данных банком
·         план первоочередных действия клиента
·         план (регламент) сбора технических данных клиентом
·         регламентировать передачу носителей тех. данных от клиента - банку

Для оперативной реализации всех указанных действий организации БС необходимо заранее подготовить комплекс технических средств и инструментов: выделенные АРМы, носители информации, ПО для сбора данных, ПО для контроля целостности, средства сбора и анализа журналов (SIEM), средства записи трафика, контейнеры, наклейки, блокноты, фотоаппараты, диктофоны.   Получится в нашем банке своя криминалистическая лаборатория.   
Для получения помощи в рамках расследования инцидента рекомендуется обращаться в МВД и FinCERT.
В приложениях к стандарту приводятся правильные формы протоколов и примеры технических средств, которые подойдут для нашей лаборатории.

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


пятница, 2 декабря 2016 г.

Общее. Онлайн ИБ тренинг Kaspersky Interactive Protection Simulation

В этот четверг Лаборатория Касперского провела онлайн тренинг по информационной безопасности KasperskyInteractive Protection Simulation Winter Season.

Почитать текстом про это мероприятие можно у Алексея Лукацкого или в правилах ниже.


Я же подготовил видео ролик по данному мероприятию.

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

Тренинг проходил в двух окнах: первое окно – webex конференция в которой ведущий рассказывал правила, озвучивал обще игровые события и комментировал изменения в рейтинге за последний ход. Второе окно – непосредственно интерактивный симулятор, в котором и происходила игра. Для того чтобы не раскрывать всю интригу, я не стал записывать видео с webex, вместо этого добавил комментарии от себя.

Данный тренинг проходил в режиме соревнования. Всего в европейском регионе было зарегистрировано более 160 команд, так что борьба развернулась нешуточная. Так как по правилам игры, необходимо было собрать команду из 2-3 человек и коллективно обсуждать угрозы, меры защиты и возможные действия, то я объединил усилия с ещё одним практикующим специалистом.



Могу сказать, что получилось отлично - Kaspersky Interactive Protection Simulation поможет находить общий язык между представителями разных подразделений и уровней – CISO, CIO, ИТ, ИБ и бизнесом, поможет работать в команде и повысит осведомленность в вопросах кибербезопасности.



понедельник, 21 ноября 2016 г.

Общее. Новости регуляторов с SOC-Forum 2.0

16 ноября принял участие в довольно интересном мероприятии SOC-Forum 2.0 посвященном практике противодействия кибератакам и построению центров мониторинга ИБ.
Для такого практического мероприятия удивительно много было докладов со стороны регуляторов – ФСБ России, ФСТЭК России, ЦБ РФ (большая часть которых кстати пришла с практическим опытом построения центров мониторинга ИБ) на которых я и хочу остановится в данной статье.



ФСБ России участвовали в пленарной дискуссии, а также 2 них было 2 доклада (Алексей Новиков и Владислав Гончаренко) на секции посвященной информированию об инцидентах:
·         (о целях) Организациям по отдельности сложно успешно противостоять организованным группам и сообществу киберпреступников, а значит необходимо объединять усилия ИБ – делится информацией, передавать информацию об атаках и инцидентах в центры мониторинга, а в ответ получать от них рекомендации по защите
·         ФСБ России на практике убедилась в пользе такого объединения, когда во время зимней олимпиады, при взаимодействии с международными центрами мониторинга (CSIRT) удавалось очень быстро реагировать на атаки, в том числе выводить из строя центры управления ботнет-сетями в течении 5 часов

·         (о этапах) Для регулирования таких действий поэтапно создается государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА) – по сути это объединение/сообщество центров мониторинга ИБ и реагирования на инциденты
·         В первую очередь к системе подключаются федеральные и региональные гос. органы исполнительной власти. Основное внимание ФСБ России направлено на создание ведомственных центров ГосСОПКА – центры которые создаются в федеральных органах власти и помогают обеспечивать безопасность в подведомственных
·         Для коммерческих организаций, в том числе для владельцев КВО пока никаких обязательных требований для подключения. Но многие крупные корпорации - владельцы SOC-ков подключаются добровольно, так как видят реальную пользу от обмена важной для ИБ информацией

·         (о документах) в данный момент разработан проект Методических рекомендаций по созданию ведомственных и корпоративных центров ГосСОПКА. Документ не секретный. Алексей Новиков готов предоставить данный документ в ответ на ваш запрос по его контактному адресу
·         В следующем году планируется выпустить регламента обмена информацией об инцидентах в рамках ГосСОПКА , в котором будут формально описаны правила и форматы обмена.
·         Также ФСБ России очень надеется на оживление в 2017 году законопроекта «О безопасности критической информационной инфраструктуры РФ», который даст основания для обязательного подключения к ГосСОПКА компаний, являющихся владельцами критически важных объектов

·         (об охват гос. учреждений) На вопрос о том, как планируется обеспечивать с помощью ГосСОПКА безопасность остальных гос. учреждений (особенно региональных) представитель ФСБ России ответил, что этот вопрос окончательно не решен – ещё ведутся обсуждения как это лучше сделать: через ведомственные, региональные или корпоративные центры ГосСОПКА

·         (о сервисах) ГосСОПКА собирает информацию:
o   источники угроз
o   атакованные системы
o   агрегацию по инцидентам
o   состояние защищенности
o   уязвимости ПО
o   признаки компрометации
o   другие оперативные и значимые сведения
·         ГосСОПКА сейчас предоставляет 4 сервиса:
o   информация о заражённых узлах в области покрытия ГосСОПКА,  
o   обмен индикаторами обнаружения вредоносных программ
o   консолидированные данные об уязвимостях ПО
o   оперативные сведения о проводимых и готовящихся компьютерных атаках

·         (о соглашении) в данный момент, пока нет регламента взаимодействия, между ФСБ России и другими организациями, владельцами центров ГосСОПКА заключается персональное соглашение, в том числе включающее:
o   перечень направлений взаимодействия
o   требования к организации
o   требования к ФСБ России ! (тот редкий случай, когда вы можете что-то потребовать у ФСБ)
o   безвозмездность, ограничение на передаваемую информацию и т.п.

Представители ФСТЭК России (Дмитрий Шевцов и Игорь Носов)  участвовали в пленарной дискуссии, а также сделали доклад на секции посвященной информированию об инцидентах.
·         (об инцидентах) ФСТЭК России ожидает принятия своего законопроекта по информированию об инцидентах ИБ (о котором я писал ранее) в начале 2017 г. Он не заменяет законопроекта о защите КВО.
На вопрос – кого именно надо будет информировать, представитель ФСТЭК России ответил, что после принятия закона будут разработаны соответствующие подзаконные акты, определяющие порядок и варианты информирования

·         (об уязвимостях) ФСТЭК России поблагодарил поименно специалистов (Никитин Виктор, Губенков Артём, Щербаков Андрей), отправивших информацию об уязвимостях в БДУ ФСТЭК. Чем вам не Hall of Fame для российских исследователей ИБ
·         Анализ уязвимостей – важный процесс, который необходим на многих стадиях жизненного цикла ИС. В SOC может выполнятся интеграция процессов мониторинга с результатами анализа уязвимостей (требование к усилению 2 для РСБ.5)

·         (о лицензировании) 17.06.2017 вступает в силу Постановление Правительства РФ от 15.06.2016 N 541 в котором в перечень лицензируемых видов деятельности добавлены “услуги по мониторингу информационной безопасности средств и систем информатизации” (все SOC-и), в котором имеется вид деятельности “контроль защищенности конфиденциальной информации” (пентестеры для ИСПДн и ГИС), и содержатся новые требования к лицензиатам
·         ФСТЭК России должен выпустить отдельный документ, содержащий детальные требования к лицензиату, но пока этого документа нет, а времени остается совсем мало
·         скорее всего многим существующим лицензиатам ФСТЭК потребуется отправлять заявки на обновление лицензии (включение нового вида деятельности) и при этом придется предоставить свидетельства выполнения новых требований (квалификация, процессы управления ИБ)
Подробнее о ПП 541 можно почитать у Лукацкого и Агеева.


ЦБ РФ выступал с докладами на параллельно идущих секциях, соответственно послушать мне удалось только один из них.
·         FinCERT рассматривается как ведомственный центр ГосСОПКА, в область действия которого попадают все кредитно-финансовые организации
·         FinCERT также рассматривает возможность взаимодействия с другими SOC напрямую – можно обращаться
·         Для того чтобы сделать его обязательным принимается новое положение Банка России (прошло все экспертизы и сейчас на согласовании в Минюсте)
·         Именно для кредитно-финансовой сферы время реагирования очень важно, поэтому вводятся обязательный срок информирования – не позднее 3-х часов после выявления инцидента. Срок очень короткий, поэтому банкам придется внедрять какие-то системы автоматизации либо хорошо выстраивать свои процессы, чтобы успевать вовремя проинформировать FinCERT
·         Примеры атак, для которых важен срок оповещения. Благодаря своевременным действиям FinCERT уже удалось предотвратить хищения на сумму около 0.57 млрд рублей
·         Для того чтобы оптимизировать работу по регистрации, анализу, реагированию и уведомлению об инцидентах ЦБ РФ видит необходимость перейти от пересылки информации по электронной почте к работе в некой информационной системе, с личными кабинетами для банков и вероятно API для обмена информацией.





PS: Так как был на форуме первый раз, напишу пару впечатлений о самом форуме. Организован на хорошем уровне – стандарт для Авангарда.
Лично мне пришлось пропустить несколько интересных докладов из-за того, что все сессии шли параллельными потоками: регуляторы или практики; эффективщики или практики или вендоры. Но думаю, что многим посетителям так наоборот было удобнее.
Также отмечу отсутствие зарядных будок для мобильных устройств, кофе-брейки вместо полноценного обеда, постоянные толпы народа в фойе – все это помогло сделать, отрыв от полезного контента минимальным.  
Показательно то, что SOC форум посетило более 1000 человек, хотя ещё недавно тема Security Operation Center была уделом избранных из 10-15 корпораций.  Неужели они все планируют строить SOC? Ведь практики рассказали, что для этого нужны огромные средства, несколько лет, а в итоге команда штатных экспертов будет составлять от 10 до 20 человек? Скорее всего в регионах никто не сможет позволить себе подобное – и единственным вариантом присоединится к коллективному разуму по ИБ будет использование аутсорсинговых услуг внешних SOC-ов.