Основы информационной безопасности

Ландшафт угроз и базовые принципы ИБ

Зачем нужна информационная безопасность

Информационная безопасность (ИБ) защищает конфиденциальность, целостность и доступность информации и систем. Это нужно, чтобы:

не допустить утечек персональных и коммерческих данных

предотвратить подмену данных и мошенничество

обеспечить работу сервисов без простоев

выполнять требования законодательства и договоров

В этом курсе мы будем идти от понимания угроз и рисков к практическим мерам защиты (политики, процессы, технические контрмеры).

Что именно мы защищаем

В ИБ защищают не только «файлы» или «серверы». Обычно выделяют активы:

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

учетные записи и права доступа

инфраструктура: рабочие станции, серверы, сеть, облака

приложения и API

процессы: бизнес-операции, цепочки поставок, взаимодействие с подрядчиками

репутация и доверие пользователей

Важно: актив почти всегда связан с владельцем (кто отвечает) и ценностью (какой ущерб будет при инциденте).

Ландшафт угроз: кто атакует и почему

Угрозы различаются по мотивации и возможностям.

Основные типы нарушителей

киберпреступники: деньги (вымогательство, кража средств, продажа данных)

внутренние нарушители: злоупотребление доступом или ошибки сотрудников

хактивисты: идеологические мотивы, публичность

конкуренты и промышленный шпионаж: получение преимуществ

государственные группы: разведка, влияние, саботаж

Типовые цели атак

учетные данные (логины, пароли, токены)

персональные данные и базы клиентов

платежная инфраструктура

критичные сервисы (чтобы остановить работу)

исходный код, интеллектуальная собственность

!Схема показывает основные группы атакующих и их типичные мотивы и цели.

Базовые свойства безопасности: конфиденциальность, целостность, доступность

Классическая модель ИБ — три свойства (часто называют триадой CIA):

Конфиденциальность: доступ к данным получают только те, кому разрешено

Целостность: данные не изменяются незаметно и не подменяются

Доступность: системы и данные доступны тогда, когда нужны

Одна и та же атака может бить по нескольким свойствам. Например, шифровальщик нарушает доступность, а утечка перед шифрованием — еще и конфиденциальность.

Что такое угроза, уязвимость, атака и риск

Чтобы говорить об ИБ предметно, важно различать термины:

Угроза: потенциальная причина инцидента (например, фишинг)

Уязвимость: слабое место, которое можно использовать (например, отсутствие MFA)

Атака/воздействие: конкретное действие злоумышленника (например, вход в аккаунт по украденному паролю)

Риск: ожидаемый ущерб с учетом вероятности и последствий

Упрощенная логика такая:

есть актив (что защищаем)

есть угроза (что может случиться)

есть уязвимость (почему это возможно)

получаем риск (что будет и насколько это вероятно)

выбираем меры защиты (как снизить риск)

Для терминов полезен глоссарий NIST: NIST Computer Security Resource Center Glossary.

Поверхность атаки и точки входа

Поверхность атаки — все, через что можно повлиять на систему извне или изнутри. Типовые точки входа:

электронная почта и мессенджеры (фишинг, вложения, ссылки)

веб-приложения и API (ошибки авторизации, инъекции, логические уязвимости)

удаленный доступ (VPN, RDP, SSH, панели администрирования)

облачная конфигурация (публичные бакеты, избыточные права, утечки ключей)

цепочка поставок (компрометация подрядчиков, обновлений, библиотек)

физический доступ (украденные устройства, незаблокированные рабочие места)

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

Типовые классы угроз и примеры

| Класс угроз | Как выглядит на практике | Что обычно страдает | |---|---|---| | Социальная инженерия | фишинговые письма, звонки «службы безопасности», поддельные страницы входа | конфиденциальность, деньги | | Вредоносное ПО | шифровальщики, трояны, бэкдоры | доступность, конфиденциальность | | Компрометация учетных данных | подбор пароля, утечки, повторное использование паролей | конфиденциальность, целостность | | Уязвимости приложений | ошибки авторизации, небезопасные API, инъекции | все три свойства | | Неверная конфигурация | открытые порты, публичные хранилища, «admin/admin» | конфиденциальность | | DDoS | перегрузка сервиса трафиком | доступность | | Внутренние инциденты | удаление данных, копирование баз, обход процедур | целостность, конфиденциальность |

Для понимания распространенных проблем веб-приложений полезен список: OWASP Top 10.

Базовые принципы построения защиты

Принципы помогают не «настроить один раз», а выстроить устойчивую систему.

Управление рисками вместо «защиты от всего»

ИБ почти всегда про выбор: ресурсы ограничены. Поэтому организации:

определяют критичные активы

оценивают риски и приоритизируют их

выбирают меры: снизить риск, избежать, передать (например, страховка), принять

Ориентир по структуре работы с ИБ на уровне организации: NIST Cybersecurity Framework.

Многоуровневая защита

Идея defense in depth: если один рубеж не сработал, следующий остановит атаку или снизит ущерб.

Примеры уровней:

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

идентификация и доступ: MFA, принцип наименьших привилегий

сеть: сегментация, фильтрация, VPN по необходимости

конечные устройства: обновления, EDR/антивирус, шифрование диска

приложения и данные: безопасная разработка, резервные копии, DLP

мониторинг: журналы, SIEM, реагирование на инциденты

