Сертификация аутентификации

...при сертификации не ищутся уязвимости - она всего лишь подтверждает функционал продукта и его соответствие требованиям регулятора.

Алексей Лукацкий

Отличный пост Алексея: все подробнейшим образом рассказано, объяснено, даны ссылки на руководящие документы, ... - методически и систематически все на высшем уровне.

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

Есть, например, такое требование: "МЭ должен обеспечивать идентификацию и аутентификацию администратора МЭ при его локальных запросах на доступ". Аутентификация, с точки зрения их же, регуляторов, терминов: "Проверка принадлежности субъекту доступа предъявленного им идентификатора; подтверждение подлинности". Можно предположить, что принадлежащим субъекту идентификатором в контексте данного определения считается пароль, который пользователь сам себе назначил (==известен только ему). Из чего, несложно понять простую логику: если пользователь проходит проверку принадлежности ему идентификатора, предъявляя системе идентификатор (пароль), ему не принадлежащий, то такое поведение системы нельзя считать обеспечением аутентификации. Говоря совсем просто: аутентификация, работающая с ошибкой, приводящей к НСД, не может называться аутентификацией, ибо сама по себе нужна лишь для того, чтобы НСД не было. Итого: в устройстве нет аутентификации, подтверждение ее наличия сертификатом - ошибка, из которой надо извлечь соответствующие уроки...

Конкретно в этом случае все было еще хуже, приведу цитату: "The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify any username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges", так как я во-первых, предъявляя не свой пароль успешно аутентифицируюсь, а во-вторых, после этого я еще и авторизуюсь максимальным админом, ну, как минимум, не с полномочиями, указанного при аутентификации аккаунта.

... но вернемся к извлеченным урокам....
Вообще, внедряя процесс и инвестируя в него, необходимо всегда помнить цель, не надо инвестировать в тот процесс, который не приводит к цели, или степень приближения к цели не оправдывает инвестиций. Цель сертификации - подтверждение качества товара, защита потребителя. Если какой-то из видов сертификации этой цели не достигает, или достигает не нужной не той цели, в ней нет смысла => ее надо или изменить, или отменить. Если любая из заявленных функций может быть скомпрометирована наличием НДВ, так давайте оставим только сертификацию на НДВ. Отзыв сертификатов, при этом, - тоже нормальное решение ("не пойманный - не вор" - неподходящий в этом случае принцип), если практика показала, что в сертифицированном на НДВ продукте все-таки нашлись НДВ, логичны два последствия: а) отзыв сертификата, б) lessons learned для процесса сертификации - это нормально, так как ничего не стоит на месте и подходы к сертификации подтверждению качества продукта также должны эволюционировать.

ЗЫ: вот и Фортинет порадовал. Я когда-то в шею гнал разработчиков, хардкодящих пароли, а вот, оказывается, это общая практика....