09.09.2019

Разъяснения Банка России с осенной сессии Уральского форума

На прошлой неделе прошла конференция, организатором которой стал Банк России, и которая стала выездной сессией Уральского форума, проведенной в Москве. На ней регулятор попробовал ответить на животрепещущие вопросы, касающиеся как ЕБС, так и недавно выпущенных, но уже вызвавших немало вопросов нормативных актов (683-П, 684-П и т.п.). Параллельно с этим, как член ПК1 ТК122 я собрал с отрасли около 50 вопросов, которые были направлены в Департамент ИБ Банка России с целью получения ответов на них. И вот часть таких ответов прозвучала на конференции. Позволю себе тезисно озвучить то, что было озвучено.

Единая биометрическая система
  1. Банк России опросил 38 банков, 7 из которых планируют делать свои собственные решения для подключения к ЕБС. Остальные хотят использовать типовое решение, самых распространенных сейчас четыре - от Ростелекома, Инфотекса, ЦФТ и IDSystems.
  2. Стоимость облачного решения Ростелекома - около 3 миллионов рублей в год. Стоимость типового решения - 5 миллионов (включая инфраструктуру построения, HSM, антивирусы и т.п.).
  3. Типовое решение уже включает тематические исследования и финансовым организациям проводить их не требуется.
  4. Покупка типового решения не отменяет выполнения методички Банка России МР-4.
  5. По словам ЦБ, ряд разработчиков типовых решений делают только сбор биометрии, без предоставления функции верификации, что неправильно по мнению регулятора.
  6. Стоимость собственной разработки (в качестве примера был приглашен Тинькофф) обходится примерно в те же 5 миллионов. Но это все без резервирования тех HSM. С резервированием - стоимость увеличивается еще примерно на 3-4 миллиона. Длительность создания собственного решения у Тинькофф составила 4-5 месяцев без тематических исследований.
  7. Обсуждалась тема мобильного сбора биометрии, для которой максимальный возможный класс сертификации СКЗИ озвучивался как КС2. Готовых решений пока нет, но Ростелеком работает над ним. При этом вопрос качества собранной биометрии с помощью планшета или смартфона не обсуждался совсем.
  8. Для удаленного сбора должны применяться только СКЗИ КС3 или КС2 но с соблюдением. требований к СВТ 4-го класса. Пока обойти эти требования или снизить нельзя. 

683-П / 684-П / 672-П
  1. Планируется кардинальное изменение 382-П, из которого уберут упоминание кредитных организаций (операторов по переводу денежных средств). 382-П будет распространяться на участников НПС - некредитные организации, а также на новые сущности, введенные последними правками в 161-ФЗ - платежные агрегаторы, разработчики платежных приложений, операторы информационного обмена (SWIFT, привет!). Защита информации при осуществлении переводов денежных средств уйдут целиком под 683-П, который покрывает все банковские операции. 
  2. ЦБ считает, что анализ уязвимостей можно проводить своими силами, если есть для этого возможности, навыки и квалификация. Но пока непонятно, как отсекать некачественно проведенную оценку. ЦБ думает над этим.  
  3. На вопрос о том, что является доказательством проведения анализа уязвимостей, если это делает производитель платежного ПО или привлекаемый лицензиат, ЦБ подготовит разъяснение. Надо внимательно посмотреть ГОСТ 15408 в части представления результатов оценки.
  4. В августе ЦБ разослал письмо по кредитным организациям, в котором говорится, что с учетом принятия ГОСТ 57580.1/57580.2 и 683-П, направлять оценку по СТО БР ИББС 1.2-2014 больше не требуется. Ее проведение остается на усмотрение кредитной организации. Когда кредитные организации выведут и из под 382-П, то у них останется единственная оценка соответствия - по ГОСТу. Надзор ЦБ больше не будет руководствоваться СТО БР при проведении своих мероприятий.
  5. 202-я форма будет пересмотрена.
  6. Документ по операционным рискам (с резервирование капитала и прочим блэкджеком) будет очень плотно завязан на новый ГОСТ по управлению киберрисками, который сейчас активно пишется и в октябре будет представлен членам ПК1 ТК122. Так что можно ожидать, что до конца года положение по операционным рискам будет все-таки принято.  
  7. На вопрос о том, почему 683-П и 684-П местами так отличаются друг от друга, прозвучало, что хоть они и писались ДИБом, но затем сильно перерабатывались соответствующими - департаментами банковским и НФО.
  8. Несмотря на то, что в 684-П прямо не упомянуты (при установлении уровней защиты) микрофинансовые организации, ломбарды и ряд иных, на них распространяются общие требования, прописанные в 684-П (защита от вредоносного кода, уведомление клиентов о рисках и т.п.).
  9. Если кредитная организация ведет депозитарную и репозитарную деятельность, то применять необходимо и 684-П, даже несмотря на то, что у него сфера деятельности - некредитные финансовые организации. Но, учитывая, что кредитные организации обязаны также выполнять и 683-П, то при пересечении требований выполняться должны те, которые жестче, то есть, по сути, 683-П. 
  10. По поводу SMS и Push ЦБ считает, что не обязательно применять УКЭП. Можно использовать и другие меры подтверждения целостности без УКЭП. Сейчас завершается подготовка информационного письма для этого.
  11. Было озвучено, что есть правовые проблемы с использованием облачным провайдером ЭП банка (ключи нельзя передавать третьим лицам). ЦБ вроде как нашел с ФСБ некое решение, но у них есть сомнение в его правомерности. Если в новую редакцию 63-ФЗ внесут "третью доверенную сторону", то проблема разрешится. Пока этот вопрос в серой зоне и каждая кредитная организация решает его для себя самостоятельно.
  12. ГОСТ допускает применение несертифицированных средств защиты при отсутствии их на рынке (техническая невозможность) или высокой цены (экономическая нецелесообразность). Это и так было понятно, но тут это прозвучало еще раз на прямо заданный вопрос.
  13. Вновь прозвучала мысль, которая звучит последние лет 10, что ЦБ не интересует КАК будут реализовываться защитные меры и какие конкретные технические решения будут применяться. Финансовые организации сами выбирают способ реализации. Для ЦБ важна оценка уровня риска, для чего ЦБ сейчас внедряет новый риск-ориентированный подход, который будет оценивать каждую организацию по набору показателей.

Перспективы и планы

Конференция не была ориентирована на озвучивание планов по новым нормативным актам, но на одном из слайдов были приведены направления деятельности ДИБ, из которых становится понятно, в каком направлении ждать и новых нормативных актов. Как минимум, сейчас пишется нормативка под финансовый маркетплейс, блокчейн, цифровой профиль и Open. API.

04.09.2019

Почему ВУЗы не преподают теорию игр специалистам по ИБ?

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

Когда я учился на "Прикладной математике", моя специализация по диплому была "Защита информации", но что удивительно, нам не преподавали теорию игр, которая, очень хорошо подходит для преподавания специалистам по ИБ. Сейчас я оставлю в стороне тему бизнес-направленности ИБ - ей очень трудно учить студентов технических специальностей, которые еще даже не знают, пойдут они работать в ИБ или нет. А вот теория игр подойдет, независимо от того, станет ли выпускник безопасником или пойдет искать себя на каком-либо ином поприще. В области же ИБ эта теория может найти свое достойное место, повернув процесс преподавания как от тупого пересказа преподавателями российской нормативки, в которой даже ее авторы уже путаются, так и от рассмотрения устаревших версий средств защиты, которые составляют хорошо если 10% от портфолио, с которым придется иметь дело выпускнику.

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

По сути речь идет о некооперативной игре с ненулевой суммой, где как минимум 3 игрока - компания, хакеры и регуляторы. Каждая из сторон имеет свою цель и некоторую стратегию, которая ведет либо к выигрышу, либо к проигрышу - в зависимости от поведения других игроков.  Вот эта зависимость от поведения других игроков отличает теорию игр от типичного преподавания ИБ в российских ВУЗах. Теория игр учитывает ресурсы игроков, их поведение и его вариативность, различные цели игроков, а также наличие определенных правил игры. Все это позволяет выстроить (или приблизиться) оптимальную стратегию деятельности своей службы. В более реалистичном примере игроков у нас становится больше - и регулятор у нас обычно не один, и хакерских групп с разной тактикой не одна, и даже сама компания представляет из себя набор разных сил с разными интересами, которые надо учитывать в ИБ, - пользователи, бизнес, ИТ... 

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

Про игру Касперского я повторяться не буду, покажу еще парочку примеров игр по ИБ, которые основаны на теории игр (я постил их скриншоты в своем Twitter, но решил повторить и в блоге). Начну с решения Project Ares компании Circadence, которое позволяет моделировать различные ситуации и учить специалистов по ИБ реагированию на различные ситуации.


