Привет, Хабр.

Я Георгий Марков, архитектор сервисных проектов компании Инфосистемы Джет. В сервисе уже более 10 лет в различных ролях. За это время удалось поработать практически со всеми классами СЗИ и различными по величине инфраструктурами — от отдельных решений в небольших офисах до крупных территориально распределенных комплексов площадками по всей России и за ее пределами. В ходе работы я сталкивался с ситуациями, когда неплохо внедренные системы с годами переставали выполнять свои функции. На практике часть этих проблем возникает еще на моменте передачи системы после проекта внедрения во внутреннюю эксплуатацию.

Введение

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

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

Проблемные вопросы эксплуатации при передаче от команды внедрения

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

1. Недовнедренные СЗИ как попытка уйти от ответственности

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

Пример из практики №1:

Передавался после внедрения сканер уязвимостей. При этом в ТЗ требований по работе сканера уязвимостей не было, а проверяющую сторону устроила просто установленная система без приемочных тестов — в итоге группа эксплуатации получила сканер без единого шаблона. Когда заказчику потребовалось сканирование уязвимостей — ушло время на выяснение того, какие проверки требуются, и на настройку подобного профиля. Также при первом сканировании по большей части АРМ не было получено данных, пришлось заниматься диагностикой проблем. Корректное сканирование уязвимостей было выполнено только спустя месяцы с начала эксплуатации!

Что делать, когда видишь такой риск на практике.

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

2. Небезопасные настройки как выбор легкого пути при внедрении

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

Пример из практики № 2:

При передаче после внедрения двух шлюзов, связанных VPN-туннелем, из-за сложностей команды внедрения с сетевыми инженерами долго настраивался доступ к удаленному шлюзу. Но так как сроки сдачи подходили к завершению, был настроен прямой доступ по SSH к удаленному шлюзу. Впоследствии данный доступ не был закрыт, и система с такой настройкой была передана на сервис. Благо это было вовремя выявлено, и доступ к управлению системой извне был перекрыт.

Что делать, когда видишь такой риск на практике.

Для избежания подобных проблем во время проверки работоспособности систем также рекомендуется проверять систему на лучшие практики безопасной настройки, тем более, что многие вендоры имеют подобные гайды (hardening, best practice guides). В них как правило есть рекомендации, относящиеся к требованиям к УЗ, правам доступа, используемым протоколам и их версий, сетевой доступности интерфейсов управления, настройкам журналирования и прочим параметрам безопасности в зависимости от типа СЗИ и их настроек. Такие документы удобно использовать в дополнение к чеклистам проверки системы.

3. Несоблюдение требований системы

Бывает и обратный эффект. Получив систему, многие забывают, что у нее есть системные требования, что для системы рассчитывался сайзинг (ресурсный расчёт) для определенных модулей (например, сколько выделять места под хранилище).

Это приводит к тому, что производительность системы падает из-за высокой нагрузки, могут происходить подвисания или очереди, может заканчиваться место, иметь место превышение лицензионных лимитов. Данный тип проблемы довольно часто встречается на SIEM-системах, когда после внедрения администраторы, не глядя на систему, начинают добавлять много источников, превышая рамки EPS (количество событий, обрабатываемых системой в секунду).

Пример из практики №3:

Был случай, когда после длительного внедрения наконец запустили SIEM-систему. Через несколько месяцев произошел сбой. Причиной было переполнение места. При проверке выяснили, что был некорректно рассчитан сайзинг. Оказалось, что на момент выделения места были добавлены не все источники событий, но отталкивались в сайзинге от текущего размера разбиения данных — «партиций» событий. Естественно, после добавления всех необходимых событий, партиции разрослись почти в три раза, и вместо времени хранения в год нужно было ужиматься в гораздо меньший срок, а заказчику — жертвовать глубиной хранения до ввода дополнительных ресурсов (что также стало непредвиденными затратами).

Что делать, когда видишь такой риск на практике.

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

4. Отсутствие передачи знаний: «внедрили и забыли»

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

Пример из практики №4:

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

Что делать, когда видишь такой риск на практике.

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

Что в итоге делать — системный подход

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

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

Приведем пример чек-листа, который можно использовать при принятии системы от команды внедрения:

Отдельно хочется остановится на разделе из таблицы выше – «Состояние системы».

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

Результаты проверки стоит фиксировать, чтобы помнить данные состояния за определенное время. Если результат фиксировать в виде чеклиста, то его можно будет в будущем использовать для периодических проверок с отслеживанием изменений в системе со временем. Ниже приведен пример такого чеклиста. В нем — общие проверки, применимые к большинству СЗИ. Соответственно, потребуется его адаптация в зависимости от класса и архитектуры СЗИ.

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

Выводы

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

Что же происходит после и как сохранить работоспособность системы — разберем в следующей части.