Фреймворк конфигурации и управления политиками Software Restriction Policies — II

Приняв решение выбрать Политики ограниченного использования программ (Software Restriction Policies, SRP) в качестве инструмента реализации «белых списков» (Application Whitelisting, AWL) и заручившись поддержкой всех ответственных лиц, можно перейти к аудиту используемых на предприятии приложений. Это позволит реализовать AWL с полным знанием того, какие на самом деле программы и откуда запускаются пользователями вручную или операционной системой автоматически (например, сценарии входа, Logon Scripts). Узнав, какие пути реально используются, вы сможете настроить «белые списки», не повредив функционалу компьютера. Разумеется, существует множество конфигураций, в которых рабочая станция стандартизирована и полностью готова к внедрению AWL без дополнительных временных затрат на аудит, но такое случается не столь часто, как хотелось бы.

 

ЧАСТЬ ВТОРАЯ. АУДИТ ИСПОЛЬЗУЕМЫХ ПРИЛОЖЕНИЙ.

 

Разрабатывая фреймворк управления политиками SRP, я старался создать систему аудита, позволяющую ответить на следующие вопросы:

  • Какие программы и модули используются на компьютерах компании в настоящий момент? Что потребуется добавить в политику, чтобы не вызвать отказ производственных систем при включении SRP?
  • Какие программы и модули были заблокированы уже задействованной политикой? Не было ли среди сработавших блокировок false positive?
  • Исправна ли система AWL? Нет ли в ней пробелов, позволяющих её легко обойти?
  • Какие программы запускают сотрудники техподдержки и другие пользователи с правами администратора? Не пытаются ли они обмануть или отключить систему AWL?
  • В самом ли деле пользователи работают с определёнными программами, количество лицензий на которые ограничено?

Продолжить чтение этой записи

Фреймворк конфигурации и управления политиками Software Restriction Policies — I

Некоторые вполне себе удачные ИТ-технологии не внедряются или неверно применяются потому, что у людей нет понимания, как это делать правильно, а заниматься собственными исследованиями не каждый захочет. К таким технологиям в настоящий момент относится и столь важная концепция безопасности, как «белые списки» программ (Application Whitelisting, AWL), которая в Microsoft Windows реализована в виде Политик ограничения программ (Software Restriction Policies, SRP) и AppLocker (SRPv2). Возможно, она непопулярна среди ИТ-администраторов в первую очередь из-за относительной сложности внедрения и диагностики. В этой статье я поделюсь своим опытом внедрения SRP на предприятии, попытавшись сформулировать основные положения правильной конфигурации политик в доменах Active Directory (AD).

 

Приведённый ниже опыт получен как с нескольких компаний размером порядка 1000 хостов, так и с большого количества маленьких компаний. Некоторые политики было проще реализовать на небольших объёмах, так как в них количество администраторов не превышало двух-трёх; компании побольше дали понимание того, как обычные сотрудники службы техподдержки взаимодействуют с администраторами и другими сотрудниками. Далее я буду описывать свой фреймворк внедрения SRP применительно для компании с парой-тройкой администраторов и десятком сотрудников техподдержки.

Продолжить чтение этой записи

DSS 2015 Riga

Ethical Hacker in Action @DSS2015 that took place in Riga on 22-Oct-2015:

 

 

I know that got failed a lot of times during this presentation. But I know, you gonna seal your webcam, anyway .)

Продолжить чтение этой записи

Linux жил, Linux жив, Linux будет жить!

Я думал, такие люди перевелись лет десять тому обратно. Но нет, не оскудела земля латвийская чудесами, ещё остались и порох, и ягоды!

Приведённый ниже разговор состоялся пару дней назад. Текст является переводом с латышского; точно переданы оригинальные высказывания, сохранены некоторые английские выражения. Действующие лица: менеджер по продажам (М), клиент (К), ИТ-тренер (Я). Разумеется, настоящие имена и названия компаний я вам не раскрою.

 

М:   Ув. клиент, не желаете ли пройти какие-либо из наших популярных курсов, например, Ethical Hacking and Countermeasures или что-нибудь по Windows Server 2012?

 

К:   Мы делаем всё возможное, чтобы избавиться от продуктов MS, и вот почему:
Продолжить чтение этой записи

Надёжная установка программ средствами групповых политик без SCCM

Централизованно устанавливать программы в домене Active Directory можно либо средствами групповых политик (Group Policy), либо инструментарием наподобие System Center Configuration Manager. Но SCCM — мероприятие недешёвое, поэтому весомая часть системных администраторов распространяет MSI-пакеты политиками. Однако, установка политиками обладает рядом существенных недостатков:

  1. Если инсталляция не удалась с первого раза, она никогда не будет исполнена до конца. Причины сбоя установки могут быть разными, но политика так или иначе создаст в реестре клиентской машины запись «Объект политики с таким-то номером отработал, дело можно закрыть». Идентификатор объекта вы можете найти в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt. Получается, системе безразлично, нормально ли установилась программа — она регистрирует лишь факт исполнения политики, чтобы потом к этому вопросу больше уже не возвращаться.
  2. Если так случилось, что установленную политикой программу кто-то убрал вручную, она не будет возвращена на место автоматически. Проблема известная, вот где я нашёл объяснение, когда столкнулся с ней впервые: https://social.technet.microsoft.com/Forums/windowsserver/en-US/82f1e144-78a3-4446-8aaf-18843c890cdc/force-reinstall-of-applications-deployed-by-software-gpo-after-uninstall. Причина всё та же, что в пункте номер раз.
  3. Иногда требуется задавать особые условия установки или проверки предварительных условий, которые стандартные политики не поддерживают. Например, при инсталляции Oracle VirtualBox добавить сертификат доверенного издателя:
"%~dp0\cert\VBoxCertUtil.exe" add-trusted-publisher "%~dp0\cert\oracle-vbox.cer"

Для решения этих проблем я написал скрипты распространения и убирания программ. Стандартная схема централизованного распространения может выглядеть так:

Продолжить чтение этой записи

How to find out how many PCs in your domain are SRP-compliant?

During Application Whitelisting (AWL) implementation throughout an Enterprise, it is essential to easily find an answer for questions like «how far we have come?» Running a fairly complex Active Directory (AD) structure, you can never guess for sure. Instead, you may choose to implement some objective monitoring tool, let’s call it «AWL Compliance Report«. You don’t have SCCM? Not a problem, we will make it happen using built-in Group Policy (GP) mechanism.

For example, it’s quite easy to figure out the presence (or absence) of Software Restriction Policies (SRP) by querying particular values in HKLM\Software\Policy\Microsoft\Windows\Safer\CodeIdentifiers Registry key:

Продолжить чтение этой записи

Как узнать, какой процент компьютеров подчиняется SRP?

Внедряя Software Restriction Policies (SRP) в очередной компании, регулярно требуется отвечать на вопрос «а как далеко мы продвинулись?» Работая со сравнительно разветвлённой структурой Active Directory, никогда не получится ответить «с наскоку», требуется некий механизм объективного контроля (назовём его SRP Compliance Report). У вас нет SCCM? Не беда, такой контроль можно осуществлять с помощью встроенного механизма Group Policy.

Продолжить чтение этой записи

Отслеживать

Настройте получение новых записей по электронной почте.

Присоединиться к ещё 177 подписчикам