История №2 «Как из-за лени был провален аудит безопасности» (из «5 историй об информационной безопасности»)

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

Первую историю («Полуденный вор») Вы можете прочитать здесь ^[1]

А теперь история вторая, «Как из-за лени был провален аудит безопасности, или Кто изменил групповые политики?».

“Мы провалили аудит безопасности!”

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

“Кто это сделал?!!”

Дженнифер взглянула на коллег. В компании было более 20 человек, входящих в группе Привилегированных Администраторов Домена, и любой из них мог отключить политику паролей. Политика паролей была задана в объекте групповых политик высокого уровня, который содержал тысячи других настроек. Все эти администраторы вносили изменения в групповые политики практически каждую неделю. В журналах событий отображались записи о доступе, но журналы аудита не содержали в себе информации о том, какие именно настройки были изменены. Любой мог сделать это – пусть даже случайно – и способа определить, кто именно это был, не существовало. Джозеф, новенький администратор нервно объяснял это начальнику, которого такой расклад дел явно не устраивал.

“То есть, кто-то либо случайно либо специально изменил эти настройки, и мы не можем узнать, кто же это именно был?”

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

“Никто не хочет признаться?” – спросил начальник. Никто не признавался. За предыдущие 4 месяца из компании ушло 4 администратора, и проще всего было свалить всю вину на них.

“У кого-нибудь есть соображения, зачем это было сделано, если это не случайность?”

Дженнифер пожала плечами. “Думаю, они столкнулись с пользователем, который не мог придумать достаточно сложный пароль. Проще все было отключить политику. Некоторые из нас делали так раньше, чтобы быстро дать доступ в сеть, и затем сразу же включали политику. Возможно, кто-то просто забыл включить политику”.

“Совсем не то, что он хотел бы услышать”, – подумала Дженнифер, видя как лицо начальника становится пурпурным от злости.

Она знала, что ее компании требуется более совершенное решение для аудита изменений, особенно тех, которые связаны с объектами групповых политик. Нужно знать, кто и когда их менял. А также нужно решение, которое позволяло бы оптимально хранить записи журналов, чтобы можно было сразу же отфильтровать только записи изменений объектов групповых политик, предпочтительно без отдельного поиска по каждому контроллеру домена.

Какие решения Вы бы применили для мониторинга изменений групповых политик?

Автор: NetWrixRU