Здравствуйте. Я работаю в компании CardSec и, в частности, мы занимаемся тем, что помогаем нашим клиентам готовиться к аудитам по информационной безопасности и проводим эти аудиты.

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

Особенно эта проблема актуальна для финтех отрасли, в силу большего количества требований и регуляторов.

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

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

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

Структура

  1. Из чего это состоит ИБ и сколько это может стоить

  2. Какие требования есть, для кого они актуальны

  3. Лайфхак: соответствовать нужно не всему и сразу. Как выстроить roadmap, в какой момент и насколько нужно соответствовать

  4. По шагам: делай раз-два-три. Что нужно для соответствия

1. Из чего это состоит ИБ и сколько это может стоить

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

Для выполнения у вас должны быть документы, описывающие что и как вы защищаете. И эти документы описывают, в том числе, настройки системы и специальных средств защиты, которые, конечно же, должны быть установленными и работать.
Т.е. стоимость соответствия можно разложить на следующие составляющие:

  • Стоимость консалтинга: услуг по сертификации;

  • Стоимость консалтинга: услуг по разработке процессов и нужных документов. Услуга называется «приведение в соответствие»;

  • Стоимость покупки устройств и лицензий средств защиты;

  • Стоимость продления лицензий и подписок средств защиты;

  • Стоимость поддержки средств защиты – зарплата безопаснику, или оплата за аутсорс;

  • Стоимость консалтинга: услуг по периодической ресертификации;

2. Какие требования есть, для кого они актуальны

К финтеху с высокой степенью вероятности могут применяться следующие обязательные требования:

  • Практически в любом случае - защита персональных данных клиентов. 152-ФЗ.

  • Если компания принимает или отправляет платежи на пластиковые карты – то стандарт PCI DSS.

  • Если компания проводит платежи через процессинговый центр – требования ЦБ РФ (Положения 719-П и 747-П) и требования стандарта ГОСТ Р 57580.1-2017.

  • Если компания является финансовым агрегатором и перепродает партнерские финансовые услуги (страховку, кредиты и т.п.) – требования ЦБ РФ: 211-ФЗ и положения 742-П, ГОСТ Р 57580.1-2017.

Чуть подробнее про законы и стандарты:

152-ФЗ, защита персональных данных

Самый простой закон для соответствия.

Кому нужно: формально – соответствовать должны все и всегда.
Кому особенно нужно:

  • Если у вас есть данные клиентов, и их много. Любые: Имя и телефон, имя и email, имя и адрес, email и телефон. Все, что уникально указывает на одного человека – это персональные данные.

  • Если у вас есть холодная база клиентов. Холодные клиенты – недовольные клиенты. А недовольные клиенты – пишут жалобы.

  • Если у вас сервис для юридических лиц, а в нем обрабатываются данные сотрудников ваших клиентов, или контр-агентов (в том числе клиентов) ваших клиентов.

Требованиям ЦБ РФ (ГОСТ Р 57580.1-2017) нужно соответствовать в следующих ситуациях:

  • У вас есть лицензия ЦБ РФ кредитной организации (на осуществление банковской деятельности, например). Тогда нужно соответствовать требованиям положения ЦБ РФ 683-П.

  • Вы являетесь некредитной финансовой организацией в соответствии с определением 86-ФЗ «О Центральном банке Российской Федерации», статьей 76.1. Тогда вы подпадаете под требования положения ЦБ РФ 757-П.

    • Исключение – микрофинансовые компании и микрокредитные компании. Они не попали в 757-П и соответствие в данный момент не является обязательным.

  • Вы являетесь оператором финансовой платформы в соответствии с 211-ФЗ. И тогда вы подпадаете под требования постановления ЦБ РФ 742-П.

  • Если вы проводите платежи через внешний банк или расчетный центр, то этот расчетный центр имеет право в какой-то момент потребовать от вас соответствия требованиям положений ЦБ РФ 719-п (чаще) или 747-П (реже).

