Между политикой ИБ и реальностью на рабочих местах: контроль конфигураций и патч-менеджмент как непрерывный процесс

Самая массовая и самая живая часть инфраструктуры

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

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

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

Несколько слов об инструменте, о котором пойдет речь

ACM – единая платформа централизованного управления парком компьютеров, серверов и виртуальных машин, ориентированная на эксплуатацию в инфраструктурах на базе Linux и, прежде всего, на Astra Linux. В рамках одной консоли ACM закрывает задачи, которые в классическом Windows-мире обычно распределялись между несколькими инструментами уровня WSUS и SCCM: развертывание и обновление ОС, управление прикладным ПО, инвентаризацию и аналитику состояния парка устройств. Продукт рассчитан в том числе на работу в изолированных контурах без доступа в интернет, что для предприятий КИИ и госсектора давно является стандартным режимом работы.

ACM входит в портфель серверных продуктов «Группы Астра» наряду с операционной системой Astra Linux Server и службой каталога ALD Pro. В связке с ALD Pro платформа ACM импортирует организационную структуру и учетные записи рабочих мест –единоразово или с регулярной синхронизацией, –благодаря чему иерархия подразделений и групп устройств становится расширением уже существующей доменной модели, а не отдельным проектом «с нуля». В ACM поддерживаются и другие службы каталога.

Почему «золотой образ» – это иллюзия контроля

На первый взгляд кажется логичным подготовить выверенный образ, протестировать его, выдать пользователю – и считать, что задача закрыта. Но рабочая станция живет у сотрудника не неделю и не месяц. В нашей практике типичная ситуация – когда сотрудник работает в компании пять, семь, десять лет, и все это время использует одно и то же устройство.

За это время многое успевает произойти:

• пользователь ставит стороннее ПО – что-то необходимое для работы, что-то на всякий случай;
• временные исключения от ИТ-поддержки превращаются в постоянные;
• какие-то политики «не доезжают» до удаленных машин;
• параллельные инструменты управления конфликтуют между собой;
• выходят обновления, которые перезаписывают часть настроек;
• каждый день обновляются списки CVE – неизбежная часть современной эксплуатации, от которой никуда не уйти.

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

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

Состояние рабочей станции напрямую формирует поверхность атаки:

• Неконтролируемое ПО. Теневые установки, утилиты с непроверенных источников, устаревшие версии браузеров и офисных пакетов с известными уязвимостями.

• Отставание патчей. Известные эксплуатируемые CVE в браузере или офисном приложении могут жить на машинах месяцами после выхода исправления.
• Учетные записи и права. Локальные учетки «для удобства», лишние права, забытые сервисные пользователи. Здесь важная оговорка: ACM управляет устройством, а не пользователем. Если на одной машине работает десять человек, для бизнеса важно, что устройство присутствует в инфраструктуре и приведено к нужному состоянию – актуальная версия программного обеспечения будет для всех десяти.
• Драйверы и прошивки. Уязвимости находят не только в ПО и ОС, но и в драйверах конкретного оборудования – и без аппаратной инвентаризации эти риски просто не видны.

Каждый из этих пунктов знаком службе ИБ. Но в реальности они возникают не столько из-за ошибок первичной настройки, сколько из-за того, что за разрывом между «как было задумано» и «как есть сейчас» никто не следит постоянно.

Почему классические подходы не закрывают проблему

• Золотой образ при выдаче. Дает снимок состояния на момент T, теряет актуальность через несколько недель.
• Антивирус или EDR. Решают свою задачу – обнаружение и реагирование, – но не отвечают на вопрос «соответствует ли машина политике ИБ прямо сейчас», какие пакеты на ней установлены и какие из них устарели.
• Сканеры уязвимостей. Выявляют CVE – и это полезно. Но после того как сканер показал отчет, с уязвимостями еще нужно что-то сделать: доставить патчи, обновить пакеты, заменить версии ПО на сотнях машин. И вот здесь начинается отдельная большая задача.
• Ручные обходы и инвентаризации. Просто не масштабируются. На парке в сотни тысяч машин это физически невозможно.
• Разрозненные инструменты ИТ и ИБ. ИТ ставит патчи, ИБ требует харденинга, но единой картины состояния парка не видит никто.

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

