Информационная безопасность: базовый курс

Основы ИБ: цели, термины, CIA-триада и модели угроз

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

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

На практике ИБ отвечает на вопрос: что именно мы защищаем, от кого, какими способами и почему именно так.

Базовые определения

Ниже — минимальный словарь, без которого дальше будет сложно.

Информация и информационная система

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

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

Актив

Актив — то, что имеет ценность и нуждается в защите.

Типичные активы:

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

сервисы (интернет-магазин, CRM, платежи)

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

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

Субъект и объект доступа

Субъект — тот, кто пытается получить доступ (пользователь, сервис, процесс).

Объект — то, к чему запрашивают доступ (файл, запись в БД, API-метод, функция админки).

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

Эти термины постоянно путают, поэтому разберём их на одном примере.

Представьте веб-сервис:

Угроза — потенциальная причина инцидента (например, злоумышленник пытается украсть учётные записи).

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

Воздействие (impact) — ущерб при успешной атаке (например, кража данных клиентов и штрафы).

Риск — сочетание вероятности и ущерба: насколько реально это случится и насколько больно будет.

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

угрозы используют уязвимости

уязвимости приводят к воздействию

риск — это приоритет, с чего начинать защиту

О терминах и определениях также можно сверяться с глоссариями:

NIST Computer Security Resource Center Glossary

ISO/IEC 27000 overview (ISO)

Контроль (мера защиты)

Контроль — действие или механизм, который снижает риск.

Контроли бывают:

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

технические (MFA, шифрование, WAF, сегментация сети)

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

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

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

обнаруживающие (заметить атаку)

корректирующие (восстановиться и снизить последствия)

Цели информационной безопасности и CIA-триада

Классическая модель целей ИБ — CIA-триада.

!Схема показывает три базовые цели ИБ и их связь

Конфиденциальность

Конфиденциальность означает, что информацию могут читать только те, кому это разрешено.

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

утечка базы пользователей

доступ сотрудника к данным «не по роли»

перехват трафика без шифрования

Примеры мер защиты:

разграничение прав (RBAC/ABAC)

многофакторная аутентификация (MFA)

шифрование данных и каналов (например, TLS)

Целостность

Целостность означает, что данные не изменяются несанкционированно и не теряют корректность.

Типичные нарушения целостности:

подмена реквизитов в платёжке

изменение данных в БД через уязвимость

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

Примеры мер защиты:

контроль изменений (change management)

журналирование и неизменяемые логи

контроль целостности (хэши, подписи), права на запись

Доступность

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

Типичные нарушения доступности:

DDoS-атака

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

ошибка обновления, остановившая сервис

Примеры мер защиты:

резервирование и отказоустойчивость

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

мониторинг, алёрты, план реагирования

Важный практический вывод

CIA — это не «галочки», а компромиссы. Усиление одного свойства может усложнять другое.

Примеры типовых конфликтов:

жёсткие правила доступа повышают конфиденциальность, но могут снижать доступность (пользователи не могут быстро получить нужные данные)

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

Задача ИБ — найти баланс, соответствующий ценности активов и допустимому риску.

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

Кроме CIA часто используют ещё два свойства.

Подлинность (authenticity) — уверенность, что субъект или данные действительно те, за кого себя выдают.

Неотказуемость (non-repudiation) — невозможность правдоподобно отрицать совершённое действие (важно для юридически значимых операций).

Эти свойства обычно достигаются комбинацией:

строгой аутентификации

журналирования

криптографических подписей

Как думать об атакующих и инцидентах

ИБ становится проще, если разделять:

кто атакует (мотивы и возможности)

что атакует (активы и поверхности атаки)

как атакует (типовые техники)

Типовые нарушители

Часто выделяют:

внешних злоумышленников (финансовая мотивация, шантаж, конкуренция)

внутренних нарушителей (умышленно или по ошибке)

подрядчиков и партнёров (доступ через интеграции)

автоматизированные угрозы (боты, сканеры, массовые атаки)

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

Поверхность атаки — все точки, через которые можно воздействовать на систему.

Примеры:

публичные веб-страницы и API

админ-панели и консоли

интеграции и ключи доступа

рабочие станции сотрудников

процессы поддержки (сброс пароля, звонки в helpdesk)

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

Модели угроз: что это и зачем

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

Модель угроз помогает:

не спорить «на ощущениях», а фиксировать допущения

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

выбирать контроли, которые реально снижают риск

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

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

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

NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments)

OWASP Threat Modeling

NIST SP 800-154 (Guide to Data-Centric System Threat Modeling)

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

