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

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

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

Интересная заметка попалась на глаза: «Банковский троян использует групповые политики для блокировки антивирусных программ». Примерно накидаю перевод:

«Вредоносное ПО, в настоящий момент распространяющееся в Японии, использует встроенные механизмы Windows, чтобы заблокировать работу защитного программного обеспечения поражённых машин. Trend Micro сообщает, что крадущий реквизиты онлайн-доступа к некоторым японским банкам шпионский модуль BKDR_VAWTRAK использует компонент Windows под названием Политики Ограничения Программ (Software Restriction Policies, SRP), чтобы заблокировать на заражённых системах запуск широкого ряда защитных программ, в том числе антивирусы Microsoft, Symantec, Intel — всего 53 различных программы.

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