+7 495 228-02-08 info@tessis.ru
ВХОД
Меню
Array ( [ROOT_MENU_TYPE] => top [MENU_CACHE_TYPE] => Y [MENU_CACHE_TIME] => 36000000 [MENU_CACHE_USE_GROUPS] => Y [MENU_CACHE_GET_VARS] => [MAX_LEVEL] => 2 [CHILD_MENU_TYPE] => left [USE_EXT] => [DELAY] => N [ALLOW_MULTI_SELECT] => [CACHE_TYPE] => Y [CACHE_TIME] => 36000000 [~ROOT_MENU_TYPE] => top [~MENU_CACHE_TYPE] => Y [~MENU_CACHE_TIME] => 36000000 [~MENU_CACHE_USE_GROUPS] => Y [~MENU_CACHE_GET_VARS] => [~MAX_LEVEL] => 2 [~CHILD_MENU_TYPE] => left [~USE_EXT] => N [~DELAY] => N [~ALLOW_MULTI_SELECT] => N [~CACHE_TYPE] => Y [~CACHE_TIME] => 36000000 [CACHE_SELECTED_ITEMS] => 1 )

ТРИ РЕГЛАМЕНТА.

Тренды ИБ в сфере стандартов нормативных требований.

Сергей Кузнецов

Глава направления GemaltoEnterprise & Cybersecurity в России и СНГ

2018 год богат на международные стандарты и обновления требований Регламентов по безопасности, которые вступают в силу и ожидаемо серьезно осложнят жизнь организациям. Как показывает практика, многие организации даже не подозревают, что они, в силу своей деятельности, попадают под действие Регламентов. Есть три, касающихся Европейского законодательства и финансовых организаций : PCI-DSS 3.2, GDPR и eIDAS. Они вступают в силу в Феврале, Мае и Сентябре 2018 года соответственно. Примечательно, первые два Регламента предполагают существенные штрафы за их несоблюдение. Так размер штрафа за несоблюдение GDPR может составлять 2 миллиона евро или до 4% годового оборота компании, что - больше... Уверен, что до конца этого календарного года, мир увидит реальные примеры применения наказаний за несоблюдение Регламентов по безопасности для Европейских и сотрудничающих с ними компаний, расположенных в разных частях мира.

В PCI-DSS 3.2, раздел 8.3, наиболее значительным изменением явилось требование многофакторной аутентификации для администраторов внутри защищенной инфраструктуры организации, имеющей дело с данными платежных карт. Это очень существенное и порой трудно-выполнимое требование отражает понимание рисков, связанных с одной стороны с инсайдерами, а с другой – с привилегированными пользователями. Важно отметить, что в требованиях появилось явное описание понятия многофакторной аутентификации (то что вы знаете, то что вы имеете или то что вам присуще) и неприменимость многократного использования однофакторных, хотя и сложных, и отличающихся паролей. Также изменения коснулись всех сотрудников, имеющих доступ к данным держателей карт – Пункты 8.3.1 и 8.3.2. Теперь, независимо от их нахождения в защищенной сети или работающих удаленно, они должны применять многофакторную аутентификацию. Другим важным изменением стали требования к Сервис Провайдерам. Они коснулись, как компаний в целом, так и напрямую отдельных руководителей этих компаний. Теперь Сервис Провайдеры должны иметь описание полной криптографической архитектуры, что должно нивелировать риски утечек в третьих вовлеченных сторонах. Также добавлено требование регулярных пентестов инфраструктуры и создание процессов защиты, отражения, документирования и информирования об атаках, которые могли привести к потере данных.   

Несмотря на сужение периметра вокруг данных и минимизацию хранимой информации, требования к физической безопасности становятся не менее актуальными и выражаются в комбинированных требованиях контроля доступа в помещения (RFID) с аутентификаторами PKI (Смарт Картами) инфраструктуры открытых ключей. При этом все более приветствуются возможности визуального контроля Смарт Карт в решениях Корпоративных Бэджей (Физический и Цифровой идентификатор сотрудника) и методов контекстной аутентификации, когда в зависимости от местонахождения сотрудника и используемого им устройства предъявляются разные по степени сложности и защищенности методы аутентификации. (Рисунок 1)

8.11

8.1.2

8.1.3-8.1.8

8.2

8.2.3

8.3

9

Context-based

 + 

  +

  +

  +

  +

  +

OTP Push

  +

  +

  +

  +

  +

  +

PKI (cert-based)

  +

  +

  +

  +

  +

  +

PKI with PAC

  +

  +

  +

  +

  +

  +

  +

OOB

  +

  +

  +

  +

  +

  +

OTP HW

  +

  +

  +

  +

  +

  +

Рисунок 1.

Если требования PCI-DSS к использованию шифрования и хранения ключей шифрования отдельно, в железе, уже не является чем-то удивительным, то возможность не разглашать публично взлом данных, которые были зашифрованы (Регламент GDPR) – это важный фактор. На текущий момент только 4% компаний шифруют данные, что открывает большую перспективу по применению методов шифрования данных и управлению ключами шифрования в финансовых организациях и корпоративном секторе, особенно, если подходить к этой задаче системно и защищать данные в состоянии покоя, во время транзита, в виртуальных средах, облаках и т.д.

В свете всё большего использования моделей аутсорсинга, облачных и виртуальных технологий, что благотворно влияет на сокращение издержек и расходов, открытым остается вопрос ответственности организации за персональные данные и данные платежных карт. Кому вы доверяете? Кто будет нести ответственность, если ваши данные будут скомпрометированы в Облаке или Арендованном ЦОДе? Ответ – никому. Организации должны ответственно подходить к вопросам защиты информации и первыми шагами, которые помогут решить эти вопросы начинаются с контроля доступа с помощью автоматизированных систем Аутентификации, шифрования данных и управления жизненным циклом ключей шифрования. В совокупности использование этих подходом позволит закрыть львиную долю требований Регламентов по безопасности и оградить ваши организации от материальной ответственности и штрафов.