Ниже — базовый процесс, который подходит для старта и небольших систем.

Определите границы системы и активы

Нужно зафиксировать:

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

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

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

какие есть внешние зависимости (платежи, SMS, облака)

Результат: список активов и архитектурный контур.

Опишите поток данных и доверенные границы

Полезно нарисовать упрощённую схему:

где данные появляются

где хранятся

куда передаются

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

!Диаграмма помогает увидеть, где данные пересекают границы доверия

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

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

«кто-то получает доступ к X без прав»

«кто-то изменяет Y так, что это незаметно»

«сервис Z становится недоступен из-за …»

Чтобы не забывать классы угроз, часто используют чек-листы и подходы вроде STRIDE, но на базовом уровне достаточно привязки к CIA:

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

угрозы целостности

угрозы доступности

Найдите уязвимости и текущие меры защиты

Для каждого сценария полезно ответить:

что должно быть слабым местом, чтобы сценарий удался

какие меры уже есть

что отсутствует или настроено неверно

Оцените риск и приоритизируйте

Даже грубой оценки достаточно, чтобы выбрать порядок работ.

Простой подход:

вероятность: низкая / средняя / высокая

ущерб: низкий / средний / высокий

Дальше выбирают сценарии с максимальным приоритетом (например, «высокая вероятность + высокий ущерб»).

Сформируйте план обработки рисков

Классические варианты:

снизить (внедрить/усилить контроли)

избежать (изменить архитектуру/функцию)

передать (страхование, договоры, аутсорс)

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

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

Минимальный пример модели угроз для веб-приложения

Актив: база пользователей (контакты, хэши паролей, история заказов).

Сценарии:

конфиденциальность: утечка базы через SQL-инъекцию

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

доступность: перегрузка сервиса ботами на эндпоинте поиска

Возможные меры:

параметризованные запросы, ORM, WAF (для снижения риска SQL-инъекций)

серверная валидация, контроль бизнес-логики, тесты (для целостности)

rate limiting, кеширование, защита от ботов, наблюдаемость (для доступности)

Этот пример показывает ключевую идею: одна и та же система требует мер по всем трём целям CIA.

Что запомнить

ИБ начинается с активов и целей: что защищаем и почему это важно.

CIA-триада — базовая рамка: конфиденциальность, целостность, доступность.

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

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

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

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

Как эта тема связана с прошлой статьёй

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

Теперь сделаем следующий шаг: посмотрим на самые частые классы атак, которые вы будете встречать в реальных системах:

социальная инженерия (атаки через людей и процессы)

вредоносное ПО (атаки через выполнение кода на устройствах)

сетевые атаки (атаки через сетевые протоколы и сервисы)

Задача статьи — научиться распознавать типовые сценарии, понимать, какую цель CIA они нарушают, и какие меры защиты обычно работают.

Базовая логика атаки: от входа до ущерба

Большинство инцидентов укладывается в понятную цепочку:

Злоумышленник находит вход (почта, сайт, удалённый доступ, подрядчик, уязвимость).

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

Закрепляется (настраивает автозапуск, создаёт учётку, крадёт токены).

Расширяет доступ (получает больше прав, двигается по сети).

Делает действие по цели (крадёт данные, шифрует, нарушает работу).

!Наглядно показывает типовые этапы атаки и где можно прерывать сценарий защитными мерами

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

Социальная инженерия

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

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

Почему работает

Чаще всего используют сочетание:

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

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

авторитет ("пишет директор", "служба безопасности")

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

Основные виды атак

Ниже — самые типовые формы. Они часто комбинируются.

Фишинг — массовые письма/сообщения с целью украсть учётные данные или заставить открыть вредоносный файл.

Целевой фишинг (spear phishing) — то же, но с персонализацией под конкретного сотрудника/команду.

Whaling — атаки на руководителей и сотрудников с доступом к деньгам и критичным системам.

Vishing — звонки (голос), где выманивают коды, пароли, заставляют установить ПО.

Smishing — SMS/мессенджеры, часто с вредоносными ссылками.

Pretexting — заранее придуманный сценарий (легенда): "я из ИТ", "я подрядчик", "я из банка".

Baiting — приманка (например, "зарплатная ведомость" или флешка "Служебное").

Tailgating — проход в закрытую зону "хвостом" за сотрудником (физический аспект ИБ).

Примеры сценариев и какие свойства CIA они бьют

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

Подмена платёжных реквизитов через письмо "от поставщика" — нарушение целостности (данные изменены, деньги ушли не туда).

