Комментарии 31
Скажите, а сертификация ФСТЭК гарантирует отсутствие недокументированных возможностей в сертифицированном ПО?
Например, ФСТЭК сказала, что недокументированной возможности выполнять код без авторизации нет, а завтра CVE в которой написано, что возможность есть.
Что происходит?
а) ФСТЭК признаёт, что лохи и не могут решить задачу остановки.
б) Роскомнадзор блокирует доступ к страничке CVE на митре.
в) Написавшего об этом сажают как экстремиста (на территории страны) или кормят следующими двумя буквами из таблицы Менделеева (за пределами).
г) Все делают вид, что так и должно быть.
Я не понимаю, какой из вариантов реализуется. Объясните мне, неразумному. Спасибо.
«11. Заявители должны обеспечивать соответствие сертифицированных средств защиты информации требованиям по безопасности информации, а также осуществлять устранение недостатков и дефектов средств защиты информации, в том числе устранение уязвимостей и недекларированных возможностей программного обеспечения средств защиты информации, информирование потребителей об обновлении программного обеспечения средств защиты информации, доведение до потребителей обновлений программного обеспечения средств защиты информации, а также изменений в эксплуатационную документацию».
Иначе действие сертификата будет приостановлено (из того же Приказа):
«83. Действие сертификата соответствия приостанавливается в случаях:
…
установления факта несоответствия сертифицированного средства защиты информации требованиям по безопасности информации на основании поступившей в ФСТЭК России информации, в том числе о наличии в сертифицированном средстве защиты информации уязвимостей или недекларированных возможностей;
…»
Поэтому, реализуется вариант «д», который у Вас не приведен:
д) Заявитель/производитель оперативно устраняет выявленную проблему в сертифицированном ПО.
Отлично! Софт с апдейтами.
Дано: apt get install qemu-system-x86. С апдейтами! Производитель оперативно устраняет выявленную проблему в несертифицированном ПО.
Дано: сертификат ФСТЭК. Всё то же самое, только с сертификатом.
И зачем нам тогда сертификат? И вся процедура сертификации, когда кто-то (всего лишь человечишка) так же тупит в сырцы как в них тупит и программист — к чему она?
Ведь сертифицирующие товарищи — они же даже баги не репортят. Т.е. пользы от ФСТЭК куда меньше, чем от первого попавшегося линтера или фаззи-тестера.
Зато сколько слов "должны".
Вот если я стану Президентом РФ, то я издам указ о том, что все ДОЛЖНЫ писать софт, который ДОЛЖЕН работать без багов. И все будут ДОЛЖНЫ писать софт без багов. ДОЛЖНЫ ДОЛЖНЫ ДОЛЖНЫ. И даже обязаны.
Голосовать ногами, а закон выполнять в минимально необходимой степени, чтобы отстали.
Обычно, в обществе, есть идея, что законы придумываются для того, чтобы людям жить лучше было, а бесполезные законы отменяют или даже не принимают в первую очередь.
… или я что-то за последние годы упустил в политике РФ?
Но сама система сертификации направлена на то, чтобы минимизировать такие риски.
Но ведь процесс получения сертификата ФСТЭК замедляет выход обновлений, из-за чего сертифицированное ПО всегда немного устаревшее и дырявое.
Или я чего-то пропустил, и всё давно поменялось?
Согласно определению ФСТЭК они ищут:
2.1. Недекларированные возможности — функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации (ссылка на РД).
А вы говорите про уязвимости программного обеспечения, на которые ФСТЭК не смотрит от слова совсем.
Если бы ФСТЭК вместо производителя проверял на наличие уявимостей и работоспособность ПО, то кол-во сертифицированных средств защиты было бы близко к нулю.
О! А расскажите мне, в чём разница между RCE-CVE и бэкдором? А между бэкдором и хардкоженным паролем Pa$$w0rd в устройстве? А между хардкоженным паролем и немного странной константой для криптоалгоритма?
Кроме того, я не понимаю, как можно искать недокументированные возможности не читая исходный код. А если они читают исходный код, то это code review и он должен баги ловить.
Вы неправильно трактуете термин «недокументированные». В понимании ФСТЭК это функции, которые отсутствуют в переданной им документации к коду или функции, которые этой документации не соответствуют и могут нарушить конфиденциальность, доступность или целостность.
Цель, которую преследует сертификация – это подтверждение того факта, что производитель не получит доступ и/или не передаст такой доступ заинтересованным лицам.
Сертификация — это попытка решения проблемы доверия к ПО или программно аппаратному комплексу, который вы будете использовать при работе с защищаемыми данными.
Проверка всего остального это задачи бизнеса, проходящего сертификацию. Потому что от этого зависит в том числе и брэнд, и репутация компании и к ФСТЭК не имеет никакого отношения. Но по факту очень мало кто занимается полным циклом разработки безопасного программного обеспечения. И основное требования бизнеса как правило звучит как:«вот мы продали, поставка завтра, как вы это организуете нас не волнует».
Исходя из определения «Backdoor» — это целенаправленное встраивание разработчиком функций, позволяющих получить доступ к управлению «продуктом» или получению доступа к данным.
RCE-CVE — исполнение произвольного кода, и тут далеко не всякий RCE позволяет получить доступ к управлению или доступ к данным. Например, «js injection» это тоже RCE.
Backdoor и захордкоженный Pa$$w0rd – одно и то же по определению (см. выше), туда же ваш пример про пароль и константу криптоалгоритма, но последним занимается ФСБ.
Надеюсь, что смог немного прояснить для вас ситуацию.
Я не понимаю разницы. Если у нас есть zero-day RCE (и не js-что-то, а прям натуральный RCE — прислали без авторизации хитрый utf8 — получили рута), то чем он отличается от забытого тестового аккаунта? В обоих случаях человек, знающий магическую последовательность из какашек и символов цвета кожи может выполнить свой код на чужом оборудовании.
Дальше мы можем начать классифицировать их как "умышленные" и "неумышленные". Но тестовые аккаунты (привет, Циска) забывают тоже по небрежности, совершенно такой же, как и проверку на размер буффера в Си.
Т.е. я не понимаю от чего защищает сертификация и чем сертифицированное ПО от несертифицированного отличается.
Дано:
1. Вы государство с растущей информатизацией и информацией уровня секретно и выше;
2. НИИ/ФГУП и тд. силовых ведомств не могут производить оборудование и ПО для организации необходимой инфраструктуры, как следствие вы не доверяете всему спектру ПО/ПАК на рынке;
3. Организация всех взаимодействий на закрытых каналах связи (прямые охраняемые линии) без доступа к общественным сетям невозможна, так как необходимо взаимодействие как минимум с юр. лицами.
Задача:
Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа.
Предложите ваше решение.
За качество и защищенность ПО/ПАК отвечает разработчик этого ПО/ПАК. И как отметил представитель КРОК выше, сертифицируясь разработчик принимает на себя ответственность и обязательства в исправлении найденных уязвимостей, в противном случае он лишается лицензии и всех заказов со стороны государства и коммерции, которую обязали обмениваться данными с государством посредством сертифицированных версий (а это очень большие суммы).
В несертифицируемом ПО/ПАК вы полностью доверяете разработчику и принимаете все риски, связанные с его безопасностью и как покупатель не можете повлиять на наличие выхода обновлений безопасности. В случае обнаружения RCE вы будете принимать решение о дальнейшем использовании ПО/ПАК или переходе на новое, что вызовет дополнительные траты.
Я хотел бы обозначить свою позицию, я не призываю пользоваться везде сертифицированными версиями и не пытаюсь вас склонить к этому (хотя идея идеального «реестра безопасного ПО/ПАК» мне немного импонирует, но как обычно реализация всегда вызывает вопросы). Сертификация нужна, по моему мнению, только в гос. структурах и для взаимодействия с ним, что порождает низкое качество сертифицированных ПО/ПАК в ввиду почти полного отсутствия конкуренции.
Задача: Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа.
Решение тривиально: решаем задачу останова, с помощью решённой задачи автоматически валидируем на правильность весь код в системе.
Если решить задачу останова руки коротки, то цель "Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа." недостижима.
Дальше можно сколько угодно делать магические пассы руками, но в стандарте языка Си сказано, что шаг влево, шаг в право — undefined behaviour, в том числе и всё самое страшное, что вы можете себе представить. Вот с этим и живём.
Рядом есть cox, но с его помощью полного стека (ОС, компилятор и т.д.) никто ещё не написал.
Это, как если бы у производителей продуктов представители Роспотребнадзора проверяли каждую партию и следили за качеством продукции и точности состава. Очень удобно для бизнеса, зачем тратиться на свой отдел контроля качества, когда все это делает за вас государство.
Так, же к своему невежеству прошу вас объяснить, что вы понимаете под «задачу останова» (поскольку вы говорите о ней, а подразумеваете SDLC)? В моем понимании «задача останова» формулируется как определение завершится ли задача когда-либо при определенных исходных данных. SDLC – оно несколько по другое, оно про написание кода исключающего возможность эксплуатации уязвимостей. Специалисты в этой области получают довольно высокий оклад и далеко не все компании могут позволить себе таких специалистов. Вы же предлагаете это полностью переложить на государство.
Если я правильно понимаю, то вы хотите следующую схему:
1. программисты «вашей» компании пишут любой код с любыми RCE;
2. вы направляете этот код в ФСТЭК;
3. ФСТЭК делает подробный анализ вашего кода, составляет полный отчет и направляет обратно;
4. Цикл повторяется любое кол-во раз пока вы не пройдет «сертификацию».
У меня вопросы:
1. за чей счет сей банкет?
2. почему вы перекладываете ответственность за ваш «продукт» на государство?
У вас есть задача: " Построить инфраструктуру так, чтобы защитить информацию и исключить возможность несанкционированного доступа.". Вы ее выполнили в силу своего разумения (пусть и хорошего и грамотного) на открытом ПО. Выходит 0day уязвимость и вашу систему успевают вальнуть.
Начинается разбор полетов. Приходят компетентные органы и спрашивают «А что вы предприняли, чтоб защитится?»
-Ну я поставил, то се и вот это вот.
— А с чего вы взяли, что это все от чего то защищает и вообще безопасно?
— Ну я так решил на основании отзывов в сети, анализа кода и т.д.
-Ага! То есть ты решил — вот тебе и отвечать! Посиди ка троечку колонии поселения.
А при сертифицированном ПО диалог пойдет по другому.
-Ну я поставил, то се и вот это вот.
— А с чего вы взяли, что это все от чего то защищает и вообще безопасно?
— Ну на все это есть сертификаты ФСТЭК и оно закрывает уязвимости из перечня ФСТЭК. Вот бумажки.
— Ну чтож меры защиты были приняты, вины админа нет.
Вот только ради этого вся эта сертификация и существует.
Как пользователь может поставить апдейт, если на него ещё сертификата ФСТЭК не готово?
Но то, что для пользователей доступны обновления в обычных версиях не значит, что их обновят. Серверное ПО обновляется администратором например и у нас огромное количество пользователей на древних версиях. Не ставят и остаются уязвимыми
Не всегда сертификаты бесполезны. К примеру pcidss четко регламентирует как часто должно происходить обновление по и с каких репозиториев, как реагировать на cve и т.д. Т.е. риск того что на сервере будет стоять трехлетней давности nginx, как часто бывает, сводится к нулю.
Что-то не понял как из того что оператор обеспечивает безопасность следует возможность забить болт на угрозы второго типа. Тем более что определять актуальность угроз, насколько я помню, нужно по вполне такой формальной методике, а не "аа, да нормально всё будет, давайте забьём".
«И так сойдет»: что облачные провайдеры не договаривают о персональных данных