В сфере ИТ и ИБ давно утвердилось понятие бенчмарк (benchmark) — это технический стандарт настройки конкретной операционной системы, сетевого оборудования или серверного софта. В таких документах обычно описывают, что и как должно работать в инфраструктуре компании, на какие аспекты защиты это влияет, как все проверить и настроить. Звучит коротко и ясно, но на практике оказывается сложнее.

В этой статье мы поговорим о проблемах современных технических стандартов (бенчмарков) информационной безопасности и о том, как их можно решить.

Как выглядят современные бенчмарки

Для каждой системы эти стандарты разные. В мире наибольшей известностью пользуются стандарты семейства CIS Benchmarks, разрабатываемые под эгидой международной организации CIS силами приглашенных экспертов-энтузиастов со всего мира.

Обычно такие стандартны включают в себя сотни требований, которые описывают в том числе:

• длину и сложность паролей;
• права доступа к файлам разных типов;
• рекомендованные ко включению и отключению сервисы.

Плюсы и минусы существующих технических стандартов

Как и любое методическое пособие, бенчмарки в сфере безопасности полезны тем, что позволяют повысить средний уровень защищенности инфраструктуры. Это выражается в том, что инфраструктура, настроенная хотя бы по основным рекомендациям бенчмарков, гораздо труднее поддается взлому — как минимум пентестерами (в ряде таких случаев им вообще не удается достичь поставленных целей из-за ограничений по срокам или допустимым целям атаки или допустимым методам атаки).

Поскольку каждый такой стандарт довольно велик, то его просто можно использовать как справочник или чек-лист, по которому осуществляется настройка оборудования и софта.

Признанные за рубежом бенчмарки знакомы компаниям из разных стран, поэтому они знают об их плюсах и стремятся выполнять прописанные в документах требования.

Но не все так гладко на практике: применение привычных всем стандартов не обходится без проблем. Вот лишь некоторые из них.

Требований очень много

Если на каком-то узле установлена и ОС, и парочка серверных приложений, то нужно будет применить несколько стандартов, а общее количество требований легко может превысить 500. Приведем простую арифметику для случая типичной крупной организации:

1. Рабочие станции: более 500 требований для Windows и MS Office, количество узлов — от тысячи.
2. Серверы: в зависимости от ОС и установленного серверного ПО, от 100 до 700 требований на узел, количество узлов — сотни.
3. Сетевое оборудование: в зависимости от марки, модели и функциональности от 20 до 80 требований на узел, количество узлов — сотни.

Нижняя граница оценки — 500 тысяч требований по всей инфраструктуре. Логично, что обеспечить соответствие всех ее узлов всем требованиям таких стандартов невозможно, равно как и отследить факт соблюдения этих требований.

Из чересчур большого количества требований и узлов в подконтрольной инфраструктуре также вытекает немаловажное следствие: длительность и трудоемкость автоматизированного сканирования даже части инфраструктуры, как правило, не устраивают ни IT-администраторов, ни специалистов по ИБ. Чтобы хоть как-то проверить все узлы, приходится идти на различные ухищрения: назначать определенные «технологические окна» для разных групп узлов, производить сканирования реже, чем хотелось бы.

При этом все равно приходится внимательно следить за доступностью сети удаленных филиалов и ее пропускной способностью (в ряде случаев это спутниковые каналы, что добавляет сложностей), стараться не запутаться в периодичности сканирований, да и просто находить время для решения возникающих проблем сканирования.

Трудно расставлять приоритеты

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

Ряд организаций стремятся создать свои собственные стандарты защищенных настроек на основе CIS, количество требований в которых меньше оригинала. Однако в случае компаний других сфер специалистам часто не хватает узкоспециализированных знаний.

Непонятно, на что именно влияет конкретное требование

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

Нет стимула использовать технические стандарты

Добиться выполнения требований множества бенчмарков на множестве узлов — это огромная, сложная и напряженная работа. При этом если IT-специалист, занимающийся инфраструктурой, даже не понимает, что конкретно даст выполнение тех или иных требований уже и так работающей системе — нет никакого стимула это использовать.

Как решить эти проблемы: стандарты PT Essential

Главные проблемы сегодняшних стандартов в информационной безопасности — их огромный размер и общая неконкретность. Если не устранить эти два недостатка, то польза от применения таких стандартов всегда будет ограничена.

Чтобы решить эти проблемы, для различных целевых систем мы разработали стандарты нового поколения PT Essential (PTE) и реализуем их в MaxPatrol 8. Новые документы создавались на основе существующих бенчмарков (например, CIS) и информации о реальных проблемах защищенности, полученной по результатам тестирований на проникновение нашими специалистами. При этом мы используем принцип Парето 20/80 –— обычно меньшая часть требований позволяет закрыть большое количество возможных проблем безопасности.

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

