Splunk 27-го февраля объявил о подписании соглашения о покупке Phantom Cyber, компании, которая работает в сегменте SOAR по версии Gartner, и занимается оркестрацией и автоматизацией вопросов ИБ. Размер сделаки составл 350 миллионов долларов США.
27.2.18
РНТ выходит на рынок киберразведки, а МФИ Софт выделяет новое направление бизнеса
Компания РНТ, занимающаяся информационной безопасностью, приобрела контрольный пакет «Лавины Пульс», специализирующейся на интернет-разведке и контроле активности в социальных сетях. Ранее эта доля принадлежала близкой к структурам Саида Керимова компании «Эйр-Синема». Господин Керимов интересовался и покупкой самой РНТ, но, как считается, разочаровался в инвестиционной привлекательности рынка. Оставшаяся доля остается у известного в среде ИБ специалиста - Андрея Масаловича. В свою очередь другая российская компания, МФИ Софт, выделила направление ИБ в отдельную компанию - "Гарда Технологии".
Конференция ФСТЭК: финальный аккорд
Завершить рассказ (начало тут, тут и тут) о конференции ФСТЭК мне бы хотелось рассказом о некоторых докладах, которые запомнились (рекламные доклады я в расчет не беру). Начну с Конфидента, который в очередной раз порадовал хорошей аналитикой. В ноябре они в Питере уже делали очень хороший доклад на тему возможности (а точнее невозможности) выполнения требований по ИБ ФСТЭК (например, 17-го приказа) на базе отечественных ИТ-продуктов. В этот раз Конфидент, в лице Егора Кожемяки, рассказывал об устранении уязвимостей в сертифицированных средствах защиты информации. Первоначально была приведена статистика проект 0-DAY tracking project (www.zero-day.cz), который накапливает данные по ведущим мировым разработчикам ПО последние десять лет. Среднее время выпуска патча производителем составляет одни сутки. Тут стоит обратить внимание, что речь идет не об устранении уязвимости заказчиком, а о разработке патча вендором. Как показывает исследование Cisco среднее время присутствия уязвимости на стороне заказчика составляет... 5 (!) лет.
Но вернемся к устранению уязвимостей в сертифицированных средствах защиты. По оценкам Конфидента среднее время устранения уязвимостей у отечественных вендоров навесных систем составляет около месяца. Кстати, на конференции со стороны ФСТЭК прозвучала угроза отзыва сертификатов у заявителей за отказ устранять уязвимости в разработанном или сертифицируемом ими ПО.
А вот статистика по устранению уязвимостей в сертифицированных операционных системах гораздо показательнее. Позволю себе скопировать подстрочник из презентации Конфидента, чтобы не пересказывать своими словами: "...заметен более длительный срок устранения уязвимостей в ОС. Если детально изучить выявленные уязвимости, то обнаружим, что подавляющее количество уязвимостей содержится в сторонних модулях (пакетах) т.н. свободного программного обеспечения, которые включаются в дистрибутив ОС".
"В 2017 году ситуация с обновлениями безопасности у Альт Линукс существенно изменилась в лучшую сторону. В 2016 году было 1 обновление, а в 2017 году их уже более 20 штук (и это не считая большого количества новостей по данной тематике)! Сроки устранения уязвимостей у Альт Линукс также на достаточно высоком уровне. Если не принимать в расчёт буквально несколько уязвимостей со сроком устранения 3 года (которые влияют на статистику), то среднее значение по срокам будет раза в 2 лучше. В статистике Альт Линукс встречаются уязвимости со сроком устранения буквально несколько дней. У Astra Linux Special Edition 1.5 также только одно обновление безопасности в 2016 году и только 3 таких обновления за 2017 год – скорость (частота) исправления уязвимостей существенно ниже по сравнению с Альт Линукс". Возвращаясь к разговору о том, что безопаснее, Windows или Linux, и может ли число уязвимостей говорить о незащищенности продукта, вспомню, что защищенность любого ИТ-решения, в т.ч. и сертифицированного, определяется не числом уязвимостей, а оперативностью их устранения, чем отечественные игроки пока похвастаться не могут (по сравнению с их зарубежными коллегами).
Второй запомнившийся мне доклад был сделан Суховерховым Александром из воронежского ГНИИ ПТЗИ ФСТЭК. Посвящен он был банку данных угроз и уязвимостей, которая активно развивается. Если не повторять цифр, то меня заинтересовал "Зал славы", в котором публикуются данные об организациях и частных лицах, которые активно исследуют защищенность различных ИТ-продуктов и сообщать о них в ФСТЭК. Каждому участнику, попадающему на сайт ФСТЭК, присваивается свой рейтинг, который и определяет место исследователей на "доске почета".
Хотя значения некоторых показателей вызывают у меня вопросы. Например, показатель важности объекта исследования. Почему BIOS важнее сетевого оборудования (чем, кстати, ПО сетевого средства отличается от сетевого программного средства)? А чем отличается программное средство АСУ ТП от ПО программно-аппаратного средства АСУ ТП? Наконец, почему ПО виртуализации важнее ПО СУБД? Ну да ладно.
Среди направлений совершенствования БДУ хотел бы выделить бесплатную утилиту ScanOVAL, которая предназначена для обнаружения уязвимостей ПО на платформе MS Windows.
В самое ближайшее время утилита появится на сайте ФСТЭК и будет доступна для всех желающих.
Утилита позволит загружать XML-файлы с OVAL-описанием уязвимостей, согласно которым будет происходить обнаружение уязвимостей на локальной машине (но только для Windows).
Во время секции вопросов и ответов Дмитрию Шевцову задали вопрос о том, какие РД/профили ФСТЭК выпустить в этом году. Дмитрий Николаевич ответил, что слишком много развелось "всяких блогеров", которые фотографируют планы ФСТЭК, публикуют их в Интернет, а потом критикуют и спрашивают, почему планы не выполняются :-) Одним из таких "блогеров" являюсь и я. Но я не буду спрашивать про обещанные на прошлогодней конференции ФСТЭК РД по СУБД, виртуализации и управлению потоками. Мне интереснее сейчас планы по развитию БДУ, которые были озвучены в прошлом году. Где база шаблонов ошибок для отдельных языков программирования и личный кабинет пользователя? Не успели их сделать в этом году :-(
На финал еще несколько прозвучавших тезисов:
ЗЫ. Мне кажется, что конференцию ФСТЭК логичнее было бы проводить в рамках InfoSecurity Russia. Организатор тот же, а аудитория гораздо более релевантная. Хотя если убрать "Актуальные вопросы защиты информации" из программы ТБ-Форума, то кто же туда ходить будеть?
ЗЗЫ. Конференция ФСТЭК - единственная на моей памяти (а их на ней много), на которой вообще не делается перерывов ни на обед, ни на кофе-брейк, ни вообще. 7 часов сплошных выступлений.
Но вернемся к устранению уязвимостей в сертифицированных средствах защиты. По оценкам Конфидента среднее время устранения уязвимостей у отечественных вендоров навесных систем составляет около месяца. Кстати, на конференции со стороны ФСТЭК прозвучала угроза отзыва сертификатов у заявителей за отказ устранять уязвимости в разработанном или сертифицируемом ими ПО.
А вот статистика по устранению уязвимостей в сертифицированных операционных системах гораздо показательнее. Позволю себе скопировать подстрочник из презентации Конфидента, чтобы не пересказывать своими словами: "...заметен более длительный срок устранения уязвимостей в ОС. Если детально изучить выявленные уязвимости, то обнаружим, что подавляющее количество уязвимостей содержится в сторонних модулях (пакетах) т.н. свободного программного обеспечения, которые включаются в дистрибутив ОС".
"В 2017 году ситуация с обновлениями безопасности у Альт Линукс существенно изменилась в лучшую сторону. В 2016 году было 1 обновление, а в 2017 году их уже более 20 штук (и это не считая большого количества новостей по данной тематике)! Сроки устранения уязвимостей у Альт Линукс также на достаточно высоком уровне. Если не принимать в расчёт буквально несколько уязвимостей со сроком устранения 3 года (которые влияют на статистику), то среднее значение по срокам будет раза в 2 лучше. В статистике Альт Линукс встречаются уязвимости со сроком устранения буквально несколько дней. У Astra Linux Special Edition 1.5 также только одно обновление безопасности в 2016 году и только 3 таких обновления за 2017 год – скорость (частота) исправления уязвимостей существенно ниже по сравнению с Альт Линукс". Возвращаясь к разговору о том, что безопаснее, Windows или Linux, и может ли число уязвимостей говорить о незащищенности продукта, вспомню, что защищенность любого ИТ-решения, в т.ч. и сертифицированного, определяется не числом уязвимостей, а оперативностью их устранения, чем отечественные игроки пока похвастаться не могут (по сравнению с их зарубежными коллегами).
Второй запомнившийся мне доклад был сделан Суховерховым Александром из воронежского ГНИИ ПТЗИ ФСТЭК. Посвящен он был банку данных угроз и уязвимостей, которая активно развивается. Если не повторять цифр, то меня заинтересовал "Зал славы", в котором публикуются данные об организациях и частных лицах, которые активно исследуют защищенность различных ИТ-продуктов и сообщать о них в ФСТЭК. Каждому участнику, попадающему на сайт ФСТЭК, присваивается свой рейтинг, который и определяет место исследователей на "доске почета".
Хотя значения некоторых показателей вызывают у меня вопросы. Например, показатель важности объекта исследования. Почему BIOS важнее сетевого оборудования (чем, кстати, ПО сетевого средства отличается от сетевого программного средства)? А чем отличается программное средство АСУ ТП от ПО программно-аппаратного средства АСУ ТП? Наконец, почему ПО виртуализации важнее ПО СУБД? Ну да ладно.
Среди направлений совершенствования БДУ хотел бы выделить бесплатную утилиту ScanOVAL, которая предназначена для обнаружения уязвимостей ПО на платформе MS Windows.
В самое ближайшее время утилита появится на сайте ФСТЭК и будет доступна для всех желающих.
Утилита позволит загружать XML-файлы с OVAL-описанием уязвимостей, согласно которым будет происходить обнаружение уязвимостей на локальной машине (но только для Windows).
Во время секции вопросов и ответов Дмитрию Шевцову задали вопрос о том, какие РД/профили ФСТЭК выпустить в этом году. Дмитрий Николаевич ответил, что слишком много развелось "всяких блогеров", которые фотографируют планы ФСТЭК, публикуют их в Интернет, а потом критикуют и спрашивают, почему планы не выполняются :-) Одним из таких "блогеров" являюсь и я. Но я не буду спрашивать про обещанные на прошлогодней конференции ФСТЭК РД по СУБД, виртуализации и управлению потоками. Мне интереснее сейчас планы по развитию БДУ, которые были озвучены в прошлом году. Где база шаблонов ошибок для отдельных языков программирования и личный кабинет пользователя? Не успели их сделать в этом году :-(
На финал еще несколько прозвучавших тезисов:
- Заданный вопрос про методику моделирования угроз, обещанную еще в 2013-м году, мягко замылили, просто сославшись на необходимость использования БДУ и здравый смысл.
- В этом году, в начале второго полугодия, обещают не только упомянутый вчера РД по уровням доверия, но и РД по средствам борьбы с DDoS-атаками (для меня это было неожиданно - раньше этот тип средств ни разу не звучал на мероприятиях ФСТЭК).
ЗЫ. Мне кажется, что конференцию ФСТЭК логичнее было бы проводить в рамках InfoSecurity Russia. Организатор тот же, а аудитория гораздо более релевантная. Хотя если убрать "Актуальные вопросы защиты информации" из программы ТБ-Форума, то кто же туда ходить будеть?
ЗЗЫ. Конференция ФСТЭК - единственная на моей памяти (а их на ней много), на которой вообще не делается перерывов ни на обед, ни на кофе-брейк, ни вообще. 7 часов сплошных выступлений.
Гиперфакториал кибербезопасности
В первый день весны в Москве пройдет "Код ИБ. Профи", о котором я уже писал в декабре. У нас уже окончательно сформировалась программа и можно рассказать о том, кто и что будет рассказывать в рамках очень насыщенной деловой двухдневной программы (еще можно успеть зарегистрироваться).
Я уже писал, что мне хотелось, чтобы в России проходила своя RSA Security, ориентированная на специалистов по ИБ, принимающих решения или готовящих их (этакая идея фикс). И вот, благодаря "Экспо-Линку" это, похоже, удается сделать, так как действительно удалось собрать на одной площадке действительно достойнейших спикеров, которые будут делиться своим опытом (далее в алфавитном порядке):
Я уже писал, что мне хотелось, чтобы в России проходила своя RSA Security, ориентированная на специалистов по ИБ, принимающих решения или готовящих их (этакая идея фикс). И вот, благодаря "Экспо-Линку" это, похоже, удается сделать, так как действительно удалось собрать на одной площадке действительно достойнейших спикеров, которые будут делиться своим опытом (далее в алфавитном порядке):
- Максим Авдюнин. Я слышал Максима на Уральском форуме, где он проводил у меня в секции мастер-класс по поиску информации по открытым источникам Интернета (OSINT) в целяъ информационной безопасности. Но тогда у Максима было всего около 30 минут, а сейчас у него будет целый час и он сможет раскрыть эту тему более детально. Будут рассмотрены интересные кейсы, которые помогут показать роль ИБ в бизнесе компании, и продемонстрировать, что умение не только защищать, но и добывать информацию, может сильно помочь безопасникам в общении с различными целевыми аудиториями внутри своей организации.
- Вячеслав Борилин. Вячеслав ведет в Лаборатории Касперского практику геймификации, обучения, культуры ИБ и будет делиться своим опытом внедрения новых практик донесения до разных групп пользователей информации о правилах ИБ. Это та тема, которая только-только начинает набирать популярность на Западе, и очень важно, что Вячеслав сможет рассказать о своем опыте в этой сфере.
- Илья Борисов. Как написано в Википедии, SCRUM - это метод "разработки продуктов высокой ценности в запутанной среде". Как еще лучше можно сказать про информационную безопасность? Вообще про гибкую методологию в ИБ почти никто не говорит (это вам не agile при разработке ПО). На первый взгляд очень сложно совместить жестко зарегулированную область, мероприятия которой длятся месяцами и кварталами, с методологией выполнения задач за небольшие интервалы времени (спринты). Тем ценнее доклад Ильи Борисова, который будет делиться практическим опытом применения SCRUM в ИБ. И да, Илья не работает в Сбербанке, который практически узурпировал тему agile :-)
- Алексей Волков. У кого-то может сложиться впечатление, что грядущий «Код ИБ. Профи» выкуплен Сбербанком, ведь там выступает три классных докладчика от него - Кирилл Мартыненко, Алексей Качалин и Алексей Волков. Но это не так 😉 Просто Сбер спылесосил огромное количество классных специалистов и харизматичных спикеров. Алексей Волков один из них и на конференции он поднимет достаточно непростую тему оценки киберрисков и управления ими. Шаманство или реальная практика? Все секреты от рискованного харизматика!
- Дмитрий Гадарь. В первом, сочинском "Коде ИБ. Профи" у нас был в программе один мастер-класс от Алексея Качалина (он еще работал в Positive Technologies), посвященный методам хакеров. В этот раз мы решили немного поменять концепцию и рассказать о двух реальных примерах атак, с которыми пришлось столкнуться Дмитрию, и о том, какие уроки были извлечены из этих кейсов. Мастер-класс ценен тем, что нечасто безопасники готовы делиться тем, как их атаковали и как они боролись с хакерами.
- Наталья Гуляева. Аутсорсинг, внешние провайдеры услуг... Это то, что становится потихоньку мейнстримом и многие безопасники начинают присматриватья к игрокам этого рынка, выбирая их по тем или иным наборам критериев. Но очень редко когда в список этих критериев включаются юридические вопросы, недооценка которых может дорого обойтись в случае какого-либо инцидента или конфликта или разрыва договора. Вот о том, какие подводные камни существуют при заключении договоров на аутсорсинг и будет говорить Наталья, имеющая колоссальный опыт международной и российской юридической практики в этом вопросе.
- Андрей Дугин. Для обеспечения информационной безопасности в корпоративной сети необходимо определить, что контролировать в первую очередь, какие для этого выбрать технические и организационные меры. В мастер-классе Андрея будут проанализированы необходимые практические меры при масштабах инфраструктуры, измеряемой десятками тысяч клиентских станций и серверов. Да, не каждый слушатель работает в компании такого масштаба, как у Андрея (МТС), но кто знает, что будет завтра? Вдруг вас пригласят возглавить службу ИБ транснациональной корпорации или российской федеральной структуры?
- Кирилл Ермаков. Когда Кирилл прислал тему своего выступления на «Код ИБ. Профи», я вначале был не совсем уверен, что тема bug bounty интересна не только вендорам. Но оказалось, что это не так. Кирилл расскажет, как bug bounty помогает корпоративным безопасникам делать свою жизнь лучше и дешевле традиционных подходов к поиску уязвимостей.
- Роман Жуков. До недавней смены работы Роман работал в Ростелекоме, который в России активно развивает тему облаков и достаточно активно конкурирует с иностранными и другими российскими поставщиками облачных услуг. Роман как раз и будет рассказывать и показывать, как выбирать облако с точки зрения безопасности.
- Денис Зенкин. Знаю Дениса уже давно. Большая удача вытащить его с выступлением на такую непростую тему. Вспоминая известное высказывание, что есть два типа компаний, те, кого уже взломали, и те, кто еще об этом не знает, умение общаться с внешним миром является очень важным для любого предприятия и любого безопасника. А учитывая происходящее в последнее время вокруг Лаборатории Касперского, рассказ Дениса будет ценен вдвойне - опыт у него колоссальный.
- Антона Карпов очень сложно вытащить с выступлением по ИБ на какое-то мероприятие, если это не YAC. Но на «Код ИБ. Профи» это удалось сделать, за что Антону большое спасибо. Я как-то слушал доклад Антона, где он рассказывал, как Яндекс искал-искал и не нашел устраивающее их решение по аутентификации и написал свое. Я тогда подумал: «Вот ведь. Не каждая компания будет сама писать средства защиты под свои нужды». Сегодня это уже практика для лидеров рынка. Тем интереснее, что Антон расскажет на этот раз - опыт Яндекса всегда интересен. Антон поделится практическим взглядом на самые популярные вопросы, встающие перед руководителем ИБ: где структурно должна быть Служба ИБ, какие основные направления она должна охватывать, как оценивать риски, как построить модель нарушителя, какие контроли ИБ следует внедрять и какой подход при этом исповедовать.
- Алексей Качалин. В процессе подготовки к «Коду ИБ.Профи» я понял одно - я бы не хотел работать в Сбербанке, несмотря на интересные проекты, которые там ведутся. Такой нагрузки на людей я не видел давно. Тем ценнее участие Алексея с мастер-классом на животрепещущую и практическую тему про security operations (нет, это не будут очередная реклама SOCа). В России не так много (вообще нет) центров мониторинга такого масштаба, как у Сбербанка. Поэтому вы больше нигде не узнаете о таком количестве граблей и способов их обхода, как в этом мастер-классе.
- Алексей Комаров. Вы все еще пользуетесь паролями? Тогда Алексей идет к вам. Его мастер-класс посвящён современным методам аутентификации пользователей, их сильным и слабым сторонам с практической точки зрения. Будут рассмотрены основные тенденции в этом сегменте решений в привязке к реалиям российского (и постсоветского) рынка в свете существующих исторических особенностей. Для основных типовых ситуаций будут представлены рекомендации по выбору типа решения для аутентификации. Несколько сценариев, выбранных аудиторией голосованием, будут рассмотрены более подробно. Дополнительно будет дан обзор основных игроков российского рынка двухфакторной аутентификации и их решений.
- Дмитрий Кузнецов. Дмитрий, раньше занимавшийся практической ИБ в одном из европейских банков, а позже перешедший в Positive Technologies и занявшийся практической ИБ и там будет говорить о деятельности SOC в разрезе реагирования на компьютерные инциденты. Создавая такой SOC для крупной IT-инфраструктуры, мы обычно ожидаем, что он будет способен принимать решения и начинать действовать оперативно, в течение первых же минут инцидента. На практике чаще всего приходится сталкиваться с тем, что почти каждый инцидент становится для защищающейся стороны головоломкой-сюрпризом. Как этого избежать? SOC приходится "выращивать", начиная с некоторого минимума ресурсов, ограниченной области действия и ограниченных возможностей. То, как свежесозданный "отдел мониторинга" превращается в полноценный центр кибербезопасности, и будет предметом мастер-класса Дмитрия.
- Олег Кузьмин начал тему психологии в ИБ еще на сочинском "Код ИБ. Профи". В Москве Олег продолжит авторскую тему общей психологии в информационной безопасности и посвятит мастер-класс вопросам практической работы и контроля за действиями привилегированных пользователей (ТОП-менеджеры, администраторы, специалисты ИБ, а также различные внешние аудиторы). Работа с ТОП-менеджерами, администраторами и прочими привилегированными должностными лицами всегда характеризуется сложными психологическими отношениями и непростыми рабочими моментами, непредсказуемость последствий которых порой носит очень критичный характер. Основные подходы в решении этих вопросов с разбором всех их возможных составляющих и будут подробно рассмотрены в ходе мастер-класса Олега.
- Алексей Лукацкий. Сложно писать о самом себе, но попробую. В рамках своего мастер-класса я попробую поделиться опытом проведения киберучений (деловых игр) по ИБ для топ-менеджмента предприятия (именно для них, а не для технарей). Как это сделать? Что интересует топ-менеджмент? Какие варианты проведения киберучений являются наиболее эффективными для руководства компании? Как заинтересовать целевую аудиторию? Какие ошибки допускаются при проведении киберучений? Вот это вот все :-)
- Дмитрий Мананников является родоначальником темы бизнес-ориентации ИБ на российских мероприятиях. Он меняет взгляды слушателей на привычные мероприятия, показывая эффективность и неэффективности типовых задач, которым ежедневно занимаются безопасники. В рамках своего мастер-класса Дмитрий рассмотрит инциденты безопасности с точки зрения бизнес-логики. Каким образом цикл инцидента влияет на бизнес-показатели, как выявлять предпосылки к возникновению инцидентов в рамках существующих бизнес-процессов? Также будет обсужден подход к сбору данных по инцидентам, который позволит получать данные для обоснования экономического эффекта от внедрения средств защиты.
- Кирилл Мартыненко. А вот еще один бомбический доклад от Сбербанка на «Код ИБ. Профи». Теперь от Кирилла Мартыненко. Реальные кейсы и примеры по формированию культуры ИБ, геймификацию, security awareness. Кирилл даже VR-оборудование притащит, чтобы показать, как это все работает и как современные технологии виртуальной реальности помогают повышать защищенность предприятия.
- Василий Окулесский. С Василием Андреевичем Окулесским мы знакомы лет двадцать и этим все сказано. Прекрасный рассказчик, колоссальный практический опыт - все это залог успеха его выступления на «Код ИБ. Профи». А тема фрода и борьбы с ним все чаще попадает в прицел безопасников; и не только банковских. Ведь мошенничество есть у многих - нефтянка, энергетика, ритейл, логистика, операторы связи и т.д.
- Сергей Рублев. В свое время доклад «Инфосекьюрити Сервис» на SOC Forum выбивался на общем фоне, потому что ребята сделали свой SOC на open source компонентах - Hadoop, Spark и т.д. Никаких покупных решений, все свое. Сегодня open source все чаще используется в деятельности служб ИБ, которые не могут найти на рынке адекватных продуктов. Кейс, о котором будет рассказывать Сергей, очень интересен еще и тем, что говорит о модной теме мониторинга ИБ (SOC) не на базе ArcSight :-)
- Александр Скакунов. Можно заметить, что в программе "Кода ИБ. Профи" не так много технических мастер-классов. Это сделано специально, но есть и некоторые исключения. Например, Александр расскажет о такой "модной" теме, как машинное обучение в ИБ, но в практической плоскости. Он покажет, как за счет анализа машинных данных противостоять ransomware без изменения текущей ИБ-инфраструктуры. Будет дана информация для тех, кому надоели «rip-and-replace» предложения по внедрению новых специализированных средств защиты информации.
- Алексей Смирнов. Проездом в Москве! Всего одно выступление! Редкие гастроли :-) Почему не работают лучшие практики и как жить за чертой бедности - об этом и многом другом расскажет Alex Smirnoff, широко известный в узких кругах как Арканоид :-) Много лет назад (10+) я помню, как Алексей зажигал на РусКрипто, "моча" коммерческих вендоров межсетевых экранов :-) Сейчас нас ждет не менее зажигательное шоу. Что мешает нам заниматься информационной безопасностью эффективно? Вера в действенность универсальных "лучших практик" и "современных технологий", психологические ловушки, заставляющие нас концентрировать усилия за пределами зоны максимального риска, ложные метафоры, препятствующие пониманию того, что мы на самом деле делаем и как, фрагментарность показателей эффективности, маскирующая общий план, "синдром троечника" (подмена достижения цели демонстрацией усердия) - со всем этим можно и нужно бороться. А как бороться и расскажет Алексей.
- Рустэм Хайретдинов. Средства корпоративной ИБ почти никогда не работают "сами по себе", а требуют соблюдения пользователями определенных правил, то есть ограничений в поведении. Будут ли такие правила выполняться естественно и автоматически или будут постоянно саботироваться, зависит как от самих правил, так и от методики их внедрения. Правила, выполняющиеся всеми сотрудниками автоматически, снижают стоимость средств контроля, требуют меньше внимания со стороны контролирующих и уменьшают количество нарушений. Мастер-класса Рустэма представляет методику мягкого прививания корпоративных правил персоналу на основе постепенного введения в корпоративную культуру четких и понятных правил, эффективных средств контроля и чёткой и неотвратимой обратной связи с учётом различных психотипов сотрудников. Руст - офигенный докладчик с кучей баей и историй из жизни.
- Алексей Чеканов. Гартнер в своих прогнозах предсказывает, что 80% классических CISO вымрут и им на смену придет CISO нового поколения, бизнес-ориентированный, незамкнутый в теме киберугроз и compliance. Поэтому в программе «Код ИБ. Профи» нет ни одного доклада про нормативку :-) Зато есть темы, которые выходят за рамки традиционного безопасника. Одна из них - непрерывность и киберустойчивость бизнеса, о которой будет рассказывать Алексей, занимающейся этой темой уже много лет.
До встречи на "Коде ИБ. Профи" в этот четверг и пятницу! Да, если вдруг вы не сможете поучаствовать, но захотите получить доступ к видеозаписям всех мастер-классов, то на сайте конференции написано, как это сделать.
26.2.18
Конференция ФСТЭК: "В одних трусах много ошибок не обнаружишь"
Третьей темой конференции ФСТЭК (после КИИ и сертификации) стало доверие или, согласно ГОСТ 15408, основание для уверенности в том, что объект оценки отвечает конкретным функциональным требованиям безопасности. О том, какие усилия предпринимает ФСТЭК для этого, рассказал начальник отдела организации и проведения работ по сертификации средств защиты информации и аттестации объектов информатизации Костенко Михаил Евгеньевич.
У регулятора достаточно много различных документов, говорящих о доверии, - от профилей защиты информации и РД на НДВ до ГОСТов 54581/2/3, 15408, 18045 и 56939. Все они направлены на то, чтобы удостовериться не только в функциональных возможностях того или иного решения, но и в том, что реализованы они качественно, а разработчик в состоянии поддерживать свое творение в течение всего жизненного цикла продукта.
Поэтому среди элементов доверия, на которые обращает внимания ФСТЭК, есть и действия, которые должны выполняться разработчиком, и свидетельства, доказывающие их исполнение, и действия самого оценщика.
Правильная оценка уровня доверия дает уверенность в том, что функциональные требования безопасности реализованы корректно. Поэтому во всех последних профилях защиты ФСТЭК наращивает требования по обеспечению доверия. Начав с РД на системы обнаружения вторжений и антивирусы эти требования по нарастающей попадают в РД на DLP, межсетевые экраны, операционные системы, СУБД и др.
Однако достаточно сложно становится поддерживать множество разрозненных документов, в которых еще и разные наборы требований к доверию. Поэтому сейчас ФСТЭК завершает работы по унификации соответствующих требований, которые можно было бы:
Соответственно сейчас на подходе у ФСТЭК находится два документа. Первый - давно обещанная методика поиска уязвимостей и недекларированных возможностей. От старого РД по НДВ будут отказываться - по сути он и так сейчас используется только в тех случаях, когда на средство защиты нет профиля, а требования сертификации присутствует. Учитывая, что требования по отсутствию НДВ уже включены во все профили защиты, то необходимость в таком РД постепенно исчезает. А вот методика поиска НДВ и уязвимостей нужна.
Про методику рассказ подхватил начальник лаборатории ГНИИ ПТЗИ Алексей Сердечный, который подробно описал не только структуру нового документа:
но и методы выявления уязвимостей и недекларированных возможностей, а также их применимость в тех или иных ситуациях, в том числе и учитывая потенциал нарушителя.
Опираясь на методику по поиску уязвимостей, ГОСТы по уязвимостям, по безопасной разработке, требования по обновлению, ФСТЭК готовит второй документ "Требования по безопасности информации, устанавливающие уровни доверия к программному обеспчеению и оборудованию, используемому в государственных органах и организациях" (обратите внимание, и к оборудованию).
В новых документах наконец-то найдут свое отражение требования, которые уже требуются при сертификации, например, межсетевых экранов, и которые могут представлять некоторую проблему для разработчиков, использующих не свое железо.
Кроме этого, некоторые требования вообще непонятно как выполнять, что отчасти и привело к снижению числа сертифицированных МСЭ, о чем я писал на прошлой неделе. Например, в случае наличия подсистемы Secure Boot или специальных ASIC (а это норма для иностранных аппаратных средств защиты), они предотвращают проверку этих подсистем или некоторых защищенных областей внутри них. Как выполнить существующие и формализуемые требования, не совсем понятно :-(
Вообще ФСТЭК стала больше уделять внимания именно аппаратной начинке сертифицируемых средств защиты, что тоже еще аукнется на первых порах. Испытательные лаборатории не знают многих навороченных штук, которые сегодня внедряются для повышения доверия к средствам защиты и контроля отсутствия вмешательства на этапах поставки и эксплуатации оборудования. При наличии формальных требованиях о верификации неверифицируемых в принципе компонентов (или доверять заявлениям вендора) будут возникать ситуации либо с невозможностью сертификации того или иного продукта, либо с обманом со стороны испытательной лаборатории, которая не захочет терять контракт на и так стагнирующем рынке сертификации.
В целом, надо признать, что ФСТЭК движется в правильном направлении с усилением требований к доверию и оценке соответствия средств защиты, с одним "но". Рынок отечественных решений по ИБ еще не готов к полноценному замещению всей номенклатуры средств защиты, которая представлена преимущественно иностранными вендорами, которые, в свою очередь, уже не могут выполнять все новые требования, которые начинает предъявлять регулятор. Вспоминая известное изречение вождя мирового пролетариата про условия возникновения революционной ситуации ("низы не могут, а верхи не хотят"), мы сейчас находимся в схожем положении - иностранцы не могут, а свои вендоры не хотят. Чем ответит потребитель?
ЗЫ. В заключение хотелось бы раскрыть цитату, вынесенную в заголовок заметки. Ее произнес Дмитрий Шевцов, когда рассказывал о том, как производится сегодня оценка доверия применительно к некоторым иностранным продуктам, производители которых допускают сотрудников испытательных лабораторий к исходному коду только в исподнем, чтобы те не унесли чужую интеллектуальную собственность.
У регулятора достаточно много различных документов, говорящих о доверии, - от профилей защиты информации и РД на НДВ до ГОСТов 54581/2/3, 15408, 18045 и 56939. Все они направлены на то, чтобы удостовериться не только в функциональных возможностях того или иного решения, но и в том, что реализованы они качественно, а разработчик в состоянии поддерживать свое творение в течение всего жизненного цикла продукта.
Поэтому среди элементов доверия, на которые обращает внимания ФСТЭК, есть и действия, которые должны выполняться разработчиком, и свидетельства, доказывающие их исполнение, и действия самого оценщика.
Правильная оценка уровня доверия дает уверенность в том, что функциональные требования безопасности реализованы корректно. Поэтому во всех последних профилях защиты ФСТЭК наращивает требования по обеспечению доверия. Начав с РД на системы обнаружения вторжений и антивирусы эти требования по нарастающей попадают в РД на DLP, межсетевые экраны, операционные системы, СУБД и др.
Однако достаточно сложно становится поддерживать множество разрозненных документов, в которых еще и разные наборы требований к доверию. Поэтому сейчас ФСТЭК завершает работы по унификации соответствующих требований, которые можно было бы:
- поместить в один документ
- использовать для всех типов средств защиты - существующих и планируемых.
Соответственно сейчас на подходе у ФСТЭК находится два документа. Первый - давно обещанная методика поиска уязвимостей и недекларированных возможностей. От старого РД по НДВ будут отказываться - по сути он и так сейчас используется только в тех случаях, когда на средство защиты нет профиля, а требования сертификации присутствует. Учитывая, что требования по отсутствию НДВ уже включены во все профили защиты, то необходимость в таком РД постепенно исчезает. А вот методика поиска НДВ и уязвимостей нужна.
Про методику рассказ подхватил начальник лаборатории ГНИИ ПТЗИ Алексей Сердечный, который подробно описал не только структуру нового документа:
но и методы выявления уязвимостей и недекларированных возможностей, а также их применимость в тех или иных ситуациях, в том числе и учитывая потенциал нарушителя.
Опираясь на методику по поиску уязвимостей, ГОСТы по уязвимостям, по безопасной разработке, требования по обновлению, ФСТЭК готовит второй документ "Требования по безопасности информации, устанавливающие уровни доверия к программному обеспчеению и оборудованию, используемому в государственных органах и организациях" (обратите внимание, и к оборудованию).
В новых документах наконец-то найдут свое отражение требования, которые уже требуются при сертификации, например, межсетевых экранов, и которые могут представлять некоторую проблему для разработчиков, использующих не свое железо.
Кроме этого, некоторые требования вообще непонятно как выполнять, что отчасти и привело к снижению числа сертифицированных МСЭ, о чем я писал на прошлой неделе. Например, в случае наличия подсистемы Secure Boot или специальных ASIC (а это норма для иностранных аппаратных средств защиты), они предотвращают проверку этих подсистем или некоторых защищенных областей внутри них. Как выполнить существующие и формализуемые требования, не совсем понятно :-(
Вообще ФСТЭК стала больше уделять внимания именно аппаратной начинке сертифицируемых средств защиты, что тоже еще аукнется на первых порах. Испытательные лаборатории не знают многих навороченных штук, которые сегодня внедряются для повышения доверия к средствам защиты и контроля отсутствия вмешательства на этапах поставки и эксплуатации оборудования. При наличии формальных требованиях о верификации неверифицируемых в принципе компонентов (или доверять заявлениям вендора) будут возникать ситуации либо с невозможностью сертификации того или иного продукта, либо с обманом со стороны испытательной лаборатории, которая не захочет терять контракт на и так стагнирующем рынке сертификации.
В целом, надо признать, что ФСТЭК движется в правильном направлении с усилением требований к доверию и оценке соответствия средств защиты, с одним "но". Рынок отечественных решений по ИБ еще не готов к полноценному замещению всей номенклатуры средств защиты, которая представлена преимущественно иностранными вендорами, которые, в свою очередь, уже не могут выполнять все новые требования, которые начинает предъявлять регулятор. Вспоминая известное изречение вождя мирового пролетариата про условия возникновения революционной ситуации ("низы не могут, а верхи не хотят"), мы сейчас находимся в схожем положении - иностранцы не могут, а свои вендоры не хотят. Чем ответит потребитель?
ЗЫ. В заключение хотелось бы раскрыть цитату, вынесенную в заголовок заметки. Ее произнес Дмитрий Шевцов, когда рассказывал о том, как производится сегодня оценка доверия применительно к некоторым иностранным продуктам, производители которых допускают сотрудников испытательных лабораторий к исходному коду только в исподнем, чтобы те не унесли чужую интеллектуальную собственность.
22.2.18
Конференция ФСТЭК: новые правила сертификации средств защиты
Как я и обещал вчера, сегодня поговорим о второй части конференции ФСТЭК, посвященной сертификации. Во вчерашнем обзоре достижений российского рынка сертифицированных решений я обратил внимание на снижение числа продуктов, прошедших оценку соответствия и предрек еще большее снижение этого числа, вызванное готовящимися правилами сертификации ФСТЭК, о которых регулятор говорил на конференции на прошлой неделе.
Как мы помним вся сертификация сегодня базируется на артефакте времен перестройки - Постановлении Правительства №608 от 1995 года. 23 года! Немыслимый срок, в течение которого изменилось все (даже Президент) - технологии, производители, руководство ФСТЭК, продукты, угрозы, нарушители, геополитическая ситуация. А подходы к сертификации оставались теми же, что и во время, когда кроме гостайны у нас почти и не было никакой защищаемой информации. В 2010-м году была сделана попытка с выходом 330-м Постановления Правительства, которое регулировало вопросы сертификации средств защиты персданных и государственных информационных ресурсов. Безуспешно. В 2012-м году ФСТЭК попробовала еще раз урегулировать этот вопрос, но уже через информационное сообщение. Правительство же в том же году решило навести порядок с оценкой соответствия, но оставило в стороне тему защиты информации. И вот пришел через для нашего с вами направления деятельности. По решению Совета Безопасности подготовливается новый НПА - "Положение о сертификации продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа по требованиям безопасности информации". Именно о нем и шла речь в докладе Дмитрия Шевцова.
За 23 года накопилось немало проблем в сертификации, поэтому изменений процесса тоже будет немало. Я попробую тезисно выделить некоторые из тех, что мне запомнились из доклада:
Вот такая картина вырисовывается с готовящимися правилами сертификации средств защиты. Стремление ФСТЭК усилить контроль за заявителями и ужесточить требования к сертификации понятно, но оцениваются ли последствия принимаемых решений? Сегодня до сих пор не менее половины средств защиты, используемых теми же госорганами, - это иностранные решения. Если их не станет, то успеет ли российский рынок предложить соответствующую замену? Судя по вчерашнему обзору, отечественные разработчики пока не спешат занять высвобождающуюся нишу.
А вообще с наступающим всех праздником! Ведь это праздник не только защитников Отечества, но и киберзащитников киберотечества :-) Так что с праздником - одним или с двумя сразу!
PS. Я ошибся в заметке, написав про отзыв 4 сертификатов у РНТ, и в частности, у "Форпост". Никакого отзыва не было. Прошу извинений за введение в заблуждение.
За 23 года накопилось немало проблем в сертификации, поэтому изменений процесса тоже будет немало. Я попробую тезисно выделить некоторые из тех, что мне запомнились из доклада:
- До 1-го апреля должно быть разработано новое положение, которое затем уйдет в Правительство и Минюст. Можно предположить, что летом у нас будут новые правила сертификации средств защиты.
- Сроки действия сертификатов будут увеличены до 5 лет. Этот срок распространяется на заявителя. Потребитель, не являющийся заявителем, может эксплуатировать средства защиты вне зависимости от срока действия сертификата при выполнении следующих условий:
- не истек срок эксплуатации, установленный заявителем на сертификацию (при его наличии);
- заявитель осуществляет техническую поддержку сертифицированной продукции;
- применение продукции не противоречит требованиям по защите информации, установленным ФСТЭК;
- ФСТЭК не запретила применение продукции и сведения о сертификате соответствия на продукцию находятся в реестре на сайте регулятора.
- Устанавливаются более жесткие требования к заявителям. Включение требований к потребителям продукции, которые могут быть заявителями. Предъявление новых требований к разработчикам продукции (часто разработчик и заявитель - это разные лица; например, для иностранных средств защиты). Все разработчики средств защиты, зарегистрированные на территории России, должны будут иметь лицензию ФСТЭК на разработку средств защиты.
- ФСТЭК начинает "драть" разработчиков, которые не способны поддерживать сертифицированные изделия. Также ФСТЭК применяет метод "контрольных закупок" через звонки в службы техподдержки производителей от имени потребителей.
- Изменение схем сертификации продукции. Производители средств защиты теперь смогут сертифицировать свои решения только по схеме "серия". Никаких партий или единичных экземпляров. А вот потребители смогут сертифицировать средства защиты только по схемам "единичный экземпляр" или "партия". В целом, это логичное разделение, хотя проблему с огромным количеством сертификатов на один и тот же продукт не решит. Например, на Cisco ASA выдано около 50-60 сертификатов ФСТЭК для разных заявителей. Поддерживать такой зоопарк достаточно сложно.
- Детализация заявки на сертификацию. Если средство защиты иностранного происхождения и разработчик не имеет лицензии ФСТЭК на разработку, то сертификация будет проводиться только при наличии письма от потребителя о необходимости применения такого средства. Это вступает в некоторое противоречие с тем, что разработчик может сертифицировать только по схеме "серия". Но принятый курс на импортозапрещение подсказывает, что по другому и быть не могло. Число сертификаций зарубежных решений еще больше уменьшиться. Не каждый заказчик захочет "подставляться" и писать письмо регулятору с признанием, что хочется применять продукты нероссийского происхождения.
- Установление требований по защите информации ограниченного доступа и коммерческой тайны заявителя.
- Детализация процедур сертификации и установление точных сроков выполнения процедур сертификации. Например, для иностранных продуктов теперь будет требоваться сертификация только на территории России. Вот это требование, я боюсь, поставит крест на сертификации всех иностранных вендоров, которые пока еще тратят деньги на сертификацию в России. Одно дело предоставлять доступ к исходникам (а сейчас почти при любой сертификации это требуется в той или иной степени) или вывозить представителей испытательной лаборатории на место производства, и совсем другое дело - передавать исходные коды испытательной лаборатории (даже при включении в договор требований о сохранности коммерческой тайны). Есть, конечно, вариант с созданием западными вендорами собственных площадок на территории России, но пока этот путь еще никто не проходил и неизвестно вообще возможен ли он юридически?
Вот такая картина вырисовывается с готовящимися правилами сертификации средств защиты. Стремление ФСТЭК усилить контроль за заявителями и ужесточить требования к сертификации понятно, но оцениваются ли последствия принимаемых решений? Сегодня до сих пор не менее половины средств защиты, используемых теми же госорганами, - это иностранные решения. Если их не станет, то успеет ли российский рынок предложить соответствующую замену? Судя по вчерашнему обзору, отечественные разработчики пока не спешат занять высвобождающуюся нишу.
А вообще с наступающим всех праздником! Ведь это праздник не только защитников Отечества, но и киберзащитников киберотечества :-) Так что с праздником - одним или с двумя сразу!
PS. Я ошибся в заметке, написав про отзыв 4 сертификатов у РНТ, и в частности, у "Форпост". Никакого отзыва не было. Прошу извинений за введение в заблуждение.
21.2.18
Является ли облачный провайдер субъектом КИИ?
Вчера в Фейсбуке прошла небольшая дискуссия на тему, является ли облачный провайдер субъектом КИИ, если он обрабатывает данные или хостит системы субъекта КИИ? Вопрос не праздный, так как сегодня многие организации с целью фокусировки на своем основном бизнесе отдают часть своей инфраструктуры или данных внешним провайдерам. А они в свою очередь должны соблюдать требования действующего законодательства. С выполнением ФЗ-152 проблем я не вижу - оператором ПДн является любая организация, обрабатывающая ПДн и устанавливающая цели и задачи обработки. Обработчик ПДн не должен выполнять некоторых обязанностей, присущих оператору, но, например, обеспечивать защиту должен в любом случае. С ФЗ-187 ситуация иная - понятие субъекта очень размытое и не всегда понятно, кто же под него попадает. Вот и давайте попробуем разобраться с этим применительно к облачным провайдерам и субъектам КИИ.
Самая простая ситуация, когда облачный провайдер является одновременно оператором связи. Тогда он просто по определению из ФЗ-187 становится субъектом КИИ и на него распространяются все или часть требований закона (в зависимости от наличия значимых объектов). А вот что делать, например, с облачным провайдером, не имеющим лицензии в области связи, но которому какая-либо финансовая организация, являющаяся субъектом КИИ, доверила обработку каких-либо данных?
Как мне кажется (это мое оценочное суждение) надо внимательно посмотреть определение субъекта КИИ. В рассматриваемом варианте с банком и облаком это юрлицо, которому на праве собственности, аренды или на ином законном основании принадлежит информационная система, функционирующая в банковской сфере. Принадлежит ли банку облачная ИС на праве аренды? В зависимости от модели (IaaS, PaaS или SaaS) да. А есть ли у облачного провайдера ИС, функционирующая в банковской сфере? А вот тут надо смотреть более внимательно. В случае с моделями IaaS и PaaS, я думаю, что нет. А вот в случае с SaaS надо изучать уже функционал конкретной системы. Хотя как мне кажется, даже этот случай не попадает под определение в законе. Иначе придется признать, что разработчик АБС или MS Word, проданного в банк, тоже является субъектом КИИ, а это нонсенс. Мне можно возразить, что в отличие от разработчика АБС, который выпускает только ПО, у облачного провайдера еще и данные обрабатываются. Верно, но ФЗ-187 никак не связан с охраняемой законом информацией. Объектом КИИ является только информационная система, АСУ или сеть связи. Иными словами, получается, что облачный провайдер не является субъектом КИИ, если у него нет лицензии или он не обеспечивает взаимодействие разных систем субъектов КИИ.
Значит ли то, что облачный провайдер - не субъект КИИ, что он не должен выполнять требования к субъектам КИИ? А вот это правильный вопрос. Если банк передает часть своих данных в облако, то это не снимает с него обязанности обеспечить защиту этих данных по требованиям 382-П, 21-го приказа ФСТЭК или ФЗ-187. Это обязанность, от которой нельзя отказаться и нельзя ни на кого переложить - ответственность за нарушение все равно ляжет на банк. Вспомните ФЗ-152. Вы могли привлечь сколь угодно много обработчиков ПДн, но ответственность за утечку ПДн лежала все равно на вас, а не на них. То есть субсидиарная ответственность в данном случае отсутствует и привлечь обработчика ПДн к ответственности можно только, если в договоре с ним прописаны требования, нарушение которых и привело к утечке и данный факт был доказан.
Аналогичная ситуация и с ФЗ-187. Субъект КИИ для облегчения свой жизни может привлекать кого угодно, но ответственность за нарушение ФЗ-187 все равно лежит на нем. Чтобы соблюсти все требования закона банк должен выставить соответствующие требования из подзаконных актов ФСТЭК (если у него есть значимые объекты) облачному провайдеру в рамках договора (если провайдер согласится). И тогда облачный провайдер должен будет соблюдать все требования ФСТЭК, но не потому, что он субъект КИИ, а потому что так написано в договоре между ним и банком.
Отдельно хочется остановиться на вопросе с присоединением облачного провайдера, выполняющего работы для банка, к ГосСОПКЕ. Эта тема вскользь была поднята во время выступления на Уральском форуме Алексея Новикова из Positive Technologies, рассказывающего о расследовании инцидентов в облачной инфраструктуре. Я ему задал вопрос, как он считает, как выполнить требование об отправке данных об инцидентах, произошедших в инфраструктуре облачного провайдера, работающего по договору с банком? К сожалению, он не смог сходу предложить пути решения этой непростой задачи. Я их тоже не вижу. Ответственность за отправку данных лежат на банке, как субъекте КИИ. Требования ФСБ (пока проекты) не подразумевают делегирования этой функции никому, кроме ведомственного или корпоративного центра ГосСОПКИ. Получается, что облачный провайдер должен направлять данные об инцидентах обратно банку, а он уже отправляет их в ГосСОПКУ. Да, это можно полностью автоматизировать, но все равно, цепочка получается непростая.
Вот такие рассуждения получились. Не претендую на истину в последней инстанции; допускаю, что у других специалистов может быть иное мнение. Но возможно какие-то идеи в этой заметке будут полезны. Ну и не забываем, что можно направить свои вопросы ФСТЭК. Хотя законодатели исключили из полномочий ФСТЭК право трактовать ФЗ-187, я думаю, ФСТЭК все равно будет получать множество вопросов о том, кто относится к субъектам КИИ и они будут высказывать свою позицию по данному вопросу.
А если все-таки регулятор решит, что облачный провайдер, работающий с субъектом КИИ, тоже субъект КИИ? Ну тогда мы попадем в ад, когда такими субъектами КИИ будут признаны аутсорсинговые Call Center, ЧОПы, кейтеринговые и клининговые компании, бизнес-центры, фитнесс-центры и т.п. организации, обслуживающие субъектов КИИ и предоставляющие им доступ к своим ИС.
UPDATE: Заметка вызвала некоторую дискуссию в Фейсбуке и Валерий Комаров обратил внимание на следующий момент. Как правильно, отметила Елена Торбенко на конференции, при определении того, является ли организация субъектом КИИ или нет, надо руководствоваться различными классификаторами деятельности. Одним из них является ОКВЭД 2, в котором есть класс 63.11 "Деятельность по обработке данных, предоставление услуг по размещению информации и связанная с этим деятельность". Этот класс ОКВЭД относится к разделу J "Деятельность в области информации и связи". То есть получается, что мои рассуждения не совсем верны. Облачный провайдер сам по себе является субъектом КИИ, работающим в сфере информации и связи, не взирая на то, кто с ним заключает договор и какие услуги он оказывает по договору. Лично для меня это неожиданный поворот, который показывает, что процедура категорирования не так проста, как казалось сначала :-( Я поторопился с выводами. Тут, конечно, можно сказать, что в ФЗ-187 говорится только о сфере связи, а облачный провайдер - это в первую очередь сфера информации, но это уже совсем иная дискуссия, более сложная и долгая. Попробовать пойти по этому пути можно, но с непредсказуемыми последствиями.
Самая простая ситуация, когда облачный провайдер является одновременно оператором связи. Тогда он просто по определению из ФЗ-187 становится субъектом КИИ и на него распространяются все или часть требований закона (в зависимости от наличия значимых объектов). А вот что делать, например, с облачным провайдером, не имеющим лицензии в области связи, но которому какая-либо финансовая организация, являющаяся субъектом КИИ, доверила обработку каких-либо данных?
Как мне кажется (это мое оценочное суждение) надо внимательно посмотреть определение субъекта КИИ. В рассматриваемом варианте с банком и облаком это юрлицо, которому на праве собственности, аренды или на ином законном основании принадлежит информационная система, функционирующая в банковской сфере. Принадлежит ли банку облачная ИС на праве аренды? В зависимости от модели (IaaS, PaaS или SaaS) да. А есть ли у облачного провайдера ИС, функционирующая в банковской сфере? А вот тут надо смотреть более внимательно. В случае с моделями IaaS и PaaS, я думаю, что нет. А вот в случае с SaaS надо изучать уже функционал конкретной системы. Хотя как мне кажется, даже этот случай не попадает под определение в законе. Иначе придется признать, что разработчик АБС или MS Word, проданного в банк, тоже является субъектом КИИ, а это нонсенс. Мне можно возразить, что в отличие от разработчика АБС, который выпускает только ПО, у облачного провайдера еще и данные обрабатываются. Верно, но ФЗ-187 никак не связан с охраняемой законом информацией. Объектом КИИ является только информационная система, АСУ или сеть связи. Иными словами, получается, что облачный провайдер не является субъектом КИИ, если у него нет лицензии или он не обеспечивает взаимодействие разных систем субъектов КИИ.
Значит ли то, что облачный провайдер - не субъект КИИ, что он не должен выполнять требования к субъектам КИИ? А вот это правильный вопрос. Если банк передает часть своих данных в облако, то это не снимает с него обязанности обеспечить защиту этих данных по требованиям 382-П, 21-го приказа ФСТЭК или ФЗ-187. Это обязанность, от которой нельзя отказаться и нельзя ни на кого переложить - ответственность за нарушение все равно ляжет на банк. Вспомните ФЗ-152. Вы могли привлечь сколь угодно много обработчиков ПДн, но ответственность за утечку ПДн лежала все равно на вас, а не на них. То есть субсидиарная ответственность в данном случае отсутствует и привлечь обработчика ПДн к ответственности можно только, если в договоре с ним прописаны требования, нарушение которых и привело к утечке и данный факт был доказан.
Аналогичная ситуация и с ФЗ-187. Субъект КИИ для облегчения свой жизни может привлекать кого угодно, но ответственность за нарушение ФЗ-187 все равно лежит на нем. Чтобы соблюсти все требования закона банк должен выставить соответствующие требования из подзаконных актов ФСТЭК (если у него есть значимые объекты) облачному провайдеру в рамках договора (если провайдер согласится). И тогда облачный провайдер должен будет соблюдать все требования ФСТЭК, но не потому, что он субъект КИИ, а потому что так написано в договоре между ним и банком.
Отдельно хочется остановиться на вопросе с присоединением облачного провайдера, выполняющего работы для банка, к ГосСОПКЕ. Эта тема вскользь была поднята во время выступления на Уральском форуме Алексея Новикова из Positive Technologies, рассказывающего о расследовании инцидентов в облачной инфраструктуре. Я ему задал вопрос, как он считает, как выполнить требование об отправке данных об инцидентах, произошедших в инфраструктуре облачного провайдера, работающего по договору с банком? К сожалению, он не смог сходу предложить пути решения этой непростой задачи. Я их тоже не вижу. Ответственность за отправку данных лежат на банке, как субъекте КИИ. Требования ФСБ (пока проекты) не подразумевают делегирования этой функции никому, кроме ведомственного или корпоративного центра ГосСОПКИ. Получается, что облачный провайдер должен направлять данные об инцидентах обратно банку, а он уже отправляет их в ГосСОПКУ. Да, это можно полностью автоматизировать, но все равно, цепочка получается непростая.
Вот такие рассуждения получились. Не претендую на истину в последней инстанции; допускаю, что у других специалистов может быть иное мнение. Но возможно какие-то идеи в этой заметке будут полезны. Ну и не забываем, что можно направить свои вопросы ФСТЭК. Хотя законодатели исключили из полномочий ФСТЭК право трактовать ФЗ-187, я думаю, ФСТЭК все равно будет получать множество вопросов о том, кто относится к субъектам КИИ и они будут высказывать свою позицию по данному вопросу.
А если все-таки регулятор решит, что облачный провайдер, работающий с субъектом КИИ, тоже субъект КИИ? Ну тогда мы попадем в ад, когда такими субъектами КИИ будут признаны аутсорсинговые Call Center, ЧОПы, кейтеринговые и клининговые компании, бизнес-центры, фитнесс-центры и т.п. организации, обслуживающие субъектов КИИ и предоставляющие им доступ к своим ИС.
UPDATE: Заметка вызвала некоторую дискуссию в Фейсбуке и Валерий Комаров обратил внимание на следующий момент. Как правильно, отметила Елена Торбенко на конференции, при определении того, является ли организация субъектом КИИ или нет, надо руководствоваться различными классификаторами деятельности. Одним из них является ОКВЭД 2, в котором есть класс 63.11 "Деятельность по обработке данных, предоставление услуг по размещению информации и связанная с этим деятельность". Этот класс ОКВЭД относится к разделу J "Деятельность в области информации и связи". То есть получается, что мои рассуждения не совсем верны. Облачный провайдер сам по себе является субъектом КИИ, работающим в сфере информации и связи, не взирая на то, кто с ним заключает договор и какие услуги он оказывает по договору. Лично для меня это неожиданный поворот, который показывает, что процедура категорирования не так проста, как казалось сначала :-( Я поторопился с выводами. Тут, конечно, можно сказать, что в ФЗ-187 говорится только о сфере связи, а облачный провайдер - это в первую очередь сфера информации, но это уже совсем иная дискуссия, более сложная и долгая. Попробовать пойти по этому пути можно, но с непредсказуемыми последствиями.
Анализ реестра сертифицированных средств защиты ФСТЭК за 2017 год
Чуть больше года назад я провел блиц-анализ реестра сертифицированных средств защиты информации ФСТЭК за интервал 2012-2016 годов (часть 1 и 2). И вот в предверие конференции ФСТЭК "Актуальные вопросы защиты информации" я решил проанализировать изменения, произошедшие в реестре за ушедший год. Мой особенный интерес был связан с вопросом, как меняется поведение игроков отечественного рынка ИБ в условиях санкций и импортозапрещения.
Основной тенденцией прошедшего года стало существенное (трехкратное) сокращение числа иностранных средств защиты, получивших сертификаты ФСТЭК. На мой взгляд это обусловлено несколькими причинами:
Вообще динамика сертификации традиционных средств защиты выглядит не очень позитивно - число сертифицированных решений неуклонно снижается, что связано, на мой взгляд, с серьезным ужесточением требований ФСТЭК по оценке соответствия. Даже российские компании не всегда в состоянии их выполнить, не говоря уже об "иностранцах". А уж поддерживать сертифицированное решение в актуальном состоянии и вовсе задача неподъемная для многих.
Из отдельных тенденций я бы отметил еще следующее:
И надо признать, что ситуация будет только хуже. Во-первых, ФСТЭК еще больше ужесточает требования по сертификации (про это я напишу завтра). Во-вторых, заказчики не имеют возможности брать то, что им нужно. Иностранное они не могут, а отечественного просто нет (я даже не говорю, когда отечественное хуже, а именно про те ситуации, когда отечественного вообще нет). В-третьих, иностранные вендоры боятся или физически не могут сертифицировать свои продукты в России. В-четвертых, на развитие отечественной ИБ-отрасли денег как не выделяли, так и не выделяют.А тут еще грядет цифровая экономика, для которой нужно еще больше ИТ/ИБ-решений, чем было раньше. И где их брать при существующих требованиях по ИБ, выставленных государством? Если на 2018-й год программа "Цифровой экономики" по направлению ИБ требует 5 миллиардов рублей, то правительство выделило всего 500 миллионов. И что на эти деньги можно сделать? Ничего :-(
ЗЫ. Снижение числа сертификаций означает еще и тот факт, что у испытательных лабораторий могут начать сложности с финансированием, что приведет либо к сокращению числа лабораторий, либо к увеличению цен на сертификацию, либо к снижению качества сертификации при тех же ценах. И все эти варианты непозитивны :-(
Основной тенденцией прошедшего года стало существенное (трехкратное) сокращение числа иностранных средств защиты, получивших сертификаты ФСТЭК. На мой взгляд это обусловлено несколькими причинами:
- ужесточение требований по сертификации (и дальше будет только хуже, но об этом в следующей заметке)
- курс на импортозапрещение и нежелание иностранных игроков бессмысленно тратить деньги на то, что невостребовано заказчиками.
Логично было бы предположить, что российские компании воспользуются возможностью и начнут активно разрабатывать (тем более, что с введения санкций прошло уже 4 года - достаточный срок для создания средства защиты) новые типы средств кибербезопасности. Увы. И хотя общее число сертификатов на отечественные СрЗИ чуть выросло по сравнению с предыдущими годами, новых средств так и не появилось. Повторюсь, что на гистограмме ниже показаны цифры для традиционных средств защиты информации - всякие защитные фольги, генераторы шума, системы защиты локомотивов и т.п. я в эти цифры не включал.
Вообще динамика сертификации традиционных средств защиты выглядит не очень позитивно - число сертифицированных решений неуклонно снижается, что связано, на мой взгляд, с серьезным ужесточением требований ФСТЭК по оценке соответствия. Даже российские компании не всегда в состоянии их выполнить, не говоря уже об "иностранцах". А уж поддерживать сертифицированное решение в актуальном состоянии и вовсе задача неподъемная для многих.
Очевидно, что санкции повлияли на общее число сертификатов, выданных ФСТЭК, с небольшим преимуществом для российских компаний.
Из отдельных тенденций я бы отметил еще следующее:
- за прошедший год в России не было сертифицировано ни одного промышленного МСЭ и это несмотря на активную шумиху вокруг темы защиты АСУ ТП и безопасности КИИ
- прикладных МСЭ (класс В) сертифицировано всего... 1 изделие, а всего по новым требованиям к МСЭ было выдано 8 сертификатов по классу А и 4 - по классу Б
- систем обнаружения атак было сертифицировано по 3 каждого класса = сетевого и хостового
- несмотря на шумиху вокруг темы SOC и активную разработку отечественных SIEM, сертификат на данные типы средств (необходимы для получения лицензий ФСТЭК на мониторинг ИБ) был выдан всего 1 (на MaxPatrol SIEM)
- а вот IDMов было сертифицировано целых 5 - и отечественных, и иностранных
- из отечественных офисных решений заветную бумажку получил только "МойОфис", отечественное сетевое оборудование отметилось всего одним сертификатом ФСТЭК (на Cisco при этом было выдано около десятка сертификатов), а также было сертифицирована одна "отечественная" ОС (Нейтрино). Известные Альт Линукс и некая EcoRouter были сертифицированы почему-то как СВТ. И если для Альт Линукс это еще можно понять (хотя РД на ОС уже были), то сетевая ОС как СВТ?.. Это за гранью.
И надо признать, что ситуация будет только хуже. Во-первых, ФСТЭК еще больше ужесточает требования по сертификации (про это я напишу завтра). Во-вторых, заказчики не имеют возможности брать то, что им нужно. Иностранное они не могут, а отечественного просто нет (я даже не говорю, когда отечественное хуже, а именно про те ситуации, когда отечественного вообще нет). В-третьих, иностранные вендоры боятся или физически не могут сертифицировать свои продукты в России. В-четвертых, на развитие отечественной ИБ-отрасли денег как не выделяли, так и не выделяют.А тут еще грядет цифровая экономика, для которой нужно еще больше ИТ/ИБ-решений, чем было раньше. И где их брать при существующих требованиях по ИБ, выставленных государством? Если на 2018-й год программа "Цифровой экономики" по направлению ИБ требует 5 миллиардов рублей, то правительство выделило всего 500 миллионов. И что на эти деньги можно сделать? Ничего :-(
ЗЫ. Снижение числа сертификаций означает еще и тот факт, что у испытательных лабораторий могут начать сложности с финансированием, что приведет либо к сокращению числа лабораторий, либо к увеличению цен на сертификацию, либо к снижению качества сертификации при тех же ценах. И все эти варианты непозитивны :-(
20.2.18
#ibbank Удаленная биометрическая идентификация и ее обход мошенниками, использующими нейросети
На Уральском форуме очень много говорилось о том, как полезна и удобна удаленная биометрическая идентификация с точки зрения клиента, а у банков появляется новая возможность для зарабатывания денег, потому что увеличивается число клиентов, которые смогут проходить идентификацию без физического присутствия в отделении банка. Особенно много может появиться таких клиентов из удаленных регионов, где физически сложно присутствовать в отделении кредитной организации для проведения тех или иных операций.
докладчики перешли к примерам угроз для систем биометрической идентификации:
а потом немного коснулись темы применения искусственного интеллекта... нет, не в средствах защиты, а наоборот, мошенниками и киберпреступниками:
А перед описанием защиты от такого рода угроз был дан неплохой обзор (хотя и короткий) особенностей средств биометрической идентификации и того, как они принимают решения о достоверности представленных биометрических данных и их совпадении с имещимся в хранилище эталонным образцом. Там тоже есть множество нюансов, которые могут превратить национальную систему идентификации в тыкву, если не подумать о нивелировании этих рисков.
Но к сожалению, о безопасности удаленной биометрической идентификации на форуме не говорилось. То ли потому, что сказать пока нечего, то ли потому, что никто не хотел привлекать внимание к тому, как можно обойти систему, которая может стать одним из центральных звеньев будущей стратегии развития ЦБ. Хорошим финалом для этой темы (или промежуточной точкой) стал доклад Алексея Сабанова из Аладдина, который привел ссылки на большое количество международных стандартов по идентификации и аутентификации, в которых прямо написано, что биометрия не является надежным методом идентификации и не должен использоваться как единственный механизм проверки подлинности гражданина, получающего доступ к финансовым услугам. "Безопасность биометрии сродни домофону", так закончил свой доклад Алексей Сабанов и также хочу завершить заметку и я.
Но совершенно неозвученной оказалась тема безопасности хранилища биометрических данных, применяемых для удаленной идентификации. Да и вообще тема безопасности самой биометрической идентификации осталась незаслуженно обойденной вниманием. Но в отличие от хранилища биометрических паспортов, доступ к которому имеет ограниченное количество лиц, к базе биометрических данных всех граждан Российской Федерации в ЕСИА получают доступ все банки, Почта России и другие организации. А значит риски возрастают многократно. И если в случае кражи или подмены обычного логина и пароля их легко заменить, то заменить биометрические данные становится проблематично.
В этом контексте мне понравился мастер-класс, который на пару вели представители Информзащиты и Oz Forensics. Это, кстати, был единственный пример, когда выступление было разделено между двумя спикерами, играющими свои роли, которые передавали друг другу слово по мере рассказа.
Начав с исторического экскурса в историю фальсификации фотографий:
докладчики перешли к примерам угроз для систем биометрической идентификации:
а потом немного коснулись темы применения искусственного интеллекта... нет, не в средствах защиты, а наоборот, мошенниками и киберпреступниками:
А перед описанием защиты от такого рода угроз был дан неплохой обзор (хотя и короткий) особенностей средств биометрической идентификации и того, как они принимают решения о достоверности представленных биометрических данных и их совпадении с имещимся в хранилище эталонным образцом. Там тоже есть множество нюансов, которые могут превратить национальную систему идентификации в тыкву, если не подумать о нивелировании этих рисков.
Конференция ФСТЭК: критическая инфраструктура
На прошлой неделе в Москве прошла конференция ФСТЭК "Актуальные вопросы защиты информации", которая была посвящена 4-м основным направлениям, которые будут главенствовать у нашего регулятора в ближайшей перспективе:
Эта заметка будет посвящена первому направлению - безопасности критической информационной инфраструктуры, регулятором по которой в конце прошлого года была назначена ФСТЭК России. По данному направлению от ФСТЭК выступало 4 сотрудника, которые рассказали о своем видении того, что будет драйвить рынок ИБ в России в ближайшее время. Позволю себе тезисно повторить то, что говорилось на конференции (в дополнение к ответам на те вопросы, что давала ФСТЭК в рамках конференции):
Эта заметка будет посвящена первому направлению - безопасности критической информационной инфраструктуры, регулятором по которой в конце прошлого года была назначена ФСТЭК России. По данному направлению от ФСТЭК выступало 4 сотрудника, которые рассказали о своем видении того, что будет драйвить рынок ИБ в России в ближайшее время. Позволю себе тезисно повторить то, что говорилось на конференции (в дополнение к ответам на те вопросы, что давала ФСТЭК в рамках конференции):
- По словам Дмитрия Шевцова ФСТЭК утвердила 5 приказов, 2 из которых уже утверждены Минюстом, а 3 проходят эту процедуру сейчас.
- Проект Постановления Правительства по надзору скоро должен быть принят несмотря на отрицательную оценку на портале regulation.gov.ru. Но как показывает практика это врядли повлият на принятие - документ примут. Он устанавливает общие правила надзора со стороны ФСТЭК по данной теме. Я более чем уверен, что ФСТЭК не будет повторять путь РКН и не начнет расширять перечень оснований для проведения плановых и внеплановых проверок.
- Несмотря на то, что первые плановые проверки ФСТЭК начнет проводить только через 3 года после внесения значимого объекта в реестр объектов КИИ (то есть спустя минимум 4 года с текущего момента), не стоит думать, что субъекты КИИ могут расслабиться. Существуют еще прокурорские проверки, которые по данной теме проводились, проводятся и будут проводиться достаточно активно.
- Утвержденные приказы ФСТЭК большой акцент делают на оценке соответствия средств защиты информации объектов КИИ и самих значимых объектов КИИ. Обратите внимание, что обязательная сертификация для средств защиты не требуется - по решению субъекта КИИ или в случаях, установленных законодательством (например, если объект КИИ = ГИС). В остальных случаях оценка соответствия средств защиты осуществляется в форме испытаний или приемки.
- Никаких документов, регламентирующих испытания и приемку средств защиты, разрабатывать не предполагается. ФСТЭК всех отправляет к ФЗ-184 о техническом регулировании и к соответствующим ГОСТам по формам оценки соответствия автоматизированных систем, подробно рассматривающим данный вопрос, но в более широком контексте.
- Оценка соответствия самого объекта осуществляется в форме приемочных испытаний (никак не регулируется) или в форме аттестации, если объект КИИ является ГИС или если субъект КИИ принял такое решение.
- Если объект КИИ является ГИС, ИСПДн или АСУ ТП, то наряду с документами ФСТЭК по КИИ должны применяться уже имеющиеся документы по ГИС, ИСПДн и АСУ ТП соответственно. С 31-м приказом ситуация следующая. Если объект значимый, то применяется приказ ФСТЭК по КИИ, а если незначимый, то 31-й приказ. При этом никто не запрещает для незначимых объектов АСУ ТП также применять приказ ФСТЭК по КИИ, а для значимых - дополнять требования приказа ФСТЭК по КИИ требованиями 31-го приказа, который гораздо лучше учитывает специфику АСУ ТП, чем общий приказ по КИИ.
- Во второй половине 2018-го года планируется выпустить единую методичку ФСТЭК по мерам защиты, которая придет на смену существующей методичке по мерам защиты в ГИС. Будет единое описание мер защиты для всех открытых приказов ФСТЭК.
- На животрепещущий вопрос о том, кто является субъектом КИИ, ФСТЭК в лице Елены Торбенко привела рекомендацию на иллюстрации ниже. Она работает в тех случаях, когда организация четко не ложится в 12/13 отраслей, упомянутых в ФЗ-187. Но надо четко для себя уяснить, что финального списка субъектов КИИ нет и быть не может.
- Категорирование объектов КИИ осуществляется по процедуре и в порядке, описанных в ПП-127, утвержденном 8-го февраля и опубликованном 13-го февраля.
- Я вновь, уже в третий раз вернусь к непростой теме, связанной с составлением перечня объектов КИИ, который должен согласовываться с отраслевым регулятором. Как и советовал Дмитрий Шевцов, во всех спорных случаях надо проконсультироваться с ФСТЭК по адресу: otd22@fstec.ru, что я и сделал. В результате общения с регулятором вырисовывается следующая блок-схема для 15-го пункта ПП-127. В финальной версии ПП-127 ряд важных фрагментов убрали, но если обратить внимание на проект Постановления Правительства, то начинается все с составления перечня объектов КИИ. Потом процедура раздваивается в зависимости от того, кем является субъект КИИ, - подведомственным предприятием для ФОИВ или госкорпораций и иных юрлиц или обычной коммерческой структурой. Если первое, то перечень должен быть сначала согласован с отраслевым регулятором, например, с Минпромторгом или Росатомом или Роскосмосом. А, например, банки не должны ничего согласовывать с ЦБ (даже несмотря на заявления представителя Аппарата Правительства на Уральском форуме). И энергетики не должны. И операторы связи не должны. Затем наступает процедура утверждения перечня в разумные сроки после его составления. Согласно правилам подготовки и прочтения НПА если в отношении какой-либо нормы нет особого указания о сроках ее действия, то она вступает в силу с момента вступления в силу самого НПА. В проекте ПП-127 говорилось о шести месяцах; в финале этот срок убрали. Значит перечень должен быть утвержден к моменту вступления в силу ПП-127. то есть к 20-му (а не 23-му) февраля. Да, это нелогично и невыполнимо, но так есть. После утверждения перечня, в течение пяти дней он направляется в ФСТЭК.
- Версия с согласованием перечня только подведомственными предприятиями подтверждается и текстом самого ПП-127, и презентацией Елены Торбенко, где перечисляются некоторые лица, с которыми согласовывался проект ПП-127.
- В соцсетях сейчас активно идет обсуждения срока подготовки перечня объектов КИИ и разговоры о том, что раз сроков нет, то и выполнение этой задачи можно растянуть на неограниченное количество времени. Я бы хотел напомнить всем про ФЗ-152, в котором тоже нигде ни для какой процедуры не установлены сроки их реализации. Но ни у кого не возникало вопросов по поводу моделирования угроз, утверждения перечня ПДн, назначения ответственных и т.п. Закон вступил в силу и все пошли его выполнять. И, кстати, закон тоже был отсроченного действия (вступал в силу через 180 дней поле принятия) и до момента вступления в силу никто даже не парился на тему его выполнения. Правда и потом никто не парился - все напряглись только после принятия четверокнижия ФСТЭК. В случае с ФЗ-187 ровно такая же ситуация со сроками. И не забывайте, что помимо ФСТЭК надзором занимается еще и прокуратура и будет сложно объяснять прокурору, пришедшему с проверкой, что перечня объектов нет, потому что непонятны сроки выполнения задачи. Также прокуроров мало волновал статус 31-го приказа ФСТЭК по АСУ ТП - они просто наказывали энергетиков за его неисполнение. Поэтому выводы делайте сами. Я лично не вижу большой проблемы в составлении перечня объектов КИИ. Тут могут сильно помочь уже проведенные классификации ГИС, ИСПДн, АСУ ТП, КСИИ, ИСИОД, ИСОП и т.п.
- После категорирования материалы направляются в ФСТЭК и информация вносится в реестр или просто принимается к сведению, если объект незначимый и у ФСТЭК нет претензий к выставленным категориям.
Вот, примерно так выглядела часть конференции ФСТЭК, посвященная безопасности КИИ в моей интерпретации.
19.2.18
#ibbank Финансовая организация как КИИ
В последний день Уральского форума прошла сессия, посвященная критической информационной инфраструктуре в разрезе финансового рынка. Я не буду пересказывать все доклады этой сессии, коснусь только выступления Андрея Выборнова из ГУБиЗИ Банка России, который осветил взгляд регулятора на применение ФЗ-187 к финансовым организациям. Тезисно, я бы отметил следующее:
- Все финансовые организации без исключения являются субъектами КИИ и обязаны будут подключаться к ГосСОПКЕ
- Информационные системы банков, страховых, микрофинансовых организаций, бирж и т.п., включая АБС, ДБО, Интернет-банк, CRM, HRM и т.д. являются объектами КИИ. Часть из них является значимыми объектами, а часть нет. Для отнесения объектов к значимым или нет используется ПП-127, принятое 8 февраля, а вступающее в силу 20 февраля (через 7 дней после опубликования).
- Категорировать объекты надо не всем субъектам КИИ, а тем, кто перечислен в моей заметке. У остальных будут незначимые объекты, о чем можно сразу и уведомить регулятора.
- Все значимые объекты должны защищаться по требованиям ФСТЭК (приказы №235 и №239). По мнению ЦБ принятый СТО и планируемый к обязательному применению ГОСТ 57580.1 закрывают все требования приказов ФСТЭК. На мой взгляд это не совсем так - есть требования, которые документами ЦБ не закрываются (хотя в массе своей это так). Например, в части выбора средств защиты информации и компаний, оказывающих для этих средств техническую поддержку.
- Все финансовые организации как субъекты КИИ должны присоединиться к ГосСОПКЕ для отправки в нее информации об инцидентах.
- Есть тонкий момент, на который я бы хотел обратить внимание еще раз. В настоящий момент ФинЦЕРТ не является ни корпоративным, ни ведомственным центром ГосСОПКИ. С юридической точки зрения. На форуме прозвучало, что сейчас ведется работа по получению ФинЦЕРТом более официального статуса в ГосСОПКЕ. Пока же тема передачи информации об инцидентах остается незакрытой. Надо ли дублировать данные в ФинЦЕРТ и ГосСОПКУ или достаточно только передавать данные в ФинЦЕРТ, а он сам будет передавать данные в ФСБ? Будет ли ФСБ требовать жесткого соблюдения закона или даст возможность на переходный период работать финансовым организациям через ФинЦЕРТ? Нет ответа на эти вопросы. Представителей ГосСОПКИ на мероприятии вообще не было, а ЦБ пока не имеет готового ответа.
- Последний момент касается сюрприза, прозвучавшего на конференции ФСТЭК, о том, что субъекты КИИ должны отправить отраслевому регулятору перечень объектов КИИ до 23-го февраля 2018-го года. По версии регулятора этот перечень должен готовиться только подведомственными организациями, которые есть далеко не у всех (преимущественно ФОИВы и госкорпорации). Это, конечно, тоже не сахар, но хотя бы коммерческие субъекты КИИ останутся вне этого требования. Однако на Уральском форуме поправки в эту точку зрения внес Аппарат Правительства, представитель которого заявил, что все субъекты КИИ без исключения должны составлять перечень и отправлять его своему отраслевому регулятору. Правда, на вопрос, сколько времени нужно на составление перечня, "аппаратчик" заявил, что по его мнению, не менее шести месяцев (как и было в проекте ПП-127). На вопрос о 23-м февраля он не смог ничего ответить. В итоге мы имеем очередную темную зону законодательства о безопасности КИИ, которая возникла из-за низкого качества ФЗ и подзаконных актов, возникших в свою очередь из-за сверхмалых сроков подготовки всех НПА и нежелания инициаторов закона прислушиваться к мнению экспертов, которые указывали на многие косяки, которые мы сейчас разгребаем.
В качестве резюме просто порекомендую финансовым организациям внимательнее присмотреться к ФЗ-187 и подзаконным актам. Эта тема в ближайший год станет достаточно актуальной для многих финансовых структур.