Политика ограничения программного обеспечения Software Restriction Policy (SRP) - Черные списки против белых списков
ОГЛАВЛЕНИЕ
Черные списки против белых списков
Первые фильтры для портов на сетевых маршрутизаторах (network router) в начале 1990-х годов были настроены на блокировку особых портов, и разрешали все извне, растущего интернета. Сетевые администраторы (Network administrator) всегда были на шаг позади хакеров, которые мгновенно изменили атаки для проникновения через новые службы. Когда сетевые администраторы блокировали входящий TELNET, то был атакован RLOGIN или FTP. Эта была бесконечная война с хакерами, которая могла привести лишь к реализации на брандмауэре правила "Default Deny" (запретить все по умолчанию). По умолчанию ничего не разрешалось до тех пор, пока мы не зададим некоторые исключения из правила по умолчанию.
Взгляните также на антивирусные приложения, которым необходимо постоянно обновлять описания вирусов, чтобы идентифицировать код, который нельзя запускать на сетевых компьютерах – вместо того, чтобы обратить этот процесс и описать все, что нам нужно запускать, и запретить все остальное программное обеспечение. То же самое справедливо и для приложений, которые запускаются сегодня на компьютерах по всему миру. Для чего по умолчанию разрешено запускать все программы, когда мы в большинстве случаев точно знаем приложения, которые нам понадобятся для работы? Почему не ввести правило "Default deny all applications (по умолчанию запретить все приложения)" на наших клиентских компьютерах и делать исключении из этого правило по умолчанию для приложений, которые можно запускать пользователям?
Подход "Default deny all applications (по умолчанию запретить все приложения)" известен также как белый список (Whitelisting или WL). При настройке SRP в режиме белого списка (WL mode) уровень безопасности по умолчанию (Default Security Level) устанавливается в ‘Disallowed (запрещено)’ – затем создаются дополнительные правила с исключениями для правила по умолчанию. Подумайте об этом, ни один файл нельзя будет запустить на компьютере до тех пор, пока вы не указали это в политике – разве вам не нравится такая идея!
Если мы хотим использовать WL, то мы должны закончить список разрешенного программного обеспечения – и если мы хотим использовать метод идентификации (identification method) на основе HASH, то нам нужен доступ к выполняемым файлам. Если мы хотим использовать правило сертификатов (certificate rule), то нам нужен файл сертификата (certificate file с расширением .CER или .CRT) или просто доступ к подписанному выполняемому файлу.
Черный список (Blacklisting BL) после подключения SRP имеет уровень безопасности по умолчанию (default Security Level) также известный, как ‘Unrestricted (неограниченный)’. BL можно назвать задачей Sisyphean – он никогда не заканчивается и кроме того, он на обеспечивает такого уровня безопасности, который можно получить с помощью белых списков WL does. Благодаря большому количеству и формам, которые может принимать вредоносный код, блокировка всех их становится достаточно сложной задачей, не важно используете ли вы при этом отпечатки кода, или имен файлов. Зачем поддерживать список из более миллиона типов вредоносного кода – список, который быстро разрастается – вместо того, чтобы поддерживать список из всего лишь 50 или 100 приложений, необходимых для работы организации?
Если смотреть на управляемость, то BL гораздо проще управлять и реализовать, но просто невозможно получить тот же уровень безопасности с помощью BL, как благодаря WL. BL замечательны для слабо управляемых компьютеров, но если мы хотим жестко ограничить наши компьютеры, чтобы сделать их сильно ограниченными и безопасными, то в этом случае WL будет лучшим выбором.
Доказательством этой концепции является инструмент под названием Gpdisable, созданный Марком Руссиновичем (Mark Russinovich) несколько лет назад, и который является наглядным примером, почему WL лучше BL. С помощью Gpdisable, или любого другого аналогичного инструмента, даже ограниченные пользователи могут блокировать политики групп на запущенном клиенте Windows – включая SRP – за исключением того случая, когда SRP усилен использованием Whitelisting!
Лишь правило "Default deny all applications (по умолчанию запретить все приложения)" пройдет проверку временем. К несчастью, на по-прежнему нужно антивирусное программное обеспечение для защиты от загрузки и исполнения вредоносного кода. Давайте также не забывать, что SRP "лишь" защищает локальную систему от исполнении нежелательного программного обеспечения, она не защищает от записи исполняемых файлов на жесткий диск, или от вложений с электронной почтой.
Будущее
Я надеюсь, что компания Microsoft продолжит упрощать процесс разрешения новых приложений в ближайшие годы. Было бы здорово, если бы появилась возможность импорта SRP или определенных значений HASH, необходимых для определенных приложений. Это потребует, чтобы сторонние производители предоставляли шаблон SRP "template" вместе со своими приложениями, чтобы сетевые администраторы (network administrator) могли легко их импортировать, а не создавать собственноручно новые политики. Такие шаблоны должны состоять из HASH значений для всех исполняемых файлов, а также необходимых библиотек Dynamic Link Libraries (DLL).
К несчастью, лишь очень немногие производители программного обеспечения использую технология подписи кода. Остается лишь надеяться, что производители программного обеспечения будут использовать цифровые сертификаты для подписи своего кода в ближайшем будущем.
Я хочу поделиться с вами идеей относительного того, как упросить администрирование белых списков (WL administration). Когда разговор идее о правилах для HASH, администратору необходимо открыть объект политики групп Group Policy Object (GPO) и перейти к файлам. Если этот процесс можно запланировать и записать с помощью сценариев, то все, что необходимо было бы сделать сетевым администраторам – это поместить выполняемый файл в центральную ‘разрешенную (approval)’ директорию (с правильно назначенными разрешениями NTFS), то при запуске сценария автоматически создавалось значение HASH, и это значение добавлялось к значения в разрешенной политике в соответствующем объекте GPO. Это также можно сделать для сертификатов, просто поместить сертификат в центральную папку, подождать, пока не появится процесс или сценарий. Пока что это все мечты, но будем надеяться, что кто-нибудь однажды сделает этот сон явью – может быть даже компания Microsoft…
Опасная зона
Перед тем, как мы продолжим, очень важно указать на то, что перед тем, как реализовать SRP на ваших промышленных компьютерах, вы должны ее тщательно спланировать и проверить. Это можно сделать в Active Directory (AD) изолировав одну тестовую машину или пользовательский объект в организационной единице (Organizational Unit или OU) или задав разрешение "Apply Group Policy"(применить политику группы) для объекта Group Policy Object (GPO) только для одной тестовой машины или пользовательской учетной записи. SRP можно использовать даже на отдельно стоящей машине, если вы вовсе не хотите касаться промышленной среды. Я рекомендую использовать для основного тестирования виртуальные компьютеры и компьютеры, максимально похожие на промышленные, для окончательных тестов. После тщательного тестирования SRP необходимо реализовать для опытных пользователей в группах, лучше идти небольшими шагами, чем сразу попасть в беду!