За последний год проект существенно обновился и "вырос" - появились различные варианты подписки - для ВУЗов, для корпоративных пользователей и т.п.


Есть различные сценарии проведения игр с разным числом участников и разными заданиями.


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


Есть в Project Ares и развлекательные компоненты, например, "пасьянс "Косынка" на тему ИБ:


или аналог "Своей игры":


или аналог "Змейки":


Стоит отметить, что несмотря на игровой формат, Project Ares - это не обычная компьютерная игрушка. Это целая платформа для обучения специалистов по ИБ, использующая разные техники, вплоть до искусственного интеллекта, подстраивающегося под манеру каждого игрока и меняющего задания на ходу.


Но стали появляться и компьютерные игры, доступные каждому желающему. Например, на игровой платформе Steam скоро выпустят игру ThreatGEN: Red vs Blue, которая позволит множеству игроков попробовать себя в роли хакеров или защитников, не ломая реальные сети и системы, но оттачивая свои стратегические и тактические навыки, которые можно будет применять в реальной жизни (конечно, с оговорками). 

У этой игры будет несколько версий:
  • Red vs Blue. Игра для всех желающих на платформе Steam.
  • Red vs Blue Corporate. Настраиваемые сценарии игр для корпоративных тренингов.
  • Red vs Blue CTF. Соревнования команд.
  • Red vs Blue Tabletop. Игра для проведения штабных киберучений.
  • Red vs Blue Instructor Led Training.
Несмотря на громкое название заметки, я не ставил перед собой цель написать учебник или пособие по теории игр для кибербезопасника (все-таки я учил эту дисциплину в качестве факультатива, для себя лично, уже после окончания ВУЗа, и не могу сказать, что я в ней специалист). Скорее мне хотелось показать, что сегодня, в условиях непрерывно меняющихся технологий, атак, нормативки, и постоянно устаревающих знаний, подходы к обучению (в том числе и корпоративному) должны меняться. И геймификация, построенная на теории игр, является одним из инструментов решения этой задачи.

03.09.2019

Deepfake: обход биометрии, непредусмотренный регуляторами

Все откладывал как-то эту тему, но тут что-то критическая масса накопилась - за вчерашний день попало на глаза несколько новостей/статей про обход биометрических систем. Об этом и будет заметка. Начну, пожалуй, с шуточного видео, за которым при этом скрыта очень большая проблема, название которой deepfake. Если первая версия одноименного приложения накладывала лица на видео очень некачественно, то китайское приложение ZAO делает это на порядок лучше. Посмотрите, как с помощью всего одной фотографии (аватарки с соцсети) смогли поменять лицо Леонардо ДиКаприо в фильмах с его участием.



Меня эта тема интересует последние пару лет, когда только появилось первое приложение DeepFake и когда Банк России стал семимильными шагами внедрять Единую Биометрическую Систему (ЕБС). Когда ЦБ выпустил свое Указание 4859-У, то я надеялся, что там такого рода угрозы найдут отражение, но все, что хоть как-то можно отнести к ним, это расплывчатая формулировка про актуальность угроз нарушения целостности (подмены) биометрических персональных данных. Настолько абстрактное понятие, что даже непонятно, о чем идет речь - о deepfake или о подмене свертки биометрического фактора?

Была надежда, что в 321-м приказе МинЦифры или в МР-4 Банка России включат раздел про нейтрализацию таких угроз, но увы. И эти документы оказались далеки от прикладных атак, концентрируясь либо на применении криптографии, либо на применении сертифицированной ОС, МСЭ и антивируса, напрочь забыв даже про защитные меры из 21-го приказа ФСТЭК по защите ИСПДн. Последний, перекрывая по своему содержанию и МР-4 и приказ №321, тоже ни слова не говорит о том, как. бороться с deepfake.

Самое неприятное, что на различных мероприятиях или в соцсетях, где присутствуют участники процесса, связанного с ЕБС, упорно обходят молчанием эту тему, даже если им задаешь напрямую вопрос о том, как бороться с этой проблемой. Хоть какой-то ответ я нашел в одной презентации "Центра речевых технологий", чьи технологии используются в ЕБС, например, у того же Банка "Открытие" и ряда других (решение VoiceKey.INSPECTOR). Правда, используются они при сборе биометрии, а проблема с deepfake возникает на этапе ее проверки в режиме повседневной эксплуатации.

Если посмотреть на классический жизненный цикл биометрической, то он в обязательном порядке должен содержать этап проверки "живости", без которого биометрия не имеет никакой ценности, несмотря на использование СКЗИ класса КВ или даже КА.


В своих материалах ЦРТ приводит методы проверки живости для изображения лица, как биометрического признака:

и для голоса, как второго биометрического признака:

Но какие из этих методов реализованы в ЕБС не совсем понятно. В описании того же "Ключа" от Ростелоекома говорится о liveness detection, но без каких-либо деталей и уточнений. А судя по презентациям отдельных банков, которые бодро отрапортовали о том, что они не только интегрировались с ЕБС, но и внедряют уже биометрию в свои банковские процессы, далеко не все понимают угрозу deepfake и борются с ней. Например, один из банков предлагает возможность перевода денег без указания номера карты или телефона, "просто сфотографировав получателя". В данной схеме даже liveness detection никакого нет - работа со статическим биометрическим признаком, который подделать ничего не стоит.

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

Если посмотреть на обратную сторону, на то, что можно противопоставить deepfake, то тут исследований не так уж и много. На последних крупных конференциях по ИБ я вспомнил только одно. А вот с готовыми решениями по этой теме, что-то не густо. Что-то встроено в сами биометрические решения, но не во все. В отличие от идентификации фальшивых изображений (OZ Forensics) или собственно самой биометрической идентификации. И тут остается полагаться на здравый смысл безопасников, которые будут следовать не только нормативных актам регуляторов, но и самостоятельно задавать вопросы производителям внедряемых решений о том, как те борятся с deepfake. Ибо цена ошибки достаточно высока, а ответственности за взлом биометрической системы регуляторы не несут; как и сами вендоры, которые продают свою решения по принципу "AS IS". Как минимум, стоит посмотреть в сторону решений по многофакторной аутентификации, которые могут частично. нивелировать проблемы, связанные с низкой защищенностью биометрии.

Отдельная тема, которая пока не имеет какого-то решения, это проведение экспертизы в случае конфликтных ситуаций, которые однозначно появляются в случае обхода биометрии злоумышленниками. Это что-то сродни фототехнической криминалистической экспертизе, но для биометрических признаков (голоса и видео). Не знаю, насколько в России есть у кого-то опыт именно в этой части (хотя вот вчерашний пример). Но при внедрении биометрии, стоит держать в голове этот вопрос и иметь какой-то ответ на него. 

02.09.2019

От. 2,5 до 5 часов за смену тратят аналитики SOC на работу с инцидентами

В августе я уже делал обзор двух отчетов, SANS и Exabeam, по центрам мониторинга ИБ (SOCам) и вот в руки попало еще один - от CriticalStart. В нем есть несколько интересных цифр о том, как аналитики SOC занимаются своей ежедневной деятельностью. Например, часто звучащий вопрос о том, сколько в среднем инцидентов ИБ в день, попадает в SOC? Я пару лет назад уже писал об этом, давая ссылки на конкретные организации, которые делились своей статистикой. В отчете CriticalStart, который стал результатом опроса около 50 различных корпоративных и аутсорсинговых SOC и MDR, приводится некая средняя цифра - 70% аналитиков расследует более 10 инцидентов в день на каждого. Достаточно большое число; особенно удивляет, что 7% аналитиков более 50 инцидентов в день отрабатывает, то есть по инциденту за 10 минут (!).


Понятно, что отчет показывает среднюю температуру по больнице, но в целом получается, что 95% инцидентов расследуется максимум за 20 минут. Если немного усреднить первые два параметра, то получается, что аналитики тратят на исследования инцидентов от 2,5 до 5 часов за смену (в прошлом году я писал про другое исследование по распределению времени у аналитиков SOC).


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


А вот дальше интересно. На вопрос, что вы делаете с большим количеством сигналов тревоги, 39% аналитиков... игнорируют некоторые категории алертов! Прекрасное решение :-) 38% отключают регистрацию большого числа событий. Также 38% (данный вопрос подразумевал множественный выбор) просто нанимает большее число аналитиков.


В прошлом году у 70% аналитиков основной целью называлось анализ и снижение числа угроз. В этом году этот показатель хоть и остался на первом месте, но снизился до 41%. А высвободившиеся 30% ушли на "тиранию алертов", то есть снижение времени на борьбу с ними (пятикратный рост по сравнению с прошлым годом) и расследование как можно большего их числа (трехкратный рост).


В эпоху мессенджеров, чатботов и средств унифицированных коммуникаций, самым популярным средством коммуникаций с клиентами/пользователями по-прежнему остается электронная почта и портал. Еще 40% аналитиков используют мобильные приложения.