Требованиям PCI DSS нужно соответствовать в следующих случаях:

  • Вы являетесь платежным шлюзом: услуги по оплате с карт, переводу с карты на карту и т.д. (потребует банк, подключающий вас к системе, или НСПК);

  • Если вы принимаете оплату по карте с использованием процессинга какого-то банка или процессингового центра, то этот банк или процессинговый центр имеет право в какой-то момент потребовать от вас соответствия требованиям PCI DSS.

3. Лайфхак: соответствовать нужно не всему и сразу. Как выстроить роудмап, в какой момент и насколько нужно соответствовать

Не всем стандартам нужно соответствовать сразу и полностью.

Во-первых, у всех стандартов есть уровни соответствия.

Во-вторых – большую часть работ по соответствию можно сделать в тот момент, когда они понадобятся.

При планировании соответствия нужно учитывать следующие вещи:

  • Проект по соответствию не делается моментально. Подробнее будет указано в следующем разделе, но это 2-7 месяцев.

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

  • Есть несколько архитектурных требований, которые лучше учесть заранее, чтобы не переделывать все в последний момент.

Уровни соответствия позволяют сначала привестись в соответствие «попроще», а потом, если надо – «посильнее». Завышать уровень – обычно смысла нет: дороже, а на выходе получите такую же бумагу, которую у вас примет ваш контр-агент или инвестор. И никаких плюсов от завышения.

152-ФЗ:

Текст ниже – актуален для коммерческих компаний, не взаимодействующих со ФСТЭК напрямую.

152-ФЗ подразумевает 4 уровня защищенности (УЗ), Где УЗ1 – самый защищенный, УЗ4 – наименее защищенный. УЗ определяется в соответствии с постановлением правительства №1119.

  • УЗ1 – не возникает никогда.

  • УЗ2 – возникает, если обрабатываются «специальная» категория данных И для более, чем 100 000 человек. Специальные данные – это чаще всего медицинские данные или данные о судимостях.

  • УЗ3\УЗ4 – почти не отличаются друг от друга. УЗ3\УЗ4 – применяются ко всем, у кого нет специальных данных в большом количестве.

Соответствие, теоретически, бессрочное.

Требования ЦБ РФ

Их много. И пути применения 2:

  • Вы должны соответствовать им из-за прямого требования законов (перечисленных в пункте 2). И тогда соответствие должно быть к моменту выхода на рынок – без него нельзя работать.

  • Соответствия потребовал расчетный или платежный центр, через который вы проводите платежи. Требование скорее всего будет говорить про положения ЦБ РФ 719-П или 747-П. Поэтому, если вы планируете работать через платежный или расчетный центр – стоит у представителей этого расчетного центра уточнить: в какой момент и какой уровень соответствия они потребуют. Момент зависит от количества транзакций и денег по этим транзакциям, которые вы проводите через платежный или расчетный центр.

Большинство требований ЦБ приводят к необходимости выполнить ГОСТ Р 57580.1-2017.

В ГОСТ Р 57580.1-2017 есть 3 уровня защиты: от УЗ1 (усиленный) до УЗ3 (минимальный).

  • Требования для обладателей лицензий ЦБ описаны в 683-П, пункте 3.1. И это либо УЗ1 (для системнозначимых), либо УЗ2 (для остальных).

  • Требования для некредитных финансовых организаций описаны в 757-П, пункте 1.4.

  • Требования к уровню защиты, предъявляемые 719-П, описаны в пунктах 3.5, 4.3, 6.5. – возможны все 3 УЗ.

Кроме того, ГОСТ Р 57580.1, каждому из его уровней, можно лучше или хуже соответствовать – выставляются оценки уровня соответствия. Их 5: от 1 (совсем плохо) до 5 (совсем хорошо). В 2022-м году – скорее всего потребуется уровень соответствия не хуже 3-го (средне). В 2023-м году – уже потребуется улучшаться до 4-го (хорошо).

Соответствие нужно подтверждать не реже 1 раза в 2 года.

PCI DSS

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

Стандарт требует от всех одинаковой защиты, и от уровня зависит только строгость проверки.

На низких уровнях – компания может сама себя проверить (и сама нести все риски, если решила слегка улучшить оценку).

