В целом, достаточно занимательное занятие логгировать пролетающие через фаервол пакеты - обычно, почему-то, логгируют deny-и, хотя, наверно, любопытнее было бы смотреть на permit-ы.Также прикольно смотреть логи IDSIPS... Но с точки зрения контроля доступа (а вся безопасность так или иначе может свестись к контролю доступа к защищаемым данным) куда более интересны события добавленияудаления ролигруппыполномочия. Безусловно любая продвинутая система умеет писать такие события в свои логи безопасности, соответстенно, их можно собрать в какой-нибудь SIEM и повесить на них какое-нибудь реагирование.
Однако тут есть некая философская проблема - такой инцидент не поднимется на бизнес-уровень самостоятельно и оператору мониторинга SIEM придется переводить технический отчет на язык понятный менеджерам. Делать такое "уточнение у бизнеса" скорее всего придется, поскольку далеко не всегда у оператора SIEM есть понимание насколько легитимно то или иное присвоениеудаление.
Другим вариантом является - возложение вопроса аудита полномочий пользователей в системах на предмет соответствия поданным заявкам на подразделение контроля доступа, которое если и делает такие проверки то нечасто, что создает возможность преднамеренной атаки НСД остаться вообще не замеченной: несанкционированные добавления с последующим удалением полномочий проводятся между процедурмаи аудита прав.
Поэтому, обычно, на практике все-таки делают автоматическое оповещение об изменении полномочий, но для каких-то особых случаев, когда таких пользователейролейполномочий не так много - как правило, какие-нибудь администраторы (Domain Admins, Enterprise Admins, Administrators, ....), казначеи и операторы систем ДБО и т.п.
Но все становится по-другому с появлением решений IDMIAG (не буду тут много лить воды об их функционале и различиях - можно ознакомиться в Интернете). Практически все современные их представители имеют функционал аудита настроенных прав доступа в управляемой системе (системы, доступ к которым регулируется через IDM) на соответствие согласованным доступам в системе IDM. Найденные несоответствия могут обрабатываться по-разному, как правило, это настраиваемо. Мне нравится реакция в виде запуска workflow согласовния. Это позволяет автоматически вывести техническую проблемупоявления членства в лишней группе AD на бизнес-уровень - согласующие получат автоматически сгенеренные заявки по этому поводу на согласование. Если такой доступ был предоставлен в связи с реальной бизнес-потребностью, доступ останется и легализуется. Если такой доступ появился в результате каких-то неправильных позывов - он будет отобран IDM на основании отклоения поданной на этот доступ заявки. И вот тут уже прилетает оповещение в Безопасность, что был обнаружен и испрвлен факт НСД (так как заявка была отклонена Бизнесом). Принципиально здесь то, что решение об отъеме доступа принимается не оператором SIEM, у которого, безусловно, есть чем заняться (его любимые фаерволы и IDSIPS генерят гигабайты логов в день, с которыми, раз уж собираем, надо хотя бы что-то делать), а бизес-согласующие по результатам отработки формального процесса согласованияотклонения доступа.
Однако тут есть некая философская проблема - такой инцидент не поднимется на бизнес-уровень самостоятельно и оператору мониторинга SIEM придется переводить технический отчет на язык понятный менеджерам. Делать такое "уточнение у бизнеса" скорее всего придется, поскольку далеко не всегда у оператора SIEM есть понимание насколько легитимно то или иное присвоениеудаление.
Другим вариантом является - возложение вопроса аудита полномочий пользователей в системах на предмет соответствия поданным заявкам на подразделение контроля доступа, которое если и делает такие проверки то нечасто, что создает возможность преднамеренной атаки НСД остаться вообще не замеченной: несанкционированные добавления с последующим удалением полномочий проводятся между процедурмаи аудита прав.
Поэтому, обычно, на практике все-таки делают автоматическое оповещение об изменении полномочий, но для каких-то особых случаев, когда таких пользователейролейполномочий не так много - как правило, какие-нибудь администраторы (Domain Admins, Enterprise Admins, Administrators, ....), казначеи и операторы систем ДБО и т.п.
Но все становится по-другому с появлением решений IDMIAG (не буду тут много лить воды об их функционале и различиях - можно ознакомиться в Интернете). Практически все современные их представители имеют функционал аудита настроенных прав доступа в управляемой системе (системы, доступ к которым регулируется через IDM) на соответствие согласованным доступам в системе IDM. Найденные несоответствия могут обрабатываться по-разному, как правило, это настраиваемо. Мне нравится реакция в виде запуска workflow согласовния. Это позволяет автоматически вывести техническую проблемупоявления членства в лишней группе AD на бизнес-уровень - согласующие получат автоматически сгенеренные заявки по этому поводу на согласование. Если такой доступ был предоставлен в связи с реальной бизнес-потребностью, доступ останется и легализуется. Если такой доступ появился в результате каких-то неправильных позывов - он будет отобран IDM на основании отклоения поданной на этот доступ заявки. И вот тут уже прилетает оповещение в Безопасность, что был обнаружен и испрвлен факт НСД (так как заявка была отклонена Бизнесом). Принципиально здесь то, что решение об отъеме доступа принимается не оператором SIEM, у которого, безусловно, есть чем заняться (его любимые фаерволы и IDSIPS генерят гигабайты логов в день, с которыми, раз уж собираем, надо хотя бы что-то делать), а бизес-согласующие по результатам отработки формального процесса согласованияотклонения доступа.