28.08.2019

Уберизация SOCов

Несмотря на то, что Uber появился относительно недавно, бизнес-модель этой компании заслужила отдельного названия, "уберизация", о которой я и хотел сегодня поговорить применительно к SOCам. Но будем патриотами, и заменим в рамках обсуждения Uber на более привычный многим Яндекс (на суть это не влияет).

Итак, представим, что нам нужно добраться из точки А в точку Б на автомобиле. У нас есть три возможности:
  • Собственный автомобиль. Удобный и полностью контролируемый способ передвижения. Но и самый дорогой из всех.
  • Аренда автомобиля, например, через Яндекс.Драйв. Этот вариант дешевле собственного авто, но бензин вы оплачиваете сами и водить вы будете самостоятельно (или надо нанимать водителя). Яндекс.Драйв предоставляет. вам только средство передвижения, не более того. Все остальное - ваша прерогатива.
  • Услуга такси, например, через Яндекс.Такси. Вы просто заказываете такси, которое приезжает и отвозит вас, куда скажете. Вам ничего не надо делать, только сделать заказ и оплатить его.
Если посмотреть на российский рынок центров мониторинга ИБ, то у вас только две альтернативы, - построить SOC самостоятельно или заказать услугу в аутсорсинговом SOCе. В мире же рынок SOCов выглядит немного иначе - помимо указанных двух вариантов предоставляется еще и третий, аналогичный Яндекс.Драйву. Вы обращаетесь к компании, которая сдает вам платформу для управления SOCами в аренду. То есть вам не надо покупать SIEM, IRP/SOAR, TIP и другой инструментарий SOC, но при этом аналитики должны быть ваши, как и выстроенные процессы, playbook, runbook и т.п.

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

Если возвращаться ко всем трем вариантам, то у каждого из них есть свои преимущества и свои недостатки. Но в вариантах "Яндекс.Драйва" и "Яндекс.Такси" важно понимать, что услуга может быть оказана по-разному. Вспомним,  что у Яндекса есть несколько пакетов оказания услуги - Эконом, Комфорт, Комфорт+, Бизнес, Премиум. Многие берут первое из-за экономии. Но тогда без претензий по качеству. “Дорогу покажешь, дарагой” - такого уже почти нет (благодаря Яндекс.Картам), но слушать радио “Восток” всю дорогу и смотреть как водила чатится с кем-то, попутно еще и руля, стремно. Стоит ли экономия таких рисков?

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


Опыт работы не требуется! И вот такие люди будут заниматься мониторингом вашей ИБ. А вы ведь ждете от них квалификации, многолетнего опыта, выдачи вам рекомендаций, а не тупого следования вашим просьбам и распоряжениям (это, кстати, касается и проектировщиков SOC). Когда происходит инцидент ваш аутсорсер будет ждать, когда произойдет компрометация и тогда будет реагировать, или он обладает offensive-навыками и может предсказать, что будет делать хакер дальше, и сможет вовремя остановить его? За что вы в итоге платите - за профессиональный центр по ИБ или за дорогую справочную службу? 

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

Может тогда стоит посмотреть в сторону Яндекс.Драйва облачной платформы SOC или построения собственного SOC? Я ни в коем случае не призываю отказываться от аутсорсинга SOC и не говорю, что это все профанация (тем более, что Cisco сама оказывает такие услуги, но не в России). Просто стоит все очень серьезно взвесить, задумывась о передаче SOC в чужие руки (не забыв задать и ранее мной описанные вопросы). И только потом принимать взвешенное решение.

27.08.2019

Как НЕ надо выбирать SIEM?

На сочинском "Коде ИБ. Профи" (кстати, на прошлой неделе стали доступны все презентации и записи с него) у Льва Палея был мастер-класс о том, как выбирать средства защиты, где среди рассматриваемых в качестве примера решений были системы управления событиями ИБ (SIEM). И у меня в загашнике давно был черновик заметки на схожую тему. Но я не стану отнимать хлеб у Льва (тем более, что у него мастер-класс был практический - с заданиями и их разбором) и напишу о том, как НЕ надо выбирать SIEM :-) Тем более, что за последнее время, в ряде проектов по SOC, в которых я участвую в России и странах СНГ, накопились определенные наблюдения, которые и станут основой этой заметки.

Итак, вы составили список из 30-ти названий SIEM, представленных на рынке (а их точно не меньше этого числа), составили табличку с ключевыми функциями, которые вам якобы нужны, проставили по ним веса и сидите заполняете, обращаясь к разным вендорам по поводу того или иного пункта или наняли интегратора, который это сделает за долю малую, а может и вовсе используете уже кем-то подготовленные таблички. Но для начала, я бы посмотрел на нижеприведенный список из двух десятков пунктов, который показывает, чего не надо делать, выбирая SIEM.

Не выбирайте SIEM, потому что это модно

Ну это вроде и так понятно. Выбирайте не то, что модно, а то, что нужно. Это простая истина применима не только к SIEM, но и вообще к любому хайпу - от SOCа до блокчейна, от WAF до CASB. Для этого вам, правда, нужно знать, что нужно :-) А поняв это, вы поймете, как этого достичь и, только потом, сможете определиться с инструментарием для этого.

Не выбирайте SIEM под требования регуляторов

Регуляторы, и ФСТЭК, и ФСБ, и ЦБ, сегодня много говорят про необходимость непрерывного мониторинга ИБ и устанавливают требования к решениям этого класса. Особенно важно это при интеграции вашей инфраструктуры мониторинга с той же ГосСОПКА или ФинЦЕРТом. Но... обратите внимание, что иногда гораздо проще и лучше - строить систему мониторинга такой, какой ее хотите видеть вы (исходя из ваших условий), а на стыке с ГосСОПКОЙ или ФинЦЕРТом поставить какой-нибудь шлюз, который будет посредником между вами и регулятором и просто передавать нужные данные туда и обратно. Не ведитесь на рекламу ряда отечественных вендоров, которые говорят, что у них встроенная поддержка взаимодействия с ГосСОПКОЙ "из коробки". Зато другой функционал, который вам и нужен в первую очередь, там может быть не очень. В конце концов, если выбранный вами SIEM из-за "печати" "Approved by GosSOPKA" не сможет видеть инцидентов, то и отдавать вам будет нечего. А вот функция "генерация отчетов о соответствии требованиям регуляторов" очень неплоха; главное, чтобы эти отчеты были по регуляторике, которая применима к вам. В любом случае помните, решение по безопасности нужно для обеспечения вашей безопасности, а не требований регуляторов.

Не выбирайте SIEM, потому что вы строите SOC

Все умные люди, говоря о SOCах, обычно делают знак равенства между двумя фразами "имею SOC" и "имею SIEM", но это не совсем так. Достаточно просто вспомнить, что вы можете аутсорсить свой SOC у внешнего поставщика услуг, к которому вы предъявляете требования по скорости реакции, гарантиям, охвату вашей инфраструктуры, но точно не по тому инструментарию, который он должен использовать. Это его прерогатива, раз уж вы выбрали его из множества аутсорсинговых SOCов; доверьте ему и выбор SIEM. Вы вообще можете не знать, какой SIEM у вашего SOC-as-a-Service; вы же платите за услугу с понятными входными и выходными данными и вам не так уж и важно, что у нее внутри.

Не выбирайте SIEM, потому что он в правом верхнем углу магического квадранта

Обратите внимание, я не говорю, не выбирайте SIEM из этого угла квадранта. Я говорю, не выбирайте, потому что он там. Чувствуете разницу? Если SIEM попал в этот угол, значит он достаточно хорош (а вы же хотите все самое лучшее, не так ли?). Но вам нужна не медаль на грудь и не "мировой рекорд",  а решение стоящих перед вами задач. Возможно вас устроит что-то более простое и не столь дорогое? Возможно 50% функционала самого крутого SIEM в мире вам просто не нужны? Так зачем за нее платить (а также за специалистов, которые знают как работать с самым крутым SIEM в мире)?

Не выбирайте SIEM, потому что вас зачморили коллеги и говорят вам "Ты что, с Урала?"

Помните советский фильм "Самая обязательная и привлекательная"? Там был эпизод, где главную героиню привели к, как сейчас модно говорить, байеру, который предлагал то одну модную штуку, то другую, то третью. А на изумленный вопрос героини "А зачем это?", ее сравнили с деревенщиной, припечатав, ставшим классикой, "Ты что, с Урала?" Не выбирайте конкретный SIEM и вообще SIEM, потому что это модно и у всех ваших коллег это есть.

Не выбирайте SIEM, потому что вам надо выстроить сбор логов

