Оценка уязвимостей — ключевой этап в процессе проведения тестирования на проникновение, целью которого является выявление слабых мест в информационных системах. Для стандартизации и упрощения процесса оценки часто используется методика CVSS (Common Vulnerability Scoring System) — общепринятая система оценки уязвимостей.

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

▫️Базовые метрики определяют первоначальную оценку уязвимости и включают такие параметры, как:

🔸Вектор атаки (Attack Vector, AV) — способ, которым атакующий может эксплуатировать уязвимость (например, локально или удаленно).

🔸Сложность атаки (Attack Complexity, AC) — уровень сложности, необходимый для успешной эксплуатации.

🔸Привилегии, необходимые для эксплуатации (Privileges Required, PR) — уровень доступа, необходимый атакующему.

🔸Пользовательское взаимодействие (User Interaction, UI) — необходимость участия пользователя для успешной атаки.

🔸Воздействие на конфиденциальность, целостность и доступность (Confidentiality, Integrity, Availability Impact) — потенциальные последствия для системы в случае успешной атаки.

▫️Временные метрики учитывают временные аспекты уязвимости, такие как наличие исправлений или уровень осведомленности о ней.

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

Использование CVSS в тестировании на проникновение позволяет объективно оценить уровень риска, связанный с выявленными уязвимостями, и приоритизировать их исправление. Это помогает организациям эффективно распределять ресурсы и принимать информированные решения по безопасности.

#Pentesting

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

Принцип работы «соли»:

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

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

Основные задачи, которые помогает решить «соль»:

▫️Защита от радужных таблиц: использование радужных таблиц (базы данных с предварительно вычисленными хэшами популярных паролей) становится бесполезным, так как добавление «соли» меняет результат хеширования.

▫️Минимизация рисков:

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

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

Существует два основных типа «соли»:

▫️Статическая – это одна и та же «соль», которая используется для всех пользователей системы и обычно хранится в коде приложения или в конфигурации.

▫️Динамическая
(или персонализированная) – это «соль», которая генерируется индивидуально для каждого пользователя и добавляется к его паролю перед хешированием и хранится в базе данных вместе с хешем пароля.

#ИБ
#ПолезноЗнать

Вопрос:

Какие требования PCI DSS v.4.0 к шифрованию данных нужно выполнить в 2025 году?

Ответ:

31 марта 2022 г. был опубликован стандарт PCI DSS v.4.0, в котором обновились требования по обеспечению безопасности при защите данных платежных карт, в том числе в отношении шифрования. Часть требований вступает в силу с 31 марта 2025 г., среди которых:

▫️Шифрование данных при их хранении и передаче
Данные держателей карт должны быть защищены как при хранении, так и при передаче через публичные сети. Использование шифрования является обязательным.

▫️Управление ключами
Запрещается использовать одни и те же ключи в производственных и тестовых средах. Кроме того, необходимо применять одобренные генераторы случайных чисел.

▫️Критичные аутентификационные данные
Все важные аутентификационные данные (например, PIN, CVC2), хранящиеся до момента авторизации транзакции, должны быть защищены с использованием шифрования.

▫️Ограничения на шифрование на уровне диска
Шифрование на уровне диска разрешается только для съёмных носителей; в других ситуациях должны быть применены дополнительные меры по обеспечению безопасности данных.

▫️Контроль сертификатов
Необходимо регулярно проверять актуальность сертификатов, используемых для защиты информации при её передаче.

Следует учесть, что с 1 января 2025 г. вступят в силу требования, изложенные в Указе Президента РФ № 250, в части импортозамещения решений по защите информации из недружественных стран. Указанные требования распространяются, помимо прочих, на субъекты КИИ, функционирующие в банковской сфере и иных сферах финансового рынка.
Соответственно, субъектам КИИ при реализации требований PCI DSS 4.0 рекомендуется обратить внимание на положения Указа Президента РФ № 250 об импортозамещении и подбирать подходящие решения.

#ИБ
#KeptОтвечает