Антивирусная защита реализацией разграничительной политики доступа к ресурсам для субъекта «Процесс» - Выбор домашних средств защиты - Форумы Anti-Malware.ru Перейти к содержанию
Сергей Ильин

Антивирусная защита реализацией разграничительной политики доступа к ресурсам для субъекта «Процесс»

Recommended Posts

Сергей Ильин

Выношу на ваш суд предложенную мне для публикации статью д.т.н., проф. А.Ю.Щеглова.

ЗАО «НПП «Информационные технологии в бизнесе»

www.npp-itb.spb.ru

**********************************************

Антивирусная защита реализацией разграничительной политики доступа к ресурсам для субъекта «Процесс»

Краткое содержание:

- Так что же такое «вирус» в общем случае, что же несет в себе угрозу вирусной атаки?

- Защита от сторонних процессов.

- Защита от атак со стороны санкционированных процессов.

- Единые разграничения к системным ресурсам для процессов офисных приложений

- Комплексное решение задачи антивирусной защиты.

Введение

Большинство современных антивирусных средств защиты основано на реализации механизмов контроля (контроль сигнатур и поведенческие анализаторы). Вместе с тем, известно, что основу эффективной защиты информации составляет реализация разграничительной политики доступа к ресурсам, механизмы контроля (например, контроля целостности) здесь вторичны, как правило, используются в том случае, когда невозможно корректно решить задачу механизмами разграничения прав доступа к ресурсам. И это вполне объяснимо, механизмы контроля не только очень ресурсоемки, но и принципиально не могут эффективно решить задачу защиты, т.к. в общем случае могут обнаруживать лишь известные вирусы (вирусы, для которых разработчиками определена сигнатура) – о какой же защите при этом можно говорить. Современные условия практического использования подобных средств характеризуются тем, что базы сигнатур уже давно «перевалили» за сотню тысяч. Если контроль только системного диска может составлять несколько часов, может ли в принципе использоваться такое средство на практике - как часто мы будем использовать такое средство? Здесь уже нужно вести разговор не об эффективности, а о применимости. Что же мы имеем - нет никакой гарантии выявить вновь созданный вирус, да и к тому же, серьезные ограничения по практическому применению - как использовать – редко бессмысленно, часто невозможно. Наверное, давно назрела необходимость в использовании иных подходов к антивирусной защите.

.........

Статья большая (11 стр.), поэтому выкладывать ее текстом не буду. Кому интересно, могут скачать атач.

АЗащРД.doc

АЗащРД.doc

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович

И тут этот "профессор". Никак не может понять, чьто его продукт плохо покупается не потому, что мало саморекламы, а потому, что слишком сложен в использовании. Ну почему обычный пользователь должен знать, что есть такая штука- реестр, и что значит HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER, да ещё и настраивать самостоятельно эти параметры?

Плюс- защита от внедрения в процессы обходится стороной. В общем, недопесочница у человека получилась, да ещё и кривая в реализации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Mona Sax

Щеглов шикарный теоретик. но "почитать для общего развития", не более.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Олег777

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

Я вот столкнулся с проблемой очисти некоторых веток в HKEY_LOCAL_MACHINE и на собственном опыте могу сказать, что теории это хорошо, а на практике может и не пригодиться...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов

Вы вплотную подошли к серьезнейшей проблеме построения и использования средств защиты.

Простота или эффективность? Именно "ИЛИ"! Защита информации очень сложная задача, простейшими способами ее не решить.

Существуют две области применения средств защиты - при личном и корпоративном (на предприятии) использовании вычислительных средств. Разные задачи, разные требования к средству защиты.

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

Корпоративные приложения - иное дело, если администратор боится "трогать реестр", его нужно "гнать в шею". В этих приложениях есть что защищать, и разговоры о сложности средства защиты неуместны. Здесь уже нужно говорить об эффективности защиты и о требуемой квалификации администратора.

На практике существует необходимость в обоих типах средств, но не нужно путать решаемые ими задачи и требования к средствам!

Технология, рассматривая в статье, ориентирована на корпоративные приложения. Здесь следует говорить об эффективности защиты, а уровень сложности настройки рассмотренного средства - это уровень лабораторной работы 5 курса профильной специальности. К тому же рассматриваемое средство защиты снабжено соответствующим механизмом инструментального аудита (поставьте на аудит все обращения какого-либо приложения к системному диску, не задавая разграничений доступа, за пару дней получите всю необходимую и нформацию).

P.S. Относительно же восстребованности наших средств и стабильности их функционирования, это другой вопрос, и не очень понятно, зачем обсуждать данный вопрос при рассмотрении технологии. Недоброжелателям - у нас все хорошо. В части модификации процессов, об этом сказано в статье.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович
Простота или эффективность?

Разумный баланс между ними. Правильная архитектура, заложенная в фундамент средства защиты. И никаких "или".

Технология, рассматривая в статье, ориентирована на корпоративные приложения.

Гы, теоретически оно красиво, а вот на практике- не работает. У IT отделов и так куча работы, а вешать ещё и настройку whitelising-защиты для каждого компа в отдельности...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов

Вот она истинная причина. Но она не имеет никакого отношения к технике!

По нашему опыту внедрения стредств защиты, там, где задачи ЗИ, как дополнительные, возложены на ИТ подразделения, толка не будет.

Заканчивается все разговорами о том, что за ту же зарплату еще лишняя "головная боль", еще что-то настраивать, обучаться....., в итоге получаем то же желанием воспользоваться одной "большой кнопкой", но уже по и ной причине. Как следствие, "мечта" заняться безопасностью, ничего не предпринимая, не тратя времени... Более того, реализация эффективной защиты может буквально отрицательно повлиять и на решение основных задач, за которые платится заработная плата, задач, решаемых ИТ подразделениями на предприятии.

