При использовании небезопасных (передающих логин и пароль пользователя в открытом виде, таких как: telnet, ftp), всегда имеются риски компрометации серверов и данных платежных карт, которые в них обрабатываются. Подобные риски компрометации имеются и при использовании ненужных для бизнеса протоколов и сервисов, которые также могут содержать уязвимости, т.к. их никто не исправляет (например, потому что сервис никто не использует и не администрирует). Данные виды рисков, в соответствии с требованиями стандарта, каждая организация должна осознавать и стараться минимизировать.

Выполнение требования 1.1.5 направлено на решение этой задачи и включает в себя: документирование всех необходимых для ведения бизнеса протоколов и сервисов, а также обоснование их  применения. Небезопасные протоколы также можно использовать, но только в случае если разработаны и описаны защитные меры при их использовании.

На первый взгляд просто, но на практике часто встречаются следующие ошибки:

1. Требуемый список документируется, но в него включаются только протоколы, используемые при взаимодействии между сегментами (через межсетевые экраны), взаимодействие внутри сегментов не рассматривается;
2. В список не включаются инфраструктурные протоколы для серверных ресурсов (например, используемые для управления ОС, БД);
3. Не проводится анализ необходимости протоколов и в результате в список включаются все протоколы и сервисы «как есть» (например, по результату команды netstat);
4. Меры защиты уязвимых протоколов не разрабатываются либо недостаточны для снижения риска перехвата паролей.

Легко увидеть, что при такой реализации, задача, описанная выше, не решается. Рекомендуемый порядок выполнения требования 1.1.5 следующий:

1. Провести сканирование всех внутренних сетей, попадающих в область  проверки стандарта.
2. Провести анализ обнаруженных открытых портов и работающих сервисов на предмет:

   a. Необходимости (уточнить  для чего нужен данный сервис, кто им пользуется);
   b. Безопасности (выделить те протоколы, где логин и пароль передается в незашифрованном виде).
   -  В ходе анализа необходимо:
   a. Учитывать все сетевое взаимодействие (как между сегментами, так и внутри каждого сетевого сегмента);
   b. Учитывать как прикладные, так и инфраструктурные протоколы и сервисы, в том числе на сетевом оборудовании.

3. Отказаться от  использования ненужных для бизнеса  протоколов и сервисов, выключив их на серверах (и, желательно, удалив соответствующие программные модули) или закрыв доступ к ним по сети локальным межсетевым экраном.
4. Заменить уязвимые протоколы и сервисы на безопасных аналоги везде, где это возможно (например,  FTP на  SFTP,  telnet на SSH и т.п.); Для уязвимых протоколов, отказаться от использования которых невозможно, разработать защитные меры, снижающие риск перехвата пароля (например, выделение ресурсов, которые их используют в отдельный  VLAN);
5. Документировать все оставшиеся (необходимые)  протоколы, сервисы, порты и их назначение, при этом, для небезопасных включить в документ обоснование невозможности их замены и описание применяемых защитных мер.

Пример документирования:

Название	Назначение	Сетевой протокол, сервис	Уязвимые протоколы
			Причина использования	Защитные меры
ISO8583	Передача финансовой информации	TCP:  2400-2500
RDP	Административный доступ к windows-серверам	TCP: 3389		Шифрование 128 bit
Oracle SQLNET	Доступ к  БД	TCP:  1521,1526
Telnet	Удаленное администрирование motorola vanguard	TCP: 23	Не поддерживается SSH	Выделенный не маршрутизируемый VLAN управления, в который включен узел с поддержкой SSH. АРМ администратора>узел с поддержкой ssh> telnet на motorola

 

Андрей Казимиров,  QSA