14.12.2017

ФСТЭК, SOC и #socforum

После окончания SOC Forum одно из изданий попросило меня написать заметку по итогам форума. Я отказался, так как в одну заметку очень сложно вместить все, что произошло и было сказано на мероприятии. Но самое главное, сложно писать о том, чего сказано не было или как было сказано то или иное слово/фраза. Ситуация с ФСТЭК и SOCами как раз относится к этой категории. И сейчас я бы хотел вкратце описать сугубо свои личные впечатления от неучастия ФСТЭК в SOC Forum. Да-да, именно неучастии, так как если у ФСБ была отдельная целая секция (про КИИ, а не SOCи), выступление в пленарке и стенд, то второй регулятор в лице Виталий Сергеевича Лютикова ограничился только участием в пленарной дискуссии. И это при том, что именно ФСТЭК является уполномоченным органом в области безопасности КИИ, и именно у ФСТЭК уже больше года есть утвержденные требования по лицензированию деятельности по мониторингу ИБ (читай, по SOCам). И вот это фактически "молчание" говорит о многом.


Но попробую все-таки тезисно описать то, что ФСТЭК сказала/не сказала по теме мероприятия (но не по КИИ):

  • Виталий Сергеевич повторил мысль, прозвучавшую из его же уст днем ранее на конференции ЦБИ. Чтобы что-то мониторить, надо построить фундамент - то есть иметь выстроенную систему защиты информации. А так как многие организации даже основ не имеют, то говорить о мониторинге еще рано. Тем более, что с точки зрения ФСТЭК тема SOCов - это, как модно говорить, "хайп", так как в тех же требованиях 17-го, 21-го, 31-го приказов вопросы мониторинга и управления событиями безопасности рассматривались уже 4 года назад. Почему именно сейчас такая шумиха вокруг SOCостроения непонятно (ну или понятно).
  • Я уже писал год назад, что на мой взгляд, ФСТЭК слишком рано стала требовать лицензию на мониторинг ИБ при оказании внешних услуг. Не сформировался еще и сам рынок, и непонятно, куда заведут сырые, а местами и невыполнимые требования. И вот на форуме я получил парочку подтверждений этому. Начнем с того, что лицензия ФСТЭК на мониторинг ИБ нужна при любом оказании услуг внешним лицам. И даже если речь идет о холдинге или группе компаний, то лицензия обязательна. Поэтому тот же Сбербанк, мониторящий свои региональные банки и дочерние предприятия, Газпром, РЖД, Ростех, Ростелеком и т.п. структуры, построившие или строящие свои SOCи обязаны иметь лицензию ФСТЭК на мониторинг ИБ. Но что-то они не торопятся это делать. Кстати, интересный вопрос. Относится ли деятельность ФинЦЕРТ к мониторингу ИБ? А если да, то нужна ли ФинЦЕРТу лицензия ФСТЭК на мониторинг?
  • В требованиях ФСТЭК к лицензиатам мониторинга ИБ прописаны требования к используемому ими программному обеспечению. Среди прочего на ряд решений, например, SIEM или систему управления инцидентами, требуется либо сертификат ФСТЭК по требованиям безопасности, либо формуляр. Но, например, когда я слушал доклад Сергея Рублева из ГК Инфосекьюрити про то, как устроен их SOC (а он построен на open source и самописных решениях - Hadoop, Spark, Scala  и т.п.), то я понял, что им сложно будет выполнить требование по сертификации или оформлению формуляров. Не невозможно, а сложно.
  • Требования ФСТЭК к SOCам, оказывающим внешние услуги, и требования ФСБ к ведомственным и корпоративным центрам ГосСОПКИ (а это тоже по сути SOCи) отличаются и местами сильно. Ниже только один пример по техническим средствам. А разница не только в этом - там и в квалификации и численности работающих в центрах людей есть отличия.

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


  • Вообще, отношения между двумя регуляторами, как видно из последних мероприятий, непростые, и их требования не всегда синхронизированы, что приведет еще к сложностям в будущем.



  • А еще у ФСТЭК на SOC Forum был свой стенд, что тоже не может не радовать :-) 


