Настройка дружбы ИБ и ИТ: внедряем стандарты безопасного конфигурирования

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

Автор: Кирилл Евтушенко, генеральный директор ООО “Кауч”

Зачем заниматься настройками?

Зачем заниматься управлением безопасностью конфигураций, к примеру, банковским организациям? Вопрос риторический.

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

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

Почему работать с настройками сложно?

Основная проблема в работе с настройками проста и фундаментальна: их очень много.

Если собрать настройки по всем типам ресурсов, которые есть в сети среднестатистической компании (ОС, СУБД, прикладное ПО, веб-серверы и т. д.), то получится около 1000 штук, из них критически важных – 200–300. В масштабе инфраструктуры на 1000 хостов – уже 200–300 тыс. настроек. При 10 тыс. хостов настройки исчисляются миллионами. Отметим радикальное отличие от работы с "классическими" вендорскими брешами (с CVE), где уязвимостей с высоким риском, требующих срочного реагирования, будет от силы 2–3 на систему.

При этом подразделение ИБ выступает заказчиком и лишь частичным исполнителем, так как не может выполнить задачу безопасной настройки без привлечения ИТ. ИТ-администраторы, в свою очередь, не понимают, за что им все это – "красный" отчет от сканера уязвимостей на пятьсот или более страниц по каждой ИТ-системе объективно деморализует. Кроме того, многое в требованиях стандартов может быть непонятно без объяснений, так как в своей ежедневной работе по сопровождению систем администраторы могли никогда не сталкиваться с частью настроек, которые относятся к безопасности.

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

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

Ешьте слона по частям

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

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

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

Сколько вешать в граммах?

Занимаясь внедрением стандартов, мы пришли к оптимальному количеству требований, которое на старте для большинства систем колеблется в районе 30. За исключением операционных систем – там собрать всю "критику" в столь малое количество сложно, лучше ориентироваться на 50 требований в одном стандарте. Старайтесь не включать в одно требование большие вложенные списки подпунктов, например полсотни параметров аудита. Желательно ориентироваться на принцип "одно требование – одна настройка".

Помимо количества, важно учитывать критичность. Если есть конкретные обязательные для исполнения требования (например, PCI DSS), в первую очередь берите их оттуда, чтобы не столкнуться с санкциями и штрафами. Далее стоит включить наиболее критичные элементы: парольную политику, управление доступами, логирование и аудит, шифрование, защиту данных и т.д., в зависимости от типа системы.

Эти требования понятны администраторам с точки зрения важности: никто не скажет, что не нужно настраивать парольную политику. От стандарта посильного объема и "без воды" у администратора системы не возникает ощутимого неприятия.

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

Отлично, если при внедрении стандартов есть возможность автоматизировать работу специалистов ИБ и ИТ-администраторов – здесь стоит вернуться к вопросу об альтернативах сканеру. В своих проектах мы используем собственную платформу "Кауч" [1], решение набирающего обороты класса Security Configuration Management, которое предоставляет единую среду для ИБ и ИТ, позволяя автоматизировать всю техническую часть управления безопасностью настроек. При наличии готовых команд и скриптов "из коробки", а также возможности настроить систему в пару кликов, ИТ-администраторы на практике справляются с освоением стандарта в десятки раз быстрее.

Жизнь после первого стандарта: что дальше?

Естественно, 30–50 настроек с глобальной точки зрения – лишь стартовая точка для выстраивания процесса, и нужно двигаться дальше. Отталкивайтесь от оценки прогресса: если, например, успешно кастомизированы 80% настроек на 80% хостов, то прогресс хороший и можно добавлять новые изменения. При этом проводить оценку необходимо по каждому типу систем и каждой группе ИТ-администраторов: в зависимости от сложности систем и количества настроек все могут двигаться с разной скоростью. Важно оценивать динамику и реагировать соответствующе: "отличникам" добавлять больше требований, "отстающим" – меньше; или даже отложить добавление до следующего пересмотра, а сейчас – выявить и устранить причины проблем.

Как часто это делать? Почти все практики и стандарты по управлению информационной безопасности – международные и отечественные – требуют регулярного пересмотра политик. Рекомендуем оценивать прогресс один раз в три месяца или один раз в полгода.

Союзники

Еще один немаловажный фактор успеха при внедрении стандартов – насколько хорошо вы "продали" это в ИТ.

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

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

От того, насколько сильно вы вложитесь на старте, будет зависеть дальнейший успех. Важно не быть "черным ящиком", выдающим указания: старайтесь объяснять на этапе согласования стандарта с точки зрения ИБ каждое требование, которое вызывает вопросы, разбирайтесь вместе в проблемах и трудных местах с конкретными администраторами.

Проводите тестирование совместно с ИТ: помогайте консультативно в пределах компетенций в настройке тестовых систем, сразу идентифицируйте и обрабатывайте отклонения, собирайте обратную связь и разбирайтесь в причинах конфликтов. Составляйте на основе полученных данных реально рабочие стандарты – копипасты из отчетов сканеров и бенчмарков "не взлетят".

Если резюмировать все упомянутые выше рекомендации, можно прийти к простому выводу: самой важной настройкой при разработке и внедрении стандартов станет настройка дружбы с ИТ. Остальное помогут решить здравый смысл и технологии.