!Иллюстрация показывает, что защита строится слоями, а не одной мерой.

Принцип наименьших привилегий

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

Практические следствия:

роли вместо «универсального доступа»

отдельные админ-аккаунты для администрирования

регулярная ревизия прав и удаление лишнего

Надежная идентификация и MFA

Пароль сам по себе часто недостаточен. Многофакторная аутентификация (MFA) снижает риск захвата аккаунта даже при утечке пароля.

Важно понимать разницу:

аутентификация: доказать, кто ты

авторизация: что тебе можно

Безопасная конфигурация и обновления

Большая часть массовых атак использует либо известные уязвимости, либо ошибки настроек.

Базовые практики:

регулярные обновления ОС, приложений, сетевого оборудования

отключение неиспользуемых сервисов и портов

запрет «дефолтных» паролей

стандарты конфигураций и проверка соответствия

Резервное копирование и готовность к инцидентам

Даже при хорошей защите инциденты случаются. Поэтому нужны:

резервные копии (включая защищенные от удаления и шифрования)

план реагирования (кто и что делает при инциденте)

журналы и мониторинг, чтобы заметить атаку

Отчет Verizon помогает понять, какие инциденты наиболее распространены: Verizon Data Breach Investigations Report.

Как злоумышленники действуют: краткая модель стадий атаки

Удобно мыслить не отдельными «хаками», а цепочкой действий:

разведка и выбор цели

первичное проникновение (например, фишинг)

закрепление и повышение привилегий

перемещение внутри сети

достижение цели (кража данных, шифрование, саботаж)

сокрытие следов

Для систематизации тактик и техник атак используют базу знаний: MITRE ATT&CK.

Итоги

ИБ защищает конфиденциальность, целостность и доступность активов.

Угрозы реализуются через уязвимости; результат выражается в риске.

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

Понимание ландшафта угроз помогает выбирать меры, которые реально снижают риск.

Уязвимости, атаки и модели угроз

Как эта тема связана с предыдущей статьей

В статье «Ландшафт угроз и базовые принципы ИБ» мы разобрали, кто атакует, что защищаем, и почему защита строится вокруг рисков, многоуровневости и принципа наименьших привилегий.

Теперь сфокусируемся на трех практических вопросах:

где именно возникают уязвимости

как уязвимости превращаются в атаки

как заранее системно выявлять слабые места с помощью модели угроз

Уязвимость, эксплойт, атака, инцидент

Чтобы одинаково понимать процесс, разделим термины.

Уязвимость: слабое место в системе, которое можно использовать (например, отсутствие проверки прав доступа).

Эксплойт: способ или код, который использует уязвимость (например, последовательность запросов, позволяющая обойти авторизацию).

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

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

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

Откуда берутся уязвимости

Уязвимости появляются не только из-за «ошибок программистов». Чаще всего причины системные.

Основные источники

ошибки проектирования: небезопасная архитектура, неверные допущения о доверии

ошибки реализации: баги в коде и логике

уязвимые зависимости: библиотеки и компоненты с известными проблемами

неверная конфигурация: открытые доступы, дефолтные пароли, лишние права

ошибки процессов: отсутствие ревью, тестирования, управления изменениями

человеческий фактор: фишинг, повторное использование паролей, игнорирование процедур

Классификация уязвимостей

Для веб-приложений и API полезно ориентироваться на OWASP Top 10: OWASP Top 10.

Примеры категорий (упрощенно):

сломанная авторизация: доступ к чужим данным

инъекции: выполнение непредусмотренных команд или запросов

утечки данных: отсутствие шифрования, неправильные права

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

уязвимые компоненты: использование библиотек с известными CVE

Как уязвимости находят и описывают

Идентификаторы CVE и базы уязвимостей

Во многих случаях уязвимость получает идентификатор CVE (Common Vulnerabilities and Exposures). Это удобный способ ссылаться на проблему однозначно.

Полезные источники:

CVE Program

NIST National Vulnerability Database

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

Часто уязвимости сопровождаются оценкой CVSS (Common Vulnerability Scoring System), которая помогает приоритизировать исправления.

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

Как уязвимость превращается в атаку

Переход от «слабого места» к ущербу обычно проходит через цепочку шагов.

!Иллюстрация показывает, как уязвимость через вектор и эксплойт приводит к последствиям

Вектор атаки

Вектор атаки — путь, по которому атакующий добирается до уязвимости.

Типовые векторы:

интернет-доступные сервисы и API

фишинг через почту и мессенджеры

удаленный доступ (VPN, RDP, SSH)

цепочка поставок (компоненты, обновления, подрядчики)

физический доступ к устройствам

Условия эксплуатации

Даже при наличии уязвимости атакующему часто нужны условия:

сетевой доступ к компоненту

учетная запись определенного уровня

знание внутренней структуры (эндпоинты, форматы)

возможность обойти мониторинг

Часть этих условий снижается многоуровневой защитой: сегментацией, принципом наименьших привилегий, MFA, ограничением админ-панелей.

Zero-day и n-day

Zero-day: уязвимость, для которой нет общедоступного патча или она неизвестна защитникам.

n-day: уязвимость уже известна и обычно есть обновление, но система не пропатчена.

На практике многие массовые инциденты связаны именно с n-day: исправление есть, но не установлено.

Риск как связующее звено между уязвимостями и мерами