Ложное "срочное" действие, отключающее сервис (например, удаление записей/ресурсов по инструкции) — нарушение доступности.

Что реально снижает риск

Меры против социальной инженерии — это сочетание технических и организационных контролей:

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

- MFA снижает ценность украденного пароля. - Запрет устаревших методов (например, базовой аутентификации там, где это возможно).

Проверки по независимому каналу

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

Почтовая защита и фильтрация

- Антифишинговые фильтры, проверка вложений, блокировка исполняемых типов.

Обучение и тренировки

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

Минимизация прав

- Даже если человека обманули, последствия ограничены его ролью.

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

CISA: Avoiding Social Engineering and Phishing Attacks

Вредоносное ПО

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

Основные типы (простыми словами)

Вирус — заражает файлы и распространяется при их запуске/копировании.

Червь — распространяется сам по сети, используя уязвимости или слабые настройки.

Троян — маскируется под полезное ПО, но выполняет вредоносные действия.

Шпионское ПО (spyware) — собирает данные: пароли, нажатия клавиш, содержимое экрана.

Вымогатель (ransomware) — шифрует данные и требует выкуп.

Бэкдор — скрытый способ удалённого доступа.

Бот — заражённое устройство, управляемое командным сервером (часть ботнета).

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

Типовые пути заражения

Фишинговые вложения и ссылки

- Документы с макросами, архивы с исполняемыми файлами, ссылки на поддельные страницы.

Скачивание "нужной утилиты"

- Поддельные установщики, кряки, расширения браузера.

Эксплуатация уязвимостей

- Необновлённые сервисы, плагины, VPN-шлюзы.

Компрометация цепочки поставок

- Вредонос попадает через обновление или библиотеку, которой доверяют.

Что происходит после заражения

В упрощённом виде вредонос обычно пытается:

закрепиться (автозапуск, службы, планировщик)

украсть секреты (пароли, токены, ключи)

получить больше прав (используя ошибки конфигурации или уязвимости)

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

выполнить цель (утечка, шифрование, саботаж)

Влияние на CIA

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

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

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

Базовые меры защиты

Управление обновлениями (patch management)

- Многие массовые заражения происходят через известные уязвимости.

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

- Антивирус/EDR, контроль поведения, изоляция подозрительных процессов.

Ограничение запуска

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

Резервное копирование

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

Сегментация сети и минимизация прав

- Ограничивает распространение и снижает ущерб.

Наблюдаемость и реагирование

- Логи, алёрты, понятный процесс: кто и что делает при подозрении на заражение.

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

NIST SP 800-83 Rev. 1: Guide to Malware Incident Prevention and Handling

NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide

Сетевые атаки

Сетевая атака — это попытка нарушить работу или безопасность системы через сеть: используя сетевые протоколы, уязвимые сервисы, ошибки настройки, слабые пароли.

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

Пакет — небольшая часть данных, которая передаётся по сети.

Порт — логический "номер двери" на устройстве, через который работает конкретный сетевой сервис (например, веб-сервис).

Частые виды сетевых атак

#### Разведка и подготовка

Сканирование портов — поиск открытых сервисов и их версий.

Перебор паролей и password spraying

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

#### Перехват и подмена трафика

Man-in-the-Middle (MITM) — злоумышленник становится "между" сторонами и читает/меняет данные.

Подмена DNS — пользователь идёт на правильное имя, но попадает на неправильный адрес.

Защита обычно опирается на шифрование каналов (например, TLS), корректную проверку сертификатов и защищённые настройки сети.

#### Атаки на доступность

DoS/DDoS — перегрузка сервиса запросами, чтобы он перестал отвечать.

Базовые меры:

rate limiting, кеширование, CDN/WAF, защита на уровне провайдера, масштабирование, наблюдаемость.

#### Эксплуатация уязвимых сетевых сервисов

атаки на не обновлённые публичные сервисы

использование дефолтных паролей

ошибки конфигурации удалённого доступа

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

Где чаще всего ошибаются

Оставляют админ-доступ в интернет без ограничений

- панели управления, базы данных, удалённые протоколы.

Полагаются только на пароль

- без MFA, без ограничений по IP, без мониторинга.

Не сегментируют сеть

- один взломанный компьютер даёт путь ко всем серверам.

Не замечают атаки из-за отсутствия логов и алёртов

- даже хорошие контроли бессмысленны, если никто не видит, что происходит.

Как связать атаки с моделью угроз и CIA

Удобная практика: для каждого важного актива перечислить сценарии по CIA и добавить типовые источники атак.

Ниже — упрощённая карта соответствий.