Если задача ЗИ выделена в самостоятельную задачу, для ее решения выделены средства, приняты на работу сотрудники - ситуация кардинально иная. Для этих сотрудников задача защиты основная, другое отношение, желание решать задачу профессионально. Однако, сразу же возникают конфликты между ИТ подразделением и подразделением ЗИ, и чем лучше решается задача ЗИ , тем более недовольны ИТ специалисты, для них это лишние проблемы за ту же зарплату.

Да и не их это личная информация, "зачем напрягаться"?

Вот основная прична. Такова жизнь.

Однако, давайте не будем, говоря о технологиях, путать их с конкретными организационными проблемами на конкретном предприятии.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович
Вот она истинная причина. Но она не имеет никакого отношения к технике!

Да, она имеет отношение к бизнесу предприятия. Если продукт не нуждается в выделении отдельных людей для внедрения и поддержки- то продукт, который требует такого специального подхода, не выдерживает конкуренции и выдавливается с рынка. Логика проста как два пальца.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов
Да, она имеет отношение к бизнесу предприятия. Если продукт не нуждается в выделении отдельных людей для внедрения и поддержки- то продукт, который требует такого специального подхода, не выдерживает конкуренции и выдавливается с рынка. Логика проста как два пальца.

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

А для решения этой задачи, при желании заниматься вопросами ЗИ, уже потребуется какой-либо инструментарий (продукт), а его выбор будет определяться квалификацией и мерой ответственности лиц, занимающихся вопросами ЗИ. Действительно, логика проста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович

Не везде есть необходимые ресурсы для выделения подразделения ЗИ в отдельную функциональную единицу. Да, когда оно есть + есть выделенный на эти задачи бюджет, то задача упрощается, я совершенно согласен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
nremezov

Эфективного применения не вижу в сложившихся реалиях.

Для гос.организаций - у Панциря 1Г, низкая квалификация ИТ\ИБ персонала.

Для коммерческих - слишком много ресурсов уйдёт на тестирование и поддержку. Думаю, что прикинув потери от срабатывания вируса (реальную утечку или уничтожение информации) против стоимости обслуживания такого комплекса в год - менеджмент покрутит пальцем у виска и купит стандартные антивирусы

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович

Угу, песочницы намного удобнее при внедрении и эксплуатации. А whitelisting слишком сложен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
Однако, давайте не будем, говоря о технологиях, путать их с конкретными организационными проблемами на конкретном предприятии.

При любой организации будет конфликты между отделами ИТ и информационной безопасности (ИБ), так как имеет место борьба за сферу влияния. Потом даже если конфликты и удалось волевым решение руководства прекратить, то это не снимает другую задачу - оптимизацию затраты ресурсов на оперативную деятельность ИБ.

Для коммерческих - слишком много ресурсов уйдёт на тестирование и поддержку. Думаю, что прикинув потери от срабатывания вируса (реальную утечку или уничтожение информации) против стоимости обслуживания такого комплекса в год - менеджмент покрутит пальцем у виска и купит стандартные антивирусы

Согласен. Для бизнеса важны такие вещи как TCO или ROI, т.е. стоимость владения и возврат инвестиций. Никакой здравомыслящий капиталист не будет стремиться построить у себя 100% защиту, не ориентируясь на стоимость вопроса. В итоге все сводится к простому соотношению: Риски/Стоимость. Кому-то подойдет вариант с большими рисками, но меньшие деньги, кому-то с деньгами наоборот. А вот ставить дорогие и сложные продукты под силу только гос. органам, там обычно ресурсы не считают ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов

Коллеги, хочу внести некоторую ясность. Зачем я систематически печатаю статьи? Кто-то меня обвиняет в рекламе Панциря. Это не так, средства рекламируются иным способом (прежде всего там, где их потенциально могут купить). В частности, Илья высказал мнение, что Панцирь плохо продается, поэтому "я здесь". Опять не так. Вопрос вот в чем. У Панциря вполне определенный сегмент рынка, и здесь все хорошо. Панцирь - это не антивирусное средство - это сложное профессиональное решение: защита от инсайдерских атак, от сетевых атак и т.д. и т.п. Там одних драйверов около 20. Сложность, это вопрос, однако, Панцирь настраивают студенты при выполнении лабораторных работ, и в тех приложениях, где он используется, сложности это не вызывает. Однако, меня интересуют и иные сегмента рынка, где, как вы, единодушно, высказали мнение, Панцирь сложен (о стоимости речи нет, за сколько хотим, за столько и продаем). Вот я и хочу понять, как обеспечить компромисс эффективность/сложность, о котором сказал Илья. У нас есть ряд новых разработок (в частности, средство построения корпоративной VPN, здесь, мне кажется, подобный компромисс найден). Одна из которых требует наполнения функциональном (есть собственно костяк, необходимо определиться с тем, какие механизмы защиты следует внедрить для какого сегмента рынка). Вот это я для себя и пытаюсь понять, участвуя во всевозможных дискуссиях. Вот и по этой статье, мы опять начали обсуждать Панцирь - не это мне интересно, я рассмотрел технологию (Панцирь приведен лишь в качестве примеров реализации интерфейсов - это пресловутая простота администрирования, о чем мы также задумываемся).