Риск удобнее всего объяснять как сочетание вероятности и ущерба.

Часто используют простую модель:

Где:

— итоговый риск (насколько проблема важна)

— вероятность (насколько реально, что уязвимость будет использована именно у вас)

— последствия (что вы потеряете при успешной атаке)

Это не «точная математика», а способ структурировать обсуждение и приоритизацию. Две одинаковые уязвимости по CVE могут иметь разный риск в разных системах.

Модель угроз: зачем и когда нужна

Модель угроз — это структурированный способ заранее ответить на вопросы:

какие активы и сценарии использования нужно защитить

кто может атаковать и какими путями

какие угрозы реалистичны в рамках архитектуры

какие меры снизят риск до приемлемого уровня

Модель угроз особенно полезна:

на этапе проектирования новой системы

при существенных изменениях архитектуры (новый сервис, внешняя интеграция)

при подключении подрядчиков и поставщиков

после серьезного инцидента, чтобы закрыть системные причины

Базовый процесс моделирования угроз

Процесс можно сделать легким и регулярным, без «больших документов».

Определить границы

- что входит в систему, а что считается внешним

Составить инвентаризацию активов

- данные, учетные записи, ключи, критичные функции

Нарисовать поток данных

- кто кому и какие данные передает, где хранятся, где шифруются

Определить границы доверия

- где меняется уровень доверия, например между интернетом и внутренней сетью

Выявить угрозы и сценарии атак

- «что может пойти не так» на каждом шаге потока

Оценить риск и выбрать контрмеры

- что исправляем сразу, что откладываем, что принимаем

Зафиксировать решения и допущения

- что считаем допустимым риском и почему

STRIDE как удобная шпаргалка

Один из распространенных подходов к перечислению угроз — STRIDE от Microsoft:

Spoofing: подмена личности

Tampering: подмена данных

Repudiation: отказ от совершенных действий

Information Disclosure: раскрытие информации

Denial of Service: отказ в обслуживании

Elevation of Privilege: повышение привилегий

Источник: Microsoft STRIDE threat model).

STRIDE удобно использовать как чек-лист: пройтись по компонентам и спросить, возможен ли каждый тип угроз.

Пример: мини-модель угроз для веб-сервиса

Представим сервис: пользователь заходит в личный кабинет, сервис хранит профиль и историю заказов, есть админ-панель.

Активы

персональные данные профиля

учетные записи пользователей и администраторов

база заказов

токены сессий и API-ключи

Типовые угрозы (по смыслу STRIDE)

подмена личности: кража сессии, фишинг, подбор пароля

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

подмена данных: изменение адреса доставки или статуса заказа

отказ в обслуживании: перегрузка публичных эндпоинтов

повышение привилегий: ошибка в ролях, доступ к админ-функциям

Контрмеры

MFA для админов и сотрудников, защита от подбора паролей

принцип наименьших привилегий и строгие проверки авторизации на уровне API

шифрование данных и секретов, безопасное хранение ключей

журналирование действий и мониторинг аномалий

лимиты запросов и базовая DDoS-защита

регулярные обновления и проверка зависимостей

Здесь видно связь с базовыми принципами из предыдущей статьи: многоуровневая защита и управление рисками превращают модель угроз в конкретный план работ.

Связка «уязвимость → атака → контроль»

| Уязвимость или слабость | Какой атакой обычно пользуются | Что помогает защититься | |---|---|---| | слабые пароли, нет MFA | захват аккаунта через утечку или подбор | MFA, политики паролей, защита от перебора | | ошибка авторизации в API | чтение или изменение чужих данных | проверки прав на каждом запросе, тесты, ревью | | уязвимая библиотека | удаленное выполнение кода, утечки | обновления, SCA-сканирование зависимостей | | публичное хранилище в облаке | скачивание базы или бэкапов | безопасная конфигурация, IAM, аудит | | нет сегментации сети | боковое перемещение после проникновения | сегментация, ограничение east-west трафика |

Итоги

Уязвимость — слабое место, эксплойт — способ его использовать, атака — действия для достижения цели, инцидент — факт или риск нарушения безопасности.

Важен контекст: критичность уязвимости по CVSS не равна риску для конкретной организации.

Модель угроз позволяет заранее увидеть реалистичные сценарии атак и привязать их к мерам защиты.

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

Технические меры защиты: сети, системы, данные

Связь с предыдущими темами

В прошлых статьях мы разобрали ландшафт угроз, базовые принципы (CIA, риск-ориентированный подход, многоуровневая защита), а также связку уязвимость → атака → контроль и практику моделирования угроз.

Технические меры защиты — это конкретные настройки и инструменты, которые:

уменьшают вероятность успешной атаки

ограничивают ущерб при компрометации

помогают обнаружить и расследовать инцидент

Важно: технические меры работают лучше всего, когда они привязаны к модели угроз и приоритетам рисков, а не внедряются «по списку».

!Наглядно показывает принцип defense in depth на уровне технических мер

Как выбирать технические меры

Технические меры удобнее рассматривать как ответы на вопросы:

Где атакующий может войти? (точки входа и поверхность атаки)

Что он сможет сделать после входа? (права, сегментация, доступ к данным)

Как быстро мы это заметим? (логи, детектирование)

Как быстро восстановимся? (резервные копии, планы)

Практический ориентир для набора базовых контролей: CIS Critical Security Controls v8.

Защита сети

