Как из бумажной безопасности сделать практическую, или зачем нам соблюдение 152-ФЗ и PCI DSS в одном облаке

в 7:20, , рубрики: 152-фз, pci dss, безопасность, Блог компании DataLine, информационная безопасность, Облачные вычисления, облачные сервисы

Наша IaaS-платформа Cloud-152 одновременно сертифицирована по требованиям PCI DSS и имеет аттестат соответствия 152-ФЗ по УЗ-2 (без актуальных угроз 1-го и 2-го типа). Эта же платформа входит еще и в область действия нашей системы управления информационной безопасностью (СУИБ), которую мы сертифицировали по ISO/IEC 27001:2013. Про это и про STAR Cloud Security Alliance (CSA) я обязательно как-нибудь тоже расскажу, но сегодня остановлюсь на плюсах синергии PCI DSS и 152-ФЗ для наших клиентов.

Как из бумажной безопасности сделать практическую, или зачем нам соблюдение 152-ФЗ и PCI DSS в одном облаке - 1
Мы живем в России, наши клиенты преимущественно ведут бизнес в РФ, и всем приходится соблюдать требования российского законодательства в области защиты персональных данных. Тот самый ФЗ “О персональных данных” от 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.
Как из бумажной безопасности сделать практическую, или зачем нам соблюдение 152-ФЗ и PCI DSS в одном облаке - 2
Схема Cloud-152

Теперь, когда я подробно рассказал, как соблюдение PCI DSS в IaaS-платформе под 152-ФЗ помогают достичь реальной безопасности, вы наверное спросите: зачем все так усложнять, когда можно и без всякого PCI DSS сделать так, чтобы работало. Да, можно, но вместе с PCI DSS у нас есть доказательство этого в виде сертификата, который мы ежегодно подтверждаем.

Автор: svs422

Источник


* - обязательные к заполнению поля