• сложность паролей*,
• периодичность смены паролей,
• применение устаревших ОС и ПО, снятых с поддержки.

* Результаты тестирований уровня безопасности систем, проведенных Positive Technologies, показали, что подавляющее большинство успешно подобранных в ходе тестирований защищенности паролей были составлены предсказуемым образом. Половина из них была связана с различными комбинациями месяца или времени года с цифрами, обозначающими год (например, Fduecn2019, Зима2019). На втором месте по распространенности оказались пароли типа 123456, 1qaz!QAZ, Qwerty1213, которые составляются из близкорасположенных клавиш на клавиатуре.

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

Вот ключевые отличия новых бенчмарков:

• Каждый из них содержит минимум требований — включаются только те, что напрямую влияют на защищенность системы. Количество требований PTE по каждой целевой системе в N (N — от 3 до 10) раз меньше аналога CIS. Как следствие, пропорционально уменьшаются:
  
  • время сканирования,
  • трудозатраты на разбор сканирования и устранение найденных недостатков.
  
  
• Для большинства требований стандарта присваиваются метрики CVSS — по аналогии с уязвимостями. Это позволяет сразу расставить приоритеты по устранению найденных недостатков.
  
• В описании всех требований описываются последствия, с которыми организация может столкнуться, если не выполнит его.
  

Ниже краткое сравнение семейств CIS Benchmarks и PT Essential:

Вот как выглядит пример требования PTE (примеры ниже относятся к UNIX-системам; вместо отдельных стандартов на каждую UNIX-подобную операционную систему создан единый стандарт для всех таких систем, поддерживаемых в рамках MaxPatrol 8):

Пример требования «Отключить беспарольный удаленный вход в систему для rlogin/rsh»

• Настроенные сервисы rlogin/rsh позволяют входить в систему без указания пароля.
• Они могут быть настроены как для всех пользователей (задается в /etc/hosts.equiv), так и индивидуально для каждого пользователя (в $HOME/.rhosts).
• При наличии этих настроек пользователи могут входить на целевой сервер с указанных клиентов, не вводя пароля на целевом сервере.
• Кроме того, R-подсистемы страдают от атак ARP spoofing, так как критерий доверия строится только на адресах клиентов.
• Использование этих устаревших подсистем представляет крайне серьезный риск, поэтому их строго рекомендуется отключить.
• Все прикладное и системное ПО, использующее эти средства, поддерживает SSH как гораздо более безопасную альтернативу.

CVSS: 3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8)

Пример требования «Исключить опасные команды из настроек sudo»

Неправильные настройки sudo могут позволить обладающему правом выполнения некоторых (потенциально опасных) команд от имени root пользователю:

1. повысить привилегии в системе,
2. перезаписать системные файлы, нарушив работу системы.

Потенциально опасной может быть любая команда, позволяющая:

• записать в произвольный (указанный пользователем) файл;
• записать в один из системных файлов;
• уничтожить файловую систему либо дисковый раздел.

Необходимо исключить опасные команды из настроек sudo.

CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

Пример требования «Обеспечить установку корректных прав доступа к файлам запущенных процессов»

• Контроль всех исполняемых файлов, запускаемых во время работы ОС, является непростой задачей. Однако в каждый момент времени можно установить, какие процессы запущены, и соответственно — какие исполняемые файлы с ними связаны.
• Права доступа к этим исполняемым файлам должны быть 755 или строже, их владельцами в подавляющем большинстве случаев должен являться root либо системные пользователи (то есть не имеющие возможности входить в систему с паролем).
• В противном случае если исполняемый файл процесса может быть изменен непривилегированным пользователем, будет выполнен код с правами пользователя, запустившего процесс. Если таким пользователем был root, то система будет полностью скомпрометирована.

CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

Важно: в обязательном порядке каждое требование содержит руководство по устранению недостатков безопасности и проверке наличия проблем.

Заключение

Технические стандарты в информационной безопасности — это важный инструмент повышения уровня защищенности инфраструктуры, сильно усложняющий жизнь злоумышленникам при грамотной реализации и хорошем взаимодействии между департаментами ИТ и ИБ. Однако многие современные стандарты слишком сложны и объемны для практического применения.

Гораздо удобнее использовать стандартные семейства PT Essential — бенчмарки нового поколения, которые доносят только самой важную информацию и базируются на опыте проведения сотен тестирований на проникновение. И сотрудникам IT-департаментов, и специалистам по ИБ при их внедрении понятно, какие требования наиболее значимы, с чего нужно начать, и какие проблемы могут возникнуть при несоответствии этим требованиям.

Применение требований PT Essential позволяет оперативно выявить и устранить самые важные проблемы безопасности в инфраструктуре с заметным снижением трудоемкости и сложности этого процесса. Так почему бы не усложнить жизнь пентестерам и злоумышленникам?..