Еще один практический момент: ACM поддерживает ролевую модель, и инструментом пользуются и ИТ-, и ИБ-специалисты. Распределение зон ответственности определяется внутренними регламентами компании, и в зависимости от них через ACM свои задачи могут закрывать обе службы. Это устраняет традиционный разрыв: «ИТ ставит патчи отдельно, ИБ требует харденинга отдельно».

Как выстроить непрерывный процесс: делай раз, делай два, делай три

Перейдем к практической части – как переложить идею непрерывного процесса в конкретные шаги.

Шаг 1. Полная видимость парка. Первым делом добавить в систему управления все устройства, и доменные, и недоменные. Доменные удобно подтянуть импортом записей из службы каталога, а недоменные добавить вручную или с помощью дополнительных инструментов автоматизации. Как только парк собран в одном месте, появляется полная картина: программная и аппаратная инвентаризация, версии ОС, установленные пакеты, драйверы. Без этой картины все дальнейшие шаги бессмысленны, нельзя управлять тем, чего не видишь.

Шаг 2. Решения на основе данных, а не догадок. При наличии полной инвентаризации любая новость о критической уязвимости перестает быть стрессом. Если определенная версия ОС или пакета перестает отвечать требованиям безопасности, все машины с этой версией обнаруживаются за минуты, и формируется план действий. Без инвентаризации тот же вопрос превращается в недели работы, а часть машин и вовсе остается забытой.

Шаг 3. Управляемые волны раскатки. Дальше – патч-менеджмент. Совместно со службой ИБ или в рамках ее требований формируется план: какие устройства идут на обновление первыми, какие следом, в каком объеме. Это классические волны раскатки – сначала тестовая группа, затем ранние пользователи, затем массовая часть парка. Такой подход снимает главное опасение ИТ-службы: «накатим патч и сломаем продуктив». Сломать можем, но только в контролируемой группе и до того, как изменения дойдут до всех.

Шаг 4. Автоматическое поддержание целевого состояния парка. Помимо разовых кампаний обновления, ACM позволяет заранее описать желаемое состояние парка в виде набора правил, и система будет поддерживать это состояние автоматически. Например, можно задать список нежелательного в организации ПО, и оно будет автоматически удаляться с машин пользователей. Или указать корпоративный набор приложений, который должен поддерживаться в актуальной версии. Если в каком-то пакете найдена уязвимость, достаточно поменять версию в сценарии, старый пакет будет удален, новый установлен, причем для всех пользователей устройства одновременно.

Шаг 5. Обратная связь и отчетность. После того как кампания обновления отработала, важно не просто увидеть «сделано / не сделано», а получить детальную обратную связь: где установилось, где нет, где требуется ручное вмешательство. На основе этих данных формируются дашборды, отчеты и графики – для руководства, для службы ИБ, для собственной операционной работы. По ним видно, сколько устройств в парке остаются в уязвимой зоне, и динамика по этой цифре становится основной метрикой зрелости процесса.

А главное – после пятого шага процесс возвращается к первому. Это и есть непрерывный цикл.

Короткий сценарий из практики. В популярном корпоративном браузере выходит уведомление о критической уязвимости. В компании 3 000 рабочих мест, часть сотрудников на удаленке. Без инвентаризации поиск ответа на первый вопрос – «у кого вообще стоит уязвимая версия?» – отнимает дни. С полной видимостью парка ответ можно получить мгновенно: ACM показывает все машины с уязвимой версией, включая ноутбуки удаленных сотрудников, которые подхватываются при подключении к корпоративной сети. Дальше – раскатка обновления волнами: сначала тестовая группа из ИТ, через сутки ранние пользователи, через двое суток – основной парк. По итогу – отчет: где установилось, где машина не была в сети и попадет в следующее окно, где требуется внимание инженера. Вся история – от новости до закрытия уязвимости по парку – занимает дни, а не недели.

Защищенность АРМ – это процесс, а не состояние

Главный сдвиг в мышлении, который важно зафиксировать: невозможно один раз настроить рабочее место и считать его защищенным. Приведя инфраструктуру в безопасное состояние сегодня, мы не получаем гарантии, что через час или через сутки она останется такой же. Каждый день обновляются списки уязвимостей, выходит новое ПО, появляются новые версии. Инфраструктура постоянно меняется, и инструменты должны ей соответствовать.

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

Анастасия Белоусова, менеджер продукта ACM, «Группы Астра»