| Класс атаки | Что обычно нарушают | Типовые входы | Примеры контролей | |---|---|---|---| | Социальная инженерия | Конфиденциальность, целостность | Почта, мессенджеры, телефон, процессы согласования | MFA, обучение, независимое подтверждение, почтовые фильтры, минимизация прав | | Вредоносное ПО | Все три свойства CIA | Вложения, ссылки, уязвимости, цепочка поставок | Патчи, EDR/AV, ограничения запуска, сегментация, бэкапы, мониторинг | | Сетевые атаки | Доступность, конфиденциальность, целостность | Публичные сервисы, удалённый доступ, протоколы сети | TLS, WAF, rate limiting, сегментация, закрытие портов, MFA, журналирование |

Ключевая идея: защита — это не "одна волшебная технология", а набор контролей, которые перекрывают разные этапы атаки и разные свойства CIA.

Что запомнить

Социальная инженерия атакует людей и процессы; её цель — заставить сделать действие, которое открывает доступ.

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

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

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

Криптография и аутентификация: шифрование, хэширование, MFA, PKI

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

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

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

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

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

подлинность: чтобы понимать, кто именно подключился или подписал данные

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

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

Базовые понятия: что именно мы защищаем криптографией

Секрет, ключ и алгоритм

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

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

Секрет: любая ценная чувствительная информация (пароль, токен, ключ API, приватный ключ).

Практический принцип: безопасность должна опираться на секретность ключа, а не на «секретность алгоритма».

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

шифрование трафика между клиентом и сервером (TLS)

шифрование данных на диске (полное шифрование, шифрование БД)

безопасное хранение паролей (хэширование с солью)

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

аутентификация пользователей и сервисов (сертификаты, токены, MFA)

Шифрование: как защищают конфиденциальность

Шифрование преобразует данные так, что без ключа их нельзя прочитать. Расшифровка возвращает исходные данные.

Симметричное шифрование

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

Ключевые свойства:

быстрое и подходит для больших объёмов данных

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

Популярный алгоритм: AES.

Асимметричное шифрование

Асимметричное шифрование использует пару ключей:

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

приватный ключ хранится в секрете

Что это даёт:

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

можно строить механизмы подлинности и подписей

Популярные алгоритмы: RSA (исторически широко распространён), ECC (эллиптические кривые).

!Сравнение двух подходов шифрования и их ключевых свойств

Почему в TLS используются оба подхода

В защищённых соединениях (например, HTTPS) обычно комбинируют подходы:

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

симметричная криптография затем шифрует основной трафик быстро и эффективно

Спецификация TLS 1.3: RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.

Типовые ошибки при внедрении шифрования

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

отключение проверки сертификата «чтобы работало»

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

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

Хэширование: как фиксируют целостность и безопасно хранят пароли

Хэш-функция преобразует входные данные в строку фиксированной длины (хэш). Важное отличие от шифрования: хэширование не предполагает обратного преобразования.

Зачем нужно хэширование

контроль целостности: файл изменился, если изменился его хэш

хранение паролей: система не должна хранить пароль в открытом виде

Почему «просто SHA-256» для паролей недостаточно

Для паролей опасны быстрые хэш-функции (SHA-256, SHA-1): атакующий может очень быстро перебирать варианты на видеокартах.

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

bcrypt

scrypt

Argon2

Практический ориентир: OWASP Password Storage Cheat Sheet.

Соль и почему она обязательна

Соль — случайная строка, уникальная для каждого пароля, которая добавляется перед хэшированием.

Соль нужна, чтобы:

одинаковые пароли у разных пользователей давали разные хэши

стали бесполезны заранее подготовленные таблицы атак (радужные таблицы)

Важно: соль не обязана быть секретной, но должна быть уникальной и достаточно случайной.

MAC и подпись: как защищают целостность и подлинность

Шифрование защищает от чтения, но не всегда защищает от незаметного изменения. Для целостности и подлинности применяют дополнительные механизмы.

MAC и HMAC

MAC (Message Authentication Code) — код аутентичности сообщения, который вычисляется на основе сообщения и общего секретного ключа.

Практический вариант: HMAC.

Что даёт HMAC:

обнаружение изменения данных

подтверждение, что сообщение сделала сторона, знающая общий секрет

Где применяется:

подпись API-запросов между сервисами

защита целостности сообщений в интеграциях

Ограничение:

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

Цифровая подпись

Цифровая подпись строится на асимметричной криптографии:

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

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

Что даёт подпись:

целостность: изменения обнаруживаются

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

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

Где применяется:

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

подпись обновлений, контейнеров, пакетов