На высоком уровне (Level 1) – нужно звать специального PCI-аудитора, и он проводит оценку.

Уровень зависит от типа операций и количества карточных транзакций:
Типы операций, упрощенно:

  • Merchant. Продавец. Принимает деньги с карты клиентов на свой счет.

  • Service provider. Оказывает какой-либо сервис в рамках процесса карточных операций. Переводит деньги с карту на карту клиента (клиентов), или начисляет деньги на карту клиента.

Уровни для Merchant:

  • Level 1 - Более 6 миллионов карточных транзакций в год. Требуется сертификационный аудит со стороны специальных аудиторов.

  • Level 2, 3 – менее 6 миллионов карточных транзакций в год. Требуется заполнение формы самооценки (можно провести самостоятельно).

  • Level 4 – менее 20 тысяч карточных транзакций в год. Необходимость подтверждение соответствия устанавливается банком или карточным центром. При необходимости подтверждения – аналогично Level 2,3.

Уровни для Service Provider:

  • Level 1 – процессинговые центры, центры токенизации, компании с количеством карточных транзакций более 300 тысяч в год. Требуется сертификационный аудит со стороны специальных аудиторов.

  • Level 2 – компании (кроме процессинговых центров и центров токенизации) с количеством карточных транзакций менее 300 тысяч в год. Требуется заполнение формы самооценки (можно провести самостоятельно).

4. По шагам: делай раз-два-три. Что нужно для соответствия

Для соответствия 152-ФЗ нужно

  • Разработать документы для взаимодействия с регулятором, описывающие цели сбора персональных данных, что с данными делают, и как данные защищаются. Проще делать с помощью консультантов. Проект занимает, в среднем, 1,5-3 месяца.

  • Установить и настроить меры и средства защиты, требуемые в соответствии с приказом ФСТЭК России №21:

    • Межсетевой экран;

    • IPS (только для УЗ2);

    • Антивирус (особенно для Windows-систем);

    • Настроить аутентификацию в системах (она просто должна быть);

    • Устанавливать обновления;

    • Контролировать отсутствие уязвимостей;

    • Настроить бэкапы (детализации требований к бэкапам нет);

    • Собирать логи (только для УЗ2).

  • Если используется облако – оно должно соответствовать требованиям 152-ФЗ. Но свою систему в облаке тоже нужно привести в соответствие.

  • Штатный межсетевой экран в облаке не умеет IPS (нужный на УЗ2). Его придется покупать. IPS – может оказаться дорогим.

  • Важно: НЕТ требований применять только сертифицированные средства защиты. Можно применять обычные.

  • Важно: не всегда (точнее редко) нужно применять ГОСТ-криптографию – фактически только в случае интеграции с государственными системами, или обработки медицинских данных.

  • Важно: нет требований проводить аттестацию системы, кроме случаев интеграции с государственными системами. Аттестация – добровольная.

Итог: «привести в соответствие» — это разработать процессы и документы. С технической точки зрения, большинство систем соответствуют требованиям 152-ФЗ.
Соответствия достичь легко.

Для соответствия ГОСТ Р 57580.1-2017 нужно:

  • Разработать массу документов, регламентирующих управление защищенностью. Почти всегда делается с помощью консультантов – документы сложные. Документы PCI DSS и документы для ГОСТ Р 57580.1 – похожи, можно частично реиспользовать. Проект занимает, в среднем, 4-6 месяцев.

  • Установить и настроить средства и меры защиты:

    • Межсетевой экран;

    • IPS;

    • 3 разных антивируса: например, для пользователей, серверов и сетевой;

    • Средство контроля целостности на серверах;

    • Проводить сканирование на уязвимости;

    • Устанавливать обновления;

    • Настроить сбор логов и их хранение до 3-х лет;

    • Настроить определенным образом права доступа и периодических их проверять;

    • Иметь систему Service Desk (или любой другой способ формально отслеживать заявки на изменения);

    • Организовать двухфакторную аутентификацию для администраторов;

    • Проводить ежегодный pentest.

  • Если использовать облако – очень желательно, чтобы оно соответствовало требованиям ГОСТ Р 57580.1. Но свою систему в облаке тоже нужно привести в соответствие.

  • Если используется облако - штатный межсетевой экран не умеет IPS. Его придется покупать. IPS может оказаться дорогим.

  • Сбор логов может потребовать существенный объем дисков.

  • Антивирусы и сканер уязвимостей – потребуют ежегодного продления подписки.

  • Прочие меры создают существенную нагрузку по администрированию – может понадобиться дополнительный администратор.

  • Соответствие подтверждается специальным аудитом, раз в 2 года.

  • Для подтверждения соответствия нужен отчет о прохождении успешного пентеста.