ЗЫ. Понятно, что ряд вопросов снимется в ближайшее время, но огорчает то, что подготавливаемые в спешке нормативные акты не успевают согласовываться между регуляторами в должной мере, чтобы синхронизировать позиции и требования, и отточить формулировки. В итоге страдает потребитель :-(  Но есть ряд вопросов, которые не будут согласованы и просто связаны с тем, что к SOCам выставлены достаточно жесткие требования, которые ограничивают развитие этой ниши рынка ИБ в России...

13.12.2017

Security Dream Team зовет всех в гости

Давным-давно, в далекой-далекой галактике... было организовано выездное закрытое мероприятие в городе Хабаровске с участием известных специалистов по кибербезопасности, которых, с легкой руки организаторов назвали Security Dream Team.


Мероприятие было сделано под заказ и попасть на него со стороны было сложно. Отсюда, как мне показалось, совершенно иное отношение и со стороны спикеров, и со стороны слушателей, которым реально было интересно. Еще одним схожим по сути стало мероприятие "Код ИБ. Профи", прошедшее в первый раз этим летом в городе Сочи. Мероприятие получилось живым и интересным, как с деловой, так и с культурной точки зрения. И оно тоже не подразумевало доступ посторонних - за участие каждый платил свои кровные деньги (ну или компании, что не сильно отличается).


И хотя у меня местами субъективная оценка (я все-таки отвечал за программу), как рассказали организаторы они отбили вложенные в организацию мероприятия деньги, что, на мой взгляд, является показателем. Все-таки нечасто первое мероприятие нестандартного формата уходит в плюс. Тем более, что сочинский "Код ИБ. Профи" отличался от привычных мероприятий тем, что он стоил денег и деньги эти платили участники, а не спонсоры. Иными словами, в программе не было рекламной джинсы и спикеры делились своим практическим опытом по тем или иным вопросам ИБ. Еще одним отличием стала длительность докладов - 1,5 часа на каждое выступление. Никаких 15 или 20 минут, в которые надо уложить достаточно интересный контент, не слиться в банальщину и повтор прописных истин, и не растекаться мыслью по древу. Я просмотрел записи всех докладов и могу сказать, что доклады были интересными со всех точек зрения.

Данное мероприятие показало, что несмотря на все разговоры о том, что у нас не готовы платить за контент, это оказалось неправдой. Да, это не 1000, не 2000 и не 6000 участников. Зато приехали те, кому действительно интересно было услышать интересные доклады от интересных спикеров. Опираясь на полученный опыт компания "Экспо-Линк" решила повторить успех первого "Кода ИБ. Профи" и провести второе мероприятие уже в Москве. Меня вновь пригласили сформировать программу этой конференции, что я сейчас и делаю.

Security Dream Team с PHDays
На самом деле программа уже практически сформирована. Из 24 часовых тайм-слотов распределено уже 20. Целевая аудитория конференции - руководители и ведущие специалисты по информационной безопасности. Мы не будем отнимать хлеб у PHDays и проводить хакерскую конференцию. И у спонсорских мероприятий тоже отнимать хлеб не будем. Наша задача - дать практический и полезный контент для тех, кто принимает решения или участвует в их принятии и кто готов заплатить деньги за участие, а не прийти "на халяву" потусить и пообедать (ни промо-кодов, ни инвайтов, ни бесплатных билетов через спонсоров, ни нагнанных для массовки студентов). Поэтому среди выступающих большое количество действующих руководителей служб, департаментов и отделов ИБ, или людей, которые еще совсем недавно руководили ими. Список участников, согласившихся выступить на данный момент, выглядит следующим образом:
  • Арканоид (независимый эксперт)
  • Вячеслав Борилин (Лаборатория Касперского)
  • Илья Борисов (ThyssenKrupp)
  • Алексей Волков (Сбербанк)
  • Наталья Гуляева (Hogan Lovells)
  • Кирилл Ермаков (Qiwi)
  • Денис Зенкин (Лаборатория Касперского)
  • Антон Карпов (Яндекс)
  • Алексей Качалин (Сбербанк)
  • Алексей Комаров (УЦСБ)
  • Дмитрий Кузнецов (Positive Technologies)
  • Олег Кузьмин (Алмаз-Антей)
  • Алексей Лукацкий (Cisco)
  • Дмитрий Мананников (независимый эксперт)
  • Кирилл Мартыненко (Сбербанк)
  • Александр Скакунов (VolgaBlob)
  • Рустэм Хайретдинов (Атак Киллер)
  • Алексей Чеканов (Алмитек)
  • Лев Шумский (независимый эксперт).

Отличием от сочинского мероприятия будет не только расширенный состав спикеров, но и 4 параллельных потока вместо двух. Видеозаписи мероприятий будут доступны для тех, кто захочет посмотреть то, что было в соседних залах (это, кстати, еще одно отличие "Код ИБ. Профи" - возможность доступа к записанному контенту для более глубокого изучения). Учитывая это число, у меня родилась идея посвятить 4 потока четырем этапам цикла "Шухарта-Деминга", более известного как цикл PDCA, буквы аббревиатуры которого часто расшифровываются как «Планируй – Делай – Контролируй – Совершенствуй». И хотя существуют критики, говорящие о неприменимости PDCA к реальной информационной безопасности, все-таки этот 4-хэтапный цикл до сих пор составляет основу многих стандартов по ИБ или ИТ, на основе которых строится деятельности многих специалистов по ИБ. Я тоже решил взять цикл PDCA за основу и разбить программу "Код ИБ" на 4 потока, посвятив каждый из них одному из этапов создания или совершенствования системы обеспечения информационной безопасности на предприятии. Тем более, что как раз для создания системы ИБ цикл PDCA подходит очень неплохо.

Security Dream Team с Secure IT World
Среди уже заявленных 20 тем будут совершенно разноплановые, но практически полезные темы от тех, кто проверял все на собственном опыте и учился на собственных ошибках:
  • Управление инцидентами с точки зрения бизнеса и с точки зрения SOC
  • Обеспечение непрерывности и киберустойчивости бизнеса
  • OpSec
  • BugBounty в деятельности служб ИБ
  • Геймификация в обучении ИБ
  • Повышение осведомленности и формирование культуры ИБ
  • Анализ машинных данных для обнаружения угроз
  • Разработка стратегии ИБ: от А до Я
  • Обеспечение ИБ в крупной компании
  • Построение работающей системы управления киберрисками
  • Как общаться с внешним миром, если вас взломали
  • Внедрение эффективных корпоративных правил
  • Формирование SLA с точки зрения ИБ аутсорсинга и аутсорсинга ИБ
  • Киберучения для высшего руководства
  • Внедрение SCRUM в ИБ
  • Психология ИБ 
  • И т.д.
Обратите внимание - все темы разноплановые, но безусловно интересные и насущные для многих. Тем более, что они нигде еще не читались и не будут ограничены короткими 15-минутными выступлениями. У вас будет возможность не только погрузиться в часовой мастер-класс, но и задать свои вопросы спикеру, пообщаться с ним в кулуарах, и иными способами удовлетворить свою жажду знаний. Кстати, никакого законодательства не будет. Это осознанное решение. Этих докладов было уже столько (а будет в контексте принятого ФЗ-187 по БКИИ и новых ГОСТов Банка России еще больше), что не хочется тратить драгоценное время на повтор или очередную страшилку, которую можно будет услышать в другом месте. 

Должно получиться очень неплохо. Я верю в это и опыт сочинского "Код ИБ. Профи" доказывает, что это вполне осуществимая задача. Регистрируйтесь! До 31-го декабря действует скидка в 15% на все пакеты участия (они разные). Давайте вместе создавать хорошие мероприятия по ИБ - с минимумом рекламы и максимум пользы для слушателей!

ЗЫ. Как вы могли заметить, у нас в программе есть 4 свободных тайм-слота. Поэтому если вам есть, что сказать, то милости просим. Мы не делаем никаких ограничений на участие в программе с докладом. Выступить может как признанный эксперт, срывающий овации на каждом своем выступлении, так и начинающий специалист, которому уже есть чем поделиться. Вы можете быть представителем вендора/интегратора или работать на стороне заказчика. Основное требование – доклад должен быть интересным, актуальным, ранее нигде не прочитанным, а вы должны иметь подтвержденный опыт выступлений.

Чтобы направить вас по нужному пути, сразу хочу сказать, каких докладов видеть не хочется:

  • Рекламирующих (даже неявно) конкретные продукты, услуги и компании. Исключение составляет какая-либо релевантная статистика, собранная вашими компаниями (если применимо к мастер-классу), или разработанные вами бесплатные продукты, услуги, документы, шаблоны и иные полезные в работе материалы. В любом случае решение за организаторами и куратором программы.
  • Посвященные законодательству, еще не вступившему в силу (да и вступившему тоже).
  • Не имеющих практической ценности. Обзоры технологий, атак, стандартов – это интересно, но из них слушатели врядли вынесут что-то, что можно будет применить на практике, на следующий день после мероприятия. Вообще я не против таких выступлений и сам с такими часто выступаю, но у "Код ИБ. Профи" немного иная цель.
ЗЗЫ. Особо пытливые умы могут обратить внимание, что на главной странице сайта мероприятия указано 31 мастер-класса, а я написал про 24. Никакой ошибки тут нет. Следуя практике RSA Conference или Gartnter Risk & Security Summit выделяются спонсируемые вендорами/интеграторами мастер-классы, которые позволят финансово поддержать мероприятие и предложить участникам различные "плюшки". Отличие этих мастер-классов в том, что там не столь жесткая модерация, как в основной программе. Хотя по опыту Сочи могу сказать, что "спонсорские" доклады тоже были местами спорные (очень спорные), но интересные и вызвавшие дискуссию. По аналогии с Gartner'овской конференцией все спонсорские мероприятия идут параллельно в течение одного часа в первый и во второй день, тем самым у вас появляется выбор - слушать их или, в случае с непонравившейся вам рекламой, потратить время на рабочие вопросы (ответить на звонки или почту).

Приходите, будет интересно!

12.12.2017

Планы по стандартизации ИБ финансовых организаций

Сегодня утром проходило заседании ПК1 ТК122 Банка России, посвященное стандартизации ИБ в финансовых организациях, на котором решалось 3 вопроса:

  • обсуждение и голосование за ГОСТа 57580.2 по оценке соответствия защитных мер, описываемых ГОСТом 57580.1 (единогласно при одном воздержавшемся)
  • обсуждение и голосование за СТО по безопасности аутсорсинга (единогласно)
  • обсуждение планов подкомитета по разработке новых стандартов по ИБ.
В качестве резюме хочется тезисно отметить следующее:
  • ЦБ выделяет для себя на ближайшие годы (до 2021 года) 5 направлений развития - управление киберрисками, взаимодействие с поставщиками услуг, управление инцидентами, киберустойчивость и мониторинг киберрисков и ситуационная осведомленность.
  • Стандарт по киберрискам - это реинкарнация СТО 1.0, который был посвящен преимущественно вопросам управления ИБ и управления рисками. В недавно принятом ГОСТ 57580.1 описаны защитные меры (то есть вопросы уровнем ниже). Отсюда логичное желание регулятора трансформировать СТО 1.0 в ГОСТ, что постепенно и будет происходить. Пока же СТО 1.0 (как и СТО 1.2) остаются и отменять их никто не будет. В паре с этим ГОСТом будет и стандарт по оценке соответствия (также в статусе ГОСТа).
  • Сам комплекс стандартов по ИБ (СТОБР) продолжит существовать и будет выполнять методологическую функцию. По сути на нем будут апробировать различные направления, которые затем будут входить в состав ГОСТов или нормативных актов Банка России.
  • СТО 1.3 по сбору данных для расследования инцидентов и РС 2.5 по менеджменту инцидентов трансформируются в соответствующие ГОСТы, к которым добавится третий стандарт по обмену информацией об ИБ между финансовыми организациями и ФинЦЕРТом.
  • Появится ГОСТ по аудиту, приходящий на смену СТО 1.1.
  • Планируемый сейчас СТО по ИБ аутсорсинга трансформируется со временем в ГОСТ. А в пару к нему появится стандарт по ИБ при использовании информационных сервисов.
  • Ранее неоднократно упоминаемая тема по киберустойчивости трансформировалась в ГОСТ по обеспечению непрерывности выполнения бизнес и технологических процессов (и тут АСУ ТП :-) и ГОСТ по оценке соответствия этим требованиям.
  • Наконец, пятым направлением станет разработка ГОСТа по мониторингу киберрисков (модная тема) и ситуационной осведомленности и ГОСТа по оценке соответствия в данной сфере. 
Визуально, план работы ПК1 ТК122 Банка России я бы отразил примерно так (серым показано то, что уже разработано и практически принято):

Помимо этого я бы отметил несколько интересных тезисов, прозвучавших на мероприятии:

  • Планируемый в свое время СТО по некредитным финансовым организациям (а точнее два СТО) плавно перетечет в ГОСТ 57580.1. Ну тут никаких сюрпризов - это было логично; зачем городить СТО, если новый ГОСТ и так покрывает НКФО. Ну и остальные ГОСТы, упомянутые выше, будут учитывать специфику НКФО. 
  • Во исполнении пунктов ГОСТа и новой редакции 382-П, требующих оценки соответствия платежных и финансовых приложений (в виде сертификации или оценки уязвимостей), ЦБ подготовил профиль защиты, направленный в ФСТЭК России на согласование. Соответственно разработчикам банковского и финансового ПО стоит подготовиться к данной процедуре.
  • Аккредитации поставщиков услуг аутсорсинга ИБ не планируется, а вот тема некой "аккредитации" (хотя скорее это некоторая форма оценки качества работ) аудиторов поднималась и в каком-то виде будет реализована. Либо это будет добровольная сертификация, либо саморегулируемая организация. Вопрос пока в стадии обсуждения.
  • ЦБ активно копает тему страхования киберрисков, но каких-то конкретных действий и стандартов не озвучено. Какая-то ясность будет на Магнитогорском форуме, регистрация на который уже началась.
  • Применительно к теме КИИ ЦБ никаких документов не планирует выпускать. Регулятором является ФСТЭК и именно она пишет требования к безопасности значимых объектов КИИ. ФСБ в свою очередь устанавливает требования по присоединению финансовых организаций к ГосСОПКЕ. По оценка ЦБ, и я с ними согласен, не очень много финансовых организаций будет иметь значимые объекты. А вот отправлять данные по инцидентам в ГосСОПКУ придется. Правда тут мы с ЦБ не сходимся во мнении. Они считают, что ФинЦЕРТ является ведомственным центром ГосСОПКИ и финансовые организации смогут без проблем направлять данные об инцидентах только в одну сторону, в ФинЦЕРТ, который уже сам все направит в ГосСОПКУ. Я по формальным признакам с этим не согласен, но буду рад ошибиться.
  • Новая редакция 382-П (я о ней писал) находится на согласовании в ФСБ и скоро должна быть отправлена в Минюст на утверждение. Предположу, что это произойдет достаточно скоро и она вступит в действие (как и новая редакция 2831-У) с 1-го июля 2018-го года. Самое главное, что в ней не будет ссылок на новый ГОСТ 57580.1. Это произойдет в следующей версии 382-П, работа над которой начнется сразу после принятия текущего проекта. В принципе это было известно давно, но многие почему-то считали, что принятие в августе нового ГОСТа означает, что теперь на него ЦБ вставит ссылки во все свои нормативные акты. Это не так. Процесс небыстрый и требует, как минимум, разработки всей номенклатуры основных ГОСТов по защите информации и управлению киберрисками, что также займет определенное время.

Вот такой набор новостей по тому, что ЦБ готовит финансовым организациям с точки зрения нормативных требований. Обратите внимание, что на организации возрастет нагрузка по выполнению требований и, самое главное, оценке соответствия им. Запланирована разработка 5 стандартов по оценке соответствия и это помимо оценки, предусмотренной 382-П, а также иными требованиями, распространяющимися на финансовые организации (PCI DSS, SWIFT и т.д.). Вот такие дела...

Можно ли взимать деньги за законную обязанность или кто платит за подключение к ГосСОПКЕ? #socforum

Вчера я задался вроде бы и риторическим на первый взгляд, но не таким уж и простым вопросом. А кто платит за подключение финансовых организаций к ГосСОПКЕ, если они не смогут отправлять данные об инцидентах через ФинЦЕРТ? Если я правильно читаю ФЗ-187 и методические рекомендации ФСБ по созданию ведомственных и корпоративных центров, то субъект не может напрямую подключиться к ГосСОПКЕ - ему нужен ведомственный или корпоративный центр, который и будет принимать соответствующие данные об инцидентах и пересылать их в Головной центр ГосСОПКИ.

Если мы посмотрим на такие структуры как РЖД, Сбербанк, Газпром, Росатом, Ростех, ФНС, ФТС и другие аналогичные по масштабу государственные и коммерческие структуры, то никаких сложностей у них с созданием своих собственных ведомственных или корпоративных центров ГосСОПКИ нет. Они без особых проблем смогут создать такие центры и обязать все подчиненные структуры, дочерние предприятия, удаленные офисы и т.п. направлять всю информацию к ним. По сути речь идет о обычном SOCе, который будет сопряжен с ГосСОПКОЙ. Но что делать тем, кто не является частью холдинга или крупного ведомства?

Возьмем какую-нибудь значимую платежную систему или предприятие электроэнергетики. Смею предположить, что они могут попасть под категории, установленные Постановлением Правительства о категорировании значимых объектов КИИ. И они обязаны будут направлять данные об инцидентах на своих объектах в ГосСОПКУ - это их обязанность, от которой нельзя отказаться. Но как они будут направлять? Напрямую нельзя. Своего ведомственного или корпоративного центра у них нет. Через чужой ведомственный центр? Ну только если он создан в рамках той же отрасли, например, у МинЭнерго (если такой появится). А у платежной системы? Как мы увидели вчера ФинЦЕРТ ЦБ пока не может считаться ведомственным центром ГосСОПКИ. И как быть? Остается искать какой-либо корпоративный центр и заключать с ним договор. Собственно в методичке ФСБ и написано, что в этом и заключается основная роль корпоративных центров. Только есть одно "но".

Уведомлять об инцидентах ГосСОПКУ - это обязанность субъекта, а заключать с ним договор - это право корпоративного центра (от него и отказаться можно). Более того, скромно предположу, что корпоративный центр не будет работать бесплатно. И если отправку данных об инцидентах в рамках договора на более широкие услуги аутсорсингового SOC еще можно понять, то что делать, если субъект КИИ не хочет никакого внешнего SOC и ему надо просто отправить в ФСБ то, что от него требует закон и от чего отказаться никак нельзя? Почему он должен платить за то, что его обязывают делать и за невыполнение чего предусмотрена ответственность (может быть даже уголовная)?


Странная ситуация. Ее могли бы исправить территориальные и региональные центры ГосСОПКИ, которые могут быть созданы ФСБ и которые могли бы взять на себя функцию приема сообщений от субъектов КИИ, которые не подключены ни к корпоративным, ни к ведомственным центрам. Но есть ли они? И какова процедура работы с ними? На SOC Forum эта тема не звучала, оставшись за рамками всех докладов. Вообще тема взаимодействия именно субъектов КИИ с ГосСОПКОЙ на SOC Forum была раскрыта не полностью, как мне кажется. Возможно ответ дадут готовящиеся в ФСБ приказы:

  • Перечень информации, предоставляемой в ГосСОПКА и порядок ее предоставления
  • Порядок обмена информацией о компьютерных инцидентах
  • Порядок информирования ФСБ России о компьютерных инцидентах, реагирования на них, принятия мер ликвидации последствий,
но пока их нет и до 1-го января остается совсем немного времени на их разработку и принятие. 


Кстати, бытует мнение, что направлять данные об инцидентах в ГосСОПКУ должны субъекты КИИ, владеющие только значимыми объектами КИИ. Это было бы классно, сильно уменьшив нагрузку на:
  • обычные поликлиники, которые являются субъектами КИИ только потому, что входят в сферу здравоохранения,
  • микрофинансовые организации и ломбарды, которые являются субъектами КИИ только потому, что входят в сферу финансового рынка,
  • домашних операторов связи, которые являются субъектами КИИ только потому, что входят в сферу связи,
  • и т.п.
Но... Я специально несколько раз перечитал ФЗ-187 и не нашел там никаких ограничений на круг лиц, которые взаимодействуют с ГосСОПКОЙ. Часть 2 статьи 9 начинается со слов "субъекты критической информационной инфраструктуры обязаны" и дальше перечисляется три обязанности - информирование об инцидентах, оказание содействия сотрудникам ФСБ и выполнение порядка эксплуатации средств ГосСОПКИ. Часть 3 той же статьи дополняет этот перечень новыми обязанностями и вот они уже распространяются на владельцев значимых объектов КИИ. Иными словами, независимо от наличия или отсутствия значимых объектов, взаимодействовать с ГосСОПКОЙ придется и вопрос о том, как ломбарду или районной поликлинике подключиться к ней встанет во всей красе. И ответа на него на SOC Forum не было (или я его пропустил).

ЗЫ. Решение описанной в заметке проблемы есть - субъект может стать корпоративным центром и, мониторя самого себя, направлять эти данные в ГосСОПКУ. Вот только выполнить все требования к таким центрам непросто и цена вопроса может быть несоизмеримо большой. А учитывая, что начать уведомлять об инцидентах надо с 1-го января 2018-го года, вопрос встает очень остро.

11.12.2017

ФинЦЕРТ и ГосСОПКА: как им жить вместе #socforum

На прошлой неделе Банк России выложил на официальный портал размещения проектов нормативных актов проект указания "О внесении изменений в Указание Банка России от 9 июня 2012 года № 2831-У "Об отчетности по обеспечению защиты информации при осуществлении переводов денежных средств операторов платежных систем, операторов услуг платежной инфраструктуры, операторов по переводу денежных средств". Я про него уже писал в августе (с тех пор оно не изменилось), но этот проект заставил меня коснуться темы связи между ФинЦЕРТом Банка России и ГосСОПКОЙ, о которой я так ничего и не услышал в рамках прошедшего SOC Forum. Будем считать эту заметку первой в серии по результатам московского SOC Forum 2017.

Стенд ФинЦЕРТ на SOC Forum (фото АвангардПро)
Итак, что же я хотел услышать на SOC Forum про взаимоотношения ГосСОПКИ и ФинЦЕРТа? Ответ на очень простой вопрос - как финансовые организации, которые окажутся владельцами значимых объектов КИИ, должны будут сообщать об инцидентах в ГосСОПКУ при условии, что сейчас они и так (правда, по требованиям ЦБ, а не ФЗ-187) отправляют данные об инцидентах в ФинЦЕРТ? В части 552-П такая отправка осуществляется в течение 3-х часов с момента наступления/обнаружения инцидента. По 2831-У 203-я форма отчетности об инцидентах направляется раз в месяц. По проекту изменений в 2831-У, упомянутому выше, это будет делаться раз в квартал или раз в полгода и отчетность не будет содержать данных об инцидентах. Такое изменение связано с тем, что в проекте новой редакции 382-П написано, что все данные об инцидентах направляются в ФинЦЕРТ в порядке, установленном Банком России и размещенном на официальном сайте ЦБ. Такого порядка еще нет, но я не думаю, что там будет указано значение, отличное от 552-П, то есть 3 часа на уведомление об инцидентах.

А теперь вновь повторю вопрос. Финансовая организация, владеющая значимым объектом КИИ, должна направлять данные об инцидентах только в ФинЦЕРТ (а он уже сам все отправит дальше в ГосСОПКУ) или помимо ФинЦЕРТа надо дублировать информацию и для ГосСОПКИ? Вопрос непраздный. Первый вариант предпочтительнее для всех, так как он не меняет сложившейся за последнее время ситуации.

Артем Калашников, руководитель ФинЦЕРТ

Но чтобы реализовать этот сценарий нужно, чтобы ФинЦЕРТ числился корпоративным или ведомственным центром ГосСОПКИ. Однако, согласно методическим рекомендациям ФСБ по созданию ведомственных и корпоративных центров ГосСОПКИ к таковым относятся только:
  • госкорпорации
  • операторы связи
  • лицензиаты в области защиты информации
  • органы госвласти.


Так вот особый статус Банка России, который не относится ни к одной из этих 4-х сущностей, не позволяет стать ему ни корпоративным, ни ведомственным центром. И отсюда вытекает сразу два важных вопроса вопрос:
  • Придется ли финансовым организациям направлять данные об инцидентах в ГосСОПКУ напрямую? Судя по ст.9.2 ФЗ-187 да, придется отправлять данные об инцидентах в обе стороны - ФинЦЕРТ и ГосСОПКУ. Хотелось бы, конечно, уменьшить число точек входа.
  • В течение какого интервала времени надо будет отправлять сведения об инцидентах? В ст.9.2 ФЗ-187 говорится "незамедлительно". Что это означает? Не хотелось бы, чтобы у ФСБ и ЦБ были разные порядки уведомления, что повлечет за собой удвоение работы по выполнению требований и ФЗ-187 и 382-П/552-П.
  • Если финансовые организации вынуждены будут отправлять данные об инцидентах в ГосСОПКУ, то как это должно происходить? Кто будет тем корпоративным центром, который будет принимать данные от финансовой отрасли и отправлять их в головной центр ГосСОПКИ? А самое главное, будет ли это бесплатно?


На эти вопросы, к сожалению, ответа пока нет и, к сожалению, на SOC Forum о них никто не говорил. Да, думаю, никто пока и не может сказать ничего конкретного. Очень уж много неясного в спешке разработанном и принятом ФЗ-187. Все участники процесса пытаются найти устраивающие всех решения, но надо понимать, что есть и непреодолимые обстоятельства, которые могут всему помешать. Зовут эти обстоятельства - юристы.

Зато выступление Андрея Думанского из ФинЦЕРТ было неплохим - подробно были освещены направления деятельности ФинЦЕРТ, достигнутые результаты, сложности в работе. Из нового (по сравнению с ранними выступлениями на InfoSecurity Russia и закрытом клубе SOC Club) я бы отметил следующие моменты:
  • вступление ФинЦЕРТ в FIRST и EAST EGAF
  • проведение криминалистических экспертиз (компьютерных исследований)
  • автоматизацию процесса отправки индикаторов компрометации (до конца года хотят запустить).



ЗЫ. На смену упомянутым выше методическим рекомендациям ФСБ готовит требования к корпоративным и ведомственным центрам. Может быть там учесть статус ФинЦЕРТ? Правда, статью 9.2 ФЗ-187 это все равно не отменит.


08.12.2017

Демотиваторы и смешные картинки с #socforum

Решил по традиции выложить все демотиваторы и смешные картинки, которые я делал для последнего SOC Forum:






























07.12.2017

Бывает ли кибербезопасность с десяти до шести?

Незапланированная заметка, навеянная тремя событиями. Началось все позавчера, когда Дима Мананников опубликовал в Фейсбуке заметку про безопасность смарт-контрактов, ICO и всего такого и, не увидя бурной дискуссии от коллег, высказал удивление сему факту. Мол, задача безопасника - отслеживать все новые бизнес-технологии и искать способы их безопасного внедрения/использования в бизнесе. Я ему возразил и в итоге завязалась дискуссия, в которой я высказал следующую мысль: "Безопасник в массе свой рядовой сотрудник, выполняющий трудовые обязанности с 10 до 6. Он ничем не отличается об уборщицы или бухгалтера. Им всем комфортно в своем болотце и менять что-то они будут только в экстренных ситуациях. Плюс образование, которое учит compliance и борьбе мо старыми угрозами. Отсюда все. Исключения бывают, но только подтверждают общее правило".

Подтверждение моему высказыванию я получил относительно недавно на одном крупном предприятии, которое любит выпячивать свою экспертизу в области ИБ. В рамках очередного моего приезда к ним и рассказа о том, как у нас в компании выстроен процесс реагирования на инциденты, я рассказал о сервисе Cisco Umbrella Investigate, позволяющего оперативно и без установки какого-либо железа и софта у заказчика (и даже без какой-либо их перенастройки и перенаправления трафика) проводить анализ инцидентов, связанных с Интернет-активностью. Решение заинтересовало заказчика, тем более, что он запустил свой SOC, в рамках которой работала группа по расследованию инцидентов и Threat Intelligence. От нас оперативно потребовали триальный доступ для тестирования, что мы и сделали. Прошел месяц. На очередной встрече у этого заказчика представитель группы реагирования на инциденты в присутствии большого руководства отчитался о завершении тестировании Investigate и нахождении ряда интересных кейсов. Руководство заинтересовалось и попросило показать систему в действии... И вот тут случился казус. Я с ноутбука зашел в панель аналитика и предложил представителю incident response team показать, что он обнаружил. Но в глазах его я увидел, что он в первый раз видит панель аналитика Investigate. Заподозрив неладное, я хотел спустить дело на тормозах, но большое руководство заказчика потребовало "красивых картинок и схем", за которыми последовал ужасный вывод - выяснилось, что IRT заказчика даже не активировало предоставленный им временный доступ и он, разумеется, уже "протух". Оставлю за рамками произошедший после этого разбор полетов, но меня неприятно поразило отношение некоторых безопасников к своим обязанностям. Чем-то это напомнило Советский Союз с его победными реляциями, отчетами о деятельности для галочки и очковтирательством :-(

Финальным аккордом стали комментарии Михаила Никишина к моей заметке про семинар Gartner, который высказал (да уже и не первый раз) мысль, что в нашей отрасли ИБ вообще нет безопасников (вспоминаем сентябрьский чеклист "настоящий ли ты безопасник?"), а только одни айтишники с их специфическим мышлением и способом решения задач. Не совсем я согласен с Михаилом, но доля истины в его словах есть. Кибербезопасность превратилась в обычную деятельность, как и сотни других профессий. И многие специалисты действительно работают с 10 утра и до 6 вечера, напрочь забывая про ИБ за пределами времени, установленного Трудовым Кодексом.


По сути, большинство "безопасников" действительно погрязли в своей зоне комфорта и выйти из нее зачастую не могут или не хотят. Лет 10 назад я приехал к одному знакомому, руководившему сектором ИБ в одной организации. Мы поговорили о том, о сем, и я предложил ему рассмотреть несколько технологий и решений, которые могли бы помочь ему в озвученных им проблемах. И что же вы думаете? Он отказался, сославшись на то, что его все и так устраивает, а новые решения - это новая головная боль, а ему хотелось бы сидеть на попе ровно и не напрягаться по поводу чего-то нового. Он до сих пор сидит на своей должности, не выходя из зоны комфорта, не занимаясь развитием. Хотя я и встречаю его регулярно на различных ИБ-тусовках, где он задает якобы каверзные вопросы, но в своей практике затем полученные знания никак не использует. Грустно это...

Дмитрий удивляется, почему безопасники не занимаются бизнес-стороной своей деятельности. Я же удивляюсь, почему они не занимаются даже просто новыми технологиями ИБ. NTA, EDR,  UEBA, IAG/IGA, PAM, CASB, SDS, SDP, SOAR, DDP, SIG, RASP, SAT, NFT и др. Нет денег? Не смешите. Бюджеты у многих заказчиков измеряются сотнями миллионов, а то и миллиардами рублей. Они могут себе позволить эти решения и они им зачастую нужны. Но не используют. Потому что надо въезжать во все эти новомодные аббревиатуры, внедрять их, учиться им, объяснять руководству результаты и т.п. А зачем? Нормативка не требует, за инциденты не наказывают, эффективность никого не волнует. "И так сойдет", как говорилось в известном советском мультфильме.


Грустные размышления какие-то получились. Может я не прав? Может жду от безопасников чего-то чего не стоило бы? Фиг знает.

ЗЫ. Оказывается я про это два месяца назад писал, но другими словами :-) Наболело, значит. Ну да ничего. Повторенье - мать ученья.

ЗЗЫ. Дальше вернусь к темеSOCов.