...при сертификации не ищутся уязвимости - она всего лишь подтверждает
функционал продукта и его соответствие требованиям регулятора.
Алексей Лукацкий
Отличный пост Алексея: все подробнейшим образом рассказано, объяснено, даны ссылки на руководящие документы, ... - методически и систематически все на высшем уровне.
Но почему-то остается ощущение какого-то чеквалапства: создана целая система, потребляющая немало инвестиций, однако выхлоп - небольшой. Попробую разобраться.
Есть, например, такое требование: "МЭ должен обеспечивать идентификацию и аутентификацию администратора МЭ при его локальных запросах на доступ". Аутентификация, с точки зрения их же, регуляторов, терминов: "Проверка принадлежности субъекту доступа предъявленного им идентификатора; подтверждение подлинности". Можно предположить, что принадлежащим субъекту идентификатором в контексте данного определения считается пароль, который пользователь сам себе назначил (==известен только ему). Из чего, несложно понять простую логику: если пользователь проходит проверку принадлежности ему идентификатора, предъявляя системе идентификатор (пароль), ему не принадлежащий, то такое поведение системы нельзя считать обеспечением аутентификации. Говоря совсем просто: аутентификация, работающая с ошибкой, приводящей к НСД, не может называться аутентификацией, ибо сама по себе нужна лишь для того, чтобы НСД не было. Итого: в устройстве нет аутентификации, подтверждение ее наличия сертификатом - ошибка, из которой надо извлечь соответствующие уроки...
Конкретно в этом случае все было еще хуже, приведу цитату: "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", так как я во-первых, предъявляя не свой пароль успешно аутентифицируюсь, а во-вторых, после этого я еще и авторизуюсь максимальным админом, ну, как минимум, не с полномочиями, указанного при аутентификации аккаунта.
... но вернемся к извлеченным урокам....
Вообще, внедряя процесс и инвестируя в него, необходимо всегда помнить цель, не надо инвестировать в тот процесс, который не приводит к цели, или степень приближения к цели не оправдывает инвестиций. Цель сертификации - подтверждение качества товара, защита потребителя. Если какой-то из видов сертификации этой цели не достигает, или достигает
ЗЫ: вот и Фортинет порадовал. Я когда-то в шею гнал разработчиков, хардкодящих пароли, а вот, оказывается, это общая практика....
7 comments:
>>> Можно предположить, что принадлежащим субъекту идентификатором в контексте данного определения считается пароль
Нельзя так предположить smile emoticon Ибо идентификатором является имя пользователя, а вовсе не пароль. А пароль как раз используется для подтверждения правомочности доступа к учетной записи с данным именем.
Точно, ВоВ, так и есть, вы правы!
А я-то думал, чего это они аутентификатор "идентификатором" обзывают....
Однако суть не меняется - аутентификация не работает, поскольку секретный пароль позволяет успешно аутентифицироваться с любым идентификатором (именем аккаунта)
Или, по-вашему, аутентификация есть (так как это подтверждено сертификацией), просто она работает, скажем, неправильно?
Тут можно рассуждать долго.
Например, по утверждению высший уровень привилегий получается с любым юзернеймом и данным конкретным паролем. В этом случае юзернейм, так выходит, перестает быть идентификатором, поскольку он может быть любым, и даже не зарегистрированным в системе. Упс :) И вот этот конкретный пароль именно что становится идентификатором пользователя с высшими привилегиями, который используется без аутентификации. Забавно, правда? :)
Тем не менее, все-таки есть некоторая функциональность позволяющая отличить одного пользователя от другого, правда? Есть зарегистрированные пользователи, есть пары логин-пароль, которые позволяют проводить аутентификацию и авторизацию пользователей. Но есть и некоторый "волшебный" идентификатор, который распознает система, дающий максимальные привилегии без аутентификации.
То есть аутентификация безусловно есть и работает "by design", если можно так выразиться. То есть нельзя говорить о том, что такая функция отсутствует. "Но, Петька, есть нюанс" (с)
Это как раз и есть недекларированная возможность, а не отсутствие функции. Вот.
Любую уязвимость, умышленную или неумышленную, можно свести к НДВ. Чем уязвимость к переполнению буфера с последующим RCE не НДВ? А раз так, то и надо оставить только сертификацию на НДВ, я об этом явно в посте сказал.
Сейчас мы имеем, что сертификация не решает своей прямой задачи - защиты меня, потребителя, от некачественной продукции, однако это оправдывается типа "для таких случаев у нас есть другая сертификация". А зачем тогда эта? Подтвердить мне, что покупаемый мною продукт - фаервол, так мне это не надо. Тем не менее - вендоры тратят средства на проведении таких сертификаций, есть фирмы которые на сделали бизнес на сертификации, потребители продолжают стремиться покупать такие сертифицированные продукты, хоть они и дороже... - есть целый пласт деятельности со стороны всех участников рынка, в общем-то, пустой. Может, все занятые этим ресурсы перебросить на более продуктивные задачи? Давайте оставим только сертификацию на отсутствие НДВ, давайте сделаем ее лучше, давайте построим процесс отзыва сертификатов после проколов (у нас же отнимают водительское удостоверение в результате определенных нарушений, хотя, по факту, в результате нарушения мы не стали хуже водить автомобиль или знать ПДД), давайте после каждого инцидента пересматривать подходы к сертификации, построим цикл Деминга.... Давайте подходить к вопросу не формально, а преследуя цель, анализируя, что наши действия к цели приближают.
Сейчас же просматривается именно формальный подход: сертификация - нужна, значит - есть; сертифицированный, значит - хороший и т.п. и такой формальный подход приводит исключительно к бездумному формальному подходу в целой отрасли:
- люди занимаются аттестацией своих информационных систем ради аттестата,
- люди покупают сертифицированные неизвестно на что (по ТУ) продукты, хотя они и дороже,
- люди покупают поверх вендорских лицензий дополнительные "пакеты сертификации" и думают, что этим они защитились от ошибок/закладок вендора;
- люди занимаются разработкой документации исключительно радии наличия этой документации;
- внутренняя нормативная база пишется для того, чтобы была
- ....
Давайте разорвем порочный круг формального подхода к вопросам безопасности и будем подходить к ним с позиции практики, чтобы любые наши действия имели практическую ценность. Важен же результат, а не процесс...
Post a Comment