Для сбора логов выбирайте решение соответствующего класса -  SIEM тут будет избыточен. Если, конечно, у вас нет четкого плана продержаться на вашем текущем месте еще лет пять, на которые у вас уже есть стратегия развернуть полноценный мониторинг ИБ, с долговременным хранением, корелляцией, оркестрацией, контролем поведения, анализом сетевого трафика и т.п. Если вы не имеете персонала, который будет пялиться в монитор SIEM круглые сутки или хотя бы в режиме 5х8 или если у вас нет задачи оперативного реагирования на инциденты (а ее может и не быть), то зачем вам SIEM? Ограничьтесь обычным LM-решением.

Не выбирайте SIEM по фичам и обещаниям вендора

Часто, смотря материалы вендоров, мы попадаем в ловушку "kill feature", которая означает, что у продукта есть какая-то классная фишка и вокруг нее выстроен процесс продаж. Помните анекдот про студента, сдающего экзамен по зоологии, который успел выучить только билет про блох? Вот так и тут. Например, у SIEM классная фишка - он по умолчанию интегрируется с ГосСОПКА, а вы, как субъект КИИ обязаны это сделать. И вот вокруг этого начинаются танцы продаванов с бубном, уводя вас в сторону от такой, например, проблемы как низкое количество событий в секунду (EPS), которое может обработать одна нода SIEM. И чтобы работать в вашей организации вам нужно поставить 4 ноды, в то время как у другого SIEM, у которого нет встроенной "килфичи" работы с ГосСОПКОЙ, достаточно всего одной ноды, да еще и с запасом.

Или другой пример. Продавец SIEM вам говорит, что вы сэкономите, купив его решение, так как у него SIEM и SOAR и IRP - все в одном флаконе. А вы же понимаете, что хотя бы IRP, но вам нужна (а может и SOAR вместо IRP). Вы берете этот SIEM, но потом оказывается, что он не работает в multi-tenant архитектуре, а у вас холдинг и каждому предприятию нужен свой "кусок". Или multi-tenant поддерживается, но нет иерархии SIEM "главный-подчиненный", которая вам нужна для охвата 9 часовых поясов и размещения нескольких центров мониторинга по России и странам СНГ, в которых у вас размещены точки присутствия. Смотрите сначала на архитектуру, а потом на конкретные функции, тем более обещаемые.

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

Не выбирайте SIEM, потому что он поддерживает искусственный интеллект

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

От ответов на них зависит, понимает ли вендор, что такое ИИ и машинное обучение в частности или нет? И стоит ли вестись на всю эту хайповую тему с магической заменой кучи конструкций "IF THEN" в коде или корреляционном правиле на словосочетания "искусственный интеллект", "нейросеть" или "глубокое обучение". Для того, чтобы назвать атакой 3+ попыток неудачного входа в систему с одной учетки за короткий интервал времени, много ума не надо. В отличие от идентификации кражи учетной записи по определению нетипичного места входа в систему, опираясь на результаты кластеризации таких попыток за большой интервал предыдущего времени, опираясь именно на ваши данные. ИИ в SIEM есть и он может решать свои задачи - вопрос в том, знаете ли, как выжать максимум из него, и знает ли это локальный поставщик?

Не выбирайте SIEM, потому что у него отличная корреляция

Это древняя песня, которую я помню еще с конца 90-х годов, когда внедрял свой первый SIEM в одном из национальных банков на постсоветском пространстве. Заказчик тогда тоже купился на рассказ про корреляцию и вот это вот все, но реальность была совсем другой. Несмотря на наличие правил корреляции "из коробки", которыми так кичился вендор, пришлось писать много своей логики, отличавшейся от задумки производителя. И это при том, что число источников, подключаемых к SIEM, было на порядки меньше, чем у современных решений по мониторингу. По рынку ходит цифра, что сколько бы правил корреляции в вашем SIEM не было, только 20% их них можно применять безболезненно. Поэтому надо четко осознавать, что писать правила корреляции под ваши use case придется вам (или внешнему интегратору за дополнительные деньги) и все слова о "уникальной системе корреляции" превратятся в реальности в тыкву.

Не выбирайте SIEM, потому что он имеет универсальный коннектор ко всему

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

Не выбирайте SIEM, у которого нет плана развития

Я уже писал выше, что надо проверять все заявленные и нужные вам фичи в рамках пилота. Не менее важно, чтобы у SIEMа был четкий план развития (с соответствующими подтверждениями), который учитывает тенденции рынка и вашу стратегию развития. Возможности масштабирования, рост производительности, новые коннекторы для интеграция с различными решениями (не забывайте учитывать все скрытые затраты такой интеграции, которые лягут тяжким бременем на ваши плечи), поддержка каких-либо стандартов (от STIX/TAXII и MITRE ATT&CK до ГосСОПКИ и ФинЦЕРТа), новые функциональные модули, новые корреляционные возможности, обнаружение новых атак и т.п. Вроде бы очевидные вещи, но часто бывает так, что продукт берется ради сиюминутных задач, а потом оказывается, что вендор и не развивает свой продукт, делая только косметические правки, оставаясь на позади конкурентов. Такое было в свое время с netForensics - лидером рынка SIEMов, который сдулся и прекратил свое существование. Кстати, план развития тоже не гарантия, что продукт будет развиваться согласно ему. Но это уже ситуация, которая не предсказуема и с которой приходится просто мириться, на ходу меняя решение на другое.

И уточните, как вендор будет учитывать ваши новые хотелки? Например, у иностранных вендоров есть такое понятие как "бизнес-кейс", который имеет вполне конкретное (у каждого свое) денежное выражение. Вендор включит ту или иную фичу в план разработки, когда один или несколько заказчиков, готовы будут заплатить в краткосрочной перспективе за эту функцию. Если вы очень маленький заказчик, то даже очень важную фичу вам писать никто не будет, хотя в план (дальний) могут и включить. У российских вендоров SIEM ситуация чуть проще - их обороты гораздо меньше оборотов любого из их заказчиков и поэтому они стараются прислушиваться к мнению "народа" и оперативно реализовывать все новые "хотелки". Но все-таки лучше этот вопрос уточнить на берегу, перед окончательным принятием решения.

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

Не выбирайте SIEM, потому что у него харизматичный лидер с горящими глазами

Проверьте, что за этим лидером есть команда, которая готова развивать и поддерживать продукт. Извините, никто не вечен и все может произойти в жизни - от рождения детей до попадания в ДТП на "джихад-такси" Яндекс.Такси. Горящие глаза и делающие руки - это классно, но любая разработка - это процесс, который не должен зависеть от одного винтика, вынув который, все ломается. К иностранным вендорам этот совет малоприменим, а вот в России такие случаи бывают. 

Не выбирайте SIEM, потому что он поддерживает ваши средства защиты периметра

Первые SIEM появились в конце 90-х годов, чтобы сократить число ложных срабатываний у систем обнаружения вторжений и межсетевых экранов. С тех пор число источников событий безопасности и объем этих событий возросли многократно. Насколько выбираемый вами SIEM способен работать с такими источниками? DLP? CASB? AWS CloudTrail? Azure Monitor? UEBA? EDR? HRM? СКУД? SCM? ERP? СУБД? Иные бизнес-системы?

Не выбирайте SIEM, у которого нет реагирования

Вам для чего нужен мониторинг ИБ? Чтобы видеть атаки или чтобы их отражать или купировать последствия? Вот так и SIEM нужен не только для того, чтобы видеть как можно больше, но и для того, чтобы оперативно реагировать на обнаруженное. Поэтому неплохо бы, чтобы выбираемый вами SIEM знал как реагировать и, желательно, применительно к вашим же средствами защиты (напрямую, через скрипты или через какой-либо SOAR). 

Не выбирайте SIEM, если не знаете, где взять людей для работы с ним

Очевидно.

Не выбирайте SIEM, если у вас нет процесса мониторинга ИБ

SIEM - это инструмент, который позволяет вам автоматизировать процесс мониторинга ИБ. С его помощью вы сможете собирать нужные данные с нужных источников, производить над ними нужную обработку и анализ, сохранять и принимать те или иные решения. Но для эффективного использования этого инструмента, у вас должен быть сначала выстроен процесс. Вы должны четко понимать:
  • Что вы хотите собирать?
  • Где это находится?
  • Кто отвечает за эти источники?
  • Как и в каком формате хранятся эти данные?
  • Как отдаются эти данные?
  • Что надо предпринять, чтобы забрать эти данные?
  • Как обеспечивается целостность и непротиворечивость этих данных?
  • Что вы будете делать с этими данными?
  • Сколько надо хранить эти данные?
  • Какие виды анализа вы будете проводить над этими данными? 
  • Как вы управляете временными метками в вашей инфраструктуре?
  • Кто имеет доступ к этим данным?
  • Насколько структурированы эти данные?
Вот только небольшой список вопросов, на которые надо получить ответы до начала выбора SIEM.

Не выбирайте SIEM с непонятным TCO