Скажу честно, для меня это большой вопрос, как обеспечить компромисс. Проиллюстрирую на простом примере. Модным стало разграничивать права доступа к устройствам, сразу появились соответствующие средства защиты. Но в решении этой задачи есть одна кардинальная проблема, подавляющая часть устройств взаимодействует с пользователем через драйвер. В результате, перехватывая обращение к устройству, мы видим пользователя System, процесс System. Корректно решить задачу нельзя. Как определить имя пользователя, обратившегося к устройству? Можно "закрыть глаза" на подобные мелочи и взять имя зарегистрированного пользователя (где-то его взять надо), что получаем - при многопользовательском режиме (например, запуск приложения по runas) корректные разграничения невозможны - несколько пользователей зарегистрированы, какой обратился к ресурсу? Вот что делать разработчику - "гнать явную липу, т.к. пользователь всеравно мало, что поймет", при этом средство будет простым, или усложнять, но при этом средство потеряет свою "привлекательность" у потенциального потребителя. А усложнения, они, как снежный ком, чтобы корректно решить одну задачу, потребуется решить еще пяток сопутствующих.

Речь же не о каких-то там рисках (это совсем иной вопрос). Речь о том, что эффективное средство защиты (если разработчик не хочет позориться, и кроме коммерческого успеха заботится о своем "имени") не может быть простым, но не может быть оно и сложным в определенных сегментах рынка. Это объективно существующее противоречие, как быть, чем т в какой мере "жертвовать", достигая компромисса? Сегодня у меня нет ответа на этот вопрос, вот я его для себя и ищу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Werasy

Работа по "белым спискам"?В открытой системе невозможна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов

Можно, если не все, то очень многое, смотря, как к этому относиться. Вопрос же не о конкретной реализации, лишь пример проблемы. Иной пример. в Панцире есть механизм контроля сервисов олицетворения, эти возможности разграничиваются для процессов. Разрешите олицетворение процессу winlogon олицетворение Sestem - User1, и войти в систему станет возможным только под User1, какую бы учетную запись, где и как Вы бы не завели. Задайте соответствующие правила разрешенных олицетворений для процесса печати - разграничите доступ к локальным и сетевым принтерам и т.д. и т.п. Масса возможностей. Сложно? Используя аудит, за пару дней поймете, что происходит в системе с сервисами олицетворения. Да и атаки на расширение привилегий для Вас станут не столь критичны.

По поводу же антивирусной защиты. Если мы говорим о сигнатурном анализаторе, сам подобный принцип имеет право на жизнь (при попытке реализации эффективной защиты)? Что важно, результат или процесс? Разработчики, не унывая, пополняют "тонные" списки выявленных сигнатур, пользователи часами что-то проверяют, а результат один, заложенный в самом принципе механизма контроля - всегда присутствуют невыявленный на конкретный момент времени сигнатуры вирусов, т.е., де факто, антивирусная защита отсутствует. Но все при деле - обеспечивуают защиту.

Если речь о поведенческом анализаторе, то ответьте на вопрос, а кто определит (задаст) разрешенное поведение процесса. Задавать подобный вопрос пользователю? При личном использовании компьютера глупо (посмотрите, что с подобной опцией делает пользователь в Viste - отключает), для корпоративного пользователя - недопустимо - именно санкционированный пользователь несет в себе максимальную угрозу (инсайдер). Если данные функции "берет на себя" разработчик, неминуемы конфликтные ситуации, "по умолчанию все корректно не задать".

Нужны новые подходы? Конечно. Один из них рассмотрен в статье. Но в "шок" читателя повергла сложность администрирования - потратить пару дней на анализ и внести пяток строчек в интерфейс. Да, за то время, что антивирус ищет что-то по своей базе сигнатур, десять раз можно осуществить подобную настройку. А ведь антивирусная защита - это одна из наиболее простых в решении задач защиты информации в корпоративных приложениях, на мой взгляд. Тогда о какой безопасности мы говорим?!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Werasy

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

При этом ещё не решён вопрос для корпоративных об уходе обрабатываемой информации виртуальной зоны.Списки для приложений с виртуальной зоной есть достаточны только для классического пользователя,где не домашние,а только инет является причиной.Насчёт людей этим никогда не решить.Всех поделить по спискам?Будет ли кто в белых?Это не как причина для вседозволенности.

Задайте соответствующие правила...

Примерно это (подробности знает Илья,к примеру) уже решено через предпосылку,что только приходящее извне в "систему" может содержать "вируса",всё же,что "Админ" осознанно поставил (пару кнопок надо нажать для этого при этом),должно соответственно работать,иначе бы не поставил.Можно для теории исходить из того,что "система" защищена и извне неизменяема,так как виртуальная зона перенимает эти изменения и ошибочные действия пользователя не приводят к "заражению",оставляя возможность чистки следов виртуальной зоны.Пока "система" остаётся некоррумпированной,можно доверять её обработке,и только внутри её.Угроза "системе" и через неё всему,над чем она стоит (обрабатываемые виртуальной зоны?равноправные системы,имеющие контакт напрямую,без виртуалки?...) - стоящее над ней.Так как изменения в системе неизбежны,решающе есть,что есть их инициатор и исполнитель.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
alexgr

вся полемика мне стала напоминать полемику на тему "о безполезности информационной безопасности". Если сигнатурные и несигнатурные методы бесполезны, списки ничего не гарантируют - топ-менеджмент может быть "доверенным инсайдером", веб - контент ненадежен, живем в опасном окружении - может, не стоит всем этим заниматься? всегда появится новая технология проникновения или взлома, всегда будет человеческий фактор и кривые ручки админа, который студент - недоучка...... Застрелиться, что ли? :))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов
вся полемика мне стала напоминать полемику на тему "о безполезности информационной безопасности". Если сигнатурные и несигнатурные методы бесполезны, списки ничего не гарантируют - топ-менеджмент может быть "доверенным инсайдером", веб - контент ненадежен, живем в опасном окружении - может, не стоит всем этим заниматься? всегда появится новая технология проникновения или взлома, всегда будет человеческий фактор и кривые ручки админа, который студент - недоучка...... Застрелиться, что ли? :))

