На пленарной сессии Председатель ЦБ РФ Набиуллина Эльвира Сахипзадовна выделила несколько важнейших направлений по развитию ИБ в банковской сфере:
Было отмечено, что за последний год увеличилась доля возмещения средств людям, пострадавшим в кибермошенничестве - с 4,9 до 7,8 процентов. Увеличилось и количество атак, успешно отраженных банками и иными финансовыми организациями. Однако, клиенты до сих пор уязвимы и это значит, что еще многие вопросы недостаточно проработаны.
На фото специалисты Deiteriy обсуждают с Эльвирой Сахипзадовной методики проведения тестирования на проникновение и анализа уязвимостей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Множество обсуждений посвящено борьбе с дропперами и созданию общей системы антифрода с единой базой злоумышленников.
В ходе пленарной сессии было предложено объединить усилия финансовых организаций, чтобы блокировать выявленных мошенников не только в рамках одной организации, но и лишить их возможности вывода украденных средств через любые финансовые институты.
Уже сейчас разрабатываются регулирующие нормативные документы и технические решения, например, системы антифрода на основе искусственного интеллекта или защита от подмены телефонных номеров.
Однако, новым вызовом является социальная инженерия с DeepFake, практика борьбы с которой пока только формируется.
«Мы стали ближе. Мы стали взаимодействовать на совершенно другом уровне. И эту тенденцию нужно развивать!», - один из ключевых тезисов пленарной сессии Уральского форума.
Please open Telegram to view this post
VIEW IN TELEGRAM
На сессии «Аутсорсинг информационных технологий и использование облачных сервисов» участники, в том числе представители ЦБ РФ, Государственной Думы ФС РФ, Национального совета финансового рынка, Ассоциации банков России и облачных сервисов, сделали акцент на том, что для аутсорсинга не хватает правовой основы. Это связано с тем, что финансовые организации, привлекающие различных поставщиков услуг, работают не только с персональными данными, но и банковской тайной.
Сложность заключается в том, что необходимо учесть интересы всех сторон. Ответственность при таком взаимодействии должна разделяться между финансовой организацией и поставщиком услуг.
Представители облачных решений заявили, что их не пугает такая ответственность и они готовы работать с финансовым рынком, поэтому активно участвуют в разработке законопроектов.
Важным вектором развития остается оценка рисков при взаимодействии с поставщиками услуг. Необходимо явно задокументировать определение аутсорсинга и требования к содержанию договора между банками и компаниями, предоставляющими различные сервисы.
ЦБ РФ также предложил первично установить саморегулирование, то есть попробовать рассмотреть внедрение не законов, а стандартов, тем самым снизив регуляторную нагрузку.
Национальный совет финансового рынка считает, что нужен компромисс, например, рекомендации от регуляторов с популяризацией лучших практик.
Сложность заключается в том, что необходимо учесть интересы всех сторон. Ответственность при таком взаимодействии должна разделяться между финансовой организацией и поставщиком услуг.
Представители облачных решений заявили, что их не пугает такая ответственность и они готовы работать с финансовым рынком, поэтому активно участвуют в разработке законопроектов.
Важным вектором развития остается оценка рисков при взаимодействии с поставщиками услуг. Необходимо явно задокументировать определение аутсорсинга и требования к содержанию договора между банками и компаниями, предоставляющими различные сервисы.
ЦБ РФ также предложил первично установить саморегулирование, то есть попробовать рассмотреть внедрение не законов, а стандартов, тем самым снизив регуляторную нагрузку.
Национальный совет финансового рынка считает, что нужен компромисс, например, рекомендации от регуляторов с популяризацией лучших практик.
Защита субъектов КИИ: прогноз на 2024 год
За пару месяцев 2024 года наблюдаем резкий прирост вопросов по 187-ФЗ. Заметно, что регуляторы усиливают контроль субъектов критической информационной инфраструктуры (КИИ) не только в финансовой индустрии.
По сложившейся традиции на Уральском форуме данным вопросам была посвящена отдельная сессия «Обеспечение безопасности значимых объектов критической информационной инфраструктуры». Среди рассматриваемых вопросов особое внимание было уделено новым угрозам в отношении субъектов КИИ, среди которых были рассмотрены атаки на цепочки поставок. В качестве решений были названы:
- обеспечение технологической независимости;
- обеспечение безопасного жизненного цикла всех элементов КИИ, включая безопасную разработку.
Отдельным вопросом рассмотрели влияние разработчиков и подрядчиков на безопасность субъектов КИИ. Практика показывает, что компании пренебрегают обработкой рисков, связанных с их влиянием.
Заместитель директора ФСТЭК Лютиков Виталий Сергеевич рассказал о проекте документа по сертификации процессов разработки для субъектов КИИ.
Помимо разработки собственного программного обеспечения субъектами КИИ, обсудили безопасность использования Open Source решений.
В текущих реалиях необходимо приложить много усилий, чтобы убедиться в их безопасности. Сейчас каждая организация делает это самостоятельно, независимо от других. Была высказана идея о том, что эффективнее было бы объединить усилия, организовать данный процесс и делиться результатами друг с другом.
Говоря об импортозамещении, Виталий Лютиков отметил, что переход на отечественные решения неизбежен, а все мысли о том, что зарубежные вендоры вернутся и можно будет снова использовать их решения, стоит отбросить.
На вопрос о том, стоит ли субъектам КИИ ожидать изменений в требованиях по защите своих объектов, представитель регулятора ответил, что требования Приказов ФСТЭК №235 и №239 в будущем будут меняться, но концептуально останутся теми же. Подобных изменений в ближайший год ожидать не стоит.
За пару месяцев 2024 года наблюдаем резкий прирост вопросов по 187-ФЗ. Заметно, что регуляторы усиливают контроль субъектов критической информационной инфраструктуры (КИИ) не только в финансовой индустрии.
По сложившейся традиции на Уральском форуме данным вопросам была посвящена отдельная сессия «Обеспечение безопасности значимых объектов критической информационной инфраструктуры». Среди рассматриваемых вопросов особое внимание было уделено новым угрозам в отношении субъектов КИИ, среди которых были рассмотрены атаки на цепочки поставок. В качестве решений были названы:
- обеспечение технологической независимости;
- обеспечение безопасного жизненного цикла всех элементов КИИ, включая безопасную разработку.
Отдельным вопросом рассмотрели влияние разработчиков и подрядчиков на безопасность субъектов КИИ. Практика показывает, что компании пренебрегают обработкой рисков, связанных с их влиянием.
Заместитель директора ФСТЭК Лютиков Виталий Сергеевич рассказал о проекте документа по сертификации процессов разработки для субъектов КИИ.
Помимо разработки собственного программного обеспечения субъектами КИИ, обсудили безопасность использования Open Source решений.
В текущих реалиях необходимо приложить много усилий, чтобы убедиться в их безопасности. Сейчас каждая организация делает это самостоятельно, независимо от других. Была высказана идея о том, что эффективнее было бы объединить усилия, организовать данный процесс и делиться результатами друг с другом.
Говоря об импортозамещении, Виталий Лютиков отметил, что переход на отечественные решения неизбежен, а все мысли о том, что зарубежные вендоры вернутся и можно будет снова использовать их решения, стоит отбросить.
На вопрос о том, стоит ли субъектам КИИ ожидать изменений в требованиях по защите своих объектов, представитель регулятора ответил, что требования Приказов ФСТЭК №235 и №239 в будущем будут меняться, но концептуально останутся теми же. Подобных изменений в ближайший год ожидать не стоит.
Объявляем конкурс докладов для #PAYMENTSECURITY!
Для участия необходимо направить темы и тезисы на электронную почту: cfp@paymentsecurity.ru.
Каждая заявка будет рассмотрена программным комитетом, который выберет лучшие из них.
☑️ Заявки принимаются до 7 июня 2024 года.
☑️ Длительность доклада может быть 20 или 40 минут.
☑️ Доклад не должен быть рекламным.
☑️ К заявке можно приложить любые материалы, которые помогут комитету оценить доклад.
Спикерам, чьи доклады получат одобрение программного комитета, мы оплатим дорогу до Санкт-Петербурга и обратно, а также вручим два билета на конференцию, чтобы можно было позвать друга.
Воспользуйтесь возможностью заявить о себе, исследовать что-то новое и поделиться своим опытом с заинтересованной публикой.
Ждем ваши заявки на cfp@paymentsecurity.ru!
Для участия необходимо направить темы и тезисы на электронную почту: cfp@paymentsecurity.ru.
Каждая заявка будет рассмотрена программным комитетом, который выберет лучшие из них.
☑️ Заявки принимаются до 7 июня 2024 года.
☑️ Длительность доклада может быть 20 или 40 минут.
☑️ Доклад не должен быть рекламным.
☑️ К заявке можно приложить любые материалы, которые помогут комитету оценить доклад.
Спикерам, чьи доклады получат одобрение программного комитета, мы оплатим дорогу до Санкт-Петербурга и обратно, а также вручим два билета на конференцию, чтобы можно было позвать друга.
Воспользуйтесь возможностью заявить о себе, исследовать что-то новое и поделиться своим опытом с заинтересованной публикой.
Ждем ваши заявки на cfp@paymentsecurity.ru!
Мы продолжаем делать мир чуточку безопаснее 🙌🏻
Недавно одна из наших пентестеров выявила ряд уязвимостей в системе управления веб-проектами 1С-Битрикс.
Одной из них присвоен идентификатор BDU:2024-01501.
Также на хабре вышла наша статья, где мы подробно рассказываем про обнаруженные уязвимости.
Поздравляем, Ксюша!🎉
Недавно одна из наших пентестеров выявила ряд уязвимостей в системе управления веб-проектами 1С-Битрикс.
Одной из них присвоен идентификатор BDU:2024-01501.
Также на хабре вышла наша статья, где мы подробно рассказываем про обнаруженные уязвимости.
Поздравляем, Ксюша!
Please open Telegram to view this post
VIEW IN TELEGRAM
Как автоматизировать процесс ИБ-комплаенса, чтобы снять нагрузку со специалистов по информационной безопасности и повысить качество их работы?
18 апреля эксперты Ассоциации АБИСС совместно с Академией Информационных Систем поделятся своим опытом в рамках онлайн вебинара "Автоматизация и постановка процесса комплаенса".
Ключевые темы вебинара:
☑️ Организация и автоматизация при реализации и контроле мер защиты.
☑️ Автоматизация комплаенса – реализация процесса.
☑️ Опыт постановки процесса комплаенса в организациях, который может помочь компаниям и их работникам стать лучше с точки зрения ИБ.
☑️ Проблематика ситуационного моделирования ИБ.
Ведущие вебинара:
💬 Гусейнов Рустам, Председатель кооператива специалистов по кибербезопасности «РАД КОП».
💬 Игнатьева Алена, Начальник отдела консалтинга и аудита ИБ.
💬 Иванцов Александр, Старший инженер по защите информации Deiteriy Compliance.
💬 Царев Евгений, Управляющий RTM Group.
Участие в вебинаре бесплатное.
Узнать подробнее и зарегистрироваться можно по ссылке.
⏰ 18 апреля, 11:00-12:30.
18 апреля эксперты Ассоциации АБИСС совместно с Академией Информационных Систем поделятся своим опытом в рамках онлайн вебинара "Автоматизация и постановка процесса комплаенса".
Ключевые темы вебинара:
☑️ Организация и автоматизация при реализации и контроле мер защиты.
☑️ Автоматизация комплаенса – реализация процесса.
☑️ Опыт постановки процесса комплаенса в организациях, который может помочь компаниям и их работникам стать лучше с точки зрения ИБ.
☑️ Проблематика ситуационного моделирования ИБ.
Ведущие вебинара:
💬 Гусейнов Рустам, Председатель кооператива специалистов по кибербезопасности «РАД КОП».
💬 Игнатьева Алена, Начальник отдела консалтинга и аудита ИБ.
💬 Иванцов Александр, Старший инженер по защите информации Deiteriy Compliance.
💬 Царев Евгений, Управляющий RTM Group.
Участие в вебинаре бесплатное.
Узнать подробнее и зарегистрироваться можно по ссылке.
Please open Telegram to view this post
VIEW IN TELEGRAM
Наши пентестеры запустили канал по практической информационной безопасности 🎉
Подписывайтесь, ставьте лайки, будет много интересных постов)
Подписывайтесь, ставьте лайки, будет много интересных постов)
Please open Telegram to view this post
VIEW IN TELEGRAM
Рассказываем про возможные варианты обхода ограничений Docker Hub 🐳
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Консерва
Сегодня утром появилась новость о том, что доступ к DockerHub закрыт для российских IP-адресов.
Предлагаем решение проблемы 🦾
Вариант 1 - Настроить локальный прокси
[Linux]
1. Создать на вашем компьютере директорию: /etc/systemd/system/docker.service.d/…
Предлагаем решение проблемы 🦾
Вариант 1 - Настроить локальный прокси
[Linux]
1. Создать на вашем компьютере директорию: /etc/systemd/system/docker.service.d/…
Сергей Шустиков, генеральный директор и QSA-аудитор компании Deiteriy, расскажет:
☑️ об индустрии платёжных карт и стандарте PCI DSS 4.0;
☑️ как грамотно внедрить PCI DSS и поддерживать его соответствие в дальнейшем;
☑️ про подходы к новым требованиям, к которым следует готовиться уже сейчас.
Также Сергей поделится экспертным опытом и ответит на ваши вопросы.
Участие бесплатное, но необходимо будет зарегистрироваться по ссылке.
До встречи на PCI DSS Training!
Please open Telegram to view this post
VIEW IN TELEGRAM
Совет PCI SSC внёс порядка 50 изменений в стандарт PCI DSS и обновил его версию с 4.0 на 4.0.1. Сразу стоит отметить, что все изменения не добавляют, не удаляют и кардинально не изменяют требования Стандарта и его проверочные процедуры. Изменения минорные. Но именно в деталях скрываются нюансы, которые могут пригодиться на этапах внедрения Стандарта, поддержке соответствия и QSA-аудитах. Рассмотрим их подробнее и остановимся на наиболее примечательных.
1. Совет всё больше внимания уделяет аутсорсингу соответствия Стандарту. Это особенно актуально с учётом роста популярности услуг защищённых ЦОД, включая IaaS, SecaaS, Comliance as a Service.
2. Во всем Стандарте, где критерием применимости было "влияние на безопасность инфраструктуры", теперь заменили на "влияние на безопасность данных о держателях карт или критичных аутентификационных данных". В редких случаях это потенциально может повлиять на границы области применимости Стандарта, хотя в большинстве случаев будет являться просто более корректной формулировкой.
3. Теперь в Стандарте отдельно описано, что делать с ситуациями, когда компания получает данные платёжных карт по каналам, не предназначенным для передачи этих данных. На практике это: формы обратной связи, почта, чаты и другие. Канал нужно включать в скоуп PCI DSS, либо безопасно удалять данные платёжных карт и внедрять контрмеры, чтобы больше не получать данные платёжных карт по такому каналу.
4. Совет детализировал требования к защите электронной коммерции и веб-технологий. Например, контроль целостности скриптов и заголовков должен быть внедрён и на страницах, в которых встроен iframe с платёжной формой.
5. Помимо того, что каждый скрипт необходимо согласовывать перед добавлением на платёжную страницу и контролировать его целостность, необходимо проводить инвентаризацию скриптов и поддерживать их перечень. В таком перечне для каждого скрипта должна быть указана бизнес потребность или техническая необходимость его добавления на платёжную страницу.
6. В доработанном Стандарте Совет уделил много внимания разграничению ответственности третьих сторон. Особенный акцент сделан на поставщиках услуг, которые забирают со своих клиентов ответственность за часть требований PCI DSS.
По PCI DSS v.4.0 можно будет проходить аудит до декабря 2024 года. После декабря нужно будет использовать новую актуальную версию PCI DSS v.4.0.1 для сертификационных аудитов. Стандарт PCI DSS продолжает модернизироваться, а мы продолжаем готовиться к 2025 году, когда вступят в силу новые требования. Приходите на PCI DSS Training 26 июня обсудить нюансы изменений в PCI DSS! 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
Пока Москву снова одолевает непогода, мы рассеиваем туман неведения и вносим ясность в вопросы PCI DSS.
Сегодня у нас PCI DSS Training от QSA-аудитора Сергея Шустикова. Разбираем нововведения версии 4.0.1, регулирование вопросов PCI DSS со стороны НСПК и в целом жизнь с PCI DSS в 2024 году.
Для тех, кто не смог посетить тренинг, уже скоро опубликуем подробный анализ всех изменений версии 4.0.1.
Сегодня у нас PCI DSS Training от QSA-аудитора Сергея Шустикова. Разбираем нововведения версии 4.0.1, регулирование вопросов PCI DSS со стороны НСПК и в целом жизнь с PCI DSS в 2024 году.
Для тех, кто не смог посетить тренинг, уже скоро опубликуем подробный анализ всех изменений версии 4.0.1.
Конференция состоится 26 и 27 сентября 2024 года в Красной Поляне на площадке гостиничного комплекса «Гранд Отель Поляна».
Два дня актуального контента и общения с единомышленниками среди величественных горных вершин у Черного моря ⛰️
Что у нас в программе?
1. Воркшоп по практической информационной безопасности Practical Security Village от команды пентестеров Deiteriy Lab.
2. PCI DSS Training - авторский семинар от команды Deiteriy Compliance.
3. Обсуждение актуальных вопросов с экспертами ИБ и ИТ.
4. Полезные доклады на тему информационной безопасности в финтехе.
Регистрация уже доступна на сайте.
Мы будем рады видеть вас на #PAYMENTSECURITY!
Please open Telegram to view this post
VIEW IN TELEGRAM
Конкурс докладов для #PAYMENTSECURITY продлён!
Для участия необходимо направить темы и тезисы на электронную почту: cfp@paymentsecurity.ru.
Каждая заявка будет рассмотрена программным комитетом, который выберет лучшие из них.
☑️ Заявки принимаются до 31 августа 2024 года.
☑️ Длительность доклада - 40 минут.
☑️ Доклад не должен быть рекламным.
☑️ К заявке можно приложить любые материалы, которые помогут комитету оценить доклад.
Спикерам, чьи доклады получат одобрение программного комитета, мы оплатим дорогу до Сочи и обратно, а также проживание.
Воспользуйтесь возможностью заявить о себе, исследовать что-то новое и поделиться своим опытом с заинтересованной публикой.
Ждем ваши заявки на cfp@paymentsecurity.ru!
Для участия необходимо направить темы и тезисы на электронную почту: cfp@paymentsecurity.ru.
Каждая заявка будет рассмотрена программным комитетом, который выберет лучшие из них.
☑️ Заявки принимаются до 31 августа 2024 года.
☑️ Длительность доклада - 40 минут.
☑️ Доклад не должен быть рекламным.
☑️ К заявке можно приложить любые материалы, которые помогут комитету оценить доклад.
Спикерам, чьи доклады получат одобрение программного комитета, мы оплатим дорогу до Сочи и обратно, а также проживание.
Воспользуйтесь возможностью заявить о себе, исследовать что-то новое и поделиться своим опытом с заинтересованной публикой.
Ждем ваши заявки на cfp@paymentsecurity.ru!
Платёжная система SWIFT с каждым годом всё строже относится к безопасности своих участников и к независимой внешней оценке участников платёжной системы по требованиям стандарта SWIFT Customer Security Controls Framework.
В этом году платёжная система SWIFT открыла программу международной сертификации аудиторов. Тенденция ведёт к тому, что скоро и в платёжной системе SWIFT будет внедрена практика привлекать к внешним независимым аудитам опытных экспертов, успешно прошедших программу сертификации и сдавших экзамены, как это сейчас работает в индустрии платёжных карт.
Аудиторы-консультанты Deiteriy Владимир Ковалев и Александр Иванцов стали первыми в России аудиторами, получившими статус CSP Certified Assessor.
Поздравляем Вову и Сашу!
Please open Telegram to view this post
VIEW IN TELEGRAM
Друзья, у нас отличные новости!
🎉 Компания Deiteriy стала обладателем международного статуса Approved Scanning Vendor (ASV). Сервис Deiteriy Lab ASV получил аккредитацию Совета PCI SSC, выполнив все требования регулятора и пройдя испытания в независимой лаборатории.
📃 Теперь Deiteriy Lab ASV может применяться для выполнения требований 11.3.2, 11.З.2.1 стандарта PCI DSS. Кроме того, он полностью удовлетворяет требованиям 2.2.11, 2.3.7, 2.4.14, 2.5.5, 2.5.8, 2.7.6 Программы безопасности ПС Мир (НСПК), так как сервис ASV предоставляется поставщиком услуг, аккредитованным Советом PCI SSC и находящимся на территории Российской Федерации.
📮 По любым вопросам, связанным с приобретением или использованием ASV-сканера, вы можете написать нам на адрес электронной почты asv@deiteriy.com.
📃 Теперь Deiteriy Lab ASV может применяться для выполнения требований 11.3.2, 11.З.2.1 стандарта PCI DSS. Кроме того, он полностью удовлетворяет требованиям 2.2.11, 2.3.7, 2.4.14, 2.5.5, 2.5.8, 2.7.6 Программы безопасности ПС Мир (НСПК), так как сервис ASV предоставляется поставщиком услуг, аккредитованным Советом PCI SSC и находящимся на территории Российской Федерации.
📮 По любым вопросам, связанным с приобретением или использованием ASV-сканера, вы можете написать нам на адрес электронной почты asv@deiteriy.com.
Please open Telegram to view this post
VIEW IN TELEGRAM
📋 Банк России опубликовал проект изменений в Положение № 821-П. Вот основные изменения:
📌 Новые требования к организациям, проводящим оценку соответствия требованиям ГОСТ 57580.1.
Проверяющие организации, помимо лицензии на ТЗКИ, должны подтвердить соответствие требованиям ГОСТ Р ИСО/МЭК 17021-1-2017 «Оценка соответствия. Требования к органам, проводящим аудит и сертификацию систем менеджмента. Часть 1. Требования».
📌 Регулярность анализа уязвимостей ПО по ОУД.
Сертификация в системе ФСТЭК или оценка соответствия по требованиям к ОУД необходима при каждом внесении изменений в исходный код прикладного ПО, участвующего в платежных операциях.
Сертификация или оценка соответствия не требуется, если компания-разработчик имеет заключение от внешней проверяющей организации о том, что её процессы разработки ПО соответствуют мерам, описанным в разделе 7.4 «Профиля защиты прикладного ПО АС и приложений кредитных организаций и некредитных финансовых организаций».
📌 Необходимость использования усиленной электронной подписи.
Все участники платежной системы, к которым применимы требования Положения № 821-П, при передаче электронных сообщений между собой в рамках осуществления платежей, должны использовать сертифицированные средства и удостоверяющие центры для установки и проверки электронной подписи.
📌 Требования ИБ при осуществлении трансграничных переводов.
Если компания осуществляет трансграничные переводы, то обеспечение ИБ этого процесса должно осуществляться на основании соглашения с центральным банком другого государства, иностранным банком или иностранным регулятором финансового рынка. Копию данного соглашения с описанием порядка обеспечения ИБ необходимо будет предоставить в Банк России.
📌 Сроки информирования Банка России об инцидентах ИБ.
Установлена необходимость и сроки передачи в Банк России сведений о выявленных инцидентах или произошедших утечках информации, и о результатах расследований данных инцидентов. Также установлены сроки предоставления информации об инцидентах по запросу Банка России.
📌 Оценка выполнения требований Банка России по ИБ.
В изменениях явно описана необходимость планировать, реализовывать, контролировать и совершенствовать технические меры защиты, описанные в Положениях Банка России. Оценки выполнения данных процедур должны проводиться в соответствии с порядком, описанным в формах отчетности:
- 0409071 - для кредитных организаций,
- 0403202 - для некредитных организаций,
- 0420722 - для операторов электронных платформ.
Операторы по переводу денежных средств обязаны проводить данную оценку раз в два года наряду с оценкой соответствия требованиям ГОСТ 57580.1.
📌 Уточнение об итоговом уровне защиты при объединении нескольких контуров.
Уровень защиты для всего контура определяется по самой критичной его части. То есть, если в компании реализован единый контур защиты информации, объединяющий разные контуры, для которых по требованиям Положений Банка России применимы разные уровни защиты информации, то для всего единого контура необходимо реализовать максимальный из этих уровней защиты.
📌 Расширение состава регистрируемой информации о пользователях при совершении платежных операций через системы ДБО.
📌 Расширение перечня поднадзорных организаций – теперь к ним относятся и филиалы иностранных банков.
Планируется, что перечисленные изменения вступят в силу с 1 октября 2025 года.
📌 Новые требования к организациям, проводящим оценку соответствия требованиям ГОСТ 57580.1.
Проверяющие организации, помимо лицензии на ТЗКИ, должны подтвердить соответствие требованиям ГОСТ Р ИСО/МЭК 17021-1-2017 «Оценка соответствия. Требования к органам, проводящим аудит и сертификацию систем менеджмента. Часть 1. Требования».
📌 Регулярность анализа уязвимостей ПО по ОУД.
Сертификация в системе ФСТЭК или оценка соответствия по требованиям к ОУД необходима при каждом внесении изменений в исходный код прикладного ПО, участвующего в платежных операциях.
Сертификация или оценка соответствия не требуется, если компания-разработчик имеет заключение от внешней проверяющей организации о том, что её процессы разработки ПО соответствуют мерам, описанным в разделе 7.4 «Профиля защиты прикладного ПО АС и приложений кредитных организаций и некредитных финансовых организаций».
📌 Необходимость использования усиленной электронной подписи.
Все участники платежной системы, к которым применимы требования Положения № 821-П, при передаче электронных сообщений между собой в рамках осуществления платежей, должны использовать сертифицированные средства и удостоверяющие центры для установки и проверки электронной подписи.
📌 Требования ИБ при осуществлении трансграничных переводов.
Если компания осуществляет трансграничные переводы, то обеспечение ИБ этого процесса должно осуществляться на основании соглашения с центральным банком другого государства, иностранным банком или иностранным регулятором финансового рынка. Копию данного соглашения с описанием порядка обеспечения ИБ необходимо будет предоставить в Банк России.
📌 Сроки информирования Банка России об инцидентах ИБ.
Установлена необходимость и сроки передачи в Банк России сведений о выявленных инцидентах или произошедших утечках информации, и о результатах расследований данных инцидентов. Также установлены сроки предоставления информации об инцидентах по запросу Банка России.
📌 Оценка выполнения требований Банка России по ИБ.
В изменениях явно описана необходимость планировать, реализовывать, контролировать и совершенствовать технические меры защиты, описанные в Положениях Банка России. Оценки выполнения данных процедур должны проводиться в соответствии с порядком, описанным в формах отчетности:
- 0409071 - для кредитных организаций,
- 0403202 - для некредитных организаций,
- 0420722 - для операторов электронных платформ.
Операторы по переводу денежных средств обязаны проводить данную оценку раз в два года наряду с оценкой соответствия требованиям ГОСТ 57580.1.
📌 Уточнение об итоговом уровне защиты при объединении нескольких контуров.
Уровень защиты для всего контура определяется по самой критичной его части. То есть, если в компании реализован единый контур защиты информации, объединяющий разные контуры, для которых по требованиям Положений Банка России применимы разные уровни защиты информации, то для всего единого контура необходимо реализовать максимальный из этих уровней защиты.
📌 Расширение состава регистрируемой информации о пользователях при совершении платежных операций через системы ДБО.
📌 Расширение перечня поднадзорных организаций – теперь к ним относятся и филиалы иностранных банков.
Планируется, что перечисленные изменения вступят в силу с 1 октября 2025 года.
Ассоциация АБИСС и Академия Информационных Систем приглашают принять участие в новом обучающем вебинаре «Регуляторика при ИТ/ИБ-аутсорсинге»!
В этот раз эксперты АБИСС обсудят тему аутсорсинга и взаимодействия с поставщиками услуг, а также сопутствующие проблемы комплаенса, риски, способы их устранения и возможные последствия.
Программа вебинара:
☑️ Введение в тему аутсорсинга и его роль в информационной безопасности.
☑️ Анализ ситуаций, когда у банков возникли проблемы из-за контрагентов.
☑️ Рекомендации по предотвращению подобных ситуаций.
☑️ Практические советы по выбору надёжных поставщиков услуг.
☑️ Обсуждение «тёмной стороны» аутсорсинга и его ограничений.
Эксперты вебинара:
💬 Александр Иванцов, старший инженер по защите информации Deiteriy
💬 Федор Музалевский, директор технического департамента RTM Group
Узнать подробнее и зарегистрироваться можно по ссылке.
⏰ 21 августа, 11:00.
В этот раз эксперты АБИСС обсудят тему аутсорсинга и взаимодействия с поставщиками услуг, а также сопутствующие проблемы комплаенса, риски, способы их устранения и возможные последствия.
Программа вебинара:
☑️ Введение в тему аутсорсинга и его роль в информационной безопасности.
☑️ Анализ ситуаций, когда у банков возникли проблемы из-за контрагентов.
☑️ Рекомендации по предотвращению подобных ситуаций.
☑️ Практические советы по выбору надёжных поставщиков услуг.
☑️ Обсуждение «тёмной стороны» аутсорсинга и его ограничений.
Эксперты вебинара:
💬 Александр Иванцов, старший инженер по защите информации Deiteriy
💬 Федор Музалевский, директор технического департамента RTM Group
Узнать подробнее и зарегистрироваться можно по ссылке.
⏰ 21 августа, 11:00.
Новая версия Стандарта вступила в силу с 10 сентября 2024 года и содержит следующие изменения:
📌 Требования Стандарта стали распространяться на организации, обрабатывающие данные платёжных карт не для переводов денежных средств, а в рамках других сервисов, например, идентификации субъекта, реализации права льготного проезда в общественном транспорте и т. п.
📌 Добавлено ограничение на состав данных платёжных карт, разрешённых к обработке: В рамках нефинансовых сервисов допускается обработка только номера платёжной карты и имени её держателя.
📌 Организации, которые участвуют в предоставлении нефинансовых сервисов, хранят, передают или обрабатывают данные платёжных карт и не участвуют в их приёме или финансовых операциях, должны защищать данные платёжных карт, выполняя требования из Приложения В Стандарта или требования PCI DSS.
📌 Введены требования, при выполнении которых допустимо нахождение в одной инфраструктуре хешированных или зашифрованных номеров карт и ключей, используемых для их защиты. Добавлены примеры допустимых мер по изолированию сред:
1. Выгрузка хешированных или зашифрованных номеров карт или ключей, используемых для их защиты, на съёмные носители, доступ к которым ограничен;
2. Запрет логического доступа одного пользователя одновременно к ключам хеширования или шифрования и к защищаемым ими данным.
Примером реализации такого запрета является хранение номеров карт в БД, а ключей — в файле криптографического контейнера в файловой системе. При этом пользователи с учётными записями на уровне БД не должны иметь учётных записей на уровне ОС, позволяющих получить доступ к ключам, и наоборот.
📌 Введено требование по обработке инцидентов ИБ, связанных с компрометацией платёжных карт, в соответствии с положениями документа «Стандарт «ПС Мир». Порядок обработки Инцидентов ИБ Участником».
📌 Рекомендовано исключить обработку усечённых и хешированных или зашифрованных версий полного номера карты в одной инфраструктуре. Если такая обработка необходима для осуществления целей обработки данных в рамках нефинансового сервиса, то допустимым является использование правила усечения «видимы только 2 последние цифры».
📌 Внесены изменения в требование по управлению ключами хеширования, используемых в рамках HMAC. В том числе исключено требование по установке криптопериода и добавлены примеры возможных способов безопасного распространения и передачи ключей хеширования.
📌 При использовании асимметричных алгоритмов для получения идентификатора из полного номера карты и при выполнении шифрования необходимо к значению номера карты добавлять путём конкатенации последовательность случайных чисел, соответствующую требованиям к ключам, указанным в пункте 3.3 Стандарта.
📌 Из Бюллетени безопасности #02.2024 в Стандарт перенесены требования к Считывателям Карт в организациях, которые осуществляют считывание и обработку данных платёжных карт в устройствах, не предусмотренных для обработки финансовой информации, например, СКУД, (Кампусные проекты).
Новые требования по ограничению состава обрабатываемых данных платёжных карт и по безопасности среды их обработки (2.1, 2.9, 2.12) станут обязательными с 01 октября 2025 года. До этого времени они носят рекомендательный характер.
Кроме того, в связи с тем, что с 01 апреля 2025 года для хеширования полного номера карты в нефинансовых сервисах необходимо будет использовать HMAC, в Стандарте исключена возможность использования алгоритмов Argon, Bcrypt или PBKDF2 для хеширования полного номера карты и исключены требования по использованию случайного значения («соли») при выполнении хеширования.
Но до 31 марта 2025 года для хеширования полного номера карты в нефинансовых сервисах могут использоваться следующие алгоритмы:
1. HMAC с секретным ключом, реализованные на основе ГОСТ Р 34.11-2012, SHA-1, SHA-2 и SHA-3;
2. Argon21, Bcrypt2 или PBKDF23 с солью;
3. SHA2, SHA-3 с солью.
Please open Telegram to view this post
VIEW IN TELEGRAM