По результатам общения с вендором вам все понравилось и вы готовы заплатить кругленькую сумму за систему мониторинга событий ИБ. Но... посчитайте TCO для него. На тестах оказалось, что вам нужна иная конфигурация, чем вы изначально рассчитывали? Вам нужна лицензия на большее число EPS, чем думали изначально? Выбранное или рекомендованное вендором железо "не тянет" и требуется более мощное? Ваша архитектура потребовала новых коллекторов? Курсы обучения по SIEM в России не проводятся и надо ехать в Европу (а вас по приезду развернули, потому что вы под санкциями, несмотря на полную предоплату, - реальный случай)? Вы не учли размер хранилища под собираемые события ИБ (кстати, вы в курсе, что будет, если на ваш SIEM подадут больше EPS, чем надо, или база переполнится?)? Вы не заложили стоимость написания коннекторов под ваши специфические источники? Есть вендора, которые предлагают к своим решениям полную калькуляцию всех статей расходов, которые могут понадобиться для развертывания и эксплуатации SIEM с расчетом на 12, 24 или даже 36 месяцев. Ваш вендор вам такое может сделать с учетом вертикального (число EPS) и горизонтального масштабирования (число и типы источников)?

 Не выбирайте SIEM-вендора - выбирайте SIEM-партнера

В отличие от МСЭ, EDR, NGIPS или SIG, решение по мониторингу событий ИБ требует гораздо более тесного взаимодействия с его производителем (тоже можно сказать и про DLP, и про другие прикладные ИБ-игрушки). Это не коробка, которая работает по принципу "поставил и забыл". Работы с новыми источниками, понимание методов анализа, разработка правил корреляции, масштабирование, расчет TCO, обучение модели ML... Да мало ли еще тем, по которым вы будете постоянно общаться с производителем вашего SIEM. Готов ли вендор к этому? Готовы ли вы к этому?

 Не выбирайте SIEM как самодостаточную систему

Как вы будете использовать SIEM? Это важный вопрос. Не для чего, а именно как. Вы планируете ее использовать как самодостаточное решение или интегрировать с IRP/SOAR, TIP, NTA, UEBA, EDR, CASB, CMDB и другими решениями, которые вместе позволят выстроить вам цикл управления инцидентами в вашей инфраструктуре? Если второе, то смотрите на то, с чем и как может интегрироваться выбираемый вами SIEM.

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

26.08.2019

О сертификации NGFW - текущий статус

В январе я написал заметку о том, что согласно новым подходам ФСТЭК, сертифицировать многие зарубежные средства защиты будет скоро невозможно. В апреле я продолжил тему, когда ФСТЭК выпустила письмо, требующее до 1-го января 2020 года (осталось 4 месяца) обновить все действующие сертификаты и подтвердить соответствие требованиям по доверию. И вот сейчас, спустя 4 месяца после последней заметки я хотел бы обновить тему и написать о текущем статусе сертификации NGFW.

Несмотря на кочующий из доклада в доклада, из статьи в статью, тезис о том, что 100% организаций имеют межсетевой экран и антивирус, в реальности все-таки речь обычно идет не об обычном МСЭ, а о межсетевом экране следующего поколения (NGFW), задача которого не только фильтровать трафик на прикладном уровне, но и распознавать приложения и осуществляемые внутри них действия, применяя к ним соответствующие политики, блокировать атаки, нейтрализовывать вредоносный код, предоставлять функцию VPN и контролировать доступ в Интернет, беря на себя функцию прокси. Это типовой функционал NGFW, который в зависимости от вендора расширяется песочницами, CASB, глубокой DNS-инспекцией, отражением DDoS-атак, WAF, сканером уязвимостей и т.п.

Как я уже писал в январе, чтобы получить по новым требованиям ФСТЭК сертификат на такой "комбайн", необходимо проверить весь функционал (хорошо, что ФСТЭК пока не требует, чтобы в NGFW функция VPN строилась на базе сертифицированных СКЗИ). Прошли те времена (хотя иногда раз-раз, да проскользнет мимо ФСТЭК такой сертификат) когда можно было получить для NGFW сертификат только по РД к МСЭ. Сегодня будь добр сертифицировать все - и антивирус (на соответствующий РД), и систему обнаружения вторжений, и WAF. А для того, для чего у ФСТЭК нет РД, будь добр прописывай проверку этих функций и среды функционирования в задание по безопасности. Весь непроверяемый функционал должен быть удален. Правда, в этом случае уже не приходится говорить о продукте класса NG, но это уже частности (кому-то важна именно бумажка, а не чистота процесса).


Все это была прелюдия, о которой я уже писал. Теперь пора посмотреть, что происходит у нас в части сертификации популярных в России NGFW по линии ФСТЭК (по линии ФСБ это и в голову никому не приходит). Не слукавлю, если скажу, что 99% всех NGFW, которые продаются в России, имеют иностранное происхождение. Специально не буду называть вендоров, но думаю, что их все и так знают. Так вот, общаясь с коллегами из всех этих компаний, но не называя имен, у меня сложилась сейчас следующая картина по состоянию сертификаций из NGFW:
  • Один вендор вырезал из своего продукта часть основного (например, обнаружение приложений) и управляющего функционала (например, поддержку SSL, что поставило вопрос о работе с HTTPS, управлении по HTTPS и получении обновлений по нему же). В итоге NGFW превратился в обычный МСЭ (без приставки NG).
  • Другой вендор, имея на NGFW-платформе, несколько вариантов ПО, сертифицирует только тот, который содержит только функционал МСЭ. Даже СОВ уже сертифицировать нельзя (это касается всех производителей), так как они все обновляются из-за рубежа, что по версии регулятора является угрозой ИБ.
  • Третий вендор пытается запустить для России разработку особой ветки своего продукта, в котором от NGFW останется только FW, превратив его, да, в гораздо более удобный, чем российские МСЭ, продукт, но все-таки это уже не решение класса NG.
  • Кто-то пытается скрыть свой NGFW в корпусе другого продукта, в котором еще установлен российский VPN, что якобы должно сделать продукт российским и обойти преграды при сертификации. Но судя по отсутствию сертификата, этот фокус тоже не прошел.
  • Последний из иностранных вендоров и вовсе отказался от сертификации, понимая всю бесперспективность этого процесса для своего продукта.
Что в итоге? Полное отсутствие популярных сертифицированных NGFW на российском рынке, каковая тенденция сохранится и в будущем. И дальше у иностранного вендора два пути. Первый - продолжать сертифицировать свои решения только как МСЭ (если вендор в состояния представить продукт в варианте "нестареющей классики" без всяких модных технологий, упомянутых выше), но не выше 6-го класса по РД на МСЭ. Нужен ли будет кому-то такой сертификат - большой вопрос. Вариант второй - забить на сертификацию. И что-то по общению с коллегами я вижу, что многие стали склоняться к этому варианту развития событий. Слишком большие усилия необходимо предпринять с обеих сторон (и в штаб-квартире, и в России), чтобы получить минимально возможный класс. Овчинка не стоит выделки.

А заказчикам стоит задуматься, им нужны шашечки или ехать? 

ЗЫ. Кстати, с сертификацией даже на 6-й класс сейчас тоже немало интересного происходит. Прописанный в требованиях ФСТЭК к доверию фаззинг - это то еще приключение, "карта" которого не понятна до конца даже регулятору, не говоря уже об испытательных лабораториях и заявителях. 

09.08.2019

ИБ-фреймворки: какие бывают и зачем нужны?

На прошедшем "Код ИБ. Профи" еще одной активно обсуждаемой темой стали фреймворки, - о них рассказывал Илья Борисов, делавший обзор существующих распространенных фреймворков, и Андрей Прозоров, посвятивший свое выступление ISO 27001. Я решил тоже не отставать от коллег и поделиться своим взглядом на эту тему.

Я бы выделил три набора фреймворков, различающихся по своим задачам и цели применения - контрольные (от английского control, которое по-русски звучи длиннее - "мера защиты"), программные и рисковые. Большинство знакомо с первой категорией, которые представлены не только иностранными примерами - NIST SP800-53, горячая двадцатка CIS (бывший SANS Top20), а также отечественные документы ФСТЭК (приказы 17/21/31/239) и Банка России (ГОСТ 57580.1).


Эти фреймворки нужны для решения важных "технических" задач по ИБ:

  • определение базового набора защитных мер, подходящих конкретной организации
  • оценка текущего состояния уровня технической защиты информации
  • приоритезации защитных мероприятий и составления дорожной карты развития.
