Уязвимость: что это такое, какие бывают виды и как их находить

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

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

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

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

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

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

Какие бывают уязвимости

Уязвимости удобно классифицировать по месту возникновения. Программный дефект появляется в коде приложения, ОС, библиотеки или драйвера. Это могут быть ошибки работы с памятью, инъекции и неправильная проверка прав. Такой недостаток иногда позволяет выполнить чужой код, прочитать закрытые сведения или повысить привилегии.

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

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

К распространенным категориям относятся:

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

Почему появляются слабые места

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

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

Особая ситуация — уязвимость нулевого дня. Обычно так называют ранее неизвестную вендору уязвимость, для которой на момент обнаружения или эксплуатации еще нет официального исправления. Если злоумышленники используют ее до появления патча, говорят о Zero-day атаке. Выражение Zero-day буквально передает идею «нулевой день»: времени на подготовку исправления не было. Здесь особенно важны сегментация, контроль поведения процессов и ограничение привилегий.

Как оценивают опасность

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

Для известных проблем применяют CVE и CVSS:

• CVE (Common Vulnerabilities and Exposures) позволяет однозначно идентифицировать публично раскрытую уязвимость.
• CVSS (Common Vulnerability Scoring System) помогает оценить ее техническую серьезность по стандартизированной шкале от 0 до 10. Такая оценка показывает технический уровень серьезности, но не заменяет оценку бизнес-риска.

В CVSS 4.0 используются четыре группы метрик:

1. Base Metrics;
2. Threat Metrics;
3. Environmental Metrics;
4. Supplemental Metrics.

Base описывает технические характеристики проблемы, Threat — актуальность эксплуатации, Environmental — особенности конкретной среды. Supplemental-метрики дают дополнительный контекст, но сами по себе не изменяют балл CVSS.

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

В российской практике сведения также сопоставляют с БДУ ФСТЭК. Банк данных содержит информацию об угрозах и уязвимостях, которую используют при анализе защищенности и выборе мер реагирования. ФСТЭК применяет БДУ как один из источников сведений при работе с уязвимостями.

GigaChat — генерация картинок,
текстов и многого другого

Попробовать в браузере

Встраивайте GigaChat API в свои проекты

GigaChat 2 Lite

GigaChat 2 Pro

GigaChat 2 Max

900 000 токенов для генерации текста за 0₽

12 месяцев

Еще тарифы

Попробовать GigaChat API

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

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

• SAST (Static Application Security Testing) исследует исходный код и, в зависимости от инструмента, его промежуточное или скомпилированное представление без запуска приложения.

• DAST (Dynamic Application Security Testing) проверяет уже работающее приложение снаружи.

• SCA (Software Composition Analysis) помогает контролировать сторонние библиотеки и зависимости.

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

• Сканер уязвимостей автоматизирует проверку: определяет доступные сервисы и версии компонентов, сопоставляет их с базами известных проблем, ищет часть ошибок конфигурации. В англоязычной документации встречается слово scanner или scanners. Результаты нужно проверять: программа может дать ложное срабатывание, пропустить проблему или не распознать дефект бизнес-логики.

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

1. провести инвентаризацию активов и определить внешние сервисы;
2. запустить сканирование и проверку зависимостей;
3. вручную проверить наиболее опасные находки;
4. сопоставить их с CVE, критичностью активов и доступными исправлениями;
5. назначить владельцев задач и сроки;
6. после изменений выполнить повторную проверку.

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

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

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

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

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

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

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

Типовой сценарий — SQL-инъекция. Некорректная обработка входных параметров может позволить выполнить нежелательный запрос к базе данных и раскрыть данные. Защита строится на параметризованных запросах, минимальных правах учетной записи базы данных и корректной обработке входной информации.

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

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

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

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