Сетевой уровень отвечает за контроль путей, по которым трафик может попасть к системам, и за ограничение перемещения злоумышленника внутри инфраструктуры.

Сегментация и изоляция

Сегментация сети — разделение инфраструктуры на зоны с разным уровнем доверия (например, пользовательская зона, серверная зона, зона администрирования).

Что это дает:

снижает риск бокового перемещения (lateral movement)

позволяет применять разные правила доступа для разных типов систем

уменьшает площадь поражения при компрометации одного узла

Типовая схема зон:

DMZ для публичных сервисов

отдельная зона для баз данных

отдельная зона для администрирования (jump host, bastion)

отдельные сегменты для рабочих станций и серверов

!Показывает идею зон доверия и минимально необходимых сетевых связей

Межсетевые экраны и фильтрация

Межсетевой экран (firewall) — устройство или сервис, который разрешает или запрещает сетевые соединения по правилам.

Базовые практики:

запрет по умолчанию (разрешаем только необходимое)

минимизация открытых портов и адресов

контроль исходящего трафика (egress filtering), чтобы усложнить утечки и связь с командными серверами

Защита периметра приложений

Если у вас есть веб-сервисы, часто применяют:

WAF (Web Application Firewall): помогает от типовых веб-атак на уровне HTTP (но не заменяет исправление уязвимостей)

защита от ботов и ограничение частоты запросов (rate limiting)

Материал по базовым классам веб-угроз хорошо систематизирован в OWASP Top 10.

Удаленный доступ

Удаленный доступ — частая точка входа.

Технические меры:

VPN или ZTNA-решение с жесткой аутентификацией

MFA для удаленного доступа

запрет прямого доступа к админ-интерфейсам из интернета

доступ администраторов через выделенный bastion/jump host

Защита DNS и почты (как сетевой слой)

Многие атаки начинаются с доставки.

DNS-фильтрация может блокировать известные вредоносные домены

для почты важны SPF/DKIM/DMARC, чтобы снизить подделку домена отправителя

Официальный обзор DMARC: RFC 7489.

Защита систем и конечных устройств

Этот блок про то, чтобы хосты были сложнее взломать, а компрометацию было проще заметить.

Управление обновлениями и устранением уязвимостей

Большая доля атак использует известные уязвимости (n-day). Техническая основа защиты здесь:

инвентаризация активов (что у вас реально установлено)

централизованное управление патчами

окна обновлений и быстрые процедуры для критических патчей

контроль версий и запрет «самовольных» установок на серверах

Оценка уязвимостей и их контекст часто описываются через CVE и NVD: NIST National Vulnerability Database.

Безопасная конфигурация (hardening)

Hardening — приведение системы к безопасному минимуму: отключить лишнее, закрыть лишнее, ограничить права.

Типовые шаги:

отключение неиспользуемых служб

запрет устаревших протоколов и слабых шифров

ограничение локальных администраторов

контроль автозапуска и скриптов

стандартизированные образы (golden images)

Практический ориентир по бенчмаркам конфигурации: CIS Benchmarks.

Защита конечных точек: антивирус, EDR

EDR (Endpoint Detection and Response) — класс средств, которые собирают телеметрию с устройств и помогают обнаруживать подозрительные действия (например, запуск неизвестных процессов, попытки дампа учетных данных).

Важно понимать границы:

EDR снижает риск и ускоряет обнаружение, но не отменяет обновления и сегментацию

качество результата зависит от настроек, правил и реакции на алерты

Управление привилегиями на хостах

Связь с принципом наименьших привилегий проявляется технически:

отдельные админ-учетки и отдельные рабочие учетные записи

запрет входа админов на обычные рабочие станции без необходимости

ограничение использования sudo/локальных админ-групп

PIM/JIT (выдача привилегий на время) там, где это возможно

Журналы и время

Чтобы расследовать инциденты, нужны логи и корректное время.

Минимальный набор практик:

централизованный сбор логов (не только локально)

синхронизация времени (NTP) на серверах и рабочих станциях

защита логов от подмены и удаления (ограничение прав, неизменяемые хранилища)

Ориентир по семействам контролей (включая аудит и логирование): NIST SP 800-53 Rev. 5.

Защита данных

Техническая защита данных обычно отвечает на три вопроса:

Кто может прочитать данные? (доступ и шифрование)

Можно ли незаметно изменить данные? (целостность и аудит)

Можно ли восстановить данные? (резервное копирование)

Контроль доступа к данным

Даже сильное шифрование не спасет, если доступы выданы слишком широко.

разграничение прав на уровне БД, хранилищ и приложений

роли вместо индивидуальных «исключений»

регулярная ревизия прав (особенно у сервисных учетных записей)

Шифрование при передаче и хранении

Различают:

шифрование при передаче: защита данных по пути (обычно TLS)

шифрование при хранении: защита данных на дисках/в хранилищах

Практические акценты:

включать TLS на внешних и внутренних соединениях, где есть границы доверия

использовать управляемые механизмы шифрования дисков/томов/бакетов в облаке

понимать, где хранятся ключи, и кто имеет к ним доступ

Управление ключами и секретами

Секрет — чувствительное значение, которое дает доступ: пароль, токен, API-ключ, приватный ключ.

Критичные практики:

не хранить секреты в коде и в открытых конфигурациях

использовать хранилища секретов (secrets manager) или защищенные механизмы платформы