Отличительной особенностью хорошего фреймворка являются группирование (тут почти все упомянутые выше примеры на высоте) и приоритезация защитных мер. А вот с последним пунктом в документах ЦБ и ФСТЭК есть сложности. Каталоги защитных мер обширны и насчитывают около двух сотен наименований, но как из них выбрать те, что дают максимальный эффект, особенно в условиях нехватки ресурсов на внедрение, непонятно. У уже не раз мной описанных австралийских требований по ИБ, например, есть такая приоритезация. Есть Топ4, Топ8 и Топ35 защитных мер, которые позволяют достичь 80%, 90% и 98% результата. Аналогичная функция есть и у NIST SP800-53 - против каждой защитной меры в поле "Приоритет" стоит значение от 0 до 3, означающих важность реализуемого мероприятия.


"Программные" фреймворки предназначены для:

  • оценки текущего состояния программы ИБ на предприятии
  • построения всесторонней (хотя это все-таки не совсем так) программы ИБ
  • измерения зрелости программы ИБ и обеспечения возможности бенчмаркинга (сравнения себя с другими по отрасли).
Самым известным в Евразии и популярным фреймворком является ISO 27001, а в Северной Америке - NIST CSF. Первый интересен тем, что у него множество расширений под различные задачи. Например, есть ISO 27019 для энергетики, 27011 для телекома или ISO 27701 (совсем свежий стандарт) для персональных данных. В отличие от технических мер защиты, в ISO 27001 или NIST CSF меры носят более высокоуровневый характер - взаимоотношение с поставщиками, выбор средств защиты, управление активами, работа с персоналом, повышение осведомленности, управление инцидентами и т.п.





Часть этих мероприятий есть и в приказах ФСТЭК, но они все-таки ориентированы именно на техническую составляющую, чем на выстраивание программы. С ними можно построить и некоторое подобие программы, но для этого надо иметь достаточно большой опыт работы с документами ФСТЭК, - новичку это не удастся - многие пункты понятным далеко не всем. Да и процесс оценки текущего состояния или измерения зрелости программы ИБ по нормативным актам ФСТЭК невозможен. Я уже писал о возможных вариантах решения этой задачи, но они должны исходить от регулятора. ЦБ эту задачу решает лучше - у них скоро должен появиться еще один стандарт как раз по управлению ИБ на предприятию, который позволит и текущее состояние программы ИБ оценивать, и ее зрелость. 

Если первые два типа фреймворков хорошо дополняют друг друга, то третий имеет смысл применять только в очень зрелых компаниях, которые действительно понимают, что такое риски ИБ и знают как считать вероятность и ущерб (а это то еще приключение). В целом данный тип фреймворка, ярким представителем которого является FAIR или серия NIST, позволяет:
  • идентифицировать и измерять риски ИБ
  • приоритезировать защитные мероприятия
  • определить ключевые этапы управления рисками
  • структурировать программу управления рисками.
Резюмируя, хорошие фреймворки, опираясь на опыт уже множества внедрений и набитых шишек, позволяют сэкономить вам время и нервы, следуя описанному в фреймворке алгоритмы построения системы ИБ. Но не стоит думать, что вам нужен именно один из перечисленных выше фреймворков. По статистике Gartner 20% компаний разрабатывают собственный фреймворк, еще 16% дорабатывают существующие, а 20% - комбинируют компоненты из разных фреймворков. Еще 21% вообще их не используют вовсе, а 23% используют стандартные фреймворки (NIST CSF, ITIL и ISO 27001 входят в тройку самых популярных по версии NIST). 



Поэтому выбирайте то, что лучше подходит именно вам и именно под ваши задачи. Если вы государственный орган, то выбор у вас не богат - документы ФСТЭК и, возможно, ГОСТ Р ИСО/МЭК 27001 (сейчас как раз через ТК 362 проходит новая версия этого стандарта). Для финансовых организаций обойти ГОСТ 57580.1 (и последующие ГОСТы от ТК122) будет непросто. Остальные же имеют свободу выбора и я бы (если бы я выбирал), остановился бы на NIST CSF и NIST SP800-53. А если бы передо мной стояла задача выбора только контрольного фреймворка, то CIS Top20 у меня был бы на первом месте (или австралийский перечень).

ЗЫ. Практические аспекты по этим фреймворкам можно посмотреть в докладах с "Кода ИБ. Профи", которые скоро будут доступны на сайте (по подписке).

08.08.2019

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

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

Платежных приложения Apple Pay и облачные ДБО должны быть сертифицированы

3-го июля был подписан 173-й ФЗ "О внесении изменений в Федеральный закон "О национальной платежной системе" и отдельные законодательные акты Российской Федерации", который среди прочего определяет ряд новых терминов и среди них "платежное приложение", "поставщик платежного приложения" и "платежный агрегатор".


К двум новым субъектам ФЗ-161 теперь предъявляются новые требования в области кибербезопасности. Платежные приложения, которые используют операторы по переводу денежных средств должны соответствовать требованиям к защите информации при осуществлении переводов денежных средств. Можно было бы предположить, что под термин "платежное поручение" попадут и системы ДБО или "клиент-банк", но в законе и в своих разъяснениях Банк России дает понять, что речь идет только о тех приложениях, которые разработаны организациями, которые привлекаются кредитной организацией для проведения платежей. В пояснительной записке в качестве примера приводятся имена Apple Pay, Samsung Pay и MirPay. Опираясь на определение, я бы еще отнес к такого рода система и облачные ДБО, которые используют некоторые банки сегодня. Вообще это странная формулировка, так как требования 27-й статьи ФЗ-161 применяются к участникам НПС, а не к приложениям. Думаю, что тут речь идет о последних правках в 382-П, которые требуют сертификации платежных приложений на отсутствие НДВ или выполнения в их отношении анализа защищенности в соответствие с ОУД4.

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

Те, кто работает с МПС, обязаны выполнять требования ФСТЭК

2-го августа был принят 264-й ФЗ "Федеральный закон от 02.08.2019 N 264-ФЗ "О внесении изменений в Федеральный закон "О национальной платежной системе" и Федеральный закон "О Центральном банке Российской Федерации (Банке России)". Он направлен "против" иностранных платежных систем, заставляя их соблюдать требования, применяющиеся к российским платежным системам. Среди прочего в законе есть такой пункт: "Информационные системы операторов по переводу денежных средств, с использованием которых осуществляется прием электронных средств платежа и обмен информацией с иностранными поставщиками платежных услуг, информационные системы операторов услуг информационного обмена, с использованием которых осуществляется взаимодействие с иностранными поставщиками платежных услуг, должны соответствовать требованиям по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации." Иными словами, те системы кредитных организаций, которые взаимодействуют с иностранными платежными системами должны выполнять требования 235-го и 239-го приказов ФСТЭК независимо от результатов категорирования. Кстати, до 1-го сентября 2019-го года в ФСТЭК надо отправить перечень объектов КИИ.

Также требования Банка России по защите информации должны соблюдать операторы услуг информационного обмена (новая сущность в законе), операторы по переводу денежных средств при приеме электронных средств платежа и иностранные поставщики платежных услуг.

Кроме того, операторы иностранных платежных систем должны иметь установленные правила защиты информации, а Банк России имеет право установить требования по защите информации при использовании трансграничного перевода денежных средств. Вспоминая, как Банк России "рисовал" себе картинку про НПС, можно увидеть, что последним пунктом ЦБ как раз закрыл последний ранее незакрытый кусок в виде SWIFT (когда выпустит требования).


Профиль защиты для платежных приложений

В 382-П, 683-П, 684-П, а также ГОСТ 57580.1 было требование о том, что платежные приложения должны быть сертифицированы в ФСТЭК по требованиям безопасности или в отношении которых проведен анализ уязвимостей на соответствие ОУД4. Вот собственно требования, по которым должна проходить сертификация, и прописаны в этом почти 150-тистраничном документе, проект которого выложен на сайте ТК122 (доступен только для членов технического комитета по стандартизации). Я не буду раскрывать подробности этого документа, но работа у разработчиков и испытательных лабораторий предстоит непростая и к 1-му января 2020-го года (этот срок прописан, как минимум, в 382-П) они точно не успеют провести сертификацию (там есть и иные препоны, связанные уже с самой системой сертификации ФСТЭК). Поэтому сейчас стоило бы воспользоваться оставшимися пятью месяцами и начал бы проводить анализ уязвимостей по ОУД4 (или требовать этого от разработчиков).

Вот такая тройка нормативных актов. И пусть на улице холодновато (в Москве, как минимум), то работка по реализации этих требований предстоит жарковатая... 

07.08.2019

Пять уровней зрелости оценки ущерба от DDoS-атак на сайт организации

Понравилась мне прошлая заметка про ИБ для бизнеса на примере HR-подразделения. Она и дискуссии на прошедшем "Код ИБ. Профи" подтолкнули меня к идее данной заметки. На мастер-классе Рустема Хайретдинова зашел разговор о том, как можно показать влияние ИБ на бизнес, и прозвучал тезис о том, что бороться с угрозами не всегда необходимо, так как они не всегда интересны бизнесу. Этот тезис не нов, но дальше был приведен пример сайта, который подвергается DDoS-атаке, и который нуждается в защите... Или все-таки не нуждается?

