Здравствуйте. Я работаю в компании 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. Вероятно, потребуется выделенный сотрудник.