регулярная ротация ключей и токенов

минимальные права для сервисных учеток и ключей

Резервное копирование и восстановление

Резервные копии защищают доступность и часто целостность данных.

Что важно технически:

проверяемое восстановление (restore test), а не только факт создания бэкапа

изоляция бэкапов от основной инфраструктуры (чтобы шифровальщик не удалил копии)

неизменяемые хранилища (immutable backups) там, где возможно

документированные RPO/RTO (сколько данных можно потерять и за сколько восстановиться) как требования к системе

!Иллюстрирует, почему бэкапы должны быть изолированы и проверяемы

DLP и контроль утечек

DLP (Data Loss Prevention) — средства, которые помогают обнаруживать и блокировать попытки вывода чувствительных данных (почта, мессенджеры, веб, съемные носители).

Реалистичные ожидания:

DLP требует классификации данных и настройки правил, иначе будет много ложных срабатываний

DLP не заменяет доступы и шифрование, а дополняет их

Как связать меры с угрозами: краткая матрица

| Сценарий атаки | Типовая уязвимость/слабость | Технические меры, которые реально помогают | |---|---|---| | Захват учетной записи | нет MFA, слабые пароли, утечки | MFA, ограничение попыток входа, мониторинг аномалий, привилегии по минимуму | | Взлом через публичный сервис | не закрыт порт, нет патча, слабая конфигурация | firewall, патч-менеджмент, hardening, WAF (для веб), сегментация | | Боковое перемещение внутри сети | плоская сеть, общие админ-учетки | сегментация, отдельная зона администрирования, запрет избыточных прав, EDR | | Утечка данных из хранилища | публичный доступ, ключи утекли | IAM по минимуму, шифрование, секреты в хранилище, аудит доступа | | Шифровальщик | доступ к общим ресурсам и бэкапам | EDR, ограничение прав, изолированные неизменяемые бэкапы, сегментация |

Минимальный «базовый набор» технических мер

Если нужно начать с минимально полезного набора, который почти всегда снижает риск:

Инвентаризация активов и регулярные обновления.

MFA для администраторов и удаленного доступа.

Сегментация и закрытие лишних сетевых доступов.

Hardening типовых систем по стандарту.

Централизованные логи и мониторинг критичных событий.

Изолированные резервные копии с регулярной проверкой восстановления.

Управление секретами и запрет секретов в коде.

Итоги

Технические меры защиты эффективны, когда они привязаны к модели угроз и рискам.

На уровне сети ключевые идеи: минимум связности, сегментация, контроль удаленного доступа и защита периметра.

На уровне систем: патчи, hardening, управление привилегиями, EDR и логирование.

На уровне данных: контроль доступа, шифрование, управление секретами и проверяемые изолированные бэкапы.

Организационная безопасность и управление рисками

Связь с предыдущими темами курса

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

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

Центральная идея: риски определяют приоритеты, а процессы и роли делают защиту системной.

Что такое организационная безопасность

Организационная безопасность — это правила, роли, процессы и контроль исполнения, которые обеспечивают, что:

активы учтены и имеют владельцев

риски оцениваются и снижаются до приемлемого уровня

доступы выдаются и отзываются по понятным правилам

изменения делаются контролируемо

инциденты обнаруживаются, расследуются и приводят к улучшениям

подрядчики и поставщики не становятся “черным ходом”

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

Управление ИБ: роли и ответственность

Чтобы безопасность работала, ответственность должна быть распределена.

Типовые роли

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

владелец данных: определяет, кто и на каких условиях может обрабатывать данные

ИБ-специалист или команда ИБ: строит контролі, консультирует и контролирует соблюдение

ИТ/инфраструктура: реализует настройки и эксплуатационные процессы

разработка: отвечает за безопасную реализацию и исправление уязвимостей в продукте

служба поддержки: часто первая видит признаки инцидентов у пользователей

руководство: утверждает риск-аппетит и принимает остаточные риски

Принцип “безопасность — это ответственность бизнеса”

ИБ редко может “запретить риск” в одиночку. Важно, чтобы решение принять риск или финансировать его снижение принималось владельцем процесса или руководством.

Политики, стандарты, процедуры: чем они отличаются

Организационные документы удобно разделять по уровню.

политика: что организация считает обязательным и почему

стандарт: минимальные требования к реализации (например, “MFA для админов обязательна”)

процедура: как именно выполняется действие (например, шаги выдачи доступа)

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

Важно: документы должны быть исполняемыми. Если в политике написано “обновлять все быстро”, но нет сроков, владельцев и контроля, это не работает.

Управление рисками в ИБ

Риск — это вероятность того, что угроза реализуется через уязвимость, и последствия для организации.

Зачем нужна риск-ориентация

Ресурсы ограничены: невозможно одинаково защищать все. Управление рисками помогает:

выбрать, что защищать в первую очередь

обосновать бюджет и приоритеты работ

согласовать компромиссы между удобством, скоростью изменений и защитой

В качестве ориентира по управлению рисками часто используют:

NIST SP 800-30 Guide for Conducting Risk Assessments

ISO/IEC 27001

NIST Cybersecurity Framework

Риск-аппетит и критерии приемлемости

Риск-аппетит — это заранее определенный уровень риска, который организация готова принимать ради целей бизнеса.

Примеры того, как выражают критерии:

нельзя принимать риск, который может привести к остановке критичного сервиса дольше N часов

нельзя принимать риск утечки определенных классов данных

риски выше заданного уровня должны утверждаться руководителем

Базовый цикл управления рисками

!Цикл помогает понять, что управление рисками — это повторяющийся процесс

Практически цикл можно вести легковесно.

определить активы и владельцев

описать сценарии угроз, опираясь на модель угроз и реальную архитектуру

оценить вероятность и ущерб удобной шкалой

выбрать способ обработки риска

назначить задачи, сроки и ответственных

периодически пересматривать риски и качество контролей

Способы обработки риска

Обычно используют четыре варианта.

снизить риск: внедрить меры, которые уменьшают вероятность или ущерб

избежать риска: изменить процесс или архитектуру так, чтобы сценарий стал невозможен

передать риск: часть ответственности переносится (страхование, контрактные обязательства, аутсорсинг)

принять риск: осознанно оставить как есть, зафиксировав причины и владельца решения

Ключевой момент: принятие риска требует явного решения и понимания остаточного риска.

Контроли: как связать организационное и техническое

Контроли можно группировать по смыслу.

превентивные: уменьшают вероятность инцидента (MFA, сегментация, обучение)

детективные: помогают обнаружить (логи, алерты, SIEM, мониторинг)

корректирующие: уменьшают ущерб и ускоряют восстановление (план реагирования, бэкапы, отработанные процедуры)

В качестве базового набора практик часто используют CIS Critical Security Controls v8.

Управление активами и классификация данных

Без инвентаризации невозможно управлять рисками.

Инвентаризация активов

Нужно понимать:

какие системы существуют и где они размещены

какие данные обрабатываются и где они хранятся

какие внешние интеграции и подрядчики задействованы

какие учетные записи и ключи используются сервисами

Инвентаризация напрямую снижает риск “неизвестных” точек входа и упрощает патч-менеджмент.

Классификация данных

Классификация данных — это разделение данных на классы по чувствительности и требованиям.

Типовой подход:

публичные: можно раскрывать без ущерба

внутренние: не для публикации, но без строгих требований

конфиденциальные: утечка приводит к заметному ущербу

строго конфиденциальные: утечка критична, требуются усиленные меры

Классификация нужна, чтобы DLP, права доступа, шифрование и правила обмена данными были обоснованными, а не “для всего одинаково”.

Управление доступом как организационный процесс

Технические механизмы (IAM, MFA) должны поддерживаться процессами.

Жизненный цикл доступа

запрос доступа должен иметь владельца и обоснование

выдача должна соответствовать ролям и принципу наименьших привилегий

изменения роли сотрудника должны менять доступы

увольнение должно приводить к быстрому отзыву доступов

должна быть регулярная ревизия прав

Разделение обязанностей

Разделение обязанностей снижает риск злоупотреблений и ошибок.

Примеры:

разработчик не должен единолично выкатывать изменения в продакшн без контроля

администратор не должен иметь возможность незаметно отключать аудит и менять логи

финансовые операции должны требовать второго подтверждения

Управление изменениями и уязвимостями

Технические проблемы часто становятся инцидентами из-за слабых процессов.

Управление изменениями

Организационно важно:

фиксировать, что изменилось, зачем и кто одобрил

оценивать риск изменения до внедрения

иметь план отката

понимать, какие изменения экстренные, а какие плановые

Управление уязвимостями

Процесс обычно включает:

обнаружение: сканеры, отчеты поставщиков, мониторинг CVE

приоритизацию: по контексту и риску, а не только по баллу CVSS

исправление: патчи, конфигурации, временные компенсирующие меры

проверку: подтверждение, что проблема устранена

Управление инцидентами

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

План реагирования на инциденты

Минимум, который должен быть определен заранее:

что считается инцидентом и как его классифицировать

кто принимает решения и кто на связи 24/7 при необходимости

как собирать и сохранять доказательства

когда и как уведомлять руководство, клиентов и регуляторов

как организовать восстановление и пост-инцидентный разбор

Ориентир по построению процесса реагирования: NIST SP 800-61 Computer Security Incident Handling Guide.

Пост-инцидентные улучшения

Хорошая практика — завершать инцидент не только восстановлением, но и изменениями в системе.

исправление корневых причин

обновление модели угроз

обновление правил мониторинга и плейбуков

обучение на основе реального кейса

Управление рисками третьих сторон

Подрядчики, SaaS и поставщики — часть вашей поверхности атаки.

Что важно контролировать

доступ подрядчика: минимальный, ограниченный по времени и по сетевым путям

договорные обязательства: уведомления об инцидентах, требования к защите, право на аудит

точки интеграции: API-ключи, токены, сетевые каналы, доступ к данным

жизненный цикл: что происходит с доступами после завершения работ

!Иллюстрация помогает увидеть, где в цепочке поставок возникают риски

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

Многие инциденты начинаются с человека, но это не значит, что “виноват сотрудник”. Организации управляют этим риском через:

понятные правила и простые безопасные сценарии работы

регулярное обучение и симуляции фишинга

культуру сообщений об ошибках без страха наказания

отдельное обучение для администраторов, разработчиков и поддержки

Цель обучения — снизить вероятность успешной атаки и сократить время обнаружения.

Метрики и контроль исполнения

Без измерения безопасность превращается в декларации.

Примеры практичных метрик

доля активов с актуальными патчами

