В целом, достаточно занимательное занятие логгировать пролетающие через фаервол пакеты - обычно, почему-то, логгируют deny-и, хотя, наверно, любопытнее было бы смотреть на permit-ы. Также прикольно смотреть логи IDS\IPS... Но с точки зрения контроля доступа (а вся безопасность так или иначе может свестись к контролю доступа к защищаемым данным) куда более интересны события добавления\удаления роли\группы\полномочия. Безусловно любая продвинутая система умеет писать такие события в свои логи безопасности, соответстенно, их можно собрать в какой-нибудь SIEM и повесить на них какое-нибудь реагирование.
Однако тут есть некая философская проблема - такой инцидент не поднимется на бизнес-уровень самостоятельно и оператору мониторинга SIEM придется переводить технический отчет на язык понятный менеджерам. Делать такое "уточнение у бизнеса" скорее всего придется, поскольку далеко не всегда у оператора SIEM есть понимание насколько легитимно то или иное присвоение\удаление.
Другим вариантом является - возложение вопроса аудита полномочий пользователей в системах на предмет соответствия поданным заявкам на подразделение контроля доступа, которое если и делает такие проверки то нечасто, что создает возможность преднамеренной атаки НСД остаться вообще не замеченной: несанкционированные добавления с последующим удалением полномочий проводятся между процедурмаи аудита прав.
Поэтому, обычно, на практике все-таки делают автоматическое оповещение об изменении полномочий, но для каких-то особых случаев, когда таких пользователей\ролей\полномочий не так много - как правило, какие-нибудь администраторы (Domain Admins, Enterprise Admins, Administrators, ....), казначеи и операторы систем ДБО и т.п.
Но все становится по-другому с появлением решений IDM\IAG (не буду тут много лить воды об их функционале и различиях - можно ознакомиться в Интернете). Практически все современные их представители имеют функционал аудита настроенных прав доступа в управляемой системе (системы, доступ к которым регулируется через IDM) на соответствие согласованным доступам в системе IDM. Найденные несоответствия могут обрабатываться по-разному, как правило, это настраиваемо. Мне нравится реакция в виде запуска workflow согласовния. Это позволяет автоматически вывести техническую проблему появления членства в лишней группе AD на бизнес-уровень - согласующие получат автоматически сгенеренные заявки по этому поводу на согласование. Если такой доступ был предоставлен в связи с реальной бизнес-потребностью, доступ останется и легализуется. Если такой доступ появился в результате каких-то неправильных позывов - он будет отобран IDM на основании отклоения поданной на этот доступ заявки. И вот тут уже прилетает оповещение в Безопасность, что был обнаружен и испрвлен факт НСД (так как заявка была отклонена Бизнесом). Принципиально здесь то, что решение об отъеме доступа принимается не оператором SIEM, у которого, безусловно, есть чем заняться (его любимые фаерволы и IDS\IPS генерят гигабайты логов в день, с которыми, раз уж собираем, надо хотя бы что-то делать), а бизес-согласующие по результатам отработки формального процесса согласования\отклонения доступа.
Однако тут есть некая философская проблема - такой инцидент не поднимется на бизнес-уровень самостоятельно и оператору мониторинга SIEM придется переводить технический отчет на язык понятный менеджерам. Делать такое "уточнение у бизнеса" скорее всего придется, поскольку далеко не всегда у оператора SIEM есть понимание насколько легитимно то или иное присвоение\удаление.
Другим вариантом является - возложение вопроса аудита полномочий пользователей в системах на предмет соответствия поданным заявкам на подразделение контроля доступа, которое если и делает такие проверки то нечасто, что создает возможность преднамеренной атаки НСД остаться вообще не замеченной: несанкционированные добавления с последующим удалением полномочий проводятся между процедурмаи аудита прав.
Поэтому, обычно, на практике все-таки делают автоматическое оповещение об изменении полномочий, но для каких-то особых случаев, когда таких пользователей\ролей\полномочий не так много - как правило, какие-нибудь администраторы (Domain Admins, Enterprise Admins, Administrators, ....), казначеи и операторы систем ДБО и т.п.
Но все становится по-другому с появлением решений IDM\IAG (не буду тут много лить воды об их функционале и различиях - можно ознакомиться в Интернете). Практически все современные их представители имеют функционал аудита настроенных прав доступа в управляемой системе (системы, доступ к которым регулируется через IDM) на соответствие согласованным доступам в системе IDM. Найденные несоответствия могут обрабатываться по-разному, как правило, это настраиваемо. Мне нравится реакция в виде запуска workflow согласовния. Это позволяет автоматически вывести техническую проблему появления членства в лишней группе AD на бизнес-уровень - согласующие получат автоматически сгенеренные заявки по этому поводу на согласование. Если такой доступ был предоставлен в связи с реальной бизнес-потребностью, доступ останется и легализуется. Если такой доступ появился в результате каких-то неправильных позывов - он будет отобран IDM на основании отклоения поданной на этот доступ заявки. И вот тут уже прилетает оповещение в Безопасность, что был обнаружен и испрвлен факт НСД (так как заявка была отклонена Бизнесом). Принципиально здесь то, что решение об отъеме доступа принимается не оператором SIEM, у которого, безусловно, есть чем заняться (его любимые фаерволы и IDS\IPS генерят гигабайты логов в день, с которыми, раз уж собираем, надо хотя бы что-то делать), а бизес-согласующие по результатам отработки формального процесса согласования\отклонения доступа.
5 comments:
IDM прекрасно с того момента, как можно выделить согласующих. И в любом случае абсолютно неверно переваливать это решение на какого-то оператора SIEM, не его уровень совершенно.
Если процес контроля доступа в принципе есть, то согласующие определены.
В случае idm они могут вычисляться автоматически по оргструктуре или справочникам ролей/ресурсов.
А может есть идеи относительно того, как этот функционал (аудит прав и согласование) реализовать без внедрения IDM\IAG?
Возьмем небольшую организацию, в которой роль IDM играет Active Directory. Как в ней внедрить такое красивое решение с минимумом затрат?
Игорь, ну ты же сам знаешь как это можно сделать скриптами.
Современные IDM могут назначать веса каждому доступу и показывать аггрегированный уровень риска, есть и более интересная тема для борьбы с привилегированными учетками - автообнаружение привилегированных и автосмена паролей каждые 5 минут
Post a Comment