В ходе нагрузочного тестирования на сервере чуть выше начального уровня с процессором Хeon E5-2650 v2 2.60GHz (10 ядер) и 32 Гб ОЗУ была получена скорость обработки событий порядка 5500 EPS (запись событий и индексов).
Подождите-подождите, но ведь ещё в предыдущих версиях вашего продукта, Комрад 2 и Комрад 3 (судя по Tadviser ещё 2016 году) вы доблестно отрапортовали не о 5500 EPS, а в 2 раза больше, о целых 10 000 EPS на абсолютно такой же (сюрприз-сюрприз!) серверной конфигурации:
производительность: до 20 000 EPS. 10 000 EPS на серверной платформе со следующими характеристиками: 2 CPU Intel Xeon E5 2650, ОЗУ: 32 Гб, HDD: 2 Тб.;
Какие должны напрашиваться выводы у читателя?
У вас последние 5 лет используется один и тот же сервер для тестирования?
Продукт стал глючнее и тормознее в последней версии? EPS разворовываются и уводятся в офшоры? ))
Но проблема в том, что результаты тоже нужно кому-то интерпретировать. И какой смысл в любом системном администраторе, который может прокликать кнопочки, но по факту не будет знать, что делать дальше и который не сможет понять, какие уязвимости на самом деле критичные, а какие нет.
Да, конечно, интерпретация необходима. Но скажем так, с интерпретацией значительной части уязвимостей всё достаточно прозрачно: как правило это либо необновленные компоненты и системы (openssl, Apache), либо ошибки конфигурации.
Сканер безопасности даёт базовую информацию об уязвимости и её важности плюс ссылки на БДУ ФСТЭК, CVE и другие источники, в который кстати как правило, есть метрика CVSS (критичности уязвимости), которую можно разобрать детально по векторам с учётом особенностей своей сетки + там есть ссылки на дополнительные веб-ресурсы, где можно изучить детали уязвимости, как она проявляется и к чему ведёт.
Пусть лучше тогда системный администратор потратит время на изучение этих деталей, чем на "курение" мануалов nmap и Metasploit.
В большинстве случаев (но конечно, не всех) данный подход оправдан.
Вспомним, что все IT-технологии строятся на декомпозиции и инкапсуляции сложности по разным уровням и компонентам.
Мы можем не знать, зачем вызывается xor eax, eax, и не понимать тонкостей работы аллокатора с кучей, но при этом писать прекрасно работающие и полезные программы.
Подобные "погружения" в нижележащий слой, в некоторых особых редких случаях нужны, но конечно не всегда.
Только уже давным давно, как пользователь с пустым паролем не сможет зайти.
Когда мы удаляем хэш пароля из etc/shadow мы устанавливаем не пустой пароль, а по сути включаем для пользователя режим входа без пароля. Установить пустой пароль, как уже указывалось в статье, действительно нельзя и само собой зайти в систему тоже. В статье поправил.
Не совсем так, если у термина нет единого устоявшегося определения, это не значит что никто не знает, что это такое вообще )
Ну вот нет общепринятого научного определения понятия "интеллект", а есть миллион различных его интерпретаций, но все равно, в целом-то мы все понимаем о чём идет речь? ;)
С доверенной средой, конечно же, всё плохо не до такой степени, но тоже присутствует некоторая амбивалентность, которую и хочется прояснить в этом цикле статей.
Согласен, что надо было сразу сослаться на большее число источников, где оно вообще упоминается.
С другой стороны не хочется закапываться в глубокую теорию, хабр — это не учебник и не руководящий документ Гостехкомиссии. Изначально была попытка донести саму проблематику доверия к среде на живых практических примерах доступных любому компьютерному пользователю. И, разумеется "сброс пароля и запись хэша" здесь показывалось не как некоторое тайное знание, а как рядовой случай из практики уровень сложности будет расти линейно, дойдет очередь и SecureBoot, EFI, DXE и других интересных вещей.
Ага, а фанаты анонимности и параноики всеобщей слежки, наверное под своей доверенной средой будут понимать какой-нибудь Tails с браузером Tor, в который из поисковиков используется только duckduckgo.com =)
Тут надо сразу договориться о чьем доверии идет речь, кто является потребителем этого доверия :)
В любом случае тут необходим системный подход, понять что происходит с вашим устройством после нажатия кнопки Power on, каким компонентам в дальнейшем передается управления, а уж доверять или нет тому или иному из них, потребитель выбирает сам.
Список литературы конечно впечатляющий(и одновременно бесполезный). Наверное для дипломной работы готовили, но 1992год! Серьезно?
Абсолютно, надо понимать что это не копи-паста из реферата, а собствено действующий в РФ документ в плане оценке защиты автоматизированных (информационных) систем.
@KhodeN
Судя по названию, это чисто теоретический документ, по большей части философский, чем технический. А такие материалы остаются актуальными долго, т.к. они обо всем сразу и ни о чем вообще.
Это не отвлеченный философский документ. Не более философский, чем например Инструкция по охране труда =)
Его реально используют в аттестации государственных информационных систем, систем обработки персональных данных (те же поликлиники, ВУЗы и многое другое).
Да, 1992 год несколько демотивирует, но как уже выше написал, он достаточно высокоуровневый и абстрагирован от конкретных технологий.
Конечно, это не значит что современные системы проверяют лишь по древним фолиантам, есть и современные метастандарты "Общие критерии" с современными профилями защиты для средств доверенной загрузки, и приказы 17, 21, 31 и много чего более современного созданного уже в эпоху всеобщих облачных технологий и гипервизоров, но всему свое время, это темы для целых отдельных статей.
В данной статье хотелось с одной стороны рассказать о чем-то практическом (объяснить, как ломаются пароли и зачем нужно это доверие к среде) и заложить какую-то понятийную базу по trusted systems, а для этого как раз и подойдет старые, но все еще действующие наши и американские документы.
Общепринятое сокращение РД АС. В статье есть упоминание и ссылка на документ. Является действующим высокоуровневым документ ФСТЭК России и определяет классификацию автоматизированных систем (АС) в целях разработки и применения обоснованных мер по достижению требуемого уровня защиты информации во всех организациях, обрабатывающих конфиденциальную информацию и сведения, составляющие государственную тайну.
Осуществляет поиск свыше 100 типов дефектов кодирования.
Классифицирует потенциально опасные конструкции в соответствии со стандартом CWE.
Web-интерфейс позволяет проводить совместный аудит кода несколькими экспертами, а высокое качество разбора исходных текстов позволяет снизить число ложных срабатываний.
Гибкая конфигурация анализируемых проектов позволяет учитывать влияние таких особенностей языков программирования, как например директивы прекомпиляции (в C/C++).
Дефект, который у Вас в примере — это CWE-457: "Use of Uninitialized Variable". Подобные дефекты AppChecker обнаруживает в настоящее время для языка PHP. Возьмем к примеру тот же Chamilo LMS, о котором написано в статье. Там есть, например, вот такой код:
Здесь как раз используется неинициализированная переменная — значение присваивается переменной $ldapuser, сравнивается $ldap_user, а потом используется $ldapuser.
Этот дефект разработчики также исправили после того как мы им о нем сообщили.
В настоящее время мы дорабатываем продукт, чтобы находить этот дефект и для C/C++
Разумеется две эти аудитории не идентичны, но на мой взгляд у них — серьёзное пересечение, т.к активные пользователи вконтакте могут вполне захотеть иметь возможность читать и хабровские посты в общей ленте активностей.
Вообще всё это — отдельная гипотеза, и было бы интересно её проверить в одной из дальнейших статей этого цикла) Хотя бы на уровне прямого вопроса о чтении хабра в соцсетях )
Интуитивно мне кажется, что эти аудитории весьма близки.
По вашему тексту можно изучать методы геббельсовской пропаганды. Здесь есть и явная ложь («появились именно по результатам устранения замечаний»), и попытки манипулировать («Все, кто работает… прекрасно знает», «Старый добрый принцип…»), и отсутствие конкретики («работает также некорректно, но чуть лучше»), и попытки сталкивать с третьей стороной («ваша цель — не допустить распространения в отрасли сертификации…»), ну и, конечно, перевод на параллельные темы и масса эмоций (в основном обиды). Короче, характерно выделяющийся профиль.
Так как дискуссия перестает быть конструктивной, этот ответ вам будет заключительным.
Теперь по пунктам.
Относительно ГОСТ Р 56939-2016, который вы связали с обсуждаемой темой.
По поводу исследований, которые с ваших слов появились после замечаний, вот первый вариант стандарта, в котором они все есть, так как были изначально: http://docs.cntd.ru/document/1200113247
Cмотреть нужно 13-16 стр. asasasdd, ЛГАТЬ – это очень плохо.
Ликбез. Разумеется, ГОСТ изначально не был копией РД НДВ и не задумывался таковым. Извините, ну уж даже не знать, что упоминаемый статический анализ в РД и в ГОСТ – это абсолютно разные понятия?! Да уж.
Идея РД НДВ в декомпозиционном подходе к разбору структуры текста программы (там вопросы безопасности косвенно возникают лишь тогда, когда речь идет о защите гостайны уровня аж СС!). Это поймет любой начинающий программист.
ГОСТ Р 56939-2016 – это (для справки) организационный стандарт, который в том числе включает в себя совокупность мер, которые может обоснованно принять разработчик ПО с целью повышения безопасности программного изделия в рамках именно его жизненного цикла! Здесь, пардон, преследуются другие цели: разработчики стремятся минимизировать риски появления ошибок безопасности, уязвимостей, угроз (связанных их наличием) и т.п. Иные и задачи, и предметная область, и методическая база.
Относительно АК-ВС, который вы подтянули к обсуждаемой теме:
Есть старый анекдот:
— Таки мне Каррузо не понравился: каатавит, гнусавит, в ноты не попадает…
— Вы были на концерте Карузо?
— Нет, мне дгуг по телефону напел.
asasasdd, вы легально используете АК-ВС 2.0 на своем месте работы, и у вас есть конкретные замечания по целевой работе этого продукта? Вы о них сообщили в техподдержку? Разработчики не отреагировали? Номера ваших обращений в техподдержку? Все, как в анекдоте.
Мы признательны всем за конструктивные конкретные замечания и предложения по улучшению продукта, чему и посвящен данный пост.
Да, Вы правы, использовать standalone-приложение конечно приятнее. Но для этого необходимо, чтобы оно было на той же машине, на которой производится сборка проекта, а это не всегда удобно и даже не всегда реально — из-за различий операционных систем и даже архитектур процессора. Особенно, если аудит кода проводит не разработчик, а специалист по QA, ИБ и т.п.
Спасибо за предоставленный отзыв! Как с вами можно напрямую связаться, чтобы получить более подробную информацию для разрешения возникших сложностей?
Относительно результатов тестов, то похоже действительно проанализировались не все исходники, поскольку те дефекты, которые нашел pvs и о которых Вы пишете в своем комментарии, AppChecker также обнаруживает)
В частности:
V570 The 'Parabola' variable is assigned to itself. SomeFileName.cpp 287
Parabola =Parabola ;
Это тот же тип дефекта, что и нашелся у Вас:
присвоение переменной самой себе
tmp = tmp;
Относительно V522 Dereferencing of the null pointer 'SetterGetter' might take place. OtherFileName.cpp 305
if ( SetterGetter==0 )
{
SetterGetter->set(false) ;
}
об этом типе дефекта собственно сама наша статья) было бы подозрительно, если бы мы писали о таком дефекте и при этом его не обнаруживали)
У нас есть инструкция по конфигурированию проектов C/C++. Её можно скачать прямо из AppChecker — при создании проекта перейдите по ссылке «Перейти на страницу загрузки утилит и инструкции по конфигурированию» -> «Настройка парсера C/C++», там же можно скачать и утилиту для конфигурирования.
Шаги такие:
запустить утилиту CppConfMonitor.exe
пересобрать проект в Visual Studio
остановить утилиту, введя «s» в ее консоли
утилита сформирует архив, который нужно загрузить в AppChecker
Подождите-подождите, но ведь ещё в предыдущих версиях вашего продукта, Комрад 2 и Комрад 3 (судя по Tadviser ещё 2016 году) вы доблестно отрапортовали не о 5500 EPS, а в 2 раза больше, о целых 10 000 EPS на абсолютно такой же (сюрприз-сюрприз!) серверной конфигурации:
Текст Комрад 2 у tadviser:
Те же 10 000 EPS указаны в магазине Softline, где продают Комрад 3:
Какие должны напрашиваться выводы у читателя?
У вас последние 5 лет используется один и тот же сервер для тестирования?
Продукт стал глючнее и тормознее в последней версии? EPS разворовываются и уводятся в офшоры? ))
Не знаю, буду рада услышать вашу точку зрения))
Да, конечно, интерпретация необходима. Но скажем так, с интерпретацией значительной части уязвимостей всё достаточно прозрачно: как правило это либо необновленные компоненты и системы (openssl, Apache), либо ошибки конфигурации.
Сканер безопасности даёт базовую информацию об уязвимости и её важности плюс ссылки на БДУ ФСТЭК, CVE и другие источники, в который кстати как правило, есть метрика CVSS (критичности уязвимости), которую можно разобрать детально по векторам с учётом особенностей своей сетки + там есть ссылки на дополнительные веб-ресурсы, где можно изучить детали уязвимости, как она проявляется и к чему ведёт.
Пусть лучше тогда системный администратор потратит время на изучение этих деталей, чем на "курение" мануалов nmap и Metasploit.
В большинстве случаев (но конечно, не всех) данный подход оправдан.
Вспомним, что все IT-технологии строятся на декомпозиции и инкапсуляции сложности по разным уровням и компонентам.
Мы можем не знать, зачем вызывается
xor eax, eax, и не понимать тонкостей работы аллокатора с кучей, но при этом писать прекрасно работающие и полезные программы.Подобные "погружения" в нижележащий слой, в некоторых особых редких случаях нужны, но конечно не всегда.
Когда мы удаляем хэш пароля из etc/shadow мы устанавливаем не пустой пароль, а по сути включаем для пользователя режим входа без пароля. Установить пустой пароль, как уже указывалось в статье, действительно нельзя и само собой зайти в систему тоже. В статье поправил.
@manjrick
Не совсем так, если у термина нет единого устоявшегося определения, это не значит что никто не знает, что это такое вообще )
Ну вот нет общепринятого научного определения понятия "интеллект", а есть миллион различных его интерпретаций, но все равно, в целом-то мы все понимаем о чём идет речь? ;)
С доверенной средой, конечно же, всё плохо не до такой степени, но тоже присутствует некоторая амбивалентность, которую и хочется прояснить в этом цикле статей.
Согласен, что надо было сразу сослаться на большее число источников, где оно вообще упоминается.
С другой стороны не хочется закапываться в глубокую теорию, хабр — это не учебник и не руководящий документ Гостехкомиссии. Изначально была попытка донести саму проблематику доверия к среде на живых практических примерах доступных любому компьютерному пользователю. И, разумеется "сброс пароля и запись хэша" здесь показывалось не как некоторое тайное знание, а как рядовой случай из практики уровень сложности будет расти линейно, дойдет очередь и SecureBoot, EFI, DXE и других интересных вещей.
@sumanai
Ага, а фанаты анонимности и параноики всеобщей слежки, наверное под своей доверенной средой будут понимать какой-нибудь Tails с браузером Tor, в который из поисковиков используется только duckduckgo.com =)
Тут надо сразу договориться о чьем доверии идет речь, кто является потребителем этого доверия :)
В любом случае тут необходим системный подход, понять что происходит с вашим устройством после нажатия кнопки Power on, каким компонентам в дальнейшем передается управления, а уж доверять или нет тому или иному из них, потребитель выбирает сам.
@TimsTims
Абсолютно, надо понимать что это не копи-паста из реферата, а собствено действующий в РФ документ в плане оценке защиты автоматизированных (информационных) систем.
@KhodeN
Это не отвлеченный философский документ. Не более философский, чем например Инструкция по охране труда =)
Его реально используют в аттестации государственных информационных систем, систем обработки персональных данных (те же поликлиники, ВУЗы и многое другое).
Да, 1992 год несколько демотивирует, но как уже выше написал, он достаточно высокоуровневый и абстрагирован от конкретных технологий.
Конечно, это не значит что современные системы проверяют лишь по древним фолиантам, есть и современные метастандарты "Общие критерии" с современными профилями защиты для средств доверенной загрузки, и приказы 17, 21, 31 и много чего более современного созданного уже в эпоху всеобщих облачных технологий и гипервизоров, но всему свое время, это темы для целых отдельных статей.
В данной статье хотелось с одной стороны рассказать о чем-то практическом (объяснить, как ломаются пароли и зачем нужно это доверие к среде) и заложить какую-то понятийную базу по trusted systems, а для этого как раз и подойдет старые, но все еще действующие наши и американские документы.
Общепринятое сокращение РД АС. В статье есть упоминание и ссылка на документ. Является действующим высокоуровневым документ ФСТЭК России и определяет классификацию автоматизированных систем (АС) в целях разработки и применения обоснованных мер по достижению требуемого уровня защиты информации во всех организациях, обрабатывающих конфиденциальную информацию и сведения, составляющие государственную тайну.
Ответили Вам на этот вопрос в другой теме: https://habrahabr.ru/company/echelon/blog/320398/#comment_10038854
Конкурентные преимущества AppChecker:
Дефект, который у Вас в примере — это CWE-457: "Use of Uninitialized Variable". Подобные дефекты AppChecker обнаруживает в настоящее время для языка PHP. Возьмем к примеру тот же Chamilo LMS, о котором написано в статье. Там есть, например, вот такой код:
Здесь как раз используется неинициализированная переменная — значение присваивается переменной $ldapuser, сравнивается $ldap_user, а потом используется $ldapuser.
Этот дефект разработчики также исправили после того как мы им о нем сообщили.
В настоящее время мы дорабатываем продукт, чтобы находить этот дефект и для C/C++
Вообще всё это — отдельная гипотеза, и было бы интересно её проверить в одной из дальнейших статей этого цикла) Хотя бы на уровне прямого вопроса о чтении хабра в соцсетях )
Интуитивно мне кажется, что эти аудитории весьма близки.
Можно и не задействовать для перекодировки LibreOffice вообще, так как текстовый редактор встроенный в RStudio может пересохранить файл с любой кодировкой.
По вашему тексту можно изучать методы геббельсовской пропаганды. Здесь есть и явная ложь («появились именно по результатам устранения замечаний»), и попытки манипулировать («Все, кто работает… прекрасно знает», «Старый добрый принцип…»), и отсутствие конкретики («работает также некорректно, но чуть лучше»), и попытки сталкивать с третьей стороной («ваша цель — не допустить распространения в отрасли сертификации…»), ну и, конечно, перевод на параллельные темы и масса эмоций (в основном обиды). Короче, характерно выделяющийся профиль.
Так как дискуссия перестает быть конструктивной, этот ответ вам будет заключительным.
Теперь по пунктам.
Относительно ГОСТ Р 56939-2016, который вы связали с обсуждаемой темой.
По поводу исследований, которые с ваших слов появились после замечаний, вот первый вариант стандарта, в котором они все есть, так как были изначально: http://docs.cntd.ru/document/1200113247
Cмотреть нужно 13-16 стр. asasasdd, ЛГАТЬ – это очень плохо.
Ликбез. Разумеется, ГОСТ изначально не был копией РД НДВ и не задумывался таковым. Извините, ну уж даже не знать, что упоминаемый статический анализ в РД и в ГОСТ – это абсолютно разные понятия?! Да уж.
Идея РД НДВ в декомпозиционном подходе к разбору структуры текста программы (там вопросы безопасности косвенно возникают лишь тогда, когда речь идет о защите гостайны уровня аж СС!). Это поймет любой начинающий программист.
ГОСТ Р 56939-2016 – это (для справки) организационный стандарт, который в том числе включает в себя совокупность мер, которые может обоснованно принять разработчик ПО с целью повышения безопасности программного изделия в рамках именно его жизненного цикла! Здесь, пардон, преследуются другие цели: разработчики стремятся минимизировать риски появления ошибок безопасности, уязвимостей, угроз (связанных их наличием) и т.п. Иные и задачи, и предметная область, и методическая база.
Относительно АК-ВС, который вы подтянули к обсуждаемой теме:
Есть старый анекдот:
— Таки мне Каррузо не понравился: каатавит, гнусавит, в ноты не попадает…
— Вы были на концерте Карузо?
— Нет, мне дгуг по телефону напел.
asasasdd, вы легально используете АК-ВС 2.0 на своем месте работы, и у вас есть конкретные замечания по целевой работе этого продукта? Вы о них сообщили в техподдержку? Разработчики не отреагировали? Номера ваших обращений в техподдержку? Все, как в анекдоте.
Мы признательны всем за конструктивные конкретные замечания и предложения по улучшению продукта, чему и посвящен данный пост.
Относительно результатов тестов, то похоже действительно проанализировались не все исходники, поскольку те дефекты, которые нашел pvs и о которых Вы пишете в своем комментарии, AppChecker также обнаруживает)
В частности:
V570 The 'Parabola' variable is assigned to itself. SomeFileName.cpp 287
Это тот же тип дефекта, что и нашелся у Вас:
присвоение переменной самой себе
Относительно V522 Dereferencing of the null pointer 'SetterGetter' might take place. OtherFileName.cpp 305
об этом типе дефекта собственно сама наша статья) было бы подозрительно, если бы мы писали о таком дефекте и при этом его не обнаруживали)
Шаги такие: