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

Политики «белых списков» помогают защитить систему от несанкционированных изменений — то есть, законсервировать её. Но полная консервация невозможна: следует ставить обновления операционной системы, иногда требуется менять программы. Как вносить санкционированные изменения?

 

ЧАСТЬ ЧЕТВЁРТАЯ. ОТКЛЮЧЕНИЕ ПОЛИТИК APPLICATION WHITELISTING

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

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

ЧАСТЬ ТРЕТЬЯ. КОНФИГУРАЦИЯ БЛОКИРУЮЩИХ ПОЛИТИК.

Какое количество политик (объектов GPO) создать, в каких ситуациях следует создавать дополнительные политики? На это влияют следующие факторы:

  • Раздельные реализации AWL: AppLocker или SRP;
  • Возможность раздельного отключения политик для определённых контейнеров АД. Например, когда требуется временно выключить AWL для одного-двух департаментов, но не выключать для всех остальных;
  • Делегирование управления. Если компания имеет представительства в различных странах (например, Латвия и Россия), и в каждой стране имеется своя IT-поддержка, то для базовой политики SRP я предпочту создать два дополнения: SRP Workstations LV и SRP Workstations RU. Затем можно делегировать управление этими дополнениями IT-отделам соответствующих стран, разрешив конфигурацию базовой политики только доменным администраторам;
  • Разбиение большого количества дополнительных правил на несколько GPO. Количество правил может зависеть в том числе и от политических установок руководства компании. Например, IT-директор может заявить «да, наши пользователи устанавливают программы дезорганизованно, но сделайте AWL так, чтобы им ничего не пришлось переделывать». Такая позиция потребует применить сотни путей и хэшей, которые будет лучше разнести по нескольким GPO согласно структуре департаментов или другому признаку;
  • Существенные различия в конфигурации AWL: например, для департамента продаж, где все сотрудники работают с ограниченными привилегиями, можно включить AWL, нацеленный только на стандартных пользователей, в то время как для компьютеров химического анализа, где все сотрудники обладают привилегиями администратора, следует задействовать фильтрацию всех пользователей, в том числе администраторов.

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

Фреймворк конфигурации и управления политиками 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"

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

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