Журнал "Information Security/ Информационная безопасность" #2, 2025

оценку, получить премию – дополни- тельно поможет снять сопротивление от участия в процессе. Сколько вешать в граммах? Занимаясь внедрением стандартов, мы пришли к оптимальному количеству требований, которое на старте для боль- шинства систем колеблется в районе 30. За исключением операционных систем – там собрать всю "критику" в столь малое количество сложно, лучше ориентироваться на 50 требований в одном стандарте. Старайтесь не вклю- чать в одно требование большие вло- женные списки подпунктов, например полсотни параметров аудита. Желатель- но ориентироваться на принцип "одно требование – одна настройка". Помимо количества, важно учитывать критичность. Если есть конкретные обя- зательные для исполнения требования (например, PCI DSS), в первую очередь берите их оттуда, чтобы не столкнуться с санкциями и штрафами. Далее стоит включить наиболее критичные элементы: парольную политику, управление досту- пами, логирование и аудит, шифрование, защиту данных и т.д., в зависимости от типа системы. Эти требования понятны администра- торам с точки зрения важности: никто не скажет, что не нужно настраивать парольную политику. От стандарта посильного объема и "без воды" у адми- нистратора системы не возникает ощу- тимого неприятия. По нашему опыту внедрения стандар- тов, стартуя с разумного количества требований и продвигаясь последова- тельно в их расширении, прийти к целе- вому значению можно гораздо раньше, чем скидывая в ИТ сотни требований по отдельной системе. Помните, что быстрая настройка даже самого базо- вого перечня наиболее важных конфи- гураций на всех или большинстве систем поможет значительно поднять общий уровень защищенности. Отлично, если при внедрении стандар- тов есть возможность автоматизировать работу специалистов ИБ и ИТ-админи- страторов – здесь стоит вернуться к вопро- су об альтернативах сканеру. В своих проектах мы используем собственную платформу "Кауч", решение набирающего обороты класса Security Configuration Management, которое предоставляет еди- ную среду для ИБ и ИТ, позволяя автома- тизировать всю техническую часть управ- ления безопасностью настроек. При нали- чии готовых команд и скриптов "из короб- ки", а также возможности настроить систе- му в пару кликов, ИТ-администраторы на практике справляются с освоением стан- дарта в десятки раз быстрее. Жизнь после первого стандарта: что дальше? Естественно, 30–50 настроек с гло- бальной точки зрения – лишь стартовая точка для выстраивания процесса, и нужно двигаться дальше. Отталкивайтесь от оценки прогресса: если, например, успешно кастомизированы 80% настроек на 80% хостов, то прогресс хороший и можно добавлять новые изменения. При этом проводить оценку необходимо по каждому типу систем и каждой группе ИТ-администраторов: в зависимости от сложности систем и количества настроек все могут двигаться с разной скоростью. Важно оценивать динамику и реагировать соответствующе: "отличникам" добавлять больше требований, "отстающим" – мень- ше; или даже отложить добавление до следующего пересмотра, а сейчас – выявить и устранить причины проблем. Как часто это делать? Почти все прак- тики и стандарты по управлению инфор- мационной безопасности – международ- ные и отечественные – требуют регу- лярного пересмотра политик. Рекомен- дуем оценивать прогресс один раз в три месяца или один раз в полгода. Союзники Еще один немаловажный фактор успе- ха при внедрении стандартов – насколь- ко хорошо вы "продали" это в ИТ. За безопасность ИТ-систем отвечает подразделение информационной без- опасности, именно на него возложена задача по управлению уязвимостями, в том числе связанными с настройками. Но исполнителем по ней является ИТ- подразделение, которое и без того пол- ностью загружено обязанностями по обеспечению работоспособности необхо- димых бизнесу систем. Проанализируйте, есть ли у вас уже выстроенные хорошие отношения внутри ИТ. Возможно, вы ранее плодотворно поработали с каким-то подразделени- ем на другом проекте. Начинайте внедрение стандартов именно с этими людьми с небольших пилотных проектов: если все пройдет хорошо, то получится показать результат и прорек- ламировать эту активность среди других подразделений. Если выстроенных отно- шений нет, ищите экспертов, которые могут быть заинтересованы в сотрудни- честве с вами: секьюрити-чемпионов, проявляющих инициативу по ИТ и ИБ энтузиастов, гиков, которым нравится разбираться в нюансах работы тех или иных систем. Успешный пример поможет с меньшими усилиями и более эффек- тивно вовлечь в процесс другие подраз- деления и ИТ-руководителей. От того, насколько сильно вы вложитесь на старте, будет зависеть дальнейший успех. Важно не быть "черным ящиком", выдающим указания: старайтесь объ- яснять на этапе согласования стандарта с точки зрения ИБ каждое требование, которое вызывает вопросы, разбирайтесь вместе в проблемах и трудных местах с конкретными администраторами. Проводите тестирование совместно с ИТ: помогайте консультативно в пре- делах компетенций в настройке тестовых систем, сразу идентифицируйте и обра- батывайте отклонения, собирайте обрат- ную связь и разбирайтесь в причинах конфликтов. Составляйте на основе полученных данных реально рабочие стандарты – копипасты из отчетов ска- неров и бенчмарков "не взлетят". Если резюмировать все упомянутые выше рекомендации, можно прийти к простому выводу: самой важной настройкой при разработке и внедрении стандартов станет настройка дружбы с ИТ. Остальное помогут решить здравый смысл и технологии. l • 25 Управление конфигУрациями www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ "КАУЧ" см. стр. 82 NM Реклама