Классификация угроз и современные векторы атак
В многих организациях к теме информационной безопасности приходят уже постфактум, после утечек и сбоев, когда решения принимаются хаотично и без опоры на реальные приоритеты. Такой подход приводит к перегруженной, но малоэффективной защите, которая слабо соотносится с реальными сценариями атак. https://seberd.ru/262
Представьте: сегодня утром исчезло одно из двух — база клиентов или инструкция по настройке принтеров. Какая потеря остановит компанию? Ответ на этот вопрос и есть начало осмысленной защиты.
Большинство компаний приходят к информационной безопасности после инцидента. До этого бюджет тратится на то, что посоветовал поставщик или внедрил конкурент. В итоге в инфраструктуре появляются неиспользуемые системы, а в папках — документы, которых никто не читает.
Правильный порядок обратный. Сначала выявляют активы, компрометация или остановка которых приводит к критическим потерям. Всё остальное получает защиту второго или третьего уровня — или не получает вовсе.
Как определить, что действительно критично
Процесс начинается с разговора с генеральным и финансовым директором. Не с аудита, не с инвентаризации — именно с разговора. Задают три вопроса.
Первый: какой финансовый ущерб возникнет, если основная система будет недоступна четыре часа? Второй: что потеряет компания через месяц и через год, если база клиентов или контрагентов окажется в открытом доступе? Третий: какой ущерб нанесёт несанкционированное изменение данных в отчётности или платёжных документах?
Ответы выявляют три-семь ключевых процессов и систем. Именно их компрометация недопустима — в терминологии регуляторов это называется недопустимыми событиями. Остальные риски допустимы в установленных пределах, и это нормально.
После разговора берут схему бизнес-процессов и накладывают на неё карту ИТ-инфраструктуры. Получается тепловая карта зависимостей. Один сервер обеспечивает приём платежей, одна база содержит договоры, один канал связи ведёт в банк. Там, где одиночная точка отказа остановит значительную часть дохода, — там и сосредоточена реальная защита.
Как посчитать допустимое время простоя
Цифры в договорах часто выглядят абстрактно, пока бухгалтерия не пытается выгрузить квартальный отчёт в момент аварии. Перевести проценты SLA в конкретные часы помогает простая формула: 365 × 24 × (100 − SLA) ÷ 100.
| Целевая доступность | Максимальный простой в год | Типичная нагрузка |
|---|---|---|
| 99,00% | 87 ч 36 мин | Офисные файловые хранилища |
| 99,90% | 8 ч 45 мин | Корпоративные порталы, внутренние CRM |
| 99,95% | 4 ч 22 мин | Интернет-магазины, складской учёт |
| 99,99% | 52 мин 34 с | Клиент-банки, биллинговые системы |
| 99,999% | 5 мин 15 с | Платёжные шлюзы, критичные SaaS |
Полученное число сравнивают с реальной историей инцидентов за последние двенадцать месяцев. Расхождение даже на несколько часов означает: инфраструктура не соответствует заявленным обязательствам. Техническая команда сразу видит, где теряется резервирование. Иногда причина в одном коммутаторе без дублирования питания. В других случаях виноват устаревший график замены дисков.
Почему универсальные меры защиты не работают
Одинаковые стандарты для всех систем создают иллюзию безопасности. Один владелец компании боится утечки клиентской базы больше, чем временной остановки 1С. Другой готов мириться с доступом по публичным каналам, пока финансовые проводки остаются неизменными. Закрыть все уязвимости одновременно невозможно: бюджет не выдержит.
Конфиденциальность, целостность и доступность всегда конкурируют за ресурсы. Приоритеты определяют архитектуру защиты.
Если критичнее всего сохранность платёжных реквизитов — фокус смещается на контроль изменений, журналирование операций и разделение ролей. Если бизнес теряет деньги каждую минуту простоя — инвестиции уходят в кластеризацию, резервные каналы и быстрые сценарии восстановления.
Попытка уравнять все риски ведёт к распылению средств. Администраторы тратят время на настройку инструментов, которые почти никогда не пригодятся. Реальные уязвимости остаются без внимания.
Как собрать модель угроз под конкретный бизнес
Модель угроз строится не на догадках, а на фактах эксплуатации. Начинают с инвентаризации активов, затем смотрят на историю обращений в поддержку, журналы событий и отчёты аудиторов. Из этого отбирают десять-двадцать сценариев, которые уже случались или могут произойти с высокой вероятностью в текущей конфигурации.
Несколько типичных примеров для региональных компаний.
Бухгалтер переходит по ссылке в письме, стилизованном под требование налоговой, и запускает загрузчик вредоносного кода. Сервер 2015 года с открытым портом годами отвечает из интернета, пока внешний сканер не обнаружит уязвимость в устаревшей ОС. Подрядчик после завершения работ забирает копию базы — потому что процедура отзыва доступов не прописана в договоре. Отказ ИБП в серверной комнате переводит оборудование в аварийный режим, восстановление занимает сутки из-за отсутствия холодного резерва. Удалённый сотрудник подключается к открытой точке в кафе, сессия захватывается, учётные данные уходят к злоумышленникам.
Список корректируют совместно с руководителями отделов. ИТ-специалисты часто не видят бизнес-процессы целиком: финансисты знают, какие операции критичны для кассового разрыва, логисты понимают, какой простой парализует отгрузки. Совместный разбор убирает фантастические сценарии вроде целевой атаки государственного уровня — если у компании нет стратегических данных, эту угрозу исключают. Остаётся рабочий документ.
Классификация угроз: почему делить на внешние и внутренние недостаточно
Классическое разделение по источнику доступа выглядит логично на бумаге. Внешний атакующий стучится через интернет, внутренний уже находится за периметром. Реальность размывает эту границу.
Удалённый сотрудник подключается к корпоративной сети из кафе с личного ноутбука: учётная запись формально внутренняя, но канал связи и устройство находятся под внешним контролем. Подрядчик получает временный доступ для настройки резервного копирования — потом забытую учётку никто не отзывает.
Полезнее разделять угрозы не по источнику, а по двум параметрам одновременно: уровню начального доступа и наличию умысла.
Внешние сценарии требуют фильтрации трафика, защиты от фишинга и мониторинга входящих соединений. Внутренние — сегментации, контроля привилегий и аудита действий авторизованных пользователей. Умышленные действия требуют технических ограничений: шифрования конечных точек, контроля выгрузок, разделения обязанностей и журналирования всех операций с критичными данными. Случайные ошибки закрываются обучением, ограничениями на отправку вложений и простой проверкой получателя.
Техногенные отказы не реагируют ни на психологические меры, ни на регламенты. Здесь работают только инженерные решения: резервирование питания, географически распределённые копии, автоматическое переключение каналов.
| Комбинация | Механизм реализации | Приоритетная мера |
|---|---|---|
| Внешний умышленный / конфиденциальность | Перехват учётных данных через фишинг, выгрузка CRM | MFA, контроль выгрузок, сегментация |
| Внутренний неумышленный / доступность | Обновление касс без тестирования, конфликт драйверов | Поэтапный rollout, тестовый контур, автооткат |
| Внутренний умышленный / целостность | Подмена скидок в учётной системе | Разделение ролей, аудит изменений, автолимиты |
| Внешний умышленный / доступность | DDoS на сайт в период распродажи | Облачный scrubbing, CDN, автомасштабирование |
| Внутренний неумышленный / конфиденциальность | Реестр поставщиков в общем мессенджере | Шифрование каналов, DLP на уровне приложений |
Статистика региональных компаний складывается не из шпионских триллеров. Основная масса ущерба приходит из двух пересечений: внешние умышленные атаки на конфиденциальность и внутренние неумышленные сбои доступности. Первые реализуются через массовый фишинг, шифровальщики и сканирование открытых портов. Вторые возникают из-за человеческой невнимательности, устаревших регламентов обновлений и отсутствия тестовых сред.
Современные векторы атак: что изменилось
Атаки стали проще. Злоумышленникам больше не нужны эксплойты нулевого дня — достаточно одной человеческой ошибки или одной забытой системы.
Многоэтапный фишинг. Сначала приходит письмо с правдоподобной темой от банка, налоговой или поставщика. Большинство игнорируют. Через несколько часов — звонок с поддельного номера: звонящий называет последние цифры карты или номер договора и просит подтвердить код из SMS или установить AnyDesk. Вся процедура занимает меньше пятнадцати минут. Бухгалтерия и кадровая служба остаются самыми уязвимыми отделами.
Рынок готового доступа. Существуют закрытые площадки, где торгуют учётными записями корпоративных сетей. Обычный доменный аккаунт стоит несколько сотен долларов. Доступ к клиент-банку или базе 1С может стоить до двадцати тысяч. Схема стандартная: сначала взламывают мелкого подрядчика — рекламное агентство, службу доставки или аутсорс-бухгалтерию, — через него проникают к основным клиентам.
Шифровальщики с двойным вымогательством. Перед шифрованием они копируют данные объёмом от пятидесяти до нескольких сотен гигабайт. Если выкуп не платят быстро, информацию публикуют и рассылают уведомления клиентам и партнёрам жертвы.
Living off the land. После получения начального доступа злоумышленники отказываются от стороннего вредоносного кода. Все действия выполняются через PowerShell, PsExec, WMI и штатный RDP. Большинство антивирусов не реагируют, поскольку действия выглядят легитимными. В сети они могут находиться неделями и месяцами.
Облачные хранилища и API. Открытый бакет без ограничений или избыточные права в облачной почте дают полный доступ за минуты. Неправильная настройка общего доступа к папкам или слабые политики условного доступа открывают всю корпоративную переписку и документы.
Устаревшее оборудование. Серверы, установленные много лет назад, часто продолжают отвечать из интернета с заводскими паролями и открытыми портами — о них просто забыли.
Как построить эффективную защиту без лишних затрат
Защита работает, только когда строится по модели угроз. Без неё любые вложения превращаются в бесполезные покупки. Есть модель — выбирают только то, что закрывает восемьдесят процентов реального риска.
Три базовые меры дают семьдесят-восемьдесят процентов результата и требуют минимальных затрат.
Закрыть лишнее от прямого доступа из интернета. Внешний периметр проверяют через Shodan или аналог за один вечер. Закрывают RDP, SMB, старые веб-панели и любые ненужные порты. Всё, что должно быть доступно снаружи, публикуют только через VPN или терминальные фермы. Девяносто процентов типовых проникновений исчезают сразу.
Усилить контроль входа. Отключают локальных администраторов на рабочих станциях, внедряют LAPS или аналог. Включают многофакторную аутентификацию везде, где возможно: почта, VPN, банковские клиенты, административные панели. Для сотрудников, работающих с деньгами и критическими данными, используют аппаратные ключи (Рутокен или аналоги). Для остальных достаточно push-уведомлений в смартфоне.
Регулярные обновления и изоляция устаревшего. Всё, что получает обновления безопасности, патчится не позже тридцати дней после выхода. Критические уязвимости закрываются в течение недели. Системы без поддержки выводятся в изолированный сегмент без выхода в интернет и без прямого доступа к важным базам.
Дальнейшие меры выбирают под конкретные угрозы из модели.
Если главная угроза — фишинг и кража учётных данных: включают строгую политику DMARC, блокируют макросы в офисных файлах, запрещают пересылку корпоративной почты на личные ящики. Раз в квартал проводят внутренний тест — рассылают имитацию фишингового письма и фиксируют, кто открыл.
Если основной риск — шифровальщики: создают офлайн-бэкапы с невозможностью перезаписи, хранят минимум девяносто дней. Раз в полгода отрабатывают полное восстановление на отдельной площадке. Ограничивают выполнение PowerShell и других скриптовых средств для обычных пользователей.
Если боятся утечек через сотрудников: на критических местах используют тонкие клиенты или VDI, запрещают USB-накопители через групповые политики. Контроль настраивают только на выгрузку баз клиентов и платёжных данных.
Если риски связаны с подрядчиками: каждому внешнему исполнителю выдают отдельную учётную запись без прав в основном домене. Доступ предоставляют через jump-сервер с записью всех действий. Раз в год меняют все пароли и сертификаты.
Мониторинг без дорогих систем. Включают встроенный аудит Windows, собирают логи в бесплатный Wazuh или аналог. Настраивают пять-семь важных алертов: вход с нового региона, запуск подозрительных команд, массовое чтение файлов.
Любое новое средство защиты сначала тестируют на небольшой группе одну-две недели. Если процессы тормозят или сотрудники жалуются — откатывают и ищут альтернативу. Защита не должна мешать бизнесу.
Как согласовать бюджет с реальными рисками
Каждая закупка проходит через фильтр модели угроз. Нет риска утечки через сетевые принтеры — средства DLP не требуются. Главный сценарий связан с отказом оборудования — деньги идут на резервирование каналов, горячие замены и отлаженные процедуры восстановления. Нет смысла покупать дорогие SIEM-системы, если в компании работает пять серверов и два администратора. Достаточно централизованного лог-сервера, базовых правил корреляции и чёткого регламента реакции.
Шаг 1. Оцениваем ущерб. Берут три наиболее вероятных сценария из модели угроз и считают прямой ущерб: выручка за четыре часа простоя основной системы; штраф за утечку персональных данных плюс расходы на компенсацию пострадавшим; средний чек мошеннического платежа при компрометации банк-клиента. Сумма даёт верхнюю границу годовых инвестиций. Если потенциальный ущерб — два миллиона рублей, а базовые меры стоят двести тысяч, инвестиции экономически обоснованы.
Шаг 2. Планируем базовый набор. Минимум, который закрывает восемьдесят процентов рисков при двадцати пяти сотрудниках: закрытие неиспользуемых портов (ноль рублей, делается своими силами за вечер), многофакторная аутентификация для почты и банк-клиента (ноль рублей, включается в веб-интерфейсе), облачный бэкап с ежедневной версией (около восемнадцати тысяч рублей в год при объёме до одного терабайта), внутренний тест фишинга дважды в год (пятьдесят тысяч рублей у регионального подрядчика). Итого: около шестидесяти восьми тысяч рублей в год.
Шаг 3. Исключаем скрытые платежи. В договоре с внешним подрядчиком прописывают фиксированную стоимость работ и перечень входящих услуг. Любое «дополнительное обследование» оплачивается только по письменному согласованию. При закупке лицензий используют официальных дистрибьюторов и проверяют цены на сайте производителя.
Шаг 4. Фиксируем экономику. Раз в год пересчитывают стоимость избежанного ущерба: берут количество инцидентов, которые не случились благодаря внедрённым мерам, и умножают на средний чек ущерба по отрасли. Если полученная сумма втрое превышает затраты — бюджет подтверждён. Если нет — корректируют список мер, а не увеличивают расходы.
Как проверять, что защита работает
После внедрения базовых мер возникает вопрос: работает ли всё на практике? Без регулярной проверки любая защита быстро превращается в формальность.
Контроль эффективности строится на трёх цифрах: время обнаружения инцидента, время его локализации, время восстановления. Для каждого показателя устанавливают целевое значение, фиксируют фактическое и сравнивают ежеквартально.
Внутренний тест безопасности проводят дважды в год. Сканируют внешние IP-адреса компании на открытый порт 3389, пытаются авторизоваться с учётными записями бывших сотрудников и паролями из списка «top-500 дефолтных», проверяют блокировку после трёх-пяти неудачных попыток. Параллельно рассылают сотрудникам контрольное фишинговое письмо — имитацию банка или налоговой, — отслеживают, кто открыл, кто кликнул, кто ввёл пароль. Цель: ноль открытых RDP-аккаунтов и менее пяти процентов кликов по фишингу.
Таблица KPI включает три показателя: среднее время между появлением инцидента и его регистрацией, доля успешных авторизаций с двухфакторной аутентификацией, доля машин с установленным обновлением не позже тридцати дней. Данные берут из логов автоматически.
Проверка бэкапов — раз в полгода. Выбирают случайную дату восстановления и полностью разворачивают виртуальную копию серверов на изолированной площадке. Восстановление должно занять не более времени, заявленного в регламенте, а данные должны быть целыми и консистентными.
Аудит подрядчиков — раз в год. Запрашивают отчёт о работе за двенадцать месяцев: количество закрытых инцидентов, среднее время реакции, критические уязвимости, найденные и устранённые. Отчёт сверяют с договорными значениями.
Что делать при инциденте
Проникновение часто замечают не сразу — злоумышленники могут находиться в сети неделями. Поэтому раз в месяц сканируют инфраструктуру на новые устройства, открытые порты и забытые учётные записи.
При обнаружении инцидента главное — не паниковать и не отключать всё подряд. Действуют по плану реагирования объёмом три-пять страниц. Первый шаг: изолировать заражённую машину — выдернуть кабель или отключить порт на коммутаторе. Второй: собрать доказательства — скриншоты, логи, дамп памяти. Третий: уведомить нужных людей — при утечке данных юристов и клиентов, при остановке работы руководство. Четвёртый: восстановить работу только из проверенного бэкапа.
Для быстрого реагирования назначают дежурного — одного человека на телефоне круглосуточно. В небольших компаниях эту роль берёт системный администратор с небольшой доплатой. Его задача — не решить проблему самостоятельно, а знать, кого разбудить ночью.
Подрядчики и внутренние силы: как не переплатить
Малый и средний бизнес редко содержит штатного офицера информационной безопасности. Задача решается комбинацией одного внутреннего ответственного и внешнего подрядчика по фиксированному перечню работ.
Договор строят по трём блокам.
Объём работ прописывают конкретно: внешнее сканирование уязвимостей — раз в квартал, внутренний тест фишинга — дважды в год, обновление политик — раз в год, проверка бэкапа на восстановление — раз в полгода. Любое действие вне списка оплачивается отдельно по фиксированному часовому тарифу.
Цена и сроки. Используют модель «фикс + лимит часов». Пример: базовый пакет — сто восемьдесят тысяч рублей в год, включая двадцать четыре выездных часа. Превышение оплачивается по договорному тарифу, но не более двадцати процентов от годового пакета. Это исключает неожиданные счета при инциденте.
Время реакции. Для критичных инцидентов (шифровальщик, утечка данных) прописывают час с момента обращения по дежурной линии. Для некритичных — четыре часа. За каждый час просрочки подрядчик предоставляет неустойку в размере пяти процентов от месячного платежа.
В договор включают пункт о передаче дел: все конфигурации, скрипты и пароли предоставляются в читаемом виде в течение пяти рабочих дней после расторжения. Это исключает «захват» инфраструктуры.
Перед подписанием проверяют подрядчика: запрашивают выписку из ЕГРЮЛ не старше тридцати дней, берут контакты двух клиентов аналогичного масштаба и уточняют среднее время реакции, проверяют наличие полиса страхования профессиональной ответственности на сумму не ниже одного миллиона рублей.
Годовой план-график: когда и что делать
Всю деятельность фиксируют в календаре — к каждому событию прикрепляют отчёт на одну-две страницы. За три года накапливается история, которую можно показать аудитору, страховой компании или крупному клиенту. Весь цикл занимает около двенадцати часов совещаний и шести-восьми часов технических работ в год.
Первый квартал: пересмотр модели угроз (совещание руководства плюс технический разбор), внешнее сканирование уязвимостей, проверка офлайн-бэкапа на восстановление в тестовой среде, первый фишинг-тест.
Второй квартал: обновление политик и регламентов, аудит прав доступа (уволенные, изменившие должность, внешние подрядчики), внутренний пентест по двум сценариям, проверка журнала инцидентов.
Третий квартал: учения команды инцидент-менеджмента (table-top exercise с директором, бухгалтером, юристом и ИТ), обновление всех паролей у подрядчиков и служебных учёток, проверка облачных сервисов, второй фишинг-тест с анализом динамики.
Четвёртый квартал: годовой пересмотр модели угроз, внешнее сканирование и проверка сертификатов TLS, акт приёмки бэкапа с подписью директора, подготовка бюджета на следующий год.
Как внедрить защиту без остановки бизнеса
Полная остановка компании ради настройки сетевых правил выглядит убедительно только в презентациях для совета директоров. В реальности остановка конвейера или отгрузка без накладных влечёт штрафы и потерю контрактов.
Внедрение начинают с ограниченного участка — подразделения, где риски уже оценены как средние, а операционная нагрузка позволяет экспериментировать без мгновенных потерь.
Быстрый аудит занимает пять рабочих дней: сканируют внешний периметр Nmap-ом, сверяют список активных сессий в каталоге, выгружают отчёты об обновлениях из централизованной консоли. Результат — таблица с тремя колонками: адрес, найденная слабость, приоритет закрытия. Оставляют только задачи, устранимые без закупки нового железа.
Пилотный запуск новых правил проводят на десяти-пятнадцати сотрудниках в течение недели. Замеряют не количество заблокированных угроз, а скорость выполнения типовых операций. Пользователи начинают жаловаться, когда двухфакторная аутентификация сбрасывается при каждом открытии браузера, а запрет на съёмные носители ломает ежедневную выгрузку отчётов в контролирующие органы. Правила упрощают на месте. Вместо полного блокирования портов разрешают передачу данных только через зашифрованные накопители, выпущенные самой компанией.
Поэтапное подключение остальных отделов занимает от месяца до квартала. Каждый новый блок получает ровно одну инструкцию: один экран, крупный шрифт, три шага действия. Длинные вебинары по кибербезопасности заканчиваются в корзине корпоративного портала.
Минимальный набор документов
Инспекторы, страховые компании и крупные клиенты запрашивают «доказательства зрелости процесса». Достаточно пяти документов, каждый не больше трёх страниц.
Политика информационной безопасности утверждается приказом генерального директора. Содержит цель, перечень критических активов, основные запреты и ответственность сотрудников. Обновляется раз в год.
Регламент управления доступом определяет, кто и на каком основании получает учётную запись, как часто меняются пароли, когда отключается доступ при увольнении. Приложение — таблица ролей и прав.
План реагирования на инциденты фиксирует шаги, которые выполняет дежурный в первый час: изоляция, сбор логов, уведомление, восстановление. Указаны телефоны и email ответственных. Хранится в печатном виде у дежурного и в электронном — в общей папке.
Журнал учёта инцидентов ведётся в Excel: дата, тип события, краткое описание, причина, меры устранения, подпись ответственного. Срок хранения — три года.
Акт приёмки резервной копии подписывается после каждого полугодового теста восстановления. Подтверждает, что бэкап развёрнут успешно и данные соответствуют ожидаемому состоянию.
Дополнительные документы заводят только по факту запроса регулятора или крупного контрагента. Все остальные «тома» создают по мере необходимости, а не заранее.
Как поддерживать систему в актуальном состоянии
Модель угроз и перечень защитных мер требуют регулярного пересмотра. Через полгода бизнес меняется: появляются новые процессы, уходят старые подрядчики, подключаются новые сервисы. Каждые шесть месяцев собирают исходную группу — генеральный директор, финансовый директор, ответственный за ИТ — и повторяют упражнение: проверяют, какие сценарии утратили актуальность, какие риски возникли впервые.
Один человек из ИТ или службы безопасности отвечает за обновления. Его задачи: раз в месяц просматривать логи и алерты, раз в квартал проводить короткое совещание и фиксировать изменения, раз в год пересматривать политики и план реагирования.
Обучение сотрудников продолжают короткими напоминаниями: раз в неделю — email с одним практическим советом, раз в год — тест на знание основных угроз. Кто не прошёл порог в восемьдесят процентов — получает индивидуальную повторную сессию.
Система остаётся эффективной, пока она простая и понятная. Сотрудник замечает подозрительное письмо и знает, кому сообщить без страха наказания. Руководитель запрашивает текущие риски и получает краткий отчёт вместо толстого тома. Защита встраивается в повседневные процессы и становится нормой, а не препятствием.
Документ живёт. Его правят после каждого инцидента, после смены вендора, после расширения штата. Модель угроз остаётся якорем — всё остальное подстраивается под неё.
Читайте нас в Telegram: https://t.me/seberd_ru