Оценка уязвимостей — ключевой этап в процессе проведения тестирования на проникновение, целью которого является выявление слабых мест в информационных системах. Для стандартизации и упрощения процесса оценки часто используется методика 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Отвечает

NIST Cybersecurity Framework (CSF) 2.0 – фреймворк по информационной безопасности (ИБ) от Национального института стандартов и технологий США (NIST). Версия 2.0 была опубликована в феврале 2024 года. Ранее мы рассказывали о фреймворках по ИБ.
CSF 2.0 представляет собой описание целевого состояния ИБ в организации и может быть использован компаниями любых размеров и направлений деятельности ввиду гибкости внедрения представленных рекомендаций.

Фреймворк состоит из 6 ключевых разделов:

1️⃣Управление (Govern) – комплексный взгляд на жизненный цикл управления рисками ИБ.
2️⃣Идентификация (Identify) – определение ресурсов, которые необходимо защищать.
3️⃣Защита (Protect) – разработка и внедрение мер защиты ресурсов для минимизации рисков ИБ.
4️⃣Обнаружение (Detect) – обнаружение и анализ событий ИБ.
5️⃣Реагирование (Respond) – управление инцидентами ИБ.
6️⃣Восстановление (Recover) – восстановление нормальной работы после инцидента.

При внедрении фреймворка следует учитывать следующее:

1️⃣Адаптация рекомендаций
Стандарт рекомендует расставлять приоритеты в области обеспечения ИБ для принятия обоснованных решений о расходах на ИБ и действиях по внедрению стандарта.

2️⃣Интеграция с другими системами
Для создания единой экосистемы безопасности важно обеспечить совместимость с другими фреймворками и стандартами, используемыми в компании, например, ISO 2700X, CIS Controls.

3️⃣Автоматизация процессов
Внедрение инструментов автоматизации способствует повышению эффективности многих процессов обеспечения ИБ, например, повышение осведомленности, управление уязвимостями, реагирование на инциденты.

NIST Cybersecurity Framework (CSF) 2.0 является хорошей методической базой для построения ИБ в компании, однако следует помнить, что стандарт не содержит подробное описание шагов для достижения целевого состояния ИБ. Для эффективного ИБ в компании требуется комплексный подход: необходимо грамотное распределение ресурсов, компетентные специалисты, актуальные меры и средства защиты, а также постоянство обеспечения ИБ.

#ИБ