аутентификация в протоколах и инфраструктуре

Аутентификация: как система понимает, кто вы

Аутентификация отвечает на вопрос: кто вы?

Её часто путают с авторизацией:

аутентификация: установление личности

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

Факторы аутентификации

Факторы делят на:

что вы знаете (пароль, PIN)

что у вас есть (телефон с приложением, аппаратный ключ)

кто вы есть (биометрия)

MFA и почему она снижает ущерб от фишинга

MFA (многофакторная аутентификация) требует минимум два разных фактора.

Практический эффект:

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

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

Типовые варианты MFA:

одноразовые коды (TOTP-приложения)

push-подтверждения (подтвердить вход в приложении)

аппаратные ключи по стандартам FIDO2/WebAuthn

Самый устойчивый к фишингу вариант обычно связан с FIDO2/WebAuthn, потому что проверка привязана к сайту и сложнее «прокинуть» на фейковую страницу.

Рекомендации по цифровой идентификации: NIST SP 800-63B: Digital Identity Guidelines.

Частые ошибки внедрения MFA

«MFA только для админов», хотя основной входной вектор атакующих часто через обычных сотрудников

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

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

PKI: инфраструктура доверия для сертификатов

PKI (Public Key Infrastructure) — это набор технологий и процессов, который позволяет доверять публичным ключам через сертификаты.

Что такое сертификат

Сертификат (чаще всего X.509) — это файл, который связывает:

публичный ключ

сведения о владельце (домен, организация, сервис)

срок действия

подпись удостоверяющего центра

Сертификат отвечает на вопрос: этот публичный ключ действительно принадлежит этому домену или организации?

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

Удостоверяющий центр (CA) выпускает сертификаты и подписывает их своим ключом.

Обычно есть цепочка:

корневой CA (доверие встроено в ОС и браузеры)

промежуточный CA

сертификат сайта или сервиса

Клиент проверяет цепочку и решает, доверять ли соединению.

!Как браузер проверяет сертификат через цепочку удостоверяющих центров

PKI в реальной жизни

HTTPS: браузер проверяет сертификат сайта и устанавливает защищённое соединение

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

корпоративные сертификаты: доступ к VPN, Wi‑Fi, внутренним ресурсам

Отзыв и ротация

Сертификаты и ключи не должны жить вечно.

Важно понимать два процесса:

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

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

Управление ключами: то, на чём чаще всего ломается криптография

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

Практики, которые стоит внедрять

хранить секреты в специализированных хранилищах (vault, KMS), а не в репозитории

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

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

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

Рекомендации по управлению ключами: NIST SP 800-57 Part 1 Rev. 5.

Как привязать криптографию к CIA и типовым атакам

| Механизм | Что защищает | От каких атак помогает | Типовые ошибки | |---|---|---|---| | TLS (HTTPS) | Конфиденциальность и целостность трафика, подлинность сервера | MITM, перехват в сети | Отключение проверки сертификата, устаревшие настройки | | Хэширование паролей (bcrypt/Argon2) | Конфиденциальность учётных данных | Утечки БД, офлайн-перебор | Хранение паролей в открытом виде, быстрые хэши | | MFA | Подлинность пользователя | Фишинг, повторное использование паролей | Слабое восстановление доступа, исключения «для удобства» | | Подписи и PKI | Целостность и подлинность артефактов и соединений | Подмена обновлений, поддельные сервисы | Непонятная цепочка доверия, отсутствие ротации |

Что запомнить

Шифрование защищает данные от чтения, но для защиты от незаметных изменений часто нужны MAC или подписи.

Пароли не шифруют и не хранят как есть: их хэшируют специальными алгоритмами и обязательно используют соль.

MFA снижает ущерб от фишинга, потому что украденного пароля обычно недостаточно.

PKI и сертификаты позволяют доверять публичным ключам и строить защищённые соединения в интернете и внутри компаний.

Самая частая причина провалов криптографии — плохое управление ключами и секретами, а не «слабый алгоритм».

Практика защиты: доступы, сети, ОС, обновления, резервное копирование

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

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

цели ИБ через CIA-триаду

типовые атаки (социальная инженерия, вредоносное ПО, сетевые атаки)

криптографию и аутентификацию (TLS, хэши паролей, MFA, PKI)

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

доступы

сеть

операционные системы и рабочие станции

обновления

резервное копирование

Главная идея: защищают не отдельные технологии, а согласованный набор контролей, которые перекрывают разные этапы атаки и поддерживают цели CIA.

!Карта того, как пять практик защиты поддерживают цели CIA

