Проект

Общее

Профиль

Действия
История

Wiki » ISM »

Создание СУИБ на предприятии

Введение

Предыдущие темы курса заложили теоретическую базу: мы разобрали понятия ИБ, классифицировали угрозы, изучили оценочные стандарты и стандарты управления, освоили методологию оценки рисков. Эта тема — практическая: как всё это превратить в работающую систему на конкретном предприятии.

Создание СУИБ — не разовый проект, а переход организации в новый режим работы.
Именно поэтому стандарт ISO 27001 делит путь на два принципиально разных этапа:
разработку (что и как должно работать) и внедрение (запуск в реальных условиях).

Эта тема опирается на методологию управления рисками из 5. Управление рисками ИБ и нормативную базу из 4. Стандарты управления. Результат — СУИБ, готовая к сертификации по ISO 27001.

Два этапа и роль руководства

Создание СУИБ делится на два этапа с принципиально разными исполнителями.

Этап Кто выполняет Результат
Разработка системы управления и всех необходимых процедур Внутренние специалисты + внешние консультанты Задокументированная система: политики, методики, реестры, SOA
Внедрение системы управления Сама компания Работающие процессы, обученный персонал, функционирующие контроли

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

Роль руководства — не формальная. Это не подписать политику и забыть. Все сотрудники должны видеть: руководство инициировало программу ИБ, лично контролирует её функционирование и само соблюдает те же правила, что и рядовые сотрудники. Без этого СУИБ превращается в набор бумаг, которые никто не читает.

Вовлечённость руководства — одно из ключевых требований ISO 27001 (раздел 5). Стандарт прямо указывает: высшее руководство должно демонстрировать лидерство и приверженность СУИБ, а не просто делегировать её IT-отделу.

Определение области действия СУИБ

Прежде чем что-либо строить, нужно ответить на вопрос: что именно входит в СУИБ?

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

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

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

Этапы разработки СУИБ

Шаг 1. Инвентаризация активов

Инвентаризация — составление реестра всего, что имеет ценность для организации с точки зрения ИБ. Без понимания того, что защищаем, невозможно ни оценить риски, ни выбрать контроли.

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

Категория актива Примеры Кто обычно владелец
Информационные ресурсы Базы данных клиентов, финансовая отчётность, контракты, ПДн Руководители бизнес-подразделений
Программное обеспечение ERP-система, ОС, средства защиты, разработанный код IT-директор, руководители проектов
Материальные активы Серверы, рабочие станции, сетевое оборудование, носители IT-служба
Сервисы Интернет-канал, облачные платформы, электроснабжение IT-служба, АХО
Персонал Сотрудники с уникальными знаниями и критичными правами доступа HR, руководители подразделений
Репутация Бренд, доверие клиентов, имидж на рынке Топ-менеджмент

Инвентаризацию выполняют владельцы активов, а не IT-отдел. Только владелец знает реальную ценность и критичность актива для своего бизнес-процесса.

Шаг 2. Категорирование активов

Категорирование — оценка критичности каждого актива по трём параметрам триады КДЦ:
какой ущерб понесёт компания при нарушении конфиденциальности, целостности или доступности данного актива.

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

Практические принципы оценки по типам активов:

Информационные активы оцениваются по ущербу от раскрытия, модификации или недоступности в течение определённого времени.

ПО, оборудование и сервисы оцениваются прежде всего по доступности: какой ущерб понесёт компания при нарушении их работоспособности. Например, отказ системы кондиционирования серверной на трое суток → отказ серверов → недоступность сервисов → измеримые финансовые потери.

Персонал оценивается по трём измерениям: доступ к информации (конфиденциальность), полномочия на изменение данных (целостность), доступность сотрудника для выполнения критичных операций (доступность). Ключевые параметры — уникальность компетенций и объём критичных прав доступа.

Репутация оценивается косвенно: какой репутационный ущерб нанесёт инцидент ИБ (утечка данных клиентов, публичный взлом, штраф регулятора).

При выборе шкалы оценки важен баланс:
3-уровневая шкала проста, но груба;
10-уровневая точнее, но разница между уровнями 7 и 8 становится неочевидной.
Оптимум для большинства организаций — 3–5 уровней.

Шаг 3. Оценка защищённости информационной системы

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

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

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

Классификация угроз и методы их выявления подробно рассмотрены в теме 2. Угрозы. Каталоги STRIDE и MITRE ATT&CK используются именно на этом шаге.

Шаг 4. Оценка информационных рисков

Имея данные о критичности активов и вероятности реализации уязвимостей, рассчитываем риски по формуле:

R = D × P(V)

где R — информационный риск, D — критичность актива (ущерб), P(V) — вероятность реализации уязвимости.

