Комментарии 13
А какой имеет отношение PCI DSS к вам? Вы не процессинг, не банк, не… и т.д.
Только очень маленькая часть требований разве что..
На нашей IaaS-платформе размещаются банковские системы, разные порталы с оплатой, программы лояльности и т.д., в общем на ней могут быть размещены ИС, требующие обеспечения соответствия PCI DSS. Да, к IaaS требований меньше, чем к самой ИС, но сильно больше, чем к ЦОД (по сути: СКУД, видео, охрана), например, при colocation.
Спасибо. Понятно.
А то смутило упоминание контекста PCI DSS (требования Visa & MC к ТСП и процессингам), касающиеся в основном хранению и использованию платежных/карточных данных (ключи,HSM,PIN блоки, треки и прочее) к обычному универсальному облачному сервису.
Хотя, любопытно как это выглядит… Организация конечная (банк/эквайрер/процессинг..) проходит сертификацию для Visa & MC по PCI DSS. Как помогает сертфикат выданный "облаку" сертификации этой организации?
"Как" — в смысле, как это выглядит процедурно.
Конечная организация говорит своему аудитору по 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.
— 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.
Аттестат сейчас до 5 лет выдают
Да, можно и на 5 лет у кого-то, наверно, получить аттестат, ФСТЭК допускает. Но вот у нас аттестат свежий от 26.04.2019 г., ООО «НАЦ» выдали на 3 года.
Не путайте с государственными информационными системами. 5 лет прописано в 17 приказе ФСТЭК, а в 21 приказе (для ПДн) обязательная аттестация не предусмотрена (вместо нее оценка эффективности принятых мер). При этом других нормативных документах (Положение по аттестации и ГОСТ) максимальный срок аттестата — 3 года.
У PCI-DSS несколько классификаций
По какой прошли вы?
По какой прошли вы?
В то же время у ФСТЭК нет требований по его настройке и обслуживанию.
Вы серьезно?
УПД.3 Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами
Базовая мера для всех уровней защищенности ПДн. А какие вы хотели требования по настройке МЭ от регулятора? Конкретные правила и белые списки? Требование непосредственно по настройке МЭ — есть, только конкретные параметры настройки владелец ИСПДн определяет самостоятельно. Для этого в том числе делается модель угроз.
Не видел ни разу обоснования настройки FW на основании МУ. Скорее видел, что в МУ определяется необходимость сертифицированного FW, поэтому в результате появляется отечественный на периметре, пропускающий все на следующий несертифицированный, на котором все правила фильтрации и осуществляются. Подход с МУ нормальный, но такого не встречал просто на практике.
Я бы предложил уточнить следующее:
1. Подход большинства ИТшников, утрирую, – «открыть все, лишь бы работало», у ИБшников – «закрыть все и открывать по запросу». Если бы Регулятор определил подход, меньше вопросов было бы при настройке FW в ИСПДн.
2. Обоснование правил настройки нужно документировать, это было бы полезно и проверяющим.
3. Глубину хранения логов FW тоже не мешало бы определить, это позволило бы более верно модели FW подбирать и обеспечивать расследование инцидентов в случае необходимости. Тут ведь есть срок исковой давности 3 года, есть лучшие практики 90 дней, есть размер диска, и т.д.
4. Не все обязательно нужно через FW пускать, бэкапы внутри корп.сети (разные сегменты) избыточно через FW запускать в ряде случаев. УПД.3 исключений не предусматривает.
Я бы предложил уточнить следующее:
1. Подход большинства ИТшников, утрирую, – «открыть все, лишь бы работало», у ИБшников – «закрыть все и открывать по запросу». Если бы Регулятор определил подход, меньше вопросов было бы при настройке FW в ИСПДн.
2. Обоснование правил настройки нужно документировать, это было бы полезно и проверяющим.
3. Глубину хранения логов FW тоже не мешало бы определить, это позволило бы более верно модели FW подбирать и обеспечивать расследование инцидентов в случае необходимости. Тут ведь есть срок исковой давности 3 года, есть лучшие практики 90 дней, есть размер диска, и т.д.
4. Не все обязательно нужно через FW пускать, бэкапы внутри корп.сети (разные сегменты) избыточно через FW запускать в ряде случаев. УПД.3 исключений не предусматривает.
В МУ не обосновываются конкретные настройки FW, в МУ определяются актуальные угрозы, исходя из которых уже надо смотреть какие из них нейтрализуются настройками FW и думать какие конкретно настройки нужно применить для нейтрализации угроз. Конкретные настройки могут быть предложены в эскизном (техническом) проекте на систему защиты информации. Необходимость сертифицированного FW тоже определяется не в МУ, а в проектных документах. Кстати, для чистых ИСПДн (не в составе ГИС) нет явного требования сертифицированного FW.
1. Поэтому ИБ должно быть отдельно от ИТ. В данном случае регулятор поступил рационально. Если бы ФСТЭК определил подход (например «только белые списки»), то ничего хорошего из этого могло бы не получиться (все бы просто игнорировали такое требование). Такой подход мы уже проходили с 58-приказом ФСТЭК, отмененным в 2013 году.
3. Определение времени хранения логов (всех, не только FW) установлено мерой РСБ.3. Здесь тоже оператор должен самостоятельно определить эти параметры.
4. Перечитайте еще раз УПД.3, управление потоками это не только правила FW.
1. Поэтому ИБ должно быть отдельно от ИТ. В данном случае регулятор поступил рационально. Если бы ФСТЭК определил подход (например «только белые списки»), то ничего хорошего из этого могло бы не получиться (все бы просто игнорировали такое требование). Такой подход мы уже проходили с 58-приказом ФСТЭК, отмененным в 2013 году.
3. Определение времени хранения логов (всех, не только FW) установлено мерой РСБ.3. Здесь тоже оператор должен самостоятельно определить эти параметры.
4. Перечитайте еще раз УПД.3, управление потоками это не только правила FW.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как из бумажной безопасности сделать практическую, или зачем нам соблюдение 152-ФЗ и PCI DSS в одном облаке