Comments 16
Уже на стадии запуска компьютера можно контролировать запуск программного обеспечения, подписанного доверенными сертификатами. Далее, имея список своего программного обеспечения, можно запретить запуск чего-то иного, и задача обеспечения безопасности решена.
С тем маленьким исключением, что сертификаты могут быть скомпрометированы, а вменяемый разработчик может с умыслом или без выпустить опасное или вредоносное, хотя и подписанное обновление.
Да и от уязвимостей в пользовательском П.О., когда находят бинарную дыру и присылают carefully crafted .pdf это всё не спасёт от слова совсем.
Согласен, это не абсолютное средство защиты. Но добавлю несколько соображений.
- Существует оценка, согласно которой около 95% вредоносного кода не имеет подписи. Применение политики CI, таким образом, отсекает существенное количество подобных проблем.
- Сертификат можно скомпрометировать. Сертификат Microsoft скомпрометировать теоретически можно, но сложнее. CI можно настроить так, чтобы любой исполняемый компонент режима ядра запускался бы только при наличии подписи WHQL от MS. Кроме того, можно потребовать, чтобы помимо подписи драйвера, поставщик драйвера обладал сертификатом Extended Verification (EV).
- Можно настроить CI на доверие только определенным сертификатом. Разработчик может подписывать свой код чем угодно. Но запускаться будет только код, подписанный сертификатом, специально сгенерированным, например, локальным центром сертификации компании. И доступ к этому сертификату, а соответственно и к возможности подписать код, будут иметь строго определенные люди.
Инъекция кода — только первый шаг. Приложение закрыто — инжект пропал. Ему надо выжить. И здесь важна целостность кода, подписи. Был в ХР? Ок, а как там с чужими драйверами?
Это нужно, чтобы предотвратить атаки в том числе на этапе загрузки ОС. Нужно тем, кому для определенных машин требуется повышенный уровень безопасности. Кому не требуется, этим не пользуется и живет как раньше. Быстро собирать хэши придется для каждого обновления и патча каждого такого софта. В зависимости от разнообразия софта и количества машин масштаб работ может быть очень разным. С сертификатами этой проблемы нет.
Для загрузки драйвера нужны права админа, если их нет то облом
Драйвера принтера уже не устанавливаются пользователем?
В других ОС нет никаких подписей для модулей ядра, да и не нужны они юзеру, только мешаются.
Мда. Сколько у Win % рынка нынче? Среди десктоп систем, естественно.
По поводу ничего не страшно в других ОС легко лечится стандартными средствами: заводится эталонная ОС, к ней цепляется подозреваемый и далее можно сверять хэши и смотреть подозрительные вещи
При чем тут вычисление подозрительных вещей? Я про drive by и интеграцию в систему.
и все они хорошо известны.
Хорошо помогает. Особенно когда доступ к этим "хорошо известным" уже контроллируется и подменяется зловредным кодом.
С дровами в ХР было хорошо, в отличии от фошисткой висты и выше — можно было грузить не подписанные дрова свободно.
Ага, например тот самый инжект, который работает через дыру в third party ПО, про который вы упомянули выше, кинет на диск свой драйвер, загрузит его и проникнет в ядро. А там ему уже ничего не страшно — если написан верно, никакой антивирус или монитор не поможет.
Не совсем. К примеру, попробуйте инъекцию кода в Microsoft Edge. Туда даже длл-ку не подгрузишь, если она не Microsoft'ом подписана. В ХР\2к таких механизмов защиты не было.
Не соглашусь. Software Restriction Policy и ее развитие в виде AppLocker существуют далеко не первый релиз Windows. Тут Вы правы. Но они применимы только к интерактивным процессам пользовательского режима. CI можно (и нужно) применять от фактически загрузки ядра ОС до любого исполняемого кода пользовательского режима. CI-политика применяется к устройству вне зависимости от пользователя и его полномочий на машине. Второй важный момент заключается в том, что неподписанный, но нужный организации код стало проще подписать. Это позволяет прийти к ситуации, когда неподписанного кода на машине просто нет, а если таковой появляется, он не будет запущен.
Я бы сказал, предложили более глобальный подход. Тем не менее, AppLocker может быть полезен в связке с CI. Пример. CI-политика доверяет приложениям, подписанным сертификатом Microsoft. Но такая подпись есть у любого приложения из Windows Store. Если мы хотим определенным пользователям запретить запуск тех или иных приложений Windows Store, можно задействовать политики AppLocker.
Sign up to leave a comment.
Device Guard в Windows 10. Политика целостности кода