время установки критических обновлений

доля учетных записей с включенной MFA

количество “вечных” административных доступов

время обнаружения и время реагирования на инциденты

покрытие логированием критичных систем

успешность тестов восстановления из бэкапов

Метрики должны приводить к решениям: что улучшать и где риски остаются неприемлемыми.

Итоги

Организационная безопасность делает ИБ управляемой: через роли, политики, процессы и контроль исполнения.

Управление рисками помогает приоритизировать меры и согласовать риск-аппетит.

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

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

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

Мониторинг, инциденты и непрерывность бизнеса

Как тема связана с предыдущими статьями

Ранее мы разобрали:

ландшафт угроз и принципы (CIA, риск, defense in depth)

уязвимости, атаки и моделирование угроз

технические меры защиты (сети, системы, данные)

организационную безопасность и управление рисками

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

мониторинг: быстро заметить отклонения и атаки

реагирование на инциденты: локализовать, расследовать и восстановиться

непрерывность бизнеса: продолжить работу даже при серьезных сбоях

!Связь профилактики, мониторинга и реагирования в едином цикле

Мониторинг в ИБ: цель и базовые понятия

Мониторинг безопасности — это сбор и анализ событий, чтобы:

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

сокращать время до обнаружения

иметь доказательства и контекст для расследования

Чтобы избежать путаницы, разделим термины.

Событие: факт в системе (например, успешный вход, запуск процесса, изменение политики).

Инцидент: событие или набор событий, который привел или мог привести к нарушению безопасности.

Журнал (лог): запись о событии.

Телеметрия: более широкий набор данных, чем логи (например, сетевые потоки, события EDR, метрики).

Детект (правило обнаружения): логика, которая ищет подозрительные паттерны.

Полезный ориентир по построению процесса реагирования: NIST SP 800-61 Computer Security Incident Handling Guide.

Что именно мониторить: приоритизация по рискам

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

Критичные источники событий

Идентификация и доступ: входы в учетные записи, ошибки входа, изменения MFA, выдача/изменение прав.

Административные действия: создание пользователей, добавление в админ-группы, изменения политик.

Конечные точки: запуск подозрительных процессов, попытки выгрузки учетных данных, отключение защит.

Сеть: соединения к редким внешним адресам, аномалии DNS, сканирование портов, lateral movement.

Данные: массовые выгрузки, нетипичные запросы к БД, доступ к хранилищам, операции с резервными копиями.

Облако: изменения IAM, открытие публичного доступа к бакетам, создание ключей доступа.

Минимальный набор «сигналов», которые часто дают реальную пользу

вход администратора без MFA или обход MFA

множественные неуспешные попытки входа и последующий успех

создание нового ключа/токена доступа и сразу массовые запросы

запуск утилит, часто связанных с пост-эксплуатацией (дамп учетных данных, удаленное управление)

изменения политик логирования и отключение средств защиты

Архитектура мониторинга: от логов к SIEM

Сбор, нормализация и хранение

Чтобы мониторинг работал, важно обеспечить три свойства.

Полнота: нужные источники действительно отправляют события.

Целостность: события нельзя незаметно подменить или удалить.

Доступность: события можно быстро найти для расследования.

Практики, которые почти всегда нужны:

централизованный сбор логов (а не хранение только локально)

синхронизация времени на системах через NTP

контроль доступа к логам и настройкам логирования

Ориентир по управлению логами: NIST SP 800-92 Guide to Computer Security Log Management.

SIEM, SOAR, EDR: что за что отвечает

SIEM собирает события из разных источников, хранит, коррелирует, помогает искать.

SOAR помогает автоматизировать реакцию по плейбукам (например, блокировка учетной записи по сигналу).

EDR дает детальную телеметрию с рабочих станций и серверов и помогает реагировать на уровне хоста.

Важно: SIEM и EDR не заменяют друг друга. EDR сильнее на хостовых техниках, SIEM полезен для сквозной картины (IAM, сеть, приложения, облако).

Ложные срабатывания и качество детектов

Главная проблема мониторинга — не отсутствие событий, а качество сигналов.

Причины «шума»:

слишком общие правила

отсутствие базовой нормализации и контекста (кто это, откуда, какие права)

отсутствие белых списков для легитимной админ-активности

Практика улучшения:

вести каталог детектов (описание, источник, владелец, приоритет, как проверять)

после каждого инцидента улучшать правила и добавлять контекст

связывать детекты с техниками атак по MITRE ATT&CK

Реагирование на инциденты: жизненный цикл

Реагирование — это не «героическое тушение пожара», а управляемый процесс.

Удобно мыслить по стадиям (по смыслу NIST SP 800-61):

Подготовка

Обнаружение и анализ

Сдерживание, устранение и восстановление

Пост-инцидентные улучшения

!Основные этапы процесса Incident Response

Подготовка: что должно быть до инцидента

Без подготовки организация теряет время на самое дорогое — на координацию.

Минимальный набор:

определение, что считается инцидентом и уровни критичности

контакты и роли (кто принимает решения, кто делает технические действия, кто общается)

доступы для реагирования (включая экстренные процедуры)

плейбуки под частые сценарии

резервные копии и проверка восстановления

юридические и коммуникационные правила (уведомления, хранение доказательств)

Обнаружение и анализ: триаж и проверка гипотез

На этом этапе важно быстро ответить:

это реальная атака или ложное срабатывание

что затронуто: какие системы, учетные записи, данные

продолжается ли активность

Практичный формат работы — триаж:

подтвердить сигнал (сопоставить источники: SIEM, EDR, IAM, сеть)

оценить критичность (влияние на CIA, затронутые активы)

решить: эскалация, блокировка, наблюдение

Сдерживание, устранение и восстановление

Эти шаги часто путают, но цели разные.

Сдерживание: быстро остановить развитие (например, изолировать хост, заблокировать учетку, закрыть доступ).

Устранение: убрать причину (удалить вредоносное ПО, закрыть уязвимость, сменить ключи, исправить конфигурацию).

Восстановление: вернуть сервис в норму и убедиться, что атака не продолжается.

Типовые действия, которые важно уметь делать быстро:

принудительный сброс сессий и ротация токенов

сброс паролей и включение/усиление MFA

отзыв/ротация ключей и секретов

изоляция сегмента или узла

временные компенсирующие меры (например, отключение уязвимой функции)

Пост-инцидентные улучшения: закрываем системные причины

Если после инцидента «просто починили и забыли», вероятность повторения высока.

Что обычно фиксируют:

хронология событий (кто что увидел и когда)

root cause: первопричина (не только «кликнул по ссылке», а почему это привело к ущербу)

какие контроли не сработали или отсутствовали

какие улучшения нужны: патчи, сегментация, детекты, обучение, изменения в процессах

Плейбуки: как превратить реагирование в повторяемый процесс

Плейбук — это короткая инструкция для конкретного сценария: что проверяем, что делаем, кто утверждает.

Хороший плейбук содержит:

условия запуска (какой сигнал или какая заявка)

источники данных для проверки

шаги сдерживания (с учетом риска остановить бизнес)

шаги устранения и критерии завершения

список артефактов, которые нужно сохранить

кому и что сообщаем

Примеры сценариев, под которые почти всегда полезно иметь плейбуки:

компрометация учетной записи

заражение шифровальщиком

утечка ключей/секретов

взлом публичного веб-сервиса

подозрение на утечку данных из хранилища

Непрерывность бизнеса и восстановление после аварий

Инциденты ИБ часто превращаются в простой бизнеса. Поэтому безопасность тесно связана с BCP и DR.

Непрерывность бизнеса (Business Continuity): как продолжать критичные процессы при сбоях.

Восстановление после аварий (Disaster Recovery): как восстановить ИТ-сервисы после серьезного события.

Ориентир по управлению непрерывностью: ISO 22301.

RTO и RPO: как перевести «надо быстро восстановиться» в требования

Эти параметры задают реалистичные цели и компромиссы.

RTO (Recovery Time Objective): максимальное допустимое время простоя сервиса.

RPO (Recovery Point Objective): максимальная допустимая потеря данных по времени (насколько «старым» может быть восстановление).

Пример интерпретации:

RTO = 2 часа означает, что спустя 2 часа сервис должен быть восстановлен хотя бы в минимально рабочем виде.

RPO = 15 минут означает, что в худшем случае вы готовы потерять изменения за последние 15 минут.

Почему бэкапы — это часть ИБ, а не только ИТ

Шифровальщик и разрушительные атаки бьют по доступности и целостности. Поэтому бэкапы должны быть:

изолированными от основной инфраструктуры

защищенными от удаления и шифрования (по возможности immutable)

регулярно проверяемыми через тест восстановления

Ориентир по планированию восстановления: NIST SP 800-34 Contingency Planning Guide for Federal Information Systems.

План непрерывности: что в нем должно быть

План должен быть применимым, а не «документом на полке». Минимальные элементы:

список критичных процессов и систем

зависимости (внутренние и внешние: провайдеры, SaaS, подрядчики)

порядок переключения на резервные сценарии

порядок коммуникаций (внутри компании, с клиентами, с регуляторами при необходимости)

критерии возврата к штатной работе

Упражнения и готовность

Непрерывность и реагирование проверяются только практикой.

Полезные форматы:

tabletop exercise: разбор сценария «на столе» с ролями и таймлайном

технические учения: восстановление из бэкапа, переключение на резервную площадку

проверка контактов и доступов: доступны ли ответственные, работают ли экстренные процедуры

Как связать мониторинг, IR и непрерывность в единую систему управления

Практичная связка выглядит так:

модель угроз определяет приоритетные сценарии атак

под эти сценарии создаются детекты и плейбуки

плейбуки учитывают бизнес-ограничения (что можно отключить, а что нельзя)

непрерывность бизнеса задает целевые RTO/RPO и резервные сценарии

метрики показывают, становится ли система лучше

Минимальные метрики, которые помогают управлять

время от события до обнаружения (время обнаружения)

время от обнаружения до локализации (время сдерживания)

доля критичных систем с логированием и доставкой логов

доля админ-аккаунтов с MFA

успешность и регулярность тестов восстановления

Итоги

Мониторинг нужен, чтобы обнаруживать инциденты быстро и с доказательствами.

Реагирование на инциденты — это процесс: подготовка, анализ, сдерживание/устранение/восстановление, улучшения.

Непрерывность бизнеса переводит безопасность в измеримые цели через RTO и RPO и требует проверяемых планов восстановления.

Лучший результат дает связка: модель угроз → детекты → плейбуки → упражнения → улучшения и метрики.