Результаты оформляются в «Отчёт об оценке информационных рисков» и реестр рисков.

Методология расчёта рисков (качественная матрица 5×5 и количественные метрики SLE/ARO/ALE) детально рассмотрена в теме 5. Управление рисками ИБ.

Шаг 5. Обработка информационных рисков

По результатам оценки для каждого риска выбирается стратегия обработки. Сначала определяется приемлемый уровень риска — пороговое значение, утверждённое руководством. Риски ниже порога принимаются. Риски выше порога требуют обработки.

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

По итогам составляется «План снижения рисков»: конкретные меры, ответственные
сотрудники, сроки реализации, метрики проверки эффективности.

Шаг 6. Положение о применимости (SOA)

Положение о применимости (SOA) — обязательный документ для сертификации по ISO 27001. Это итоговое решение организации о том, какие контроли из Приложения А стандарта применяются, а какие — нет, и почему.

SOA содержит все 93 контроля (в редакции ISO 27001:2022) с указанием для каждого:
  • применяется ли контроль в организации;
  • если применяется — какими документами и процедурами реализован;
  • если не применяется — обоснование исключения (например, отсутствие соответствующей угрозы по результатам оценки рисков).

SOA — главный документ, который аудитор изучает в первую очередь. Он связывает результаты оценки рисков с конкретными контролями и доказывает осознанность принятых решений. Без SOA сертификация невозможна.

Шаг 7. Документирование процедур

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

Документация СУИБ строится в виде четырёхуровневой пирамиды:

Уровень 1 — политики. Политика ИБ определяет цели и принципы. SOA фиксирует выбранные контроли. Эти документы утверждаются руководством.

Уровень 2 — регламенты и положения. Описывают организационные структуры, процессы и ответственность. Примеры: положение о комитете ИБ, регламент управления доступом, регламент управления инцидентами.

Уровень 3 — инструкции и методики. Пошаговые руководства для исполнителей.

Типовой перечень:

  • инструкция пользователя по ИБ;
  • инструкция системного администратора по ИБ;
  • инструкция администратора безопасности;
  • инструкция по управлению доступом пользователей;
  • инструкция по защите от вредоносного ПО;
  • инструкция по резервному копированию;
  • инструкция по обращению со съёмными носителями;
  • инструкция по использованию СКЗИ;
  • инструкция по управлению инцидентами ИБ;
  • методика инвентаризации и категорирования активов;
  • методика оценки и обработки рисков;
  • план непрерывности бизнеса и план восстановления (BCP/DRP).

Уровень 4 — записи и журналы. Доказательства того, что процедуры реально выполняются: журналы аудита, отчёты об инцидентах, записи об обучении, протоколы аудиторских проверок.

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

Обучение персонала как контроль снижения рисков

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

Основные инструменты работы с персоналом:
  • базовый курс ИБ для всех новых сотрудников при найме;
  • ежегодное повторное обучение с тестированием;
  • ролевые курсы для IT-администраторов, разработчиков, финансистов;
  • симуляции фишинговых атак для проверки реальной осведомлённости;
  • инструктаж при изменении должностных обязанностей или прав доступа.

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

Обучение персонала — контроль из Приложения А ISO 27001 (тема «Контроли в отношении персонала»). Его применение должно быть отражено в SOA и подкреплено записями о прохождении обучения.

Внедрение СУИБ: от документов к практике

Система считается внедрённой — а не просто разработанной — когда все её процедуры прошли как минимум один полный цикл PDCA и реальная практика соответствует документации. Это означает: процедуры работают не потому что написаны, а потому что сотрудники их понимают, выполняют и получают обратную связь по результатам.

Типичная последовательность внедрения:

  1. Информирование — довести до каждого сотрудника его роль и обязанности в СУИБ.
  2. Запуск процедур — поочерёдный ввод процедур в действие с фиксацией первых записей.
  3. Контроль выполнения — регулярные проверки: процедуры выполняются фактически, а не только на бумаге.
  4. Внутренний аудит — независимая проверка соответствия практики документации. Обязательное требование ISO 27001 перед сертификацией.
  5. Анализ со стороны руководства — топ-менеджмент рассматривает результаты аудита и принимает решения об улучшении системы.
  6. Корректирующие действия — устранение выявленных несоответствий.

Систему управления ИБ можно считать готовой к сертификационному аудиту тогда, когда все процедуры прошли цикл PDCA, внутренний аудит завершён, несоответствия устранены, а руководство провело анализ системы.

Что дальше

Созданная СУИБ требует правовой поддержки и организационных мер — без них техническая система не имеет юридической силы и не защищает от ответственности.

Список литературы и стандартов

Обновлено С. Антошкин 16 дня назад · 10 изменени(я, ий)