Я часто пишу о том, как важно не только развернуть в периметре средства защиты информации, но и надлежащим образом их обслуживать и поддерживать в работоспособном состоянии. Сегодня хочется поговорить о локальных агентах СЗИ, устанавливаемых на хосты корпоративной сети. Довольно очевидно, что в идеальной ситуации эти агенты должны быть установлены везде, где это возможно.
Степень покрытия хостов корпоративной сети локальными агентами — простая и относительно легко измеримая метрика состояния защищённости инфраструктуры. Здесь есть свои особенности: например, нельзя просто взять список всех хостов и сверить его со списком, выгруженным из консоли СЗИ, потому что не все типы ОС могут этим СЗИ поддерживаться, а ряд хостов может быть исключён из покрытия в связи с недостатком ресурсов или особенностями корпоративной политики. Но даже с учётом этого вопрос «На каком проценте хостов, пригодных к установке локальных агентов, эти агенты реально установлены?» звучит куда проще, чем, например, «Насколько полно наш SOC покрывает атаки по классификации MITRE?» или «Какой процент существующих рисков безопасности отражён в матрице рисков?»
Из моего личного опыта, на практике посчитанная метрика покрытия обычно выглядят неприглядно и грустно, тоскливо болтаясь где-то в районе 50–60% (а в тяжёлых случаях — и 30%). Насколько при этом падает приносимая соответствующим СЗИ польза — вопрос дискуссионный, но я бы грубо оценил процент падения эффективности равным проценту «недопокрытых» хостов. При этом никто не отменял закон подлости: атака на компанию, как назло, пройдёт именно через них.
Вот пример из реальной практики: организация заключила контракт с MSSP на мониторинг событий безопасности. Всего на серверы и рабочие станции было установлено порядка двух тысяч сенсоров, степень покрытия Windows-инфраструктуры агентами при этом составила солидные 70%. Через некоторое время бдительный аналитик SOC заметил отсутствие сенсора на одном из контроллеров домена (на все остальные сенсоры были установлены). Отбившийся от стада контроллер был «возвращён в стойло», и буквально через час сработало правило SIEM, обнаружившее подозрительный процесс, выполнявший дамп базы данных Active Directory. Дальше события развивались вполне предсказуемо: эскалация, запуск процедуры реагирования на инцидент, изучение под микроскопом всех активностей на хосте, его очистка и так далее. Однако из-за отсутствующего долгое время агента атака была обнаружена с лагом в несколько месяцев, что сильно затруднило определение вероятного пути компрометации и её масштабов.
Другой пример — хосты с устаревшей и снятой с поддержки ОС, а также высоконагруженные серверы. Как показывает практика, даже в крупных и известных компаниях нередка ситуация, когда критичные для бизнеса сервисы разворачивались настолько давно, что сейчас уже никто не понимает, ни как это работает, ни как это поддерживать, ни что делать, если всё вдруг «упадёт». Вот и крутится себе какое-нибудь веб-приложение под Windows 2003, на которую не то что антивирус, но даже и обновления безопасности администраторы ставить отказываются, мотивируя это тем, что «если сломается, уже не починим». Для атакующих такие системы — настоящий рай: взломать легко, заметить никто не сможет, а проблемы со стабильностью злоумышленников, разумеется, не волнуют.
Ну и последняя типичная ситуация — хосты (как правило, серверы), которые более не используются, но ещё не выведены из эксплуатации и работают. Это тоже лакомый кусочек для хакеров. Но к теме теневой ИТ-инфраструктуры вернёмся как-нибудь в другой раз.
Так что, приобретая очередное чудо-СЗИ, неплохо бы сразу внедрить и метрику по контролю степени его покрытия. А чтобы эта метрика выглядела не слишком печально, придётся организовать адекватную поддержку —об этом мы говорили в апрельской заметке прошлого года. И пусть кому-то эта метрика покажется скучной и незамысловатой, но многие самые важные вещи в нашей индустрии часто выглядят именно так.