Вроде бы любой безопасник должен защищаться от DDoS-атак, которые могут вывести из строя сайт компании. Но... нужно ли это бизнесу? И вот тут пригодится идея с пятью уровнями зрелости, которую я описал в прошлой заметке про ИБ и HR. На самом низшем уровне зрелости безопасник обычно вообще не думает об оценке ущерба от той или иной атаки, следуя принципу д'Артаньяна "я дерусь, потому что я дерусь", то есть "я защищаю, потому что надо защищать (или потому что так сказал регулятор"). К бизнесу это не имеет никакого отношения.

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

Третий уровень уже больше похож на бизнес-ориентацию. Мы обращаемся к айтишникам (или к хостинг-провайдеру) и получаем от них данные по времени простоя сайта в результате DDoS-атак за прошедший год (или иной период времени). Затем мы просто перемножаем эти цифры на размер доходов от продаж через сайт и получаем... фанфары... размер ущерба от DDoS-атак. Но... Есть небольшое "но". Такой простой расчет исходит из предположения, что график продаж через сайт представляет из себя обычную прямую, параллельную оси абсцисс. Ни взлетов, ни падений. Каждую минуту происходит одинаковое число сделок и так в течение года. В таком идеальном мире действительно предложенная формула будет работать. Но мир неидеален...

Многие виды бизнеса являются сезонными. Турагентства продают большинство путевок перед майскими, летними и зимними каникулами. Интернет-магазины также имеют сезонные всплески - перед Рождеством, перед Новым годом, перед 14-м и 23-м февраля, а также 8-м марта. Кроме этого, глупо думать, что посетитель, столкнувшись с простоем сайта, навсегда про него забудет и откажется от покупки. Он может прийти через 15 минут и совершить покупку. Он может позвонить по телефону в отдел продаж или написать по электронной почте, а потом продолжить цикл покупки снова через сайт. Поведение пользователя и цикл продаж - это два важных параметра, которые вам потребуется узнать у вашего коммерческого подразделения прежде чем вы снова возьметесь за калькулятор.

Но можно (а временами и нужно) пойти дальше. Помимо учета множества показателей, связанных с циклом продаж, профилем пользователя, временными спадами и пиками, размер средней сделки, количеством транзакций и т.п., мы должны также оценить финансовые показатели приобретаемого средства защиты от DDoS. Понятно, что эта сумма не должна превышать размер ущерба, но это совсем уж поверхностное суждение. Борьба с DDoS может быть представлена в виде облачного или on-prem решения (то есть продаваться по модели OpEx или CapEx соответственно). Купить такое решение можно поставив его на баланс, а можно воспользоваться лизингом. Оплата может быть произведена как за год использования (типичная схема для большинства средств защиты), так и помесячно или в пиковые интервалы продаж/спроса со стороны клиентов, а также по схеме "on-demand", то есть во время самой атаки. При этом последний вариант тоже может быть реализован по-разному - оплата "за атаку" или оплата "за полосу". И вот собрав воедино все финансовые, маркетинговые и айтишные показатели, можно уже заниматься расчетом ущерба от DDoS-атак и его оценкой применительно к конкретной организации. И только в этом случае можно говорить о том, нужна ли конкретному бизнесу защита от DDoS-атак или можно принять данный риск.

06.08.2019

Обзор отчета SANS по Security Operations Center

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

  • Чаще всего на аутсорсинг отдают пентесты и различные формы проверки защищенности организации (red/purple teaming). В остальном тенденции схожи с тем, что написано у Exabeam; с поправкой на то, что SANS оперирует абсолютными цифрами и практически не сравнивает ситуацию с предыдущим годом.
  • Интересен был вопрос о том, как в SOC выстроен процесс управления знаниями, то есть документирование знаний, связанных с прошедшими инцидентами и операциями для ускорения процесса погружения в деятельность SOC новых его членов. Небольшие SOC используют неформальный процесс "один гигантский документ OneNote" или просто SharePoint. Большие SOCи используют для этих задач связку Jira с Confluence, которые позволяют вести базу тикетов и осуществлять накопление знаний в wiki-формате и обмен ими. SOCи, тесно связанные с ИТ, часто задействуют ServiceNow или BMC Remedy для управления тикетами и SharePoint для обмена знаниями.
  • SOCи преимущественно мониторят ИТ-инфраструктуру и только 10% из них берут на контроль еще и АСУ ТП и Интернет вещей. 
  • Для большинства SOCов остается проблемой наличие актуальной информации по активам, которые требуют мониторинга. Это связано с тем, что даже в зрелых ИТ-организациях CMDB обладает точной информации хорошо если на 80%. Часто именно SOC, которые предоставляют услуги сканирования и мониторинга учетных записей, сообщают в ИТ знания, которых у ИТ не было даже при наличии CMDB. Еще большую проблему в понимании активов представляет собой использование IaaS/PaaS/SaaS.
  • В случае наличия в организации NOC, в большинстве случаев он никак не связан с SOC, и их усилия объединяются только в условиях экстренных ситуаций.
  • Авторы отчета отмечают, что ответа на вопрос "Сколько достаточно сотрудников в SOC?" нет. Все зависит от множества факторов. Треть всех опрошенных имеют от 2 до 5 сотрудников в SOC (а всего опросили 355 SOCа по всему миру). Еще треть имеет от 6 до 25 сотрудников. Интересно, что 6 SOCов из 355 (в том числе и Cisco) имеют от 101 до 1000 аналитиков в своем составе, а 3 - более 1000 аналитиков. Хотелось бы знать имена этих "героев". Если же попробовать увязать число аналитиков SOC с размером организации, то картинка получается следующая:
    • При численности компании менее 10000 человек в SOC обычно от 2 до 5 аналитиков.
    • При численности от 10 до 15 тысяч человек SOC насчитывает обычно от 6 до 10 человек. 
    • В организациях от 15 до 100 тысяч сотрудников в SOC обычно работает от 11 до 25 человек.
    • В монстрах от 100 тысяч сотрудников SOC насчитывает от 26 до 100 аналитиков.
  • Получается, что среднее число айтишников от общей численности компании составляет 3% и еще 3% от службы ИТ составляет ИБ.
  • Большинство SOCов построено по централизованной архитектуре, что немудрено. Однако интересным оказалось, что более 10% опрошенных планируют перейти к облачной модели SOC. Еще 10% не имеют вообще никакой четко определенной архитектуры для своего центра мониторинга.
  • Интересным, но предсказуемым оказался ответ на вопрос об используемых метриках эффективности SOC. Самыми популярными метриками являются число инцидентов и время от обнаружения инцидента до реагирования и восстановления после него. Их измерять проще всего, опираясь на используемые в SOC инструменты. Бизнес-метрики, о которых я писал в прошлом сентябре, измерять достаточно тяжело и поэтому ими мало кто занимается. Стоимость инцидента как метрику для SOC использует не больше шестой части участвовавших в опросе центров мониторинга, также как и соотношение понесенных и предотвращенных от инцидентов потерь. В практике Cisco у нас был интересный проект по созданию SOC в финансовой организации, где заказчик в качестве одной из основных метрик использовал стоимость выписки по клиенту в Darknet. Ее увеличение говорило об эффективности работы ИБ. Только 11% организаций полностью автоматизировали процесс сбора и представления метрик - остальные используют либо целиком ручной, либо смешанный способ работы с показателями оценки эффективности SOC.
  • Список барьеров при построении и эксплуатации SOC более полон, чем у Exabeam, хотя топ этих барьеров почти полностью совпадают:
    • Нехватка квалифицированного персонала
    • Нехватка автоматизации и оркестрации
    • Отсутствие интеграции между инструментами SOC
    • Нехватка поддержки руководства
    • Нехватка процессов или playbook
    • Нехватка видимости на 360 градусов в рамках всего предприятия
    • Нехватка корреляции между всеми сигналами тревоги
    • Отсутствие кооперации между ИБ, реагированием на инциденты и аналитиками
    • Нехватка контекста к событиям безопасности
    • Требования регуляторики.
Вот такие данные, которые можно использовать как некоторый ориентир при построении с нуля или оценке уже построенного центра мониторинга безопасности. В целом могу подтвердить правдивость и отчета SANS и отчета Exabeam - мы, проводя аудиты SOCов по всему миру, включая и территорию бывшего Советского Союза, видим те же сложности и наблюдаем то же, что и в упомянутых отчетах.

05.08.2019

Обзор отчета Exabeam по состоянию Security Operations Center

