Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 9
Это не так. Сертификат не делает тебя неуязвимым! И это, пожалуй, главная проблема в мышлении российских вендоров.
По моему, это главная проблема специалистов СИБ. Особенно в банках. По принципу “бумажка есть - попа прикрыта”.
Когда требуют формального “сканер не должен показывать уязвимости”. И бесполезно доказывать, что
эта конкретная “уязвимость” вообще и в принципе в данном ПО не может быть использована.
“ставьте новую версию либы” - это спрятаться от проблем. Потому что “в новой версии opensource либы сканер не показывает уязвимости” - это не потому, что их там нет. А потому что не успели найти (или что хуже, успели, но используют втихушку).
Хороший способ нашли некоторые крупные вендоры (не буду пальцем тыкать). Берут ветку opensource и собирают из нее свою либу, меняя ключевые тэги/версии. Сканеры стандартные их воспринимают как “все идеально”. У СИБ все формально идеально. “Все хорошо прекрасная маркиза”.
продукт получил сертификат ФСТЭК
Ага. то же по формальным признакам проверяют. И привязываются к “у вас тут код написать чуть другому надо”. Настолько мелкие вкусовые и стилистические “пожелания”, что прям понимаешь как старались найти к чему бы придраться, не вникая в сущность того что ПО то делает.
Даже местами можно догадаться через какую LLM прогоняли.
LLM часто тупые советы дают. Типа предлагая заменить функцию поиска через перебор (< 10 элементов по определению/контексту задачи) на HashMap. Типа есть формальные оценки по algorithm time complexity и все. А все остальное не учитывать.
В любом случае нужно каждую уязвимость проецировать на модель угроз - возможно ли её применить в данном конкретном случае, даже не в привязке к конкретному ПО, а к конкретной системе, инфраструктуре, обрабатываемых данных. И даже в случае применимости уязвимости нужно смотреть на её трендовость. Если уязвимость не трендовая, то вероятно ей смогут воспользоваться только при целенаправленной (APT) атаке. Но если есть задача целенаправленной атаки, то в 80% случаев всё решается социальной инженерией / инсайдерством без задействования сложных технических схем.
Плюсую!
На практике это бесполезно. Пишешь длинное описание почему конкретно эта уязвимость, найденная сканером, в принципе не может быть задействована в этом конкретном ПО. В результате “а у нас сканер показал. Сделайте что бы не показывал”. И хоть тресни и ничего не докажешь. Проще сделать формально правильно, но по сути хуже с точки зрения безопасности. А не бороться с ветряными мельницами.
А сертификат ФСБ… на крипто ПО… Ну ну. Как то нужно было разобраться с внутренним протоколом обмена одного крипто ПО, навязываемого ЦБ (кто знает, тот знает) :facepalm Пароль к секретному ключу в открытом TCP/IP канале ходил “зашифрованным” по XOR (!) одним константным(!) байтом (!).
Сертификации…
Я прям чувствую боль в этих словах) Тяжело не согласиться, так же тяжело для понимания, почему у нас отечественные вендоры не все стоят на платформах багбаунти, где подобные кейсы можно отловить (хотя поэтому наверное и не выходят)
В документе НКЦКИ прописаны важные оговорки:
если эксплуатацию уязвимости можно предотвратить наложенными средствами защиты, с обновлением такого ПО лучше не торопиться;
если специалисты компании могут сами проверить обновление на недекларированные возможности, решение стоит принимать на основе собственного анализа;
Если это действует, если регуляторы это воспринимают, то это здорово.
Спасибо за статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление уязвимостями по-русски: ФСТЭК, БДУ, приказ № 117 и почему обновление стало риском