СРАВНЕНИЕ ЭФФЕКТИВНОСТИ СРЕДСТВ ЗАЩИТЫ ИНФОРМАЦИИ ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА - Форум по вопросам информационной безопасности

to oko
Вы совершенно правы в отношении векторов атак и "правильных местах применения".
Но из этой мысли следует, что подобные средства должны использоваться исключительно в ГТ? Но это ж не так, они используются и в иных приложениях, с иными векторами атак.
Вспомним, например, вирусы шифровальщики. Их вектор атак предполагал получение системных прав путем эксплуатации уязвимости в яде или SMB (не буду детализировать). Запустив простой ассемблерный код с таким правами, в качестве полезной нагрузки - проэксплуатировав уязвимость, следуя проведенному исследованию, можно легко снять эти средства, в том числе, выгрузить драйверы - убрать замкнутость программной среды. Затем загрузить вредонос, и все.
Действительно, при проведении исследования необходимо определиться с моделью угроз, которая следует из области использования средств, соответственно с их назначением и решаемыми задачами.

Сугубо imho, ни одно даже крайне навороченное навесное СЗИ (АВЗ, СОВ и т.д.), работающее на уровне ОС, не сможет полноценно защитить от эксплойтов для данной ОС. Да и от эксплойтов в ППО тоже, если говорить честно. Тем более 0-day. Замкнутый контур как ни создавай, а информация все равно имеет свойство "просачиваться", ага...
И да, еще нюанс: проводить тестирование на стенде в среде виртуализации (любой) для СЗИ, исторически развивавшихся в области "железных" систем, - как бы моветон. Ничего против не имею, но похоже на весьма поверхностный взгляд. Уровень абстракций (и переопределений, ага), вносимых в тестовую среду компонентами той же самой VMWare явно не учтен. А там, знаете ли, имеются свои нюансы, даже если гостевая ОС полностью имитирует "реальные условия"...

ЗЫ Перечитал документ еще раз. Явственный прикол: большая часть политик DL не просто выставлена в дефолт, а не выставлена никак. Сам не проверял, но думаю, что это любопытный баг DL (вот о чем стоило написать, ага) - по умолчанию "разрешено", а не "запрещено", если не указано явно. Тогда понятно, как обошли механизм защиты низкоуровневого доступа к диску, в частности. Ну и остальные мероприятия (начиная с "скачаем" и заканчивая "запустим", ага)...
Впрочем, после выпуска обновленных версий DL из-за BDU:2016-01520, дырявость только повысилась, не удивлен. Сдается мне, вся неплохо проработанная ранее система защиты держалась как раз на той уязвимости. Устранили ее - поломали все хорошее, что было, ага...

to oko
Сугубо imho, ни одно даже крайне навороченное навесное СЗИ (АВЗ, СОВ и т.д.), работающее на уровне ОС, не сможет полноценно защитить от эксплойтов для данной ОС. Да и от эксплойтов в ППО тоже, если говорить честно. Тем более 0-day. Замкнутый контур как ни создавай, а информация все равно имеет свойство "просачиваться", ага…
Здесь я не согласен, пока не определено понятие "полноценно", но это совсем иная тема.

Относительно любого подобного обновления - это "костыли", вносимые в отлаженную систему, естественно, что ничего хорошего - внесение новых "дыр".

А вот по поводу обсуждаемой темы. В исследовании не рассмотрено ряд важных моментов - контроль доступа к альтернативным потокам, при использовании символических ссылок, к таблице MFT и к иным объектам, к скрытым объектам, например, системным - Admin$, к загрузчику ОС, к не отмапленным на букву диска объектам, к иным атрибутам, не только ::DAT и т.д., и т.п. Все эти объекты активно используются при атаках.
На мой взгляд, чтобы не случалось подобных казусов, как с этим исследованием, разработчик сам должен проводить подобное исследование с соответствующими настройками (при этом и дыры закроет), и выкладывать результаты в открытый доступ. Эти результаты уже можно обсуждать. Тогда заказчик будет реально понимать, что покупает, а не исходить из "криков", что наша система лучшая.