Векторы атак и поверхность атаки
Вектор атаки — путь, по которому угроза достигает актива; поверхность атаки — совокупность доступных точек. Чем больше интернет-сервисов, устройств, интеграций и людей, тем больше путей нужно контролировать. Инвентаризация — основа: неизвестный актив нельзя надёжно патчить или мониторить.
Частые векторы
Фишинг использует письмо, ссылку или вложение, чтобы украсть учётные данные, запустить код или заставить перевести деньги. Spear phishing адресован конкретному человеку, whaling — руководителю, а business email compromise часто обходится без малвари. Защита: SPF/DKIM/DMARC, фильтрация, sandbox, MFA и процедура обратной проверки платежей.
Message-based атаки шире электронной почты: SMS (smishing), мессенджеры, QR-коды и голосовые сообщения. Пользователь видит знакомый бренд, но ссылка ведёт на поддельный домен. Не полагайтесь только на визуальный текст: проверяйте URL, контекст и канал подтверждения.
Supply chain атакует поставщика, библиотеку, обновление или процесс сборки. Компрометация доверенного компонента опасна именно тем, что его разрешили заранее. Нужны SBOM, подпись артефактов, pinning версий, проверка репозитория, отдельные среды сборки и мониторинг изменений.
Уязвимое ПО включает не только известную CVE: слабая конфигурация, устаревшая библиотека, открытая панель и дефолтный пароль тоже создают вход. Сканирование, приоритизация по эксплуатируемости и управляемое исправление полезнее «патчить всё одинаково».
Управление поверхностью
Создайте каталог доменов, API, облачных ресурсов, рабочих станций, SaaS и поставщиков. Для каждого укажите владельца, данные, внешний доступ, версию, MFA и дату проверки. Удаляйте забытые тестовые экземпляры и закрывайте неиспользуемые порты.
Для веб-сервиса модель угроз выглядит так: пользовательское сообщение ведёт на фишинговый сайт, похищенный токен открывает VPN, затем отсутствие сегментации даёт доступ к базе. Слои должны разорвать цепочку: фильтр и обучение, phishing-resistant MFA, device posture, NAC/сегментация, WAF и мониторинг.
# только в своей инфраструктуре: обзор слушающих портов
ss -tulpen
# проверка версии установленного пакета Debian
dpkg-query -W openssl
Проверяйте не только «есть ли контроль», но и исключения. Внешний сканер, тест восстановления и учения по фишингу показывают разницу между документацией и реальным состоянием.
Уменьшение пути атаки
Для каждой точки задайте превентивный, детективный и корректирующий контроль. Письмо фильтруется, подозрительная ссылка создаёт тревогу, а скомпрометированный аккаунт быстро блокируется. В цепочке поставок проверяйте хэши и подписи, ограничивайте CI-токены и требуйте review зависимостей.
Управляйте внешними сервисами непрерывно: DNS и сертификаты меняются, временный облачный ресурс может стать публичным, а забытый API — принять старую версию библиотеки. Автоматический discovery полезен, но владелец всё равно должен подтвердить назначение актива.
Tabletop-упражнение «фишинговое письмо от поставщика» проверяет сразу почту, help desk, MFA, платежный процесс, SOC и коммуникации. После него исправьте конкретные шаги, а не ограничивайтесь новым семинаром.
Практическое задание
Закрепите тему на собственной тестовой схеме, не затрагивая рабочие системы. Сначала опишите активы и доверенные границы простыми словами, затем укажите владельца каждого решения. Для каждого риска запишите вероятность, последствия, существующий контроль и остаточный риск. Такой короткий реестр полезнее списка модных продуктов: он показывает, какую именно задачу решает мера и где остаётся пробел.
Проведите проверку в безопасной лаборатории и сохраните результат: время, команду или действие, ожидаемый результат и фактическое наблюдение. Если проверка не удалась, сначала проверьте разрешение, область теста и журналирование, а не усиливайте настройки вслепую. Любое исключение оформите с причиной, сроком и ответственным.
При разборе инцидента отделяйте факт от гипотезы. Факт подтверждается журналом, конфигурацией или воспроизводимым тестом; гипотеза требует дополнительной проверки. Это снижает риск неправильной атрибуции и помогает команде выбрать пропорциональную реакцию. После изменения контроля повторите тест и убедитесь, что доступность бизнеса не пострадала.
Полезный результат обучения — не запомнить термин, а уметь объяснить его на сценарии: какая угроза действует, какой актив затронут, какой контроль сработает первым, что обнаружит событие и как восстановиться. Именно такую цепочку проверяйте при подготовке к Security+.
Вопросы для самопроверки
Проверьте себя по сценарию. Какой актив защищается и какое свойство CIA важнее всего? Где проходит граница доверия? Как злоумышленник может получить первоначальный доступ, какое событие подтвердит гипотезу и кто принимает решение о сдерживании? Затем назовите как минимум один технический, один административный и один физический контроль. Для каждого укажите, является ли он превентивным, детективным или корректирующим, и какое доказательство эффективности можно получить.
Отдельно продумайте исключения. Что произойдёт, если основной сервис, каталог идентичностей или канал связи недоступен? Запишите ручную процедуру, резервный контакт и безопасный способ возврата к нормальной работе. Не забывайте о приватности: журналы должны содержать достаточно контекста для расследования, но не раскрывать пароли, токены и лишние персональные данные.
Хороший ответ Security+ связывает термин с решением и ограничением. MFA уменьшает риск украденного пароля, но не устраняет вредоносную конечную точку; резервная копия ускоряет восстановление, но не предотвращает утечку; IDS обнаруживает, но требует реакции. Такая причинно-следственная цепочка помогает выбирать правильный контроль в практическом вопросе. **Дисклеймер: материал учебный и не заменяет официальные exam objectives CompTIA.
Комментарии