Попался мне тут в руки отчет Exabeam с различной статистикой и обзором происходящего в области Security Operations Center в 2018 году (80% участников опроса имеют опыт работы в SOCах от 6 лет, а длительность работы 90% опрошенных SOC составляет более 3-х лет). Все перечислять не буду, но несколько интересных моментов оттуда я все-таки вытащу:

  • Почти половина SOCов продолжает аутсорсить функции Threat Intelligence (ежегодный рост 17%) и анализ вредоносного кода (ежегодный рост 15%), а вот аутсорсинг функции мониторинга (одной из основных для SOC) наоборот снижается (на 10% по сравнению с прошлым годом). Вспоминая недавнюю заметку, становится понятно, почему многие организации (если уж они доросли до идеи SOC) предпочитают все-таки строить свой центр мониторинга, отдавая вовне только сложные сервисы. Также возрастает число кейсов (на 6%), в которых на аутсорсинг отдается внеурочная работа (ночные часы и выходные). Сократилось до нуля число организаций, которые целиком отдавали функцию SOC на аутсорсинг. 
  • Менее эффективные SOC имеют больше проблем с нехваткой персонала, чем высоко эффективные центры мониторинга. Трети SOC не хватает 6-10 человек для выполнения своих функций. Интересно, что в России многие службы ИБ насчитывают меньше людей, чем это число.
  • Одним из мотивирующих факторов для аналитиков SOC продолжать работать в SOC являются вызовы, с которыми приходится сталкиваться в работе. Иными словами, в центрах, которые занимаются "ерундой" (мало заказчиков при аутсорсинге, мониторинг только периметра и небольшое количество инцидентов), аналитики должно не удерживаются, что приводит к снижению эффективности SOC (я об этом уже писал год назад). И это обычно не находится на поверхности, если речь идет об аутсорсинговом SOC. На желание покинуть SOC активно влияют плохой график работы (о том, что с этим делать, я говорил на прошлом SOC Forum), возможность фриланса (врядли актуально в России), а также отсутствие возможностей для внутреннего роста.
  • Возрастает роль так называемых soft skills для аналитиков SOC. Особенно важны становятся социальные навыки, умение коммуницировать и умение работать в команде.
  • Из технических навыков возрастает роль threat hunting и поиска утечек информации. А вот важность навыков работы с МСЭ, форензики и анализа вредоносного кода снизилась.
  • Общая эффективность SOC за год не изменилась, а вот возможности по автоматизации существенно упали (на 14%).
  • Три основных проблемы, возникающие у аналитиков SOC, - время, затрачиваемое на отчетность и документацию, ложные срабатывания и усталость от угроз (а тут недалеко и до психологической слепоты). А в целом у SOC проблемы следующие (в порядке приоритета) - успевать реагировать на все события ИБ, координация между ИБ и ИТ, слабая интеграция различными инструментов ИБ, необновленное оборудование. Тут вроде ничего нового
  • В рамках технологического стека у SOCов 4 приоритета - анализ больших данных, EDR (endpoint detection & response), мониторинг сети (NTA) и облаков (но не CASB), а также управление учетными записями. Около 40% SOC используют их в своей работе. Возрастает интерес к машинному обучению, которое может помочь в деятельности SOC, но пока только в крупных центрах мониторинга. 
  • Треть высокоэффективных SOCов проводят тренинги персонала на ежемесячной основе, еще столько же - на ежеквартальной, а пятая часть - на еженедельной основе. Это очень необычно для многих российских SOCов (да и вообще служб ИБ), которые не всегда выполняют требования даже пятилетних циклов повышения квалификации для своих сотрудников. Но не нужно думать, что речь всегда идет только о внешних курсах обучения или повышения квалификации. Нередко SOCи проводят внутренние тренинги или онлайн-курсы. Интересно, что высокоэффективные SOC отдают предпочтение внутреннему обучению, в отличие от низкоэффективных, ориентированных на внешнее обучение.
  • Интересно отличие в части используемых метрик для больших (более 200 человек) или малых (до 24 человек) SOCов. Последние чаще всего используют время простоя ИТ- или бизнес-сервисов, а первые - число эскалированных инцидентов, время простоя ИТ-сервисов и время от обнаружения инцидента до реагирования и восстановления после него. При этом существуют отличия между тем, какие метрики предпочитают руководители ИТ или ИБ и аналитики SOC. Первым интересно число тикетов по инцидентам, а вторым - время простоя. 
  • Только 5% SOCов утверждают, что видят все, что им необходимо. К основным причинам, которые мешают SOCам видеть все, относят - legacy-приложения, которые не отдают события в SIEM, нехватка взаимодействия с владельцами сервисов/приложений, которые должны отдавать события безопасности, нехватка бюджета, а также нестандартизованные технологии (например, в процессе слияний и поглощений или неиспользующие стандарты).
  • В тройку основных направлений инвестиций для улучшения SOC входят - новые технологии, персонал и автоматизация.

23.07.2019

Обзор 281-го приказа ФСБ по порядку установки средств ГосСОПКИ

Еще один появившийся на прошлой неделе приказ ФСБ касается правил установки и эксплуатации средств ГосСОПКИ. Эти правила достаточно просты:
  • Установка средств ГосСОПКИ согласуется с ФСБ. Ну вроде все понятно, за исключением одного момента. Какое именно подразделение ФСБ согласует установку? Например, в 282-м приказе четко написано, что информировать об инцидентах надо не просто ФСБ, а именно НКЦКИ. По тексту же говорится, что после приемки в эксплуатацию средств ГосСОПКИ необходимо информировать НКЦКИ. Если бы НКЦКИ согласовывал установку, то его не надо было информировать о приемке в эксплуатацию.
  • Чтобы согласовать установку с ФСБ вы должна знать, что вы будете устанавливать, где, кто их будет эксплуатировать и какие объекты КИИ будут контролироваться средствами ГосСОПКИ. Любое изменение указанной информации (кроме ФИО администраторов и операторов) требует согласования с ФСБ, на что дается также 45 дней (при изменении админов и операторов надо всего лишь информировать ФСБ об этом).
  • За 45 дней ФСБ согласует установку или отказывает в ней (почему-то фраза "мотивированный отказ" в документе отсутствует).
  • Субъект КИИ, являющийся финансовой организацией, должен уведомить Банк России (какое подразделение) о том, что ФСБ согласовала установку средств ГосСОПКИ. В случае изменений в согласованных ФСБ условиях, о них также должен быть уведомлен Банк России. В документах ЦБ таких требований нет.
Однако гораздо более интересен вопрос о том, что же такое средства ГосСОПКИ? Например, согласно 196-му приказу об утверждении требований к средствам ГосСОПКИ под это понятие попадают и SIEMы, и сканеры безопасности, и системы обнаружения вторжений, и SOAR/IRP и т.п. Значит ли это, что на установку всех этих решений надо получать согласие ФСБ, без которого их установка будет признана незаконной и за это можно будет "присесть" на срок до десяти лет лишения свободы? В пятницу в одном из чатиков была длинная дискуссия на эту тему, по результатам которой, мы так и не пришли к единому пониманию ибо практика общения с регулятором не бьется с его же требованиями. И вот почему.

Попробую поделиться собственным мнением о том, что есть средства ГосСОПКИ и с чем их едят. Для начала надо вспомнить, что темы КИИ и ГосСОПКИ развиваются параллельно. Для многих ГосСОПКА - это то, что делается в рамках КИИ, что в корне неверно. ГоСОПКА развиваться начала гораздо раньше появления ФЗ-187 и распространяется она не только на критическую инфраструктуру (еще и на государственные информационные ресурсы). То есть ГосСОПКА живет по своим правилам (к слову сказать, регулирующимся ДСПшными документами) и только в отдельных случаях касается субъектов КИИ.

Отсюда вытекает простой вывод "силы и средства ГосСОПКИ" и "средства защиты и подразделения по ИБ субъекта КИИ", хоть и схожи по смыслу, но являются разными сущностями. При наличии у вас значимых объектов вы обязаны выполнять требования ФСТЭК, описанные в 235-м и 239-м приказах регулятора. Вы должны регистрировать события (SIEM), искать и устранять уязвимости (сканеры), обнаруживать вторжения (СОВ/СОА), управлять инцидентами (IRP/SOAR) и т.п. И это все вы делаете по требованиям ФСТЭК, которая хоть и установила требования к средствам защиты, но достаточно свободные и исполнимые.

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

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


Вроде бы на этом, можно было бы и завершить этот обзор 281-го приказа и экскурс в ГосСОПКУ, но в уже упомянутом выше чатике, в процессе дискуссии была озвучена очень интересная мысль о том, что НКЦКИ сегодня согласовывает центрам подключения к ГосСОПКЕ даже если их инструментарий не соответствует требованиям 196-го приказа и, например, может быть модернизирован только только иностранными организациями и имеет гарантийную поддержку от иностранных организаций (а это запрещено 196-м приказом). Я не то, чтобы против такого подхода, даже за. Просто такое вольное прочтение своих же приказов опять приводит к неоднозначностям, что не есть хорошо.