К сожалению, Вы абсолютно правы, и тема: "о бесполезности информационной безопасности" назрела уже давно. Однако, стреляться - это удел слабых.

Когда мне осточертели споры на тему "Какая ОС безопаснее", то я не поленился, и сделал простейшую математическую оценку уровня безопасности современных универсальных ОС, со всей их "кучей" бесполезных механизмов защиты. Идея подобного исследования весьма проста, как в теории надежности. Есть поток отказов, поток восстановления после отказов (проще, продолжительность ремонта, в течение которого система неработоспособна), можно расчитать вероятность того, что в любой момент времени система находится в работоспособном состоянии. В смысле безопасности, ничего не напоминает - есть поток обнаружения уязвимостей (для оценки его интенсивности информации навалом), есть среднее время исправления уязвимости (это интенсивность выхода патчей), можно рассчитать вероятность того, что в любой момент времени система находится в безопасном состоянии.

Если интересно, могу предложить Вам познакомиться с результатами исследований в моей статье "Исследование на тему: какая ОС безопаснее?" (в разделе статьи на сайте www.securitylab.ru). Посмотрите, схватитесь "за голову". Аналогичные исследования можно провести и для антивирусов, думаю, когда все это "переведете в цифры", тоже ужаснетесь!

Относительно того, стоит ли этим заниматься? А куда деваться? Вы немного следите за тем,что происходит в мире? Хорошо происходящее представлено, например, на сайте www.itsec.ru. Уже давно вопросы обороноспособности любой страны тесно связывают с вопросами информационной безопасности. А Вы о "кривых ручках", о недоучках.... Просто, у нас складывается весьма странная ситуация, все понимают, что вопросами безопасности необходимо заниматься и заниматься профессионально (иначе, как Вы отметили, нужно "стреляться", большинство же предпочитают оставаться "страусами", только страусы эти "стоят на асфальте"), но что для этого реально делается? Вот и на этом форуме, меня называют теоретиком, не более того, интересно почитать, но кто же этим всем будет заниматься? А результат - посмотрите, как пестрят новостные ленты информациями о хищениях, взломах и т.д. и т.д. А в это время, ни на что не смотря, многие серьезно обсуждают эффективность сигнатурных анализаторов различных производителей....... :lol:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов

При этом ещё не решён вопрос для корпоративных об уходе обрабатываемой информации виртуальной зоны.

И т.д.

У Вас масса вопросов, и это понятно. Невозможно в рамках одной статьи (кстати говоря, моя статья здесь так и не опубликована), а уж тем более, в форуме, ответить на все эти вопросы. Если Вас интересует мое мнение по многим из озвученных Вами вопросов, приглашаю посетить наш сайт www.npp-itb.spb.ru раздел "Публикации". Там размещено пару десятков статей, отражающих мое мнение по многим вопросам защиты информации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
alexgr

при прочих равных условиях считаю, что в данном случае мы имеем весьма философскую задачу снаряда и брони. Сам занимаюсь этим сравнительно давно, веду почасовку в ВУЗе, но полагаю, что решения должны начинаться в области научного поиска, даже хотя бы из вывода критерия эффективности - максимизации выбранного функционала защищенности - для своей информационной системы. И использовать процессную модель безопасности, а не статическую...

За возможность знакомиться с публикациями - спасибо за сслки, обязательно почитаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
ASMax

Теоретизирование конечно весьма занимательное, но было бы куда полезнее дать общественности пощупать сие чудо, дабы проверить возможно ли невозможное. ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов
при прочих равных условиях считаю, что в данном случае мы имеем весьма философскую задачу снаряда и брони. Сам занимаюсь этим сравнительно давно, веду почасовку в ВУЗе, но полагаю, что решения должны начинаться в области научного поиска, даже хотя бы из вывода критерия эффективности - максимизации выбранного функционала защищенности - для своей информационной системы. И использовать процессную модель безопасности, а не статическую...

За возможность знакомиться с публикациями - спасибо за сслки, обязательно почитаю.

Не могу возразить ни по одному пункту. Кстати, любопытно, как Вы оцените уровень выпускника ВУЗа за последние лет 5 (у меня стаж работы в ВУЗе более 15 лет и сложилось вполне определенное мнение на этот счет, на мой взгляд, имеет мето "процессная модель" в Вашей терминологии)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А.Щеглов
Теоретизирование конечно весьма занимательное, но было бы куда полезнее дать общественности пощупать сие чудо, дабы проверить возможно ли невозможное. ;)

Я стараюсь не опубликовывать чисто теоретические выкладки, как правило, о чем-либо пишу лишь после апробации теоретических посылов. Все эти решения реализованы в одном из наших средств защиты, на которое есть ссылка в статье, и которое уже внедряется более двух лет. Так что "пощупать сие чудо" многим уже удалось - на сегодняшний день более сотни внедрений в корпоративном секторе (некоторые внедрения на 500 и более компьютеров в сети). Не в порядке рекламы - я лишь отвечаю на Ваш вопрос. Мы работаем с корпоративным сектором и придерживаемся определенного правила предоставления демо-версии. Вся информация об этом есть на нашем сайте. Можете и Вы "пощупать".

В чем причина некоторых ограничений на предоставление демо-версии? Все очень просто. После ее скачивания неизбежны вопросы (и уверяю Вас, далеко не всегда эти вопросы адекватны). Когда в техподдержку поступает несколько десятков вопросов в день, многие из которых - почему не запускается интерфейс, на что следует ответить - у Вас не хватает прав, зайдите с правами администратора, то, как Вы сами понимаете, это временные затраты. Не отвечать же на подобные вопросы нельзя, в противном случае, может пострадать наша репутация и репутация средства.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
alexgr
Не могу возразить ни по одному пункту. Кстати, любопытно, как Вы оцените уровень выпускника ВУЗа за последние лет 5 (у меня стаж работы в ВУЗе более 15 лет и сложилось вполне определенное мнение на этот счет, на мой взгляд, имеет мето "процессная модель" в Вашей терминологии)?

