Не ткну: в PCI DSS прям самую малость другая логика ссылок на регламентирование шифрования. А вопрос я все также не понимаю. Не могли бы его сформулировать?
не очень понимаю, в чем вопрос. PCI DSS по большей части ссылается на внешние документы по криптографии. И да, Sha-1, упомянутый в приведенном вами cipher suite подходил для PCI DSS 3.2.1, и не подойдет (начиная с 25-го года) для PCI DSS 4. Только теоретически ничто не мешает во время жизненного цикла pci dss v4 появиться какому-то документу, регламентирующему уязвимость, например, sha-2 - и таким образом выводящим, например, sha-2 за пределы понятия "стойких алгоритмов"
И да, и нет. тут вообще различия в подходе к созданию нормативных документов. В российской традиции создания именно обязательных документов - очень важно отразить 2 стороны медали: - ограничения: чего делать нельзя, и что сделать нужно; - методология: что и как сделать, чтобы было "нормально". и методологическая часть описана и послабее, и плотно связана с обязательной - как раз через описание процессов и контролей. А в западной традиции часто действует принцип "написано то, что должно получиться. А как - придумай сам, или закажи профильных специалистов. А если нарушишь - ну не маленький, сам понимаешь". Мне, честно говоря, подход ГОСТа больше нравится - и подробнее, и конкретнее. Но на любителя, да
ок, спасибо: соглашусь, плохо сформулировал. PCI DSS не требует конкретных мер и средств защиты для тестовых сред. Но при работе с тестовой средой - да, просит не вносить продуктивные данные в тест, и тестовые "артефакты" в прод
Действительно, есть некоторые изменения, а также предлагаемые со стороны ЦБ РФ меры, правда они относятся скорее к экономической безопасности, и на технические меры скорее опираются как на инструменты.
Грубо говоря:
Банки должны иметь антифрод-систему, по которой, в том числе проверяются разные параметры, позволяющие вовремя определить: а не является ли кто-то из сторон сделки террористом, отмывателем денег (ПОД\ФТ), или еще кем-нибудь нехорошим. Это уже давно так;
ЦБ ведет реестр нехороших мошенников, и номеров их счетов и карт;
Банки должны данные из этого реестра загружать в свой антифрод, и если клиент совершает перевод на счет или карту из реестра - как минимум задерживать платеж на несколько дней (на "период охлаждения");
Реестр пополняется в том числе (и в большой степени, честно говоря) самими банками: если кто-то из клиентов жалуется на мошенническую деятельность, то банк должен принять сообщение, как-то его проверить, и внести упомянутые в жалобе счета или номера карт в реестр. И отправить в ЦБ.
Еще по новым изменениям - банки должны как-то сами (превентивно) выявлять карты "дропов" и счета мошенников - например, поддельные карты, или карты не находящиеся под контролем формальных владельцев, их их тоже вносить в реестр.
Это даст возможность останавливать волны краж - условно, после первой порции жертв мошенников и жалоб от них - карта попадает в реестр, новые платежи на нее задерживаются, у следующих жертв появляется несколько дней, чтобы отменить перевод и вернуть деньги.
С другой стороны - банки как-то должны проверять переводы на большее количество параметров, соответственно будут сильнее всего бояться, чаще проверять переводы на законность, нужность, отсутствие злого умысла и т.д., - и переводы могут начать ходить медленнее.
Безусловно. И требований много, и стартапы разные бывают. Только вот CVV хранить самостоятельно мало кому нужно - это нужно именно при авторизации платежей. Делающие процессинговый центр с нуля - скорее всего купят подходящий софт)
Чаще вопросы возникают у мерчантов и пользователей подключаемых процессинговых центров - им CVV хранить не нужно.
Подход к разработке у всех разный и как раз WAF позволяет сократить внимание к процедурам code review. А подход к хранению логов - тема, которую в короткой статье не описать, но логи в любом случае нужно хранить. И это - потребует денег.
Я статья задумал в основном как гайд "на что обратить внимание, и стоимость чего необходимо учесть", чтобы не возникло ситуации, когда экономика сервиса уже рассчитана, завтра запускаться, а тут выясняется что запуск без сертификата или заключения невозможен, а сертификат или заключение потребуют вложений, разрушающих экономику сервиса
Это, простите какая-то утопия. По, ка минимум, двум причинам: 1. все, что автор перечислил в примерах - это retail. Простая, атомизированная, размножаемая услуга с понятными параметрами для клиентов частных лиц. Даже в обычном ИТ - идея уже становится профанацией. Невозможно сделать "простое КП", если нужно сделать сложную услугу. Например из первого примера - в результате пентеста выяснится, что - у заказчика есть недокументированные сервисы. Нужно документировать. Заранее неизвестен объем работы - у заказчика не установлены апдейты безопасности. Админы есть и должны ставить - но не поставили. При глубоком копании выясняется, что с апдейтами не совместимо что-то из ПО заказчика. А доработать ПО не позволяют, например, бюджетные ограничения и т.д. т.е. огромное количество параметров необходимо обсуждать до старта проекта. 2. Что значит гарантии? Такси или приехало, или нет. Система или работает, или нет (и то - может же глючить). А в ИБ? Гарантии в смысле =- не взломают клиента? Так во первых - невзламываемых систем не бывает, во вторых - защита это процесс. много процессов. и вы хотите, что бы команда подрядчиков за один раз сделала что-то, что будет само работать вечно?) Так не бывает. Можно нанять свою сильную свою команду (и так мало кто делает - дорого). Есть вот прекрасные практики систем управления ИБ: с метриками, внутренним аудитом, мониторингом защищенности, постоянным контролем, и высокими требованиями к численности собственного ИБ - тоже можно внедрить. Только так же тоже мало кто делает. Интеграторы могут давать сервис (непрерывный, с кучей ограничений в сторону заказчика), и на этих условиях давать гарантии защиты - и страховать свои риски. Только это тоже увеличит стоимость услуги для заказчика. И что-то как-то я не вижу, чтобы массовые заказчики были готовы хоть что-то из этого оплачивать. PS ну и ТЗ все-таки ДОЛЖЕН формулировать заказчик. кто его пишет-оформляет - дело десятое. Но если не хочется попадать в ситуацию "я не этого хотел", то надо хотя бы представлять "чего хотел".
Не ткну: в PCI DSS прям самую малость другая логика ссылок на регламентирование шифрования. А вопрос я все также не понимаю. Не могли бы его сформулировать?
не очень понимаю, в чем вопрос. PCI DSS по большей части ссылается на внешние документы по криптографии. И да, Sha-1, упомянутый в приведенном вами cipher suite подходил для PCI DSS 3.2.1, и не подойдет (начиная с 25-го года) для PCI DSS 4.
Только теоретически ничто не мешает во время жизненного цикла pci dss v4 появиться какому-то документу, регламентирующему уязвимость, например, sha-2 - и таким образом выводящим, например, sha-2 за пределы понятия "стойких алгоритмов"
И да, и нет. тут вообще различия в подходе к созданию нормативных документов. В российской традиции создания именно обязательных документов - очень важно отразить 2 стороны медали:
- ограничения: чего делать нельзя, и что сделать нужно;
- методология: что и как сделать, чтобы было "нормально".
и методологическая часть описана и послабее, и плотно связана с обязательной - как раз через описание процессов и контролей.
А в западной традиции часто действует принцип "написано то, что должно получиться. А как - придумай сам, или закажи профильных специалистов. А если нарушишь - ну не маленький, сам понимаешь".
Мне, честно говоря, подход ГОСТа больше нравится - и подробнее, и конкретнее. Но на любителя, да
ок, спасибо: соглашусь, плохо сформулировал.
PCI DSS не требует конкретных мер и средств защиты для тестовых сред. Но при работе с тестовой средой - да, просит не вносить продуктивные данные в тест, и тестовые "артефакты" в прод
Действительно, есть некоторые изменения, а также предлагаемые со стороны ЦБ РФ меры, правда они относятся скорее к экономической безопасности, и на технические меры скорее опираются как на инструменты.
Грубо говоря:
Банки должны иметь антифрод-систему, по которой, в том числе проверяются разные параметры, позволяющие вовремя определить: а не является ли кто-то из сторон сделки террористом, отмывателем денег (ПОД\ФТ), или еще кем-нибудь нехорошим. Это уже давно так;
ЦБ ведет реестр нехороших мошенников, и номеров их счетов и карт;
Банки должны данные из этого реестра загружать в свой антифрод, и если клиент совершает перевод на счет или карту из реестра - как минимум задерживать платеж на несколько дней (на "период охлаждения");
Реестр пополняется в том числе (и в большой степени, честно говоря) самими банками: если кто-то из клиентов жалуется на мошенническую деятельность, то банк должен принять сообщение, как-то его проверить, и внести упомянутые в жалобе счета или номера карт в реестр. И отправить в ЦБ.
Еще по новым изменениям - банки должны как-то сами (превентивно) выявлять карты "дропов" и счета мошенников - например, поддельные карты, или карты не находящиеся под контролем формальных владельцев, их их тоже вносить в реестр.
Это даст возможность останавливать волны краж - условно, после первой порции жертв мошенников и жалоб от них - карта попадает в реестр, новые платежи на нее задерживаются, у следующих жертв появляется несколько дней, чтобы отменить перевод и вернуть деньги.
С другой стороны - банки как-то должны проверять переводы на большее количество параметров, соответственно будут сильнее всего бояться, чаще проверять переводы на законность, нужность, отсутствие злого умысла и т.д., - и переводы могут начать ходить медленнее.
Безусловно. И требований много, и стартапы разные бывают. Только вот CVV хранить самостоятельно мало кому нужно - это нужно именно при авторизации платежей. Делающие процессинговый центр с нуля - скорее всего купят подходящий софт)
Чаще вопросы возникают у мерчантов и пользователей подключаемых процессинговых центров - им CVV хранить не нужно.
Подход к разработке у всех разный и как раз WAF позволяет сократить внимание к процедурам code review. А подход к хранению логов - тема, которую в короткой статье не описать, но логи в любом случае нужно хранить. И это - потребует денег.
Я статья задумал в основном как гайд "на что обратить внимание, и стоимость чего необходимо учесть", чтобы не возникло ситуации, когда экономика сервиса уже рассчитана, завтра запускаться, а тут выясняется что запуск без сертификата или заключения невозможен, а сертификат или заключение потребуют вложений, разрушающих экономику сервиса
Это, простите какая-то утопия. По, ка минимум, двум причинам:
1. все, что автор перечислил в примерах - это retail. Простая, атомизированная, размножаемая услуга с понятными параметрами для клиентов частных лиц. Даже в обычном ИТ - идея уже становится профанацией. Невозможно сделать "простое КП", если нужно сделать сложную услугу.
Например из первого примера - в результате пентеста выяснится, что
- у заказчика есть недокументированные сервисы. Нужно документировать. Заранее неизвестен объем работы
- у заказчика не установлены апдейты безопасности. Админы есть и должны ставить - но не поставили. При глубоком копании выясняется, что с апдейтами не совместимо что-то из ПО заказчика. А доработать ПО не позволяют, например, бюджетные ограничения
и т.д.
т.е. огромное количество параметров необходимо обсуждать до старта проекта.
2. Что значит гарантии?
Такси или приехало, или нет. Система или работает, или нет (и то - может же глючить). А в ИБ? Гарантии в смысле =- не взломают клиента? Так во первых - невзламываемых систем не бывает, во вторых - защита это процесс. много процессов. и вы хотите, что бы команда подрядчиков за один раз сделала что-то, что будет само работать вечно?) Так не бывает.
Можно нанять свою сильную свою команду (и так мало кто делает - дорого).
Есть вот прекрасные практики систем управления ИБ: с метриками, внутренним аудитом, мониторингом защищенности, постоянным контролем, и высокими требованиями к численности собственного ИБ - тоже можно внедрить. Только так же тоже мало кто делает.
Интеграторы могут давать сервис (непрерывный, с кучей ограничений в сторону заказчика), и на этих условиях давать гарантии защиты - и страховать свои риски. Только это тоже увеличит стоимость услуги для заказчика.
И что-то как-то я не вижу, чтобы массовые заказчики были готовы хоть что-то из этого оплачивать.
PS ну и ТЗ все-таки ДОЛЖЕН формулировать заказчик. кто его пишет-оформляет - дело десятое. Но если не хочется попадать в ситуацию "я не этого хотел", то надо хотя бы представлять "чего хотел".