Наша IaaS-платформа Cloud-152 одновременно сертифицирована по требованиям PCI DSS и имеет аттестат соответствия 152-ФЗ по УЗ-2 (без актуальных угроз 1-го и 2-го типа). Эта же платформа входит еще и в область действия нашей системы управления информационной безопасностью (СУИБ), которую мы сертифицировали по ISO/IEC 27001:2013. Про это и про STAR Cloud Security Alliance (CSA) я обязательно как-нибудь тоже расскажу, но сегодня остановлюсь на плюсах синергии PCI DSS и 152-ФЗ для наших клиентов.
Мы живем в России, наши клиенты преимущественно ведут бизнес в РФ, и всем приходится соблюдать требования российского законодательства в области защиты персональных данных. Тот самый ФЗ “О персональных данных” от 27.07.2006 года № 152-ФЗ и правки к нему из 242-ФЗ от 21.07.2014 г. про обработку ПДн граждан РФ в базах, расположенных на территории РФ. GDPR далеко не всем нужен, и эту тему я тоже вынесу за пределы данной статьи.
152-ФЗ задумывался для защиты прав субъектов ПДн. Закон не дает готовых рецептов по защите персональных данных с помощью внедрения и настройки средств защиты (СЗИ). Если спуститься на более “конкретный” уровень постановления Правительства № 1119, приказа ФСТЭК России № 21 и приказа ФСБ России № 378, то там больше про факт наличия средств (в ряде случаев сертифицированных), а не про то, как это все должно быть настроено, чтобы было безопасно.
PCI DSS определяет требования к безопасности данных в индустрии платежных карт. Сфера его действия связана с деньгами, которые все традиционно оберегают особо тщательно. В нем больше конкретики, требований и листов для чтения :).
Возможно, кому-то покажется странным само соединение на одной платформе PCI DSS и 152-ФЗ, но для нас в этом есть смысл. Это не просто про два в одном флаконе, но и, что более важно, соединение бумажной и практической безопасности.
Дальше приведу несколько примеров про эту систему “сдержек и противовесов”.
Пример 1. Аттестат на инфраструктуру, соответствующую требованиям 152-ФЗ, выдается на 3 года. В течение этого времени в инфраструктуре ничего не должно меняться, либо обязательно должно быть согласовано с организацией, выдавшей аттестат. Аттестация равно фиксация системы на целых три года. Насколько инфраструктура отвечает требованиям от проверки до проверки – на совести аттестованного.
У PCI DSS цикл проверок короче: аудит каждый год. Дополнительно к этому 2 раза в год проводится pentest (внешний и внутренний нарушитель) и 4 раза в год – ASV-сканирование (Approved Scanning Vendor). Этого достаточно, чтобы держать инфраструктуру в тонусе.
Пример 2. У аттестации по 152-ФЗ есть своя цена, и это ограничения в выборе ПО и средств защиты. Если собираетесь проходить аттестацию, то все они должны быть сертифицированными. Сертифицированные – значит не самые свежие версии ПО и СЗИ. Например, сертифицирован ПАК CheckPoint, модельный ряд 2012 года, прошивка R77.10. На сертификации сейчас R77.30, но на нее уже заканчивается поддержка вендора в сентябре 2019. У PCI DSS таких требований нет (разве что к сканеру – он должен быть из списка одобренных). Это позволяет использовать параллельно средства защиты, у которых нет проблем с актуальностью версий.
Пример 3. И 152-ФЗ, и PCI DSS требуют наличия межсетевого экрана (МЭ). Только ФСТЭК России требует просто его наличия, а в случае с аттестацией – еще и наличия сертификата соответствия требованиям ФСТЭК России. В то же время у ФСТЭК нет требований по его настройке и обслуживанию. Фактически межсетевой экран может просто быть, а работает он корректно и работает ли в принципе, в документе уже не проговаривается. Такая же ситуация со средствами антивирусной защиты (САВЗ), средствами обнаружения вторжения (СОВ) и средствами защиты информации от несанкционированного доступа (СЗИ от НСД).
Проверки аттестующих организаций тоже не могут гарантировать, что все работает как надо. Часто все ограничивается выгрузкой всех правил межсетевого экрана. Бывает еще, что просто снимают контрольные суммы с файлов ОС Gaia (ОС CheckPoint). Эти файлы изменяются динамически, и их контрольная сумма тоже. Смысла в таких проверках немного.
Есть еще требования производителей сертифицированных СЗИ по их установке и эксплуатации. Но на своей практике видел крайне мало аттестаций (не гостайны), в ходе которых проверялось бы выполнение ТУ на СЗИ.
Стандарт PCI DSS требует проведения анализа правил межсетевого экрана обладателем сертификата раз в полгода. Раз в месяц специалисты центра киберзащиты DataLine проверяют правила МЭ в Cloud-152, чтобы найти ненужные, временные и неактуальные. Каждое новое правило проходит через наш Service Desk, в тикете фиксируется описание этого правила. Когда создается новое правило на МЭ, в комментарии пишется номер тикета.
Пример 4. В приказе ФСТЭК России № 21 подразумевается необходимость наличия сканера уязвимостей, опять же сертифицированного для аттестации. В качестве дополнительной меры предусмотрен pen-test, тестирование ИС на проникновение в п. 11.
С отчетами этих сканеров тоже забавная штука. Когда наши клиенты проходят аттестацию своих ИС, размещенных в Cloud-152, часто аттестующая организация хочет получить пустой отчет, в котором нет уязвимостей в аттестуемой ИС. Кроме того, аттестаторы обычно ограничиваются внутренним сканированием. Внешнее сканирование на моей практике делали аттестаторы лишь несколько раз, и это были конторы с именем.
PCI DSS четко прописывает не просто наличие сканера, но и регулярное ASV-сканирование (Approved Scanning Vendor) 4 раза в год. По его результатам инженеры вендора проверяют отчет и дают заключение. А тестирование на проникновение для Cloud-152 проводится 2 раза в год в соответствии с требованиями PCI DSS.
Пример 5. Многофакторная аутентификация. В приказе № 21 ФСТЭК России этого требования нет в явном виде. PCI DSS же требует наличия мультифакторной аутентификации.
Теперь посмотрим, как стандарт и закон “уживаются” на одной инфраструктуре.
Сегмент управления Cloud-152 и клиентская зона находятся на разном физическом оборудовании в выделенных стойках со СКУД и видеонаблюдением.
Cloud-152 построен на VMware vSphere 6.0 (сертификат № 3659). В ближайшем будущем будем переходить на 6.5, а 6.7 уже на инспекционном контроле.
Мы не используем на уровне виртуализации дополнительных СЗИ, так как с клиентами мы подписываем жесткий SLA по доступности IaaS-платформы, поэтому мы стараемся минимизировать дополнительные точки отказа.
Сегмент управления Cloud-152 отделен от сетей DataLine, клиентских сетей и от интернета с помощью сертифицированного программно-аппаратного комплекса Check Point, объединяющего в себе функции межсетевого экрана и средства обнаружения вторжений (сертификат № 3634).
Администраторы со стороны клиента проходят двухфакторную аутентификацию SafeNet Trusted Access (STA), прежде чем получить доступ к виртуальным ресурсам.
Администраторы Cloud-152 подключаются к облаку через средство контроля и отслеживания действий привилегированных пользователей СКДПУ (сертификат № 3352). Далее проходят также двухфакторную аутентификацию и только потом получают доступ к управлению Cloud-152. Этого требует стандарт PCI DSS.
В качестве средств защиты от несанкционированного доступа используем SecretNet Studio (сертификат № 3675). Антивирусная защита обеспечивается посредством Kaspersky Security for virtualization (сертификат № 3883).
В Cloud-152 задействованы сразу три сканера:
Дополнительно 4 раза в год проводим обязательное ASV-сканирование для PCI DSS.
В качестве SIEM используется Splunk, который более в РФ не продается. Сейчас мы в процессе поиска нового решения, проводим тесты. SIEM нужен для соответствия PCI DSS.
Схема Cloud-152
Теперь, когда я подробно рассказал, как соблюдение PCI DSS в IaaS-платформе под 152-ФЗ помогают достичь реальной безопасности, вы наверное спросите: зачем все так усложнять, когда можно и без всякого PCI DSS сделать так, чтобы работало. Да, можно, но вместе с PCI DSS у нас есть доказательство этого в виде сертификата, который мы ежегодно подтверждаем.
Мы живем в России, наши клиенты преимущественно ведут бизнес в РФ, и всем приходится соблюдать требования российского законодательства в области защиты персональных данных. Тот самый ФЗ “О персональных данных” от 27.07.2006 года № 152-ФЗ и правки к нему из 242-ФЗ от 21.07.2014 г. про обработку ПДн граждан РФ в базах, расположенных на территории РФ. GDPR далеко не всем нужен, и эту тему я тоже вынесу за пределы данной статьи.
152-ФЗ задумывался для защиты прав субъектов ПДн. Закон не дает готовых рецептов по защите персональных данных с помощью внедрения и настройки средств защиты (СЗИ). Если спуститься на более “конкретный” уровень постановления Правительства № 1119, приказа ФСТЭК России № 21 и приказа ФСБ России № 378, то там больше про факт наличия средств (в ряде случаев сертифицированных), а не про то, как это все должно быть настроено, чтобы было безопасно.
PCI DSS определяет требования к безопасности данных в индустрии платежных карт. Сфера его действия связана с деньгами, которые все традиционно оберегают особо тщательно. В нем больше конкретики, требований и листов для чтения :).
Возможно, кому-то покажется странным само соединение на одной платформе PCI DSS и 152-ФЗ, но для нас в этом есть смысл. Это не просто про два в одном флаконе, но и, что более важно, соединение бумажной и практической безопасности.
Дальше приведу несколько примеров про эту систему “сдержек и противовесов”.
Пример 1. Аттестат на инфраструктуру, соответствующую требованиям 152-ФЗ, выдается на 3 года. В течение этого времени в инфраструктуре ничего не должно меняться, либо обязательно должно быть согласовано с организацией, выдавшей аттестат. Аттестация равно фиксация системы на целых три года. Насколько инфраструктура отвечает требованиям от проверки до проверки – на совести аттестованного.
У PCI DSS цикл проверок короче: аудит каждый год. Дополнительно к этому 2 раза в год проводится pentest (внешний и внутренний нарушитель) и 4 раза в год – ASV-сканирование (Approved Scanning Vendor). Этого достаточно, чтобы держать инфраструктуру в тонусе.
Пример 2. У аттестации по 152-ФЗ есть своя цена, и это ограничения в выборе ПО и средств защиты. Если собираетесь проходить аттестацию, то все они должны быть сертифицированными. Сертифицированные – значит не самые свежие версии ПО и СЗИ. Например, сертифицирован ПАК CheckPoint, модельный ряд 2012 года, прошивка R77.10. На сертификации сейчас R77.30, но на нее уже заканчивается поддержка вендора в сентябре 2019. У PCI DSS таких требований нет (разве что к сканеру – он должен быть из списка одобренных). Это позволяет использовать параллельно средства защиты, у которых нет проблем с актуальностью версий.
Пример 3. И 152-ФЗ, и PCI DSS требуют наличия межсетевого экрана (МЭ). Только ФСТЭК России требует просто его наличия, а в случае с аттестацией – еще и наличия сертификата соответствия требованиям ФСТЭК России. В то же время у ФСТЭК нет требований по его настройке и обслуживанию. Фактически межсетевой экран может просто быть, а работает он корректно и работает ли в принципе, в документе уже не проговаривается. Такая же ситуация со средствами антивирусной защиты (САВЗ), средствами обнаружения вторжения (СОВ) и средствами защиты информации от несанкционированного доступа (СЗИ от НСД).
Проверки аттестующих организаций тоже не могут гарантировать, что все работает как надо. Часто все ограничивается выгрузкой всех правил межсетевого экрана. Бывает еще, что просто снимают контрольные суммы с файлов ОС Gaia (ОС CheckPoint). Эти файлы изменяются динамически, и их контрольная сумма тоже. Смысла в таких проверках немного.
Есть еще требования производителей сертифицированных СЗИ по их установке и эксплуатации. Но на своей практике видел крайне мало аттестаций (не гостайны), в ходе которых проверялось бы выполнение ТУ на СЗИ.
Стандарт PCI DSS требует проведения анализа правил межсетевого экрана обладателем сертификата раз в полгода. Раз в месяц специалисты центра киберзащиты DataLine проверяют правила МЭ в Cloud-152, чтобы найти ненужные, временные и неактуальные. Каждое новое правило проходит через наш Service Desk, в тикете фиксируется описание этого правила. Когда создается новое правило на МЭ, в комментарии пишется номер тикета.
Пример 4. В приказе ФСТЭК России № 21 подразумевается необходимость наличия сканера уязвимостей, опять же сертифицированного для аттестации. В качестве дополнительной меры предусмотрен pen-test, тестирование ИС на проникновение в п. 11.
С отчетами этих сканеров тоже забавная штука. Когда наши клиенты проходят аттестацию своих ИС, размещенных в Cloud-152, часто аттестующая организация хочет получить пустой отчет, в котором нет уязвимостей в аттестуемой ИС. Кроме того, аттестаторы обычно ограничиваются внутренним сканированием. Внешнее сканирование на моей практике делали аттестаторы лишь несколько раз, и это были конторы с именем.
PCI DSS четко прописывает не просто наличие сканера, но и регулярное ASV-сканирование (Approved Scanning Vendor) 4 раза в год. По его результатам инженеры вендора проверяют отчет и дают заключение. А тестирование на проникновение для Cloud-152 проводится 2 раза в год в соответствии с требованиями PCI DSS.
Пример 5. Многофакторная аутентификация. В приказе № 21 ФСТЭК России этого требования нет в явном виде. PCI DSS же требует наличия мультифакторной аутентификации.
Теперь посмотрим, как стандарт и закон “уживаются” на одной инфраструктуре.
Про устройство Cloud-152
Сегмент управления Cloud-152 и клиентская зона находятся на разном физическом оборудовании в выделенных стойках со СКУД и видеонаблюдением.
Cloud-152 построен на VMware vSphere 6.0 (сертификат № 3659). В ближайшем будущем будем переходить на 6.5, а 6.7 уже на инспекционном контроле.
Мы не используем на уровне виртуализации дополнительных СЗИ, так как с клиентами мы подписываем жесткий SLA по доступности IaaS-платформы, поэтому мы стараемся минимизировать дополнительные точки отказа.
Сегмент управления Cloud-152 отделен от сетей DataLine, клиентских сетей и от интернета с помощью сертифицированного программно-аппаратного комплекса Check Point, объединяющего в себе функции межсетевого экрана и средства обнаружения вторжений (сертификат № 3634).
Администраторы со стороны клиента проходят двухфакторную аутентификацию SafeNet Trusted Access (STA), прежде чем получить доступ к виртуальным ресурсам.
Администраторы Cloud-152 подключаются к облаку через средство контроля и отслеживания действий привилегированных пользователей СКДПУ (сертификат № 3352). Далее проходят также двухфакторную аутентификацию и только потом получают доступ к управлению Cloud-152. Этого требует стандарт PCI DSS.
В качестве средств защиты от несанкционированного доступа используем SecretNet Studio (сертификат № 3675). Антивирусная защита обеспечивается посредством Kaspersky Security for virtualization (сертификат № 3883).
В Cloud-152 задействованы сразу три сканера:
- сертифицированный XSpider (сертификат № 3247) для выполнения требований 152-ФЗ. Пользуемся им раз в квартал.
- Nessus для фактической работы по поиску и анализу уязвимостей внутри платформы Cloud-152.
- Qualys – сканер, который нам нужен для внешнего сканирования по требованиям PCI DSS. Его мы используем ежемесячно, а бывает и чаще.
Дополнительно 4 раза в год проводим обязательное ASV-сканирование для PCI DSS.
В качестве SIEM используется Splunk, который более в РФ не продается. Сейчас мы в процессе поиска нового решения, проводим тесты. SIEM нужен для соответствия PCI DSS.
Схема Cloud-152
Теперь, когда я подробно рассказал, как соблюдение PCI DSS в IaaS-платформе под 152-ФЗ помогают достичь реальной безопасности, вы наверное спросите: зачем все так усложнять, когда можно и без всякого PCI DSS сделать так, чтобы работало. Да, можно, но вместе с PCI DSS у нас есть доказательство этого в виде сертификата, который мы ежегодно подтверждаем.
Комментарии (10)
Otv_komar
28.08.2019 15:37Аттестат сейчас до 5 лет выдают
svs422 Автор
28.08.2019 15:37Да, можно и на 5 лет у кого-то, наверно, получить аттестат, ФСТЭК допускает. Но вот у нас аттестат свежий от 26.04.2019 г., ООО «НАЦ» выдали на 3 года.
Loreweil
30.08.2019 06:28Не путайте с государственными информационными системами. 5 лет прописано в 17 приказе ФСТЭК, а в 21 приказе (для ПДн) обязательная аттестация не предусмотрена (вместо нее оценка эффективности принятых мер). При этом других нормативных документах (Положение по аттестации и ГОСТ) максимальный срок аттестата — 3 года.
Loreweil
30.08.2019 06:30В то же время у ФСТЭК нет требований по его настройке и обслуживанию.
Вы серьезно?
УПД.3 Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами
Базовая мера для всех уровней защищенности ПДн. А какие вы хотели требования по настройке МЭ от регулятора? Конкретные правила и белые списки? Требование непосредственно по настройке МЭ — есть, только конкретные параметры настройки владелец ИСПДн определяет самостоятельно. Для этого в том числе делается модель угроз.
mmMike
А какой имеет отношение PCI DSS к вам? Вы не процессинг, не банк, не… и т.д.
Только очень маленькая часть требований разве что..
svs422 Автор
На нашей IaaS-платформе размещаются банковские системы, разные порталы с оплатой, программы лояльности и т.д., в общем на ней могут быть размещены ИС, требующие обеспечения соответствия PCI DSS. Да, к IaaS требований меньше, чем к самой ИС, но сильно больше, чем к ЦОД (по сути: СКУД, видео, охрана), например, при colocation.
mmMike
Спасибо. Понятно.
А то смутило упоминание контекста PCI DSS (требования Visa & MC к ТСП и процессингам), касающиеся в основном хранению и использованию платежных/карточных данных (ключи,HSM,PIN блоки, треки и прочее) к обычному универсальному облачному сервису.
Хотя, любопытно как это выглядит… Организация конечная (банк/эквайрер/процессинг..) проходит сертификацию для Visa & MC по PCI DSS. Как помогает сертфикат выданный "облаку" сертификации этой организации?
"Как" — в смысле, как это выглядит процедурно.
svs422 Автор
Конечная организация говорит своему аудитору по PCI DSS, что ИС расположена в облаке таком-то, показывает Договор с провайдером. Аудитор запрашивает сертификат по PCI DSS на облако и документ AoC – Attestation of Compliance, в котором указано кто и когда проводил сертификацию облака по PCI DSS, какой версии стандарта, что входит в область сертификации. Если все ок, то аудитор не проверяет облако (оно уже проверено другим аккредитованным аудитором по PCI DSS), проверяет только ИС. Область сертификации очень важна, так как бывает только co-location входит, тогда к среде виртуализации, сети, хранилищам и т.д. доверия у аудитора быть не может и тут несколько вариантов исхода. У нас, например, в область сертификации входят (как в AoC напишу):
— infrastructure/network
— physical space (co-location)
— storage
— shared hosting provider
— other hosting (specify).
Cloud-152 у нас находится в ЦОД NORD-1, а сертификат co-location покрывает все наши ЦОД, в любом можно разместить оборудование и будет на уровне ЦОД обеспечено соответствие PCI DSS, а вот облако только в NORD-1 и только Cloud-152.
mmMike
Спасибо за подробный ответ.
Как выглядит сертификация PCI DSS на всем своем — я знаю. А с облаком никогда не сталкивался.