Итог: «привести в соответствие» — это разработать процессы и документы, установить и настроить средства защиты. Потребуется существенный объем работ по настройке серверов и ПО. Потребуются периодические траты на подписку и поддержку средств защиты, проверяющего, пентест. Вероятно, потребуется выделенный сотрудник.

Для соответствия PCI DSS нужно:

  • Разработать массу документов, регламентирующих управление защищенностью. Почти всегда делается с помощью консультантов - документы сложные. Документы PCI DSS и документы для ГОСТ Р 57580.1 – похожи, можно частично реиспользовать. Проект занимает, в среднем, 5-7 месяцев.

  • Установить средства и меры защиты (похожи на ГОСТ Р 57580.1):

    • Межсетевой экран;

    • IPS;

    • Антивирус;

    • Средство контроля целостности на серверах;

    • Если есть web-сайт – нужен web application firewall (WAF);

    • Проводить сканирование на уязвимости;

    • Проводить внешнее сканирование специальным сканером (ASV);

    • Устанавливать обновления;

    • Настроить сбор логов и их хранение до 1-го года;

    • Настроить определенным образом права доступа и периодических их проверять;

    • Сеть нужно сконфигурировать определенным образом: DMZ (сервера в ней могут общаться с Интернетом) и LAN (сервера в ней не могут общаться с интернетом – только с DMZ);

    • Иметь систему Service Desk (или любой другой способ формально отслеживать заявки на изменения);

    • Организовать двухфакторную аутентификацию для администраторов;

    • Проводить ежегодный pentest (только для Level 1).

  • Если использовать облако – оно должно соответствовать требованиям PCI DSS. Но свою систему в облаке тоже нужно привести в соответствие.

  • Если используется облако - штатный межсетевой экран не умеет IPS. Его придется покупать. IPS может оказаться дорогим.

  • WAF может оказаться дорогим, цена обычно зависит от нагрузки на сайт.

  • Сбор логов может потребовать существенный объем дисков.

  • Антивирусы и сканер уязвимостей – потребуют ежегодного продления подписки.

  • Для Level 1 необходимо ежегодно проводить сертификационный аудит силами специальных аудиторов.

  • Для Level 1 потребуется проводить ежегодный pentest.

  • Прочие меры создают существенную нагрузку по администрированию – может понадобиться дополнительный администратор.

Итог: «привести в соответствие» — это разработать процессы и документы, установить и настроить средства защиты. Потребуется существенный объем работ по настройке серверов и ПО. Потребуются периодические траты на подписку и поддержку средств защиты, а для Level 1 – проверяющего и pentest. Вероятно, потребуется выделенный сотрудник.

Комментарии (3)


  1. tas
    11.04.2022 15:53

    "Собирать логи (только для УЗ2)." - по факту безопасники Заказчика требуют всегда, если есть перс данные.

    И да - при наличии перс данных логов у нас нет - вместо них у нас события безопасности :)


  1. dph
    11.04.2022 16:32

    Хм, у PCI DSS еще куча требований по хранению данных карт, cvv в процессе платежа, составу логов, подходу к разработке и так далее. И это все требует думать про архитектуру на ранних этапах разработки.


    1. Kifir42 Автор
      11.04.2022 17:39

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

      Чаще вопросы возникают у мерчантов и пользователей подключаемых процессинговых центров - им CVV хранить не нужно.

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

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