Практический принцип: сначала критичные активы и пути атаки

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

Определите активы (данные, сервисы, учётные записи, ключи).

Определите основные пути атаки (почта и фишинг, публичные сервисы, удалённый доступ, подрядчики).

Выберите контроли, которые режут риск по вероятности или по ущербу.

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

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

Управление доступами закрывает большую часть нарушений конфиденциальности и целостности: от украденных паролей до ошибочно выданных прав.

Аутентификация и жизненный цикл учётной записи

Базовые правила:

у каждого человека должна быть своя учётная запись

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

привилегированные доступы должны быть отделены от обычных

Практики, которые дают быстрый эффект:

MFA для почты, VPN, админ-панелей, облачных консолей

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

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

Ориентир по уровням и методам аутентификации: NIST SP 800-63B Digital Identity Guidelines.

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

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

Практический минимум:

роль сотрудника должна соответствовать набору прав (RBAC)

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

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

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

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

Самые опасные учётные записи:

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

администраторы домена и серверов

администраторы облака

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

Практики для снижения риска:

Отделите админ-аккаунт от обычного (разные логины).

Запретите повседневную работу под админом.

Используйте выделенные устройства или защищённые сессии для администрирования, где это возможно.

Введите журналирование админ-действий и контроль изменений.

Сервисные учётные записи и секреты

Сервисы тоже аутентифицируются: ключами API, токенами, паролями, сертификатами.

Типовые ошибки:

ключи в репозитории

один ключ на все окружения

секреты без ротации годами

Практики:

хранить секреты в специализированном хранилище (vault или KMS)

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

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

Сетевая защита: границы, сегментация, удалённый доступ

Сеть важна потому, что большинство атак пытается:

попасть внутрь (через публичные сервисы, VPN, фишинг)

закрепиться

перемещаться по сети к ценным активам

Снижение поверхности атаки

Быстрые шаги, которые часто дают максимальный эффект:

закрыть всё, что не нужно снаружи

ограничить административные интерфейсы по IP и через VPN

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

Ориентир по периметру и межсетевым экранам: NIST SP 800-41 Guidelines on Firewalls and Firewall Policy.

Сегментация: ограничить распространение атаки

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

Что это даёт:

заражение одного ноутбука не означает доступ ко всем серверам

уменьшается радиус поражения при компрометации учётной записи

проще мониторить аномалии между зонами

Минимальная практическая модель сегментации:

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

серверы приложений

базы данных и хранилища

админ-сегмент

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

Удалённый доступ почти всегда в топе входных векторов.

Правила базового уровня:

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

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

запрет прямого администрирования из интернета, если это можно избежать

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

Шифрование каналов и проверка подлинности

Используйте TLS для веба и внутренних API, а для критичных сервис-сервис взаимодействий рассматривайте взаимную аутентификацию.

Ориентир по TLS: RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3.

Защита ОС и рабочих станций: базовое укрепление

Атаки с вредоносным ПО часто начинаются с рабочей станции, а затем переходят на серверы.

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

Невозможно защищать то, чего вы не видите.

Практики:

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

стандартные безопасные конфигурации (hardening baselines)

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

Практический ориентир по системным мерам защиты: CIS Critical Security Controls v8.

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

Базовые задачи защиты хостов:

обнаруживать известное вредоносное ПО

замечать подозрительное поведение

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

Типовые меры:

включённый и обновляемый антивирус или EDR

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

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

Журналирование и наблюдаемость на хостах

Без журналов многие инциденты выглядят как “просто что-то сломалось”.

Что важно собирать на базовом уровне:

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

запуск процессов и изменения важных настроек, где это возможно

события установки и обновления ПО

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

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

Patch management как процесс

Обновления должны быть не разовой акцией, а циклом:

Учёт активов и версий.

Оценка важности обновлений и рисков простоя.

Тестирование на небольшой группе.

Развёртывание.

Контроль факта установки.

Ориентир по построению процесса: NIST SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning.

Приоритизация: что обновлять в первую очередь

Если ресурсов мало, приоритизируют так:

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

удалённый доступ и средства администрирования

почтовая инфраструктура и клиенты

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

системы с чувствительными данными

Обновления и целостность поставки

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

Минимальные практики:

запрет установки ПО из “случайных” источников

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

по возможности проверка подписей обновлений и пакетов

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

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

Что важно понимать про бэкапы

Бэкап ценен только если:

его можно восстановить

он не шифруется вместе с основной инфраструктурой

он покрывает нужные данные и нужную глубину истории

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

Правило 3-2-1 (как практическая памятка)

