Сбор данных об информационной системе

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

Основные задачи сбора данных

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

Выявление активов

Актив — это не только сервер или компьютер. Это любой ресурс, потеря, повреждение или компрометация которого ведёт к ущербу для организации. В российском контексте особый приоритет имеют ресурсы, содержащие персональные данные или сведения, составляющие служебную или государственную тайну.
Методика выявления активов требует системного подхода:

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

.

Анализ среды функционирования

Здесь важно перейти от списка к контексту. Где физически расположены активы? Как они связаны между собой? Ключевые аспекты для анализа:

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

Определение владельцев и ответственных лиц

У каждого значимого актива должен быть определён бизнес-владелец — лицо, которое несёт ответственность за его использование и может сформулировать требования к его доступности, целостности и конфиденциальности. Распространённая ошибка — назначать владельцем всех технических активов руководителя IT-отдела. Хотя он отвечает за работоспособность, реальную ценность актива и последствия его простоя знает руководитель бизнес-подразделения, которое этот актив использует.
Владелец актива формально утверждает его критичность, что в дальнейшем определяет строгость применяемых мер защиты, периодичность резервного копирования и требования к времени восстановления.

Оценка ценности и критичности

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

• Юридический: Риск штрафов со стороны регуляторов (Роскомнадзор, ФСТЭК) за нарушение требований 152-ФЗ, отраслевых стандартов или лицензионных соглашений.
• Операционный: Последствия простоя или нарушения работы актива. Остановка конвейера, сбой в расчёте зарплаты, недоступность клиентского сервиса.
• Финансовый: Прямые денежные потери (штрафы, выплаты компенсаций), затраты на восстановление, упущенная выгода.
• Репутационный: Ущерб имиджу компании, потеря доверия клиентов или партнёров.

Результатом становится матрица критичности, где активы распределены по уровням (например, высокий, средний, низкий). Это — основа для принципа соразмерности защиты.

Модель взаимоотношений в информационной безопасности

Чтобы управлять рисками осмысленно, собранные данные нужно связать в логическую модель. В её основе лежит классическая триада CIA (Конфиденциальность, Целостность, Доступность), адаптированная под российскую нормативную базу (ГОСТ Р ИСО/МЭК 27001, серия ГОСТ Р 57580).
Модель описывает причинно-следственные связи:

1. Владелец бизнес-процесса определяет ценность Активов и требования к их свойствам безопасности (CIA).
2. На эти свойства направлены Угрозы, источником которых является Нарушитель (внешний или внутренний).
3. Нарушитель реализует угрозу, используя Уязвимости в среде функционирования актива (ошибки в коде, неверные настройки, слабые пароли).
4. Чтобы разорвать эту цепь, внедряются Средства защиты информации (контрмеры) — как технические (СКЗИ, МЭ, DLP), так и организационные (регламенты, обучение, политики).

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

.

Анализ угроз безопасности

На этом этапе абстрактные риски переводятся в конкретные сценарии, которые можно оценить и против которых можно подбирать защиту.

Источники и сценарии угроз

Угрозы систематизируются по источнику:

• Внешние злоумышленники: От автоматизированных ботов, сканирующих интернет на наличие стандартных уязвимостей, до целевых атакующих группировок (APT). Для объектов КИИ особенно важна оценка мотивации и возможностей таких групп.
• Внутренние нарушители: Включают как умышленные действия нелояльных сотрудников (кражу данных перед увольнением), так и непреднамеренный вред из-за халатности или недостаточной компетенции. Риск от сотрудника, который обходит DLP-систему «для удобства работы», часто недооценивают.
• Техногенные факторы и уязвимости ПО: Отказы оборудования, ошибки в конфигурации, использование неподдерживаемых версий программного обеспечения с известными, но не закрытыми уязвимостями. Сюда же относятся риски, связанные с цепочкой поставок (закладки в оборудовании, уязвимости в библиотеках).

Результаты анализа

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

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

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

Разработка отчёта и выбор средств защиты информации (СЗИ)

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

Критерий	Что оценивать
Нормативное соответствие	Наличие действующих сертификатов ФСТЭК, ФСБ для требуемого класса защищённости. Включение в реестр отечественного ПО. Соответствие требованиям приказов ФСТЭК для конкретных типов систем.
Функциональное покрытие угроз	Способность средства эффективно противостоять сценариям угроз из составленного профиля. Например, может ли система обнаружения вторжений выявлять атаки, специфичные для используемого в организации ПО.
Интеграция в существующую среду	Совместимость с операционными системами, системами виртуализации, сетевым оборудованием. Наличие открытых API для интеграции с SIEM и другими элементами контура управления безопасностью.
Эксплуатационные качества	Влияние на производительность защищаемых систем, удобство управления, требования к квалификации администраторов, качество технической поддержки и документации.
Экономическая эффективность	Расчёт полной стоимости владения (Total Cost of Ownership — TCO) на весь жизненный цикл: лицензии, обновления, обучение, сопровождение. Сопоставление TCO с величиной предотвращаемого ущерба.

Программа создания системы информационной безопасности (СИБ)

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

1. Обследование и моделирование (текущий этап): Формирование модели защищаемой системы, модели угроз и требований к защите.
2. Проектирование архитектуры СИБ: Разработка технических решений, определение точек установки СЗИ, проектирование организационных мер (политик, регламентов).
3. Разработка документированной подсистемы управления: Создание полного комплекта организационно-распорядительной документации: политик, процедур, инструкций для пользователей и администраторов, планов реагирования на инциденты.
4. Внедрение и опытная эксплуатация: Поэтапное развёртывание технических средств, обучение персонала, настройка процессов.
5. Мониторинг, поддержка и совершенствование: Эксплуатация системы, регулярный аудит и пересмотр модели угроз, обновление средств защиты в соответствии с изменяющейся обстановкой.

Технико-экономическое обоснование

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

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

Расчёт совокупной стоимости владения (TCO): Помимо первоначальной закупки, необходимо учесть все сопутствующие расходы на горизонте 3-5 лет:

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

Часто именно эксплуатационные расходы, а не цена лицензии, становятся решающим фактором при выборе между решениями.

Тестирование решений СЗИ

Прежде чем принимать решение о масштабном внедрении, выбранные средства защиты необходимо проверить в условиях, максимально приближённых к реальным. Глубина тестирования может варьироваться.

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

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

Итоги этапа

Качественно проведённый сбор и анализ данных об информационной системе трансформируется из рутинной процедуры в стратегический актив. На выходе организация получает не просто отчёт, а динамическую модель своей цифровой среды с чётко расставленными приоритетами защиты. Эта модель служит объективной основой для:

• Обоснованного бюджетирования и планирования закупок СЗИ.
• Построения диалога с регуляторами на языке конкретных рисков и контрмер.
• Построения системы безопасности, которая не имитирует бурную деятельность, а целенаправленно и измеримо снижает реальные риски бизнеса.

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