К сожалению, был в командировке. Не могу похвастать таким стажем, но в ИБ работаю давно. Убивает путаница между безопасностью ИТ и ИБ. Люди все больше проводят знак равенства.... Со студентами еще хуже - с трудом находишь в аудитории заинтересованные глаза - и это на профильных факультетах. Студент все знает, он одинаково хорошо разбирается в боксе, футболе и ИБ. Когда просишь представить матрицу рисков - делает страшные глаза и называет это ненужной теорией, а уж про мотивацию нарушителя промолчу... :D

Процессная модель - это расширение ролевого подхода к доступу, только в динамике - что нужно для обработки в этой роли, какие права и полномочия по доступу (классическая RBAC), куда передается, уровень защиты при передаче/выкладке, возможность коммпроментирования на каждом шагу обработки каждым участником процесса. Статика губит все, нужна динамика. ИМХО. Какие привелегии нужны контролерам за процессом и как эти привилегии ограничивать? Кто контролирует привелигированных? Вот это и есть процесс. То есть процесс подготовки например договора рассматривается как процесс - многоступенчатый, с возможностью утечек на каждом этапе.

Как по мне - без теории и функционала построить нормальную систему ИБ нельзя. То, что ставят - это называют интуитивным снижением рисков. Их же никто как правило не считал :D , соответственно, никаких оптимизаций и провести нельзя. То есть подход просто - берем и ставим, потому что нравится, модно или сосед сказал. А уровень блокировки угроз какой? Да хрен его знает, но продукт хороший <_< Мрак!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
      ESET Online Scanner 4.0.1  (Windows 10/11, 64-разрядная)
                                                                                  ●
              Руководство пользователя ESET Online Scanner 4  (PDF-файл)
    • Ego Dekker
      ESET Cyber Security был обновлён до версии 9.0.6700.
    • AM_Bot
      Теория звучит убедительно, но работает ли она на практике? Мы внимательно изучили Phishman 2.35 и решили не останавливаться на описании её возможностей. Вместо этого протестировали платформу на собственных сотрудниках и удивились, к каким результатам это привело.      1. Введение2. Методология тестирования Phishman 2.353. Первичное тестирование3.1. Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылки3.2. Тестирование доставки и отражения результатов в статистике3.3. Результаты атак4. Обучение4.1. Формирование учебной группы4.2. Составление образовательной программы по повышению киберкультуры4.3. Процесс обучения и его результаты5. Повторное тестирование5.1. Результаты атак6. Подведение итогов6.1. Сложности, с которыми мы столкнулись7. Впечатления от проекта команды «АМ Медиа»7.1. Реакция сотрудников7.2. Реакция организаторов7.3. Сотрудничество с вендором8. ВыводыВведениеPhishman 2.35 — это система повышения осведомлённости пользователей в сфере ИБ. Она помогает развивать киберкультуру и формировать у сотрудников устойчивые навыки безопасной работы с информацией, цифровыми сервисами и корпоративными ресурсами. В процессе обучения сотрудники учатся распознавать актуальные сценарии атак, закрепляют правильные модели поведения и в результате реже становятся причиной инцидентов, связанных с человеческим фактором.В первой части обзора Phishman 2.35 мы рассмотрели платформу с точки зрения её возможностей. Теперь пришло время проверить, как всё это работает на практике. За время проекта мы не только оценили эффективность различных сценариев, но и столкнулись с рядом особенностей, которые невозможно увидеть в документации. Одни из них влияли на ход тестирования, другие оказались скорее организационными нюансами, о которых стоит знать заранее.Методология тестирования Phishman 2.35В процессе работы с киберкультурой «АМ Медиа» мы будем использовать следующие метрики:Обученность. Отражает уровень знаний сотрудников в области ИБ. Показатель растёт, когда сотрудники осваивают темы: реагирование на инциденты, защита от социальной инженерии и другие критически важные компетенции.Иммунность. Показывает, как сотрудники применяют знания на практике. Она повышается, когда демонстрируется способность распознавать угрозы и правильно на них реагировать в реальных сценариях.Киберосознанность — итоговая метрика. Объединяет знания и практические навыки, показывая, насколько сотрудники в целом устойчивы к киберугрозам и действуют корректно при их возникновении.Прежде чем оценивать эффективность работы системы, необходимо определить отправную точку. Первичное тестирование определит, на какие сценарии реагирует каждый сотрудник, где чаще всего допускаются ошибки и какие темы требуют дополнительного развития. На основе этих данных формируется индивидуальная программа обучения: сотрудники проходят персонализированные курсы, выполняют практические задания и тесты, которые помогают устранить выявленные пробелы и закрепить необходимые навыки. В процессе обучения повышается уровень обученности, а закрепление знаний через практику влияет на показатель иммунности. После завершения обучения мы проведём повторное тестирование, которое покажет, какие изменения произошли по всем ключевым метрикам.Заключительный этап — сравнение результатов первичного и повторного тестирования. Здесь станет понятно, насколько вырос уровень киберкультуры сотрудников: изменилось ли их отношение к вопросам ИБ, стали ли они увереннее распознавать угрозы и чаще принимать безопасные решения в ситуациях, где раньше могли допустить ошибку.В качестве основного канала для рассылки фишинга выбрали электронную почту. Причина очевидна: именно она остаётся основным способом первичного контакта злоумышленников с сотрудниками и доставки фишинговых сценариев. По имеющимся оценкам, более 90 % успешных кибератак начинаются с электронного письма, поэтому исключать этот канал из подобных проверок было бы некорректно.Первичное тестированиеРеальные фишинговые атаки почти никогда не строятся по универсальному шаблону: злоумышленники адаптируют содержание писем под роль человека в компании, его рабочие процессы и типовые задачи. Поэтому при выборе целевой аудитории мы разделили сотрудников по функциям и уровню доступа к корпоративным данным, а сам проект разбили на 3 последовательные волны с разным уровнем сложности.Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылкиПосле определения целевой аудитории был проведён анализ структуры подразделений и рабочих процессов сотрудников. На этом этапе изучались:должностные обязанности;распределение зон ответственности;характер внутреннего взаимодействия между отделами;используемые адреса электронной почты;формат повседневной служебной переписки.Это позволило понять, какие сценарии коммуникации являются для сотрудников привычными и не вызывают подозрений.На основе собранных данных были подготовлены сценарии фишинговых сообщений. При разработке содержимого учитывались тематика рабочих задач, стиль корпоративного общения, оформление внутренних уведомлений и типовые причины отправки писем внутри организации. Основная задача заключалась в том, чтобы письмо воспринималось как стандартное рабочее сообщение, соответствующее реальным бизнес-процессам заказчика.Волна 1. Первая волна была построена как массовый фишинг. Сценарий — сверка графика отпусков. Для атаки создавали и настраивали пользовательский шаблон. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки.На этом этапе проверялась базовая реакция сотрудников на привычные рабочие триггеры и способность распознавать типовые признаки фишинга без привязки к конкретному подразделению. Рисунок 1. Шаблон для первой волны Рисунок 2. Вид фишингового письма из первой волны в почте Волна 2. Для каждого отдела были подготовлены письма, основанные на реальных рабочих процессах, характерных запросах и ситуациях, с которыми сотрудники регулярно сталкиваются в своей деятельности. Для атаки создали и настроили пользовательский шаблон, где-то добавили немного визуального оформления. Время начала рассылки — по запланированному времени. Рисунок 3. Пример шаблона из второй волны для отдела «Продажи» Рисунок 4. Вид фишингового письма из второй волны для отдела «Продажи» Волна 3. Здесь моделировались уже более сложные сценарии целевого фишинга (spear phishing). В письмах использовались специальные формулировки, элементы корпоративного брендирования. На этом этапе проверялась не только внимательность сотрудников, но и способность замечать менее очевидные признаки атаки в условиях, максимально приближённых к реальной целевой компрометации.За основу брали системный брендированный шаблон «Яндекс ID», добавили фишинговую форму и скорректировали немного её содержание. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 5. Пример шаблона из третьей волны Рисунок 6. Вид фишингового письма из третьей волны При переходе по ссылке открывалась фишинговая страница. Рисунок 7. Фишинговая страница Тестирование доставки и отражения результатов в статистикеДалее была подготовлена инфраструктура рассылки. После её настройки проводилось тестирование доставки сообщений. Проверялась доставка писем во входящие сообщения почтовых клиентов, анализировалась реакция антиспам-механизмов в почте, а также контролировалась корректность работы механизмов отслеживания действий пользователей. Рисунок 8. Результаты тестирования доставки и отображения сообщений в почте Тестирование прошло успешно.После завершения проверки была сформирована последовательность отправки сообщений по заранее определённым волнам. Такой подход позволил распределить нагрузку, контролировать ход тестирования и отслеживать реакцию сотрудников на различных этапах проведения проверки. Рисунок 9. Активные мероприятия Результаты атакБыли получены следующие результаты:Иммунность — 81 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 71 %.Уровень риска — 8, средний. Устойчивость формируется, но есть ещё риски. Рисунок 10. Общая информация после проведения первичного тестирования Самый низкий уровень иммунности — около 50 %, после первых двух волн атак. Рисунок 11. График иммунности во время первичного тестирования Далее — сформировали в системе отчёт по скомпрометированности сотрудников, на основании которого выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Рисунок 12. Отчёт по скомпрометированности всех сотрудников в Phishman 2.35 Таблица 1. Результаты первичного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот04,76 %4,76 %Продажи04,76 %9,52 %Продюсеры 0023,8 %Редакция0019,04 %Руководитель000 ОбучениеПервичное тестирование завершено, поэтому следующим этапом стало определение группы риска и формирование программы обучения.Формирование учебной группыНа этапе отбора рассматривались два варианта формирования учебной группы. Первый предполагал использование показателя иммунности сотрудников. Второй вариант заключался в создании правила, автоматически формирующего список сотрудников, которые были скомпрометированы в ходе проведённых проверок. Этот подход позволял сразу получить выборку пользователей, продемонстрировавших наибольшую подверженность атакам, без ожидания обновления показателей.Был выбран второй вариант. На основании созданного правила была сформирована группа для обучения: в неё вошли люди, которые были скомпрометированы в ходе первичного тестирования. Рисунок 13. Создание правила для выявления группы риска Рисунок 14. Отчёт по отработанному правилу для выявления группы риска Отдельно была сформирована группа сотрудников, успешно распознавших фишинговую атаку, для участия в обучении, направленном на поддержание киберкультуры.Составление образовательной программы по повышению киберкультурыПопавшиеся сотрудники были включены в отдельную учебную группу, для которой сформировали персональную образовательную траекторию. В неё вошли 3 микрокурса по фишингу и 1 курс по информационной безопасности. Содержание траектории было направлено на повышение устойчивости к методам социальной инженерии и снижение вероятности компрометации учётных данных. Рисунок 15. Заполнение параметров обучения сотрудников Рисунок 16. Составление учебной программы Отдельно была запущена программа обучения для сотрудников, которые не попали в выборку по результатам правила.Процесс обучения и его результатыПервый отчёт мы сформировали через 2 дня после запуска обучения, что позволило получить предварительную оценку вовлечённости сотрудников. Анализ данных показал, что наибольшую активность на начальном этапе продемонстрировали сотрудники, которые попались на фишинг. Рисунок 17. Промежуточный анализ обучения Через неделю после запуска обучения провели повторный анализ прогресса, включая оценку прохождения курсов и выявление участников, не приступивших к обучению. Рисунок 18. Отчёт по динамике обучения в Phishman 2.35 Анализ показал, что часть сотрудников не завершила обучение в установленный срок. Для обеспечения максимального охвата было принято решение о продлении сроков прохождения курсов. Рисунок 19. Продление и корректировка процесса обучения В результате фактическая продолжительность обучения составила 2 недели, что превысило первоначально установленный срок в одну неделю. Но и этого времени не хватило нашим сотрудникам. Чтобы узнать, кто оказался более ответственным, воспользовались возможностями правил. Рисунок 20. Пример настройки правила по выявлению сотрудников, прошедших обучение В результате была получена информация о сотрудниках, полностью и частично прошедших обучение. Рисунок 21. Отчёт по сработанному правилу по выявлению сотрудников, прошедших обучение Рисунок 22. Отчёт по сработанному правилу по выявлению сотрудников, частично прошедших обучение Результаты обучения:полностью прошли обучение — 52 %;частично — 22 %;не прошли обучение — 26 %.Мы проанализировали список сотрудников, не приступивших к обучению, и выяснили, что это те, кто не попался на фишинг во время первичного тестирования.Среди сотрудников, которые попались на фишинг, 80 % прошли обучение, остальные — прошли его частично. Рисунок 23. Результаты обучения сотрудников «АМ Медиа» Вместе с тем за этот период были зафиксированы положительные изменения в ключевых показателях: уровень обученности достиг 9 319 баллов, а показатель киберосознанности — 7 561 баллов. Несмотря на положительную динамику, полученные значения оставались гораздо ниже целевых ориентиров, что свидетельствует о необходимости дальнейшей работы по повышению вовлечённости сотрудников и развитию киберкультуры.Повторное тестированиеПовторное тестирование проводилось по тем же этапам, что и первичное: подготовка шаблонов, тестирование и проведение атак. Как и на первом этапе, основной задачей было сделать письмо максимально похожим на стандартную рабочую переписку, соответствующую реальным бизнес-процессам нашей компании.Подготовительный этап повторного тестирования потребовал дополнительных временных затрат, связанных с регистрацией новых доменов и расширением сценариев атак с учётом результатов первичного тестирования.Волна 1. Сценарии формировались не только для отдельных подразделений, но и адресно для конкретных сотрудников, что позволило повысить реалистичность и точность имитации фишинговых атак. Запустили несколько атак, для каждой из них были разработаны индивидуальные шаблоны электронных писем и соответствующие фишинговые формы. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 24. Пример фишингового письма для первой волны Рисунок 25. Пример фишинговой формы для письма из первой волны Волна 2. Вторая волна представляла собой массовую фишинговую кампанию. Для неё был создан и настроен пользовательский шаблон, основанный на триггерах срочности и страхе финансовых потерь. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки. Рисунок 26. Пример фишингового письма для второй волны Тестирование доставки писем и корректности отражения результатов в статистике прошло успешно.Результаты атакВ повторном тестировании приняли участие уже 23 человека. Увеличение числа участников на 2 человека связано с подключением новых сотрудников к нашему эксперименту. Резких скачков иммунности здесь не наблюдалось. Рисунок 27. График иммунности во время повторного тестирования Для дополнительной оценки мы и здесь также выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Таблица 2. Результаты повторного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот000Продажи008,7 %Продюсеры 008,7 %Редакция8,7 %08,7 %Руководитель000 Мы также посмотрели, как себя показали сотрудники, которые не прошли обучение, в повторном фишинговом тесте. По данным отчёта, в первой волне повторного тестирования на фишинг попались 40% из всех, кто не обучался. Рисунок 28. Поиск информации о сотруднике в отчёте по атакам Подведение итогов После завершения всех этапов эксперимента мы получили следующие показатели:Иммунность — 76 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 91,3 %.Уровень риска — 7, средний. Рисунок 29. Информационная панель Phishman 2.35 после завершения эксперимента После обучения и повторного тестирования добавились другие показатели:Обученность — 11 / 100. Знания отсутствуют, обучение следует начать с базового уровня.Киберосознанность — 10 / 100. Низкий уровень, сотрудники не знают, как действовать в случае угроз.Часть результатов сравнили и представили их в таблице ниже. Таблица 3. Сравнение показателей киберкультуры до и после обученияПоказательДо обученияПосле обученияОбученность09319Иммунность81 %76 %Киберосознанность 07561Охват аудитории (повторно попались на фишинг)71 %91,3 %Уровень риска87 Также проанализировали действия сотрудников после обучения и сравнили их с результатами первичного тестирования. Таблица 4. Сравнение действий сотрудников до обучения и послеОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДо обученияПосле обученияДо обученияПосле обученияДо обученияПосле обученияДокументооборот004,76 %04,76 %0Продажи004,76 %09,52 %8,7 %Продюсеры 000023,8 %8,7 %Редакция08,7 %0019,04 %8,7 %Руководитель000000 Рисунок 30. Процент попавшихся на фишинг до обучения и после по отделам Если во время первичного тестирования попалось 22 % участников, то после обучения этот показатель уменьшился и стал 12 %. Рисунок 31. Общий процент попавшихся на фишинг до обучения и после Результаты повторного тестирования показали, что, несмотря на заметное снижение количества взаимодействий с фишинговыми письмами, часть сотрудников по-прежнему выполняет действия, свидетельствующие о подверженности атакам. Это ожидаемый результат, поскольку киберкультуру невозможно сформировать за столь короткое время. Речь идёт о длительном процессе, который требует регулярной работы как со стороны специалистов по информационной безопасности, так и со стороны самих сотрудников.Наш эксперимент позволил проверить знания сотрудников, провести обучение и затем оценить, насколько полученные знания закрепились на практике. Однако с точки зрения развития киберкультуры — это лишь один из этапов работы, а не её завершение.Сложности, с которыми мы столкнулисьОсобенность нашего эксперимента — организация предварительного тестирования. Перед запуском каждой атаки мы проверяли её работу на собственном аккаунте, чтобы убедиться в корректной отработке сценария на стороне пользователя. Такие проверки попадали в общую статистику системы и оказывали влияние на итоговые показатели. Возможность исключить подобные события из расчётов отсутствует. Согласно комментариям вендора, для этих целей следует использовать отдельный тестовый стенд. Поэтому мы вели дополнительно самостоятельный анализ результатов эксперимента.Отдельные сложности возникли на этапе обучения сотрудников. Завершить обучение в установленные сроки не удалось из-за человеческого фактора. Не все участники смогли своевременно пройти назначенные материалы, что потребовало увеличения периода обучения и дополнительного контроля за его прохождением.Впечатления от проекта команды «АМ Медиа»Проведение тестирования не вызвало негативной реакции со стороны сотрудников. Хотя фишинговые сообщения активно обсуждались внутри коллектива, жалоб руководству или недовольства вида «зачем вообще было устраивать такую проверку» не возникло. Основной интерес был сосредоточен вокруг самих писем и попыток понять, что именно происходит.Реакция сотрудниковОдним из самых любопытных наблюдений стала реакция сотрудников после первой волны первичного тестирования. Полученные фишинговые сообщения быстро стали предметом обсуждения: сотрудники пересылали их друг другу, задавали вопросы коллегам и пытались разобраться, что происходит.Некоторые пошли ещё дальше и вступали в переписку с отправителем, воспринимая фишинговые письма как реальные рабочие сообщения. Это наглядно показало не только убедительность используемых сценариев, но и то, что практическое столкновение с угрозой вовлекает сотрудников в тему ИБ гораздо сильнее, чем абстрактные примеры из учебных материалов. Во время повторного тестирования такой реакции уже не возникло.Реакция организаторовЕсли для большинства сотрудников тестирование выглядело как неожиданно появившиеся письма в почте, то для команды, которой было поручено тестирование Phishman 2.35 этот проект сопровождался совсем другими эмоциями. Подготовка сценариев, запуск атак и ожидание результатов вызывали ощутимое волнение. Оказалось, что смотреть на ситуацию глазами злоумышленника не так просто, как может показаться со стороны. Приходилось постоянно задавать себе вопросы: какой сценарий покажется правдоподобным, что привлечёт внимание сотрудника, а что, наоборот, вызовет подозрения.Самыми напряжёнными были дни первой волны тестирования. На этом этапе ещё не было понимания, как сотрудники отреагируют на рассылки, насколько убедительными окажутся сценарии и не вызовет ли проверка негативной реакции внутри коллектива. С каждой новой зафиксированной активностью интерес смешивался с тревогой, а результаты ожидались едва ли не с большим нетерпением, чем сам запуск кампании.После завершения эксперимента стало легче: всё задуманное удалось реализовать, результаты были получены и проанализированы. Тем не менее полностью избавиться от мыслей о проделанной работе не получилось. Время от времени возвращаешься к отдельным этапам и задаёшься вопросом: а стоило ли сделать именно так? Может быть, какой-то сценарий можно было построить иначе, а какие-то решения принять по-другому?Наверное, это естественная часть любого практического проекта. Когда работа заканчивается, появляется возможность посмотреть на неё со стороны и критически оценить собственные решения. Именно в такие моменты часто приходят идеи, которые помогают сделать следующие проекты лучше.Сотрудничество с вендоромВ ходе подготовки и проведения эксперимента иногда возникали вопросы, связанные с настройкой платформы, особенностями реализации отдельных сценариев и интерпретацией результатов. Для их решения использовались как переписка, так и рабочие созвоны. Запросы обрабатывались оперативно, что позволяло своевременно получать необходимую информацию и не допускать задержек в выполнении работ. Поддержка была доступна не только в рабочее время, но и в выходные дни.ВыводыПовторное тестирование показало, что тщательно подготовленные и персонализированные фишинговые атаки значительно эффективнее. При наличии качественной разведки злоумышленники способны подобрать убедительный сценарий практически для любого сотрудника. А если специалист может ошибиться, то сотруднику, который не занимается вопросами ИБ каждый день, сделать это ещё проще.Работа в сфере информационной безопасности или информационных технологий сама по себе не защищает человека от фишинга, социальной инженерии и других современных атак. Мы убедились в этом на собственном опыте: даже профильные знания не гарантируют, что человек не попадется на хорошо продуманную атаку. Злоумышленники постоянно меняют сценарии, поэтому знания, полученные однажды, быстро устаревают.При помощи эксперимента мы не только проверили, насколько сотрудники готовы распознавать атаки, но и поняли, как с помощью Phishman 2.35 можно сделать работу по развитию киберкультуры системной. Вместо отдельных курсов появился понятный цикл: смоделировать атаку, оценить реакцию, провести обучение и проверить, изменилось ли поведение участников. При необходимости — повторить или скорректировать процесс при помощи рекомендаций платформы. Результаты фиксируются автоматически, поэтому можно видеть, какие темы требуют больше внимания, и развивать киберкультуру на основе реальных данных, а не предположений.Читать далее
    • PR55.RP55
    • santy
      RP55, есть у тебя ТГ?
×