Часто используют правило:

3 копии данных

2 разных типа носителя или хранилища

1 копия вне основной среды (офлайн или отдельно изолирована)

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

Защита резервных копий от вымогателей

Вымогатели часто пытаются сначала удалить или зашифровать бэкапы.

Меры:

отдельные учётные записи и изоляция доступа к хранилищу бэкапов

неизменяемые бэкапы (immutable), где доступно

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

RPO и RTO простыми словами

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

RPO: сколько данных вы готовы потерять по времени (например, “не больше 1 часа изменений”)

RTO: за какое время сервис должен вернуться в работу (например, “за 4 часа”)

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

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

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

Базис по доступам

MFA на ключевых системах (почта, облако, VPN)

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

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

безопасное хранение и ротация секретов

Базис по сети

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

сегментация и ограничение восточно-западного трафика

защищённый удалённый доступ

TLS для трафика, где передаются чувствительные данные

Базис по ОС и хостам

инвентаризация устройств и ПО

безопасные конфигурации по стандарту организации

антивирус или EDR и базовая телеметрия

журналирование ключевых событий

Базис по обновлениям

регулярный процесс обновлений

приоритет интернет-экспонированных систем

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

Базис по резервному копированию

бэкап критичных данных

изоляция бэкапов

регулярные тесты восстановления

Что запомнить

Практическая защита строится вокруг пяти опор: доступы, сеть, ОС, обновления, резервное копирование.

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

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

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

Patch management снижает вероятность взлома через известные уязвимости.

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

Риски и процессы: политики, соответствие, инциденты и основы SOC

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

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

цели ИБ через CIA-триаду (конфиденциальность, целостность, доступность)

типовые атаки (социальная инженерия, вредоносное ПО, сетевые атаки)

криптографию и аутентификацию (TLS, хэши паролей, MFA, PKI)

практику защиты (доступы, сеть, ОС, обновления, резервное копирование)

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

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

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

Риск-ориентированный подход

Что такое управление рисками

Риск в ИБ удобно понимать как сочетание:

вероятности негативного события

масштаба ущерба, если событие произошло

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

не пытаться «защитить всё одинаково»

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

объяснять приоритеты бизнесу понятным языком

Методические ориентиры:

NIST SP 800-30: Guide for Conducting Risk Assessments

NIST Glossary

Практический цикл управления рисками

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

Опишите угрозы и сценарии (из прошлых тем: фишинг, заражение, атаки через сеть)

Найдите уязвимости и текущие контроли

Оцените риск грубо (например, низкий/средний/высокий)

Выберите обработку риска

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

Назначьте владельца, сроки и критерии приемки

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

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

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

актив

сценарий риска

текущие контроли

оценка (вероятность/ущерб)

решение (снизить/избежать/передать/принять)

план работ и владелец

Важно: реестр рисков помогает не только ИБ-команде, но и руководителям понимать, почему именно эти меры делаются первыми.

Политики: как закрепить правила, которые реально работают

Что такое политика и чем она отличается от регламента

Политика отвечает на вопрос что мы требуем и почему это важно (принципы и обязательные правила).

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

Процедура (регламент) описывает кто и что делает пошагово.

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

Признаки хорошей политики

связана с рисками и активами (а не «потому что так принято»)

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

назначает роли и ответственность

имеет область применения и исключения (и кто их согласует)

пересматривается по расписанию или при изменениях

Минимальный набор политик для базового уровня

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

- MFA для ключевых систем - принцип наименьших привилегий - порядок выдачи и пересмотра прав

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

- что считается критичным - сроки установки патчей

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

- что бэкапим, где храним, как проверяем восстановление

Политика журналирования и мониторинга

- какие события должны логироваться - сроки хранения логов

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

- кто дежурит, как эскалировать, как фиксировать артефакты

Политика приемлемого использования

- правила для почты, устройств, облачных сервисов, внешних носителей

Ориентир по «базовым управленческим требованиям к программе ИБ» можно брать из:

NIST SP 800-53 (Security and Privacy Controls)

CIS Critical Security Controls v8

Соответствие требованиям: зачем нужно и где часто ошибаются

Соответствие не равно безопасность

Соответствие (compliance) — это выполнение внешних или внутренних требований: законов, отраслевых стандартов, договорных обязательств.

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

требования выполняются формально

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

отсутствует мониторинг и реагирование

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

риски определяют приоритеты

требования помогают не забыть базовые меры

аудит проверяет, что меры реально внедрены и работают

Примеры распространённых требований

Персональные данные в ЕС: Текст GDPR (Regulation (EU) 2016/679)

Безопасность платежных карт: PCI DSS

Общая рамка кибербезопасности: NIST Cybersecurity Framework 2.0

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

Для соответствия важно понимать два слоя:

контроль: мера защиты (например, MFA для доступа к облачной консоли)

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

Типовые виды доказательств:

скриншоты или выгрузки конфигураций

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

логи и отчёты мониторинга

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

отчёты о сканировании уязвимостей и факт установки патчей

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

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

Что считать инцидентом

Инцидент ИБ — событие, которое нарушает или может нарушить цели безопасности (CIA), подлинность или законность обработки данных.

Примеры:

фишинговый вход в почту сотрудника

обнаружение вредоносного ПО на рабочей станции

утечка ключа API

DDoS, из-за которого сервис недоступен

Ориентир по процессу реагирования:

NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide

Жизненный цикл реагирования на инцидент

Подготовка

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

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

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

Сдерживание

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

Устранение

- удаление вредоносного ПО - закрытие уязвимости - смена ключей и паролей

Восстановление

- возврат сервисов в штатный режим - восстановление данных из бэкапов - усиленный мониторинг после инцидента

Разбор и улучшения

- причины, что сработало, что не сработало - обновление плейбуков и контролей

!Цикл помогает запомнить этапы реагирования и не пропускать разбор причин

Роли и коммуникации во время инцидента

Минимальный состав ролей (в небольшой организации роли могут совмещаться):

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

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

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

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

Коммуникации нужно продумывать заранее:

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

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

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

Плейбуки: почему они экономят часы

Плейбук — короткая инструкция на типовой инцидент. Он снижает хаос и ускоряет триаж.

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

«подозрение на фишинг и компрометацию почты»

«обнаружено вредоносное ПО на рабочей станции»

«утечка токена/ключа API»

«подозрительные входы в VPN/облако»

В плейбуке обычно фиксируют:

признаки (как понять, что это этот сценарий)

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

быстрые действия сдерживания

действия по восстановлению

критерии эскалации

Основы SOC: мониторинг, детектирование, SIEM и базовые метрики

Что такое SOC

SOC (Security Operations Center) — функция (команда и процессы), которая:

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

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

помогает реагировать на инциденты

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

SOC может быть:

внутренним

внешним (MSSP)

гибридным

Ориентир по непрерывному мониторингу:

NIST SP 800-137: Information Security Continuous Monitoring (ISCM)

Из чего технически состоит базовый SOC

источники событий

- журналы аутентификации (AD/SSO, VPN, облако) - почтовые события - логи серверов и приложений - EDR/антивирус на рабочих станциях - сетевые события (если доступны)

система корреляции и хранения

- SIEM (сбор, нормализация, правила, расследования)

процессы

- триаж алертов - управление инцидентами - улучшение детектов

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

Детектирование: почему «просто включить SIEM» недостаточно

Детектирование работает, когда есть:

понятные сценарии атак, которые вы хотите поймать

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

правила и аналитика

процесс обработки алертов

Полезный справочник техник атак для генерации идей детектов:

MITRE ATT&CK

Примеры детектов базового уровня:

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

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

создание нового правила переадресации в почте

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

резкое увеличение прав у учётной записи

Типовые ошибки при построении SOC

собирают «все логи мира», но не определяют сценарии и приоритеты

не назначают владельцев алертов и сроки реакции

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

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

Минимальные метрики, которые имеют смысл

Чтобы SOC и реагирование улучшались, нужны измеримые показатели:

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

время сдерживания (как быстро ограничиваем распространение)

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

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

Метрики не должны превращаться в «гонку за цифрами»: их цель — выявлять узкие места и улучшать процессы.

Как собрать всё вместе: практическая связка для базового уровня

Ниже — рабочая последовательность, которая объединяет темы курса.

Активы и модель угроз

- какие данные и сервисы критичны - какие сценарии атак наиболее вероятны

Базовые контроли

- MFA, минимизация прав, сегментация - патчи, EDR, бэкапы - шифрование каналов и корректное хранение секретов

Политики и процессы

- доступы, обновления, бэкапы, логирование, инциденты

SOC и реагирование

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

Соответствие и аудит

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

Что запомнить

Риски помогают приоритизировать безопасность: защищают сначала то, что даёт наибольшее снижение риска.

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

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

Реагирование на инциденты — это жизненный цикл от подготовки до разбора и улучшений; плейбуки ускоряют действия.

SOC — это постоянный мониторинг, детектирование и поддержка реагирования; качество важнее количества логов.